PFE Chandoul 2005

RAPPORT DE PROJET DE FIN DETUDES
Filire
Ingnieurs en Tlcommunications

Option
Ingnierie des rseaux.

CONCEPTION ET DEVELOPPEMENT DUN
SYSTEME DINFORMATION MULTIMODALE
POUR LES TRANSPORTS COLLECTIFS

Elabor par :
Haythem CHANDOUL

Encadr par :
Mhamed CHAMMAM

Anne universitaire : 2004/2005

Chandoul Haythem - SUPCOM 2005

1

P P r r o o j j e e t t d d e e f f i i n n d d t t u u d d e e s s

CAHIER DES CHARGES7
INTRODUCTION GENERALE....8
LINFORMATION MULTIMODALE DANS LE TRANSPORT COLLECTIF.10
Introduction.............................................................................................................................. 10
I Dfinition du concept de systme dinformation multimodale.......................................... 10
I.1 Lintermodalit................................................................................................................. 10
I.2 La multimodalit............................................................................................................... 11
I.3 Information multimodale.................................................................................................. 11
I.4 Systme dinformation multimodale................................................................................. 12
II Problmatique de linformation aux usagers .................................................................... 12
II.1 Problmatique de linformation multimodale.................................................................. 12
II.2 Comment approche-t-on l'information dans les transports ?........................................... 14
II.3 Comment caractrise-t-on linformation communiquer ?............................................ 15
II.4 Comment approche-t-on la question de lusage dans les transports ?............................. 16
II.5 Les attentes des usagers................................................................................................... 17
III La chane de linformation................................................................................................. 20
III.1 La collecte de donnes................................................................................................... 20
III.2 Lhomognisation et lintgration des donnes............................................................ 20
III.3 Llaboration de linformation....................................................................................... 20
III.4 La distribution de linformation..................................................................................... 20
III.5 Lusage de linformation................................................................................................ 21
Conclusion................................................................................................................................. 22
ETUDE CRITIQUE DES SIM EXISTANTS.23
Introduction.............................................................................................................................. 23
I Dveloppement des SIM........................................................................................................ 23
I.1 Rle dun SIM................................................................................................................... 23
I.2 Orientations techniques et fonctionnelles des SIM........................................................... 25
I.3 Dveloppement des services............................................................................................. 25
I.3 Difficults rencontres...................................................................................................... 26
S SO OM MM MA AI I R RE E


2

II Expriences .......................................................................................................................... 27
II.1 Le contexte anglais.......................................................................................................... 27
II.1.1 Transport for London (TfL) ............................................................................................27
II.2 Le contexte franais......................................................................................................... 29
II.2.1 COPILOT...........................................................................................................................29
II.2.2 Dfinition des services ....................................................................................................29
II.2.3 Architectures et standards pour les transports collectifs ...........................................30
II.3 Le contexte allemand....................................................................................................... 30
II.3.1 DELFI.................................................................................................................................30
II.4 Le contexte hollandais : RDS-TMC................................................................................ 31
II.5 Le contexte des Etats-Unis, du Canada et du J apon........................................................ 31
II.5.1 Dveloppement des Systmes de Transport Intelligents (STI)..................................31
II.5.2 Comit ATIS .....................................................................................................................32
II.5.3 Tourisme et voyages........................................................................................................32
III Projets en cours de ralisation........................................................................................... 32
III.1 Transport Direct............................................................................................................. 32
Conclusion................................................................................................................................. 35
SPECIFICATION DUN SYSTEME DINFORMATION TUNISIEN SIMT..36
Introduction.............................................................................................................................. 36
I Etude de Lexistant : le contexte national ........................................................................... 36
II Les objectifs du projet ......................................................................................................... 38
III La spcification des besoins ............................................................................................... 38
III.1 La notation : UML.......................................................................................................... 38
III.2 Les processus unifis...................................................................................................... 39
III.3 Le processus de dveloppement : 2TUP........................................................................ 40
III.4 Spcification des besoins fonctionnels........................................................................... 40
III.4.1 Modlisation des besoins ..............................................................................................40
III.4.1.1 Identification des acteurs........................................................................................40
III.4.1.2 Identification des cas dutilisation ........................................................................42
III.4.1.3 Description des cas dutilisation............................................................................44
III.5 Spcification des besoins techniques............................................................................. 50
III.5.1 Capture des besoins .......................................................................................................50
III.5.2 Contraintes et choix techniques....................................................................................50 III.5.2
III.5.2.1 Utilisation de XML pour dcrire linformation transport..................................50
III.5.2.2 Les technologies SMS..............................................................................................52
IV.5.3 Modlisation des besoins techniques ..........................................................................53
Conclusion................................................................................................................................. 54


3

CONCEPTION DUN SYSTEME DINFORMATION SIMT..55
Introduction.............................................................................................................................. 55
I.1 Partitionnement logique.................................................................................................... 55
I.2 Modle du sous-systme de gestion des informations collectes..................................... 57
I.2.1 Dveloppement du modle statique ..............................................................................57
I.2.2 Dveloppement du modle dynamique ........................................................................58
I.2.2.1 Elaboration des diagrammes dinteraction.............................................................58
I.2.2.2 Le diagramme des classes.........................................................................................60
I.3 Modle du sous-systme daccs aux informations.......................................................... 60
I.3.1 Architecture logicielle de lapplication web..................................................................60
I.3.2 Dveloppement du modle objet de conception ..........................................................62
I.3.2.1 Modle objet de conception de la couche prsentation (vue) ..............................63
I.3.3 Vue dynamique du sous-systme...................................................................................64
I.3.3.1 Elaboration des diagrammes de collaboration.......................................................64
I.3.3.2 Les diagrammes des classes......................................................................................66
II Modlisation du transport collectif..................................................................................... 68
II.1 Origines du modle adapt.............................................................................................. 68
II.2 Description du modle..................................................................................................... 69
II.3 Les relations importantes dans le modle........................................................................ 72
II.4 Description du modle en XML ...................................................................................... 73
Conclusion................................................................................................................................. 75

REALISATION DU SYSTEME DINFORMATION SIMT..76
Introduction.............................................................................................................................. 76
I Choix techniques.................................................................................................................... 76
I.1 Utilisation des logiciels libres et ceux Open Source........................................................ 76
I.2 Le langage de programmation : J ava................................................................................ 77
I.3 Lapplication oriente Web............................................................................................... 77
I.3.1 Le serveur web Tomcat ....................................................................................................78
I.3.2 HTML: Hyper Text Markup Language..........................................................................78
I.3.3 Java Server Pages (JSP) .....................................................................................................78
I.3.3.1 Le fonctionnement des Java Server Pages ..............................................................78
I.3.3.2 Avantages des Java Server Pages.............................................................................79
I.3.4 JavaScript............................................................................................................................80
I.4 La base de donnes........................................................................................................... 80
II Architecture gnrale du systme....................................................................................... 81
II.1 Description de larchitecture........................................................................................... 81
II.2 Acquisition automatique des donnes............................................................................. 82
II.3 Edition de linformation en XML.................................................................................... 83
II.3.1 LAPI JAXP .......................................................................................................................83
II.4 Elaboration du graphe pour le calcul ditinraire............................................................ 85
II.4.1 LAPI Mascopt..................................................................................................................85
II.4.2 Gnration du graphe .....................................................................................................86


4

II.5 Calcul ditinraire pour les transports collectifs.............................................................. 87
II.5.1 Calcul des k plus courts chemins ..................................................................................88
II.5.2 Description du problme................................................................................................89
II.5.3 Formulation de lalgorithme des k plus courts chemins............................................90
II.5.4 Choix de lalgorithme......................................................................................................90
II.5.5 Optimisation.....................................................................................................................91
II.5.6 Elimination des solutions triviales ................................................................................91
II.5.7 Implmentation de lalgorithme....................................................................................91
II.6 Distribution de linformation........................................................................................... 93
II.6.1 Service SMS.......................................................................................................................93
II.6.1.1 LAPI SMPPAPI ........................................................................................................93
II.6.1.2 Description de lapplication ....................................................................................93
II.6.1.3 Validation de lapplication SMS .............................................................................94
II.6.2 Lapplication Web............................................................................................................96
II.7 Accs aux bases de donnes............................................................................................ 97
Conclusion................................................................................................................................. 97
CONCLUSION GENERALE..98
BIBLIOGRAPHIE..100
ANNEXE A : UML : LES PROCESSUS UNIFIES...105
ANNEXE B : LE MODELE MVC II.....110


5


FIGURE 1.1 : ILLUSTRATION DES ATTENTES DES USAGERS.......................................... 13
FIGURE 1.2 : LES PRINCIPALES APPROCHES DE LINFORMATION DANS LES
TRANSPORTS......................................................................................................................... 14
FIGURE 1.3 : LES PRINCIPALES CARACTRISATION DE LINFORMATION AUX
USAGERS................................................................................................................................ 16
FIGURE 1.4 : RELATION ENTRE LES BESOINS DES UTILISATEURS ET LE TYPE
DINFORMATION..................................................................................................................... 19
FIGURE 1.5 : LES TACHES PRINCIPALES RELIEES A UN SIM DEPUIS LA COLLECTE
JUSQUA LUSAGE.................................................................................................................. 21
FIGURE 2.1 : LES SIM, OUTILS DE GESTION DES DEPLACEMENTS................................ 24
FIGURE 2.2 : TECHNOLOGIES UTILISEES POUR LA DISTRIBUTION DE LINFORMATION
................................................................................................................................................. 25
FIGURE 2.3 : QUELQUES MOYENS DACCES AUX SERVICES DE TFL............................. 28
FIGURE 3.2 : CAS DUTILISATION DU SOUS-SYSTEME DE GESTION DES
INFORMATIONS COLLECTEES............................................................................................. 42
FIGURE 3.3 : CAS DUTILISATION DU SOUS-SYSTEMES DE GESTION DACCES AUX
INFORMATIONS...................................................................................................................... 43
FIGURE 3.4 : STRUCTURE MATERIELLE DE LAPPLICATION............................................ 54
FIGURE 4.1 : ORGANISATION DES CAS DUTILISATION PAR PAQUETAGES.................. 56
FIGURE 4.2 : LE PARTITIONNEMENT EN PAQUETAGES DU 1
ER
SOUS-SYSTEME ......... 57
FIGURE 4.3 : DIAGRAMME DES CLASSES STATIQUE........................................................ 57
FIGURE 4.4 : DIAGRAMME DES CLASSES DYNAMIQUE.................................................... 60
L LI I S ST TE E
D DE ES S F FI I G GU UR RE ES S


6

FIGURE 4.6 : LE PARTITIONNEMENT EN PAQUETAGES DU DEUXIEME SOUS-SYSTEME
................................................................................................................................................. 63
FIGURE 4.7 : LA COUCHE PRESENTATION DE LAPPLICATION WEB.............................. 63
FIGURE 4.8 : DIAGRAMME DES CLASSES DU PAQUETAGE PLANIFICATIONVOYAGE.. 67
FIGURE 4.9 : DIAGRAMME DES CLASSES DU PAQUETAGE
CONSULTERINFORMATIONS................................................................................................ 67
FIGURE 4.10 : DIAGRAMME DES CLASSES DU PAQUETAGE
ADMINISTRATIONSERVICES ................................................................................................ 68
FIGURE 4.11 : MODELISATION DU RESEAU DE TRANSPORT .......................................... 73
FIGURE 4.12 : LA DTD FORMULEE POUR VALIDER LES FICHIERS XML ......................... 74
FIGURE 4.13 : LE FICHIERS XML CONTENANT LINFORMATION.................................. 74
FIGURE 5.1 : COMPARAISON ENTRE JSP ET PHP............................................................. 80
FIGURE 5.2 : ARCHITECTURE GENERALE DU SYSTEME.................................................. 81
FIGURE 5.3 : ACQUISITION AUTOMATIQUE DES DONNEES............................................. 82
FIGURE 5.4 : LEDITEUR GRAPHIQUE DE FICHIERS XML ................................................. 84
FIGURE 5.4 : UN FICHIER SOUS LE FORMAT MGL DE MASCOPT.................................... 86
FIGURE 5.5 : UN EXEMPLE DE PLANIFICATION DYNAMIQUE ET MULTIMODALE DE
VOYAGE.................................................................................................................................. 89
FIGURE 5.6 : ALGORITHME DE RECHERCHE DES K PLUS COURTS CHEMINS
IMPLEMENTE.......................................................................................................................... 92
FIGURE 5.7 : IHM DE GESTION DES DONNEES ET CONFIGURATION DU LIEN SMPP... 94
FIGURE 5.8 : REQUETE ET REPONSE PAR SMS................................................................ 95
FIGURE 5.9 : REQUETE PAR LE PROTOTYPE WEB ........................................................... 96
FIGURE 5.10 : REPONSE PAR LE PROTOTYPE WEB................................................... 96


7


our mettre en place le systme dinformation multimodale tunisien SIMT, une
bonne mthodologie ainsi quun ensemble de rgles et de contraintes
fonctionnelles et techniques sont exigs.

Du point de vue fonctionnel, SIMT devra permettre, dune part,
laccomplissement dun ensemble de procds pour crer linformation sur les
transports collectifs essentiellement la collecte des donnes, leur homognisation et
llaboration de linformation daide au dplacement. Dautre part, il assurera la
distribution de cette information aux usagers des transports collectifs sur une grande
chelle.

Du point de vue technique, les objectifs sont de concevoir et de dvelopper des
techniques de collecte dinformations, des outils dhomognisation des donnes
collectes, des fonctionnalits permettant de crer un modle du rseau de transport
collectif tunisois et de lui affecter des paramtres rels tels que les lignes de transport,
les dures de parcours afin deffectuer des calculs ditinraires. Une tape primordiale
dans le processus de distribution des informations au public est de dterminer les
mdias ncessaires et de dvelopper les mthodes daccs.

P
C CA AH HI I E ER R
D DE ES S C CH HA AR RG GE ES S


8


information aux usagers sur loffre de transport collectif est un domaine
incontournable de notre socit de linformation . Elle couvre un grand
nombre de modes de transport (bus, mtro, train) et se dcline diffrentes
chelles, du quartier au pays entier. Elle concerne une grande diversit dacteurs, les
utilisateurs de toutes catgories, les exploitants de rseaux et les administrations. Elle
se traduit sous forme de fonctions plus ou moins personnalises assures par des
systmes dinformation multimodale (SIM) : fourniture des horaires, calcul ditinraires
optimiss selon divers critres, distribution dinformations sur les vnements
importants, etc. Le dveloppement des SIM va de paire avec Le dveloppement des
technologies de linformation (web, GSM, GPRS, etc.) et la distribution de linformation
est relie aux mdias de communication supports de cette information (Internet,
messages SMS, WAP, bornes interactives, centres dappels).
Un des grands enjeux consiste profiter de ces dveloppements et de la demande
croissante du public en matire dinformation sur le transport en combinant les
informations sur chaque mode de transport en une seule information multimodale
couvrant tous les modes. Nous pouvons ds maintenant affirmer que la fonction
essentielle dun systme dinformation multimodale est de fournir lusager des
transports collectifs toute linformation ncessaire la ralisation de son voyage.
Ce projet de fin dtudes, entre dans le cadre de dveloppements des systmes
dinformation multimodale en Tunisie. Lenjeu principal est de parvenir spcifier,
concevoir et dvelopper un prototype incorporant les fonctionnalits principales dun
SIM. Nous avons appel ce prototype SIMT pour Systme dInformation
Multimodale Tunisien .
L
I I N NT TR RO OD DU UC CT TI I O ON N
G GE EN NE ER RA AL LE E


9


Ce rapport se divise en cinq chapitres.
Dans le premier chapitre nous faisons le point sur linformation multimodale en
dcrivant ses caractristiques et en introduisant les concepts qui y sont lis. Nous
posons ensuite la problmatique de linformation aux voyageurs. A la fin de ce
chapitre, nous prsentons la chane de linformation au sein des SIM ds la collecte
jusqu lusage.
Le deuxime chapitre traitera de certains SIM existants lchelle
internationale en prsentant une tude critique leur gard. Nous axerons sur la
partie conceptuelle et celle technologique de ces systmes.
Au troisime chapitre, la spcification de notre SIM dbutera par une tude de
lexistant puis la modlisation du systme en commenant par la spcification des
besoins fonctionnels et techniques.
Le quatrime chapitre exposera la conception du systme en dcrivant la
phase danalyse depuis llaboration du modle statique jusquau modle dynamique.
La dernire partie de ce chapitre sera consacre la modlisation du rseau de
transport collectif tunisois.
Le dernier chapitre traitera, quant lui, la phase de dveloppement des
principaux modules du SIMT en mettant laccent sur les apports du SIMT et les
solutions adoptes pour le mettre en uvre.


10

C

h a p i t r e
1
I nt r oduc t i on

ans le domaine des transports, l'avenir devra tre au dveloppement
harmonieux et complmentaire des divers modes de transport. Linformation
multimodale constitue lun des maillons essentiels de cette problmatique. Il
sagit de fournir toute information utile et adquate laccomplissement dun
dplacement qui peut tre ralis en utilisant diffrents modes de transport. Ceci vise,
un niveau individuel, amliorer le confort et lefficacit des dplacements et, un
niveau collectif, favoriser lusage multimodal et raisonn des diffrents modes de
transport.
Mais lre de la socit dinformation, lusager des transports rencontre
encore des difficults accder linformation lui permettant de prparer et
deffectuer ses dplacements. Diffrents solutions et services peuvent tre proposs
par des systmes dinformation multimodale (SIM), supports de diffusion de
linformation multimodale.
I Df i ni t i on du c onc ept de syst me di nf or mat i on
mul t i modal e
I .1 Li nt er modal i t
Lorganisme franais GART (Groupement des Autorits Responsables de
Transport) dfinit lintermodalit comme tant le principe dorganisation et
darticulation de loffre de transport, visant coordonner plusieurs systmes modaux
par une gestion et un amnagement spcifiques des interfaces entre les diffrents
rseaux [1].
D
I I . . L L I I N NF FO OR RM MA AT TI I O ON N M MU UL LT TI I - -
M MO OD DA AL LE E D DA AN NS S L LE E
T TR RA AN NS SP PO OR RT T C CO OL LL LE EC CT TI I F F


11

I .2 La mul t i modal i t
Le GART dfinit la multimodalit comme tant le recours plusieurs modes de
transport pour satisfaire des besoins de dplacement entre une origine et une
destination. Elle se place donc en amont, et couvre une proposition faite au client
dans laquelle chaque possibilit de choix peut tre monomodale (un seul moyen
utiliser) ou intermodale (plusieurs moyens successifs utiliser) [1] [6].
Nous pouvons distinguer :
- individu multimodal : personne qui a recours de faon rgulire plusieurs modes de
transports diffrents, choisis en fonction des circonstances et de la nature de ses
dplacements
- offre multimodale : infrastructure ou service permettant une personne dutiliser au
choix un des modes de transport proposs ou de les articuler successivement (ple
multimodal, information multimodale).

I .3 I nf or mat i on mul t i modal e
Une dfinition du concept dinformation multimodale pourrait tre : Mise
disposition de toute information utile et pertinente pour la prparation et
laccomplissement dun dplacement pouvant tre ralis en utilisant diffrents modes
de transport [1] [6].
Le concept dinformation multimodale est de proposer le mode optimal de
transport pour raliser le dplacement souhait, dune part, et daider la ralisation
du dplacement, dautre part [1] [5]. Son objectif est double :
- Eclairer le choix modal : proposer loffre globale de tous les modes de transport sur
un dplacement donn partir dadresses origine destination
- Faciliter lusage des rseaux : accompagner le voyageur qui se dplace dans tous
les rseaux de transport et linformer bon escient.
Nous la dcomposons en linformation avant le dplacement qui est importante
pour le choix du mode, de litinraire et de lhoraire du dplacement et linformation
pendant le dplacement qui peut renseigner sur les perturbations relatives aux
diffrents modes de transport (congestion routire, incident dexploitation).


12

I .4 Syst me di nf or mat i on mul t i modal e
Un systme dinformation multimodale (SIM) fournit des informations utiles sur
les diffrents modes de dplacement dun primtre gographique donn. Il informe
notamment sur les itinraires suivre, la dure, les cots, ainsi que les priodes et les
modes choisir. Il a pour vocation de constituer une aide oprationnelle au
dplacement. Lutilisation du terme systme dcoule du fait que plusieurs supports
(techniques, tlmatiques) et plusieurs schmas dorganisation sont articuls pour la
distribution de ces informations [5] [12].
Un tel systme repose sur lensemble des acteurs de transport impliqus dans
sa cration et sa gestion (oprateurs de transport collectif, tat) tout en tant centr
sur les usagers. Ces derniers sont en effet le point de dpart de la cration des SIM et
leur succs dpend de leur capacit rpondre aux besoins des voyageurs. Cest
partir de lidentification de leurs besoins que sera cr un systme efficace [12].
De plus en plus, les usagers des transports collectifs ont besoin dinformations
sur des destinations et des temporalits plus variables. Un systme dinformation
multimodale performant apporte une rponse cette nouvelle aspiration de mieux se
dplacer quelque soit le lieu et lheure. Dautres facteurs, plus globaux, ont amen
rflchir au concept de multimodalit ; ce sont principalement les problmes de
congestion, les nuisances environnementales et les difficults de stationnement en
ville [5].
I I Pr obl mat i que de l i nf or mat i on aux usager s
I I .1 Pr obl mat i que de l i nf or mat i on mul t i modal e
La problmatique de linformation multimodale prsente un intrt pour divers
acteurs du domaine des transports [2].
Dune part, pour les industriels (transporteurs, exploitants, dveloppeurs de
services) ainsi que pour les agglomrations, elle reprsente un atout en matire de
qualit de service qui peut fortement amliorer lattractivit des transports collectifs, et
par la mme en augmenter la frquentation.
Dautre part, pour les adeptes du transport collectif, linformation dans les
transports collectifs est devenue, non seulement un besoin, mais aussi une exigence.
L'information transport attache un dplacement est une demande forte des


13

