Monia & Nesrine

Mmoire de projet denvergure
Pour lobtention de
Diplme National DIngnieur
Spcialit: Informatique Applique
Sujet
Conception et ralisation dun systme de maintenance
et de contrle des vhicules distance
Soutenu le 21 Juin 2008 par :
Nesrine HARRATH
Monia ETTOUIL
Encadr par Membres de jury
M. Ridha BOUALLEGUE M. Ridha BOUALLEGUE (Prsident)
Mme. Rim GUEDRIA
M. Lotfi HAMROUNI
Anne Universitaire 2007/2008
18 Janvier BAB JEDID 4000 Sousse, Tunisie
www.eniso.rnu.tn eniso@eniso.rnu.tn ridha.bouallegue@gnet.tn
Tel: +216 73 220 664 +216 73 220 664 665 Fax: +216 73 220 470
Projet dEnvergure Tldiagnostic des vhicules
2
3
Ddicaces
Dieu merci
mon cher pre Belgacem et ma mre Aicha,
Pour leurs soutiens moral et financier durant mes tudes,
Pour lducation et le grand amour dont ils mont entour depuis ma naissance,
Et pour leurs patiences et leurs sacrifices,
mon frre Yahia,
mes surs Najia, Lamya, Amel, Radhia et Ahlem,
ma binme Nesrine,
Ziko pour son soutien moral durant ce projet,
mes amies Mdalela, Jamila, Massaouda, Majida, Awatef et Amina
tous ceux qui mont aid,
tous ceux que jaime, tous ceux qui maiment,
Je ddie ce modeste travail.
Monia
4
Ddicaces
la mmoire de mon pre Mohamed
ma chre mre Mariouma
Pour son soutien moral durant mes tudes,
Et pour sa patience et ses sacrifices,
mon cher frre et ami Bad
Pour son soutien moral et financier tout au long de mes tudes
mon frre Imed et sa femme Zakia
tous mes frres Samyra, Sami et Otta
ma sur Leila et son mari Khaled
ma binme Monia
A mes chers Wasoula, Rabouba, Chouchou, Ouba, Douma, Souma et Hama
mes chers amies Rim, Rawzeta et Nesrine
Je ddie ce modeste travail
Nesrine
5
Remerciements
La rdaction de ce manuscrit de mmoire touche sa fin et clt un
travail tal sur deux annes.
Au terme de ce rapport de projet de fin dtude nous tenons
exprimer notre profonde reconnaissance tous ceux qui, de prs ou de
loin, nous ont aids llaboration de ce prsent travail et ont prsent
leur soutien moral.
Nous tenons ici remercier particulirement M.Bouallegue Ridha pour
son encadrement et son aide tout au long de ce mmoire pour ses
claircissements scientifiques pertinents, pour ses remarques
constructives et les recadrages indispensables tout au long de lavance
de ce projet.
Nous tenons galement souligner sa gentillesse et sa disponibilit
malgr ses nombreuses fonctions administratives.
Nous tenons de plus remercier Mme.Rim Guedria davoir aimablement
accept la charge de rapporteur, ainsi que M.Lotfi Hamrouni pour avoir
particip notre jury de mmoire.
Nous remercions galement toutes les personnes que nous avons
ctoyes ces deux annes, tout le personnel de lENISo ainsi que les
enseignants.
6
Rsum
Les garagistes ont troqu leurs cls molette contre des ordinateurs croire que coup de la
panne est devenu une stratgie de l'ingnieur informatique. Avec la multiplication des
fonctions de scurit et de confort, et les micro-ordinateurs embarqus qu'elles impliquent,
impossible dsormais de comprendre ce qui se passe sous le capot. A moins de se munir de
l'outil de diagnostic informatique adquat. Dans ce projet, nous montrerons que les systmes
mcatroniques complexes, prsentent certaines caractristiques utiles pour l'observation et la
commande. La possibilit de reprsenter le systme sous forme de sous systmes
interconnects continus, discrets ou hybrides permet d'exploiter les proprits physiques et
d'amliorer l'observabilit et la contrlabilit.
Ces informations seront utiles pour le diagnostic. La tche de diagnostic consiste dtecter
les anomalies intervenant sur un systme puis expliquer ces erreurs en indiquant les
composants pouvant tre fautifs. Elle doit tre faite distance via le rseau GPRS permettant
ainsi un mcanicien distant de superviser le vhicule, dintervenir pour rparer les
anomalies si cest possible ou bien envoyer des messages dalertes au conducteur pour
intervenir immdiatement lui-mme ou passer vers le mcanicien le plus proche. Notre
travail consiste donc raliser les trois tches suivantes :
1) Programmer le module GM862 pour pouvoir envoyer et recevoir des donnes entre le
tlmcanicien et le vhicule.
2) Programmer les modes de communication entre le kit de test et le vhicule dune part et
le kit et le rseau de communication GPRS dune autre part.
3) Crer un site web qui contient une reprsentation de notre projet sous forme de pages
web facilitant ainsi tout abonn la navigation sur le site, linscription et la dcouverte de
nos services offerts dans le domaine de diagnostic.
Mots Clef
Etat du vhicule, supervision, aide la conduite, dtection de dfauts, envoie SMS, message
dalerte, gestion et enregistrement sur une base de donnes, communication avec le module
GM862, application web, accs site.
7
Abstract
Mechanics have exchange their open-end wrenches adjustable counters computers, to
believe that blow of the breakdown became a strategy of the data-processing engineer.
With the multiplication of the functions of safety and comfort and the microcomputers
embedded that they imply impossible from now on to include/understand what occurs
under the cap. Unless providing itself with the tool for adequate data-processing diagnosis.
In this project we will show that the complex mechanic systems show certain useful
characteristics for the observation and the order. The possibility of representing the
system in the form of under systems inter-connect continuous discrete or hybrid allows to
exploit the physical properties and to improve observation and the control.
These information will be useful for the diagnosis. The diagnostic task consists in
detecting system's anomalies then in attempting to explain those errors by indicating the
components that can be faulty. It must be done at distance via network GPRS permitting so
to a distant mechanic to supervise the vehicle, to repair anomalies so this is possible or else
to send alarms to the conductor to repair it himself or to go to the mechanic the most near.
During this project, we have to make sure that the process of diagnostic is progressing
successfully. We have so three essential tasks to do:
1) To program the module GM862 for sending and receiving data.
2) To program different windows.
3) To create our site which contains a representation of our project containing pages
facilitating so looking inside the site, making the registration and discovering our services.
Keywords
State of the vehicle, supervision, help to the leadership, default detection, sending SMS,
message of alert, management and registration data bases , communication with the kit
GM862, web application, web site.
8
Sommaire
Introduction gnrale................................................................................................................................ 14
Partie1 :Prsentation gnrale du projet ............................................................................................... 16
I. Objectifs du projet .................................................................................................................................................. 17
II. Organisation, structures et mode de fonctionnement ............................................................................21
III. Les principes du projet.................................................................................................................................... 22
IV. Contexte du projet et dfinition globale des besoins.......................................................................... 22
1. Contexte du projet............................................................................................................................................. 22
2. Dfinition gnrale des besoins...................................................................................................................23
3. Planification des tches................................................................................................................................... 25
Partie 2 : Conception de lapplication .................................................................................................. 27
I. Introduction..............................................................................................................................................................28
II. Conception de la base de donnes...................................................................................................................28
1. Le modle conceptuel de donnes (MCD) ............................................................................................... 28
1.1 Introduction ........................................................................................................................................................... 28
1.2 Dmarche dlaboration du schma conceptuel de donnes............................................................. 29
1.3 Le MCD Conu........................................................................................................................................................ 30
2. Le modle physique de donnes (MPD)................................................................................................... 33
2.1 Introduction ........................................................................................................................................................... 33
2.2 Le MPD conu........................................................................................................................................................ 33
III. Conception UML................................................................................................................................................. 35
1. Dfinition............................................................................................................................................................... 35
2. Diagrammes utiliss ......................................................................................................................................... 35
2.1 Diagramme de cas dutilisation............................................................................................................... 36
2.1.1 lments des diagrammes de cas dutilisation ............................................................................36
2.1.2 Ralisation du diagramme......................................................................................................................... 38
2.2 Le diagramme de squence ...................................................................................................................... 40
2.2.1 Reprsentation des messages ........................................................................................................ 40
2.2.2 Ralisation du diagramme.................................................................................................................... 41
2.3 Diagramme de classes................................................................................................................................. 44
2.3.1 Les lments de diagramme de classe............................................................................................. 45
2.3.2 Ralisation de diagramme de classe ................................................................................................ 46
IV. Conclusion ............................................................................................................................................................ 51
Partie 3 : Ralisation de lapplication .................................................................................................. 52
9
Chapitre1 : Communication RS232 ..................................................................................................... 53
I. Gnralits sur la communication srie........................................................................................................ 53
1. La communication............................................................................................................................................. 53
2. Protocoles de communication...................................................................................................................... 53
3. Communication avec le circuit..................................................................................................................... 54
II. Module GM862+Kit dvaluation RS232....................................................................................................... 54
1. Description du module GM862.................................................................................................................... 54
1.1 Description technique ................................................................................................................................. 54
1.2 Description logicielle .................................................................................................................................. 56
2. Kit dvaluation RS232.................................................................................................................................... 57
2.1 Description de la carte................................................................................................................................ 57
2.2 Composition de la carte ............................................................................................................................. 58
3. Introduction Python...................................................................................................................................... 59
3.1 Prsentation du langage............................................................................................................................. 59
3.2 Caractristiques du langage..................................................................................................................... 59
III. Les interfaces de communication ............................................................................................................... 63
1. Interface pour les commandes AT.............................................................................................................. 64
2. Interface pour la communication srie ................................................................................................... 67
2.1. Gnralits sur le logiciel Delphi............................................................................................................67
2.2. Interface de communication .................................................................................................................... 69
Chapitre 2 : Dveloppement du site web ............................................................................................ 71
I. J2EE.............................................................................................................................................................................. 71
1. Introduction......................................................................................................................................................... 71
2. L'environnement d'excution des applications J2EE.......................................................................... 72
II. Base de donnes...................................................................................................................................................... 75
1. Introduction......................................................................................................................................................... 75
2. EasyPHP................................................................................................................................................................. 76
III. Hibernate ..............................................................................................................................................................76
1. Introduction......................................................................................................................................................... 76
2. Architecture ......................................................................................................................................................... 77
3. Utilisation dans lapplication ........................................................................................................................ 79
3.3.2 Driver basepfe .................................................................................................................................... 79
6.2 Lajout dHibernate .................................................................................................................................... 81
IV. Struts....................................................................................................................................................................... 84
1. Introduction......................................................................................................................................................... 84
2. Utilisation dans lapplication ........................................................................................................................ 85
V. JSP................................................................................................................................................................................. 87
1. Introduction......................................................................................................................................................... 87
2. Le choix entre JSP et Servlets........................................................................................................................ 87
10
3. JSP et Struts ..........................................................................................................................................................88
VI. Le site...................................................................................................................................................................... 88
Conclusion gnrale .................................................................................................................................. 97
Bibliographie ........................................................................................................................................... 99
11
Liste des figures
Figure 1: La tlmatique ............................................................................................................... 17
Figure 2: Concepts du projet : Supervision et Diagnostic des vhicules distance ..................... 18
Figure 3: Etapes de diagnostic ...................................................................................................... 20
Figure 4: Exemple de diagnostic local .......................................................................................... 21
Figure 5: Architecture du systme de tldiagnostic ................................................................... 24
Figure 6: Cycle de dveloppement en V simplifi ........................................................................ 25
Figure 7: Planification des tches du PFE sous forme du diagramme de GANT ......................... 26
Figure 8: Palette utilise pour concevoir le MCD......................................................................... 30
Figure 9: Schma conceptuel de la base de donnes ..................................................................... 32
Figure 10: tapes de gnration du modle physique de donnes ................................................ 33
Figure 11: Le MPD conu ............................................................................................................. 34
Figure 12: Palette utilise pour concevoir le diagramme de cas d'utilisation ............................... 39
Figure 13: Diagramme de Cas dutilisation de l'application web ................................................. 39
Figure 14: Diagramme des cas de la communication srie ........................................................... 40
Figure 15: Message de squence ................................................................................................... 41
Figure 16: Cration dun diagramme de squences ...................................................................... 41
Figure 17: Palette utilise pour concevoir le diagramme de squences ........................................ 42
Figure 18: Diagramme de squence du tldiagnostic .................................................................. 43
Figure 19: Diagramme de squence pour la communication PC et Module GM862 ................... 44
Figure 20: Structure d'une classe................................................................................................... 45
Figure 21: Palette utilise pour concevoir le diagramme de classes ............................................. 47
Figure 22: Diagramme de Classe du tldiagnostic ...................................................................... 51
Figure 23: Schma dun port srie ................................................................................................ 53
Figure 24: Le module GM862 GSM/GPRS.................................................................................. 55
Figure 25: Structure du systme embarqu ................................................................................... 56
Figure 26: Fonctionnement du module GM862 ............................................................................ 57
Figure 27: Le kit d'valuation RS232 et les diffrents quipements............................................ 58
Figure 28: Installation du Python .................................................................................................. 61
Figure 29: Fentre principale de Python ....................................................................................... 62
Figure 30: Fentre Hyperterminal ................................................................................................. 62
Figure 31: Insertion des paramtres de la communication srie ................................................... 63
Figure 32: Vue globale de l'interface ............................................................................................ 64
Figure 33: Interface des commandes AT ...................................................................................... 65
12
Figure 34: Configuration du module GM862 ............................................................................... 66
Figure 35: Interface pour la gestion des appels ............................................................................. 67
Figure 35: Fentre principale Delphi ............................................................................................ 68
Figure 36: Fentre principale pour envoie des donnes ................................................................ 69
Figure 37: Fentre principale la rception.................................................................................. 70
Figure 38: Architecture d'une application J2EE............................................................................ 72
Figure 40: Configuration du projet sur Tomcat ............................................................................ 74
Figure 41: page daccueil de Tomcat ............................................................................................ 74
Figure 42: Administration dEasyPHP.......................................................................................... 75
Figure 43: Base de donnes "bd_pfe" ........................................................................................... 76
Figure 44: Architecture simple dHibernate.................................................................................. 77
Figure 45: architecture complte dHibernate............................................................................... 77
Figure 46: Cration du driver "basepfe"....................................................................................... 80
Figure 47: tapes de connexion .................................................................................................... 80
Figure 52: Architecture de struts ................................................................................................... 85
Figure 53: Ajout de Struts ............................................................................................................. 86
Figure 54: Exemple du Struts-config.xml ............................................................................... 86
Figure 55: Accueil.jsp ................................................................................................................... 89
Figure 56: Prsentation de l'activit de la socit ......................................................................... 90
Figure 57: Page Notre quipe ........................................................................................................ 90
Figure 61: Formulaire pour envoie SMS....................................................................................... 93
Figure 62: Authentification de l'administrateur ............................................................................ 94
Figure 63: Formulaire d'authentification du Tlsuperviseur ....................................................... 95
Figure 64: Formulaire derreur dauthentification du Tlsuperviseur ......................................... 95
Figure 65: Page Tlsuperviseur ................................................................................................... 96
13
Liste des tableaux
Tableau 1 : Description de la classe Client ............................................................................. 47
Tableau 2 : Description de la classe Tl-superviseur ............................................................ 48
Tableau 3 : Description de la classe Technicien ..................................................................... 48
Tableau 4 : Description de la classe vhicule................................................................................ 49
Tableau 5 : Description de la classe tat ....................................................................................... 49
14
Introduction gnrale
a complexit des systmes embarqus bord des vhicules automobiles, ne cesse de
crotre, ainsi que le nombre de leurs interactions. Dans le pass, lautomobile tait
essentiellement compose de systmes lectriques et mcaniques jusqu' ce que le vhicule
devienne un outil indispensable pour la mobilit de lhomme. Lexigence de performance et les
contraintes de scurit, conjugus avec les nouvelles technologies, ont impos un niveau
dautomatisation plus performant, plus rigoureux et plus fiable.
Dans ce cadre, le diagnostic est un processus intressant de plus en plus les industriels qui
essaient la mise en uvre de compromis entre le niveau de qualit intrinsque associ aux outils
de diagnostics, et les efforts de dveloppement consacrs aux systmes proprement dits.
En effet, un processus de diagnostic peut permettre d'aider le rparateur en lui indiquant le
symptme et en lui fournissant une liste de composants pouvant expliquer le symptme. Ainsi,
cela rsulte en un gain de temps qui se rpercute par une diminution du cot de la rparation.
Le processus de diagnostic de sous-systmes automobiles devient de plus en plus difficile
assurer, et son informatisation renvoie un dfi technique encore suprieur, que ce soit sur un
mode embarqu ou dans le cadre dun atelier intgr. Cela dplace la difficult au niveau de la
production de logiciels de diagnostic, et pourrait apparatre comme un problme classique de
qualit logicielle. Nanmoins, il apparat que lintroduction des applications logicielles de
diagnostic sophistiques embarques bord de vhicules automobile, peut tre considre
comme une premire tape, mais ne saurait simposer en tant que solution fondamentale aux
problmes de diagnostic rencontrs sur les systmes actuels. Relever ce dfi technologique, et
identifier des solutions requirent une approche radicalement nouvelle base sur la
comprhension de la difficult de ce processus.
Les logiciels de diagnostic automobile ont pour mission de dtecter, prdire, localiser, et
identifier les dysfonctionnements sur les diffrents sous-systmes et permettre leur rparation et
leur remise en tat.
Cette affirmation vidente fournit les cls pour dterminer la nature des dfis relever :
L
15
o Les sous-systmes automobiles se dveloppent travers un niveau de complexit toujours
croissant, parce que leurs composants sont de plus en plus sophistiqus.
o Les sous systmes interagissent la fois travers leurs interactions physiques, mais aussi
travers lchange dinformations.
o Gnrer des logiciels de diagnostic susceptibles danticiper ces vnements devient de
plus en plus urgent, du fait des exigences croissantes sur le niveau de scurit des
vhicules, ainsi que leur impact sur lenvironnement,
o Les diffrents types de sous-systmes et de composants conduisent de multiples
dclinaisons, lies aux diffrents fournisseurs, conues pour diffrentes technologies,
renvoyant de nombreuses fonctionnalits, typologies de vhicules, versions, etc.., ce qui
ncessite de rendre compte de toutes ces variantes et dclinaisons dans le logiciel, et le
processus de dveloppement du logiciel.
Finalement, nous sommes confronts une tche complexe, dont les cots ne cessent de
crotre, du fait de ses aspects rptitifs. Puisque nous parlons de logiciels de diagnostic, le
recours des techniques dingnierie logicielle doit tre dun grand recours. Il faut suivre une
approche qui permet lexploitation et le traitement effectif de la connaissance et de linformation
concernant les technologies elles mmes, les sous-systmes physiques du vhicule, leurs
composants, ainsi que leurs structures.
Dans ce rapport, nous nallons pas seulement insister sur les ides cls et les fondements
scientifiques de notre application de diagnostic distance, mais nous montrerons galement les
diffrentes technologies utilises pour sa ralisation dans les paragraphes suivants, en prsentant
les outils informatiques et lectroniques utiliss. Finalement, nous montrons, une description
dtaille de droulement de processus de diagnostic ainsi que les diffrents messages affichs du
ct client ainsi que de ct tlmcanicien.
16
Partie1 :Prsentation gnrale du
projet
17
Partie 1 : Prsentation gnrale du projet
I. Objectifs du projet
L'avnement des technologies permettant de communiquer en temps rel avec des objets se
dplaant librement a rendu possible - et donc souhaitable le dveloppement de systmes
d'information grant des donnes "mobiles''. Cette communication est double sens. Le
dveloppement des outils de communication sans fil, notamment reprsent par l'explosion du
march des tlphones portables multiplie les changes d'informations entre units mobiles et
permet la transmission au systme central d'informations prcises sur la position, la direction, la
vitesse ainsi que ltat des objets mobiles.
Figure 1: La tlmatique
En tenant compte de ces diffrentes observations, le projet consistera dvelopper une
infrastructure de diagnostic embarque, qui permettra de suivre le comportement du vhicule, et
une infrastructure dbarque, qui permettra d'amliorer en affinant le diagnostic gnr par les
outils embarqus. Ainsi, notre projet se propose trois objectifs majeurs :
Dfinir l'architecture d'un environnement permettant le dploiement et l'excution
d'outils de diagnostic volutifs au sein du vhicule. Les langages orients objet JAVA
et Delphi ont t slectionns pour le dveloppement de l'environnement ainsi que le
langage Python pour la programmation des commandes AT.
Elaborer des mthodes formelles de diagnostic exploitants les observations effectues
en temps rel par la partie embarque.
18
Enregistrer les diffrentes donnes sur un site web afin de permettre la fois
linscription, la navigation aux diffrents clients y compris tlsuperviseurs,
conducteurs et techniciens et lexcution de la tche de diagnostic par ladministrateur
et ses partenaires.
Les diffrents objectifs de notre projet ainsi que les aspects lis au diagnostic distant peuvent tre
rsums dans le schma suivant (Figure 2) :
Figure 2: Concepts du projet : Supervision et Diagnostic des vhicules distance
Le tldiagnostic :
Le tldiagnostic par internet permet, en cas de difficult ou de panne rencontres par le
conducteur, daccder au vhicule et de procder directement au diagnostic voire deffectuer
immdiatement les mesures correctives permettant la remise en route du matriel distance.
Ceci bien sr ne pouvant seffectuer quavec accord pralable du client. Le tldiagnostic par
internet permet au tlsuperviseur davoir la visualisation instantane de ltat du vhicule et de
lensemble de donnes transmises.
19
Notre projet permet au tlsuperviseur, deffectuer un diagnostic immdiat et de remdier
instantanment au problme. Pour arriver enfin dterminer lanomalie et la rparer au niveau
du vhicule, le processus de diagnostic passe par les tapes suivantes :
1 Accueillir le client
Recueillir les informations du client et complter le contrat de rparation par
inscription du client dans notre site. Ca lui permet de choisir son tlsuperviseur.
Collecter et analyser les donnes ncessaires lintervention.
Apporter un conseil technique au client.
2 Contrler et Diagnostiquer
Vrifier les symptmes dcrits par la carte.
mettre des hypothses sur le dysfonctionnement en prenant en compte les contraintes
lies aux conditions de fonctionnement.
Mettre en scurit le vhicule et/ou ses systmes.
Slectionner les contrles, les mesures, les essais raliser.
Mesurer, contrler les caractristiques mcaniques, hydrauliques, pneumatiques et
lectriques.
Mettre en uvre un matriel daide au diagnostic.
Interprter les rsultats et identifier llment dfectueux.
Apprcier si lorigine du dysfonctionnement a pu entraner des consquences sur
dautres composants.
Dduire lintervention raliser.
3 Assurer la maintenance
Appliquer la procdure de maintenance prconise.
Dposer, reposer les organes, les lments du systme concern.
Dmonter, remonter les organes, les lments du systme concern.
Remettre en conformit les organes, les lments conformment aux procdures
constructeur.
Contrler les performances du vhicule.
Mettre en conformit le vhicule avec les normes et prconisations du constructeur.
Se tenir inform des volutions techniques.
Appliquer lautocontrle son activit.
20
4 Restituer le vhicule
Rendre compte de lintervention ralise.
Fournir les lments ncessaires la facturation.
Informer le client dventuelles interventions prvoir.
La figure ci-dessous rsume bien les tapes du diagnostic:
Figure 3: Etapes de diagnostic
Les fichiers du client peuvent tre tlchargs pour permettre une analyse rapide. Pour plus de
confidentialit, le tlsuperviseur peut galement partager les applications de son propre poste de
travail avec le conducteur client afin de lui expliquer des manipulations particulires par envoie
dun SMS. Le tldiagnostic par internet facilite lanalyse prcise et lidentification des
composants dfectueux sans dplacement sur scne. Lintervention du technicien est alors
programme en fonction de la livraison de la pice incrimine. Le dpannage est effectif ds la
premire intervention.
21
La figure ci-dessous illustre un exemple concrt de droulement de processus de diagnostic mais
localement par utilisation dun PC.
Figure 4: Exemple de diagnostic local
II.Organisation, structures et mode de fonctionnement
La premire runion tenue lanne prcdente avec notre encadreur monsieur Ridha lcole.
Nous avons ainsi exprim les premires pistes de recherches explorer car le sujet tait novateur
dans le domaine des automobiles et des communications radio. Au cours des runions suivantes,
nous avons ainsi montr que ce domaine de recherche se formalisait puisque les pistes de
recherche se sont affines, que les travaux respectifs dbouchent tous sur une application relle
(transport, contrle de ltat du vhicule, diagnostic distance, ) et que lintrt de cette
thmatique se renforce.
Suite ces rencontres, nous avons discern deux orientations de recherche :
Modlisation de la mobilit, structuration et interrogation de donnes TR (temps rel),
Architecture de Systmes dInformation TR et mobile (embarqu) et communication des
donnes TR.
Les applications vises sont :
La collection des donnes issues des diffrents calculateurs vers le circuit embarqu,
Envoie des donnes en temps rel vers un serveur distant,
Ralisation de la tche de diagnostic distante par le tlsuperviseur concern.
Durant ce semestre, nous avons abord une nouvelle solution : Remplacer le vhicule par une
interface dveloppe par loutil Delphi, qui dfinit des champs pour saisir les tats des diffrents
composants du vhicule et les envoyer par une liaison RS232 vers le module GM862. Dans ce
cas nous naurons pas besoin de comprendre ni le fonctionnement des bus CAN ni le nom de
protocole de communication.
22
III. Les principes du projet
Le projet vise dvelopper un systme dinformation intgr ddi la supervision et au
diagnostic des vhicules. Lampleur du projet et la diversit des aspects dont il traite, imposent
une mthodologie de travail rsume par quelques principes suivre tout au long des tapes de
dveloppement du projet :
Convivialit: le systme, dont nous avons conu une partie, est destin des utilisateurs
de diverses disciplines utilisant les automobiles dont une partie nest forcment
familiarise avec les outils informatiques et lectroniques intgrs lintrieur du
vhicule. Il faut donc leur offrir un systme autonome qui se charge de tout pour
transmettre linformation sur le vhicule vers le tlsuperviseur qui se charge, grce
des interfaces conviviales et simple utiliser, de superviser ltat du vhicule, en plus
linformation pertinente doit tre facilement accessible. Ainsi un travail dinterface
Homme-Machine est particulirement prsent lors du dveloppement du systme.
Portabilit: Afin de permettre un large nombre de bnficiaires daccder au systme
intgr, ce dernier doit pouvoir tre support par les diffrentes plates formes utilises.
Ainsi le dveloppement se base essentiellement sur des outils portables notamment le
langage JAVA, Delphi et loutil Easy PHP afin que le systme puisse tre utilis sur des
plates formes htrognes.
Modularit: La conception du systme repose sur le modle Orient Objet, lutilisation du
langage de programmation Oriente Objet JAVA et de loutil pour la cration de bases
de donnes Easy PHP permet de tirer profit des points forts de lOrient Objet :
rutilisation, polymorphisme.
Robustesse : Le systme intgre des logiciels de calcul puissant capables de traiter des
quantits normes de donnes, ces logiciels doivent pouvoir assurer des rsultats
efficaces et fiables.
IV. Contexte du projet et dfinition globale des besoins
1. Contexte du projet
Le projet vise dvelopper un systme dinformation intgr, comprenant plusieurs
interfaces de communication et daffichage dinformations afin de prsenter un
support daide la dcision assez complet au tlsuperviseur.
Ainsi, notre rle essentiel, dans ce projet, est de concevoir et de raliser avec les
applicatifs une plate forme capable dintgrer tous les outils de travail ncessaires la
23
supervision et au diagnostic afin de disposer dun environnement de travail organis et
complet. Notre projet denvergure sinscrit dans ce cadre.
2. Dfinition gnrale des besoins
Lindustrie automobile a connu une volution qui consiste en lintroduction massive
de llectronique sous la forme des calculateurs embarqus assurant en gnral des
fonctions de contrle, de commande et de rgulation. A cause de cette volution les
actions de rparation et de prvention deviennent de plus en plus complexes et font
appel des connaissances de plus en plus varies et labores. Des outils et des
logiciels sont dvelopps afin daider les garagistes dans lanalyse de panne et de la
rparation de ces composants lectroniques et surtout lorsque ceci se fait distance et
par internet. Comme a le conducteur ne sera plus risqu de se trouver dans une
situation grave en quelques kilomtres loin du garagiste le plus proche, il ne doit pas
craindre tout vnement urgent qui peut arriver tout instant qui peut menacer son
vhicule. Notre systme est l pour superviser ltat du vhicule et informer le
tlsuperviseur de tout vnement brusque pour intervenir. Notre systme a donc pour
rle dintgrer plusieurs sous systmes la fois htrognes et complmentaires afin
de prsenter un espace de travail puissant et complet au tlsuperviseur.
Les principales fonctionnalits de ce systme sont les suivantes :
Acquisition des donnes htrognes (donnes sur ltat du moteur, de
lallumage, vitesse, bougies, temprature..) transmis du PC vers la carte
GM862.
Transfert des donnes via le rseau GSM vers un ordinateur distant (celui du
tlsuperviseur).
Rception et organisation de ces donnes dans un site web cre par les logiciels de
dveloppement et de gestion de bases de donnes JAVA et Easy PHP.
Envoie dun message dalerte vers le conducteur dans le cas dune panne.
24
Larchitecture des diffrents sous systmes de notre application peut tre illustre par la figure
suivante :
Figure 5: Architecture du systme de tldiagnostic
A partir de ce schma, nous pouvons dire que notre systme permet de coordonner, dune part,
les diffrents composants logiciels propres lapplication entre eux, et dautre part, ces
logiciels et les autres systmes dinformations externes ou gnriques (SGBD, le modem, le
rseau GPRS).
Pour rpondre ces besoins, deux principaux objectifs ont t fix :
Le dveloppement dune application stand alone grant ces diffrents composants
logiciels et offrant un espace de travail complet aux utilisateurs.
Le dveloppement dun ensemble dinterfaces offrant des fonctionnalits quivalentes en
mode client serveur et permettant ainsi un large nombre de mcaniciens de tirer profit
de la puissance des outils de travail disponibles.
La plate forme ralise a t le dveloppement dun prototype dapplication Stand Alone
intgrant des simulateurs numriques et des composants logiciels relatifs au traitement et au
stockage des donnes ainsi qu la visualisation graphique. Ces deux besoins qui font lobjet de
notre PFE seront plus dtaills dans la partie suivante.
25
3. Planification des tches
Afin de mieux grer le droulement de notre PFE, nous nous sommes bases sur un cycle de
dveloppement en V (figure 5) ; en effet, outre la simplicit de cette approche, elle prsente
plusieurs avantages :
Meilleure dfinition des besoins.
Validation intgre et planifie du cycle de dveloppement.
Prsence de points de contrle tout au long du cycle.
Importance des tests.
Figure 6: Cycle de dveloppement en V simplifi
Dans les diffrentes tches indpendantes du projet, nous avons essay autant que peut de
respecter cette approche.
26
Le schma (Figure 7) suivant explique globalement la rpartition des diffrentes tches et leur
planification sur la dure de ralisation du projet : Nous avons commenc ds lanne prcdente
par une tude gnrale du projet : tude bibliographique et tude de lexistant. Au dbut de cette
anne nous avons commenc la conception et le dveloppement de la solution.
Figure 7: Planification des tches du PFE sous forme du diagramme de GANT
27
Partie 2 : Conception de lapplication
28
Partie 2: Conception de lapplication
I. Introduction
Dans ce chapitre, nous allons faire la conception de notre application. Le premier chapitre sera
consacr la conception de la base de donnes, le deuxime sera une conception UML (Le
Langage de Modlisation Unifi) vu quil est adapt toutes les phases de dveloppement et
compatible avec tout les techniques de ralisation et dfini plusieurs type de digrammes dont
trois sont les plus utilis et finalement le troisime chapitre prsente la ralisation de
lapplication.
II.Conception de la base de donnes
1. Le modle conceptuel de donnes (MCD)
1.1 Introduction
Avant de construire la base de donnes et de saisir et enregistrer les donnes, il convient de
concevoir le modle conceptuel de donnes. Un modle conceptuel de donnes (MCD) est un
schma qui a pour but d'crire de faon formelle les donnes qui seront utilises par le systme
d'information. Il s'agit donc d'une reprsentation des donnes, facilement comprhensible,
permettant de dcrire le systme d'information l'aide d'entits.
Une entit est la reprsentation d'un lment matriel ou immatriel ayant un rle dans le
systme que l'on dsire dcrire. On appelle classe d'entit un ensemble compos d'entits de
mme type, c'est--dire dont la dfinition est la mme. Le classement des entits au sein d'une
classe s'appelle classification (ou abstraction). Une entit est une instanciation de la classe.
Chaque entit est compose de proprits, donnes lmentaires permettant de la dcrire.
Prenons par exemple un ordinateur de la marque DELL, un autre de la marque Siemens et un
troisime IBM. Il s'agit de 3 entits faisant partie d'une classe d'entit que l'on pourrait appeler
Ordinateur. Lordinateur DELL est donc une instanciation de la classe Ordinateur. Chaque entit
peut possder les proprits vitesse de microprocesseur, taille du disque dure et mmoire RAM
propres lui. Les classes d'entits sont reprsentes par un rectangle.
Ce rectangle est spar en deux champs :
29
le champ du haut contient le libell. Ce libell est gnralement une abrviation pour
une raison de simplification de l'criture. Il s'agit par contre de vrifier qu' chaque
classe d'entit correspond un et un seul libell, et rciproquement.
le champ du bas contient la liste des proprits de la classe d'entit
Une relation (appele aussi association) reprsente les liens smantiques qui peuvent exister
entre plusieurs entits. Une classe de relation contient donc toutes les relations de mme type
(qui relient donc des entits appartenant des mmes classes d'entit). Une classe de relation
peut lier plus de deux classes d'entit. Les classes de relations sont reprsentes par des
hexagones (ou des ellipses) dont l'intitul dcrit le type de relation qui relie les classes d'entit
(gnralement un verbe). Les cardinalits permettent de caractriser le lien qui existe entre une
entit et la relation laquelle elle est relie. La cardinalit d'une relation est compose d'un
couple comportant une borne maximale et une borne minimale, intervalle dans lequel la
cardinalit d'une entit peut prendre sa valeur :
La borne minimale (gnralement 0 ou 1) dcrit le nombre minimum de fois qu'une entit
peut participer une relation.
La borne maximale (gnralement 1 ou n) dcrit le nombre maximum de fois qu'une
entit peut participer une relation.
Un identifiant (ou encore cl de lentit) est un ensemble de proprits (une ou plusieurs)
permettant de dsigner une et une seule entit. La dfinition originale est la suivante :
L'identifiant est une proprit particulire d'un objet telle qu'il n'existe pas deux occurrences de
cet objet pour lesquelles cette proprit pourrait prendre une mme valeur. Ainsi, chaque classe
d'entit doit possder au moins un attribut identifiant, et l'ensemble de ses attributs identifiants
doivent tre renseigns la cration de l'entit.
1.2 Dmarche dlaboration du schma conceptuel de donnes
Pour laborer un schma conceptuel, il faut suivre les tapes suivantes :
Identifier les entits
Regrouper autour dune mme entit tous ces caractristiques (attribut) : dterminer
les dpendances fonctionnelles.
Choisir la cl de type entit.
Identifier les relations entre les entits
30
Des vnements du mode rel font parfois intervenir plusieurs entits ce qui peut
matrialiser les relations correspondantes. Plusieurs associations peuvent tre existes
entre deux entits : un vnement peut affecter une entit ou une relation
Prciser les cardinalits
Slectionner les lments pertinents
Il nest pas ncessaire que tout les entits et les relations peroivent une image dans le
systme : il ne faut pas retenir que les attributs qui prsentent un intrt.
Dessiner le modle conceptuel de donnes :
Placer les entits qui sont en relation proximit les une des autres.
Indiquer les cardinalits.
Souligner lidentifiant.
1.3 Le MCD Conu
La base de donnes que nous allons construire couvre toutes les ressources quutilise le tl-
superviseur pour atteindre ltat du vhicule. Pour ce la nous avons utilis la palette suivante :
Figure 8: Palette utilise pour concevoir le MCD
Entit
Association
Lien dassociation
Hritage
31
Pour raliser les classes suivantes :
client
Cette classe contient toutes les informations concernant les clients, tel que numro de la carte
didentit qui sera la cl primaire de celle-ci.
Tl superviseur
Puisque le tl-superviseur, pour ladministrateur de lapplication, nest autre quun client, cette
classe sera hrite de la classe prcdente. Chaque tl-superviseur doit avoir un mot de passe
pour accder son compte.
Technicien
Comme le tl-superviseur, le technicien est un client qui doit avoir son mot de passe.
vhicule
Cette classe couvre les diffrents types de vhicules diagnostiqus ou pas. Cette classe sera
identifie par le numro du matricule.
tat
On peut dire que cette classe est la plut importante dans la base de donnes puisquelle contient
ltat de chaque vhicule.
32
1,1
1,n
0,n
1,n
1,1
0,n
1,1
1,1
0,n
1,n 0,n
0,n
0,n
1,1
cl i ent
ci n_cl i ent
nom_cl i ent
prenom_cl i ent
adresse_cl i ent
emai l _cl i ent
tel ephone_cl i ent
gsm_cl i ent
<pi > Enti er
Texte
Texte
Texte
Texte
Texte
Texte
<O>
ci n_cl i ent <pi >
vehi cul e
matri cul e_veh
nature
date_di ag
<pi > Texte
Texte
Date
<O>
matri cul e_veh <pi >
tel esupervi seur
ci n_tel esup
nom_tel esup
prenom_tel esup
adresse_tel esup
emai l _tel esup
tel ephone_tel esup
gsm_tel esup
motPass_tel esup
<pi > Enti er
Texte
Texte
Texte
Texte
Texte
Texte
Texte
<O>
ci n_tel esup <pi >
techni ci en
ci n_tech
nom_tech
prenom_tech
adresse_tech
emai l _tech
tel ephone_tech
gsm_tech
motPass_tech
<pi > Enti er
Texte
Texte
Texte
Texte
Texte
Texte
Texte
<O>
ci n_tech <pi >
possede
avoi r
gerer_di stance
i nscri re
contacter
i nscri re1
gerer_di rect
Etat
code_etat
etat_eau
etat_hui l e
etat_carburateur
etat_roues
etat_pompe-a-essence
etat_Bougi
etat_Feux-avant
etat-Feux-arri re
etat_al ternateur
etat_al l umage
<pi > Numri que
Texte
Texte
Texte
Texte
Texte
Texte
Texte
Texte
Texte
Texte
<O>
code_etat <pi >
Figure 9: Schma conceptuel de la base de donnes
33
2. Le modle physique de donnes (MPD)
2.1 Introduction
Le MPD dfinit la configuration physique de la base de donnes et permet d'en connatre les
dtails. Ce modle prend en compte la fois les structures de stockage du logiciel et celles des
donnes.
2.2 Le MPD conu
Aprs la ralisation du modle conceptuel de donnes loutil AMC Power Design permet de
gnrer automatiquement le modle physique de donnes, aprs le passage par ces tapes :
Figure 10: tapes de gnration du modle physique de donnes
Une fois nous choisissons les paramtres du diagramme MPD, nous obtenons le modle ci-
dessous :
34
FK_VEHICULE_POSSEDE_CLIENT
FK_ETAT_AVOIR_VEHICULE
FK_VEHICULE_GERER_DIS_TELESUPE
FK_CLIENT_INSCRIRE_TELESUPE
FK_TECHNICI_INSCRIRE1_TELESUPE
FK_GERER_DI_GERER_DIR_TECHNICI
FK_CONTACTE_CONTACTER_CLIENT
FK_GERER_DI_GERER_DIR_VEHICULE
FK_CONTACTE_CONTACTER_TECHNICI
cl i ent
ci n_cl i ent
ci n_tel esup
nom_cl i ent
prenom_cl i ent
adresse_cl i ent
emai l _cl i ent
tel ephone_cl i ent
gsm_cl i ent
i nteger
i nteger
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
<pk>
<fk>
vehi cul e
matri cul e_veh
ci n_cl i ent
ci n_tel esup
nature
date_di ag
l ong varchar
i nteger
i nteger
l ong varchar
date
<pk>
<fk1>
<fk2>
tel esupervi seur
ci n_tel esup
nom_tel esup
prenom_tel esup
adresse_tel esup
emai l _tel esup
tel ephone_tel esup
gsm_tel esup
motPass_tel esup
i nteger
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
<pk>
techni ci en
ci n_tech
ci n_tel esup
nom_tech
prenom_tech
adresse_tech
emai l _tech
tel ephone_tech
gsm_tech
motPass_tech
i nteger
i nteger
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
<pk>
<fk>
Etat
code_etat
matri cul e_veh
etat_eau
etat_hui l e
etat_carburateur
etat_roues
etat_pompe-a-essence
etat_Bougi
etat_Feux-avant
etat-Feux-arri re
etat_al ternateur
etat_al l umage
numeri c
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
l ong varchar
<pk>
<fk>
contacter
ci n_cl i ent
ci n_tech
i nteger
i nteger
<pk,fk1>
<pk,fk2>
gerer_di rect
ci n_tech
matri cul e_veh
i nteger
l ong varchar
<pk,fk1>
<pk,fk2>
Figure 11: Le MPD conu
35
III. Conception UML
1. Dfinition
Pour programmer une application, il ne convient pas de se lancer directement dans lcriture du
code : il faut dabord organiser les ides, les documenter, puis organiser la ralisation en
dfinissant les modules et les tapes de la ralisation. Cest cette dmarche antrieure lcriture
que lon appelle modlisation ; son produit est un modle. Le langage UML est en train de
devenir un langage de modlisation universel. UML permet un change standardis depuis la
rdaction d'un cahier des charges fonctionnel, du le travail raliser par les architectes et
dveloppeurs. En effet, la notation unifie dfinit des diagrammes nombreux et dune lecture
aise pour reprsenter les diffrents points de vue de modlisation.
Ainsi, chaque organisation est libre de choisir le processus qui lui semble le plus adapt en
fonction du type d'applications dveloppes, des habitudes de ses dveloppeurs ou encore de leur
niveau de maturit objet. De fait, UML nest pas proprement parler une mthode mais un
support versatile adaptable de nombreuses mthodes de dveloppement.
2. Diagrammes utiliss
Il est impossible de donner une reprsentation graphique complte dun logiciel, ou de tout autre
systme complexe, de mme quil est impossible de reprsenter entirement un statu ( trois
dimensions) par des photographies ( deux dimensions). Mais il est possible de donner sur un tel
systme des vues partielles, analogues chacune une photographie dun statu, et dont la
conjonction donnera une ide utilisable en pratique sans risque derreur grave. UML 2.0
comporte ainsi treize types de diagrammes reprsentant autant de vues distinctes pour
reprsenter des concepts particuliers du systme dinformation. Ils se rpartissent en deux grands
groupes :
Diagrammes structurels ou diagrammes statiques (UML Structure) :
diagramme de classes (Class diagram)
diagramme dobjets (Object diagram)
diagramme de composants (Component diagram)
diagramme de dploiement (Deployment diagram)
diagramme de paquetages (Package diagram)
diagramme de structures composites (Composite structure diagram)
Diagrammes comportementaux ou diagrammes dynamiques (UML Behavior) :
36
diagramme de cas dutilisation (Use case diagram)
diagramme dactivits (Activity diagram)
diagramme dtats-transitions (State machine diagram)
diagrammes dinteraction (Interaction diagram) :
diagramme de squence (Sequence diagram)
diagramme de communication (Communication diagram)
diagramme global dinteraction (Interaction overview diagram)
diagramme de temps (Timing diagram)
Ces diagrammes, dune utilit variable selon les cas, ne sont pas ncessairement tous produits
loccasion dune modlisation. Les plus utiles pour la matrise douvrage sont les diagrammes de
cas dutilisation, dactivits, de classes, dobjets, de squence et dtats-transitions. Les
diagrammes de composants, de dploiement et de communication sont surtout utiles pour la
matrise duvre qui ils permettent de formaliser les contraintes de la ralisation et la solution
technique.
2.1 Diagramme de cas dutilisation
Le diagramme de cas dutilisation reprsente la structure des grandes fonctionnalits ncessaires
aux utilisateurs du systme. Cest le premier diagramme du modle UML, celui o sassure la
relation entre lutilisateur et les objets que le systme met en uvre.
2.1.1 lments des diagrammes de cas dutilisation
Acteur
Un acteur est lidalisation dun rle jou par une personne externe, un processus ou une chose
qui interagit avec un systme. Il se reprsente par un petit bonhomme avec son nom inscrit
dessous.
37
Cas dutilisation
Un cas dutilisation est une unit cohrente dune fonctionnalit visible de lextrieur. Il ralise
un service de bout en bout, avec un dclenchement, un droulement et une fin, pour lacteur qui
linitie. Un cas dutilisation modlise donc un service rendu par le systme, sans imposer le
mode de ralisation de ce service et se reprsente par une ellipse et optionnellement, au-
dessus du nom, un strotype.
Relation
Relation dinclusion
Un cas A inclut un cas B si le comportement dcrit par le cas A inclut le comportement du cas
B, le cas A dpend de B. Lorsque A est sollicit, B lest obligatoirement, comme une partie de A.
Cette dpendance est symbolise par le strotype include .
Relation dextension
On dit quun cas dutilisation A tend un cas dutilisation B lorsque le cas dutilisation A peut
tre appel au cours de lexcution du cas dutilisation B. Excuter B peut ventuellement
entraner lexcution de A : contrairement linclusion, lextension est optionnelle. Cette
dpendance est symbolise par le strotype extend
Relation de gnralisation
Un cas A est une gnralisation dun cas B si B est un cas particulier de A. Cette relation de
gnralisation/spcialisation est prsente dans la plupart des diagrammes UML et se traduit par
le concept dhritage dans les langages orients objet.
38
2.1.2 Ralisation du diagramme
Aprs avoir tudi la conception UML nous avons pass la ralisation. Au dbut nous avons
cre, par loutil Sun Java Studio Enterprise 8.1 , un nouveau projet de type UML.
Ensuite, nous avons cre un diagramme de cas dutilisation
Dans la conception cas dutilisation, nous avons utilis les outils qui sont prsents ci dessus.
39
Figure 12: Palette utilise pour concevoir le diagramme de cas d'utilisation
Ceci nous permet de concevoir le diagramme des cas de notre application web ainsi que de la
communication srie entre le PC et le module GM862:
Figure 13: Diagramme de Cas dutilisation de l'application web
40
Conducteur Tlsuper viseur
Supevision du vhicul e
Dtection de pannes
Envoie SMS
rpartion de dfaut
Figure 14: Diagramme des cas de la communication srie
2.2 Le diagramme de squence
Le diagramme de squence reprsente la succession chronologique des oprations ralises par
un acteur. Il indique les objets que lacteur va manipuler et les oprations qui font passer dun
objet lautre.
2.2.1 Reprsentation des messages
Un message dfinit une communication particulire entre des lignes de vie. Plusieurs types de
messages existent, les plus communs sont :
lenvoi dun signal
linvocation dune opration
La cration ou la destruction dune instance.
Graphiquement, un message synchrone se reprsente par une flche en traits pleins et
lextrmit pleine partant de la ligne de vie dun objet expditeur et allant vers celle de lobjet
cible. Ce message peut tre suivi dune rponse qui se reprsente par une flche en pointill.
41
La cration dun objet est matrialise par une flche qui pointe sur le sommet dune ligne de
vie. La destruction dun objet est matrialise par une croix qui marque la fin de la ligne de vie
de lobjet.
Figure 15: Message de squence
2.2.2 Ralisation du diagramme
Cette fois nous choisissions Sequence Diagram :
Figure 16: Cration dun diagramme de squences
Pour obtenir le diagramme de squence souhait, nous devons utiliser les outils dcrits sur la
figure suivante :
42
Figure 17: Palette utilise pour concevoir le diagramme de squences
Toute cette dmarche a t conue pour atteindre enfin ce diagramme qui reprsente une vue
claire sur le passage de linformation entre le Tlsuperviseur, le systme et la carte pour faire le
diagnostic dun
vhicule..
43
Tl superviseur
1 : Ouvrir sit e Web
2 : Demande de mot de pass e
3 : sais ir mot de pass e
5 : Vrification
6 : Menu pri ncipale
4 : Connecter la
base de donnes
Si le mot de pass e
es t incorrect e al ler
au 3
Si le mot de pas se
est correcte pass er
7 : Saisir les paramtres
du client et du s on vhi cul e
8 : Enreg l es paramtres dans la BD
9 : Vrifier code t at
10 : Enreg les dans l a BD
Client :
Carte GM 862
13 : Message de la rponse
11 : Consult er la carte t ravers le rseau GPRS
14 : Corriger les pannes
12 : Voir mmoire
Si t at dfect ueux et les
pannes peuvent corriger
dist ance : 14
Si tat dfect ueux et
les pannes ne peuvent
pas corriger a dis tance :15
15 : Informer le technicien
16 : Contacter le client
et corri ger les pannes
Technicien
Administrateur :
Base de donnes
Si pas des
problmes : 17
17 : Enregi strer les informat ions du rapport
Figure 18: Diagramme de squence du tldiagnostic
44
Concernant le diagramme de squence modlisant la communication entre le PC et le module
GM862, il est prsent comme suit.
PC Module GM862 Conducteur/ Client
envoie donnes
ecouter
indicati ondenouveau texte
ouverturede port srie
fermeture
du port
enregistrement
des donnes
fermet ure de
le connexion srie
envoie des donnes
vers le serveur web
enregistrement
dans unebase
de donnes
envoie SMS
Serveur web
Figure 19: Diagramme de squence pour la communication PC et Module GM862
2.3 Diagramme de classes
Le diagramme de classes est considr comme le plus important de la modlisation oriente
objet, il est le seul obligatoire lors dune telle modlisation. Alors que le diagramme de cas
dutilisation montre un systme du point de vue des acteurs, le diagramme de classes en montre
la structure interne. Il permet de fournir une reprsentation abstraite des objets du systme qui
vont interagir ensemble pour raliser les cas dutilisation. Il est important de noter quun mme
objet peut trs bien intervenir dans la ralisation de plusieurs cas dutilisation.
Les cas dutilisation ne ralisent donc pas une partition des classes du diagramme de classes. Un
diagramme de classes nest donc pas adapt (sauf cas particulier) pour dtailler, dcomposer, ou
45
illustrer la ralisation dun cas dutilisation particulier. Il sagit dune vue statique car on ne tient
pas compte du facteur temporel dans le comportement du systme. Le diagramme de classes
modlise les concepts du domaine dapplication ainsi que les concepts internes crs de toutes
pices dans le cadre de limplmentation dune application. Chaque langage de Programmation
Orient Objets donne un moyen spcifique dimplmenter le paradigme objet (pointeurs ou pas,
hritage multiple ou pas, etc.), mais le diagramme de classes permet de modliser les classes du
systme et leurs relations indpendamment dun langage de programmation particulier. Les
principaux lments de cette vue statique sont les classes et leurs relations : association,
gnralisation et plusieurs types de dpendances, telles que la ralisation et lutilisation.
2.3.1 Les lments de diagramme de classe
classe
Une classe est la description formelle dun ensemble dobjets ayant une smantique et des
proprits communes. Elle est reprsente par un rectangle divis en trois cinq compartiments,
Le premier indique le nom de la classe, le deuxime ses attributs et le troisime ses oprations.
Nom de l a cl asse
A tt r ibu t_ 1 : in t
A tt r ibu t_ 2 : Str i ng
M t h ode_1 (ar g_1 , ar g_ 2)
M t h ode_2 (ar g_1 , ar g_ 2, ar g_ 3)
Figure 20: Structure d'une classe
Les attributs
Les attributs dfinissent des informations quune classe ou un objet doivent connatre. Ils
reprsentent les donnes encapsules dans les objets de cette classe. Chacune de ces informations
est dfinie par un nom, un type de donnes, une visibilit et peut tre initialis. Le nom de
lattribut doit tre unique dans la classe.
Le type de lattribut (<Type>) peut tre un nom de classe, un nom dinterface ou un type de
donn prdfini. La multiplicit (<multiplicit>) dun attribut prcise le nombre de valeurs que
lattribut peut contenir.
Association
Une association est une relation entre deux classes (association binaire) ou plus (association
n-aire), qui dcrit les connexions structurelles entre leurs instances.
46
Multiplicit ou cardinalit
La multiplicit associe une terminaison dassociation, dagrgation ou de composition dclare
le nombre dobjets susceptibles doccuper la position dfinie par la terminaison dassociation.
Voici quelques exemples de multiplicit :
Exactement un : 1 ou 1..1
Plusieurs : _ ou 0.._
Au moins un : 1.._
De un six : 1..6
2.3.2 Ralisation de diagramme de classe
Pour la ouverture dun nouveau diagramme, nous avons utilis la mme procdure que celle du
digramme de squence sauf quand mais Class Diagram au lieu de Sequence Diagram .
Nous utilisons les outils suivants pour construire le diagramme final :
47
Figure 21: Palette utilise pour concevoir le diagramme de classes
a. Liste des classes
Classe client : cette classe permet la gestion des diffrents clients du tlsuperviseur
(ajout, suppression, enregistrement).
Attribut Description Type
cin_client Numro de la carte didentit de chaque client
Integer
cin_telesup CIN du tlsuperviseur integer
nom_client Nom du client String
prenom_client Prnom du client String
adresse_client Numro de tlphone du client String
email_client Ladresse lectronique du client String
telephone_client Le numro du tlphone du client Number
gsm_client Le numro du GSM du client Number
Tableau 1 : Description de la classe Client
48
Classe Tl-superviseur : cette classe reprsente le tlsuperviseur du
tldiagnostic.
cin_telesup CIN du tlsuperviseur
Integer
nom_telesup Nom du tlsuperviseur String
prenom_telesup
Prnom du tlsuperviseur
String
adresse_telesup Adresse du tlsuperviseur String
email_telesup Email du tlsuperviseur String
telephone_telesup Tlphone du tlsuperviseur Number
gsm_telesup Gsm du tlsuperviseur Number
motPasse_telesup Reprsente le mot de passe du tl-superviseur String
Tableau 2 : Description de la classe Tl-superviseur
Classe Technicien : cette classe reprsente le technicien.
cin_tech CIN du technicien
integer
nom_tech Nom du technicien String
prenom_tech Prnom du technicien String
adresse_tech Adresse du technicien String
email_tech Email du technicien String
telephone_tech Tlphone du technicien Number
gsm_tech Gsm du technicien Number
motPasse_tech Reprsente le mot de passe du technicien String
Tableau 3 : Description de la classe Technicien
49
Classe vhicule : cette classe permet la gestion des diffrents types de vhicule
(ajout, suppression, enregistrement).
matricule_veh La matricule du vhicule String
cin_client CIN du client integer
nature Nature du vhicule (exp : BMW) string
date_diag Date de diagnostic du vhicule Date
Tableau4 : Description de la classe vhicule
Classe tat : cette classe contient les diffrents tats diagnostiquer, nous allons
prsenter dans le tableau ci-dessous quelques chantillons :
code_etat code de ltat a diagnostiqu
String
etat_eau Bon ou dfectueux String
date1 Date de ltat de leau Date
etat_huile Bon ou dfectueux String
date2 Date de ltat de lhuile Date
etat_carburateur Bon ou dfectueux String
date3 Date de ltat du carburateur Date
etat_roues Bon ou dfectueux String
date4 Date de ltat des roues Date
etat_pompe-a-essence Bon ou dfectueux String
date5 Date de ltat de pompe essence Date
etat_bougies Bon ou dfectueux String
date6 Date de ltat des bougies Date
Tableau5 : Description de la classe tat
b. Rgle de relation
50
Un client possde un ou plusieurs vhicules.
Un vhicule est associ un seul client.
Un client ne peut sinscrire que chez un et un seul tl-superviseur
Un tl-superviseur peut avoir un n clients.
Un technicien ne peut sinscrire que chez un et un seul tl-superviseur.
Un tl-superviseur peut avoir un n techniciens.
Un vhicule peut avoir un ou plusieurs tats.
Un tat est associ un seul vhicule.
Un tl-superviseur peut grer distance 0 n vhicules.
Un vhicule ne peut tre gr distance que par un et un seul tl-superviseur.
Un technicien peut grer en direct 0 n vhicules.
Un vhicule peut tre gr en direct par 0 n technicien.
Un technicien peut contacter 0 n clients.
Un client peut tre contact par 0 n technicien.
c. Reprsentation
Une fois nous crons les tables utiliser, les champs relatifs chaque table et les relations entre
les diffrentes classes ou objets, nous obtenons le diagramme de classes ci-dessous qui dcrit la
relation entre les diffrents membres concerns par le processus de diagnostic : Client, Vhicule,
Etat, Technicie et, Tlsuperviseur.
51
Cli ent
CIN_Cl ient : int
Nom_Client : String
Prnom_Cli ent : Stri ng
Email _Cl ient : St ring
Adresse_Client : String
Tl phone_Cli ent : number
GSM_Cli ent : number
Ajouter (cin,nom, pr, emai l,adre,tl, gsm)
Modifier (ci n,nom, pr,emai l,adre,tl,gsm)
Suppri mer (ci n)
Rechercher ( cin)
Vhicul e
Matricule_Vh : Stri ng
Nat ure : String
Dat e_Di ag : Date
Ajouter (mat_vh, nat ure)
Modi fier (mat_vh, nature, date_diag)
Supprimer (mat_vh)
Rechercher ( mat_vh)
Possde
1.. n
1..1
Etat
Code_tat : St ri ng
Etat_eau : Stri ng
Etat_huil e : St ring
Etat_carburat eur : String
Etat_roues : St ring
Etat_pompe-a-essence : String
Etat_bougis : St ring
Etat_feux-avant : String
Etat_feux-arri re : String
Etat_al ternat eur : String
Etat_al lumage : Stri ng
Enregist rer ()
Modi fier ( code_etat )
Avoir
1. .n
1..1
Technicien
MotPasse_technicien : Stri ng
Ajouter (ci n,nom, pr,email,adre,tl,gsm, mot PassTech)
Connecter (nom, mot PassTech)
1.. 1
0..n
Grer direct
Hri te 1
Hrite 2
Informer
0. .n
0..n
1. .1
0..n
Inscrire
1..n
0..n
Contacter
1. .1
0..n
Tl suprviseur
Mot Passe_tlsupervi seur : String
Ajout er (cin,nom, pr,email ,adre,tl,gsm, motPassTl)
Connect er (nom, mot PassTl)
Grer distance
Figure 22: Diagramme de Classe du tldiagnostic
IV. Conclusion
La phase de conception, comme lindique son nom, permet de tracer le squelette global de
lapplication. La phase suivante sera une mise en ouvre de cette dernire.
52
Partie 3: Ralisation de lapplication
Chapitre 1 : Communication RS232
Chapitre 2 : Dveloppement du site web
53
Chapitre1 : Communication RS232
I. Gnralits sur la communication srie
1. La communication
Le programme doit effectuer une requte pour envoyer ltat du vhicule en temps rel vers le
port srie du PC. Le port RS232 se compose de 9 broches.
Deux broches sont utilises :
Une broche qui permet lcriture : requte
Une broche pour la lecture : lecture
Pour notre application, nous nallons utiliser que la broche destine lcriture, pour envoyer des
donnes sur ltat des diffrents composants du vhicule.
Figure 23: Schma dun port srie
2. Protocoles de communication
Lcriture des informations se fait sur une seule broche. Les informations duplex sont transmises
sous forme doctets. Chaque requte commence par ladresse du circuit code sur 7 bits.
Les 4 premiers bits sont invariants, ils dfinissent ladresse du circuit.
Les 3 derniers identifient le circuit dans un rseau.
Un dernier bit gnr par le PC indique le sens dans lequel seffectuent les informations.
54
Chapitre1: Communication RS232
3. Communication avec le circuit
Nous devons prciser ladresse du circuit avec lequel nous voulons communiquer. Lorsque le
circuit sidentifie comme le destinataire dune requte (7 premiers bits), il renvoie un signal au
PC qui indique quil est prt communiquer avec lui. Ensuite, le PC envoie le reste de sa
requte, et attend si besoin une rponse.
Prsentons tout dabord le circuit avec lequel nous travaillons :
II. Module GM862+Kit dvaluation RS232
1. Description du module GM862
1.1 Description technique
Ce module OEM (Original Equipement Manufactures), est un GSM/GPRS "Quad-bande" va
nous permettre de raliser un transmetteur dalarme GSM sans fil exprimental. Pour ce faire
nous utiliserons un module GSM/GPRS GM862 "Quad-band" capable de supporter les
modes de communication "voix", "fax", "Data", "SMS". Il est spcialement conu pour la
ralisation d'applications de contrle de commandes distance et opre dans les bandes 850 /
900 / 1800 et 1900 MHz. Il est dot dun :
Connecteur "MMCX" pour antenne externe et
Lecteur de carte SIM intgr,
Connecteur MOLEX pour le raccordement notre platine
Ce dernier se caractrise par ses faibles dimensions associes un prix trs comptitif et une
grande simplicit de mise en uvre. Ce module se pilote au moyen dune liaison srie via des
commandes "AT" et Caractris par :
Alimentation: 3,4 4,2 V (3,8 V nominal)
Consommation: < 3,5 mA
Consommation moyenne en mode voix (250 mA)
Liaison srie 1200 57600 bps
Connecteur d'antenne 50 ohm
55
Voice limage du module GM862 que nous allons utiliser dans notre application.
Figure 24: Le module GM862 GSM/GPRS
Afin de simplifier la ralisation, on aura recours une platine de test spcialement conue pour
pouvoir integrer le module GSM GM862 . Cette platine comprend un tage de rgulation
ainsi quun tage de mise en forme du signal de sortie du module GSM (afin que les niveaux
logiques de celui-ci soient compatibles avec une liaison RS232. Il nous suffira alors de connecter
une alimentation cette platine, une antenne au module GSM et dutiliser un cble pour le
relier au connecteur dans vhicule. La dernire opration indispensable consistera se munir
bien videmment dune carte SIM oprationnelle que lon aura insr (hors alimentation)
dans le module GM862 grce au connecteur prvu cet effet. Le code PIN de la carte
SIM devra tre effac afin de simplifier la procdure dutilisation du module GSM.
La figure ci-dessous prsente larchitecture complte de notre systme embarqu, ainsi que les
diffrents modes dinstallation.
Avant de commencer utiliser le module il faut bien placer les composants sur le kit
dvaluation srie comme le montre la figure ci-dessous :
56
Figure 25: Structure du systme embarqu
1.2 Description logicielle
Le script python interagit avec le terminal de donnes : le module GM862 travers 4 interfaces,
possdant chacune des fonctionnalits bien dtermines.
a. Linterface MDM
Linterface MDM est la plus importante. Elle permet au script python denvoyer des commandes
AT, de recevoir des rponses et des alertes, denvoier des donnes travers le rseau et recevoir
des donnes venant du rseau pendant la connexion. Elle joue le mme rle que linterface de
ports srie, la seule diffrence est que cette interface nest pas une interface de ports srie rels,
mais une interface interne.
57
b. Linterface SER
Elle permet au script python de lire et crire sur le port srie physique rel, dans lequel on trouve
linterface des commandes. On peut lutiliser pour crire des scripts python, lorsquil nest pas
utilis pour crire ou envoyer des commandes AT
c. Linterface GPIO
Elle permet au script python de manipuler des entres sorties de faon plus rapide que les commandes.
d. Linterface MOD
Elle contient la liste des fonctions utilises.
La figure ci-dessous dcrit en quelque sorte linteraction entre les diffrents modules.
Figure 26: Fonctionnement du module GM862
2. Kit dvaluation RS232
2.1 Description de la carte
Cette carte est un quipement lectronique adapt et pouvant tre install sur tout type de
vhicules. Il est dot dune mmoire pour le stockage des donnes de diagnostic du vhicule et
un module de communication radio GSM/GPRS. Elle permet la localisation en temps rel des
dfauts dans les vhicules par lecture partir dun port srie et le transfert de ces informations
un site distant de gestion.
58
Grce ses fonctionnalits avances de gestion et de traitement rapide des donnes, cette
dernire permet aux mcaniciens doptimiser leurs oprations et de donner de la valeur ajoute
leurs activits.
Le kit dvaluation permet lintgration des diffrents composants comme lindique la figure ci-
dessous.
Figure 27: Le kit d'valuation RS232 et les diffrents quipements
2.2Composition de la carte
Le connecteur DB9
Le connecteur DB9 est une prise analogique, comportant 9 broches, de la famille des
connecteurs. Il sert essentiellement dans les liaisons sries, permettant la transmission de
donnes asynchrone selon la norme RS-232 (RS-232C). Il fait linterface entre llectronique du
module de gestion et lenvironnement externe que constitue le circuit lectrique de la voiture et
les capteurs embarqu dans la voiture dans notre cas il assure la liaison avec le PC. Il assure la
gestion et la coordination.
Le module GM 862
Ce module, qui tait dj dcrit si dessous (section 2.2), gre les diffrentes tches ralises par les
autres modules.
Antenne GSM/GPRS
Cble RS232
Alimentation
Bouton reset
59
Rgulateur
Il permet de fournir une tension continue bien stable pour une large plage de courant de sortie.
Les rsistances
Elles permettent de la protection des Leds, en limitant le courant qui les parcourt 10mA.
Les capacits
Elles sont des composants passifs de filtrage associs au rgulateur et lhorloge pour le
dcouplage des hautes frquences.
Les 2 diodes
Pour lutter contre la chute de la tension de 1.2 V parce que le module GM862 est aliment de 3.8
V ainsi que pour la protection.
3. Introduction Python
3.1 Prsentation du langage
Python est un langage portable, dynamique, extensible, gratuit, qui permet (sans l'imposer)
une approche modulaire et oriente objet de la programmation. Python est dvelopp depuis
1989 par Guido van Rossum et de nombreux contributeurs bnvoles.
3.2 Caractristiques du langage
Dtaillons un peu les principales caractristiques de Python, plus prcisment, du langage et de
ses deux implantations actuelles:
Python est portable, non seulement sur les diffrentes variantes d'Unix, mais aussi sur les
OS propritaires: MacOS, BeOS, NeXTStep, MS-DOS et les diffrentes variantes de Windows.
Python est gratuit, mais on peut l'utiliser sans restriction dans des projets commerciaux.
Python convient aussi bien des scripts d'une dizaine de lignes qu' des projets
complexes de plusieurs dizaines de milliers de lignes.
60
La syntaxe de Python est trs simple et, combine des types de donnes volus
(listes, dictionnaires,...), conduit des programmes la fois trs compacts et trs lisibles.
Python gre ses ressources (mmoire, descripteurs de fichiers...) sans intervention du
programmeur, par un mcanisme de comptage de rfrences.
Python est (optionnellement) multi-thread.
Python est orient-objet. Il supporte l'hritage multiple et la surcharge des oprateurs.
Dans son modle objets, et en reprenant la terminologie de C++, toutes les mthodes sont
virtuelles.
Python intgre, comme Java ou les versions rcentes de C++, un systme d'exceptions,
qui permet de simplifier considrablement la gestion des erreurs.
Python est dynamique (l'interprteur peut valuer des chanes de caractres reprsentant
des
expressions ou des instructions Python), orthogonal (un petit nombre de concepts suffit
engendrer des constructions trs riches), rflectif (il supporte la mta programmation, par
exemple la capacit pour un objet de se rajouter ou de s'enlever des attributs ou des mthodes,
ou mme de changer de classe en cours d'excution) et introspectif (un grand nombre d'outils
de dveloppement, comme le debugger ou le profiler, sont implants en Python lui-mme).
Python possde actuellement deux implmentations. L'une, interprte, dans laquelle les
programmes Python sont compils en instructions portables, puis excuts par une machine
virtuelle. L'autre gnre directement du bytecode Java.
La bibliothque standard de Python, et les paquetages contribus, donnent accs une
grande varit de services : chanes de caractres et expressions rgulires
Ce logiciel est indispensable pour lexcution de notre application, grce ce logiciel nous
pouvons crire des scripts et les implmenter directement sur le module telle que envoie
SMS .
61
Figure 28: Installation du Python
62
Figure 29: Fentre principale de Python
Pour pouvoir bien faire fonctionner le module GM862 nous avons besoin dautres lments aussi
indispensable pour son bon fonctionnement, tel que lHyperTerminal, a permet de visualiser les
commandes ainsi que les rponses venant du module.
Figure 30: Fentre Hyperterminal
63
Figure 31: Insertion des paramtres de la communication srie
III. Les interfaces de communication
Nous avons utilis deux types dinterfaces pour pouvoir communiquer avec le module GM862,
lune est bien une interface pour les commandes AT, qui sont des commandes comprhensibles
par le module et lautre pour remplacer la prsence du vhicule. Avant de pouvoir faire
communiquer le module avec le rseau GSM, il ya des tapes suivre pour configurer,
enregistrer et identifier le module, pour quil soit enregistr dans un rseau local bien dtermin.
Nous avons fix :
Le port de communication entre le module et le PC
La vitesse de transmission des donnes ou le dbit.
Detection du rseau
Insertion du code PIN et PUK de la carte SIM : cette tape nest pas ncessaire lorsquon
a plus de code PIN insr dans la carte.
64
1. Interface pour les commandes AT
Figure 32: Vue globale de l'interface
Le module GM862 permet laccs au rseau GPRS (GSM 900 / 1800 / 1900) avec une
interface RS232 au niveau CMOS et avec des commandes AT. Cest la vrai solution pour des
applications sans fil distante. Ca permet une communication machine avec machine et la
communication de donnes distantes pour toutes les applications. Il offre tous les avantages de
la technologie GPRS.
Zone
message
Zone
photo
Zone
Email
Zone
musique
Zone
batterie
Gestion
du temps
65
Il permet des transferts de type:
Audio
SMS
Data/Fax
Des services GSM supplmentaires: Enregistrement des appels, attente des appels, CLIP,
CLIR, USSD, regroupement des appels
Autres caracteristiques
Gestion de SIM Phonebook, FDN, clock temps rel, gestion de lalarme, SIM Toolkit classe 2
Figure 33: Interface des commandes AT
Zone daffichage
Commande/Rponse
Zone des
commandes
Choix
du port
Choix de
la vitesse
Insertion de la
commande
Barre de menus
66
Grce cette interface, nous pouvons saisir les paramtres dinitialisation du module comme : le
choix du port, choix de dbit qui est fixe pour le module et gale 115200 , configuration de
ltat du rseau
Les rponses du module sont soit par OK, soit par donn de la valeur de la commande.
Des exemples de rponses du module sont donns sur la fentre suivante :
Figure 34: Configuration du module GM862
67
Le module offre plusieurs choix dutilisation, nous pouvons par exemple appeler quelquun
grce cette fentre, il suffit dinsrer le numro de lexpditeur.
Figure 35: Interface pour la gestion des appels
2. Interface pour la communication srie
Nous avons conu une interface principale assez simple et facile utiliser, par lutilisation du
logiciel Delphi, qui est un outil de programmation puissant et simple utiliser pour crer des
applications sous Windows.
2.1.Gnralits sur le logiciel Delphi
Delphi est un environnement de dveloppement intgr propritaire (IDE) pour le langage
Pascal sous Windows. Il implmente une version oriente objet du langage Pascal.
Lenvironnement de dveloppement sappuie sur un diteur dinterface graphique associ un
diteur de code source.
68
Il doit son succs sa facilit dutilisation pour dvelopper des applications graphiques et/ou
lies aux bases de donnes. La figure ci-dessous montre la fentre principale du logiciel.
Figure 36: Fentre principale Delphi
Nous avons prsent les diffrents composants du vhicule : Carburateur, Alternateur, Eau,
Huile, Roue, Pompe essence, Feux avant, Feux arrire, Allumage et Bougies sous forme de
composants graphiques dfinis en Delphi. Ces composants sont :
TButton : les boutons pour les deux lments Configurer, Ouvrir , Fermer,
Envoyer .
TEdit : les champs texte pour saisir l Etat , la Date et le message.
69
2.2. Interface de communication
Pour pouvoir recevoir et envoyer des donnes, il faut tout dabord configurer le port utiliser
pour la communication. Dans notre application nous avons utilis COM 1 , il faut l ouvrir
pour commencer le transfert des donnes puis une fois le transfert est achev il faut le fermer.
Pour tester le bon fonctionnement de notre interface, nous lavons utilise pour la
communication entre deux PCs. Et voici les deux interfaces la rception et lmission.
Pour cette premire fentre, nous allons envoyer les donnes prsentants ltat du vhicule vers
le port srie, il suffit tout simplement de remplir les champs destins l Etat et la Date ,
puis appuyer sur le bouton envoyer .
Figure 37: Fentre principale pour envoie des donnes
70
A la rception, les donnes seront affiches sur la zone noire de la fentre suivante : ils
correspondent aux donnes remplies lors de lenvoie.
Zone daffichage des messages entrants
Figure 38: Fentre principale la rception
71
I. J2EE
1. Introduction
J2EE est une plateforme fortement oriente serveur pour le dveloppement et l'excution
d'applications distribues. Elle est compose de deux parties essentielles :
un ensemble de spcifications pour une infrastructure dans laquelle sexcutent les
composants crits en java : un tel environnement se nomme serveur d'application.
un ensemble d'API qui peut tre obtenues et utilises sparment. Pour tre utilises,
certaines ncessitent une implmentation de la part d'un fournisseur tiers.
Sun propose une implmentation minimale des spcifications de J2EE : le J2EE SDK. Cette
implmentation permet de dvelopper des applications respectant les spcifications mais n'est
pas prvue pour tre utilise dans un environnement de production. Ces spcifications doivent
tre respectes par les outils dvelopps par des diteurs tiers.
L'utilisation de J2EE pour dvelopper et excuter une application propose plusieurs avantages :
une architecture d'application base sur les composants qui permet un dcoupage de
l'application et donc une sparation des rles lors du dveloppement.
la possibilit de s'interfacer avec le systme d'information existant grce de nombreuses
API : JDBC, JNDI, JMS, JCA ...
la possibilit de choisir les outils de dveloppement et le ou les serveurs d'applications
utiliss qu'ils soient commerciaux ou libres.
J2EE permet une grande flexibilit dans le choix de l'architecture de l'application en combinant
les diffrents composants. Ce choix dpend des besoins auxquels doit rpondre l'application mais
aussi des comptences dans les diffrentes API de J2EE. L'architecture d'une application se
dcoupe idalement en au moins trois tiers :
la partie cliente : c'est la partie qui permet le dialogue avec l'utilisateur. Elle peut tre
compose d'une application standalone, d'une application web ou d'applets.
la partie mtier : c'est la partie qui encapsule les traitements (dans des EJB ou des
JavaBeans).
la partie donnes: c'est la partie qui stocke les donnes.
72
Larchitecture dune application J2EE ainsi que les diffrents modes dinteraction entre ces
objets sont prsents sur la figure ci-dessous :
Figure 39: Architecture d'une application J2EE
2. L'environnement d'excution des applications J2EE
J2EE propose des spcifications pour une infrastructure dans laquelle sexcutent les
composants. Ces spcifications dcrivent les rles de chaque lment et prcisent un ensemble
d'interfaces pour permettre chacun de ces lments de communiquer. Ceci permet de sparer
les applications et l'environnement dans lequel il s'excute. Les spcifications prcisent l'aide
des API un certain nombre de fonctionnalits que doivent implmenter l'environnement
d'excution. Ces fonctionnalits sont de bas niveau ce qui permet aux dveloppeurs de se
concentrer sur le logique mtier.
Pour excuter ces composants de natures diffrentes, J2EE dfini des conteneurs pour chacun de
ces composants. Il dfinit pour chaque composant des interfaces qui leur permettront de
dialoguer avec les composants lors de leur excution. Les conteneurs permettent aux applications
d'accder aux ressources et aux services en utilisant les API.
Les appels aux composants se font par des clients via les conteneurs. Les clients n'accdent pas
directement aux composants mais sollicite le conteneur pour les utiliser.
Les conteneurs
Les conteneurs assurent la gestion du cycle de vie des composants qui s'excutent en eux. Les
conteneurs fournissent des services qui peuvent tre utiliss par les applications lors de leur
excution.
73
Il existe plusieurs conteneurs dfinit par J2EE:
Conteneur web : pour excuter les servlets et les JSP.
Conteneur d'EJB : pour excuter les EJB.
Conteneur client : pour excuter des applications standalone sur les postes qui utilisent
des composants J2EE.
Les serveurs d'applications peuvent fournir un conteneur web uniquement (exemple : Tomcat) ou
un conteneur d'EJB uniquement (exemple : JBoss, Jonas, ...) ou les deux (exemple : Websphere,
Weblogic, ...). Pour dployer une application dans un conteneur, il faut lui fournir deux lments
:
l'application avec tous les composants (classes compiles, ressources ...) regroups dans
une archive ou module. Chaque conteneur possde son propre format d'archive.
un fichier descripteur de dploiement contenu dans le module qui prcise au conteneur
des options pour excuter l'application
Figure 39: dploiement du projet site_web
Une fois lapplication a t dploye, nous pouvons la trouver sur Tomcat une fois il est lanc.
74
Figure 40: Configuration du projet sur Tomcat
Le conteneur web
Le conteneur web est une implmentation des spcifications servlets er par extension JSP. Ce
type de conteneur est compos de deux lments majeur :
un moteur de servlets (servlets engine)
un moteur de JSP (JSP engine).
Les conteneurs web peuvent gnralement utiliser leur propre serveur web et tre utiliss en tant
que plugin d'un serveur web ddi (Apache, IIS, ...).
L'implmentation de rfrence pour ce type de conteneur est le projet open source Tomcat du
groupe Apache.
Figure 41: page daccueil de Tomcat
75
II. Base de donnes
1. Introduction
EasyPHP est un package WAMP, une plateforme de dveloppement Web, permettant de faire
fonctionner localement (sans se connecter un serveur externe) des scripts PHP. EasyPHP n'est
pas en soi un logiciel, mais un environnement comprenant deux serveurs (un serveur web
Apache et un serveur de bases de donnes MySQL), un interprteur de script (PHP), ainsi
qu'une administration SQL PhpMyAdmin.
Il dispose d'une interface d'administration permettant de grer les alias (dossiers virtuels
disponibles sous Apache), et le dmarrage/arrt des serveurs. Il permet donc d'installer en une
seule fois tout le ncessaire au dveloppement local du PHP.
Figure 42: Administration dEasyPHP
76
Par dfaut le serveur Apache cre un nom de domaine virtuel (car local) http://127.0.0.1 ou
http://localhost.
Ainsi, quand on choisit "Web local" dans le menu d'EasyPHP, le navigateur s'ouvre sur cette
URL et affiche la page index.php de ce site qui correspond en fait au contenu du dossier www
d'EasyPHP.
2. EasyPHP
Dans notre application nous avons besoin dutiliser cet outil pour faire la gestion de la base de
donnes bd_pfe .
Figure 43: Base de donnes "bd_pfe"
III. Hibernate
1. Introduction
Hibernate est un projet open source visant proposer un outil de mapping entre les objets et des
donnes stockes dans une base de donnes relationnelle. Ce projet ne repose sur aucun standard
mais il est trs populaire notamment cause de ces bonnes performances et de son ouverture
avec de nombreuses bases de donnes.
Les bases de donnes supportes sont les principales du march : DB2, Oracle, MySQL,
PostgreSQL, Sybase, SQL Server, Interbase,
77
Hibernate a besoin de plusieurs lments pour fonctionner :
Une classe de type javabean qui encapsule les donnes d'une occurrence d'une table.
Un fichier de correspondance qui configure la correspondance entre la classe et la
table.
Des proprits de configuration notamment des informations concernant la
connexion la base de donnes.
Une fois ces lments correctement dfinis, il est possible d'utiliser Hibernate dans
le code des traitements raliser.
2. Architecture
Voici une vue de haut niveau de l'architecture d'Hibernate :
Figure 44: Architecture simple dHibernate
Mais l'architecture la plus complte et qui permet Hibernate de s'occuper des dtails est celle-
ci :
Figure 45: architecture complte dHibernate
78
SessionFactory (net.sf.hibernate.SessionFactory)
Un cache threadsafe (immuable) des mappings vers une et une seule base de donnes.
Session (net.sf.hibernate.Session)
Un objet mono-thread, dure de vie courte, qui reprsente une conversation entre l'application
et l'entrept de persistance. Encapsule une connexion JDBC. Il est utilis lors de la navigation
dans le graphe d'objets ou lors de la rcupration d'objets par leur identifiant.
Objets et Collections persistants
Objets mono-threads vie courte contenant l'tat de persistance et la fonction mtier. Ceux-ci
sont en gnral les objets de type JavaBean (ou POJOs) ; la seule particularit est qu'ils sont
associs avec une et une seule Session. Ds que la Session est ferme, ils seront dtachs et
libre d'tre utiliss par n'importe laquelle des couches de l'application.
Objets et collections
Instances de classes persistantes qui ne sont actuellement pas associes une Session. Elles ont
pu tre instancies par l'application.
Transaction (net.sf.hibernate.Transaction)
(Optionnel) Un objet mono-thread vie courte utilis par l'application pour dfinir une unit de
travail atomique. Abstrait l'application des transactions sous-jacentes qu'elles soient JDBC, JTA
ou CORBA. Une Session peut fournir plusieurs Transactions dans certain cas.
ConnectionProvider(net.sf.hibernate.connection.ConnectionProvider)
(Optionnel) Une fabrique de connexions JDBC. Abstrait l'application de la Datasource ou du
DriverManager sous-jacent.
TransactionFactory (net.sf.hibernate.TransactionFactory)
(Optionnel) Une fabrique d'instances de Transaction.
79
3. Utilisation dans lapplication
6.1 Le driver
3.3.1 Dfinition
Les pilotes JDBC actuels sont classs en quatre catgories :
Pilotes de type 1: Pilotes accdants une base de donnes par l'intermdiaire d'une autre
technologie (on parle de passerelle). Les passerelles JDBC-ODBC, permettant une
connexion via un pilote ODBC en sont l'exemple le plus courant. Le pilote convertit les
appels de donnes Java en appel ODBC valide, et les excute ensuite l'aide du pilote
ODBC
Pilotes de type 2: Pilotes d'API natifs. Il s'agit d'un mlange de pilotes natifs et de pilotes
Java. Les appels JDBC sont convertis en appels natifs pour le serveur de bases de
donnes (Oracle, Sybase, ou autres) gnralement en C ou en C++.
Pilotes de type 3: Pilotes convertissant les appels JDBC en un protocole indpendant du
SGBD. Un serveur convertit ensuite ceux-ci dans le protocole SGBD requis (modle 3
couches)
Pilotes de type 4: Pilotes convertissant les appels JDBC directement en un protocole
rseau exploit par le SGBD. Ces pilotes encapsulent directement l'interface cliente du
SGBD et sont fournis par les diteurs de base de donnes. Cette solution est prconiser
dans le cadre d'un intranet.
3.3.2 Driver basepfe
Dans notre application, nous avons utiliss un driver de type 1 mysql-connector-java-3.1.11-
bin pour crer un driver basepfe
80
Cration du driver
La cration du driver basepfe se fait comme le montre la figure suivante :
Figure 46: Cration du driver "basepfe"
Connexion la base de donnes
Aprs avoir dmarr loutil EasyPHP , nous avons suivi les tapes suivantes :
Figure 47: tapes de connexion
81
6.2 Lajout dHibernate
Lutilisation dHibernate dans notre application par loutil MyEclipse se fait comme suit :
Figure 48: Ajout Hibernate
82
Ceci permet de dterminer les spcifications dHibernate que nous allons utiliser dans notre
application : La version et le fichier o le Hibernate.cfg.xml sera installer.
Figure 49: Choix de la version dHibernate
Ensuite nous allons choisir le driver basepfe que nous avons dj cre pour raliser la
connexion la base de donnes.
83
Figure 50: Choix de driver et de package java
A la fin dexcution de toutes ces tches nous pouvons gnrer Hibernate.cfg.xml
Figure 51: Hibernate.cfg.xml
84
IV. Struts
1. Introduction
Cest une mthode de dveloppement qui fournit le minimum de rgles pour construire une
application web professionnelle (sparation des mtiers et donc des comptences)
Nous avons utilis le modle MVC: le formulaire soumet une entit controller qui distribue la
requte un composant appropri compte tenu de la logique applicative. Celle-ci gre
linteraction, avec la base de donnes et dlgue la cration de la rponse un composant dont le
but unique est de grer la prsentation.
Examinons de prs le modle MVC de Struts. ActionServlet est le cur de Struts, il contrle la
navigation au sein de la logique applicative. Une autre classe de Struts, Action, est utilise pour
accder aux objets mtiers. Lorsque lActionServlet reoit une requte du serveur dapplication
(Tomcat) il utilise une URI pour dterminer quelle Action va tre utilise pour traiter la requte.
Une Action peut par exemple valider des donnes en entre et accder la couche mtier pour
retirer de linformation dune base de donnes.
LActionServlet peut dterminer quelle ActionForm utiliser en regardant le chemin de la requte
de la manire quelle a slectionn lAction. Action ne va pas grer la prsentation mais confier
celle-ci une page JSP. Pour cela, Struts fournit une classe ActionForward qui va tre utilise
pour stocker le chemin vers une page sous un nom logique.
Une fois le processus mtier termin, lAction va slectionner et retourner un objet
ActionForward ActionServlet. Cette dernire utilisera le chemin stock dans ActionForward
pour rappeler la page et complter la rponse.
ActionForword utilise RequestDiqpacher.forward() ou httpServletResponse.sendRedirect() que
nous avons vu prcdemment pour rediriger le navigateur sur les bonnes pages .Struts rassemble
tous ces dtails dans un objet ActionMapping. Chaque ActionMapping est relatif un chemin
spcifique. ActionMapping dit quelles Actions, ActionForms et ActionForwards utiliser.
85
Le tout est dtaill dans un fichier de configuration appel Struts-config.xml. LActionServlet
lit ce fichier au dmarrage et cre une base de donnes dobjets de configuration. A lexcution
Struts se rfre aux objets crs grce ce fichier et non au fichier lui-mme.
La figure suivante illustre linteraction entre ces diffrents composants entre eux.
Figure 48: Architecture de struts
2. Utilisation dans lapplication
Pour ajouter Struts au projet, nous procdons ainsi :
86
Figure 49: Ajout de Struts
Une fois nous avons ajout Struts au projet, nous pouvons modifier le fichier Struts-
config.xml .
Figure 50: Exemple du Struts-config.xml
87
V. JSP
1. Introduction
Les JSP sont une technologie Java qui permet la gnration de pages web dynamiques.
La technologie JSP permet de sparer la prsentation sous forme de code HTML et les
traitements sous formes de classes Java dfinissant un bean ou une servlet et elle mlange la
puissance de Java ct serveur et la facilit de mise en page d'HTML ct client.
Au premier appel de la page JSP :
Le moteur de JSP gnre et compile automatiquement une servlet qui permet la
gnration de la page web.
Le code HTML est repris intgralement dans la servlet.
Le code Java est insr dans la servlet.
La servlet gnre est compile et sauvegarde puis elle est excute.
Les appels suivants de la JSP sont beaucoup plus rapides car la servlet, conserve par le serveur,
est directement excute.
Cette approche possde plusieurs avantages :
L'utilisation de Java par les JSP permet une indpendance de la plateforme d'excution
mais aussi du serveur web utilis.
La sparation des traitements et de la prsentation : la page web peut tre crite par un
designer et les tags Java peuvent tre ajouts ensuite par le dveloppeur. Les traitements
peuvent tre raliss par des composants rutilisables (des Java beans).
les JSP sont bases sur les servlets : tous ce qui est fait par une servlet pour la gnration
de pages dynamiques peuvent tre fait avec une JSP.
Les fichiers JSP possdent par convention l'extension .jsp.
2. Le choix entre JSP et Servlets
Les servlets et les JSP ont de nombreux points communs puisque une page JSP est finalement
convertie en une servlet. Le choix d'utiliser l'une ou l'autre de ces technologies ou les deux doit
tre fait pour tirer profit de chaque technologie.
88
Dans une servlet, les traitements et la prsentation sont regroups. L'aspect prsentation est dans
ce cas pnible dvelopper et maintenir cause de l'utilisation rptitive de mthodes pour
insrer le code HTML dans le flux de sortie.
De plus, une simple petite modification dans le code HTML ncessite la recompilation de la
servlet. Avec un JSP, la sparation des traitements et de la prsentation rend ceci trs facile et
automatique.
Il est prfrable d'utiliser les JSP pour gnrer des pages web dynamiques.
3. JSP et Struts
Pour le contrleur, Struts propose une unique servlet par application qui lit la configuration de
l'application dans un fichier au format XML. Cette servlet reoit toutes les requtes de
l'utilisateur concernant l'application. En fonction du paramtrage, elle instancie un objet de type
Action qui contient les traitements et renvoie une valeur particulire la servlet. Ceci lui permet
de dterminer la JSP qui affichera le rsultat l'utilisateur.
VI. Le site
Nous pouvons accder notre site par ladresse suivante : http://localhost:8082/site_web/
Nous avons conu notre site de telle sorte que ds la premire visite sur la page daccueil
prsente ci-dessous , les clients se sentent laise en navigant entre les pages. Ils peuvent avoir
grce aux diffrentes pages une ide claire sur les activits et services de notre socit.
89
Figure 51: Accueil.jsp
Nous avons conu une page pour prsenter lactivit de la socit sous la forme suivante :
90
Figure 52: Prsentation de l'activit de la socit
Si on choisit le bouton Notre quipe , le formulaire suivant saffichera :
Figure 53: Page Notre quipe
91
Si on choisit le bouton Nos clients , on obtient la page suivante qui prsente la liste des clients
qui peuvent tirer profit des services offerts par notre application :
Figure 58: Page Nos clients
La premire chose faire par ladministrateur en tant que crateur de site une fois connect est
de sauthentifier, par remplissage du formulaire suivant :
92
Figure 59: Authentification de l'administrateur
Ce formulaire lui permet daccder la page suivante : il aura les options suivantes : soit de supprimer ou
modifier un Tlsuperviseur ou Technicien, soit denvoyer un SMS dalerte pour informer le conducteur
sur ltat de son vhicule, ou bien finalement il peut faire une tude statistique sur lvolution de ltat
dun vhicule choisi.
93
Figure 60: Page administrateur
Si ladministrateur choisit denvoyer un SMS, il doit prciser les informations grce au
formulaire ci-dessous: Nom de lexpditeur, son numro et puis saisir le message envoyer dans
la zone de texte.
Figure 54: Formulaire pour envoie SMS
94
Il peut faire une gestion de ces clients : Tlsuperviseur ou bien Technicien.
Tlsuperviseur :
Un Tlesuperviseur peut accder notre site grce au formulaire ci-dessous, soit pour se
connecter et cela suppose quil est dj inscrit soit pour sinscrire et ceci la premire fois
de sa visite de notre site.
Figure 55: Authentification de l'administrateur
Dans le cas o il est dj inscrit, il est amen sauthentifier pour pouvoir grer ces propres
clients, bien sr ceci se fait par remplissage des champs : CIN et Mot de passe
95
Figure 56: Formulaire d'authentification du Tlsuperviseur
Si un des deux champs est rempli dune faon incorrecte, le formulaire suivant saffichera :
Figure 57: Formulaire derreur dauthentification du Tlsuperviseur
96
Dans le cas contraire, c'est--dire CIN et Mot de passe correctes il peut accder sa page
personnelle pour faire une gestion de ses Techniciens et ses clients grce ce formulaire :
Figure 58: Page Tlsuperviseur
Technicien
Le Technicien peut aussi sinscrire notre site, et passe par les mmes tapes que le
Tlsuperviseur, c'est--dire il peut soit sinscrire pour la premire fois, soit se connecter et
accder sa page personnelle.
Conclusion
Certes notre application ne prend pas fin avec lachvement du projet, mais elle reste ouverte
des ventuelles extensions. Afin de rendre le site plus labor, on aura pu traiter quelques points
tels que :
Sintresser plus au design et de le rendre plus ergonomique et attractif puisque notre
cible est des Tlsuperviseurs et des Techniciens.
La gestion de paiement tel que le choix de paiement par carte bancaire ou par chque ;
Hbergement de site.
97
Conclusion gnrale
Le travail que nous avons effectu consiste en le dveloppement d'un environnement total de
diagnostic de vhicules distance, compos dun site web dynamique pour envoie et rception
des donnes et dun systme embarqu pour communiquer avec le vhicule ainsi quavec le
serveur web distant. .
Notre application ainsi ralise permet dassurer la communication temps rel entre lengin
mobile et le Tlmcanicien ainsi que le droulement du processus de diagnostic.
Par le choix des concepts de dveloppement les plus rcents en matire de programmation et
d'interface utilisateur (Programmation Oriente Objets et sous Windows), nous avons labor un
produit agrable, puissant et trs extensible.
Dans ce travail, nous avons abord plusieurs problmes tels que la communication avec le
vhicule, la programmation du module GM862 pour recevoir et envoyer les donnes sous forme
d SMS et la cration dun site web interactif permettant plusieurs clients : Tlsuperviseur,
Techniciens et conducteurs de bnficier de ce service.
Nous avons utilis plusieurs technologies offerts en java pour pouvoir crer un site web
dynamique et interactif : une plate forme J2EE fortement oriente serveur qui permet une grande
flexibilit dans le choix de l'architecture de l'application, un ensemble doutils ou fichiers de
dveloppements web comme Hibernate, qui joue le rle de mapping entre les objets et des
donnes stockes dans une base de donnes, struts qui est un moyen de dveloppement
dapplications web et JSP pour la gnration de pages web dynamique.
Nous avons utilis aussi le langage orient objet Python pour la programmation de notre carte
forme de module GM862 install sur un kit dvaluation RS232 dans le but de grer la
communication avec le rseau GSM pour envoie et rception dSMS.
98
Pour des raisons de faute de temps, nous n'avons pas pu tester notre application sur un
vhicule rel, nous lavons remplac par une application sur PC dveloppe en Delphi pour
pouvoir communiquer avec le module.
Notre projet est trs extensible, la structure oriente objets des donnes permet d'ajouter de
nouveaux composants web ainsi que d'autres fonctionnalits pour communication GSM : nous
pouvons ajouter un tableau de bord au bord du vhicule pour permettre au conducteur de
naviguer sur le web et recevoir les informations par mail, de recevoir des appels au lieu des
SMS.
L'avantage d'une telle application est aussi d'tre un produit "fait maison" et non une bote noire
fournie par un organisme tranger.
99
Bibliographie
Webographie
[1] http://www.sun.com
[2] http://www.lextronic.fr
[3] http://wwwawe-communications
[4] http://www.noval-gsm.com
[5] http://www.developpez.fr
[6] http://www.codes sources.com
[7] http://www.commentcamarche.net
[8] http://www.modem-gsm.de/forum/
[9] http://www.abcelectronique.com/forum/
[10] http://www.Round-Solution.com
[11] http://www.programmez.com/forum
[12] http://www.aidewebmaster.com
[13] http://www.sourceforge.net
100
Liste des acronymes
AT Attention command
CLIP Calling Line Identification Presentation
CLIR Calling Line Identification Restriction
DTE Data Terminal Equipment
FDN Fixed Dialing Number
GPIO General Purpose Input Output
GPRS General Packet Radio Service
GSM Global System for Mobile communications
HTTP Hypertext Transfer Protocol
JSP Java Server Pages
MPD Modle Physique des donnes
MVC Modle View Controller
PLC Programmable Logic Controller
PDU Packet Data Unit
PIN Personal Identification Number
PUK Pin Unblocking Code
RAM Random Access Memory
SMS Short Message Service
TE Terminal Equipment
UML Unified Modeling Language
USSD Unstructured SS Mobile Originated Data

Monia & Nesrine

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Monia & Nesrine

Uploaded by

Copyright:

Available Formats

Mmoire de projet denvergure

You might also like

Monia &amp; Nesrine

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Monia &amp; Nesrine

Uploaded by

Copyright:

Available Formats

Mmoire de projet denvergure

You might also like

Monia & Nesrine

Monia & Nesrine