Car DC Avis V01

Dpartement Informatique
Promotion 2008
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
_______________________________________________________________________________
Dossier de Conception
Page 1 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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
_______________________________________________________________________________
Page 2 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
HISTORIQUE DES REVISIONS
Rfrence
Dossier de
Conception CAR
Dossier de
Conception CAR
Dossier de
Conception CAR
Rvision
Date
00
20/11/2007
01
11/01/2008
02
27/01/2008
Auteur(s)
Equipe de
dveloppement
Equipe de
dveloppement
Equipe de
dveloppement
Nature de la rvision
Version projet initiale
Conception Gnrale AN
Conception Dtaille AN et
AM
REFERENCE INTERNET
http://jonathan.favier.free.fr/projets/Car/
_______________________________________________________________________________
Page 3 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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
_______________________________________________________________________________
Page 4 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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).
_______________________________________________________________________________
Page 5 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 6 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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)
_______________________________________________________________________________
Page 7 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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 bottomup ) 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.
_______________________________________________________________________________
Page 8 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 9 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 10 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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 <NomDonneesAccedees>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 I<NomDonneesAccedees>DAO.
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 <NomManager>Business
les interfaces associes, implmentes par les managers : I<NomManager>Business
_______________________________________________________________________________
Page 11 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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 <Nom>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).
_______________________________________________________________________________
Page 12 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 13 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
2. Diagramme de dploiement
Voici un diagramme de dploiement rsumant les diffrents composants qui font partie du
systme Car.
_______________________________________________________________________________
Page 14 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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 :
Prsentation
Application
Mtier
Mapping
Donnes
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.
_______________________________________________________________________________
Page 15 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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-VueContrleur 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.
Utilise
Utilise
CA
R
Vue
Contrleur
Utilise
Renvoi
Cre
Utilise
Mtier
Modle
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.
_______________________________________________________________________________
Page 16 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
B. Architecture de lapplication mobile

Prsentation
Mtier
Donnes
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
_______________________________________________________________________________
Page 17 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 18 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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
_______________________________________________________________________________
Page 19 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 20 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 21 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 22 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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
_______________________________________________________________________________
Page 23 / 39
CAR-DC-AVIS-V01.doc
_______________________________________________________________________________
Page 24 / 39
CAR-DC-AVIS-V01.doc
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.
_______________________________________________________________________________
Page 25 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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).
_______________________________________________________________________________
Page 26 / 39
CAR-DC-AVIS-V01.doc
_______________________________________________________________________________
Page 27 / 39
CAR-DC-AVIS-V01.doc
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 :
Prsentation
Application
Mtier
Mapping
Donnes
Les couches Prsentation et Contrleur ont t dveloppes en utilisant le paradigme MVC :
Utilise
Utilise
CA
R
Vue
Contrleur
Utilise
Renvoi
Cre
Utilise
Mtier
Modle
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.
_______________________________________________________________________________
Page 28 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 29 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 30 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
CA
R
Requte
Utilise
Intercepteur
Dispatcheur
Vues
Utilise
Mtier
Contrleurs
Renvoi
Utilise
Cre
Modle
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.
_______________________________________________________________________________
Page 31 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 32 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
Logo
Menu
Sous-Menu
Titre
Sous-Titre
Contenu de
la page
Rsum de larchitecture en couches

Menu
JSP, CSS, JavaScript
Prsentation:
Agences
...
Client
...
Employ
...
Maintenance
...
Application: Contrleurs, Dispatcheur, Intercepteur

Administration
Clients
Mtier:
Logique mtier & CRUD
Agences
Clients
Employ
Vehicules
Droits
Partenaire
Mapping:
Agences
...
...
Physique
Agences
...
...
Maintenance
Rservation
Hibernate & DAO

Client
...
...
Employ
...
...
Maintenance
...
...
Base Oracle 10g XE

Client
...
...
Employ
...
...
Maintenance
...
...
Rpartition HTML/CSS/JavaScript
_______________________________________________________________________________
Page 33 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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
_______________________________________________________________________________
Page 34 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 35 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
Prsentation
Mtier
Donnes
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
_______________________________________________________________________________
Page 36 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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).
_______________________________________________________________________________
Page 37 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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).
_______________________________________________________________________________
Page 38 / 39
CAR-DC-AVIS-V01.doc
Promotion 2008
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.
_______________________________________________________________________________
Page 39 / 39
CAR-DC-AVIS-V01.doc

Car DC Avis V01

Uploaded by

Document Information

Original Title

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

Car DC Avis V01

Uploaded by

Copyright:

Available Formats

Dpartement Informatique

Matre douvrage (enseignant responsable) :

Titulaire (quipe de conception) :

Architecture gnrale de lapplication CAR

Interface entre lapplication nationale et les points daccs distants : la

3. Bases de donnes externes

4. Contraintes gnrales de conception

II. DOCUMENTS DE REFERENCE

Cours de Qualit (William Boher-Coy)

III. NORMES, STANDARDS ET OUTILS

2. Environnement et outils de dveloppement

A. Noms des applications et des packages

IV. CONCEPTION GENERALE

3. Architecture des Composants

A. Architecture 5 couches pour lapplication nationale

B. Architecture de lapplication mobile

Synchronisation des donnes

Au dmarrage du PDA, le responsable de parc de vhicules se synchronise avec la base

Problmatique : quels conflits peuvent tre engendrs par ces synchronisations ?

4. Structure des donnes globales, des fichiers et des

5. Stratgie de traitement des erreurs et des exceptions

6. Justification des choix darchitecture, des composants

V. CONCEPTION DETAILLEE DES COMPOSANTS

R1 : une catgorie de vhicules rassemble un ou plusieurs modles de vhicules. Un

R2 : un modle correspond un ou plusieurs tarifs de location, en fonction de diffrents

R3 : un quipement spcial peut tre mont sur un vhicule.

R4 : un vhicule appartient un modle. Un modle rassemble un ou plusieurs

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

R8 : un contrat dabonnement ncessite une carte dabonnement. Cette carte peut

R9 : un client professionnel travaille pour une entreprise.

R12 : une rservation peut contenir des quipements spciaux.

R15 : un employ de type responsable dagence est responsable dune agence.

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

R23 : une opration de maintenance est effectue dans un garage.

B. Modle Logique Relationnel

3. Application nationale (AN)

Laccs lensemble des donnes dun type ;

vrifier que les donnes saisies sont correctes

Ils se basent sur le type Controller fournit par Spring MVC.

C. Gestion des Erreurs

Rsum de larchitecture en couches

JSP, CSS, JavaScript

Application: Contrleurs, Dispatcheur, Intercepteur

Logique mtier & CRUD

Hibernate & DAO

Base Oracle 10g XE

4. Application mobile (AM)

Pour mettre en uvre cette architecture nous avons utilis :

Synchronisation et stockage des donnes

Figure : Exemple dcran de lapplication mobile. Celui-ci est

You might also like