usagers. Comment se rendre d'un point A un point B? Par quel mode de transport?
En combien de temps? A quel cot? sont quelques-unes des questions rcurrentes.
Les usagers souhaitent tre de mieux en mieux informs avant et pendant leur
voyage. Cest autour de cette dichotomie que nous allons parler, plus loin dans ce
chapitre, des attentes des usagers en matire dinformation dans les transports, en
laissant de ct laprs voyage , phase qui pourrait tre sans aucun doute riche
denseignements, et ce, par des techniques de retours dexprience et qui intresse
surtout les industriels [1].

Avant l e dpl ac ement Pendant l e dpl ac ement

Figure 1.1 : Illustration des attentes des usagers
Une autre difficult que rencontre lusager est quil dispose gnralement dune
multitude de donnes juxtaposes qui ne se transforment que rarement ou
malaisment en informations utiles, quil sagisse dinformations qui doivent tre
immdiatement oprationnelles lorsquun problme spcifique se pose ou quil


14

sagisse dinformations susceptibles de stimuler une utilisation plus large et plus
frquente des transports publics, laquelle lusager ne songe pas spontanment.
Un autre point prendre en considration est que la communication des
messages informatifs sur des interfaces diversifies ncessite un soin particulier en
terme de cohrence, d'accessibilit, et de manire gnrale d'ergonomie [1] [2] [3].
I I .2 Comment appr oc he-t -on l ' i nf or mat i on dans l es t r anspor t s ?
La question de linformation des usagers de transports peut tre aborde selon
divers points de vue gravitant plus ou moins autours de deux points extrmes
schmatiss par :
- Une appr oc he t ec hnoc ent r e
Majoritairement reprsente dans lingnierie, elle se focalise sur les media
vhicules de linformation, partant de loffre technologique disponible pour concevoir
des produits.
- Une appr oc he ant hr opoc ent r e
Cette autre dmarche consiste penser le produit aprs avoir valu les rels
besoins des utilisateurs. Cette voie est certes porteuse dune connaissance fine du
sujet mais reste coteuse en temps et en moyens, ce qui la rend parfois difficilement
applicable dans un contexte de dveloppement industriel [2].
Lapproche que nous avons adopte dans llaboration de ce projet est une
combinaison des deux dernires. En effet, nous ne sommes bass sur les mdias
disponibles en sappuyant sur les tudes effectues dans les pays ayant une
infrastructure relative aux transports collectifs proche de la notre.
Appr oc he
Tec hnoc ent r e Ant hr opoc ent r e
1- Se focalise sur les media qui achemine
linformation.
2- Dpend de loffre technologique
disponible.
3- Court le risque de faillir si elle ne
satisfait pas les besoins des utilisateurs.
1- Part de lvaluation des rels besoins
des utilisateurs.
2- Se base sur des tudes et des
statistiques.
3- Coteuse en temps et en moyens
Figure 1.2 : Les principales approches de linformation dans les transports


15

I I .3 Comment c ar ac t r i se-t -on l i nf or mat i on c ommuni quer ?
Comme son nom lindique un systme dinformation se donne pour objectif de
fournir de linformation des utilisateurs, plus prcisment cette architecture
informatique doit formaliser des donnes-systme en information-utilisateur.
Cette information peut tre :
- Per sonnal i se ou c ol l ec t i ve
Une information collective laisse lusager le soin de trier dans la masse
dinformations celle qui lintresse ou le concerne. Par contre un systme
dinformation personnalise aide ou assiste lusager dans sa recherche en sadaptant
ses buts, et en prenant ventuellement en compte un profil qui lui est propre
(centres dintrts, prfrences) [2] [12].

- St at i que ou dynami que
Linformation vhicule peut aussi tre statique et donc valable en tout temps et
en toute circonstance (nom des stations par exemple), ou dynamique (temps rel)
dans ce cas la elle est remise jour priodiquement et subit des fluctuations [2].

- Spont ane ou l a demande
Une autre caractrisation prend en compte linitiative de lusager. Une
information spontane serai une information communique tous les usagers ou
certains dentre eux et cela linitiative du systme (exemple : alerte de perturbation,
en cas dincident). Linformation dite " la demande" est celle qui fait suite une
dmarche de recherche entreprise par lusager [2].

- De pr ox i mi t ou di st anc e
Linformation est dite de proximit lorsquelle est mise sur les lieux
dexploitation et elle trouvera son aboutissement au travers des panneaux
messages variables (PMV), des panneaux daffichage, des cransAlors que
linformation dite distance sera consulte sur Internet, des bornes interactives, des
assistants personnels (PDA), des tlphones mobiles... [1] [5] [12]


16

Car ac t r i sat i on de l i nf or mat i on
Per sonnal i se Col l ec t i ve
Le systme dinformation sadapte aux
buts de lutilisateur et tient compte de son
profil.
Lutilisateur trie les informations et en
prend ce qui lintresse.
St at i que Dynami que
Valable tout moment et en toutes
circonstances.
En temps rel et remise jour
priodiquement.
Spont ane A l a demande
Communique tous les usagers
linitiative du systme lui-mme.
Communique suite une dmarche de
recherche entreprise par lusager.
De pr ox i mi t A di st anc e
Emise sur les lieux dexploitation tels que
les gares.
Consulte hors lieux dexploitation par
Internet ou sur tlphone mobile par
exemple.
Figure 1.3 : Les principales caractrisation de linformation aux usagers

I I .4 Comment appr oc he-t -on l a quest i on de l usage dans l es
t r anspor t s ?
Ltude des besoins des usagers ncessite de les caractriser [2]. Deux grandes
classes de typologies existent :
- Les c at gor i sat i ons par f r quenc e dut i l i sat i on
Cest une classification comportementale o lusager est caractris par son
habitude d'utilisation des modes de transports. Parmi les classements frquentiels
figure principalement le classement : rgulier / occasionnel/ non utilisateur/ mixte
(voiture personnelle et transport collectif).
Une catgorisation frquentielle prsente le risque dtre rductrice. Elle
suppose en effet une similitude de comportement et de besoins des usagers dun
mme mode de transport en ignorant les diffrences interindividuelles. Ainsi, des
catgories d'usagers peuvent tre ignores telles que :


17

- les personnes handicapes qui peuvent avoir les mmes comportements
frquentiels d'utilisation mais ont des besoins particuliers en termes d'accessibilit et
d'adaptabilit;
- les touristes qui peuvent tre temporairement des occasionnels puis acqurir
une connaissance du rseau qui les rendraient rguliers (selon ces classifications)
pour le reste de leur sjour.
- Les c at gor i sat i ons par pr of i l
Dans ces typologies lusager est qualifi par des caractristiques
personnalises. Parmi les classements par profil figure principalement le classement :
age/ sexe/ rpartition gographique/ mode de transports utilis.
A linverse de la prcdente cette sorte de typologie met laccent sur les
caractristiques intrinsques aux individus utilisateurs.
La diversit de catgorisation tmoigne de la complexit de la question. La
difficult qui ressort est la suivante : trouver une catgorisation qui soit assez fine pour
tre rvlatrice de la diversit des usagers, et assez simple pour tre ralisable dans
un contexte de conception industrielle. Lenjeu est daccder aux besoins rels des
usagers afin de formuler une information pertinente et accessible un maximum
d'usagers [2].
I I .5 Les at t ent es des usager s
Les attentes des usagers des transports collectifs sont quelque peu diffrentes
selon la tranche de population laquelle on sadresse. De plus, selon les tranches
dges, les besoins et les usages voluent [1] [5].
Les champs dapplication de linformation multimodale sont nombreux et
recouvrent la notion de territoires, de modes de transport et de cibles. En effet, sur le
fond, linformation, son laboration et son traitement peuvent tre diffrents selon la
couverture de la zone (urbaine, priurbaine, interurbaine...), selon le mode de
transport (collectif terrestre-arien-maritime, routier, motoris ou non), ou selon la
cible vise (usagers, gestionnaires de rseaux).
Les attentes des usagers portent essentiellement sur les caractristiques de
linformation et sur son contenu.
Dune part, les utilisateurs souhaitent avoir une information disponible quels
que soient le lieu et lheure. En effet, la dlocalisation de linformation consiste


18

amener celle-ci lendroit mme o lindividu en a besoin. Cet endroit peut tre la
maison, le bureau, la voiture, larrt de bus, les transports en commun. Linformation
apporte doit tre adapte chaque lieu. Par exemple, la maison ou au bureau, des
informations sur la prparation du trajet peuvent tre utiles, alors que dans les
transports en commun, des informations sur les retards ventuels sont ncessaires.
Les diffrents supports dinformation (ordinateurs, tlphones portables, panneaux
messages variables) permettent de disposer dinformations quels que soient le lieu
et lheure. Une autre caractristique de linformation est quelle soit peu coteuse. En
effet, la disposition payer des voyageurs pour cette information est relativement
faible [12].
Dautre part, si clairer le choix modal et faciliter l'usage des rseaux sont
les deux objectifs assigns un systme d'information multimodale, il n'en demeure
pas moins que l'ide principale reste la mise disposition auprs des usagers, et de
manire simple, dinformations oprationnelles [12].
Dans son activit de dplacement les voyageurs rencontrent deux principaux
moments de demande dinformation : au cours de la phase de planification de leurs
voyages et dans la ralisation de ceux-ci.
Avant leurs dplacements, les voyageurs veulent des informations pour prparer
leurs trajets. Des informations permettant de comparer le mme itinraire avec
diffrentes solutions de dplacement sont souhaites. Une demande est galement
exprime pour des informations relatives la ville. Les voyageurs souhaitent en effet
recevoir, paralllement aux informations sur les dplacements, des renseignements
sur les activits touristiques, sur les commerces, sur les services administratifs, etc
[12].
Pendant le trajet, les voyageurs dsirent tre informs sur les conditions de
dplacement (dure, temps dattente) et sur les alternatives existant en cas de
perturbation survenant sur un rseau. En effet, linformation est perue comme
rducteur de tension, et tre inform en permanence du temps dattente est
important pour la plupart des usagers [5].


19

Moment s Cont ex t e
gogr aphi que
Besoi n
i nf or mat i onnel
Type di nf or mat i on
Choix de litinraire
et du mode
associ.
Statique, la demande,
personnalise
Au domicile

Horaire Statique, spontane/
la demande, collective/
personnalise
En chemin vers la
station
Localisation du
point dentre dans
le rseau
Statique, spontane
collective
Localisation des
points de
correspondance

Avant
l e
dpl ac ement

A la station
Heure de darrive
et de dpart du
vhicule, retards,
temps dattente
Statique, spontane
collective
Au bord du vhicule Prochaine station Statique, spontane
collective
Comme A la
station
Nombre des
stations et terminus
Statique, spontane
collective
Nombre de stations Personnalise, statique,
la demande
Au point de
correspondance
Temps estim du
trajet
Personnalise, temps
rel, la demande
Informations
gographiques sur
les alentours de la
station
Personnalise/
collective, temps rel,
spontane/ la
demande

Au c our s
du
dpl ac ement

A larrive
Horaires des
prochains
vhicules
Collective, temps rel,
spontane
Figure 1.4 : Relation entre les besoins des utilisateurs et le type dinformation


20

I I I La c hane de l i nf or mat i on
Lassemblage pertinent de donnes monomodales permet la fabrication dune
information multimodale selon cinq maillons dcrits aux paragraphes suivants [1].
I I I .1 La c ol l ec t e de donnes
Le dbut de la chane repose sur le recueil de donnes de base, de manire
manuelle ou automatique. Ces donnes de terrain sont de deux types:
- les donnes de rfrence qui ont une certaine prennit : Les informations de
rfrence concernent les offres thoriques telles que la cartographie, les tracs de
lignes du transport collectif, les itinraires, les horaires et temps de parcours
thoriques...
- les donnes dynamiques qui offrent une mise jour en direct : Les informations
dynamiques reposent essentiellement sur les horaires et temps de parcours en temps
rel..., mais galement sur les itinraires, loffre de substitution en cas de perturbation
du transport collectif.
I I I .2 Lhomogni sat i on et l i nt gr at i on des donnes
Les donnes sont traites et gres par des systmes de gestion informatiques
et stockes dans des bases de donnes et des systmes dinformations
gographiques.
I I I .3 Ll abor at i on de l i nf or mat i on
Lassemblage des donnes ainsi traites permet la fabrication dune information
transport qui conserve les caractristiques de base : prennit et temps rel.
De base, linformation de dplacement ne concerne quun seul mode de
transport. Par un processus de fusion, les informations monomodales donnent
naissance une information multimodale, reprsentative dune chane de
dplacement multimodal.
I I I .4 La di st r i but i on de l i nf or mat i on
La transmission des informations ainsi obtenues est assure par des mdias
diffrents, via les technologies de tlcommunication, selon le contexte du lieu de
diffusion.
Linformation peut tre passive ou interactive . De type passif, lutilisateur
capte linformation telle quelle est prsente sans possibilit de complments


21

dinformation (support papier, tableau daffichage, PMV...). De type interactif,
lutilisateur peut, de sa propre initiative, sacqurir dinformations personnalises
(Internet, borne interactive, terminal embarqu, mobile GSM, assistant personnel,
tlphone fixe daccs des serveurs vocaux ou des centres dappel, etc.).
I I I .5 Lusage de l i nf or mat i on
Dernier maillon de la chane, ralise par enqute sur le terrain, au cours
dvaluation, ou bien par retour dexprience auprs des usagers et du personnel
dexploitation, lanalyse de lusage de linformation permet damliorer globalement la
qualit de linformation transport. La connaissance des besoins des usagers et les
problmes rencontrs pour accder linformation ne peut quaider affiner son
laboration et son ergonomie.

Figure 1.5 : Les tches principales relies un SIM depuis la collecte jusqu lusage


22

Conc l usi on

ans ce chapitre nous avons prsent ltat de lart sur linformation
multimodale. Nous avons enchan ensuite par la description des attentes
des usagers en matire dinformation sur le transport et du droulement du
cycle de cration de cette information par un systme dinformation multimodale. Ce
cycle de cration montre la richesse potentielle du thme de linformation multimodale
permettant de mettre en avant lensemble des disciplines des sciences sociales et
humaines, ainsi que des sciences pour lingnieur. De manire non exhaustive, et
depuis le recueil jusqu lusage, nous pouvons citer le traitement de linformation, la
gestion de bases de donnes, les tlcommunications, mais galement llectronique
et linformatique omniprsentes tous les stades. Ces points alimenteront la
modlisation qui sera prsente au troisime chapitre. Dans le chapitre suivant, nous
traiterons les systmes dinformation multimodale plus en dtail en nous basant sur
des exemples rels de travaux achevs et dautres en cours dlaboration, vritables
guides dans ce domaine.
D


23

C

h a p i t r e
2
I nt r oduc t i on

information multimodale porte sur les diffrents modes de transport et sur
leurs interconnexions. Elle permet au voyageur d'optimiser son dplacement et
d'amliorer son confort. Un systme dinformation multimodale (SIM) a pour
objet de fournir ce type dinformation, utile et pertinente pour la prparation et
laccomplissement dun dplacement pouvant tre ralis au moyen dun ou plusieurs
modes de transport.
Dans ce chapitre nous allons nous intresser aux systmes dinformation
multimodale en visant particulirement le processus de leur dveloppement et en
exposant quelques exemples raliss sur le niveau international en laissant le
contexte national au chapitre suivant.
I Dvel oppement des SI M
I .1 Rl e dun SI M
Les systmes dinformation multimodale fournissent des informations sur les
itinraires suivre, la dure, les cots ainsi que les priodes et les modes choisir. Ils
constituent une vritable aide au dplacement [12].
A une chelle collective, les SIM ont pour objectif de gnrer une meilleure
utilisation des infrastructures de transport existantes et dclairer les choix des
voyageurs dans le sens dune meilleure efficacit conomique et environnementale du
systme de dplacement.
Laugmentation du nombre de dplacements pour des motifs diversifis rend de
plus en plus utile et ncessaire linformation multimodale. En effet, dans le cas des
dplacements occasionnels, les solutions pour se rendre la nouvelle destination
tant parfois mal connues, les SIM pourraient aider choisir le meilleur itinraire ainsi
L
I I I I . . E ET TU UD DE E C CR RI I T TI I Q QU UE E
D DE ES S S SI I M M E EX XI I S ST TA AN NT TS S


24

que le meilleur moment pour se rendre au lieu voulu. Plus globalement, les SIM
permettraient de mieux planifier et organiser les dplacements [12].
Le dveloppement de linformation multimodale peut galement constituer une
rponse la complexit du chanage des dplacements. En effet, un systme
dinformation multimodale performant pourrait faciliter ces chanages en identifiant les
possibilits de transport rpondant un programme dactivits planifi selon des
horaires prcis [6].
En raison du plus grand nombre de possibilits quils proposent, les SIM
semblent tre adquats pour apporter une marge de manoeuvre supplmentaire dans
la gestion des dplacements par rapport aux systmes dinformation monomodale
[12].

Figure 2.1 : Les SIM, outils de gestion des dplacements


25

I .2 Or i ent at i ons t ec hni ques et f onc t i onnel l es des SI M
La distribution de linformation sappuie sur les diffrents mdias de
communication que sont les terminaux embarqus, les panneaux d'information, les
bornes interactives, les serveurs Minitel ou Internet, la radio (Radio Data System
(RDS) pour la transmission de donnes par radio), le tlphone portable (messages
SMS, WAP), la messagerie lectronique, la tlvision [8].
Au fur et mesure de leur dveloppement, les SIM sorientent de plus en plus
vers la mobilit individuelle de chaque voyageur (planification du dplacement, alerte
pendant le voyage, guidage) en fournissant des informations neutres sur lensemble
des modes, ainsi que dautres services spcialiss (htel, restaurant, muse,
commerce...). La personnalisation de linformation permet la transmission des seules
informations qui sont utiles en fonction du lieu et du moment [8].

Figure 2.2 : Technologies utilises pour la distribution de linformation
I .3 Dvel oppement des ser vi c es
Le dveloppement des services auprs de la clientle est vraisemblablement
un facteur important pour la fidlisation, voire pour la conqute de nouveaux usagers
des transports collectifs. Dans la relation entre le client et le transporteur, cest un lien
que lexploitant souhaite voir se dvelopper de manire forte et durable. Cependant, il
faut assurer une certaine continuit des services depuis la sphre prive vers lespace
collectif. Mais cependant, il convient de savoir galement se diffrencier de
lautomobile, en offrant des services doccupation du temps de voyage que seuls les


26

transports collectifs peuvent offrir. Lanimation des ples dchanges par loffre de
bouquets de service ou de commerces fait galement partie des services
dvelopper. Et de manire plus prospective, les services annexes au transport,
comme le tourisme, la culture, les loisirs. devraient tre mieux pris en compte dans
loffre de transport, et cest srement lenjeu des systmes dinformation sur les
transports dvelopper [1] [7].
I .3 Di f f i c ul t s r enc ont r es
Si certains lments tels que la demande croissante dinformation manant des
voyageurs, le dveloppement de technologies de communication de plus en plus
performantes, la prsence dacteurs moteurs (certains oprateurs, des socits de
tlphonie) semblent autant datouts lessor rapide de systmes dinformation
multimodale, des freins importants au dveloppement des SIM perdurent nanmoins.
Ces freins sont notamment dordre conomique, organisationnel et institutionnel [12].
Tout dabord, un grand nombre de questions dordre conomique reste en
suspens. Rassembler et fournir de linformation multimodale a un cot. Qui doit payer?
Linformation multimodale doit-elle tre prise en charge par les collectivits locales ?
Une entreprise ninvestira dans ce domaine que si elle y trouve une rentabilit
conomique (quilibre financier, gain de clientle, dimage). La collectivit publique
peut dcider dinvestir si elle y trouve une rentabilit sociale.
Par ailleurs, un certain nombre de blocages linformation multimodale semble
relever de la concurrence entre les oprateurs : le dveloppement de linformation
multimodale suppose une bonne coopration entre des acteurs peu habitus
travailler ensemble (transports publics locaux, transports privs), voire concurrents.
Ainsi les questions organisationnelles peuvent constituer un frein puissant. Une faon
possible de rsoudre cette difficult est davoir recours un tiers auquel la gestion de
linformation multimodale serait confie. Les diffrents exploitants auraient alors
obligation de fournir les informations ce tiers.
Ainsi la cration souhaitable de SIM performants est techniquement
envisageable dans un proche futur, condition, toutefois, quun certain nombre de
freins dordre organisationnel, juridique et conomique soient levs [12].


27

I I Ex pr i enc es
Linformation multimodale et les systmes qui la fournissent sont troitement
lis lorganisation des transports et de linformation au voyageur des pays o ils sont
dvelopps. Internet et dans quelques pays la tlphonie mobile et les centrales
tlphoniques sont les mdias frquemment utiliss pour la diffusion de ce type
dinformation. Il existe en effets plusieurs expriences de part et dautre du monde.

