CAR-DC-AVIS-V01

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


_______________________________________________________________________________


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


_______________________________________________________________________________


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/


_______________________________________________________________________________


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


_______________________________________________________________________________


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).


_______________________________________________________________________________


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.


_______________________________________________________________________________


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)


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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


_______________________________________________________________________________


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).


_______________________________________________________________________________


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.


_______________________________________________________________________________


2. Diagramme de dploiement

Voici un diagramme de dploiement rsumant les diffrents composants qui font partie du systme Car.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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


_______________________________________________________________________________


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.


_______________________________________________________________________________


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


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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

_______________________________________________________________________________


_______________________________________________________________________________


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.


_______________________________________________________________________________


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).

_______________________________________________________________________________


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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.


_______________________________________________________________________________


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


_______________________________________________________________________________


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


_______________________________________________________________________________


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.


_______________________________________________________________________________


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


_______________________________________________________________________________


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).


_______________________________________________________________________________


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).


_______________________________________________________________________________


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.

CAR-DC-AVIS-V01

Documents

Transcript of CAR-DC-AVIS-V01