Post on 08-Oct-2015
description
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 1 / 39
DOSSIER DE CONCEPTION Projet CAR
Matre douvrage (enseignant responsable) : William BOHER-COY
Titulaire (quipe de conception) : Jonathan FAVIER
Robin HAIDER Samuel ROLLET
Date de rdaction : 27/01/2008
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 2 / 39
Sommaire
I. Domaine dapplication............................................................................................................ 4 1. Objectifs du systme ................................................................................................................4 2. Interfaces ..................................................................................................................................5
A. Interfaces Utilisateur ...........................................................................................................5 B. Interfaces Logicielles...........................................................................................................5 C. Interfaces de communication...............................................................................................6
3. Bases de donnes externes .......................................................................................................6 4. Contraintes gnrales de conception ........................................................................................6
II. Documents de rference ........................................................................................................ 7
III. Normes, standards et outils .................................................................................................. 8 1. Mthodes de conception...........................................................................................................8 2. Environnement et outils de dveloppement .............................................................................9 3. Notations utilises ....................................................................................................................9 4. Conventions de nommage ......................................................................................................10
A. Noms des applications et des packages .............................................................................10 B. Base de donnes.................................................................................................................10 C. Application ........................................................................................................................11
5. Standards de programmation..................................................................................................12
IV. Conception generale........................................................................................................... 13 1. Langages utiliss ....................................................................................................................13 2. Diagramme de dploiement ...................................................................................................14 3. Architecture des Composants.................................................................................................15
A. Architecture 5 couches pour lapplication nationale .........................................................15 B. Architecture de lapplication mobile .................................................................................17
4. Structure des donnes globales, des fichiers et des bases de donnes ...................................19 5. Stratgie de traitement des erreurs et des exceptions .............................................................19 6. Justification des choix darchitecture, des composants et du langage ...................................21
V. Conception detaillee des composants.................................................................................. 22 1. Systme dInformation...........................................................................................................22
A. Rgles de gestion...............................................................................................................22 B. Modle Mtier ...................................................................................................................23
2. Base de donnes .....................................................................................................................25 A. Modle Conceptuel de Donnes........................................................................................25 B. Modle Logique Relationnel .............................................................................................26
3. Application nationale (AN)....................................................................................................28 4. Application mobile (AM).......................................................................................................36
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 3 / 39
HISTORIQUE DES REVISIONS
Rfrence Rvision Date Auteur(s) Nature de la rvision Dossier de
Conception CAR 00 20/11/2007 Equipe de
dveloppement Version projet initiale
Dossier de Conception CAR
01 11/01/2008 Equipe de dveloppement
Conception Gnrale AN
Dossier de Conception CAR
02 27/01/2008 Equipe de dveloppement
Conception Dtaille AN et AM
REFERENCE INTERNET
http://jonathan.favier.free.fr/projets/Car/
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 4 / 39
I. DOMAINE DAPPLICATION
1. Objectifs du systme
Lobjectif de ce projet est de fournir un systme destin grer toutes les agences de location de vhicules de la socit BYRON. Ce systme contient deux applications, une application nationale (AN) installe au sige de la socit, et une application mobile (AM) installe sur des PDA.
Lapplication nationale permet aux clients de rserver un vhicule et aux agences de grer les locations et les rservations, le parc et la maintenance des vhicules, les contrats et les clients, et enfin ladministration du systme. Cette application doit tre utilisable sur lintranet de la socit ou lextrieur laide dun navigateur WEB.
Lapplication mobile installe sur des PDA (en mode connect dans lagence par liaison WiFi ), destine aux agents responsables des parcs vhicules, permet ces derniers de grer les parcs des vhicules des agences ainsi que les locations.
Architecture gnrale de lapplication CAR
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 5 / 39
2. Interfaces
A. Interfaces Utilisateur
Le systme contient deux applications, une nationale et une mobile. Linterface de lapplication nationale est une interface WEB (via un navigateur WEB tel que Internet Explorer ou Firefox) contenant des formulaires et des tableaux de donnes regroups par fonctions, le tout agenc par une navigation par onglets. Cette interface WEB permet laffichage et la saisie de donnes. Linterface de lapplication mobile sur PDA est calque sur les applications par dfaut du PDA. Il sagit galement de formulaires et de listes de donnes, plus un accs rapide la synchronisation de donnes. Cette interface prend en compte les contraintes du PDA : technologie disponible, taille de lcran, rsolution. Pour plus dinformations sur ces interfaces, se rfrer directement la charte graphique du projet CAR.
Ces deux applications comportent leur point dentre une authentification par mot de passe de lemploy (ou du client pour lAN) qui va utiliser les services proposs. En fonction de la nature de lutilisateur, des droits ou des restrictions seront configurs sur les applications.
B. Interfaces Logicielles
Les interfaces logicielles mentionnes ici sont des interfaces internes au systme.
Interface avec la base de donnes centrale : les deux applications du systme CAR doivent interagir avec la base de donnes centrale (Oracle, installe sur le serveur de base de donnes) au moyen de pilotes ddis, de manire synchronise. Cette base de donnes rassemble toutes les donnes manipules par lapplication nationale.
Interface avec chaque base de donnes mobile : lapplication mobile installe sur le PDA doit interagir avec la base de donnes embarque qui laccompagne (Oracle Lite), grce un pilote ddi.
Interface de synchronisation entre les PDA et le serveur central : tous les PDA contiennent un composant de synchronisation de donnes avec le serveur de base de donnes (et inversement).
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 6 / 39
C. Interfaces de communication
Les interfaces de communication mentionnes ici sont des interfaces internes au systme.
Interface entre le PDA et le serveur central : le PDA et le serveur central, lors des synchronisations, communiquent grce une liaison WIFI (ou une liaison USB filaire pendant la phase de dveloppement uniquement).
Interface entre le client WEB et lapplication nationale : pour accder aux donnes et aux services prsents par lapplication nationale, une connexion TCP/IP est ncessaire.
Interface entre lapplication nationale et les points daccs distants : la synchronisation entre les bases embarques des PDA et la base centrale a lieu au niveau de points daccs distants, relis eux-mmes la base de donnes centrale. La communication entre ces composants est ralise grce une connexion Internet de type TCP/IP.
3. Bases de donnes externes
Aucune base de donnes externe nest prvue pour interagir avec notre systme. Les seules bases de donnes, mentionnes prcdemment, font partie du systme concevoir.
4. Contraintes gnrales de conception
Plusieurs contraintes provenant de diffrentes sources sont prendre en compte dans la phase de conception du systme. Ci-dessous, un rcapitulatif des contraintes imposes par le matre douvrage dans le cahier des charges :
Larchitecture J2EE doit tre utilise pour lapplication nationale, avec lutilisation des composants Hibernate et Spring.
La base de donnes doit tre de type Oracle pour lapplication nationale, et la base de donnes de la partie mobile Oracle Lite. Ces bases de donnes doivent tre synchronises intervalle rgulier.
Le modle du PDA est impos/fourni par le matre douvrage. La phase de conception nest dmarre quaprs validation du modle mtier (et du
modle conceptuel des donnes) par le matre douvrage. Les rgles de document applicables ACAI dfinies comme rfrences dans le cahier
des charges doivent tre respectes tout au long de la conception. Les deux applications devront tre en franais. Les connexions aux applications du systme CAR doivent tre scurises par mot de
passe. Chaque catgorie dutilisateurs disposera de droits spcifiques.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 7 / 39
II. DOCUMENTS DE REFERENCE
Les documents suivants sont utiliser en rfrence avec la lecture de ce document :
Le Cahier Des Charges dans sa version finale : il contient les spcifications initiales des exigences du matre douvrage. Rfrence : CAR-CDC-AVIS-V01
Le Modle Mtier : il correspond au modle conceptuel des donnes, et est accompagn des rgles de gestions, des contraintes dhistorisation et de cohrence des donnes. Rfrence : CAR-MM-AVIS-V01
La Charte Graphique : elle a t tablie spcialement pour le projet CAR. Rfrence : CAR-CG-AVIS-V01
Les Maquettes des crans et leurs Cinmatiques. Rfrence : Partie clients : http://jonathan.favier.free.fr/projets/Car/AN/
Administration : http://jonathan.favier.free.fr/projets/Car/AN/connexion.html Le Dossier Dveloppeur : il contient les instructions techniques de mise en place de
lenvironnement de dveloppement et de larchitecture. Rfrence : CAR-DD-AVIS-V01
Les Rgles ACAI : elles sont t imposes par le matre douvrage dans le CDC. o ACAI-GuideErgonomie-150 o ACAI-GuidePersistance-150 o ACAI-GuideRalisation-150 o ACAI-ModleErgonomie-150
Rfrence : http://www.informatique.dgpa.equipement.gouv.fr/
Les documents suivants ont t utiliss pour amliorer les concepts introduits dans ce dossier :
Cours de Qualit (William Boher-Coy) Cours de Gnie Logiciel Appliqu et de Gnie Logiciel (William Boher-Coy) Cours de JAVA/J2EE (Yannick Tisson) Projets MPM, Pharmatica et CAPT (projets scolaires mens lESIL en 2006-2007)
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 8 / 39
III. NORMES, STANDARDS ET OUTILS
1. Mthodes de conception
Les mthodes de conception sont utilises afin damliorer la qualit de la conception finale.
La mthode de conception MERISE a t utilise pour mettre en place le Modle Mtier du systme, le Modle Conceptuel de Donnes (MCD), le Modle Logique de Donnes (MLD) pour aboutir enfin au script de gnration de la base de donnes. Ces diffrents modles ont t crs grce lenvironnement de conception WinDesign de la socit Cecima.
Les recommandations ACAI en terme de modlisation et de conception-ralisation dapplications (documents applicables) ont constitu des rfrences pour les phases danalyse et de conception du projet . Elles peuvent tre vues comme un ensemble de bonnes pratiques permettant dorienter larchitecture et les choix techniques du systme. Rfrence : ACAI-GuideModlisation-150
La norme IEEE 1471 (2000) reprsente galement une source de recommandations importante en ce qui concerne larchitecture en 5 couches de lapplication nationale. Elle prconise ainsi lutilisation intensive de vues et notamment le Modle-Vue-Contrleur (MVC cf. Dossier Dveloppeur) utilis par la couche Client.
Les designs patterns sont utiliss pour amliorer larchitecture du logiciel. Ce sont des modles de conception rutilisables qui rpondent des problmatiques courantes de conception indpendamment de tout langage. Ces modles de conception fournissent un support fort pour la mise en oeuvre de principes chers l'approche par objets : la flexibilit, la rutilisabilit, la modularit, la maintenabilit
Rfrence : Catalogue Sun des design patterns appliqus J2EE (accs public) http://java.sun.com/j2ee/blueprints/design_patterns/catalog.html
Concernant llaboration du systme, un style de conception ascendante (ou bottom-up ) a t choisi. Cette approche permet de sappuyer sur un modle mtier valid par le matre douvrage, puis de le transfrer rapidement en modle objet. Elle permet galement dintgrer les frameworks et larchitecture en couches, dans loptique de fournir des composants rutilisables et autonomes.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 9 / 39
2. Environnement et outils de dveloppement
Le matriel de dveloppement utilis est une machine prpare pour chaque dveloppeur, quipe de Windows XP Professionnel et dune quantit suffisante de mmoire vive (le minimum a t fix 1Go pour avoir une qualit de dveloppement acceptable, en partie en raison des nombreux services excuter).
Les trois membres de lquipe de dveloppement excutent les applications du projet CAR sur leurs propres machines. La base de donnes Oracle est situe sur une quatrime machine personnelle ayant le rle de serveur central. Quatre machines sont donc ncessaires pour le dveloppement du projet.
Concernant lapplication nationale articule sur la plate-forme J2EE, loutil de dveloppement Eclipse est mis disposition de lquipe de dveloppement. Les environnements de dveloppement qui interviennent dans la conception et le dveloppement du systme sont Hibernate et Spring. Concernant lapplication mobile sur PDA, la technologie J2SE est utilise dans lenvironnement de dveloppement Eclipse.
La base de donnes Oracle est manipule et teste grce loutil SQL Developer (lors de la phase de dveloppement, un ensemble de donnes tests est utilis afin davoir un support convenable pour les diffrents services crer). Lenvironnement de conception WinDesign est quant lui utilis pour la ralisation des modles et pour la gnration du script de cration de la base de donne et des tables associes.
La gestion de configuration est effectue sur un serveur FTP pour la documentation crite et les composants sources (classes, scripts, fichiers de configurations, pages WEB).
Rfrence : http://jonathan.favier.free.fr/projets/Car/
Pour plus dinformations sur lensemble des outils et technologies utilises dans ce projet, se rfrez directement au Dossier Dveloppeur ou au Dossier de Gestion de Configuration.
3. Notations utilises
La terminologie utilise dans le projet CAR est disponible dans le Cahier Des Charges. Les acronymes qui sont les plus couramment utiliss sont AN (application nationale CAR) et AM (application mobile pour PDA). Les conventions suivantes seront utilises pour les schmas de modlisation : normes UML 1.5 et conventions MERISE.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 10 / 39
4. Conventions de nommage
Ces conventions concernent les rpertoires et dossiers, des entits spcifiques dans les applications du systme CAR (classes, variables, packages, entits de fichiers de configuration) et dans la base de donnes (tables, champs). Ces conventions respectent les conventions de codage prcises en annexe dans le document ACAI-GuidePersistance-150.
A. Noms des applications et des packages
Le systme complet sappelle CAR . Chaque application possde un nom spcifique qui permet de lidentifier dans le systme (AN pour Application Nationale, AM pour Application Mobile). Les packages utiliss dans les sources sont dfinis comme suit :
La racine de tout le systme est : CAR Lapplication centrale est situe dans le package : CAR.AN Lapplication mobile pour les agents responsables des parcs de vhicules est situe dans le
package : CAR.AM
B. Base de donnes
Les tables de la base de donnes sont issues de deux catgories de donnes dans le MCD : les entits (employs, clients, etc.) et les associations (rattachement dun vhicule une agence, mise disposition dun vhicule par un employ, etc.). Chaque entit possde un libell lisible qui permet de la distinguer clairement (table EMPLOYE au lieu de EMP par exemple). Ce libell peut contenir des chiffres, mais ne peut pas contenir d'articles dans le nom (ex : LE_CLIENT), ni de verbes (VEHICULE_RATTACHER_A).
Rfrence : PA52 du Document ACAI-GuidePersistance-150
Les associations reliant toujours deux entits au minimum, le libell des tables correspondantes est une concatnation des deux entits, ce qui donne par exemple VEHICULE_AGENCE pour la table correspondant lassociation rattachant un vhicule une agence. Etant donn que plusieurs associations peuvent exister entre 2 tables, on ajoutera alors au libell de la table le nom caractrisant cette association (RATTACHEMENT, CORRESPONDANCE, etc.). Les noms des tables ne devront jamais dpasss 30 caractres.
Concernant les champs de la base de donnes, les noms des colonnes ont les mmes rgles que les libells des tables. Le nom de chaque colonne d'une table commence par les 3 premires lettres du nom de la table (hors prfixe). Ceci permet d'identifier trs clairement les colonnes de cl trangre : elles ne commencent pas par les 3 mmes lettres.
Un index sur une cl primaire est cr automatiquement et portera le nom de la cl primaire : PK_nom de la table. Les index sur les cls trangres seront prfixs de FK. On aura FK_nom de la rfrence.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 11 / 39
Concernant les requtes SQL prsentes dans les fichiers sources, elles doivent tre crites de la faon suivante : lettres majuscules pour les mots SQL (ex. : SELECT, UPDATE, TO_CHAR) et lettres minuscules pour les noms des objets sur lequel porte la requte (noms des tables, champs, variables, etc.). Avant chaque mot SQL, il est souhaitable d'avoir un retour la ligne et d'aligner les lignes de la requte (avec des espaces et non des tabulations qui ne sont pas portables pour la mise en page). De mme, les conditions des sous-requtes doivent tre dcales par rapport la requte principale.
Rfrence : PA54 du Document ACAI-GuidePersistance-150
C. Application
Application nationale : nom des couches Au sein de lapplication nationale, il convient de nommer chaque couche de faon
prdfinie. En effet, chaque couche est stocke dans un package diffrent : la couche physique nest pas reprsente car il sagit de la base de donnes la couche mapping est stocke dans les packages : car.an.hibernate et car.an.dao la couche mtier est stocke dans le package : car.an.business la couche application est stocke dans le package : car.an.controllers la couche prsentation est stocke dans un dossier spar WebRoot contenant des jsp et
les ressources associes.
Application nationale : couche mapping Au sein de la couche mapping, plusieurs conventions de nommage sont dterminer. On
distingue deux types de fichiers : les fichiers de mapping (.hbm.xml) et les classes dentits mtiers (.java). Ces deux types de fichiers sont gnrs automatiquement partir de la base de donnes.
Les classes de mapping dveloppes dans ce projet utilisent le mapping gnr par Hibernate. Ces classes daccs aux donnes (Data Access Object) sont nommes suivant le schma DAO. Des interfaces dfinissent pour chaque DAO les mthodes offertes. Chaque classe DAO implmente linterface qui lui correspond. Ces interfaces sont nommes suivant le schma IDAO.
Application nationale : couche mtier Au sein de la couche mtier, plusieurs conventions de nommage sont galement mettre
en place. Tout dabord, les fichiers sont organiss par entits, les entits tant elles-mmes organises par groupes dentits selon laxe de fonctionnalit (activit commerciale, employs, clients etc.). Chaque entit est alors reprsente par 2 fichiers principaux (dautres fichiers complmentaires peuvent sajouter) :
les managers, nomms Business les interfaces associes, implmentes par les managers : IBusiness
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 12 / 39
Application nationale : couche application La couche application est constitue des diffrents contrleurs permettant dimplmenter
chaque service demand. Ces contrleurs sont organiss par axes de fonctionnalits ( limage de la couche mtier). Tous les contrleurs sont nomms suivant le model Controller
Spring Spring dfinit des objets et leurs dpendances dans un fichier de configuration xml. Les objets qui font rfrence aux classes cres pour reprsenter les diffrentes couches sont nommes suivant le model suivant nomClasse pour une classe NomClasse.
5. Standards de programmation
Lquipe de dveloppement suit un ensemble de conventions de codage qui permettent une homognisation des sources :
Les commentaires doivent tre rdigs pour chaque classe et chaque mthode en respectant la norme JavaDoc, afin de permettre toute personne entrant dans le projet de reconnatre lutilit, les entres et les sorties de ces entits.
Les conventions de codage Java utilises sont celles recommandes par les ACAI (cf. Guide de conception-ralisation).
Les conventions de codage SQL sont galement celles recommandes par les ACAI (cf. Guide de la persistance).
Les conventions approuves par le W3C sont galement appliques dans le cadre du dveloppement WEB (HTML et CSS).
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 13 / 39
IV. CONCEPTION GENERALE
1. Langages utiliss
Voici la liste des diffrents langages utiliss dans le projet CAR :
SQL pour les scripts de cration de la base de donnes (cration de tables et insertions de tuples dans la BD) ainsi que pour les requtes spcifiques de lAM.
PL/SQL pour les dclencheurs. HQL (langage requtes de Hibernate, similaire SQL) pour les requtes spcifiques
dans lAN. Java 1.5 pour le dveloppement de lapplication nationale, Java 1.4 pour lapplication
mobile. JSP pour le dveloppement des vues dans lAN. XHTML, CSS et Javascript pour le contenu des vues JSP dans lAN. XML pour les fichiers de configuration Spring, Hibernate et Tomcat.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 14 / 39
2. Diagramme de dploiement
Voici un diagramme de dploiement rsumant les diffrents composants qui font partie du systme Car.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 15 / 39
3. Architecture des Composants
Chaque application bnficie dune architecture spare, o le seul point commun est la base de donnes centrale. Dans ce paragraphe, nous allons nous attarder sur les problmes darchitecture fondamentaux du systme. Tous les autres choix de conception sont expliqus dans le chapitre Conception dtaille .
A. Architecture 5 couches pour lapplication nationale
Lapplication nationale est divise en cinq couches de fonctionnalits, totalement autonomes les unes des autres, et communiquant par un systme de file : chaque couche ne dialogue quavec les couches voisines suprieure et infrieure. Toutes les couches doivent agir de faon transparente les unes des autres. La sparation des couches est la suivante :
Donnes
Mapping
Mtier
Application
Prsentation
Couche Donnes : cette couche contient les donnes physiques stockes dans la base de donnes Oracle. Elle ne requiert pas dimplmentation Java particulire et fonctionne simplement comme un espace de consultation massif.
Couche Mapping : cette couche contient limplmentation des accs la base de donnes afin de la masquer la couche mtier. Cette couche est entirement gre par Hibernate.
Couche Mtier : cette couche contient les objets mtiers de lapplication. Il existe un objet par fonctionnalit de lapplication. Ces objets implmentent les fonctionnalits spcifiques relatives la location de voitures, et font le lien entre la couche contrleur et la couche mapping.
Couche Application : cette couche contient la partie fonctionnelle de lapplication. Elle sappuie sur les objets mtier pour raliser les actions sollicites par lutilisateur par lintermdiaire de la couche prsentation. Elle est en charge de vrifier la validit des requtes de la couche prsentation. Il existe un contrleur par fonctionnalit de lapplication. Le schma utilis est le MVC (Modle Vue Contrleur), mis en uvre en utilisant Spring MVC. Plus dinformations sont disponibles dans le paragraphe suivant.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 16 / 39
Couche Prsentation : cette couche reprsente les interfaces qui permettent de prsenter les contenus gnrs par la couche prsentation, grce des vues dynamiques (JSP). Elle se charge dafficher des contenus lutilisateur et de lui offrir des interfaces avec la couche contrleur pour interagir avec lapplication.
Larchitecture MVC
Les couches prsentation et application sappuient sur larchitecture Modle-Vue-Contrleur qui permet de sparer le fonctionnel de linterface. Cette architecture est ralise par une conjonction dun contrleur et dun nombre quelconque de pages JSP (les vues) qui offrent le rendu lutilisateur. Les donnes calcules par le contrleur et fournies aux vues pour tre affiches sont les modles. Le contrleur sappuie sur les couches infrieures pour obtenir ces donnes.
Modle
Vue Contrleur
Mtier
Utilise
Utilise Cre
Utilise
Renvoi
UtiliseCARCAR
Plus prcisment, lutilisateur sollicite une action par lintermdiaire dune Vue. Cette action est transmise au contrleur, qui en vrifie la validit et sappuie sur la couche mtier pour leffectuer. Enfin le contrleur renvoi sur la vue correspondant la demande de lutilisateur.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 17 / 39
B. Architecture de lapplication mobile
Donnes
Mtier
Prsentation
Sur les applications PDA, la stratgie adopte est dutiliser un modle en couches similaire. Cependant, la taille de lapplication nimpose pas une sparation aussi fine que lapplication nationale. Nous appliquons donc un modle 3 couches, organis comme suit :
Couche Prsentation : cette couche effectue la prsentation des donnes lutilisateur par lintermdiaire de formulaires et de listes de donnes interactives. Lutilisateur accde lapplication par cet unique moyen.
Couche Mtier : de mme que pour lAN, cette couche contient dune part les objets mtier, correspondant aux donnes mtier manipuler dans lapplication, dautre part, les services mtiers relis ces objets (cration, recherche, suppression, modification et autres services spcifiques). A limage de lAN, cette couche soccupe de garantir que le mtier de lapplication est respect, que les rgles lies aux donnes sont toujours suivies. Dans cette couche, on retrouve galement les mthodes daccs la base de donnes (prsentes dans la couche Donnes dans lapplication nationale).
Couche Donnes : cette couche contient les donnes physiques stockes dans la base de donnes mobile Oracle Lite.
Synchronisation des donnes
La problmatique de la synchronisation prend une part importante dans la conception du systme et notamment de la base de donnes et des parties applicatives basses. Pour rappel ces synchronisations interviennent lorsquun utilisateur de PDA (commercial ou responsable de parc dagence) veut faire concider les donnes quil possde sur son unit mobile avec celles stockes en base de donnes centrale. Le cas dutilisation type se prsente ainsi :
Au dmarrage du PDA, le responsable de parc de vhicules se synchronise avec la base Oracle pour avoir des donnes jour ;
Lors de ses dplacements dans le parc de vhicules, il peut consulter, modifier, insrer ou supprimer des donnes charges dans la base Oracle Lite sans connexion rseau ;
En fin de journe, avant dteindre le PDA, il se synchronise avec le point daccs Wifi de lagence pour soumettre ses mises jour et rcuprer celles des autres ; Ces
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 18 / 39
synchronisations peuvent tre plus frquentes dans le cas de procdures de mise disposition ou de retour de vhicules.
Problmatique : quels conflits peuvent tre engendrs par ces synchronisations ?
Du fait que les responsables de parc de vhicules utilisent le PDA en mode dconnect, il nexiste pas de conflit de modification lors de lutilisation du PDA. Ces conflits peuvent par contre apparatre lors de la synchronisation avec la base de donnes centrale. En cas de conflits pendant la synchronisation entre les donnes prsentes sur le PDA et celles prsentes dans la base centrale, la priorit est donne aux donnes contenues dans la base de donnes centrale. Cette politique de priorits est configure laide de Mobile Database Workbench, le composant de la suite Oracle Lite permettant de construire les lments de synchronisation.
Ce problme de conflit didentifiants et dcrasement des donnes est critique et peut apparatre frquemment dans un contexte dutilisation quotidienne du systme CAR. Nous avons donc dcid quune plage didentifiants serait attribue au PDA, de manire viter tout conflit. La solution optimale (nettement plus complexe mettre en uvre) serait dassocier un second identifiant, propre chaque PDA, au premier identifiant utilis dans lensemble de lapplication. Une seconde solution serait sinon de concatner lidentifiant incrment un identifiant unique de machine. Etant donn que chaque machine possde sa propre et unique base de donnes embarque, le systme serait labri de tout conflit. La gestion des identifiants des PDA devrait dans ce cas tre centralise au niveau de lapplication Mobile Server.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 19 / 39
4. Structure des donnes globales, des fichiers et des bases de donnes
Les donnes sont centralises dans une unique base de donnes Oracle 10g installe sur le serveur de base de donnes Oracle XE (les scripts de cration des tables et des tuples de la base de donnes sont livrs avec les applications AN et AM). Ces donnes sont utilises par lapplication AN, mais galement par lapplication AM qui les rcupre ou les modifie lors de la synchronisation avec le serveur (lapplication AM rcupre donc une copie de certaines tables de la BD ).
5. Stratgie de traitement des erreurs et des exceptions
Dans ce paragraphe sont exposes les diffrentes stratgies mises en place pour grer les erreurs, i.e. empcher lapplication de seffondrer sur nimporte quelle erreur et rendre les erreurs comprhensibles pour lutilisateur.
Stratgie dexceptions par couches
Afin de permettre une gestion localise des exceptions, il a t dcid que chaque couche prenne en compte. Ainsi, la couche mapping est en charge des exceptions lors des accs la base. La couche contrleur est en charge des exceptions dues au mauvais formatage des donnes et de transmettre des messages derreur textuels la couche prsentation pour lutilisateur. De cette faon, chaque couche agit de faon autonome et la rutilisation des composants est possible.
Vrification des donnes saisies
Une des principales sources derreurs dans les applications est due des saisies errones de la part de lutilisateur. Ces erreurs peuvent tre de plusieurs niveaux : erreurs de formatage, non suivi des rgles mtier, contraintes de base de donnes. Elles doivent tre interceptes le plus tt possible dans le cheminement de larchitecture afin dune part que la logique soit respecte (chaque couche a un rle particulier, il doit tre rempli sans supposer que dautres couches le feront sa place), et dautre part que le nombre de traitements ne soit pas excessivement grand. Les diffrents niveaux de vrifications de donnes sont les suivants :
- couche contrleur : les formulaires sont valids. On peut alors vrifier que les donnes ne sont pas absentes, ou mal formates. Ce sont des vrifications sans logique mtier, simplement applicable tout type de formulaire.
- couche mtier : une fois les valeurs saisies valides, la prochaine tape est de vrifier ladquation mtier de ces donnes. Par exemple, une voiture apparaissant dans des mouvements
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 20 / 39
ne peu pas tre supprime mais simplement retire de la circulation. Ce genre de rgles mtiers doivent tre vrifies par cette couche.
- couche mapping : cette couche se charge de vrifier toutes les rgles de gestion implmentes dans la base de donnes. Cela permet de passer au crible toutes les erreurs de saisies qui seraient soit mal gres par les couches suprieurs, soit appartenant des cas trs spcifiques derreurs. Notamment, la gestion des transactions est primordiale. Hibernate se charge dune grande partie de ces problmatiques, il convient toutefois de dfinir les contraintes sur la base de donnes avec prudence et prcision.
Scurisation des accs aux donnes
Les donnes sont accessibles au travers de diffrents crans, offrant les diffrentes fonctionnalits de lapplication. Les utilisateurs de la partie administration de lAN doivent sidentifier pour y accder. De plus un rle est dfinit pour chacun deux. Pour chaque rle, les fonctionnalits accessibles sont dfinies dans la base de donnes. Lapplication est dveloppe pour prendre en compte les fonctionnalits accessibles lutilisateur courant. Pour cela elle naffiche que les crans autoriss lutilisateur. De plus certaines portions de formulaires ou de menus peuvent tre masques.
Pour empcher laccs aux crans non autoriss, en plus de les masquer, un contrleur spcifique, appel intercepteur vrifie quun utilisateur peut bien y accder pour chaque requte. Les droits daccs sont ditables par ladministrateur qui dispose de tous les droits sur tous les crans de lapplication.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 21 / 39
6. Justification des choix darchitecture, des composants et du langage
Les choix de larchitecture sont en partie imposs par le matre douvrage. Celui-ci prconise lutilisation dOracle comme SGBDR, ainsi que le langage JAVA autour des frameworks J2EE pour l'application nationale. Dautre part, le modle des PDA est aussi impos par le matre douvrage. Il sagit de HP iPAQ embarquant lOS Windows Mobile 5.0.
Lapplication nationale a t dveloppe selon une architecture 5 couches. Ce choix permet daccrotre lindpendance et la rutilisation des composants. Ainsi pour chacune des couches, il est possible de changer le choix technique ou limplmentation de faon transparente pour les autres couches. Dautre part le dcoupage en couche permet une plus grande rutilisation synonyme dconomie terme.
En contrepartie, il faut tre conscient quune telle architecture rduit les performances gnrales du systme du fait du cheminement indirect par les diffrentes couches. De plus, le primo investissement est plus lourd en terme de dveloppement. Les conomies se ralisent sur les extensions et la maintenance.
Larchitecture des applications sur PDA est une architecture 3 tiers. La synchronisation entre les PDA et la base de donnes centrale sappuie sur les composants fournis par Oracle.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 22 / 39
V. CONCEPTION DETAILLEE DES COMPOSANTS
1. Systme dInformation
A. Rgles de gestion
Les rgles de gestion dcrivent la nature des relations entre les entits dun systme dinformation. Lensemble de ces rgles permet de dfinir un systme correspondant une problmatique mtier prcisment adapte aux besoins du client. Ces rgles de gestion sont utilises directement dans le modle mtier : chaque rgle correspond une relation entre 2 (ou plusieurs) entits. Les entits mtiers sont indiques en gras.
R1 : une catgorie de vhicules rassemble un ou plusieurs modles de vhicules. Un modle appartient une seule catgorie.
R2 : un modle correspond un ou plusieurs tarifs de location, en fonction de diffrents paramtres. Un tarif de location peut correspondre plusieurs vhicules.
R3 : un quipement spcial peut tre mont sur un vhicule.
R4 : un vhicule appartient un modle. Un modle rassemble un ou plusieurs vhicules.
R5 : un client peut avoir un responsable, employ de lagence.
R6 : un client peut bnficier dun contrat partenaire.
R7 : un contrat dabonnement est sign avec un client de type Particulier. Il peut inclure une remise.
R8 : un contrat dabonnement ncessite une carte dabonnement. Cette carte peut correspondre plusieurs contrats.
R9 : un client professionnel travaille pour une entreprise.
R10 : un client peut effectuer une ou plusieurs rservations. Une rservation correspond un seul client. Une rservation effective est une location.
R11 : une rservation est faite pour une catgorie de vhicule donne.
R12 : une rservation peut contenir des quipements spciaux.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 23 / 39
R13 : une rservation est paye avec un mode de rglement particulier (chque, CB, etc.).
R14 : un employ de type agent commercial met disposition un vhicule une date donne pour une rservation donne. Un employ de type agent commercial effectue le retour dun vhicule une date donne pour une rservation donne.
R15 : un employ de type responsable dagence est responsable dune agence.
R16 : un employ est soit rattach une agence, soit directement au sige.
R17 : un vhicule est prsent dans une agence un moment donn. Une agence peut contenir plusieurs vhicules dans son parc de vhicules.
R18 : des inspections sont effectues sur tous les vhicules. Chaque vhicule est inspect une date donne. Une inspection est toujours effectue lors de la mise disposition dun vhicule, et lors de son retour.
R19 : une inspection peut ne donner lieu aucun constat, ou donner lieu plusieurs.
R20 : un constat peut avoir pour objet un ou plusieurs types de problmes.
R21 : un constat ncessite une opration de maintenance de type corrective.
R22 : une opration de maintenance est effectue rgulirement de manire prventive sur un vhicule, sans que cela implique un constat.
R23 : une opration de maintenance est effectue dans un garage.
R24 : une rservation a une agence de dpart et une agence de retour prvue. Lorsque la rservation devient une location, la location a une agence de dpart effective, et lorsque le retour est effectu, une agence de retour effective.
B. Modle Mtier
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 24 / 39
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 25 / 39
2. Base de donnes
A. Modle Conceptuel de Donnes
La reprsentation du systme dinformation a t ralis laide du modle mtier et de la mthode MERISE. Cette mthode nous a permis de raliser le Modle Conceptuel de Donnes ou MCD, qui fait le lien entre le modle mtier et le modle logique. Le MCD est un modle dit entits-relations qui modlise lensemble des rgles de gestion et des contraintes du systme. Il correspond globalement au modle mtier, en dtaillant le contenu des entits mtiers (attributs).
La construction du MCD a t ralis partir des spcifications du cahier des charges, du modle mtier et des runions avec le matre douvrage. Celui-ci a t gnr grce au logiciel WinDesign, qui permet de transformer le MCD en MLR et de gnrer le script de la base de donnes correspondant.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 26 / 39
B. Modle Logique Relationnel
Le MLR est le modle logique correspondant au MCD. Il reprsente les tables et les colonnes de la base de donnes, le schma de la base de donnes relationnelles. Chaque entit du MCD correspond une table, de mme que les associations 0..n 0..n et les associations contenant des attributs.
Dans le schma du MLR ci-dessous (gnr par WinDesign), les attributs des tables contiennent un prfixe de 3 4 lettres correspondant la table dont ils sont issus (voir guide ACAI). Par exemple, les attributs de la table EMPLOYE ont pour prfixe EMP_ . Cette technique permet de reprer rapidement les cls trangres dans une table (indiqu dans le schma ci-dessous en bleu clair en italique). Les attributs obligatoires sont indiqus en gras. Les cls primaires sont regroups dans des libells contenant PK en prfixe (FK pour les cls trangres, non affiches
Le paramtrage consiste aussi dfinir le type de donnes pour chaque champ. Les types de chaque champs sont dfinis partir des informations contenues dans le cahier des charges. On utilisera ainsi des NUMBER pour les entiers (la taille du NUMBER variant en fonction de la prcision attendue, ou de la quantit denregistrements attendue dans la table) , des CHAR(32) ou des VARCHAR2(255) pour les textes, des DATE pour les dates, etc.
Lhistorisation consiste garder une traabilit de ltat dune entit ou dune relation travers les modifications et suppressions intervenues dans le temps. Elle est reprsente par le formalisme MERISE dans le MCD (voir prcdemment pour les relations entre les agences et les vhicules par exemple). Lhistorisation des dates darrive et de dpart des vhicules dans les agences, ainsi que des dates de mise disposition et de retour des vhicules a t traduite par 2 tables, EMPLOYE_VEHICULE (pour la mise disposition et le retour) et VEHICULE_AGENCE (pour les dates de dpart et de retour).
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 27 / 39
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 28 / 39
3. Application nationale (AN)
Architecture dtaille du composant
Lapplication nationale se divise en deux parties : une partie destine aux clients, permettant principalement deffectuer la rservation dun vhicule en ligne ; et une partie administration, destine aux employs et offrant toutes les fonctionnalits de gestion dfinies dans le cahier des charges.
Le choix de larchitecture 5 couches a t effectu. Nous allons dans les prochains paragraphes dtailler le fonctionnement de chaque couche. Voici un schma rcapitulatif :
Donnes
Mapping
Mtier
Application
Prsentation
Les couches Prsentation et Contrleur ont t dveloppes en utilisant le paradigme MVC :
Modle
Vue Contrleur
Mtier
Utilise
Utilise Cre
Utilise
Renvoi
UtiliseCARCAR
Pour mettre en uvre cette architecture nous avons utilis : - Oracle 10g XE pour la couche Donnes ; - Apache Commons DBCP pour le pool de connections ; - Hibernate pour le mapping de la base de donnes ; - Spring IOC pour les liens entre les diffrentes couches ; - Spring MVC pour la mise en place du MVC ; - JSTL (JavaServer Pages Standard Tag Library) pour laffichage des donnes dans les JSP.
Spring permet de rduire la dpendance entre les diffrentes couches et diminue la quantit de code ncessaire par lintermdiaire de fichiers de configuration.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 29 / 39
Spring IOC
Spring IOC permet de rduire la dpendance entre les couches de lapplication. Il sagit en fait de sparer lappel la couche infrieure de son implmentation. Linversion de contrle permet de mettre en place cette sparation. Les lments des couches Mapping et Mtiers sont dfinis par des interfaces puis implments dans des classes distinctes. La couche suprieure ne connat que lexistence des interfaces dont elle utilise les mthodes prdfinies. Ainsi le changement dimplmentation dune couche naffecte pas la couche suprieure.
Linstanciation des objets de chaque couche est prise en charge par Spring. Un fichier de configuration XML dfinit les dpendances effectives entre les couches. Grce ce fichier, Spring peut savoir quels objets instancier et comment les mettre en relation.
Hibernate
Les DAO vont utiliser des primitives fournies par Hibernate pour faire appel la base de donnes. Notamment, le langage HQL doit tre utilis pour crer des requtes. Le framework Spring fournit une encapsulation permettant de faire appel aux mthodes Hibernate plus simplement. En effet il permet de mettre en uvre linversion de contrle entre les DAO, Hibernate et le driver JDBC. Pour cela il faut utiliser un Pool de connections pour simplifier laccs la base de donnes (ici, Apache Commons DBCP).
Spring MVC
Spring MVC permet de mettre en uvre facilement le paradigme MVC en limitant les dpendances entres Modles, Vues et Contrleurs. Spring offre des types de base pour implmenter les contrleurs et les modles. De plus, il permet de mettre en uvre un contrleur central qui se charge de dispatcher les requtes de la couche Prsentation sur le contrleur appropri. Enfin les oprations dites gnriques inhrentes au modle MVC sont ralises par le framework.
Couche Physique
La couche physique ncessite Oracle 10 XE pour sa mise en place. Elle a t modlise par un Modle Mtier puis par un Modle Logique Relationnelle en utilisant WinDesign. Ces diagrammes sont prsents plus haut. Le script de cration de la base est produit par WinDesign. Il doit ensuite tre excut dans la base de donnes. Un jeu de donnes de test est aussi mis en place sous forme dun script charg de remplir la base avec des donnes cohrentes pour tester lapplication.
Lors de la phase de dveloppement, la base de donnes est situe sur une machine distante, chaque dveloppeur y accde par Internet. Cela implique des temps de latence importants entre chaque traitement et accs la base de donnes, et donc un ralentissement global de lapplication. La communication avec la couche physique se fait au moyen dun driver JDBC fournit par Oracle.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 30 / 39
Couche Mapping
Cette couche est compose de trois catgories de fichiers : les fichiers de mapping Hibernate, les objets mtiers et les DAO (Data Access Object). Nous allons prsenter les trois types de fichiers et expliquer comment nous devons les grer vis--vis des services attendus pour cette couche. Les fichiers de mapping et les objets mtiers sont gnrs automatiquement par le plugin Hibernate que nous avons install dans notre environnement de dveloppement.
A. Les fichiers de mapping Ces fichiers contiennent des informations XML permettant Hibernate de faire la liaison entre un objet mtier et son quivalent dans la base de donnes. Par exemple, le fichier indique quelle colonne de table correspond telle proprit dune classe mappe. Il convient de paramtrer Hibernate pour quil prenne en charge lincrmentation automatique des identifiants des tables.
B. Les objets mtiers de mapping Ces objets sont des classes java, totalement calques sur les objets prsents en base de donnes. Ils sont couramment appels les POJOs (Plain Old Java Objects). Ils sont gnrs automatiquement partir des fichiers mapping.
C. Les DAO Ces objets sont chargs de faire le lien avec la couche mtier en lui offrant toutes les mthodes ncessaires pour utiliser les donnes dans la couche physique. Ils masquent la technologie utilise (ici Hibernate) la couche mtier. Ainsi un changement de technologie pour la couche physique nentrainerait pas de modification des couches autre que celle du Mapping. Il existe un DAO par type de donnes de la base de donnes. Ces DAO permettent :
- Laccs lensemble des donnes dun type ; - Laccs un seul lment dun type par un critre dfinit ; - La modification dun lment ; - Linsertion dun nouvel lment ; - La suppression dun lment.
Pour respecter les contraintes de Spring MVC, chaque DAO est dfinit par lintermdiaire dune interface qui dfinit lensemble de ses mthodes. Limplmentation fait appel Hibernate pour accder la couche physique. Les requtes sont crites en HQL (Hibernate Query Language).
Couche Mtier
La couche mtier a comme rle primordial de proposer un ensemble de services gnriques sur les donnes, tout en faisant respecter les rgles mtier et les contraintes inhrentes au domaine dactivit.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 31 / 39
Il existe un objet mtier pour chaque fonctionnalit de lapplication. Les oprations les plus frquentes sont les oprations CRUD : Create, Read, Update, Delete (Crer, Lire, Modifier, Supprimer). Ces oprations sont primordiales et doivent tre lensemble minimal de mthodes fournies par toutes les entits. Elles font simplement le lien entre la couche Mapping et la couche Application.
Ces oprations peuvent tre bien plus que de simples CRUD, en intgrant par exemple de la logique mtier spcifique au domaine de la location de voiture. Dautres oprations spcifiques au mtier sont aussi prsentes quand cela est ncessaire.
Couche Application
Cette couche a pour rle dimplmenter les cas dutilisations qui seront prsents aux futurs bnficiaires du systme. Larchitecture de la couche se base sur le modle MVC expliqu plus tt. Un contrleur est mis en place pour chaque fonction de lapplication. De plus, un intercepteur se charge de contrler les accs, et un dispatcheur de renvoyer les requtes sur le contrleur appropri. Les contrleurs sont en charge de :
- vrifier que les donnes saisies sont correctes - faire appel la couche mtier pour effectuer les traitements demands - placer dans le Model les donnes ncessaires la couche prsentation - renvoyer lutilisateur sur la couche prsentation correspondant sa demande
Ils se basent sur le type Controller fournit par Spring MVC.
Modle
Vues
Contrleurs
MtierUtilise
Utilise Cre
Requte
Renvoi
UtiliseIntercepteur
DispatcheurCARCAR
A. Scurisation par un intercepteur
Comme prsent prcdemment, cette couche intgre un Intercepteur charg de contrler que lutilisateur bien accs aux crans quil demande. Pour ce faire, lintercepteur empche laccs toutes les pages sauf celle didentification, tant que lutilisateur nest pas authentifi. A lauthentification, le contrleur charg de vrifier lidentit de lutilisateur cre une session. Il place dans cette session lensemble des informations ncessaires pour quil puisse ensuite naviguer dans les diffrents crans : identit, fonction, et droits daccs associs.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 32 / 39
A chaque demande de page par lutilisateur, lintercepteur reoit cette demande et contrle que lutilisateur bien accs cette page. Si la rponse est positive, il laisse le programme sexcuter ; sinon, il redirige lutilisateur sur la page daccueil en lui indiquant quil ne peut accder la ressource quil a demand.
B. Dispatcher
Un objet spcifique est charg de diriger les requtes sur le contrleur appropri. Cet objet est un dispatcheur fournit par Spring, et configur pour diriger chaque requte sur le contrleur associ.
C. Gestion des Erreurs
Lorsquune erreur est rencontre par un contrleur, il place un message derreur dans le model. Celui-ci sera ensuite automatiquement affich lutilisateur par la couche prsentation.
Couche Prsentation
La couche prsentation est prise en charge par des pages JSP. Ces pages JSP sont structures pour standardiser lapparence rendue : les zones communes sont spares et incluses par chaque page. Laffichage des donnes du modle utilise la JSTL (JavaServer Pages Standard Tag Library) qui offre des balises pour simplifier laffichage de ces donnes.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 33 / 39
Rsum de larchitecture en couches
Agences Clients
Droits
Employ Maintenance
Partenaire RservationVehicules
Mtier: Logique mtier & CRUD
Agences Client Employ Maintenance
Mapping: Hibernate & DAO
... ... ......
... ... ......
Agences Client Employ Maintenance
Physique Base Oracle 10g XE
... ... ......
... ... ......
Application: Contrleurs, Dispatcheur, Intercepteur
Agences Client...
Employ Maintenance... ......
Prsentation: JSP, CSS, JavaScript
Administration Clients
Rpartition HTML/CSS/JavaScript
Logo Menu Sous-Menu Titre Sous-Titre
Contenu de la page
Menu
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 34 / 39
Il est important de bien faire la distinction, dans toutes les pages web qui sont dveloppes, entre le ct fonctionnel et le ct graphique. LHTML remplit le ct fonctionnel, i.e. que du contenu, sans se soucier de la forme. Lutilisation des conteneurs de type div se prte cette sparation du contenu, linverse des tableaux. En effet, un tableau utilis pour la disposition dlments na aucune signification fonctionnelle, seulement esthtique. Ce nest pas le rle de lHTML. Les tableaux sont utiliss uniquement pour laffichage de listes de donnes.
Le CSS remplit le ct graphique : disposition des lments, couleurs, tailles. La feuille de style est commune toutes les pages du site, afin de garder une unit et de pouvoir modifier le design du site trs rapidement. Le JavaScript nest utilis que pour laide la saisie. Il nintervient pas dans la validation des donnes saisies : calendrier pour les dates par exemple. En effet lutilisateur peut choisir de dsactiver le JavaScript dans son navigateur. La validation des donnes est donc entirement dlgue la couche contrleur.
Compatibilit Firefox/Internet Explorer
La problmatique de compatibilit entre les deux navigateurs les plus utiliss par les internautes doit tre prise en compte trs tt, car ce sont surtout les styles CSS qui doivent tre crits avec ces contraintes. En effet, certains styles ne sont reconnus que par lun ou lautre des navigateurs. La feuille de style a t dfinie ds ltablissement des maquettes des crans. Elle peut donc tre utilise tout au long du dveloppement pour tre teste.
Authentification utilisateur
Lapplication CAR comporte une interface de gestion destine grer les diffrents processus de lentreprise. Cette partie de lapplication nest pas destine tre accessible par une personne extrieure. Lauthentification des employs est donc ncessaire.
Les connexions utilisateurs sont effectues par identification classique : login et mot de passe. Ces informations sont stockes dans la base de donnes, leur vrification est donc immdiate lors de lauthentification de lutilisateur.
Gestion des droits dutilisateurs
Au sein de la socit, il existe plusieurs catgories demploys qui nont pas accs aux mmes fonctionnalits. Les groupes demploys considrs sont les suivants :
- Responsable Agence - Responsable Parc Vhicules - Agent Commercial - Directeur Commercial
Il est possible de dfinir des fonctionnalits au sein de lapplication. Celles-ci pourront, pour chaque type demploy, contenir le type dautorisation daccs dfini. Par exemple, les agents commerciaux nauront pas accs aux fonctions lies la gestion des employs. La solution est donc de stocker une matrice fonction/types dutilisateurs qui permettra de savoir un moment
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 35 / 39
prcis quels droits sont accords tel type dutilisateur pour telle fonctionnalit (voir le CDC pour les fonctionnalits et leurs utilisateurs potentiels).
Sessions utilisateurs
Lauthentification dun utilisateur conduit louverture dune session qui permettra celui-ci de naviguer sur tout le site sans devoir sidentifier chaque page. La technologie employe pour la ralisation du site (JSP) permet de dfinir une session utilisateur contenant un nombre quelconque de variables de sessions, dfinies et existantes pendant toute la dure de la session.
Il est important de conserver le login (ou le nom associ) de lemploy connect, pour des raisons de traabilit. Les droits allous cet utilisateur doivent tre conservs. On conserve donc les droits associs au type dutilisateur auquel appartient lemploy. Lors de la connexion de lutilisateur, une entit contenant les droits de celui-ci sera donc initialise pour la session ouverte.
Gestion interne de lauthentification
Il convient de dtailler les diffrents composants qui rentrent en jeu lors dune authentification utilisateur. Lors de la soumission du formulaire didentification par lutilisateur, une premire vrification est effectue, permettant de sassurer que ni le champ de mot de passe, ni le champ de login ne sont vides. Ensuite, les donnes sont compares avec les donnes stockes en base :
- vrifier que le mot de passe correspond bien lutilisateur ; - dans le cas o le mot de passe est erron, rediriger vers le formulaire avec une notification
derreur ; - dans le cas o le mot de passe est correct, charger les droits de lutilisateur et rediriger
vers la page daccueil de lapplication.
Expiration de session et reconnexion
Toute session de connexion possde un time out , qui correspond la dure pendant laquelle une session sans activit reste connecte. Au-del de ce temps, lutilisateur doit saisir ses informations de connexion nouveau.
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 36 / 39
4. Application mobile (AM)
Architecture dtaille du composant
Lapplication mobile a t dvelopp selon une architecture 3-couches, sparant la logique mtier des donnes et de leur prsentation. Cette architecture est moins volue et moins flexible que celle utilise dans lapplication nationale mais est tout fait adapte aux plateformes mobiles puisquelle concilie volutivit du code et performances lexcution.
Donnes
Mtier
Prsentation
Pour mettre en uvre cette architecture nous avons utilis : - Oracle Lite 10.3 pour le stockage des donnes sur le PDA. - Oracle Database Workbench et Mobile Server pour la synchronisation des donnes ct
serveur. - Oracle Device Manager et Oracle MSync pour la synchronisation des donnes ct unit
mobile. - MySaifu JVM 0.3 pour lexcution de lapplication sur le PDA.
Synchronisation et stockage des donnes
La suite Oracle Lite 10 fournit plusieurs outils permettant de configurer et mettre en place une architecture asynchrone permettant de synchroniser les donnes de plusieurs units mobiles avec une base centrale. Cette architecture ncessite linstallation et la configuration de plusieurs applications rparties classiquement entre trois machines.
La premire machine est le serveur Oracle 10g central sur lequel un compte administrateur spcifique doit tre cr. Cest avec ce compte que seront rapatries les donnes du PDA.
La seconde machine sert dintermdiaire entre Oracle XE et Oracle Lite. Elle excute Oracle Mobile Server qui a pour rle denregistrer les diffrentes applications, units mobiles et utilisateurs mobiles. Mobile Server peut alors tre configur pour grer et programmer les synchronisations ainsi que les ventuelles mises jour applicatives. Les fonctionnalits de Mobile Server sont compltes par celles dOracle Database Workbench. Cette outil permet de dfinir les diffrentes tables et colonnes qui seront accessibles depuis lapplication mobile ainsi que les
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 37 / 39
lments de synchronisation associs. Un projet finalis dans Database Workbench doit tre dploy sur le Mobile Server afin dtre pris en compte lors des synchronisations suivantes.
La dernire machine implique dans le processus de synchronisation est lunit mobile. En plus de lapplication CAR et de la base de donnes embarque Oracle Lite, deux applications doivent tre installes et configures. La premire, Oracle Device Manager, est loutil qui permet dassocier le PDA un compte Mobile Server. Cest avec cet outil que pourront en outre tre dclenches dventuelles mises jour et synchronisations automatises. Oracle MSync permet quant lui de dclencher manuellement une synchronisation. Cest avec cet outil que le responsable de parc dagences pourra rcuprer ltat courant du parc de vhicules et faire remonter les actions quil aura effectues face au client. Une fois lapplication configure, deux clics suffisent pour dclencher une synchronisation. Ce fonctionnement est pratique car il ne ncessite pas une connexion permanente Internet et permet de profiter de la proximit de points daccs sans fil.
LApplication Mobile
Lapplication mobile se prsente sous la forme dun client lourd en Java, excut sur la plateforme dexcution libre Mysaifu. Le code de cette application se limite une compatibilit avec Java 1.4, version la plus avance supporte par la JVM. Lapplication se dcompose en trois couches qui communiquent entre elles laide dappels de mthodes Java.
La couche Prsentation
La couche prsentation correspond linterface entre lapplication (le traitement mtier) et lutilisateur. LAPI Swing ncessitant des ressources trop importantes au regard de ce que supporte un PDA, lIHM nutilise que les bibliothques AWT.
LIHM de lapplication est contrle par une classe principale qui se charge dafficher lcran demand. Les diffrents crans sont implments sous la forme de calques dont lordre est gr par la classe principale. Chaque calque a la possibilit dappeler un autre calque, dans la mesure o lutilisateur authentifi dans le systme a le droit de visualiser les donnes associes. Lappel dun calque par un autre peut saccompagner du passage dun objet mtier (cf. paragraphe ddi).
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 38 / 39
Figure : Exemple dcran de lapplication mobile. Celui-ci est compos dlments fixes (tels que les onglets daccs aux modules)
et dlments contenus dans le panneau couramment affich.
Lensemble des crans est charg au dmarrage de lapplication mobile afin de rendre plus confortable la navigation entre les diffrents panneaux.
La couche Mtier
Cette couche se compose de classes faisant lintermdiaire entre la base de donnes et la couche prsentation. Ces classes extraient les donnes demandes par lutilisateur et les dlivrent lIHM. Celle-ci est alors susceptible de renvoyer de nouvelles donnes la couche mtier suite une saisie ou une autre opration de lutilisateur. La couche mtier sera alors responsable du contrle de ces donnes et de leur enregistrement dans la base Oracle Lite embarque sur le PDA.
Est associ la couche mtier un ensemble de classes dcrivant les entits manipules dans lapplication, linstar de ce que gnre Hibernate dans lapplication nationale. Ces classes mtier permettent dajouter une valeur smantique aux informations changes et facilitent limplmentation de rgles de contrle de ces informations.
Lorsquune erreur est rencontre par une classe de la couche mtier, celle-ci est transmise la couche prsentation qui laffiche sur lIHM et modifie ventuellement son comportement en consquence (par exemple le refus de la validation dun formulaire mal renseign).
Dpartement Informatique Promotion 2008
_______________________________________________________________________________
CAR-DC-AVIS-V01.doc Dossier de Conception Page 39 / 39
La couche Donnes
La couche physique ncessite Oracle Lite 10.3 pour sa mise en place. Le modle mtier quimplmente cette couche physique est commun aux applications AN et AM. Le script de cration de base est gr de manire transparente par le Mobile Server qui se charge de crer la base lors de la synchronisation si celle-ci nexiste pas.
La base de donnes laquelle accde lapplication mobile est situe sur le PDA, ce qui permet dobtenir des temps de latences trs courts (lagrment dutilisation de lapplication est cependant conditionn par la puissance du processeur embarqu). La communication avec la couche physique se fait au moyen dun driver JDBC fournit par Oracle.