I I .1 Le c ont ex t e angl ai s
I I .1.1 Tr anspor t f or London (Tf L)
La socit TfL propose plusieurs fonctionnalits [9]. Parmi ces fonctionnalits
figure un plan interactif bas sur le mtro de Londres. En cliquant sur les stations les
plus importantes, il est possible dobtenir pour chacun de ces points les informations
suivantes :
les horaires et les plans des bus en correspondance la station,
quand les services existent, les horaires des trains et autocars en correspondance
ou proximit du point daccs,
- les conditions daccs et un plan de la station.
Les autres fonctionnalits sont essentiellement la possibilit de planifier un
voyage dun point de dpart vers une destination, de consulter les informations sur les
incidents de voyages, le trafic et les alertes et ceci en utilisant une multitude de
mdias. En effet, ces services sont accessibles dune part via Internet pour les
ordinateurs (http://www.tfl.gov.uk/) et pour les PDA (Personal Device Assistant) sur
http://pda.tfl.gov.uk/ et dautre part par les tlphones mobiles via SMS
(http://mobile.tfl.gov.uk/) ou, via le protocole WAP (Wireless Application Protocol) sur
http://wap.tfl.gov.uk/. Enfin, TfL utilise les bornes interactives pour fournir le service de
planification de voyage (http://iplus.jp.tflwap.gov.uk/).


28


Service de planification de voyage via WAP

Service de planification de voyage via SMS ( numro 60835)

Service de planification de voyage accessible par PDA

Service de planification de voyage accessible sur borne interactive
Figure 2.3 : Quelques moyens daccs aux services de TfL


29

I I .2 Le c ont ex t e f r an ai s
I I .2.1 COPI LOT
En rgion Ile de France, le projet COPILOT (STIF/RATP/SNCF) prvoit une
information en temps rel pour les voitures prives et le transport collectif la fois
gnrale sur Internet (http://www.ratp.com) et personnalise par lenvoi de messages
lectroniques ou par le service SMS [4].
Mais ce projet propose une aide juste la prparation dun dplacement avec
labsence de suivi de dplacement, absence de linformation temps rel et absence de
loptimisation multicritre.
Parmi les fonctions quassure ce systme :
- Rpondre un besoin dinformation global du client qui dpasse les limites
administratives habituelles
- Donner une information temps rel sur les perturbations
- Apporter une aide au dplacement qui est multimodale.
I I .2.2 Df i ni t i on des ser vi c es
Une recherche finance en 99 par le PREDIT (Programme de Recherche Et
DInnovation dans les Transports terrestres, http://www.predit.prd.fr/) groupe
thmatique nouveaux services aux usagers vise dfinir et hirarchiser les attentes
des usagers en matire d'information sur les rseaux et les services de transport en
milieu urbain [3]. Plus prcisment, ce projet cherche dfinir les proprits de
l'assistance informationnelle ncessaires mettre en oeuvre pour donner ou redonner
l'usager une matrise sur le contexte de son dplacement, et le conduire vers la
solution la plus pertinente en fonction des situations. Au sein du programme franais
PREDIT a t cr la Plate-forme de Recherche et d'Exprimentation pour le
Dveloppement de l'Information Multimodale( PREDIM, http://www.predim.org/). Cette
recherche a conduit des spcifications d'un systme d'information multimodale,
construites partir d'une mise en relation des activits des individus et de leurs
pratiques de dplacement, des situations dans lesquelles la demande d'information
s'exprime, ainsi que des supports de l'information.


30

I I .2.3 Ar c hi t ec t ur es et st andar ds pour l es t r anspor t s c ol l ec t i f s
Le projet SITP (Systmes dInformation pour les Transports Publics) a t
financ par le PREDIT (groupe nouveaux services aux usagers ) en 99 pour une
dure de deux ans [4]. Lobjectif est de dvelopper un modle de donnes puis des
spcifications gnriques qui facilite lintgration des systmes dinformation de
transport public, en particulier pour trois domaines dapplication (billettique, tableaux
de bord, et information multimodale, y compris son lien avec linformation trafic). Ces
spcifications ont pour rle de permettre aux exploitants de construire leur
informatique partir de composants non propritaires et qui puisse interoprer avec
des systmes informatiques dautres exploitants, de manire construire des
applications intgres.
Une dmarche trs similaire a t entreprise aux tats-Unis, sous le nom de
TCIP [7].
I I .3 Le c ont ex t e al l emand
I I .3.1 DELFI
DELFI utilise les technologies de communication d'Internet. Son principe est de
mettre en relation diffrents serveurs locaux d'information tels que le serveur de
Stuttgart (http://www.efa-bw.de/), au travers d'interfaces spcialises, et de permettre
ainsi une recherche d'itinraires partir d'arrts distribus sur ces diffrents sites [10].
Chaque serveur comprend :
- Une base d'information commune : ou mta-base, o sont centralises un
petit nombre d'informations telles que des tables de transformations et de traductions.
Celle-ci sont mises jour de faon centrale, et sont ensuite copies sur les diffrents
systmes locaux. Elles jouent le rle de dictionnaire de traduction des diffrents
formats utiliss par les systmes qui composent DELFI. A ces tables de
transformation s'ajoute une table de responsabilits qui permet aux sites qui
composent DELFI de savoir, suivant les cas, quel est le serveur responsable de la
recherche.
- Un noyau local modifi destin raliser les calculs d'itinraires locaux.
- Un module d'identification des origines-destinations, lui aussi modifi dans
bien des cas pour prendre en compte les nouvelles fonctions de recherche.


31

-Un super mcanisme ou composeur principal qui permet les traitements
rpartis.
Le fonctionnement de DELFI est subordonn deux types de traitements :
- Des traitements en temps diffr, qui correspondent la mise jour ou la
modification des donnes communes l'ensemble du systme.
- Des traitements en temps rel, qui correspondent aux actions ralises par le
serveur quand un utilisateur effectue une requte.
I I .4 Le c ont ex t e hol l andai s : RDS-TMC
Les Pays-Bas ont mis en place depuis mars 98 un service dinformation trafic
national sur RDS/TMC(Radio Data System - Traffic Message Chanel) : systme
permettant partir d'un terminal portable ou intgr, de connatre en permanence
l'itinraire le plus fluide et la dure de son trajet. Il permet de transmettre des
informations codes dans le signal pour afficher des messages sur la circulation
routire. Le centre dinformation national (partenariat transports / police) envoie
automatiquement ses informations (saisies manuellement ou recueillies
automatiquement) loprateur (via Datex), qui le traduit en message Alert, puis le
diffuse sur RDS. Le protocole Datex a t dvelopp dans un cadre europen afin de
rpondre aux besoins dchanges dinformation trafic [7].
I I .5 Le c ont ex t e des Et at s-Uni s, du Canada et du J apon
I I .5.1 Dvel oppement des Syst mes de Tr anspor t I nt el l i gent s (STI )
Ces trois pays sont les pionniers en matire de dveloppement des systmes
de transport intelligents [14]. Ces systmes englobent lapplication intgre de
technologies volues de traitement de linformation, de communication, de captage
et de contrle ainsi que des stratgies de gestion afin damliorer le fonctionnement
du rseau des transports. Ces systmes fournissent des donnes de voyage
permettant daccrotre la scurit et lefficacit du rseau des transports terrestres
pour les passagers et les marchandises dans les zones urbaines et rurales. Les STI
fournissent galement de prcieuses donnes en temps rel aux exploitants de
rseau tels que les socits de transport en commun, les parcs de vhicules
commerciaux et les services routiers durgence et de scurit. Ces applications
runissent les usagers, les vhicules et linfrastructure en un systme intgr qui


32

permet lchange dinformation ncessaire une meilleure gestion et une meilleure
utilisation des ressources. Pour rpondre aux nombreux besoins des usagers, parmi
lesquels figure linformation multimodale sur le voyage, les STI offrent des fonctions
de navigation, dinformation sur le voyage et de surveillance aux usagers du rseau.
I I .5.2 Comi t ATI S
Un comit ATIS (Advanced Traveler Information Systems) a t cr dans le
cadre de linitiative fdrale amricaine pour les systmes de transport intelligents [7].
Les domaines couverts sont les suivants : systmes de navigation et cartographie
lectronique, information sur le trafic en temps rel, alerte rapide en cas durgence,
information de transport collectif et multimodale.
I I .5.3 Tour i sme et voyages
Les services dinformation pour le tourisme et les voyages sont les plus
dvelopps. Mme Microsoft a dvelopp un service (http://www.expedia.com). Des
services dinformation en matire daide au dplacement et de tourisme sont
nombreux et gnralement spcifiques une rgion particulire ou un tat
particulier.
I I I Pr oj et s en c our s de r al i sat i on
I I I .1 Tr anspor t Di r ec t
Transport Direct a pour objectif la mise en place dun systme dinformation
multimodale tendu lensemble du Royaume-Uni et accessible, dans un premier
temps, via Internet. Programme ambitieux, Transport Direct a t annonc en juillet
2000 et devrait se drouler sur une priode de 5 6 ans [9].
Techniquement, le systme sappuie sur un protocole et deux bases de
donnes alimentes par les acteurs locaux :
- JourneyWeb dcrit comment les calculateurs rgionaux communiquent entre eux ;
- NPTG est la base nationale des villes et noms de lieux du Royaume-Uni
- NaPTAN est le rpertoire national go-rfrenc des arrts ou accs aux transports
publics.
Loffre informationnelle de Transport Direct se rsume aux points suivants :


33

- Itinraires dextrmits de parcours et de correspondance : Transport Direct
doit prendre en compte linformation sur les itinraires daccs ou de sortie du rseau
ainsi que sur les itinraires de correspondances.
- Intgration de linformation routire (Voiture Prive) : Transport Direct devrait
permettre les comparaisons entre voiture particulire et transport collectif sur un
itinraire choisi.
- Vente des billets et acceptation du paiement de linformation
- Information en temps rel pour les bus et les trains
- Diffusion TPEG : TPEG est un protocole dvelopp dans le cadre dun projet
europen pilot par lEBU (European Broadcasting Union) et soumis la
normalisation. Il est destin faciliter la diffusion dinformation vers les nouveaux
rcepteurs de radio numrique ou DAB (Digital Audio Broadcasting : un systme de
radiodiffusion numrique qui remplacerait la bande FM. Ses possibilits multimdia
permettront, contrairement la radiodiffusion classique, de transmettre la fois des
sons, des textes, des images et des squences vido, ce qui en fait un systme de
radiodiffusion de donnes). TPEG est le successeur du TMC, qui utilise le canal RDS
en sous-porteuse FM.
TPEG se distingue par les caractristiques suivantes :
le standard est spcifiquement conu pour la diffusion dinformation par les radio
diffuseurs. Toutefois, il existe une version XML pour la diffusion sur le web;
il est surtout prvu pour diffuser de linformation routire, les rcepteurs DAB devant
principalement quiper les vhicules automobiles. Toutefois, il peut aussi diffuser de
linformation sur les transports collectifs;
la diffusion est mono directionnelle, sans filtrage de ce qui est envoy (le filtrage est
fait par lquipement de rception) ;
les messages TPEG intgrent linformation sur le destinataire et sur le moment o le
message doit tre diffus ;
cause de la (relativement) faible bande passante quil utilise, le systme est surtout
conu pour la diffusion de messages structurs et sapplique moins bien la diffusion
de donnes en vrac ;
TPEG est cod de faon pouvoir tre interprt dans la langue de lutilisateur final.


34

Dune manire gnrale, les principaux moyens par lesquels les usagers
pourraient recevoir de linformation sur les transports collectifs en utilisant TPEG sont:
les systmes embarqus bord des voitures prives ou des bus (par exemple
information bord des vhicules sur les dparts en station) ;
les systmes dinformation dynamique aux arrts o les informations encodes au
format TPEG seraient envoyes via un rseau radio priv ou public.
- Portail Internet : Dernire brique du projet, le portail Internet est destin
mettre disposition du public les informations de Transport Direct et offrir les
services de :
planification du dplacement.
rservation et paiement du voyage slectionn ;
information, avant le dpart, sur les conditions de fonctionnement du voyage
slectionn.
Ce portail est dj fonctionnel depuis le dbut de lanne 2005. Cest un
exemple trs russit en matire de dplacement multimodal et il est accessible sur le
web (http//www.transportdirect.com).


35

Conc l usi on

tat de lart des systmes dinformation multimodale montre plus une
superposition de systmes monomodaux dinformation que lexistence de
vritables systmes dinformation multimodaux lexception de quelques
projets comme Transport Direct qui promet dtre performant. De ltude prcdente,
nous pouvons affirmer que de grands travaux restent faire pour amliorer les
systmes existants et crer de nouveaux systmes plus performants. En portant des
critiques sur les systmes prcdemment cits, il est pertinent que larchitecture
technique diffre (par exemple entre DELFI et le TPEG) alors que les fonctionnalits
sont presque les mmes (aide au dplacement multimodal, information sur le trafic).
Un autre point important est que lexprience des systmes dinformation multimodale
ne sest pas faite grande chelle mais se sont quelques pays qui dtiennent ce
monopole .
L
Dans le chapitre suivant, nous allons prsenter la spcification savoir ltude
de lexistant, lexpression des besoins fonctionnels et techniques de notre systme
SIMT en nous basons sur ltude fonctionnelle des systmes dinformation
multimodale prsente au premier chapitre et sur les exemples dcrits dans ce
chapitres.


36


I nt r oduc t i on

our garantir la meilleure spcification pour un projet de dveloppement
dun systme dinformation multimodale (SIM) une tude approfondie des
attentes des utilisateurs dun tel type de systme -qui sont gnralement les
usagers des transports collectifs- est primordiale. Ceci permettra au
concepteur de bien comprendre les besoins rels afin de raliser la meilleure
conception du projet. Nous nous baserons dans llaboration de la spcification sur
les rsultats introduits au premier chapitre et qui concernent lnumration des
attentes des usagers et la description de la chane dinformation sur les transports.
Dans ce chapitre, commenons par une description de lexistant afin de ressentir les
limites de fonctionnement des systmes nationaux existants et en dfinissant dans un
deuxime temps les objectifs de notre projet. Nous enchanons ensuite par la
spcification des besoins.
I Et ude de Lex i st ant : l e c ont ex t e nat i onal
Le contexte tunisien est caractris par la prsence de la socit de transport
de Tunis ne de la fusion de la socit nationale de transport, SNT (1963) et de la
socit du mtro lger de Tunis, SMLT (1981). Elle assure le transport des voyageurs,
dans Tunis et banlieue. Elle transporte environ 460 millions de voyageurs par an. Ces
rseaux bus et ferr stendent, respectivement, sur 5.836 Km et 82 Km. La socit
Nationale des Chemins de Fer Tunisiens (SNCFT) jouit aussi dune activit importante
avec environ 36.5 millions de voyageurs par ans et des chemins de fer qui stendent
sur 2256 km. Douze socits rgionales ainsi quune socit de transport interurbain
anime le contexte national. Le transport arien est assur principalement par la
socit tunisienne de lair (TUNISAIR) et TUNINTER pour les vols internes. Par
C h a p i t r e
3
SYSTEME DI NFORMATI ON
TUNI SI EN SI MT
I I I . SPECI FI CATI ON DUN
P


37

ailleurs, Le transport maritime, est assur par la Compagnie Tunisienne de Navigation
(CTN).
Linformation multimodale nest pas actuellement la priorit des oprateurs
publics et privs de transport. Leur priorit affirme est damliorer linformation
monomodale existante. Cette amlioration passe par le dveloppement de
linformation en temps rel. Linformation en temps rel et celle sur le trafic, lheure
actuelle est presque inexistante. Le dveloppement de linformation sur les transports
en commun connat une volution. En effets, les exploitants de transports en commun
(comme la STT par exemple) commence dvelopper de linformation monomodale;
cette dernire tant monomodale dans la mesure o elle intgre dans la plus part des
cas les informations dun seul rseau de transport urbain. La figure 3.1 prsente le
service informationnel que propose la STT sur son rseau de transport collectif. Ce
service comprend la recherche des lignes de bus pour atteindre une destination, la
fourniture dinformations sur une ligne particulire et lnumration des lignes dune
station donne.

Figure 3.1 : Le site web de la STT (http://www.snt.com.tn)


38

I I Les obj ec t i f s du pr oj et
Les objectifs du prsent projet peuvent tre rsums comme suit :
La conception dun systme dinformation multimodale pour les usagers du
transport collectif englobant les phases de :
o Collecte des donnes.
o Homognisation et intgration des donnes.
o Elaboration de linformation aux usagers.
o Distribution de linformation aux utilisateurs.
La ralisation dun systme daide au dplacement multimodal dans la rgion
du grand Tunis.
o Cration dun format propre au dplacement en transport collectif.
o Limplmentation et loptimisation de quelques algorithmes de calcul
ditinraire multimodal.
La distribution de linformation via des technologies de communication
accessibles grande chelle et faible cot.
I I I La spc i f i c at i on des besoi ns
Pour russir la meilleure spcification des besoins ces derniers doivent tre
modliss. Un modle facilite la comprhension du problme et la communication
entre les diffrents acteurs impliqus dans un projet. La modlisation permet de mieux
apprhender les besoins, elle amliore la lisibilit des schmas de conception et
facilite la maintenance des systmes.
I I I .1 La not at i on : UML
UML (Unified Modeling Language : "langage de modlisation objet unifi") est
n de la fusion des trois mthodes qui ont le plus influenc la modlisation objet au
milieu des annes 90 : OMT, Booch et OOSE. Issu "du terrain" et fruit d'un travail
d'experts reconnus, UML est le rsultat d'un large consensus. De trs nombreux
acteurs industriels de renom ont adopt UML et participent son dveloppement [16].
La modlisation UML permet de :


39

Anal yser l es c as dut i l i sat i on
Une rflexion sur les fonctionnalits attendues du futur systme est ncessaire
avant sa conception. Les divers cas dutilisation de ce systme vont tre prsents
dans les diagrammes de cas dutilisation.
I dent i f i er l es obj et s
Les objets ayant une structure semblable, le mme comportement et les mmes
types de relations avec dautres objets sont runis dans une classe. Le diagramme de
classes permet didentifier les objets mis en jeu lintrieur du systme.
Dc r i r e l es c ompor t ement s
Les diagrammes dtats permettent de dfinir le comportement dun objet
particulier vis--vis des sollicitations internes ou externes auxquelles il peut tre
soumis.
Repr sent er l es i nt er ac t i ons
Le dialogue qui sinstaure entre les diffrents objets concerns par lvnement
pour y rpondre peut tre reprsent dans un diagramme de collaboration entre
objets. Ce diagramme insiste sur les changes qui ont lieu entre les objets. Le
diagramme de squence prsente ces mmes changes en mettant en vidence leur
chronologie.
Df i ni r l es paquet ages
Une fois les objets identifis, il est ais de rpartir les classes qui les implmentent
entre les diffrents paquetages. Les regroupements de ces classes effectus dans le
diagramme de paquetages sont faits de manire minimiser les changes entre les
diffrents paquetages.
Spc i f i er l a mi se en uvr e
La mise en uvre des objets dans un environnement de travail concret peut tre
spcifie avec les diagrammes de composants et les diagrammes de dploiement
I I I .2 Les pr oc essus uni f i s
Un processus unifi est un processus de dveloppement logiciel construit sur
UML, il est itratif centr sur larchitecture, conduit par les cas dutilisation et pilot par


40

les risques. Sa gestion est organise suivant les quatres phases suivantes : pr-
tude, laboration, construction et transition [16].
I I I .3 Le pr oc essus de dvel oppement : 2TUP
Un projet de dveloppements men avec succs satisfait les attentes des clients,
voir les dpasse. Pour cela nous avons choisit de suivre le processus 2TUP (2 Track
Unified Process) qui propose un cycle de dveloppement en Y dissociant les aspects
techniques des aspects fonctionnels [17].
Le processus en Y sarticule autour de 3 branches :
Une branche fonctionnelle : La capture et lanalyse des besoins fonctionnels.
Une branche technique : La capture et lanalyse des besoins techniques.
Une branche de ralisation : La conception dtaille, le codage et les testes.
Plus de dtails sur les processus unifis et le processus 2TUP en Annexe A.
I I I .4 Spc i f i c at i on des besoi ns f onc t i onnel s
I I I .4.1 Modl i sat i on des besoi ns
I I I I I I . . 4 4. . 1 1. . 1 1 I I d de en nt t i i f f i i c c a at t i i o on n d de es s a ac c t t e eu ur r s s
Un acteur reprsente un rle jou par une personne, un groupe de personnes ou
par un composant logiciel (un autre systme) ou matriel qui interagit avec le
systme. Il est parfois difficile de dterminer la limite du systme. Par dfinition, les
acteurs sont lextrieur du systme. Les acteurs se recrutent parmi les utilisateurs
du systme et aussi parmi les responsables de sa configuration et de sa maintenance.
Dans notre cas nous avons trois acteurs principaux qui sont :
LE FOURNI SSEUR DE DONNEES : Cest un acteur gnrique qui
reprsente diffrentes entits :
o Le fournisseur de donnes sur le transport :
Cest lentit humaine responsable des aspects d'exploitation des systmes de
transport de passagers. Elle surveille, contrle et modifie activement et
quotidiennement les itinraires et les horaires des vhicules de transport collectif.
o Le fournisseur de donnes sur les services annexes


41

Cette entit fournit des informations sur les services supplmentaires que peut
ncessiter le voyageur pour planifier son voyage ou qui peuvent lintresser lors de
son dplacement. Ces services se diversifient englobant des aspects culturels
(muses, thtres ), des services de sant (hpitaux, urgences, mdecins), des
loisirs (parcs dattractions, parcours sanitaires) des aspects commerciaux (grandes
surfaces, magasins) et plusieurs autres domaines.
o Le fournisseur de donnes sur le trafic
Cest une entit humaine qui fournit les donnes sur le trafic, les incidents, les
accidents Ces informations peuvent provenir de diffrentes sources (responsable de
la gestion du trafic, conducteurs de transport en commun, urgences, police,
voyageurs)
o Le fournisseur de donnes mtorologiques et environnementales
Il reprsente les fournisseurs de services mtorologiques spcialiss. Ces
entits fournissent des prvisions mtorologiques, des informations sur les
conditions routires ainsi que des avertissements de temps dangereux comme les
orages, les inondations et les vnements climatiques afin davoir des prvisions
dtailles et spcialises au sujet de la mto, des tempratures et des conditions
des routes.
LUTI LI SATEUR : Il reprsente toute personne qui utilise linformation sur le
transport avant le dplacement. Il peut tre un simple usagers en prparation pour un
voyage ou tout autre type dutilisateurs comme les agences de voyages, le personnel
de conduite, dexploitation, les autres fournisseurs de service dinformation entrant
dans le cadre du partage coopratif dinformations entre fournisseurs
LE PASSAGER : Ou le voyageur bord du vhicule, il reprsente un
utilisateur avant le dplacement qui est devenu un passager du transport collectif.
Cette entit dpend troitement du vhicule sur lequel elle est prsente et qui lui
fournit linformation durant le dplacement.
LADMI NI STRATEUR : Cest le responsable de la gestion de tout le
systme, il soccupe de la gestion de la collecte manuelle des donnes, de leur
homognisation et intgration, de llaboration de linformation et de sa distribution.


42

I I I I I I . . 4 4. . 1 1. . 2 2 I I d de en nt t i i f f i i c c a at t i i o on n d de es s c c a as s d d u ut t i i l l i i s sa at t i i o on n
Un cas dutilisation est une abstraction dune partie du comportement du systme
par une instance dun acteur. Dans la spcification du systme cible on prvoit sa
rpartition en deux sous-systmes : un pour la gestion des informations collectes,
lautre pour grer laccs aux informations.
Pour chaque sous-systme en prvoit plusieurs cas dutilisation savoir :
Sous-systme Cas dutilisation
Grer la collecte des donnes.
Traiter les donnes collectes.
Gestion des
informations collectes
<<subsystem>>

Elaborer linformation sur le transport.
Grer la base de donnes.
Effectuer les mises jour pour les vhicules
de transport.
Fourni sseur de
donnes sur l e transport
Fourni sseur de
donnes sur l e trafi c Fournisseur de
donnes annexes
Homogniser l es donnes
coll ectes
Intgrer les donnes formates
S'authentifier
Fourni sseur de donnes sur la
mto et l'envi ronnement
Gnrer l es donnes envoyer
Fournisseur
Traiter les donnes coll ectes
<>
<>
Effectuer les mises j our pour les
vhicul es de transport
<>
<>
Grer la base de donnes
Grer la coll ecte des donnes
<<extend>>
<>
El aborer l 'i nformation sur le
transport
Admini strateur
<<extend>>
<<extend>>
<<extend>>

Figure 3.2 : Cas dutilisation du sous-systme de gestion des informations collectes


43

Sous-systme Cas dutilisation

Planifier un voyage.
Gestion d'accs aux
informations
<<subsystem>>

Accder aux informations gnrales.
Accder aux informations localises.
Accder aux offres et annonces du
fournisseur de service dinformation
(FSI).
Evaluer le service.
Valider l'accs
Choisir la plage horaire Grer les prf rences d'une
possibilit
Accder aux av is et alertes
Garder une trace du plan
Choisir le mode de transport
Localisation
Accder aux inf ormations localis
es
<<include>>
Passager
Voy ageur en pr
paration
Organisateur de v oy age
Autre FSI sur le transport
Choisir le trajet
Grer les paramtres du v oy age
<<include>>
<<include>>
<<extend>>
Administrateur
Planif ier un v oyage
<<extend>>
<<include>>
<<extend>>
<<include>>
Accder aux inf os gnrales
<<include>>
<<include>>
Accder aux of f res et annonces du
FSI
Ev aluer le serv ice
<<extend>>
Utilisateur
<<extend>>
Figure 3.3 : Cas dutilisation du sous-systmes de gestion daccs aux informations


44

I I I I I I . . 4 4. . 1 1. . 3 3 D De es sc c r r i i p pt t i i o on n d de es s c c a as s d d u ut t i i l l i i s sa at t i i o on n
Aprs lidentification des diffrents cas dutilisation, nous procdons leurs
descriptions afin de mieux cerner les interactions entre le systme et ses acteurs.
Nous avons choisit de varier la description entre textuelle et par diagrammes de
squence systme et ninclure que les cas dutilisation les plus essentiels.
Sous-syst me de gest i on des i nf or mat i ons c ol l ec t es :
Cas dutilisation :
Gr er l a c ol l ec t e des donnes
But :
Collecter les donnes issues des diffrents fournisseurs de donnes.
Acteur :
Ladministrateur (principal) et lacteur gnrique fournisseur de
donnes (secondaire)
Prconditions :
Aut hent i f i c at i on
Scnarii :
1. Dposer l es donnes
Acteur Systme
1. Le fournisseur ou ladministrateur
demande la fonctionnalit de dposer les
donnes.
2. Le systme demande de spcifier les
donnes dposer.
3. Le fournisseur indique lemplacement des
donnes.
4. Le systme les rcupre.
5. Le systme les stocke avec lidentifiant de
leur source.
6. Le systme acquitte lopration.
7. Le systme gnre un rapport sur
lopration.
2. I mpor t er l es donnes
Acteur Systme
1. Ladministrateur lance la fonctionnalit
dimport de donnes.
2. Le systme demande le mcanisme
dimport activer.
3. Ladministrateur spcifie le mcanisme. 4. Le systme demande do importer.


45

5. Ladministrateur dtermine lemplacement. 6. Le systme lance lopration dimport.
7. Le systme les stocke avec ldentifiant de
leur source.
9. Le systme gnre un rapport.

Cas dutilisation :
Tr ai t er l es donnes c ol l ec t es
But :
Traiter les donnes collectes en les homognisant puis en les intgrant
aux anciennes donnes.
Acteur :
Ladministrateur
Scnarii :
1. Tr ai t ement des donnes c ol l ec t es
Acteur Systme
1. Ladministrateur lance le traitement des
donnes collectes.
2. Le systme demande le type
dhomognisation.
3. Ladministrateur spcifie le type
dhomognisation.
4. Le systme demande la confirmation du
dbut de lhomognisation.
5. Ladministrateur confirme le dbut de
lopration dhomognisation.
6. Le systme lance lopration
dhomognisation (Un sous-cas dutilisation).
7. Le systme demande la confirmation du
dbut dintgration des donnes.
8. Ladministrateur confirme le dbut de
lopration dintgration.
9. Le systme lance lopration dintgration
(Un sous-cas dutilisation).
10. Le systme acquitte le traitement des
donnes.

Cas dutilisation :
Homogni ser l es donnes
But :
Gnrer des donnes selon un format bien dtermin.
Acteur :
Ladministrateur
Scnarii :


46

1. Homogni sat i on manuel l e des donnes
Acteur Systme
dhomognisation manuelle.
2. Le systme demande la nature des
donnes traiter.
3. Ladministrateur spcifie la nature. 4. Le systme donne la main pour introduire
les donnes selon un certain format.
5. Ladministrateur introduit les donnes. 6. Le systme demande le format de sortie
la fin de lhomognisation.

7. Ladministrateur le format de sortie la fin
de lhomognisation.
8. Le systme gnre des donnes
formates.
9. Le systme les stocke selon leur nature.
2. Homogni sat i on aut omat i que des donnes
Acteur Systme
dhomognisation manuelle.
2. Le systme demande le format des
donnes traiter.
3. Ladministrateur spcifie le format. 4. Le systme demande le format de sortie
5. Ladministrateur spcifie le format de sortie
6. Le systme gnre des donnes
formates.
7. Le systme les stocke selon leur nature.

Cas dutilisation :
I nt gr er l es donnes
But :
Intgrer les donnes formates avec celles ncessaires pour modliser
les rseaux de transport.
Acteur :
Ladministrateur
Scnarii :


47

1. I nt gr at i on des donnes f or mat es.
Acteur Systme
dintgration des donnes.
2. Le systme demande la nature des
donnes.
3. Ladministrateur spcifie leur nature. 4. Le systme demande lemplacement des
donnes.
5. Ladministrateur spcifie leur
emplacement.
6. Le systme demande la confirmation de
lopration dintgration et la dtermination
dautres oprations possibles.
7. Ladministrateur confirme lopration. 8. Le systme intgre les donnes dans la
structure approprie.

Cas dutilisation :
l abor at i on de l i nf or mat i on sur l e t r anspor t
But :
A partir de la structure o sont stockes les donnes sur tous les rseaux
de transport crer un graphe sur lequel seffectueront les calculs
paramtrs ditinraires.
Acteur :
Ladministrateur
Scnarii :
1. l abor at i on de l i nf or mat i on
Acteur Systme
dlaboration de linformation.
2. Le systme demande lemplacement des
donnes.
3. Ladministrateur spcifie leur
emplacement.
4. Le systme demande le paramtrage
adquat la cration du graphe.
5. Ladministrateur spcifie les paramtres
ncessaires la cration du graphe.
6. Le systme demande le paramtrage
adquat lutilisation pour les calculs
ditinraires.
7. Ladministrateur spcifie les paramtres
ncessaires lutilisation et aux calculs
8. Le systme enregistre les paramtres
introduits.


48

ditinraires. 9. Le systme confirme lopration pour
effectuer les calculs ditinraires la
demande.
Sous-syst me de gest i on dac c s aux i nf or mat i ons :
Cas dutilisation :
Pl ani f i er un voyage
A partir des diffrents paramtres introduits comme les adresses dpart-
arrive, la plage horaire et certaines prfrences de lutilisateur, le
systme planifie un voyage et rend compte du rsultat au usager. Il lui
donne aussi la possibilit de trier ou de dtailler certaines solutions.
But :
Lutilisateur
Acteur :
Scnarii :
1. Pl ani f i er un voyage 2. Dt ai l l er une possi bi l i t

as dutilisation :
Ac c der aux i nf or mat i ons gnr al es
Lutilisateur aura la possibilit daccder aux horaires des lignes des
diffrents rseaux, la description de leurs itinraires ainsi quaux
informations environnementales, mtorologiques et sur le trafic.
But :
Lutilisateur
Acteur :
Scnarii :


49

1. Af f i c her des i nf os sur l es l i gnes 2. Af f i c her l es aut r es t ypes di nf os

Cas dutilisation :
Ac c der aux i nf or mat i ons l oc al i ses
But :
Permettre lutilisateur daccder aux informations localises. Ce sont
des informations obtenues suite une premire tape de localisation
effectue manuellement par lutilisateur par choix de position ou
automatiquement comme par rcepteur GPS. La deuxime tape
consiste dfinir le type dinformation recevoir.
Acteur :
Lutilisateur
Scnarii :
1. Af f i c her des i nf or mat i ons l oc al i ses


50

I I I .5 Spc i f i c at i on des besoi ns t ec hni ques
I I I .5.1 Capt ur e des besoi ns
Les besoins techniques dcrivent toutes les contraintes aux quelles est soumis
le systme pour sa ralisation et son bon fonctionnement.
Besoi n de di sponi bi l i t et de f i abi l i t :
Le systme devra tre oprationnel dune faon continue, sauf pendant la phase de
maintenance du systme par ladministrateur.
Besoi n de per f or manc e :
Le systme devra tre rapide notamment au niveau de dtection des alertes et lenvoi
des messages.
Besoi n de por t abi l i t et de modul ar i t :
Le systme devra tre multi plate-forme et modulaire pour garantir la souplesse et
lvolutivit de la solution.
I I I I I I . . 5 5. . 2 2 Cont r ai nt es et c hoi x t ec hni ques
Dans cette partie nous exposons en premier lieu le choix technologique pour la
cration du format adopt pour contenir linformation sur les transports. En deuxime
lieu, nous exposons les technologies les plus rpondues qui permettent denvoyer un
SMS partir dun PC pour dcider la solution adopter.
I I I I I I . . 5 5. . 2 2. . 1 1 U Ut t i i l l i i s s a at t i i o on n d de e X XM ML L p po ou ur r d d c c r r i i r r e e l l i i n nf f o or r m ma at t i i o on n t t r r a an ns s p po or r t t
I I I I I I . . 5 5. . 2 2. . 1 1. . 1 1 Car ac t r i st i que de l i nf or mat i on sur l es t r anspor t s
Les donnes sur les transports doivent tre :
faciles gnrer, lire et qui ne soient pas ambigus.
permettent leur extensibilit, leur internationalisation et leur portabilit.
Uniques pour tre facilement rutilisables.
reprsentes indpendamment dune machine donne.
vhicules travers un rseau qui peut tre htrogne.
bien structures, pour ceci, de plus amples dtails sur le modle adopt pour
reprsenter linformation sur les transports vous seront prsents dans le quatrime
chapitre.


51

reprsentes indpendamment dune application donne pour permettre des
applications varies de lutiliser.
qui se transforment facilement dun format un autre.
Plusieurs solutions sont envisageables pour reprsenter les donnes sur les
transports mais ne satisfont pas toutes le cahier de charge impos. En effet, lide la
plus simple est dutiliser soit un traitement de texte soit une base de donnes mais
tous deux nous rendrait prisonniers du format.
Tex t e SGBD
On ne connat pas bien la structure Dans un SGBD, on connat la structure
des tables et la smantique des
colonnes
La structure est irrgulire : Donnes
manquantes, ou en plus (annotations)
Le typage peut ntre quindicatif : On
tolre des donnes non strictement
conforme
La structure peut tre implicite, Il faut
parser pour la dcouvrir
Les modles bases de donnes
classiques proposent une structure trop
rigide
Ni le modle documentaire, ni le modle base de donnes, nous allons prendre un
modle de donnes semi-structur qui marrie les deux : XML.
Figure 3.4 : Particularits et diffrences entre le modle documentaire et celui de base de
donnes
I I I I I I . . 5 5. . 2 2. . 1 1. . 2 2 Le l angage XML
XML (eXtensible Markup Language) est une version simplifie de SGML
(Standardized Generalized Markup Language, ISO 8879, 1986). SGML est trs utilis
dans l'industrie pour de grandes documentations techniques. En revanche, Il est trop
complexe pour une utilisation grand public ou dans des domaines moins exigeants
sur la prcision. XML utilise 10% de SGML pour reprsenter efficacement la plupart
des besoins des applications. Cest en effet un modle de donnes fond sur des


52

arbres et un langage de reprsentation bas sur le balisage. Il permet de formuler des
requtes sans connatre la structure des donnes. Il interroge les donnes et leur
structure simultanment lencontre des SGBD qui ncessitent une connaissance de
la structure. XML ne dfinit que la structure et le contenu d'un document, pas son
comportement ni son traitement.
I I I I I I . . 5 5. . 2 2. . 1 1. . 3 3 Choi x du XML
Le langage XML est une rponse aux exigences de linformation sur les
transports. Il a plusieurs avantages [45] [47] :
XML est une mthode pour mmoriser des donnes structures (les tables
dhoraires, les diffrents lments constituant le rseau de transport, etc.) dans un
fichier texte. Il est lisible par un tre humain et nest pas li un mode dutilisation
puisquil autorise chacun dfinir son propre langage .
XML est portable. Cest un contenu alphanumrique qui est structur avec des
balises et indpendant de la reprsentation physique. Il peut intgrer des contenus
provenant dorigines diverses, dun traitement de texte, dun site web, dune base de
donnes, dun fichier ou de tous la fois ce qui rend le contenu indpendant de
lapplication.
XML est libre de droits et correctement pris en charge : en tant que technologie
W3C, XML est libre de droits et il est adapt pour dvelopper des logiciels sans frais.
XML est extensible, il permet chaque utilisateur de dfinir ses propres
structures de document, il peut aussi se conformer des structures types, appeles
DTD. Chaque communaut peut ainsi proposer des structures normalises.
XML permet un accs des sources d'information htrognes : l'interrogation
et l'change de donnes entre systmes d'information htrognes est souvent
complexe. XML contribue rsoudre ce problme puisquil est un format d'change
normalis et indpendant de toute plateforme.
I I I I I I . . 5 5. . 2 2. . 2 2 L Le es s t t e ec c h hn no ol l o og gi i e es s S SM MS S
Le pr ot oc ol e SMPP :
Le protocole SMPP (Short Message Peer to Peer) est un protocole industriel
ouvert, conu pour simplifier lintgration dapplications avec les rseaux mobiles
comme le rseau GSM. Le protocole SMPP apporte une interface flexible permettant
la communication des donnes pour le transfert de messages entre le centre de


53

messages et le systme de lapplication SMS. Le centre de messages peut tre un
SMSC(Short Message Service Centre), un centre de diffusion de messages ou un
autre type de centre. Le protocole est bien dploy dans lindustrie de la
tlcommunication mobile. Le port par dfaut est le port 2775, mais les oprateurs
peuvent choisir un autre port pour leur serveur SMPP. Les spcifications du protocole
SMPP sont disponibles gratuitement. (http://smsforum.net/doc/). Les SMS sont
envoys depuis le serveur jusqu' loprateur, par liaison filaire. Ce dernier se
chargera de lacheminement des SMS leurs destinataires finaux sur le rseau GSM.
Ut i l i sat i on dun modem GSM :
Un modem GSM runit les fonctions dun modem traditionnel et dun metteur
rcepteur GSM. On le raccorde, gnralement par le port srie, nimporte quel PC.
Comme tout tlphone potable, le modem GSM est videmment quip dune carte
puce de tlcommunication, mais il ne comporte en gnral ni clavier ni affichage
propre.
L Le e c c h ho oi i x x t t e ec c h hn no ol l o og gi i q qu ue e
Avant de choisir la technologie qui va tre utilise dans notre projet nous allons
dresser un tableau qui rcapitule les technologies dj cites tout en prcisant pour
chaque une les avantages et les inconvnients.
Solution Avantages Inconvnients
Le protocole SMPP
(choisi)
Simple utiliser et haut
dbit de transmission.
Ncessite une scurisation des
changes avec le SMSC.
Le modem GSM Facile installer. Faible dbit de transmission

I V.5.3 Modl i sat i on des besoi ns t ec hni ques
La modlisation des besoins techniques englobe toutes les contraintes qui ne
traitent ni laspect description du mtier, ni la description applicatrice. Cette
modlisation est exprime du point de vue de la structure du matriel exploiter.
La st r uc t ur e mat r i el l e de l appl i c at i on
Dun point de vue matriel lapplication web doit communiquer dune part via le
protocole HTTP avec le navigateur web client pour excuter les requtes des


54

utilisateurs. Dautre part lapplication SMS doit communiquer avec un tlphone
portable qui se connecte de sa part au rseau GSM pour assurer lenvoi des
messages.
PC
Aministrateur
Navigateur
Oprateur Tlcom
(SMSC)
Tlphone
Mobile
<<GSM>>
Serveur
d'information
<<SMPP>>
<<HTTP>> <<TCP/IP>>

Figure 3.4 : Structure matrielle de lapplication

Conc l usi on
D
ans cette partie, nous avons cern les objectifs du systme cible. Ces objectifs
doivent rpondre aux normes et aux exigences dun systme dinformation
multimodale typique. Lapport et loriginalit de ce travail sont quils dtaillent
le fonctionnement du SIMT. Une tche laborieuse qui a ncessit une bonne
matrise des concepts lis la modlisation UML et une bonne manipulation des outils
ncessaires. La fourniture explicite des rsultats permettra denrichir les expriences futures
dans le domaine de linformation multimodale en Tunisie en remdiant aux failles de la
spcification et de la modlisation actuelles. Tout de mme, cette phase nous permettra de bien
laborer le modle de conception de lapplication. Dans le prochain chapitre nous allons
prsenter les diagrammes de classes statiques ainsi que dynamiques en illustrant
lacheminement du premier au dernier par les diagrammes dinteraction et de collaboration.


55

C

h a p i t r e
4
I nt r oduc t i on

uite ltude de lexistant et la dtermination des objectifs du systme SIMT,
nous somme passs la dtermination des fonctionnalits du systme et ce
par llaboration des deux diagrammes des cas dutilisation correspondant aux
deux sous-systmes adopts. Par la suite, nous avons dtaill les interactions entre
les acteurs et le systme pour chacun de ces cas dutilisation.
Dans la partie suivante, nous allons procder la description dtaille du systme en
prcisant les diffrentes classes qui interviennent dans la conception.
I Anal yse obj et s des besoi ns
Aprs avoir exprim les besoins de notre systme dans le chapitre prcdent
sous forme de cas dutilisation, nous allons maintenant effectuer une analyse objet de
ces derniers. Pour cela nous allons reprsenter quelques scnarii de cas dutilisation
par des diagrammes dinteraction et des diagrammes de collaboration, pour aboutir
la fin ltablissement du diagramme des classes dynamique.
I .1 Par t i t i onnement l ogi que
Le partitionnement logique permet de dterminer comment la logique
applicative sera divise en modules. Il sert accumuler des couches de
fonctionnalits qui collaborent, laide dinterfaces bien dfinies, mais ne partage pas
beaucoup dinformations internes. Il facilite la comprhension de la structure et de la
conception de lapplication et influence son volutivit.
UML utilise le concept de paquetage pour organiser des lments partageant
la mme smantique en entits logiques. Pour ce systme, nous avons pu organis
les cas dutilisation de chaque sous-systme en plusieurs paquetages.
S
I I V V. . C CO ON NC CE EP PT TI I O ON N D DU U
S SY YS ST TE EM ME E D D I I N NF FO OR RM MA AT TI I O ON N
S SI I M MT T


56

Sous-systme Cas dutilisation Paquetage
Grer la collecte des
donnes.
CollecteInformations

Traiter les donnes
collectes.

AddInformations

Elaborer linformation sur
le transport.

ElaborateInformations

Grer la base de
donnes.

GestionBD

Gestion des
informations collectes
<<subsystem>>

Effectuer les mises jour
pour les vhicules de
transport.
SendInformations

Planifier un voyage.

PlanificationVoyage

Gestion d'accs aux
informations
<<subsystem>>

Accder aux informations
gnrales.
Accder aux
informations localises.
Accder aux offres et
annonces du fournisseur de
service dinformation (FSI).
ConsulterInformations

AdministrationServices

Evaluer le service.
Figure 4.1 : organisation des cas dutilisation par paquetages


57

I .2 Modl e du sous-syst me de gest i on des i nf or mat i ons c ol l ec t es
I .2.1 Dvel oppement du modl e st at i que
Apres avoir cit les diffrents cas dutilisation de systme ainsi que le
partitionnement logique de ces derniers, nous passons la spcification des classes
qui composent les diffrents packages du systme en tablissant le premier
diagramme des classes qui reprsente la structure statique en terme de classes et de
relations. Les classes ne contiennent que les attributs.
CollecteInformations
GestionBD
SendInformations
AddInformations
ElaborateInformations

Figure 4.2 : le partitionnement en paquetages du 1
er
sous-systme
Fournisseur
Nom : String
Adresses : String []
ImportMecanismes : String []
CollectedData
DefaultImportStockEmplacement : URL
DefaultDepositStockEmplacement : URL
ImportMecanisms : Hashtable
0..n
1..n
0..n
1..n
importer
AddedData
DefaultStockEmplacement : URL
ManagedData
DefaultCreatedDataEmplacement : URL
Format
CreatedDataFormats : Hashtable
DataOutFormats : Hashtable
DataInFormats : Hashtable 0..n 0..n 0..n 0..n
verifier
0..n
0..n
0..n
0..n
verifier
SentData
SendingMecanisms : Hashtable
Desinations : URL[ ]
0..n
0..n
0..n
0..n
verifier
ElaborateData
DefaultFileEmlacement : URL
DefaultCreationParams : Hashtable
DefaultCalculParams : Hashtable
Historique
DefaultFile : File
TimeOut : Date
1 0..n 1 0..n
ajouter
1
0..n
1
0..n
ajouter
1
0..n
1
0..n
ajouter
1
0..n
1
0..n
ajouter
1
ajouter
1
Figure 4.3 : diagramme des classes statique


58

Il faut noter aussi que pour des raisons de clart, nous navons pas inclu dans
ce diagramme les classes qui reprsentent les interfaces graphiques, nous allons
nous limiter ceux qui concernent la couche mtier (noyau de lapplication).
I .2.2 Dvel oppement du modl e dynami que
Le modle dynamique permet de complter le modle statique en ajoutant les
mthodes aux diffrentes classes. Afin de spcifier les mthodes pour chaque classe,
nous devons tablir les diagrammes dynamiques des diffrents scnarii des cas
dutilisation. Dans la suite, nous nallons prsenter que quelques diagrammes
dinteraction illustratifs du processus suivi pour aboutir au modle dynamique.
I I . . 2 2. . 2 2. . 1 1 E El l a ab bo or r a at t i i o on n d de es s d di i a ag gr r a am mm me es s d d i i n nt t e er r a ac c t t i i o on n

Sc nar i o : I mpor t er l es donnes
Ladministrateur a la possibilit dimporter donnes des diffrents fournisseurs.
: Administrateur
: CollectedData : Fournisseur : Historique
getDataTypes()
setDataType(DataType)
listFournisseurs(DataType)
setImportFournisseur(Fournisseur)
getImportMecanism(Fournisseur)
setImporMecanism(Mecanism)
setImportEmplacement(ImportEmplacement)
setImportStockEmplacement(ImportStockEmplacement)
import()
importOK()
ajouterHistorique()

Sc nar i o : Homogni ser l es donnes
Ladministrateur a la possibilit de traiter les donnes en les homognisant selon un
certain format.


59

: Administrateur
: AddedData : Format : Historique
getFusionDataInFormats()
setFusionDataInFormat(FusionDataInFormat)
setFusionDataInEmplacement(FusionDataInEmplacement)
verifyFusionDataIn()
fusionDataFormatInOK()
fusionData()
fusionDataOK()
ajouterHistorique()
setFusionDataOutFormat(FusionDataOutFormat)
setFusionDataOutEmplacement(FusionDataOuEmplacement)
getFusionDataOutFormats()
Sc nar i o : I nt gr at i on des donnes
Ladministrateur a la possibilit de traiter les donnes homognises en les
intgrant au fichier principal.
: Administrateur
: AddedData : Format : Historique
setIntegrateDataEmplacement(IntegrateDataEmplacement)
integrateData()
integrateDataOK()
ajouterHistorique()
verifyFusionDataOut()
fusionDataFormtOutOK()


60

I I . . 2 2. . 2 2. . 2 2 L Le e d di i a ag gr r a am mm me e d de es s c c l l a as s s s e es s
Fournisseur
Nom : String
Adresses : String []
ImportMecanismes : String []
listFournisseurs()
getImportMecanism()
addFournisseur()
modifyFournisseur()
deleteFournisseur()
Format
CreatedDataFormats : Hashtable
DataOutFormats : Hashtable
DataInFormats : Hashtable
getFusionDataInFormat()
getFusionDataOutFormat()
getCreatedDataFormat()
verifyFusionDataIn()
verifyFusionDataOut()
verifyCreatedData()
listFormats()
addFormat()
modifyFormat()
deleteFormat()
CollectedData
DefaultImportStockEmplacement : URL
DefaultDepositStockEmplacement : URL
ImportMecanisms : Hashtable
getDataTypes()
setDataType()
setImportFournisseur()
setImportMecanism()
setImportEmplacement()
setImportStockEmplacement()
importData()
setDepositEmplacement()
setDepositStockEmplacement()
deposit()
0..n
1..n
0..n
1..n
importer
AddedData
DefaultStockEmplacement : URL
setFusionDataInFormat()
setFusionDataInEmplacement()
fusionDataInOK()
setFusionDataOutFormat()
setFusionDataOutEmplacement()
fusionDataFormatOutOK()
fusionData()
setIntegrateDataEmplacement()
integrateData()
0..n
0..n
0..n
0..n
verifier
ManagedData
DefaultCreatedDataEmplacement : URL
getDataTypes()
listData()
filterData()
modifyData()
deleteData()
addData()
addSelectedData()
setCreatedDataEmplacement()
setCreatedDataFormat()
createData()
0..n
0..n
0..n
0..n
verifier
SentData
SendingMecanisms : Hashtable
Desinations : URL[ ]
listDestinations()
setDestination()
addDestination()
modifyDestination()
deleteDestination()
setSendingMecanism()
setCreatedDataEmplacement()
send()
createdDataFormatOK()
0..n
0..n
0..n
0..n
verifier
Historique
DefaultFile : File
TimeOut : Date
ajouterHistorique()
listerHistorique()
deleteHistorique()
filterHistorique()
1
0..n
1
0..n
ajouter
1
0..n
1
0..n
ajouter
1 0..n 1 0..n
ajouter
1
0..n
1
0..n
ajouter
ElaborateData
DefaultFileEmlacement : URL
DefaultCreationParams : Hashtable
DefaultCalculParams : Hashtable
setFileEmplacement()
setCreationParams()
setCalculParams()
saveParams()
11
ajouter
Figure 4.4 : diagramme des classes dynamique

I .3 Modl e du sous-syst me dac c s aux i nf or mat i ons
I .3.1 Ar c hi t ec t ur e l ogi c i el l e de l appl i c at i on w eb
Pr obl mat i que : Comment modliser l'interface utilisateur d'une application
Web de sorte que chaque partie puisse tre aisment modifie individuellement ?


61

Fac t eur s pr endr e en c ompt e : Les facteurs suivants agissent sur le
systme dans le contexte prsent et doivent tre pris en compte dans la recherche de
la solution au problme :
o Le code de l'interface utilisateur dpend gnralement plus de la
machine que la logique mtier. Si vous souhaitez faire migrer l'application d'une
application sur navigateur une application sur assistant personnel ou sur tlphone
mobile compatible Web, vous devez rcrire une bonne partie du code de l'interface
utilisateur alors que la logique mtier pourra rester inchange. Une sparation claire
de ces deux lments permet d'acclrer la migration et de rduire le risque
d'introduction d'erreurs dans la logique mtier.
o La logique d'interface utilisateur est modifie plus frquemment que la
logique mtier, particulirement dans les applications Web. Il est possible, par
exemple, d'ajouter de nouvelles pages d'interface ou de rorganiser les pages
existantes. Si le code de prsentation et la logique mtier sont associs dans un seul
et mme objet, vous devrez modifier l'objet contenant la logique mtier chaque fois
que vous souhaiterez changer l'interface utilisateur. Cette dmarche risque
d'introduire des erreurs et ncessite chaque modification de l'interface, mme
minime, de tester de nouveau l'ensemble de la logique mtier.
o La conception de pages HTML visuellement efficaces et attirantes
ncessite gnralement des comptences autres que celles requises pour le
dveloppement d'une logique mtier complexe. Et il est bien rare qu'une mme
personne prsente cette double comptence. Il est donc prfrable de sparer l'effort
de dveloppement de ces deux parties.
Sol ut i on : Le modl e MVC2
Le model MVC2 (pour Model View Controller) recommande de dcomposer une
application en trois parties: le modle (qui contient les donnes et implmente la
logique mtier), la vue ou la prsentation (qui ralise le rendu graphique de
l'application) et le contrleur (qui gre les interactions avec l'utilisateur). Nous pouvons
schmatiser une telle application Web de la manire suivante:


62


Figure 4.5 : le modle MVC2
1 : le client fait une demande au contrleur. Ce contrleur passe toutes les demandes
des clients. C'est la porte d'entre de l'application. C'est le C de MVC.
2 : le contrleur traite cette demande. Pour ce faire, il peut avoir besoin de l'aide de la
couche mtier, ce qu'on appelle le modle M dans la structure MVC. La couche mtier
peut ventuellement faire appel la couche daccs aux donnes.
3 : le contrleur choisit la rponse (= vue) envoyer au client. Celle-ci est le plus
souvent une page contenant des lments dynamiques.
4 : La vue construit la rponse en faisant appel aux objets mtier qui lui fournissent
des donnes.
5 : la vue est envoye au client. C'est le V de MVC.
Pour plus dtails sur le modle MVC II en Annexe B.
I .3.2 Dvel oppement du modl e obj et de c onc ept i on
Pour le dveloppement du modle nous avons adopt la reprsentation utilise
pour les diffrents composants dune application Web. Cette reprsentation sadapte
parfaitement au modle MVC. Elle reprsente chacun des lments vue, contrleur et
modle respectivement par les lments boundary , control et entity
Boundar y=Vue Cont r ol =Cont r l eur Ent i t y=Modl e


63

PlanificationVoyage
ConsulterInformations AdministrationServices
Authentification

Figure 4.6 : le partitionnement en paquetages du deuxime sous-systme
I I . . 3 3. . 2 2. . 1 1 M Mo od d l l e e o ob bj j e et t d de e c c o on nc c e ep pt t i i o on n d de e l l a a c c o ou uc c h he e p pr r s s e en nt t a at t i i o on n ( (v v u ue e) )
Notre modle logique respecte larchitecture 3-tiers selon le modle MVC.
La couche prsentation est reprsente par les pages web sous forme de
boundary.

Figure 4.7 : La couche prsentation de lapplication Web


64

I .3.3 Vue dynami que du sous-syst me
I I . . 3 3. . 3 3. . 1 1 E El l a ab bo or r a at t i i o on n d de es s d di i a ag gr r a am mm me es s d de e c c o ol l l l a ab bo or r a at t i i o on n
Scnario :
Pl ani f i er un voyage
: Utilisateur : PlanifierVoyageUser : ControllerVoyage
: Voyage
: PossibiliteVoyage
: ShemaVoyageUser
1: planifierVoyage( ) 2: planifierVoyage( )
5: afficher( )
3: createVoyage( )
4: createPossibilities( )

Scnario :
Dt ai l l er une possi bi l i t
: Utilisateur : ShemaVoyageUser
: Voyage
: PossibiliteVoyage
: ControllerVoyage
: InfosPossibiliteUser
1: infosPossibility( ) 2: infosPossibility( )
4: details( )
3: detailPossibility( )
5: afficher( )


65

Scnario :
Af f i c her des i nf os (sur l es l i gnes ou sur l es hor ai r es)
: Utilisateur : GeneralInfosUser
: ControllerInfos
: Infos
: GeneralInfo
1: showGeneralInfo_Parametresied( )
2: showGeneralInfo_Parametresied( )
5: afficher( )
3: showGeneralInfos( )
4: createGeneralInfo( )

Scnario :
Ac c der aux i nf or mat i ons l oc al i ses
: Utilisateur : GeneralInfosUser
: Infos
: TypeInfo
: LocalisatedInfosUser
: ControllerInfos
: TypeInfo
1: localisate( ) 2: localisateInfo( )
4: createInfos( )
6: selectGeneralInfoType( )
3: localisateInfo( )
5: selectGeneralType( )
7: afficher( )


66

Scnario :
val uer l e ser vi c e
: Utilisateur : EvaluationUser
: ControllerAdministration
: Evaluation
: FinEvaluation
1: evaluate( ) 2: evaluateServices( )
3: evaluateServices( )
4: afficher( )

Scnario :
met t r e une r c l amat i on
: Utilisateur
: Reclamation
: ReclamationUser
: FinReclamation
: ControllerAdministration
1: reclamer( ) 2: reclamerServices( )
3: reclamerServices( )
4: afficher( )

I I . . 3 3. . 3 3. . 2 2 L Le es s d di i a ag gr r a am mm me es s d de es s c c l l a as s s se es s
Pour terminer cette section nous allons prsenter les diagrammes de classes
pour les paquetages du sous-systme de gestion daccs aux informations.


67

ErrorParamsVoyage
message_erreur
PlanifierVoyageUser
afficher()
planifierVoyage()
changerVoyage()
ShemaVoyageUser
afficher()
trierPossibilities()
infosPossibility()
changePossibility()
changeVoyage()
InfosPossibiliteUser
afficher()
changePossibility()
ControllerVoyage
planifierVoyage()
infosPossibility()
changePossibility()
changeVoyage()
PossibiliteVoyage
details()
createPossibilities()
destroy()
selectPossibilities()
Voyage
createVoyage()
detailPossibility()
changePossibility()
change()
0..n
1
0..n
1

Figure 4.8 : diagramme des classes du paquetage PlanificationVoyage
TypeInfo
createInfos()
destroy()
selectGeneralInfoType()
selectInfoType()
ErrorLocalisation
message_erreur
GPS
checkLocalisation()
Infos
localisateInfo()
changer()
destroyAllInfoTypes()
selectGeneralType()
showGeneralInfos()
GeneralInfosUser
afficher()
localisateInfos()
modifyLocalisation()
showGeneralInfo_Parametresied()
ControllerInfos
localisateInfo()
changeInfo()
changeLocalisation()
localisationIs()
showGeneralInfo_Parametresied()
0..n
1
0..n
1
LocalisatedInfosUser
afficher()
changeInfo()
changeLocalisation()
GeneralInfo
createGeneralInfo()

Figure 4.9 : diagramme des classes du paquetage ConsulterInformations


68

FinEvaluation
afficher()
FinReclamation
afficher()
Evaluation
titre
code
format
objectifs
evaluateServices()
Reclamation
titre
code
reclamerServices()
ReclamationUser
reclamer()
ControllerAdministration
evaluateServices()
reclamerServices()
ErreurSubmit
message_erreur
EvaluationUser
evaluate()

Figure 4.10 : diagramme des classes du paquetage AdministrationServices
I I Modl i sat i on du t r anspor t c ol l ec t i f

Le but de cette section est de modliser le rseau de transport collectif tunisois:
il sagit de trouver le modle le plus appropri pour contenir linformation sur le
transport pour que nous puissions, par exemple, accomplir le calcul ditinraires.
I I .1 Or i gi nes du modl e adapt
Il y a plusieurs reprsentations possibles du transport collectif. Dans notre
lecture bibliographique, nous avons trouvs plusieurs projets, de part et dautre dans
le monde, qui expriment leur propre point de vue sur le sujet. Parmi les meilleurs
projets en matire de modlisation des changes de donnes concernant l'information
aux voyageurs, figure celui du projet europen TRIDENT (TRansport Intermodality
Data sharing and Exchange NeTworks) [44]. Le modle TRIDENT permet
concrtement d'changer des informations TC au moyen d'un format normalis mais
trop complexe pour etre ralisable en pratique cest dailleurs lune des raisons pour
quil ait t refus comme norme. Alors nous avons men une tude critique pour
proposer un modle simplifi (moins complexe que le modle original) base


69

danalogies avec les graphes, et plus adapt la ralit du transport collectif tunisois.
Nous avons test le modle labor sur des donnes relles et il a montr quil tait
apte contenir linformation sur le transport collectif Tunis.
Il faut noter que nous avons ajout une condition pour simplifier le modle.
Cette simplification consiste considrer la dure de parcours dun voyage fixe
quelque soit lheure en ignorant les facteurs qui influent sur cette dure (trafic,
conditions mtorologiques) ce qui limite le modle.
I I .2 Desc r i pt i on du modl e
Au fur et mesure que les besoins des usagers sclaircissaient, et surtout
lorsque le problme de calcul ditinraires dans le rseau de transport collectif sest
pos, il nous est paru que la dtermination dun modle pour ce rseau passait
imprativement par son assimilation un graphe. Ds lors, nous nous sommes mis
tudier la thorie des graphes pour y trouver une solution [38]. Nos travaux dans cette
direction nous ont permis de trouver des similitudes entre le voyage dans les
transports collectif et le parcours de graphe.
En effet, il existe deux familles de graphes, ceux orients et ceux non orients.
Un graphe orient G est reprsent par un couple (S, A) o S est un ensemble fini et
A une relation binaire sur S. Lensemble S est lensemble des sommets de G et A est
lensemble des arcs de G. Alors que dans un graphe non orient G = (S;A),
lensemble des artes A nest pas constitu de couples mais de paires de sommets,
une paire tant non ordonne contrairement un couple. En partant de ces
dfinitions, nous pouvons dduire que le rseau de transport est dabord un graphe
orient. Cest un graphe orient puisquon parle souvent dans les rseaux de transport
dun voyage aller et dun autre retour en passant par les mmes stations. Do, les
stations quivalent aux sommets et les tronons quivalent aux arcs. Dans un graphe
orient, nous pouvons associer des poids aux arcs. Ces poids quivalent aux cots de
dplacement, gnralement exprims en dure, dans un tronon. Nous pouvons
introduire alors le concept de tronon comme suit : un tronon relie deux arrts
(stations), dans une direction donne et possde une dure suppose fixe.


70


Arrt A Arrt B

Tronons A B
dure = 5 mn

Ensuite, dans un graphe orient G = (S, A), un chemin de longueur k dun
sommet u un sommet v est une squence (u
0,
u
1,,
uk) de sommets telle que u=u
0
,
v=u
k
et (u
i-1
,u
i
) A pour tout i dans {1,,k}. Un chemin est lmentaire si ces
sommets sont tous distincts. Un sous-chemin p
0
dun chemin p = (u
0,
u
1,,
uk) est une
sous squence contigu de ses sommets. Nous retrouvons lanalogie avec le tronon
si p
0
tait form de deux sommets contigus. Cette dernire dfinition nous conduit
dduire lquivalent de la succession des nuds du premier jusquau dernier nud :
cest le concept ditinraire qui est un chemin bien dtermin dans le rseau de
transport. Un ensemble non vide ditinraire peut constituer ce que nous qualifions de
ligne. En effet, chaque itinraire est form par une succession de tronons et chaque
ligne peut tre divise en plusieurs itinraires de directions diffrentes et de terminus
diffrents. Nous constatons, dans le cas gnral, qune ligne possde deux itinraires,
un dans le sens aller et un autre dans le sens retour. Les autres cas se prsentent
essentiellement par un changement de terminus et par un saut de stations.

Terminus 2

Terminus 4
Ligne 1
Terminus 1

Terminus 3

Terminus 2
Terminus 1
Ligne 1
Itinraire 1
Itinraire 2
Arrt desservi Arrt non desservi


71

La ligne 1 comprend 5 itinraires : terminus 1 terminus 2 avec un stop toutes les
stations, terminus 1 terminus 2 avec saut de la station 2, terminus 2 terminus 1,
terminus 3 terminus 4, terminus 4 terminus 3
De plus, dans un graphe orient G=(S, A), un chemin (u
0,
u
1,,
uk) forme un
circuit si u
0
=u
k
et si le chemin contient au moins un arc. Ce circuit est lmentaire si
les sommets u
1
,...,u
k
sont distincts. Un graphe sans cycle est dit acyclique. Daprs
cette dfinition, et en constatant que dans les rseaux de transport certaines lignes de
transport sont circulaires, nous pouvons dfinir exactement le concept dune ligne. En
effet, les lignes, analogues aux circuits, peuvent former des chemins qui partent dune
source initiale terminus vers une destination finale un autre terminus . Parfois,
les deux terminus concident.
Terminus 2
Terminus 3
Terminus 1
Ligne 1
Ligne 2

Enfin, Un graphe orient est fortement connexe si chaque sommet est
accessible partir de nimporte quel autre. Cest le cas dun rseau de transport si
nous considrons la possibilit darticuler plusieurs moyens de transport pour arriver
destination en tant parti de nimporte quelle station dans tout le rseau. On dit quun
graphe G
0
= (S
0
, A
0
) est un sous-graphe de G = (S, A) si S
0
S et si A
0
A. Cest ce
qui arrive si nous divisons tout le rseau de transport en des rseaux spcifiques aux
moyens de transport existants. Ainsi un rseau signifie ici la famille des moyens de
transport collectif existant dans le rseau tunisois. Nous pouvons distinguer le rseau
bus, le rseau mtro, et le rseau train de la banlieue sud. Chaque rseau est form
de plusieurs lignes.
Enfin, nous ajoutons un concept propre aux rseaux de transport et qui les
distingue des graphes, cest le concept dhoraire. En effet, chaque itinraire sont
associs des horaires de dpart. Il est ainsi facile de dduire lheure de passage par
chaque tronon et plus prcisment chaque station de dpart dun tronon, dans


72

une direction donne, en se basant sur leur dure. Le concept dhoraire apporte une
description temporelle au voyage.

Horaire 1
Heure de dpart =
9 :00
9 :00 9 :05 9 :10 9 :15
Horaire 2
Heure de dpart =
10 :00
10 :00 10 :05 10 :10 10 :15

I I .3 Les r el at i ons i mpor t ant es dans l e modl e
La relation entre le rseau et la ligne : un rseau est agrg par une ou plusieurs
lignes.
1 1..*
Ligne Rseau

La relation entre la ligne et litinraire: une ligne peut tre reprsente par un ou
plusieurs itinraires, et un itinraire appartient une ligne et une seule.

1..* Itinraire
Ligne
1

La relation entre litinraire et le tronon : un itinraire comprend un plusieurs
tronons, et un tronon peut appartenir un ou plusieurs itinraires.

1..*
Tronon
Itinraire
1..*
La relation entre litinraire et lhoraire de dpart : un itinraire comprend un
plusieurs horaires de dpart, et un horaire de dpart peut appartenir un ou plusieurs
itinraires.
1..*
Horaire
Itinraire
1..*

La relation entre litinraire et la station : un itinraire comprend deux stations qui sont
les terminus alors quune station peut appartenir aucun ou plusieurs itinraires.

2
Station
Itinraire
0..*


73

La relation entre le tronon et la station : un tronon est agrg par deux stations, et
une station peut appartenir un ou plusieurs tronons

2
Station
Tronon
1..*

Rseau
idRseau
nom
Ligne
idLigne
numro
1..n 1 1..n 1
Horaire
heure
Itinraire
idItinraire
1..n
1
1..n
1
1..n 1..n 1..n 1..n
Station
idStation
nom
2
0..n
2
0..n
Tronon
idTronon
dure
1..n
1..n
1..n
1..n
2
1..n
2
1..n

Figure 4.11 : Modlisation du rseau de transport
I I .4 Desc r i pt i on du modl e en XML
Le choix de XML pour reprsenter linformation sur le transport a t discut au
troisime chapitre. Limportance de cette information exige dabord que nous nous
assurions de sa validit, du moins dun point de vue structurel. En effet, une
information sur le transport ne sera considre comme valide que si elle respecte le
modle (la structure) dfinit dans la section prcdente. Le langage XML satisfait cette
exigence en offrant la possibilit de valider un document XML par une dfinition de
type de document ou Document Type Definition (DTD). En effet, une DTD permet de
dfinir la grammaire et la syntaxe dun langage XML particulier. Un document XML
bien form peut tre valid par rapport une DTD dfinit lintrieur ou lextrieur
du document XML [46]. Nous choisissons de nommer InfoTC limplmentation de
ce modle sous forme de DTD, pour Information sur le Transport Collectif . La
structure arborescente du fichier XML contenant linformation sur le transport est


74

dcrite dans cette DTD qui dfinit les lments et les balises de ce fichier. La figure
4.12 illustre la DTD de notre modle adopt.
Figure 4.12 : La DTD formule pour valider les fichiers XML
La figure 4.13 illustre le fichier XML contenant linformation sur le bus 527, du rseau
bus. Ce fichier XML est valide par rapport la DTD InfoTC .
Figure 4.13 : Le fichiers XML contenant linformation (sur 2 colonnes)


75

Conc l usi on

ans ce chapitre, nous avons fait un petit rappel des besoins du systme
en prcisant les diffrents cas dutilisations et des diffrents scnarios,
ensuite nous avons modlis ces besoins par des diagrammes de
squences pour aboutir ltablissement de diagramme des classes.
La tche la plus innovante dans ce chapitre, est la proposition dun modle pour
reprsenter le rseau de transport collectif tunisois. Le modle puise ses sources
dans la thorie des graphe ce qui lui donne une grande fiabilit et rationalit. Il peut
tre tendu dautre rgion et reprsenter tout le rseau de transport incorporant
ainsi dautres moyens de transport tels que la voiture prive et la marche. Une limite
reste franchir lavenir qui est le fait dignorer les facteurs rels qui influent sur le
transport. En rsolvant ce problme, le modle deviendra dynamique et raliste
pour donner naissance un systme dinformation plus performant. Dans le chapitre
suivant nous allons expliquer les choix entrepris pour limplmentation de la solution et
dcrire la dmarche de ralisation.
D


76

C h a p i t r e

I nt r oduc t i on

prs avoir entam la spcification et la conception du systme, nous allons
traiter dans ce chapitre les dtails lis limplmentation de lapplication. Pour
cela nous allons exposer les choix technologiques que nous avons adopt afin
de russir la ralisation du systme dinformation SIMT. Enfin nous allons citer les
tapes dimplmentation suivie de quelques copies dcrans de lexcution de certains
modules de lapplication pour illustrer quelques fonctionnalits de notre systme.
I Choi x t ec hni ques
I .1 Ut i l i sat i on des l ogi c i el s l i br es et c eux Open Sour c e
Un logiciel libre est un logiciel dont le code source est librement disponible,
duplicable, modifiable et redistribuable. La meilleure manire de rendre un logiciel
libre est de le copylefter , cest dire de le distribuer dans le domaine public, sans
copyright [48]. La GNU GPL (Licence Publique Gnrale GNU) est un ensemble
spcifique de conditions de distribution pour copylefter un programme. Le projet GNU
l'utilise comme conditions de distribution de la plupart des logiciels GNU. Le terme
open source, quant lui, exprime quelque chose de proche (mais pas tout fait
identique) au logiciel libre en ce sens que le code source est mis librement en
circulation tout en permettant son auteur de conserver son copyright [48]. Les
avantages dutilisation des logiciels libres et open source sont nombreux [18] :
Cot d'investissement : le cot des licences est cot nul ou, dans le cas d'un
distributeur, cot faible. Pour le matriel, les logiciels libres ne ncessitent pas en
gnral d'acquisitions de matriel spcifiques.
5
A
V V. . R RE EA AL LI I S SA AT TI I O ON N D DU U
S SY YS ST TE EM ME E D D I I N NF FO OR RM MA AT TI I O ON N
S SI I M MT T


77

Qualit technique du code : crit en mettant l'accent sur la fiabilit et la
performance, relu et corrig par de nombreux programmeurs qui prennent en compte
les remarques d'une communaut d'utilisateurs active.
Flexibilit : la libre disposition du code source et la logique de composants
permettent d'adapter le logiciel au type d'utilisation, donc, le cas chant, de l'allger
et d'en optimiser les performances.
Scurit : L'accs au code source facilite la dtection d'ventuels trous de
scurit intentionnels dans un logiciel libre.
I .2 Le l angage de pr ogr ammat i on : J ava
Les environnements qui permettent le dveloppement de systmes comme le
ntre sont nombreux, notre choix se porte sur la plate-forme Java (langage orient
objet cr par Sun Microsystems). Ce choix vient du fait que le langage Java est un
langage multi plate forme qui permet selon le concept : write once, run everywhere
dcrire, une fois pour toutes, des applications capables de fonctionner dans la plus
part des environnements avec des performances plus ou moins gales, cest pour
cela que nous avons opt pour ce langage pour le dveloppement de notre
application. Ce choix offre une libert dans le sens o nous ne serons pas obligs de
changer denvironnement si nous choisissons de changer la plate forme sur la quelle
sera install le systme. De plus, Java est un langage haute scurit vu quil dtecte
et ne laisse pas passer les erreurs ds la compilation. Dans le cas o une erreur
aurait pu se produire au moment de lexcution, Java excute une procdure spciale
qui arrte le programme, ce qui annule le risque du plantage.
I .3 Lappl i c at i on or i ent e Web
Les applications Web ne sont pas les seules permettre de distribuer des
informations via un rseau. Cest exactement ce que font tous les programmes client -
serveur. Mais en ajoutant un composant Web une application client-serveur
habituelle, on bnficie davantages supplmentaires :
Un accs universel : une page Web peut tre consulte depuis nimporte quel
nud dun rseau via un simple lien.
Une compatibilit entre plates-formes : les navigateurs Web ont t conus pour
fonctionner sur pratiquement toutes les plates-formes existantes et la plus part des


78

langages web sont interprts au fur et mesure par le navigateur ce qui rend
lapplication accessible via rseau sans avoir tre prpare par compilation de la
partie cliente.
I .3.1 Le ser veur w eb Tomc at
Tomcat est une implmentation de rfrence des spcifications des servlets et
des Jsp de SUN. Ce serveur est issu du projet Jakarta de l'Apache Software
Fundation. Son installation requiert la prsence dun JDK (Java Development Kit) sur
la machine. Par dfaut, Tomcat s'installe sur le port 8080 au lieu du 80 habituel.
I .3.2 HTML: Hyper Tex t Mar k up Language
Le HTML ("HyperText Markup Language") est un langage qui formalise
l'criture d'un document avec des balises de formatage indiquant la faon dont doit
tre prsent le document et les liens qu'il tablit avec d'autres documents. Il permet,
entre autres, la lecture de documents sur Internet partir de machines diffrentes
grce au protocole HTTP. Le HTML n'est pas un langage de programmation, c'est un
simple fichier texte contenant des balises permettant de mettre en forme le texte, les
images
I .3.3 J ava Ser ver Pages (J SP)
Java Server Pages, cr par Sun Microsystems, est un moteur de publication
dynamique de documents web. Les documents contiennent du HTML et du Java, ce
dernier tant interprt par le serveur. Les Jsp proposent un langage de script
puissant (un langage interprt) excut du ct du serveur au mme titre que les
scripts PHP, ASP... Les Jsp sont intgrables au sein d'une page Web en HTML
l'aide de balises spciales permettant au serveur Web de savoir que le code compris
l'intrieur de ces balises doit tre interprt afin de renvoyer du code HTML au
navigateur du client.
I I . . 3 3. . 3 3. . 1 1 L Le e f f o on nc c t t i i o on nn ne em me en nt t d de es s J J a av v a a S Se er r v v e er r P Pa ag ge es s
Une page utilisant les Java Server Pages est excute au moment de la
requte par un moteur de Jsp, fonctionnant gnralement avec un serveur Web ou un
serveur applicatif. Le modle des Jsp tant driv de celui des servlets (en effet les
Jsp sont un moyen d'crire des servlets), celle-ci est donc une classe Java drivant de


79

la classe HttpServlet, et utilisant les mthodes doGet() et doPost() permettant de
renvoyer une rponse par le protocole HTTP.
Lorsqu'un utilisateur appelle une page Jsp, le serveur Web appelle le moteur de
Jsp qui cre un code source Java partir du script Jsp, compile la classe afin de
fournir un fichier compil (d'extension .class), c'est--dire qu'il constitue en fait une
servlet partir du script Jsp... En ralit ce processus est un peu plus perfectionn : le
moteur de Jsp vrifie si la date du fichier.Jsp correspond celle du fichier.class. Le
moteur de Jsp ne transforme et compile uniquement la classe quau cas o le script
Jsp a t mis jour. Ainsi, le fait que la compilation ne se fasse que lors de la mise
jour du script Jsp, fait de cette technologies une des plus rapides pour crer des
pages dynamiques. En effet, la plupart des technologies de pages actives (ASP,
PHP...) reposent sur un code interprt, ce qui requiert beaucoup de ressources pour
fournir la rponse HTTP. Les Jsp tant compiles (en fait il s'agit d'un bytecode) elles
sont beaucoup plus rapides l'excution.
I I . . 3 3. . 3 3. . 2 2 A Av va an nt t a ag ge es s d de es s J J a av va a S Se er r v ve er r P Pa ag ge es s
Nous avons choisi JSP pour dvelopper lapplication web pour ses avantages
par rapport aux autres langages. JSP est facile comprendre et permet un
dveloppement rapide dapplication Web ouvertes et standard. Les Jsp permettent
d'crire facilement des servlets, en incluant dans des balises spcifiques le code Jsp
au sein du fichier HTML. De plus, les Jsp tant bases sur Java ct serveur
possdent toutes les caractristiques faisant la force de Java :
- les Jsp excute plusieurs activits en mme temps (multithreades),
- les Jsp sont portables,
- les Jsp sont orientes objet,
- les Jsp permettent de sparer efficacement le codage HTML de la logique
applicative des pages Web. En effet, grce l'utilisation de balises, Jsp permet
d'intgrer facilement du code Java au sein du code HTML. L'intrt principal de ce
mcanisme par rapport aux servlet provient de la sparation entre donnes (codage
HTML de la logique applicative fournie par Java.
- Les Jsp sont utiliss pour accder des composants rutilisables, tels que des
servlets, des JavaBeans et des applications compatibles avec le langage Java.
- JSP prend galement en charge l'intgration de code Java dans les pages Web.


80

La figure 5.1 montre les avantages du JSP par rapport au PHP
JSP PHP
Utilise le langage Java, qui est
totalement objet.
Langage procdural avec la possibilit de
faire de lobjet.
Grand nombre dAPIs. Moins de possibilits de dveloppement.
Connexion tout type de bases de
donnes (JDBC).
Connexion tout type de bases de
donnes (ODBC).
Les temps de rponses sont quivalents.
Gourmand en ressources (JVM). Langage interprte chaque appel.
Processus lger, utilise les Threads.
Nouveaux processus pour lexcution des
scripts.
Programmes portables. Problmes de portabilits.
Figure 5.1 : Comparaison entre JSP et PHP

I .3.4 J avaSc r i pt
Javascript est un langage de scripts, qui, incorpor aux balises Html, permet
d'amliorer la prsentation et l'interactivit des pages Web. Ces scripts vont tre grs
et excuts par le browser lui-mme sans devoir faire appel aux ressources du
serveur. Ces instructions seront donc traites en direct et surtout sans retard par le
navigateur.

I .4 La base de donnes
Notre choix sest port sur le SGBD MySQL issu du libre. Les principales
raisons de ce choix sont la rapidit, la robustesse et la facilit d'utilisation. MySQL
supporte de nombreuses API telles que C, C++, Java, Perl et PHP. Etant multiplate-
forme, il est donc disponible pour diffrents systmes dexploitation, et s'interface avec
ODBC (Open DataBase Connectivity) si ncessaire. Il est dot d'un systme souple et
scuris de privilges et de mots de passe, qui autorise une vrification base sur
l'hte. Une solution quatre en un est possible en installant Easyphp
(http://www.easyphp.org/) qui offre entre autre linstallation de MySQL.


81

I I Ar c hi t ec t ur e gnr al e du syst me
I I .1 Desc r i pt i on de l ar c hi t ec t ur e

Figure 5.2 : Architecture gnrale du systme


82

I I .2 Ac qui si t i on aut omat i que des donnes

Lintrt de lacquisition automatique dinformation est davoir toujours des
informations mises jour automatiquement sans la racqurir manuellement chaque
fois. Dans notre systme dinformation, la fourniture dinformations sur les conditions
mtorologiques est un besoin informationnel satisfaire. Aussi faut il prvoir
lacquisition des informations sur les transports partir des sites des fournisseurs et
surtout lorsque ces informations sont mises disposition sur site ftp par exemple.
Lobjectif de ce module est de dvelopper un outil en JAVA permettant
ladministrateur de naviguer sur Internet et dextraire certaines informations des pages
Web (essentiellement celles crites dans le langage HTML) ou des sites ftp. La
deuxime tape est la mmorisation de la lemplacement de linformation dans la
structure de la page ou du site ftp visits par slection dans le navigateur. Dans le cas
dune page web, lapproche dacquisition ncessite dabord lanalyse de la structure de
la page ( parsing ) en transformant cette structure en un arbre dont les nuds sont
les balises ouvrantes et o les feuilles sont le contenu des balises, contenu qui varie
selon le type de la balise. Enfin, la dernire tape consiste mmoriser
lemplacement de linformation. Lemplacement est une succession de balises dans le
cas dune page web ou de rpertoires dans le cas dun site ftp. Il correspond la cl
alors que linformation est le contenu. Cette cl sera stocke dans un fichier XML
contenant en plus ladresse do sera extraite linformation, ainsi que le type
dinformation pour quelle soit rpertorie au bon endroit dans la base de donne. Le
systme se chargera deffectuer la tche dextraction avec une frquence exprime
dans le mme fichier XML. Le reste est un simple stockage en base de donnes.

Figure 5.3 : Acquisition automatique des donnes


83

I I .3 Edi t i on de l i nf or mat i on en XML

Le but de ce module est de raliser une interface graphique conviviale
permettant dditer des fichiers XML en respectant un modle donn (celui que nous
avons adopt pour reprsenter linformation sur les transports collectifs). Lintrt de
cet diteur est de faciliter la tche de saisie des donnes selon ce format. En effet, si
nous utilisons nimporte quel diteur existant sur le march, il ne serait pas capable de
tenir compte des donnes dj saisies sans lintervention de lutilisateur pour copier et
coller ses donnes.
La tche principale de lditeur est de faciliter lajout des diffrents lments qui
constituent le rseau de transport par simple click sur linterface graphique et en
effectuant un contrle sur la hirarchie des lments ajouts. Cette hirarchie, est issu
du modle labor et dcrit dans le quatrime chapitre. Notre apport consiste aussi
ne permettre que la saisie des noms des stations ajouter au fichier XML
reprsentatif du rseau de transport. Les tronons ne seraient autoriss que sils
taient composs de deux stations existantes. De mme pour les itinraires, les
tronons qui les constituent ainsi que les deux terminus doivent exister au pralable.
Les identificateurs seront gnrs automatiquement lors de la cration de nouveaux
lments du fichier XML. Lors des mises jours par ajout ou modification, la gestion
des identificateurs se fera de manire ne reproduire aucun identificateur existant. En
rsum, cette interface graphique devra la fois guider lutilisateur pour ldition du
fichier, et le contraindre respecter le modle. Elle devra aussi le guider pour ldition
des champs textes des fichiers XML, qui doivent respecter une grammaire dfinie.
Pour produire des fichiers XML plusieurs API existent. Une API (Application
Programming Interface) est une bibliothques d'objets (dans le cas de langages
objets) qui permettent au programmeur d'utiliser directement des objets. Dans la suite,
nous allons prsenter lAPI JAXP utilise pour diter les fichiers XML.
I I .3.1 LAPI J AXP
JAXP (Java API for XML Processing) est l'API Java standard pour la
manipulation du format XML. Cette API permet la lecture, la transformation et l'criture
de fichiers ou flux XML. JAXP est compose de quatre paquetages. Cette API met
notre disposition trois ensembles de fonctionnalits regroupes en paquetages :


84

o La modlisation : org.w3c.dom est le paquetage contient l'ensemble des
classes et interfaces ncessaires pour travailler avec DOM (Document Object Model)
qui partir dun fichier XML fabrique une reprsentation en mmoire sous forme dun
arbre qui traduit l'organisation et le contenu du document XML.
o Lanalyse ( parsing ): javax.xml.parsers est le paquetage qui contient
un ensemble d'interfaces devant tre implmentes par les diffrents parseurs (SAX
pour Simple API for XML ou DOM). Le parseur va lire (parcourir) le fichier ou flux
XML. Les lments rencontrs peuvent tre des balises (ouvrantes ou fermantes), des
portions de texte, des commentaires ou encore des instructions.
o La transformation : javax.xml.transform est le paquetage contenant
l'ensemble des classes et interfaces ncessaires pour travailler avec XSLT
(eXtensible Stylesheet Language for Transformations). La transformation consiste soit
en une modification d'un fichier XML avec sauvegarde des modifications, soit en une
transformation en un autre type de document HTML et PDF, par exemple.

Figure 5.4 : Lditeur graphique de fichiers XML


85

I I .4 El abor at i on du gr aphe pour l e c al c ul di t i nr ai r e
I I .4.1 LAPI Masc opt (Masc ot t e Opt i mi zat i on)
Dveloppe dans le cadre du projet Mascotte lINRIA, lAPI Mascopt
(http://www-sop.inria.fr/mascotte/mascopt/ ) est un projet qui propose un ensemble
doutil pour les problmes doptimisation des rseaux comme le routage ou la
conception de rseaux. Mascopt sert limplmentation de solutions ces diffrents
problmes en proposant des librairies pour manipuler les rseaux et les graphes et
utiliser un ensemble dalgorithmes. Mascopt qui est un logiciel Open Source sous
licence GNU LGPL, gratuit, qui utilise les technologies les plus standards telles que
Java de Sun et le format XML assurant ainsi une grande portabilit. Mascopt fournit
aussi quelques outils graphiques pour afficher les rsultats des oprations sur les
graphes. Cette API nous a t dune grande utilit en offrant la possibilit de crer une
reprsentation des graphes en mmoire partir de la description de leurs diffrents
lments dans un fichier XML (avec lextension mgl). Ce fichier contient la dclaration
de tous les nuds (vertex) et de tous les arcs (arc ou edge) composs partir de ces
nuds. LAPI autorise chaque arcs avoir des valeurs de trois types de donnes
(cest largement suffisent). Les valeurs peuvent tre nombreuses est se distinguent
lune de lautre par le nom reprsentatif de cette valeur. Les nuds sont groups dans
un ensemble Vertex_Set ainsi que les arcs dans lensemble Arc_Set . La
cration du graphe orient DiGraph se fait par association de ces deux
ensembles.
La principale utilit de cette API est quelle permet de parcourir les diffrents
nuds suivant les diffrents arcs selon le schma du fichier XML ainsi que lobtention
de la valeur associe chaque arc. Dans notre cas, les nuds, les arcs
reprsenteraient respectivement les stations et les tronons. Pour les valeurs
associes aux arcs, lide tait dintroduire dabord la dure fixe de chaque tronon,
ensuite dintroduire les diffrentes lignes passant par ces arcs comme deuxime
valeur. Enfin, pour chaque ligne, nous ajoutons les horaires de passages par cet arc.
La ressemblance entre le fichier contenant linformation sur le transport et celui
contenant la description du graphe est frappante dans la dclaration des nuds et


86

des arcs, mais le dernier point constitue la diffrence. En effet, llment principal
dans le dernier fichier est les tronons alors que dans le premier ctait les lignes.

Figure 5.4 : Un fichier sous le format mgl de Mascopt (sur 2 colonnes)
I I .4.2 Gnr at i on du gr aphe
Le but de cette tche est dlaborer un programme de conversion, qui partir
du fichier XML contenant linformation sur les transports gnre un fichier dcrivant le
graphe sur lequel seffectuera le calcul ditinraires et selon le format que demande
lAPI Mascopt. Ensuite, la lecture de ce fichier par un autre programme et puis son
dploiement permet de le mettre en tat pour rpondre aux requtes envoyes par le
service SMS ou par le service Web. Il constitue pour ce dernier, le dernier lment de
la couche mtier avant daccder aux donnes reprsentes par le fichier XML. Le


87

premier lment est le programme de calcul des K chemins les plus courts (K>0) qui
sera prsent dans la prochaine section et qui est la plus importante dans tout le
processus de dveloppement. Nous avons procd une optimisation de lespace
mmoire en nautorisant la cration que dune seule instance du graphe et en
autorisant laccs asynchrone au graphe.
I I .5 Cal c ul di t i nr ai r e pour l es t r anspor t s c ol l ec t i f s
Les algorithmes du plus court chemin ont fait lobjet de nombreuses recherches
Toutefois, une grande partie des ces algorithmes sont relatifs des graphes dits
statiques, o les liens entre les noeuds ont des poids fixes. Autrement dit, le plus court
chemin est choisi de faon minimiser ou maximiser la somme des valeurs quon
associe aux arcs (par exemple distance, cot, ) : ces poids sont dits fixes car ils
sont prdfinis avant le calcul ditinraire. Mais pour un rseau de transport collectif,
ces poids peuvent dpendre de la date de dpart et ainsi ils ne sont pas fixes. Il est
ncessaire daborder le problme de la dpendance du temps pour les transports
collectifs, aussi doit-on prendre en compte une autre dimension en associant aux arcs
des valeurs qui varient selon le temps.
Etant donn que le problme tudi est reli au rseau de transport collectif,
notre recherche bibliographique a port sur le problme de calcul ditinraires dans les
rseaux routiers o le problme du chemin le plus court a une grande importance [20]
[21] [23]. Dans le contexte des rseaux de transport, plusieurs algorithmes sont
proposs mais qui dpendent troitement de la structure du rseau, du nombre de ses
nuds et de la fonction de cot utilise. Do, le meilleur algorithme peut varier selon
le graphe auquel il sapplique. Lalgorithme de Dijkstra, lun des meilleurs algorithmes
pour le calcul du plus court chemin dans un graphe o les poids des arcs sont positifs,
ne peut pas sappliquer directement au transport collectif car cet algorithme suppose
que les poids sont fixes. En effet, dans notre cas, nous associons chaque arc des
horaires de dpart variables et une dure fixes. Ce problme, plus complexe que le
premier, ncessite un algorithme adapt. Aprs une recherche bibliographique ([19]
[22] [24] [25][35] [36] [37]), nous avons trouv un algorithme dtiquetage labeling
algorithm[31], une extension de lalgorithme de Dijkstra, et qui rpond au problme.
Son principe, sous sa forme gnrale, est de partager les noeuds du rseau en deux


88

sous-ensembles : noeuds permanents et nuds temporaires. Les noeuds permanents
sont ceux pour lesquels on connat le chemin le plus court. Nous partons dune
situation initiale o tous les noeuds sont temporaires, sauf celui de dpart, et on largit
chaque tape lensemble des noeuds permanents de telle faon regrouper la fin
de lalgorithme tous les noeuds dans cet ensemble.
I I .5.1 Cal c ul des k pl us c our t s c hemi ns
Pour gnraliser le calcul prcdent, nous traitons les k plus courts chemins
sans boucles : il sagit de dterminer non seulement le chemin le plus court mais
aussi le deuxime, le troisime ... jusquau k
me
plus court chemin. Un chemin du
graphe est dit sans boucle sil ne contient ni arcs ni nuds rpts. Lutilisateur peut
aussi demander litinraire qui le satisfait le plus par rapport certains critres (par
exemple minimiser le temps de parcours ou minimiser le nombre de
correspondances). Pour choisir lalgorithme de recherche des k chemins les plus
courts nous avons procd une lecture bibliographique des principaux travaux dans
ce domaine essentiellement ceux crits par les chercheurs portugais Martins, Pascoal
et Santos ([24][36]) qui proposent plusieurs algorithmes de recherche des k
chemins les plus courts.
Les objectifs de notre algorithme sont :
(1) Permettre au systme dinformation de calculer plusieurs courts chemins.
(2) Autoriser lutilisateur dterminer le nombre de chemins planifier.
(3) Permettre lutilisateur dexprimer la classification lors du calcul ditinraires
(minimisation du temps de parcours ou celle du nombre de correspondances).
(4) Permettre lutilisateur de spcifier le moyen de transport quil dsire prendre.
(5) Lexploration de quelques mthodes doptimisation pour rduire la complexit
de lalgorithme (en temps de calcul et en espace mmoire).
En prenant en facteur la complexit de tenir en compte toutes les contraintes et les
incertitudes relatives au transport collectif, nous avons bas cet algorithme sur des
plusieurs considrations qui sappliquent au rseau de transport collectif tunisois :
(1) Pour chacune des lignes passant par un tronon, un voyageur prendra la
premire qui arrive de la ligne choisie.
(2) La capacit du moyen de transport nintervient pas dans son choix.


89

(3) Pour chaque ligne de transport, larrive dun voyageur une station, nous
pouvons prvoir larrive des prochains moyens de transport selon leurs
horaires considrs fixes. Le systme ne tient pas compte, en effet, ni de ltat
des routes ni du trafic cause de la complexit du problme.
(4) Pour chaque dpart dune ligne, son arriv prcde larrive du dpart qui le
suit.
I I .5.2 Desc r i pt i on du pr obl me
Le systme dvelopper est un systme daide au dplacement et la
planification dynamique de chemins adapt et conu pour le rseau de transport
collectif tunisois. Le systme rsout les problmes de dplacement multimodal et
multicritres. Multimodal dsigne le fait quil prend en considration les diffrents
moyens de transport et leurs interconnections. Ces moyens sont le bus, le mtro et le
train. En revanche, multicritre entend la considration de plusieurs critres de
slection et doptimisation selon le temps de parcours et le nombre de
correspondances.
Dans la Figure 5.5, si un voyageur arrive la station A lheure h et dsire se
dplacer de la source s = A la destination d= D, un chemin possible serait de
prendre le bus b1 de la station A lheure h1 (h1>=h) vers la station B, puis attendre
un certain temps t1 pour prendre le mtro m2 lheure h2 vers la station C, o il
prendra sans attendre le bus b2 lheure h3 vers la station D sa destination.

Figure 5.5 : Un exemple de planification dynamique et multimodale de voyage


90

I I .5.3 For mul at i on de l al gor i t hme des k pl us c our t s c hemi ns
Le problme des k plus courts chemins connu en anglais sous K-shortest
path problem , ou encore shortest path ranking problem est un problme
classique de rseau qui consiste dterminer une liste des k chemins avec le
minimum de cot et qui lient une paire source-destination dans un graphe donn. Pour
formuler le problme des k plus courts chemins, nous nous sommes bass sur des
dfinitions et des thormes trouvs dans des ouvrages spcialiss dans ce domaine,
essentiellement ceux de Martins. Soient N = {1, 2,, n} lensemble des noeuds et A
lensemble des arcs du graphe considr.
Etant donn :
(1) Un graphe G (N, A, c, s, t) avec c une fonction appele fonction de cot qui
associe chaque arc a A un nombre rel c(a) appel longueur ou cot ou
encore poids de larc, s le nud source et t le nud terminal ou destination
(2) Un paramtre K, qui reprsente le nombre de plus courts chemins dterminer
(3) Un ensemble de contraintes C qui dtermine lensemble des chemins Pij, sous
ensemble de lensemble de tous les chemins possibles P
ij
. Pour tout chemin
de P
ij
, C est satisfait. A noter que Si C = alors P
ij
= P
ij
.
Nous devons dterminer un ensemble S= {p
1
, p
2
, , p
K
}, tel que:
1) c(p
r
) c(p
s
), o r, s {1, 2, , K} et r > s;
2) c(p) c(p
r
), o r {1, 2, , K} et p P
ij
S;

I I .5.4 Choi x de l al gor i t hme
La premire catgorie pour retrouver les k plus courts chemins est celle sans
boucles. Pour cette catgorie de problmes, le meilleur algorithme tourne en un temps
O(k(m+nlogn)) dans un graphe non orient et en O(kn(m+nlogn)) dans un graphe
orient ce qui nest pas acceptable dans la pratique car m >> n >> 1 [39]. Donc, nous
nous sommes intresss la catgorie o les boucles sont autorises. Lalgorithme
dEppstein[36] propose thoriquement le meilleur temps O(m + nlogn + k) dans un
graphe orient pour rsoudre le problme mais dautres chercheurs comme Martins et
Santos[ ] proposent un algorithme en un temps dexcution O(km) et qui est prouv,
selon leur expriences, plus efficace en pratique que celui dEppstein.


91

Notre algorithme est bas sur la version du labeling algorithm propos par
Martins, Pascoal et Santos[31]. La complexit en temps dexcution et celle en
espace mmoire de cet algorithme sont tous les deux O(Km) [31]. Nous lavons
modifi pour liminer les boucles ainsi que les solutions triviales.
I I .5.5 Opt i mi sat i on
Dans la pratique, nous devons rduire la complexit de lalgorithme choisit. Une
premire constatation est celle que le nombre darcs m est gnralement trs
suprieur celui des nuds (m>>n). Une premire optimisation consiste rduire les
labels autoriss chaque nud pour quils soient infrieurs K pour diminuer
lespace mmoire allou. En effet, la quantit importante despace mmoire dans
lalgorithme est due lensemble des labels de chaque nud qui sont stocks
dans une pile et qui ne se suppriment pas aprs la fin du traitement. Cette
modification a rduit la complexit en espace mmoire de O(Km) O(Kn).
I I .5.6 El i mi nat i on des sol ut i ons t r i vi al es
Il est possible que les solutions obtenues par lalgorithme suivent le scnario
suivant : supposons que le bus b1 et le bus b2 ont des stations communes s1, s2 et
s3 et que le chemin optimal est de prendre b1 dabord puis descendre dans s2 et
prendre b2. Une autre solution consiste prendre b1 jusqu s2 puis b2 jusqu la
destination. De mme, le troisime chemin consiste effectuer le transfert en s3.
Dans ce cas, du point de vue de lalgorithme les solutions sont correctes mais de point
de vue de lutilisateur ceci na pas de sens car les trois solutions ont la mme
articulation des moyens de transport. La solution que nous apportant est de prendre
en considration que lusager ne descendra pas du moyen de transport courant pour
prendre un autre qui passe par les mmes stations que le premier.
Un autre point assez important est celui de vrifier dabord sil ny pas de lien
direct entre la source et la destination ou encore une correspondance entre deux
lignes qui relient la source la destination avant dentreprendre le calcul [20].
I I .5.7 I mpl ment at i on de l al gor i t hme
Le pseudo-code de lalgorithme de recherch des K plus courts chemins que
nous avons implment est illustr dans la figure. Pour des raisons de clart
llimination des solutions triviales et les tests sur le nombre de labels ne figurent pas.


92


/* Initialisation*/
s source
t - destination
N ensemble des nuds
A ensemble des arcs
c la fonction de cot
K nombre de chemins
h fonction qui associe chaque label le nud correspondant
h
-1
fonction qui associe un nud les labels quil possde
X pile de priorit contenant les labels des nuds et ordonne suivant leur cot
P lensemble des chemins retrouver
p un chemin solution
pred fonction qui associe un label le label qui lui a donn naissance
elm nombre dlments traits
count
i
nombre de chemins de s i

Begin
count
i
:= 0;
forall node i N-s count
i
:=-1;
elm := 1;
h(elm) := s;
h
-1
(s):= elm;
c(elm) := 0;
X := {elm};
end
While (X )
k := lment de X avec le cot le plus rduit;
X := X-{k} ;
i := h(k) ;
if(i = t) then
p=retrouver_chemin(k)
P = P U {p} ;
end
for each arc ( i , j ) A do
if ( chemin_sans_boucle ( k, j ) =true ) then
if (count
j
= K)then
l := element de h
-1
(j)/ c(l)=max{c(x)|xh
-1
(j)} ;
c(l) := calcul_temps(l);
if(c(k)+d(i,j)<c(l)) then
c(l):= c(k)+d(i,j);
pred(l):=k;
end
if ( l X) then
X:=X U {l};
end
else
elm := elm+1;
c(elm) := c(k)+d(I,j);
pred(elm) := k;
count
j
:= count
j
+1;
h(elm) := j;
h
-1
(j):= h
-1
(j) U {elm};
end
end
end
end
end
Figure 5.6 : Algorithme de recherche des k plus courts chemins implment


93

I I .6 Di st r i but i on de l i nf or mat i on
A ce stade de dveloppement, la distribution de linformation daide au
dplacement est possible. Les choix pour lesquels nous avons opts taient
influencs dabord par les moyens daccs existants et les plus rpandus en Tunisie.
En effet, le web constitue une solution incontournable pour la distribution grande
chelle de linformation. De mme, le service SMS, depuis longtemps servait
vhiculer les informations certes plus rduites en quantit que celles vhicules sur le
web mais nanmoins pratiques dans la vie courante et sadaptant parfaitement la
mobilit du voyageur.
I I .6.1 Ser vi c e SMS
Pour dvelopper la solution SMS, nous avons choisi le protocole SMPP pour
communiquer avec le centre de messages courts SMSC. Le dveloppement de cette
solution sest bas sur limplmentation du protocole SMPP par lAPI smppapi.
I I I I . . 6 6. . 1 1. . 1 1 L L A AP PI I S SM MP PP PA AP PI I
LAPI smppapi (http://www.sf.net/projects/smppapi) est sous licence GNU Lesser
GPL (LGPL). Cette API supporte les spcificits du protocole SMPP version 3.3 et 3.4.
Elle permet lenvoi et la rception de paquets SMPP contenant les messages courts
entre le serveur dinformation et le centre de messages courts (SMSC).
I I I I . . 6 6. . 1 1. . 2 2 D De es sc c r r i i p pt t i i o on n d de e l l a ap pp pl l i i c c a at t i i o on n
Pour dployer le systme dinformation sur le rseau GSM, nous avons cr une
classe SMPPRelay qui assure la communication avec le SMSC en permettant dtablir
la connexion, denvoyer des messages courts aux utilisateurs et de recevoir les
messages courts qui nous sont destins. La communication avec le SMSC se fait sur le
port 2775 par dfaut.
Diffrents types de paquets peuvent tre changs, mais nous retenons les deux
principaux. Le premier tant de type deliver_sm qui indique un paquet livr par le SMSC
au systme dinformation. Ce paquet contiendrait ventuellement dans le champ
short_message une requte exprime par un voyageur pour laider se dplacer dune
origine une destination une heure prcise de la journe. Pour que le systme puisse
rpondre la requte, cette dernire ncessite la sparation entre les diffrents champs
qui la constituent Ainsi, nous proposons un ensemble de rgles pour exprimer les


94

requtes. En effet, les champs doivent tre spars par une virgule. Par exemple la
requte suivante : (Campus,Marsa,18:00,m) exprime la demande des voyages les plus
rapides allant du Campus universitaire la Marsa partir de dix-huit heure en mtro.
En premier lieu, la classe dtermine lorigine (essentiellement le numro) du
message court extraite du champ source_addr, la sauvegarde et effectue le traitement
de la requte. Un grand nombre de voyages ntant pas permis par le service SMS vu
la taille limite du texte chang, nous choisissons dans un premier lieu de ne retourner
que le chemin le plus rapide. Pour trouver ce chemin la classe fait appel aux mthodes
de la classe de recherche des k plus courts chemins LSKSPA pour Label Setting K-
Shortest Paths Algorithm en lui passant comme paramtre k=1, les champs source et
destination obligatoires et occasionnellement les autres champs optionnels tels que
lheure ou le moyen de transport. La rponse sera envoye lutilisateur grce au
paquet de type submit_sm contenant la rponse dans le champ short_message.
I I I I . . 6 6. . 1 1. . 3 3 V Va al l i i d da at t i i o on n d de e l l a ap pp pl l i i c c a at t i i o on n S SM MS S
Pour valider lapplication SMS, nous avons eu recours un simulateur de SMSC.
Ce simulateur est une autre API Open Source , smscsim, tlchargeable depuis
http://opensmpp.logica.com/. La figure 5.8 illustre la simulation avec les paramtres
(Campus,Marsa,18 :00,m) dcrits prcdemment.

Figure 5.7 : IHM de Gestion des donnes et Configuration du lien SMPP


95


Requte
Rponse
Figure 5.8 : Requte et rponse par SMS


96

I I .6.2 Lappl i c at i on Web

Figure 5.9 : Requte par le prototype Web

Ici laffichage des
dates darrives
Le nombre des solutions est
2 puisque le systme limine
les solutions triviales
Figure 5.10 : Rponse par le prototype Web


97

I I .7 Ac c s aux bases de donnes

Nous avons eu recours aux bases de donnes pour y stocker les vnements
lis lexploitation du systme, lhistorique des manipulations effectues (collecte de
donnes, homognisation, laboration de linformation..), les paramtres de
lapplication Web (champs statiques tels que les tables dhoraires, informations
supplmentaires) et SMS (les requtes, les numros qui les envoient et les
rponses). Afin de raliser laccs aux bases de donnes nous avons utilis le pilote
JDBC mysql-connector. Le JDBC est une API Java permettant linteraction avec des
bases de donnes relationnelles.

Conc l usi on

ans ce chapitre, nous avons essay de prsenter quelques lments de la
ralisation du systme. Ce chapitre constitue pour nous un aboutissement
de tous nos efforts fournis tout au long de llaboration du systme SIMT.
Nous avons illustr les fonctionnalits importantes du systme en choisissant
quelques interfaces graphiques et captures dcran. Les efforts fournis dans le
dveloppement nous ont pris la plus grande partie du temps, nous empchant ainsi de
finir par une tude de performance de lalgorithme et de tests auprs des usagers
pour amliorer le systme. Lalgorithme se verra sans doute amlior ainsi que le
prototype de lapplication web qui sera plus ergonomique et multifonctionnel. En
rsum, nos solutions prsentent de gros avantages puisquelles tait produites dans
lopen source de manire gratuite, en saffranchissant des cots de licences. Nous
avons aussi argument nos choix pour diffuser nos services sur une grande chelle et
faible cot, ce qui est un avnement important pour la promotion du systme SIMT.
D


98


objectif de ce projet tait de concevoir et de dvelopper le prototype dun
systme dinformation multimodale tunisien. Notre dmarche a t de partir de
ltude des besoins des usagers des transports collectifs et des systmes
dinformation existants. La deuxime tape tait de parvenir modliser les tches de
ce systme. A cette fin nous avons eu recours au processus unifi 2TUP qui, base
de diagrammes UML, nous a permis la fin de proposer un modle dynamique pour
notre systme. Le reste du travail, consistait essentiellement nous baser sur la
thorie des graphes pour modliser le rseau de transport tunisien et crer par la suite
un modle thorique pour contenir linformation sur les transports collectifs. La mise
en pratique de ce modle sest concrtise en adoptant le format XML pour
reprsenter linformation. Ltude complte de la chane dinformation depuis la
collecte jusqu la distribution nous a permis de dvelopper des outils, de proposer
des algorithmes et dexpliciter des solutions pour illustrer le fonctionnement du
systme dinformation multimodale tunisien SIMT.
Dautres amliorations restent faire pour performer le SIMT. Dun point de vue
oprationnel, les exploitants des transports collectifs devraient faciliter laccs aux
donnes et surtout quelles soient prcises. Ce qui ncessite une bonne coordination
interne aux exploitants. Dun autre point de vue fonctionnel, des tudes sur les
attentes des usagers tunisiens en matire dinformation multimodale, de la structure
mme du rseau de transport devraient se multiplier pour permettre la ralisation de
systmes performants. Enfin, dun point de vue technique, la distribution de
linformation devrait exploiter dautres technologies de communication et amliorer
laccs par les solutions existantes pour russir satisfaire un grand nombre
dusagers. Dans cette perspective, la migration vers des web services bass sur les
L
C CO ON NC CL LU US SI I O ON N
G GE EN NE ER RA AL LE E


99

changes de donnes en XML permettrait des applications industrielles de
bnficier de ces informations.
Tout au long de llaboration du projet, nous avons rencontrs plusieurs
difficults tant sur le niveau conceptuel que sur le niveau de ralisation. Mais tout de
mme, nous avons russit les surpasser pour prsenter la fin un systme
oprationnel. De plus, les apports de ce projet sont nombreux. Dabord, sur un niveau
conceptuel, le projet innove en explicitant un modle du rseau de transport collectif
tunisois. La tche tait loin dtre facile vu la complexit de modlisation des rseaux
de transport en gnral et la multitude dinformations parfois imprcises voir
manquantes.
Comme dernier mot, jespre que le travail accompli tait la hauteur de la
confiance qui tait mise en ma personne et que le prototype SIMT propos puisse tre
un guide pour le dveloppement futur de systmes dinformation multimodale tunisien.


100


BI BLI OGRAPHI E

Rfrence
Document
[1]
PREDIT (Programme de Recherche Et DInnovation dans les
Transports terrestres) AFIV Actions fdratives Intermodalit-
Voyageurs / Information-communication. Rapport final du groupe de
dfinition. Juin 2000. (http://www.atec-
tec.net/dossier/01informationvoyageurs/ aijm_inrets_guidez.pdf).

[2]

Mouloudi Assia. Identification et validation des besoins utilisateurs
en matire dinformation multimodale. Mmoire prsent pour
l'obtention d'un diplme d'Etudes Approfondies. Universit de
Technologie de Compigne. Septembre 2003.

[3]
Michel MARCHI. Information multimodale dans les transports en
commun et sur la route, spcifications fonctionnelles d'un logiciel
gnrateur de messages d'information pour l'usager. Centre
dEtudes Techniques de lEquipement mditerran (CETEM).
Novembre 2000.
(5-www.atec-tec.net/dossier/01informationvoyageurs/
aijm_inrets_guidez.pdf).

[4]
Patrick Gendre. Etude sur loptimisation des itinraires. Ministre de
lEquipement, des Transports et du Logement, Juillet 2001
www.gip-ecofor.org/ecofor/ docs/6-Pointe_Noire_01.doc.pdf

[5]

Sophie Guidez Catalan, Guillaume Uster. Recherche
institutionnelle et juridique sur linformation multimodale. Institut
National de Recherche sur les Transports et leur Scurit(INRETS),
Octobre 2000
(http://ici.application.equipement.gouv.fr/QuickPlace/predim/Main.nsf
/0C11218DA05F1A5BC1256C95002CF89E/AC24434AE75FC58EC
1256CFA0050A773/?OpenDocument)

[6]

Sylvain Belloche. Temps de parcours multimodaux. INRETS, Juin
2004


101


[7]

Patrick Gendre. Systmes dinformation multimodale, une
bibliographie commente. CERTU, dpartement Systmes. Mars 1999
(http://www1.certu.fr/catalogue/scripts/pur.asp?title_id=436&lg=0)

[8]

Nela Bhouri. Intermodalit : Bilan et perspectives des systmes
informatiques. GRETIA : Laboratoire Gnie des Rseaux de
Transport et Informatique Avance. Fvrier 2002.
(http://www.inrets.fr/ur/gretia/publication/pub_gretia.htm)

[9]

Didier Danflous. Dploiement national des systmes dinformation
multimodale, Transport Direct : lexemple anglais. CETEM, Aot 2003.

[10]
multimodale, DELFI : lexemple allemand. CETEM, Aot 2000.

[11]

multimodale, GOFAS : lexemple suisse. CETEM, Octobre 2001.

[12]

Chlo Perreau. Apports et potentialits des systmes dinformation
multimodale. PSA Peugeot-Citron, Institut dEtudes Politiques de
Paris. Janvier 2002
http://gem.sciences-po.fr/textes/tfr/thesecp.pdf

[13]
Patrick Olivero. Projet europen MOBISERVICES (MSC) centre de
mobilit. Note de synthse. ZELT CETE du Sud-Ouest.
(http://www.atec-tec.net/dossier/ 01informationvoyageurs/ID67_msc-
synth-fr.pdf)

[14]

Un plan des systmes de transport intelligents pour le canada : en
route vers la mobilit intelligente. Transport Canada, NOVEMBRE
1999
(http://www.atec-tec.net/dossier/_ameriques/TP13501F.pdf)

Pierre Pietri et Franois Olivier. Fournir une Assistance au


102

[15]
Dplacement des voyageurs. ACTIF (Architecture Cadre du Transport
Intelligent en France),
(http://www.transports.equipement.gouv.fr/
dttdocs2/fich_mti_actif_mai2004.pdf)

[16]

Stve Sfartz. Processus de dveloppement Objet et Nouvelles
Technologies. Improve, 2001
(http://www.application-servers.com/articles/
pdf/a19s.ProcessusDeDeveloppement.pdf)

[17]

Pascal Roques, Franck Valle. UML en action, de lanalyse des
besoins la conception en Java. EYROLLES, Deuxime dition 2003

[18]

Guide de choix et dusage des licences de logiciels libres pour les
administrations. ATICA Agence pour les Technologies de
lInformation et de la Communication dans lAdministration. Dcembre
2002
(http://www.adae.gouv.fr/upload/documents/guide_LL.pdf)

[19]
Xavier Gandibleux, Fr_ed_eric Beugnies, Sabine Randriamasy.
Martins' algorithm revisited for multi-objective shortest path problems
with a MaxMin cost function. Laboratoire d'Automatique, de
M_ecanique et d'Informatique industrielles et Humaines, CNRS,
Janvier 2004.
(http://www.univ-valenciennes.fr/ROI/WP/download/2004/11-2004.pdf)

[20]

Anouare Meskine, Patrick Gendre. Algorithmes et calculs ditinraires
pour linformation multimodale. CERTU, Novembre 2001.

[21]

R.K. Ahuja, J.B. Orlin, S. Pallottino, M.G. Scutelle. Minimum time and
minimum cost path in street networks with lights. Rapport
techniqueTR-99-13. 1999.
(http://citeseer.nj.nec.com/ahuja99minimum.html)


103


[22]

E.Q.V. Martins, M0M.B.Pascoal, D.M.L.D. Rasteiro et J.L.E.D
Santos.The optimal path problem. Universit de Coimbra. Juillet 1998
(http://citeseer.ist.psu.edu/martins99optimal.html)

[23]

S. Pallottino, M.G. Scutella. Shortest path algorithms in transqportation
models, classical and innovate aspects. Rapport technique. Universit
de Pise.
(http://www.citeseer.csail.mit.edu/pallottino98shortest.html)

[24]

Martins, Santos. The labeling algorithme for the multiobjective shortest
path. Universit de Coimbre. Novembre 1999.
(http://www.mat.uc.pt/~eqvm/cientificos/
investigacao/Artigos/mospp.ps.gz)

[25]

Jos Augusto de Azevedo, Joaquim Joo E. R. Silvestre Madeira,
Ernesto Q. Vieira Martins, Filipe Manuel A. Pires. A Shortest Paths
Ranking Algorithm. Proceedings of the Annual Conference AIRO'90
Operational Research Society of Italy, 1990.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/k1.ps.gz)

[26]
Ernesto Q. Vieira Martins and Jos Luis E. Santos. A New Shortest
Paths Ranking Algorithm. Investigao Operacional, 2000.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/K.ps.gz)

[27]

Ernesto Q. Vieira Martins, Marta Margarida B. Pascoal and Jos Luis
E. Santos. A New Algorithm for Ranking Loopless Paths. Research
Report, CISUC, Mai 1997.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/mps.ps.g
z)

[28]
E. Santos. The K shortest paths problem. Research Report, CISUC,
Juin 1998.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/survey.ps
.gz)

[29]
E. Santos. The K shortest loopless paths problem. Research Report,
CISUC, Juillet 1998.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/loopless.
ps.gz)



104

[30]
E. Santos. Deviation algorithms for ranking shortest paths,
International Journal of Foundations of Computer Science, 1999.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/deviation.
ps.gz)

[31]

E. Santos. Labeling algorithms for ranking shortest paths, Mars 1999.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/labeling.p
s.gz)

[32]

E. Santos. A New Improvement for a K Shortest Paths Algorithm.
Novembre 1999.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/IMP_MS.
ps.gz)

[33]

E. Santos. An Algorithm for Ranking Loopless Paths. Research
Report, CISUC, December 1999.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/MPS_nov
o.ps.gz)

[34]

Ernesto Q. Vieira Martins and Marta Margarida B. Pascoal. A New
Implementation of Yen's Ranking Loopless Paths Algorithm. October
2000.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/new_yen.
ps.gz)

[35]

Ernesto Q. Vieira Martins and Marta Margarida B. Pascoal. An
Algorithm for Ranking Optimal Paths, November 2000.
(http://www.mat.uc.pt/~eqvm/cientificos/investigacao/Artigos/rank_opti
mal.ps.gz)

[36]
David Eppstein, Finding the k Shortest Paths. Rapport technique 94-
26. University of California, Irvine, CA 92697-3425,1997

[37]
David Eppstein, Finding the k Shortest Paths. Rapport technique 94-
26. University of California, Irvine, Mai 1994.
(http://citeseer.ist.psu.edu/rd/6053549%2C254747%2C1%2C0.25%2C
Download/http://citeseer.ist.psu.edu/cache/papers/cs/10246/http:zSzz
Szwww.ics.uci.eduzSz%7EeppsteinzSzpubszSzEpp-TR-94-
26.pdf/eppstein94finding.pdf)


105

[38]
Frdric Vivien. Algorithmique avance. Avril 2002

[39]
Tan Jinsong. Research and Development of RADS-MM V2.0. Projet
de fin dtudes. School of Computing National University of Singapore
2001/2002.
(http://www.math.nus.edu.sg/~mattjs/publications/
(Jinsong%20Tan%202002)RADSMM2.pdf)

[40]
Abdouroihamane ANLI. Filtrage social pour la personnalisation de
linformation transport multimodal. ECL Lille. Juillet 2004
(http://www.ort.ec-lille.fr/Exposes/Anli.PDF)

[41]
Zidi Kamel, H. Slim, Borne Pierre. Systme daide au dplacement
multimodal. ECL Lille, Juillet 2004.

[42]
Guillaume Roche, Nicolas Villetard, Pierre Langlois (INSA Lyon),
Patrick Gendre. Prototypage dune bote outils XML pour laide
linformation multimodale. Centre dtudes sur les rseaux, les
transports, lurbanisme et les constructions publiques (CERTU),
Novembre 2001

[43]
M.A Kamoun, K. Zidi, S. Hammadi, P.Borne, Guillaume Uster.
Systme daide au dplacement multimodal. Ec-Lille.
(http://www.ort.ec-lille.fr/Exposes/Zidi_kamoun.PDF)

[44]
Yongping Liu. Conception/Ralisation dune application de rfrence
pour la mise en ligne de bases de donnes sur loffre de transports
collectifs. Thse professionnelle. Ecole Nationale des Ponts et
Chausses. Dcembre 2003.
[45]
Simon St.Laurent. Java, XML, and a New World of Open Components
April 1999.
[46]
Georges-Andr Silber. Introduction XML. Centre de Recherche en
Informatique cole des Mines de Paris
(http://www.cri.ensmp.fr/~silber)

[47]
Serge Abiteboul. XML et donnes semi-structures
(http://www-rocq.inria.fr/~abitebou/DEA-III )

[48]
Mohamed BEN AHMED. Les Logiciels Libres : enjeux, opportunits et
choix stratgique. Confrence. JTLL Tunis Dcembre 2003


106

UML : LES PROCESSUS
UNI FI ES
A n n e x e
A
I Les pr oc essus uni f i s
Un processus unifi est un processus de dveloppement logiciel construit sur UML,
il est itratif centr sur larchitecture, conduit par les cas dutilisation et pilot par les
risques. Sa gestion est organise suivant les quatre phases suivantes : pr-tude,
laboration, construction et transition.
Ses activits de dveloppement sont dfinies par cinq workflows fondamentaux
qui dcrivent la capture des besoins, lanalyse, la conception, limplmentation et le
test [16].
Tout processus UP rpond aux caractristiques ci-aprs :
Il est incrmental :
La dfinition dincrments de ralisation est en effet la meilleure pratique de
gestion des risques dordre la fois technique et fonctionnel. Nous pouvons estimer
quun projet qui ne produit rien dexcutable dans les neufs mois court un risque
majeur dchec. Chaque incrment garantit que les quipes sont capables dintgrer
lenvironnement technique pour dvelopper un produit final et fournit aux utilisateurs
un rsultat de leurs spcifications. Le suivi des incrments constitue par ailleurs un
excellent contrle des cots et des dlais
Il est pilot par les risques :
Dans ce cadre, les causes majeures dchec dun projet logiciel doivent tre
cartes en priorit. Lidentification de la premire cause provenant de lincapacit de
larchitecture technique rpondre aux contraintes oprationnelles, et une seconde
cause est lie linadquation du dveloppement aux besoins des utilisateurs est


107

ncessaire.
Il est construit autour de la cration et de la maintenance dun modle, plutt
que de la production de documents :
Le volume dinformations de ce modle ncessite une organisation stricte qui
prsente les diffrents points de vue du logiciel diffrents degrs dabstraction.
Lobtention de mtriques sur le modle fournit par ailleurs des moyens objectifs
destimation.
Il est itratif :
Chaque itration porte sur des degrs dabstraction de plus en plus prcis et
permet de produire des traces ncessaires au contrle du changement.
Il est orient composant :
Tant au niveau modlisation que production, cest une garantie de souplesse pour
le modle lui-mme et le logiciel quil reprsente. Cette pratique constitue le support
ncessaire la rutilisation logicielle et offre des perspectives de gains non
ngligeables.
Il est orient utilisateur :
La spcification et la conception sont construites partir des modes dutilisation
attendus par les acteurs du systme.
La figure B.1 prsente un comparatif entre les diffrents processus objets bass sur le
processus unifi.


108


Figure B.1 : comparatif entre les diffrents processus objets bass sur le processus unifi
I I Le 2TUP (2 Tr ac k Uni f i ed Pr oc ess)
Le 2TUP propose un cycle de dveloppement en Y, qui dissocie les aspects
techniques des aspects fonctionnels. Le processus en Y sarticule autour de 3
branches :
Une branche technique
Une branche fonctionnelle
Une branche de ralisation


109


Figure B.2 : le processus de dveloppement en Y
I I .1 La br anc he f onc t i onnel l e
Elle comporte :
La capture des besoins fonctionnels, qui produit un modle des besoins
focalis sur le mtier des utilisateurs. Elle qualifie au plutt le risque de produire un
systme inadapt aux utilisateurs. De son ct, la matrise doeuvre consolide les
spcifications et en vrifie la cohrence et lexhaustivit.
Lanalyse, qui consiste tudier prcisment la spcification fonctionnelle de
manire obtenir une ide de ce que va raliser le systme en termes de mtier. Les
rsultats de lanalyse ne dpendent daucune technologie particulire.
I I .2 La br anc he t ec hni que :
Elle comporte :
La capture des besoins techniques, qui recense toutes les contraintes et les


110

choix dimensionnant la conception du systme. Les outils et les matriels slectionns
ainsi que la prise en compte de contraintes dintgration avec lexistant conditionnent
gnralement des prs-requis darchitecture technique.
La conception gnrique, qui dfinit ensuite les composants ncessaires la
construction de larchitecture technique. Cette conception est compltement
indpendante des aspects fonctionnels. Elle a pour objectif duniformiser et de
rutiliser les mmes mcanismes pour tout un systme informatique et carte la
plupart des risques de niveau technique.
I I .3 La br anc he du mi l i eu
Elle comporte :
La conception prliminaire, qui reprsente une tape dlicate, car elle intgre le
modle danalyse dans larchitecture technique de manire tracer la cartographie
des composants du systme dvelopper.
La conception dtaille, qui tudie ensuite comment raliser chaque composant.
Ltude de codage, qui produit ces composants et teste au fur et mesure les
units de code ralises.
Ltape de recette, qui consiste enfin valider les fonctions du systme
dvelopp.


111


A n n e x e
B

I Pr sent at i on du modl e MVC :
Le modle Model-View-Controller (MVC) spare la modlisation du domaine, la
prsentation et les actions reposant sur l'entre utilisateur en trois classes distinctes :
Modl e : Le modle gre le comportement et les donnes du domaine
d'application, rpond aux demandes d'informations sur son tat (souvent issues de
la vue) ainsi qu'aux instructions de changement d'tat (souvent issues du
contrleur).
Vue : La vue gre l'affichage des informations.
Cont r l eur : Le contrleur interprte les entres clavier et souris de l'utilisateur
et informe le modle et/ou la vue des changements ncessaires.
La figure B.1 prsente les relations structurelles entre les trois objets.

Figure B.1 : Structure de classe MVC
L LE E M MO OD DE EL LE E
M MV VC C I I I I


112


Il est important de noter que la vue et le contrleur dpendent tous deux du
modle. En revanche, le modle ne dpend ni de la vue ni du contrleur. C'est l'un
des principaux avantages de la sparation. Cette sparation des tches permet de
crer et de tester le modle indpendamment de la reprsentation visuelle. La
sparation entre la vue et le contrleur est secondaire dans la plupart des applications
clientes riches. Dans les applications Web, la sparation entre la vue (le navigateur) et
le contrleur (les composants ct serveur grant les requtes HTTP) est clairement
dfinie. Le modle Model-View-Controller est un modle de conception fondamental
en matire de sparation de la logique de l'interface utilisateur et de la logique mtier.
Malheureusement, la popularit de ce modle a eu pour consquence un certain
nombre de descriptions errones. En particulier, le terme contrleur a t utilis
pour signifier diffrentes choses dans diffrents contextes. Fort heureusement,
l'avnement des applications Web a permis de rsoudre certaines ambiguts, tant la
sparation entre la vue et le contrleur est vidente.

I I Evol ut i on :
Le modle MVC s'appuie essentiellement sur la sparation en 2 couches
verticales regroupant d'un ct les objets mtiers (Modle) et de l'autre les objets
IHM, ces derniers tant eux mmes regroups en objets charges de l'acquisition
d'informations, en provenance de l'utilisateur (contrleur) et en objets charges de la
restitution d'informations vers l'utilisateur (Vue).

MVC1

Avec MVC1, Le code daccs aux donnes et le code HTML sont intgrs
dans des composants spars. Il est donc possible de rutiliser le code.
Mais : Problme de maintenance!


113


MVC2

Dans le modle MVC2, le contrleur est unique, en classe et en
instance. Il garantit l'unicit du point d'entre de l'application. Il prend en
charge une partie du contrle de l'application. Les contrleurs MVC se
retrouvent alors partiellement dports dans l'entit dynamique de
l'application qui assure le contrle de la dynamique de l'application et qui
gre les relations entre les objets mtier et la prsentation. Les contrleurs
deviennent essentiellement des contrleurs du dialogue entre l'utilisateur et
les objets mtiers.

I I I Pour quoi opt er pour MVC :
La plupart des applications web sont cres l'aide de langages procduraux tels
que ASP, PHP ou CFML avec lesquels la tentation est grande de mlanger
traitements, donnes et prsentation. MVC impose la sparation entre ces deux
parties d'une application. Bien que cette architecture ncessite un effort en amont les
rsultats peuvent tre impressionnants.
Tout d'abord, et c'est sans doute le plus important, il est possible d'avoir plusieurs
vues qui dpendent d'un seul modle. La demande de nouveaux modes d'accs
lapplication est de plus en plus forte. Une solution consiste donc utiliser MVC. Avec
MVC, il importe peu que l'utilisateur souhaite une interface Flash ou WAP; le mme
modle peut traiter l'un ou l'autre. La duplication du code est rduite car le code du
modle n'est crit qu'une seule fois puis rutilis par toutes les vues
Comme le modle renvoie les donnes sans appliquer aucune mise en forme, les
mmes composants peuvent tre utiliss et appels pour n'importe quelle interface.
La majorit des donnes peuvent par exemple tre formates en HTML, tout aussi
bien qu'en Flash ou en WML. En outre, le modle isole et gre la gestion d'tat et la
persistance des donnes.
Comme le modle est autonome et spar du contrleur et de la vue, il est
beaucoup plus facile de modifier la couche de donnes ou les rgles mtier. Si on
change de base de donnes, par exemple de MySQL Oracle, ou on modifie une
source de donnes d'un SGBDR vers LDAP, il suffit de revoir le modle. Si elle est


114

crite correctement, la vue n'aura cure que la liste d'utilisateurs provienne d'une base
de donnes ou d'un serveur LDAP. Les trois parties d'une application MVC sont des
botes noires dont le fonctionnement interne est masqu aux autres parties. Il est ainsi
possible dlaborer des interfaces bien dfinies et des composants autonomes.
Le concept du contrleur est galement bnfique. Le contrleur sert assembler
diffrents modles et vues pour satisfaire une requte. L'architecte se voit ainsi offrir
des possibilits extraordinaires.

I I I .1 Les avant ages de MVC :
Le modle MVC impose donc une sparation totale entre le traitement,
l'interface et la communication entre ses deux parties. Cela permet d'avoir non
seulement des objets rutilisables pour d'autres applications, mais aussi de pouvoir
faire voluer aisment les programmes. Ainsi, si l'on souhaite modifier une base de
donnes il suffit de revoir le "model " et cela est valable pour le cas o l'on souhaite
changer d'interface. Les trois parties du model MVC sont rellement autonomes.
Aucunes d'elles ne s'occupent du fonctionnement de l'autre. En plus dautres
avantages existent :
o Prise en charge de plusieurs vues. Comme la vue est spare du
modle et qu'il n'y a pas de dpendance directe entre eux, l'interface utilisateur peut
afficher simultanment plusieurs vues des mmes donnes. Ainsi, plusieurs pages
d'une application Web peuvent utiliser les mmes objets du modle. L'application Web
permettant l'utilisateur de modifier l'apparence des pages constitue un autre
exemple des avantages de cette sparation. Ces pages affichent les mmes donnes
partir du modle partag mais ces donnes s'affichent de diffrentes manires.
o Adaptation aux changements. Les exigences en matire d'interface
utilisateur ont tendance changer beaucoup plus rapidement que les rgles mtier.
Les utilisateurs peuvent prfrer utiliser diffrentes couleurs, polices, disposition
l'cran et plusieurs niveaux de prise en charge des nouveaux priphriques tels que
les tlphones mobiles ou les assistants personnels. Comme le modle ne dpend
pas des vues, l'ajout de nouveaux types de vues au systme ne l'affecte
gnralement pas. En consquence, le changement porte uniquement sur la vue.


115

o La fiabilit : les couches prsentation et mtier sont compltement
spares; le mtier peut changer sans ncessairement affecter la prsentation, o
rciproquement.
o La productivit : la dure du dveloppement est rduite de manire
significative, en permettant le travail en parallle des quipes
o Cots rduits de dveloppement grce la sparation fonctionnelle qui
fait que des comptences de haut niveau ne sont plus ncessaires que pour la
ralisation des certains composants des applications.

Le modle MVC reprsente un complment fort utile aux outils du
dveloppeur, quel que soit le langage utilis. MVC2 est un modle de conception bien
adapt la cration de logiciels. Ses spcificits, telles que la sparation du contenu
et de la prsentation, peuvent sembler videntes. Toutefois, en isolant le modle, de
la vue et du contrleur, il pousse rellement repenser lapplication et rflchir
intensment l'architecture.


116


Nom & prnom : Chandoul Haythem
Option : Ingnierie des rseaux
N de tlphone : 96 05 83 64
e-mail : haythem.chandoul@gmail.com
Adresse postale : Rue Haramein Charifein, 5, rsidence
illets, 2074 Mourouj

Titre du projet

Conception et dveloppement dun systme dinformation multimodale
pour les transports collectifs

Propos par

Etablissement : IsetCom.

Lieu de ralisation : Laboratoire de dveloppement de lIsetCom.

Encadrant(s) : Mhamed CHAMMAM

Mots cls : Information multimodale, transport collectif, SIM, optimisation du voyage, UML,
XML.
Rsum : Ce projet sinscrit dans le cadre de la conception et du dveloppement dun
systme dinformation multimodale (SIM) pour les usagers des transports collectifs.
A travers une tude critique des SIM existants, les spcifications du nouveau systme tunisien
(SIMT) ont t labores en tenant compte des besoins des utilisateurs.
Lunivers informationnel du systme est riche et complexe impliquant plusieurs acteurs depuis
la collecte jusqu la distribution de linformation en passant par son homognisation dans un
format unifi.
La conception du SIMT a t base sur UML facilitant la gestion du projet et garantissant la
qualit logicielle. Son dveloppement a exploit les technologies les plus standards telles que
Java et le format XML assurant ainsi une grande portabilit.
Lapport de ce projet rside essentiellement dans lexploitation de nombreuses technologies
de linformation et de communication pour faciliter la planification et loptimisation du voyage
des usagers du transport collectif.

PFE Chandoul 2005

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

PFE Chandoul 2005

Transféré par

Droits d'auteur :

Formats disponibles

RAPPORT DE PROJET DE FIN DETUDES

Vous aimerez peut-être aussi