Rapport GesPro

Universit Mohammed V-Souissi Ecole Nationale Suprieure dInformatique et dAnalyse des Systmes

Mmoire de projet de fin dtudepour lobtention du titre

dIngnieur dtat en informatiqueoption rseaux de communication. Sujet :

Analyse, conception et ralisation dune application de gestion de projets avec deux types de clients : un client PDA (Personal Digital Assistant) et un client ordinateur

Ralis par : Issam ELASLAOUI. Hamid MAZOUAR.

Sous lencadrement de : M. Amine AMAR (CACIOPEE). M. Mohammed KETTANI (ENSIAS).

Anne universitaire 2003-2004

DdicaceA ma chre mre, A mon cher pre, A mon cher petit frre, A tout ceux qui mont aid le long de mon parcours dtudiant, A tout mes amis, A tout mes frres et mes surs en Palestine ainsi quen Iraq, et tout les musulmans du monde, A notre martyr Cheikh Ahmed YASSINE et tout ceux qui se sont sacrifis pour lamour de lIslam et pour sa gloire. Hamid.

Liste des abrviations

AbrviationAPI BD BL CDC CLDC CVM DAL DOM J2EE J2ME J2SE JRE JSP JVM KVM MIDlet MIDP MVC OS PDA PL PSP POSE RMS SSII UML UI XML

DsignationApplication Programming Interface Base de donnes Business Layer Connected Device Configuration Connected Limited Device Compact Virtual Machine Data Access Layer Document Object Model Java 2 Entreprise Edition Java 2 Micro Edition Java 2 Standard Edition Java Runtime Environment Java Server Pages Java Virtual Machine Kilo Virtual Machine Nom compos partir de MIDP et rappelant applet et servlet Mobile Information Device Profile Model View Controller Operating System Portable Digital Assistante presentation Layer Personnal Software Process Palm OS Emulator Record Management System Socit de Service en Ingnierie Informatique Unified Modeling Language User Interface eXtensible Markup Language

Projet de Fin dEtude : ENSIAS 2004

-- 1 --

Listes des figures et tableaux

Liste des tableauxTableau 1 Tableau 2 Tableau 3 Tableau 4 Tableau 5 Tableau 6 Formulaire PSP pour lhistorique de projet Formulaire PSP pour lestimation du projet Liste des packages de CLDC Liste des packages du MIDP Identification des cas dutilisation Comparaison entre larchitecture 2-tiers et 3-tiers 12 12 23 24 28 73

Liste des figures

Figure 1 Figure 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 11 Figure 12 Figure 13 Figure 14

Schma gnral de lapplication Schma global du MVC Architectures J2ME Les diffrentes configurations de larchitecture J2ME Package MIDP et CLDC Modle du cycle de vie dune Midlet Diagramme des cas dutilisation Diagramme des composants du systme environnant Empaquetage des classes cot serveur Diagramme de packages Scnario de lecture de la base de donnes Scnario dcriture dans la base de donnes Scnario nouvel utilisateur Scnario didentification

14 18 22 24 25 26 29 30 32 34 35 36 37 38 -- 2 --


Figure 15 Figure 16 Figure 17 Figure 18 Figure 19 Figure 20 Figure 21 Figure 22 Figure 23 Figure 24 Figure 25 Figure 26 Figure 27 Figure 28 Figure 29 Figure 30 Figure 31 Figure 32 Figure 33 Figure 34 Figure 35 Figure 36 Figure 37 Figure 38 Figure 39 Figure 40 Figure 41 Figure 42

Diagramme de squences du scnario suivi des tches Diagramme de squences du scnario synchronisation Diagramme de classes regroupant les deux packages SynchronizeClientSide et DbSide Diagramme de classes du package XML Diagramme de classes du package JobsLogsSwing Structure de la partie serveur Fonctionnement du client PC Ecran didentification Licne de lapplication dans le tray bar Processus de cration du profile utilisateur (1) Processus de cration du profile utilisateur (2) Processus de cration du profile utilisateur (3) Structure du rpertoire personnel dun utilisateur Fentre principale de gestion des tches Le sous-menu Import Le menu Import de licne du tray bar Le sous-menu Export Le menu Export de licne du tray bar Le sous-menu Synchronize Le menu Synchronize de licne du tray bar Lcran de configuration Lcran daccueil du client PDA Lcran New user du client PDA Lcran de choix des tches du client PDA Lcran des interruptions (pauses) du client PDA Lcran des rsultats du client PDA La page principale du module Web La page dexport du module Web

40 42 44 45 48 51 53 56 56 57 57 58 58 58 59 59 59 59 60 60 60 61 61 62 62 63 63 64 -- 3 --


Figure 43 Figure 44 Figure 45 Figure 46 Figure 47 Figure 48 Figure 49 Figure 50

La page dimport du module Web La rponse du serveur une requte du module Web Architecture Client/Serveur trois niveaux Quelques types de PDA Exemple du fichier XML dimport Exemple du fichier XML des interruptions Exemple du fichier XML dexport Exemple du fichier XML de la configuration

64 65 72 74 81 82 83 84


-- 4 --

SommaireListe des abrviations ..................................................................................................................... - 1 Listes des figures et tableaux ......................................................................................................... - 2 Introduction .................................................................................................................................... - 7 CHAPITRE .................................................................................................................................. - 9 Contexte Gnral du Projet.......................................................................................................... - 9 1.1. Organisme daccueil : CACIOPEE ................................................................................. - 9 1.1.1. Prsentation de CACIOPEE ..................................................................................... - 9 1.1.2. Division de CACIOPEE ............................................................................................ - 9 1.2. Prsentation du projet .................................................................................................... - 12 CHAPITRE ................................................................................................................................ - 17 Etude du projet ........................................................................................................................... - 17 2.1. Spcification des besoins................................................................................................. - 17 2.2. La solution propose ....................................................................................................... - 18 2.2.1. Description de la solution ........................................................................................ - 18 2.2.2. Le principe MVC ..................................................................................................... - 19 2.3. Etude technique ............................................................................................................... - 20 2.3.1. Etat de lart de la programmation sous Palm OS ................................................. - 20 2.3.1.1. Le POSE (Palm OS Emulator) ........................................................................ - 20 2.3.1.2. Programmation sur Desktop ............................................................................ - 21 2.3.1.3. Programmation embarque ............................................................................. - 21 2.3.2. Choix du langage Java sous la plate-forme J2ME ................................................ - 22 2.3.3. Prsentation de la plate-forme J2ME .................................................................... - 22 2.3.3.1. Gnralit........................................................................................................... - 22 2.3.3.2. Les configurations ............................................................................................. - 23 2.3.3.3. Les profiles ......................................................................................................... - 25 2.3.3.4. Les Midlets ......................................................................................................... - 26 CHAPITRE ................................................................................................................................ - 29 Analyse et conception ................................................................................................................ - 29 III ............................................................................................................ Erreur ! Signet non dfini. 3.1. Prsentation du langage de modlisation UML ........................................................... - 29 3.2. Analyse des besoins fonctionnels ................................................................................... - 30 3.2.1. Cas dutilisations ..................................................................................................... - 30 3.2.2. Diagramme de cas dutilisations ............................................................................ - 30 3.3. Spcifications techniques ................................................................................................ - 31 3.3.1. Diagramme des composants (figure8) .................................................................... - 31 3.3.2. Organisation du modle de spcification logicielle ............................................... - 33 3.3.2.1. Dfinition ........................................................................................................... - 33 Projet de Fin dEtude : ENSIAS 2004 -- 5 --

3.3.2.2. Modularit et organisation des packages ........................................................ - 33 3.3.3. Diagramme de package ........................................................................................... - 34 3.4. Modles statiques et dynamiques .................................................................................. - 36 3.4.1. Diagrammes de squences ....................................................................................... - 37 3.4.2. Diagrammes de classes ............................................................................................ - 44 CHAPITRE 4 : Ralisation et mise en uvre .......................................................................... - 50 4.1. Outils de dveloppement : .............................................................................................. - 50 4.1.1. Java Server Pages (JSP) : ........................................................................................ - 50 4.1.2. eXtensible Markup Language (XML) : ................................................................. - 51 4.2. Implmentation de lapplication .................................................................................... - 51 4.2.1. Implmentation de la partie serveur ...................................................................... - 51 4.2.2. Implmentation de la partie client PC ................................................................... - 52 4.2.3. Implmentation de la partie client Palm ................................................................ - 56 4.3. Exemple dutilisation : .................................................................................................... - 56 4.3.1. Utilisation du client pour PC : ................................................................................ - 56 4.3.2. Utilisation du client PDA ......................................................................................... - 61 4.3.3. Utilisation du module Web ...................................................................................... - 63 Conclusion ................................................................................................................................... - 66 Bibliographie................................................................................................................................ - 67 Glossaire ...................................................................................................................................... - 68 Annexes ....................................................................................................................................... - 71 Architecture Client/Serveur trois niveaux .......................................................................... - 72 Prsentation des PDA ............................................................................................................ - 75 Fichiers XML utiliss par lapplication ................................................................................ - 81 XML (eXtensible Markup Language) .................................................................................. - 85 -


-- 6 --

IntroductionLe dveloppement de tout organisme repose le plus souvent sur son aptitude grer ses ressources humaines, matrielles, financires et ses projets. En outre, il dpend de sa capacit dassurer de meilleures performances et de rpondre aux normes qualit et par consquent dtre plus comptitif. Cest ainsi que loptimisation des facteurs qui contribuent la composition et la fabrication dun produit ou dun service devient une priorit incontournable pour toute entreprise dsireuse de bien se positionner sur le march de son activit. La gestion efficace des projets se rvle la plus importante des dmarches que les Socits de Services en Ingnierie Informatique (SSII) doivent entreprendre. La gestion du temps, primordiale pour le respect des dlais, et la gestion des ressources humaines alloues aux projets doivent tre prises en compte dans lorganisation, la planification et le contrle de ces projets. Loptimisation du temps et lamlioration des comptences constituent donc un souci permanent. Pour ce, des mthodes formelles, facilitant la matrise des processus d'ingnierie du logiciel, ont t labores par des instituts de renomme internationale. De la matrise de ces processus dcoule la matrise de la qualit des produits et des services issus de ces processus. Cette qualit mesurable est une caractristique dmontre de la russite conomique des entreprises et de la performance des organisations. Dans le but de profiter des ces mthodes, lentreprise CACIOPEE nous a confi le dveloppement dune application dont le but est de grer le suivi des tches attribues ses dveloppeurs. Cette application aura rcolter des informations exploites par ces mthodes. Le prsent rapport expose l'objectif et les phases du dveloppement de notre projet. Nous avons jug ncessaire de le dcouper en quatre chapitres. Le premier chapitre dfinit le contexte gnral du projet. Il dbute par une prsentation de lorganisme daccueil. Ensuite, il dcrit lobjectif escompt par notre projet, et la dmarche que nous avons adopte pour la mise en uvre de cette application. Le deuxime chapitre explique la phase dtude du projet. Dans ce chapitre, nous dfinissons la problmatique rsoudre et nous dsignons les modules du projet. Ces modules proposent une solution qui rpond aux besoins de CACIOPEE. La phase danalyse et de conception constitue le sujet du troisime chapitre. Cette phase explique, dune manire dtaille, la solution apporte par notre projet en se basant sur le formalisme UML. Projet de Fin dEtude : ENSIAS 2004 -- 7 --

Quant au quatrime chapitre, il sera consacr la phase de ralisation et de mise en oeuvre. Le fonctionnement de lapplication sera illustr la lumire dun exemple. Une synthse du travail ralis sera prsente en conclusion. Quant aux technologies et concepts abords dans ce rapport, elles seront dfinies en dtails dans des annexes ddies.


-- 8 --

CHAPITRE 1

Contexte gnral du projet

CHAPITRE 1Introduction


Dans ce chapitre nous allons dcrire le cadre gnral dans lequel se droule notre projet de fin dtude. Dabord nous allons prsenter lorganisme daccueil CACIOPEE . Puis, nous passerons la prsentation de lapplication objet de notre projet.

1.1. Organisme daccueil : CACIOPEENous allons commencer dabord par une prsentation de cette socit, ensuite nous dfinissons ses diffrentes divisions. 1.1.1. Prsentation de CACIOPEE CACIOPEE est une socit spcialise dans les nouvelles technologies de linformation. Utilisant une mthodologie dassurance qualit, leader dans le domaine des services informatiques, elle veille amliorer les performances des entreprises en leur permettant : Doptimiser leurs ressources ; De mieux grer leur capital connaissance ; Damliorer leur flux internes et externes ; Dimplanter des systmes centrs sur les besoins utilisateurs ; De mieux grer leurs relations clients ; Daccder de nouveaux marchs grce a des technologies de pointe ; De sintgrer dans la nouvelle conomie.

Les domaines de comptences de CACIOPEE sont : Java, C, C++, Cobol, DB2, Corba, J2EE, UML, XML, Conceptions et modlisations orientes objet.

1.1.2. Division de CACIOPEE CACIOPEE est organise autour de 5 divisions : Division de Dveloppement ; Division de Formation ; Division de Systmes dInformation ; Division dIntgration des Systmes ; -- 9 --


CHAPITRE 1 Division de Knowledge Management.


Ces divisions partagent le mme souci defficacit et de rigueur travers lutilisation de mthodologie de dveloppement et de gestion de projets prouves et pertinentes. Les quipes dingnieurs de CACIOPEE hautement qualifis et motivs, sengagent mener terme les projets dans le respect dun niveau de service et dun plan de qualit pralablement tabli. Travaillant dans un climat de confiance rciproque, CACIOPEE tisse des relations de partenariat durables avec ses clients, dans le respect des rgles dthique .Elle assure des missions de dveloppement, de formation, dassistance et de conseil dans les technologies de linformation. Elle comporte plusieurs divisions savoir : Division de dveloppement : Cette division prend en charge : Le dveloppement de nouvelles applications : Cette activit consiste grer les grands projets de dveloppement dapplications informatiques, depuis les phases danalyse, de conception, de ralisation et de validation jusqu la mise en uvre de lenvironnement oprationnel et humain. La maintenance applicative : cette activit consiste assurer le support, la maintenance et lvolution de tout patrimoine applicatif en amliorant constamment les applications au cour de leur cycle de vie et ce dans le respect dun haut niveau de service contractuel. La migration et le r engineering dapplications existantes : Cette activit consiste : Dfinir ou redfinir larchitecture cible ; Assurer lvolution humaine ; Assurer linteroprabilit avec lenvironnement qui continuera exister (stable, processus business ou humains, autres applications, priphriques etc.). Division de formation : Le succs de lentreprise actuelle se gagne sur le terrain de la formation de ses hommes. Cela implique pour les responsables systmes la matrise des serveurs, du rseau, de la scurit et pour les producteurs de contenus lutilisation de mthodes et doutils pertinents. Son offre de formation est architectur en cinq filires : Filire Ingnierie des Systmes dInformation ; Projet de Fin dEtude : ENSIAS 2004 -- 10 --

CHAPITRE 1 Filire Ingnierie de Logiciel ; Filire Dveloppement ; Filire Base de Donnes ; Filire Systmes et Rseaux.


Lutilisation quotidienne de ces technologies par les quipes de CACIOPEE fait que les personnes suivant les cours auront acquis la fois une connaissance thorique du sujet et galement une connaissance pratique. Division systmes dinformation : On groupe au sein de cette division activits de : Conseil en stratgie informatique ; Conseil dans la slection et la mise en uvre de solutions informatiques globales ; Conception et mise en uvre des systmes dinformations e-Business. Cette division permet entre autres aux entreprises : De prendre du recul par rapport lagressivit commerciale des fournisseurs

dquipements et de logiciels informatiques ; Dadopter les stratgies gagnantes pour les prochaines annes ; De choisir les solutions informatiques rellement adaptes leurs besoins ; De russir les changements et les transformations profonds notamment lvolution vers le e-Business. Division intgration des systmes : Cette division prend en charge la mise en uvre des projets informatiques complexes dans le respect des dlais et des budgets allous. Elle sappuie pour cela tout autant sur la comptence de ses collaborateurs. Les principales activits de cette division sont : La conception des solutions ncessitant lintgration des diffrents composants technologiques : les ingnieurs travaillent concevoir les solutions rpondant au mieux aux besoins des clients. Ils dfinissent linfrastructure mettre en place pour accueillir les nouvelles applications et les applications existantes. La gestion et le dploiement du projet : un des principaux intrt des nouvelles technologies rside dans la possibilit de dvelopper de nouveaux systmes

dinformatique sur la base danciens. La rutilisation des applications et des parcs de matriels existants favorise donc limplantation rapide de ces nouveaux outils. La formation et lassistance. Division Knowledge Management :


-- 11 --

CHAPITRE 1 Les principales activits de cette division sont :


La comptitivit et business intelligence : dans le cadre de cette activit, on permet aux socits de mieux connatre leurs clients, de les slectionner, de les conqurir, de les fidliser, de connatre leurs proccupation, danticiper leurs besoins et moyen terme daugmenter significativement les volumes daffaires et la rentabilit quils gnrent. Le partage de connaissance knowledge sharing : travers cette activit, on facilite aux clients laccs aux informations pertinentes en mettant en place le (les) support(s) adquat(s). Cette activit se ralise travers la mise en uvre dintranet, lutilisation de diffrents mdias et lutilisation de moteurs de recherche et dagents intelligents. Lingnierie de lducation Education Engineering : cette activit a pour objectif de recenser les besoins en terme de formation des clients et de leur proposer les cursus les plus adapts. La ralisation de ces cursus pourra se faire par les soins de CACIOPEE ou par lintermdiaire de ses partenaires selon les domaines de

comptences quils ncessitent. En conclusion, CACIOPEE est une SSII (Socit de Services en Ingnierie de lInformatique) spcialiste des nouvelles technologies de linformation. Elle a pour principal objectif de fournir aux entreprises et organismes divers, des produits et des services professionnels de haute qualit.

1.2. Prsentation du projet La gestion de tout projet quil soit informatique ou relevant dun autre domaine exige de la part du comit responsable dassurer certaines tches essentielles pour la conduite de projet. Parmi ces tches figurent : la planification par lestimation des charges et lordonnancement des tches ; lorganisation par la constitution de lquipe de projet et laffectation des tches aux ressources ; le contrle du projet par un suivi de son avancement et une gestion efficace des perturbations qui atteignent son droulement. Pour arriver bien piloter les projets au sein de lorganisme daccueil, CACIOPEE a choisi de suivre la mthode PSP (Personnal Software Process) conu par Watts Humphrey de linstitut SEI (Software Engeneering Institute). Cette mthode a t conue afin de contrler les projets et damliorer leur qualit. Elle vise identifier les points faibles et les points forts de lingnieur et Projet de Fin dEtude : ENSIAS 2004 -- 12 --

CHAPITRE 1 laider mieux grer son temps et amliorer lestimation de ses tches. Parmi les principes de cette mthode, nous citons :


la sauvegarde de lhistorique des activits pour chaque individu et lvaluation du temps utile ainsi que du temps perdu ; lestimation des tches futures en exploitant les anciennes estimations ; lamlioration de la qualit du code ; la rduction du nombre derreurs (en les prvoyant prcocement afin de minimiser le cot des logiciels) ; la planification et la structuration des tches ; le calcul du temps consacr pour chaque phase du projet ; lestimation de la taille du projet. Pour appliquer ces principes, PSP dfinit plusieurs tableaux, chacun a un objectif prcis. Lingnieur est sollicit de remplir ces tableaux qui vont laider par la suite amliorer sa mthode de travail. La mthode PSP englobe plusieurs niveaux. En ce qui concerne le deuxime niveau, qui est en relation avec notre projet, il consiste enregistrer lhistorique et estimer les tches futures en se basant sur les anciennes estimations. Il y a deux tableaux spcifiques pour ce niveau : Time Recording Log et Job Number Log (voir les deux tableaux suivants). Name : Date Start Stop Date : Interruption Delta Time Time Activity Comments C U

Tableau 1 : Formulaire PSP pour lhistorique de projet Name : Job # Date Process Actual Time Units Rate Date : Estimated Time Units To Date Time Units Rate Max Min

Description : Tableau 2 : Formulaire PSP pour lestimation du projet Les informations contenues dans le premier tableau sont : Date : la date dune activit. En gnral, cest la date dun jour ouvr ; Start : Le temps du dbut de lactivit ; Projet de Fin dEtude : ENSIAS 2004 -- 13 --

CHAPITRE 1 Stop : le temps darrt dexercer cette activit ;


Interruption Time : Le temps perdu entre le dbut et la fin de lactivit, par exemple : la dure de la consultation du mail ; Delta Time : le temps net consacr lachvement de lactivit, il est gal (Stop- Start Interruption time) ; Activity : Cest la description de la tche ; Comments : Une note ou commentaire plus complte sur lactivit, le type dinterruption ou toute autre chose qui serait utile quand nous analysons lhistorique ; C : signifie Completed, elle est mise 1 une fois que la tche soit termine ; U (units) : Le nombre dunits ralis dune tche. Quand aux informations contenues dans le second tableau, elles sont : Job # : le numro de la tche ; Date : la date du dbut du travail ; Process : le type de la tche : analyse, conception Estimated Time : reprsente le temps estim pour une tche ; Estimated Units : le nombre dunits estimes ; Actual Time : le temps rel final que lexcution de la tche a pris ; Actual Units : le nombre rel final dunits ; Actual Rate: cette quantit est gale Actual Time divis par Actual Units; To Date Time : il est gal la somme de To Date Time de la tche la plus rcente de mme type et Actual Time de ce travail; To Date Units : il est gal la somme de To Date Units de la tche la plus rcente de mme type et Actual Units de ce travail; To Date Rate: cette quantit est gale To Date Time divis par To Date Units; Max:cest le maximum des cases Rate pour toutes les tches compltes du mme type ; Min : cest le minimum des cases Rate pour toutes les tches compltes du mme type ; Description : description du travail pour lidentifier facilement. Mais un problme se pose : Comment peut-on rcolter ces donnes? Le sujet de notre projet de fin dtude est une solution permettant lquipe dun projet (au sein de lorganisme daccueil) dalimenter une base de donnes ddie la gestion de projet (cette base contient toutes les informations ncessaires pour les tableaux dcrits prcdemment). En effet, il sagit de raliser une application client/serveur trois niveaux (une description dtaille des concepts de cette architecture sera prsente dans lannexe A) de gestion de projet avec deux types Projet de Fin dEtude : ENSIAS 2004 -- 14 --

CHAPITRE 1


de clients : un client pour PDA (voir annexe B), pour permettre la mobilit de lutilisateur de notre application surtout lorsquil sagit dune tche raliser en dehors de CACOPEE, et un autre pour ordinateur. A ces deux clients sajoute un module qui sera hberg cot base de donnes pour permettre la mise jour et/ou la consultation des donnes de cette base (voir figure 1). Qui plus est, une page Web sera dveloppe pour permettre lutilisation des donnes des tableaux cits en haut nimporte o et sans avoir installer la partie client de lapplication chez soi. Notre application est destine satisfaire aux besoins de lorganisme daccueil. Elle se base sur le modle de donnes adopt par CACIOPEE pour leur logiciel de gestion de projet PHOENIX (dvelopp localement par lquipe de CACIOPEE).

Partie cliente PDA

XML

Serveur dapplications Serveur de BD

Partie cliente

XML

Internet

XML

Partie serveur

MA J

Page Web

Figure 1 : Schma gnral de lapplication

Pour pouvoir raliser ce projet et rpondre ses objectifs, nous avons adopt la dmarche suivante : Nous avons dabord entrepris une tude des besoins de CACIOPEE et dgag les modules du projet, Ensuite, nous avons fait une analyse et conception du projet laide du langage Unified Modeling Langage (UML) et de loutil Rational Rose pour les diagrammes UML du projet, Puis, nous avons commenc implmenter les diffrents modules de lapplication tout en testant le fonctionnement de chaque module ralis.


-- 15 --

CHAPITRE 1


ConclusionCe chapitre reprsente un point de dpart pour llaboration de notre projet de fin dtude. La prsentation de lorganisme daccueil a occup sa premire moiti, tandis que la deuxime a t consacre entirement la prsentation du sujet. Dans le chapitre suivant, il sera question dexposer ltude que nous avons faite du projet.


-- 16 --

CHAPITRE 2

Etude du projet


Etude du projet

Apres avoir prsent le contexte gnral de notre PFE, nous allons dcrire dans le prsent chapitre la phase dtude du projet. Il sera question de prsenter les besoins exprims par CACIOPEE pour lesquels lapplication doit rpondre. La solution que nous avons propose sera expose dans la deuxime et dernire partie de ce chapitre.

2.1. Spcification des besoinsLe logiciel PHOENIX de gestion de projet, dvelopp au sein de lorganisme daccueil, utilise une base de donnes regroupant toutes les informations ncessaires pour la gestion des projets de CACIOPEE. Conjointement avec ce logiciel, notre application devra permettre son utilisateur de sauvegarder les informations relatives aux suivis de la ralisation des tches sur lesquelles il travaille ainsi que lhistorique des pauses quil a effectues. Cette sauvegarde doit tre sous deux formes : une sauvegarde dans un fichier local (cot partie client de notre application) des informations de suivis et de pauses et une sauvegarde au niveau de la base de donnes (il sagit de la mise jour de la base de donnes par les informations en provenance de la partie client). Lutilisateur doit pouvoir travailler avec lapplication quil soit connect Internet ou non. Il aura besoin aussi dimporter des informations relatives ses tches de la base donnes. Ces

informations lui permettront de choisir la tches sur laquelle il doit travailler (lapplication aura indiquer son utilisateur le degr durgence de chacune de ses tches). A lexception dun super utilisateur qui aura la possibilit de consulter travers notre application toutes les tches des autres utilisateurs, ceux-ci ne doivent avoir que la permission dimporter les informations des tches les concernant. La mobilit de lutilisateur doit tre permise (cest pour cette raison quune version PALM de la partie client sera dveloppe). Lutilisateur doit galement pouvoir accder ses informations via le Web et sans avoir disposer de la partie cliente de lapplication installe chez lui.


-- 17 --

CHAPITRE 2

Etude du projet

2.2. La solution propose2.2.1. Description de la solution Apres avoir tudi ce projet, la solution que nous avons adopt est la suivante : Lapplication sera rpartie entre un serveur Web et le poste client (quil soit un ordinateur ou un terminal mobile PALM). Lchange des donnes entre ces deux parties se fera en utilisant des fichiers XML. La partie hberge au niveau du serveur Web sera charge de transformer les fichiers XML de mise jour, en provenance de la partie client de lapplication, en requtes SQL puis deffectuer la mise jour de la base de donnes. Elle aura aussi la tche dextraire les donnes demandes par lautre partie tout en les transformant en fichiers XML qui seront envoys chacun vers son demandeur. Pour rpondre au dernier besoin spcifi prcdemment, une page Web JSP sera dveloppe pour permettre lutilisateur dimporter depuis la base de donnes ou dexporter vers celle-ci nimporte o et sans avoir disposer de la partie client sur le poste duquel il se connecte cette page JSP. Cette page sera intgre au site Web de CACIOPEE. Lautre partie de lapplication, cot client, sera disponible en deux versions prsentant presque les mmes fonctionnalits. Une version pour ordinateur permettra son utilisateur dimporter des donnes de la base de donnes et/ou dexporter vers celle-ci les suivis de ses tches. Il pourra galement exporter ses suivis vers un autre emplacement (sur le disque local par exemple) et importer un fichier XML (ce fichier doit tre import de la base de donnes soit par cette partie mme ou via la page Web JSP dj cite) du disque local vers lapplication. En ce qui concerne la version PALM, elle prsentera toutes les fonctionnalits offertes par la version PC lexception de limport et de lexport base des fichiers. Les oprations dimport et dexport se feront en utilisant les connexions http uniquement. Cette restriction est impose par la plate forme J2ME. Il faut noter que chaque utilisateur de la version ordinateur la possibilit de crer un rpertoire qui lui sera rserv et qui contiendra touts ses fichiers XML quils soient de limport ou de lexport. Ce rpertoire sera cr lors de sa premire utilisation de cette partie. Les fichiers exports resteront dans ce rpertoire et ne seront supprims que si lutilisateur lordonne (la partie client version ordinateur disposera dun sous-menu clear qui permettra lutilisateur de nettoyer son rpertoire des fichiers quil a dj exports avec succs). Pour la partie PALM, la mme possibilit existe avec une diffrence au niveau de limplmentation. Pour la ralisation de notre projet on a opt pour le modle MVC comme technique dorganisation de travail, cette mthode sera bien dtaille dans le paragraphe qui suit.


-- 18 --

CHAPITRE 2 2.2.2. Le principe MVC

Etude du projet

MVC est un sigle pour "Modle, Vue, Contrleur" en franais, et c'est une technique de conception frquemment employe dans les projets bass sur la programmation orient objets, comme cest le cas pour notre projet. Cette technique a comme but de faciliter la modularit, la flexibilit et la rutilisation des composants programms, elle permet aussi dassocier plusieurs vues distinctes un mme modle. En plus, un changement au niveau de limplmentation dun modle (optimisation, rorganisation, ...) nimpliquerait pas forcment des changements au niveau des vues et des contrleurs. Cela va conduire en pratique la sparation des objets en une squence d'interaction particulire en trois catgories, chacune d'elles supportant une interface but gnral travers laquelle les 2 autres la connaissent. Ces trois parties sont : Le modle qui est la partie dcrivant les donnes afficher. La vue qui est la reprsentation graphique de ces donnes, et cest ce composant qui reprsente les couteurs du modle et qui est averti du changement des donnes. Le contrleur qui est la partie qui traite des interactions du composant avec lutilisateur. Cest cette partie qui demande changer une donne du modle. En dautres termes, le but est de sparer la vue du modle afin que les modifications de la premire naffectent pas le second et rciproquement. Le contrleur assure ce dcouplage. Le modle ne connat rien de lUI ; il fournit simplement un ensemble de services ou dAPI permettant de lire ou de modifier ltat du modle. Le contrleur associe ensuite, de manire standardise, le flux des informations et des vnements entre la vue et le modle [1]. Au stade de la conception, cela signifie que des changements dans les contrles ou les lments individuels de lUI naffectent en rien le modle. Au niveau de larchitecture, cela signifie que les changements du client naffectent pas le modle (voir la figure 2).


-- 19 --

CHAPITRE 2

Etude du projet

Figure 2 : Schma global du MVC Ladoption de cette technique comme dmarche de la ralisation de notre projet, va entraner que chaque module ralis doit imprativement sparer les interfaces de lutilisateur, qui reprsente la vue et le contrleur du model MVC, et les traitements qui vont reprsenter le model , ainsi et pour mieux illustrer lintrt dun tel choix, dans notre cas cette sparation va nous donner la possibilit de rutiliser quelques modules qui seront dvelopps pour un client Swing, au niveau du client PDA, sans avoir recours les reprogrammer (sauf pour des cas particuliers o la plateforme J2ME impose certaines restrictions), de ce fait linterface utilisateur et mme la plate-forme seront changs, mais le model des donnes est conserv puisque quil regroupe les traitements utiliss par lapplication indpendamment de lutilisateur et de la reprsentation graphique.

2.3. Etude technique2.3.1. Etat de lart de la programmation sous Palm OS Dans un premier temps, pour notre projet, on a d commencer par effectuer des recherches pour savoir ce qui existait en termes de programmation pour Palm OS. On a alors dcouvert que le terrain tait particulirement riche en ce qui concerne les outils, et les langages de programmation.

2.3.1.1. Le POSE (Palm OS Emulator)

Tout dabord, pour la programmation sous Palm OS, il est absolument ncessaire davoir un mulateur de Palm. Cet lment indispensable sert raliser et tester des applications tournant sur Palm OS directement sur PC et sans avoir ncessairement sous la main un terminal mobile de type PALM. Ce POSE a t suffisamment bien conu pour permettre dmuler un grand nombre de configurations de Palm (avec des versions diffrentes du systme dexploitation et des capacits en Projet de Fin dEtude : ENSIAS 2004 -- 20 --

CHAPITRE 2

Etude du projet

mmoire paramtrables) grce un systme de ROMs. Ces derniers sont indispensables au fonctionnement du POSE.

2.3.1.2. Programmation sur Desktop

Concevoir des applications tournant sous Palm OS est possible en utilisant le POSE. Cela est grce au fait quil est possible dutiliser nimporte laquelle des plates-formes comme environnement de dveloppement, il est aussi possible dutiliser une grande varit de langages et doutils. Ces environnements de construction dapplication sont, pour beaucoup, spcifiques la plate-forme partir de laquelle on dveloppe. Dans notre cas la plate-forme de dveloppement est Windows. En effet cest la plate-forme la plus riche, et quon peut y trouver la plus grande diversit doutils de dveloppement. On peut dcomposer le dveloppement sous Windows selon les langages, car en effet, il existe une dizaine de langages utilisables. Les principaux sont le C et le Java. Pour le langage C, le plus utilis dans le march de la programmation embarque, il existe une suite doutils de dveloppement gratuite base sur la suite Unixy de PRC-Tools. Dautres outils bass sur des IDE comme Visual C++ ou CodeWarrior sont aussi disponibles, et sintgrent plus ou moins bien cet environnement de dveloppement (Wizard du CDK pour Visual C++, version CodeWarrior for Palm OS , ). En ce qui concerne le langage Java, il existe l aussi plusieurs solutions. Toutes requirent linstallation dune machine virtuelle. Celle de Sun (KVM sintgre dans son projet de J2ME sappuyant sur la technologie MIDP), celle de IBM (appele J9) ainsi que Visual Age Micro Edition, soit VAME.

2.3.1.3. Programmation embarque

Dans le cadre du dveloppement dune petite application pour Palm OS, on peut aussi utiliser un langage embarqu. Cette solution consiste en le codage, la mise en place, et le test dun programme embarqu directement sur un terminal mobile quip du systme dexploitation Palm OS. Elle a lavantage dune plus grande simplicit de mise en place et donc une rapidit de dveloppement des applications. Cependant, dans certains cas, elle peut tre limitative et donne des applications plus lentes. Il existe une multitude de langages embarqus et denvironnement de dveloppement pour ces langages destins fonctionner sous Palm OS. Parmi ces langages on cite : le C, le Visual Basic, le Projet de Fin dEtude : ENSIAS 2004 -- 21 --

CHAPITRE 2 Lua, Forth, Ruby, Lisp, Python,

Etude du projet

Ceux-ci se divisent en deux : les outils qui ncessitent une sorte de machine virtuelle (appele Runtime) sans laquelle il ne peuvent pas tourner, et ceux qui nen ont pas besoin (dits standalone). Les outils gnrant un excutable qui ncessite un runtime sont plus nombreux que ceux qui gnrent des autres.

2.3.2. Choix du langage Java sous la plate-forme J2ME Notre choix sest fait sur le langage JAVA, pour les raisons suivantes : Java est un langage portable, sr et orient objets. En outre cest le langage de programmation que CACIOPEE adopte pour la ralisation de ses projets. En Java, il existe des cadres de travail ou framework qui ont dj prvu certaines fonctionnalits avec un certain nombre de classes et dinterfaces offrant une API simple et intuitive la fois pour programmer des applications pour Palm. Le Software Development Kit destin au dveloppement des applications embarques savoir J2ME Wirless ToolKit, et ventuellement le Conduit Development Toolkit qui contient des librairies, des enttes et des outils pour la programmation pour Palm, sont disponibles gratuitement. La rutilisation de quelques modules, concernant la logique mtier de lapplication (cette logique qui sera la mme pour le client ordinateur et le client Palm), et qui seront dvelopps en JAVA dans la partie destine au client Swing (plate-forme J2EE) de notre projet. Lexcution de notre application ne serait pas limite aux terminaux Palm OS, et peut tre tendue vers dautres priphriques mobiles, sil y aurait des besoins futurs.

2.3.3. Prsentation de la plate-forme J2ME2.3.3.1. Gnralit

Java 2 Micro Edition est une architecture technique dont le but est de fournir un socle de dveloppement aux applications embarques. Lintrt tant de proposer toute la puissance dun langage tel que Java associ aux services proposs par une version bride du Framework J2SE (voir la figure 3). Les terminaux nayant pas les mmes capacits en terme de ressources que les ordinateurs de bureau classiques (mmoire, disque et puissance de calcul), la solution passe par la fourniture dun environnement allg afin de sadapter aux diffrentes contraintes dexcution. Cependant, comment faire en sorte dintgrer la diversit de loffre un socle Projet de Fin dEtude : ENSIAS 2004 -- 22 --

CHAPITRE 2

Etude du projet

technique dont la cible nest pas dfinie priori ? La solution propose par J2ME consiste regrouper par catgories certaines familles de produits tout en proposant la possibilit dimplmenter des routines spcifiques un terminal donn [2]. L'architecture J2ME se dcoupe donc en plusieurs couches : Les profiles : ils permettent une certaine catgorie de terminaux dutiliser des caractristiques communes telles que la gestion de laffichage, des vnements dentres/sorties (pointage, clavier, ) ou des mcanismes de persistance (Base de donnes lgre intgre). Ces profiles sont soumis spcifications suivant le principe du JCP (Java Community Process) Les configurations : elles dfinissent une plate-forme minimale en terme de services concernant un ou plusieurs profiles donns. Les machines virtuelles : en fonction de la cible, la machine virtuelle pourra tre allge afin de consommer plus ou moins de ressources (KVM, CVM, ) Le systme dexploitation : Lenvironnement doit sadapter au systme

dexploitation existant (Windows CE, Palm Os, SavaJe, Symbian )

Figure 3 : Architectures J2ME2.3.3.2. Les configurations

Cette architecture (J2ME) en couche a pour but de factoriser pour des familles de produits donnes un ensemble dAPI permettant une application de sexcuter sur plusieurs terminaux sans modification de code. Dans cette optique, la plate-forme propose deux configurations :


-- 23 --

CHAPITRE 2

Etude du projet CDC (Connected Device Configuration) : cette configuration spcifie un environnement pour des terminaux connects de forte capacit tels que les set top boxes , les tlphones cran, la tlvision numrique, Les caractristiques de lenvironnement matriel propos par la configuration CDC sont : Un minimum de 512Ko de ROM et 256Ko de RAM et un processeur 32 bits. Une connexion rseau obligatoire (sans fil ou pas). Un support des spcifications compltes de la machine virtuelle Java (CVM). Cette configuration sinscrit donc dans le cadre dune architecture Java presque complte. CLDC (Connected Limited Device Configuration) : Cette configuration sadresse aux terminaux lgers tels que les tlphones mobiles ou les assistants personnels. Ces priphriques tant limits en terme de ressources, lenvironnement classique ne permet pas de respecter les contraintes doccupation mmoire lie ces appareils. J2ME dfinie donc un ensemble dAPI spcifique CLDC et destines utiliser les particularits de chaque terminal dune mme famille (profile). La liste suivante rsume lensemble de ces caractristiques : Un minimum de 160Ko 512Ko de RAM, processeur 16 ou 32 bits, vitesse 16Mhz ou plus. Une alimentation limite, prise en charge dune batterie. Une connexion rseau non permanente, sans fil. Une interface graphique limite ou inexistante.

Notons que cest au niveau de la configuration CLDC que se localise la cible de notre application. Cette configuration sinscrit donc dans une logique dconomie de ressources avec une KVM de 40 80 Ko sexcutant 30 80% moins vite quune JVM normale. Il ny a aucun compilateur JustIn-Time ni mme de prise en charge des nombres flottants. Quant au Multi-threading et au Ramasse miettes, ils demeurent supports. Toutefois, CLDC nintgre pas la gestion des interfaces graphiques, la persistance ou les particularits de chaque terminal. Ces aspects ne sont pas de sa Projet de Fin dEtude : ENSIAS 2004 -- 24 --

CHAPITRE 2

Etude du projet

responsabilit. La matrice suivante rsume les packages et classes prsentes dans cette couche : Java.io Java.lang Java.util Javax.microedition.io Fournit la gestion des flux dentres/sorties Classes de base du langage (types, ) Contient les collections et classes utilitaires Classes permettant de se connecter via TCP/IP Tableau 3 : Liste des packages de CLDC Le package javax.microedition.io fait partie des briques non incluses dans J2SE tel quil est illustr dans le schma suivant.

Figure 4 : Les diffrentes configurations de larchitecture J2ME2.3.3.3. Les profiles

MIDP (Mobile Information Device Profile) est la base de limplmentation des classes lies un profile donn. On y trouve les mthodes permettant de grer laffichage, la saisie utilisateur et la gestion de la persistance (base de donnes). Il existe aujourdhui deux implmentations majeures du profile MIDP. Lune, plus spcifique, destine aux Assistants de type Palm Pilot (quip dun Palm OS) et lautre, totalement gnrique, propose par Sun comme implmentation de rfrence (RI). Ces profiles sont en libre tlchargement sur le site de Sun et intgrent plusieurs mulateurs permettant de tester les applications de manire logicielle. Les API lies MIDP font aussi partie de ce package :


-- 25 --

CHAPITRE 2 javax.microedition.lcdui javax.microedition.midlet javax.microedition.rms

Etude du projet Fournit la gestion de linterface utilisateur (contrles, ) Socle technique destin grer le cycle de vie des midlets Base de donnes persistante lgre

Tableau 4 : Liste des packages du MIDP LAPI lcdui est charge de grer lensemble des contrles graphiques proposs par ce profile. Quant la gestion des vnements, elle suit le modle des listeners du J2SE avec un CommandListener appel en cas dactivation dun contrle. Pour finir, io et rms , eux, fournissent respectivement les routines ncessaires aux entres/sorties du rseau et la prise en charge dune zone physique de stockage (voir figure 5).

Figure 5 : Package MIDP et CLDC Le MIDP 1.0, avec lequel on a travaill, prsente les limitations suivantes : Une MIDlet supporte uniquement .png comme format d'image. Sa gestion du rseau se limite aux requtes HTTP. Il n'y a aucune interface avec la carte SIM et avec les SMS (Short Message System) [3].2.3.3.4. Les Midlets

Les Midlets sont l'lment principal d'une application Java embarque. Pour bien saisir leur mode de fonctionnement, il suffit de prendre comme analogie les applets ou les servlets. Le cycle de vie dune applet est gr par un conteneur, en loccurrence le navigateur Web dont le rle est dinteragir avec celle-ci sous la forme de mthodes de notifications prdfinies

(init(),paint(),destroyed(),). Une servlet possde les mmes caractristiques quune applet Projet de Fin dEtude : ENSIAS 2004 -- 26 --

CHAPITRE 2

Etude du projet

except le fait que le conteneur est un moteur de servlet (Tomcat, WebSphere, WebLogic, ). Quant aux Midlets, ils reprsentent le pendant des applets et des servlets pour J2ME avec comme conteneur un tlphone mobile ou un assistant personnel. Ainsi, en cas de mise jour dune application embarque, un simple tlchargement de code Midlet est ncessaire partir dun quelconque serveur. De cette manire, un programme dvelopp pour un profile donn est en mesure de sexcuter sur tous les priphriques correspondant cette famille. Cest aussi une manire de dcoupler le socle technique des applicatifs puisque le seul lien existant entre les logiciels embarqus et le terminal est lAPI J2ME. Une Midlet possde essentiellement trois mthodes qui permettent de grer le cycle de vie de l'application (voir la figure 6) en fonction des trois tats possibles (active, suspendue ou dtruite) :

startApp() : la mthode appele chaque dmarrage ou redmarrage de l'application pauseApp() : la mthode appele lors de la mise en pause de l'application destroyApp() : la mthode appele lors de la destruction de l'application

Figure 6 : Modle du cycle de vie dune Midlet.


-- 27 --

CHAPITRE 2

Etude du projet

ConclusionDans ce chapitre, nous avons spcifi les besoins de lorganisme daccueil auxquels lapplication objet de notre PFE doit rpondre. Ensuite nous avons expos brivement la solution que nous avons adopte. Et enfin nous avons tal une tude technique pour ce qui existait en termes de programmation pour Palm OS ainsi quune prsentation de la technologie choisie. Le chapitre suivant sera consacr la phase danalyse et de conception et prsentera cette solution en dtail.


-- 28 --

CHAPITRE 3

Analyse et conception



Apres avoir prsent la phase tude du projet, et dcrit la solution propose selon une spcification de besoins tabli au pralable, nous ddions ce troisime chapitre la phase analyse et conception. Nous commenons tout dabord par prsenter le langage utilis pour la conception de la solution, et nous prsentons ensuite les diffrents parties de la conception de notre projet, entre outre les diagrammes UML de lapplication, et ceci afin de mieux comprendre son fonctionnement.

3.1. Prsentation du langage de modlisation UMLUML (Unified Modeling Language traduit en franais par "langage de modlisation objet unifi") est n de la fusion des trois mthodes qui ont le plus influenc la modlisation objet au milieu des annes 90 : OMT, Booch et OOSE. Issu du "terrain" et fruit d'un travail d'experts reconnus, UML est le rsultat d'un large consensus. De trs nombreux acteurs industriels de renom ont adopt UML et participent son dveloppement [4]. Il y a donc dj longtemps que l'approche objet est devenue une ralit. Les concepts de base de l'approche objet sont stables et largement prouvs. De nos jours, programmer "objet", c'est bnficier d'une panoplie d'outils et de langages performants. L'approche objet est une solution technologique incontournable. Ce n'est plus une mode, mais un rflexe quasi-automatique ds lors qu'on cherche concevoir des logiciels complexes qui doivent "rsister" des volutions incessantes. UML est un langage de modlisation objet trs puissant qui donne une dimension mthodologique l'approche objet et qui permet de mieux matriser sa richesse. Il permet de :

reprsenter des concepts abstraits (graphiquement par exemple) ; limiter les ambiguts (parler un langage commun, au vocabulaire prcis,

indpendant des langages orients objet) ;

faciliter l'analyse (simplifier la comparaison et l'valuation de solutions).

Lapplication dune dmarche d'analyse et de conception objet, va permettre dviter deffectuer Projet de Fin dEtude : ENSIAS 2004 -- 29 --

CHAPITRE 3


une analyse fonctionnelle et de se contenter d'une implmentation objet, mais il pousse penser objet ds le dpart. En plus, il permet de dfinir les vues qui permettent de dcrire tous les aspects d'un systme avec des concepts objets. UML permet donc de modliser une application selon une vision objet, en possdant plusieurs facettes. C'est une norme, un langage de modlisation objet, un support de communication et un cadre mthodologique. UML est tout cela la fois, ce qui semble d'ailleurs engendrer quelques confusions. UML a t adopt (normalis) par l'OMG et intgr l'OMA, car il participe cette vision et parce qu'il rpond la "philosophie" OMG.

3.2. Analyse des besoins fonctionnels3.2.1. Cas dutilisations Durant lanalyse du projet, nous avons dgag lexistence de deux acteurs externes qui interagissent avec notre application, il sagit de lutilisateur et de la base de donnes. Ltude prliminaire permet de faire ressortir les cas dutilisation (voir le tableau 5 et la figure 7). Cas dutilisation Identification Message (mis/reu) Emis : login et password. Reu : Ouverture de session ou refus daccs Suivi des tches Utilisateur Emis : Action relative au suivi, ou synchronisation, ou gestion de profile. Import des donnes Utilisateur Emis : requte dimport. Reu : fichier xml des donnes importes. Export des donnes Utilisateur Emis : fichier xml des donnes exporter. Reu : confirmation ou infirmation de lexport. Lire depuis la base de donnes Base de donnes Emis : requte de la lecture Reu : rsultat correspondant Ecrire dans la base de donnes Base de donnes Emis : Ajout, ou modification dlments de la BD Tableau 5 : Identification des cas dutilisation 3.2.2. Diagramme de cas dutilisations Linteraction entre cette base de donnes et lapplication objet de notre PFE se rsume en la mise jour et la consultation de cette base. Quant lutilisateur, il profite de toutes les possibilits de Projet de Fin dEtude : ENSIAS 2004 -- 30 -Acteur Utilisateur

CHAPITRE 3


gestion de ses tches que notre application lui permet .Toutefois, il ne pourra pas en bnficier sauf si son identification est valide, et un import de donnes est effectu. En outre, lutilisateur a aussi la possibilit dimporter des donnes relatives ses tches de la base de donnes, ou dexporter les donnes des suivis vers la partie de lapplication du cot serveur qui se chargera de synchroniser avec la base de donnes(voir figure 7).

Suivi des tches

Identification

Utilisateur Import des donnes Lire de la base de donnes Base de Donnes

Ecrire dans la base de donnes Export des donnes

Figure 7 : Diagramme des cas dutilisation.

3.3. Spcifications techniques3.3.1. Diagramme des composants (figure8) Le style darchitecture en partie spcifie lorganisation des composants dexploitation mis en uvre pour raliser le systme. Chaque partie indique une responsabilit technique laquelle souscrivent les diffrents composants dexploitation dun systme. On distingue donc plusieurs types de composants en fonction de la responsabilit technique quils jouent dans le systme. Un systme client/serveur fait rfrence au moins deux types de composants, qui sont les systmes de base de donnes du serveur, et les applications clientes qui en exploitent les donnes.


-- 31 --

CHAPITRE 3


DAL

SGBDR

Serveur

Swing

XML.jar

PDA

Web

DesktopIndicator. DLL

config.xml

Figure 8 : Diagramme des composants du systme environnant. La partie cliente de notre application sera subdivise en trois modules savoir : module Swing : ce module reprsente la version de notre application qui sera excut sous PC, cette partie utilisera une librairie Windows, pour pouvoir afficher un icne de lapplication dans la tray Bar . module PDA : ce module reprsente la version de notre application qui sera ddie au terminal mobile PDA utilisant un systme dexploitation Palm OS. module Web : ce module va permettre un accs via le Web, pour que lutilisateur puisse extraire les informations qui lui sont relatives, dans le cas ou seule la connexion http sera permise. Chacune des deux units Swing et PDA de notre projet va se baser sur un fichier de configuration config.xml , qui lui permettra de stocker les diffrents profiles des utilisateurs et de pouvoir les charger lors de chaque nouvel accs. Le module de la partie serveur de notre application utilise un package gnrique DAL (Data Access Layer), qui va permettre la communication avec la base de donnes. Alors quel e module XML , reprsentera un package .jar , qui sera dvelopp afin dassurer la communication avec les fichiers Xml manipuls par les diffrentes parties de notre projet. Projet de Fin dEtude : ENSIAS 2004 -- 32 --

CHAPITRE 3 3.3.2. Organisation du modle de spcification logicielle3.3.2.1. Dfinition


Couche Logicielle : Une couche logicielle reprsente un ensemble de spcifications ou de

ralisations qui respectivement expriment ou mettent en uvre un ensemble de responsabilits techniques et homognes pour un systme logiciel. Les couches sempilent en niveaux pour couvrir des transformations logicielles successives, de sorte que la couche dun niveau ne puisse utiliser que les services des couches des niveaux infrieurs. Le recours aux couches logicielles va nous permettre daffiner la spcification technique en divisant le problme en sous parties spcialises. Cette organisation correspond au style darchitecture en couches prconis pour le dveloppement dune solution client serveur.

3.3.2.2. Modularit et organisation des packages

Les packages de notre application ont t organiss de telle faon sparer entre tous ce qui est traitement et logique mtier de lentreprise, contenu dans le package BL acronyme de

Business Layer , et tous ce qui est prsentation et interface utilisateur. Que ce soient des formes swing, des pages Web, ou des servlets, cette couche est enveloppe dans le package PL acronyme de Presentation Layer , lautre package DAL acronyme de Data Access Layer reprsente la couche accs aux donnes tandis que le dernier package common contiendra dautres librairies et classes dont notre application aura besoin pour son fonctionnement. Ainsi, du cot serveur (voir figure 9) lencapsulation des classes est faite de la manire dj dcrite, en plus cette partie de notre projet sera lors de son dploiement intgre dans le projet phoenix de lentreprise. Cela va impliquer que notre architecture organisationnelle des packages sera conforme celle adopte pour le projet phoenix , et cest pour cette raison l quon trouve que les diffrentes parties de notre application sont empaquetes dans un package com.caciopee.phoenix .


-- 33 --

CHAPITRE 3


com

caciopee

phoenix

pl

bl

dal

common

service

Figure 9 : Empaquetage des classes cot serveur. En ce qui concerne lempaquetage de la partie de lapplication cot client, que a soit celle du PDA ou du Swing, on a conserv la mme architecture de modularit.

3.3.3. Diagramme de package Le diagramme de package (voir figure 10) reprsente les diffrents modules de notre projet, ainsi que les divers relations existantes entre chacun deux. Il contient les packages suivants : Package DAL : cest un package dvelopp au sein de lorganisme daccueil, il sert de couche intermdiaire entre la base de donnes et toutes les applications destines lutiliser (y compris lapplication objet de notre PFE). Package SynchronizeClientSide : Ce package englobe toutes les classes cot client ncessaires pour la communication avec la base de donnes pour synchroniser dventuels changement au niveau des suivis, et au niveau des informations relatives aux projets de lutilisateur concern. Il faut rappeler que cette communication nest pas directe mais passe travers la partie du cot serveur de notre application. Package com.caciopee.phoenix.pl.dbSide : Ce package qui reprsente la partie prsentation, contient toutes les classes du cot serveur, qui assurent la communication avec la partie cliente du projet. il est subdivis en deux parties : importpackage : reprsente linterface de lapplication, entre le client et la logique mtier du projet, elle se charge des requtes dimport, en Projet de Fin dEtude : ENSIAS 2004 -- 34 --

CHAPITRE 3

Analyse et conception provenance dun client Web (package importfromweb , dun client Swing (package importfromswing ) ou dun client PDA (package importfrompda ). exportpackage : joue le mme rle que le package ci-dessus, sauf que celui la se charge des requtes dexport, elle englobe aussi deux packages selon le client, savoir exportfromswing ,

exportfromweb et exportfrompdaweb . Package com.caciopee.phoenix.bl.service.dbSide : cette entit encapsule toute la logique mtier de notre projet concernant les traitements sur les fichiers cot serveur, la communication avec le module DAL , lassurance de lchange des fichiers ncessaires et la signalisation dventuels erreurs qui peuvent survenir nimporte quel moment lors de cette phase de communication client/serveur. Elle est divise en deux parties : importpackage , et exportpackage . Package XML : Vue que notre application se base essentiellement sur les fichiers XML, et dans le but de faciliter lutilisation de lAPI JAXP tout en garantissant la lisibilit du code source de notre application, nous avons dvelopp deux version de ce package. Ce package fournit un certain nombre de services utiles pour le traitement des fichiers XML. Nous lavons dvelopp sous deux versions : une version pour SWING, et une autre pour PDA, cette dernire utilise lAPI KXML ddie principalement aux terminaux mobiles. Package com.caciopee.tasksmanagement : Ce package englobe toutes les classes ncessaires pour accder lapplication, effectuer les suivis et synchroniser avec le serveur. Il contient en plus de la partie common deux autres parties savoir : pl.jobslogsswing : reprsente linterface utilisateur pour la partie Swing. pl.jobslogspda : reprsente linterface utilisateur pour la partie mobile. bl.jobslogsbusiness : regroupe tous les traitements relatifs la partie cliente de notre application. Elle est dveloppe en deux versions, une pour Swing, et une autre pour PDA compte tenu des limitations prsentes pour cette plate-forme. bl.synchronizeclientside : regroupe tous les traitements relatifs la partie synchronisation avec le serveur. Elle est aussi dveloppe en deux versions selon la plateforme.


-- 35 --

CHAPITRE 3


Figure 10 : Diagramme de packages. Projet de Fin dEtude : ENSIAS 2004 -- 36 --

CHAPITRE 3


3.4. Modles statiques et dynamiques3.4.1. Diagrammes de squences Afin de bien illustrer les cas dutilisations dj labors, et dans le but de mieux reprsenter les interactions entre les objets de notre projet selon un point de vue temporel, nous avons utilis les diagrammes de squences suivants : Diagrammes de squences des interactions base de donnes- application : Ce sont les diagrammes de squence les plus simples que nous avons utilis. Ils dcrivent deux scnarios savoir la lecture de la base de donnes et lcriture dans celle-ci.

: Base de donnes

DAL

FromDbToXml

DbSideReaderEntity cration.

connexion et lecture des donnes.

connexion et lecture des donnes. gnration du fichier XML importer.

le fichier XML d'import.

Figure 11 : Diagramme de squences du scnario de la lecture de la base de donnes.

La figure 11 reprsente le diagramme de squence du scnario de lecture de donnes partir de la base de donnes. Quand lobjet DbSideReaderEntity est cr, il instancie la classe FromDbToXml qui cre son tour lobjet DAL (Data Access Layer). Cette dernire classe est dveloppe au sein de CACIOPEE pour les accs aux bases de donnes et permet de jouer le rle de passerelle entre les diffrentes applications dveloppes au sein de lorganisme daccueil et les bases de donnes utilises. A travers lobjet DAL, lobjet FromDbToXml restitue les informations dsires partir de la base de donnes utilise par CACIOPEE pour la gestion de ses projets. A partir de ces informations, il construit un fichier XML qui sera pass lobjet DbSideReaderEntity appelant puis envoy la partie cliente de lapplication objet de notre PFE. Projet de Fin dEtude : ENSIAS 2004 -- 37 --

CHAPITRE 3


DAL : Base de donnes

FromXmlToDb

DbSideWriterEntity

rception du fichier xml exporter. mise jour de la base de donnes. cration cration

tat de l'opration.

Figure 12 : Diagramme de squences scnario de lcriture dans la base de donnes.

Quand DbSideWriterEntity est activ (voir la figure 12), il sauvegarde le fichier XML reu puis cre lobjet FromXmlToDb . Ce dernier utilise des objets du DAL pour effectuer la mise jour de la base de donnes. Si une erreur survient, un message derreur est renvoy par FromXmlToDb lobjet qui la cre. Sinon, lobjet DbSideWriterEntity rcupre un message lui signalant que lopration a t bien excute.

Diagrammes de squences de lidentification dun utilisateur Dans le cas dutilisation identification deux possibilits se prsente : un nouvel utilisateur qui utilise lapplication pour la premire fois (voir la figure 13) ou un ancien utilisateur (voir la figure 14). Diagramme de squences dun nouvel utilisateur Quand cest la premire fois quun utilisateur veut profiter de notre application, il doit dabord cliquer sur le bouton New User de lcran didentification. Ensuite, un cran de bienvenue reprsent dans la figure 13 par lobjet WelcomeForm est cr et affich invitant le nouvel utilisateur saisir son login et son mot de passe et choisir un rpertoire personnel qui contiendra tous ses fichiers dimport et dexport. Puis lobjet BeginningDemon est cr pour dmarrer la premire utilisation de lapplication pour ce nouvel utilisateur et dclencher le traitement li cette premire utilisation qui consiste en un avertissement pour limport des informations relatives aux pauses et aux tches de cet utilisateur. Finalement, lobjet SessionDemon est cr ainsi que Projet de Fin dEtude : ENSIAS 2004 -- 38 --

CHAPITRE 3


lobjet TaskMgmtForm et lutilisateur naura qu importer ces informations avant de profiter de notre application

IdentificationForm: Utilisateur

WelcomeForm

BegenningDemon

SessionDemon TaskMgmtForm

nouvel utilisateur.

cration et affichage.

saisie des informations de l'utilisateur. dmarrage de la premire utilisation. traitement nouvel utilisateur. dbut session.


Figure 13 : Diagramme de squences scnario dun nouvel utilisateur.

Diagramme de squences dun ancien utilisateur : Un ancien utilisateur est un acteur dont le systme possde dj des informations qui lui sont propres, ainsi aprs avoir valid son compte et son mot de passe, le systme active un dmon de dmarrage afin de vrifier sil ya des avertissements dclencher, ou des anomalies signaler lutilisateur, et de paramtrer la session avant de commencer une nouvelle utilisation de lapplication.


-- 39 --

CHAPITRE 3


IdentificationForm BegenningDemon SessionDemon TaskMgmtForm WarningXportForm WarningImportForm: Utilisateur Valider login et mot de passe. traitement de dmarrage.

entrer login et mot de passe.

cration et initialisation.

cration et affichage s'il faut avertir pour l'export. traitement d'avertissement d'export. cration et affichage s'il faut avertir pour l'import. traitement d'avertissement d'import. dbut de session.


Figure 14 : Diagramme de squences du scnario de lidentification.

Quand un utilisateur saisit son login et son mot de passe (voir la figure 14), lobjet IdentificationForm vrifie la validit de ces deux informations. Si elles ne sont pas valides, un message derreur est affich. Dans le cas o les informations saisies sont correctes, lobjet IdentificationForm cre et initialise lobjet BeginningDemon . Ce dernier effectue le traitement de dmarrage qui consiste en la recherche dans le profile de lutilisateur courant, contenu dans le fichier de configuration users.xml de lapplication, des ventuels avertissements possibles. Lorsque la condition de lavertissement de lexport est vrifie, lobjet WarningXportForm est cr et affich pour prvenir lutilisateur de la ncessit dexporter ses donnes. Il aura la possibilit de choisir entre un export immdiat et un report de lexport une date ultrieure. Aprs avoir termin avec lexport, la condition dimport est examine. Sil faut Projet de Fin dEtude : ENSIAS 2004 -- 40 --

CHAPITRE 3


avertir lutilisateur de la ncessit dimporter des donnes, un message davertissement est affich, sinon rien ne se passe. Quand le traitement davertissement de limport est termin, lobjet SessionDemon est cr ainsi que lobjet TaskMgmtForm qui reprsente lcran principal de lapplication.

Diagramme de squences des suivis des tches (figure 15) Aprs stre identifi entant que nouvel ou ancien utilisateur, ce dernier dbute le suivi des tches quil va effectuer, en signalant chaque fois au systme lopration ralise, ces oprations peuvent tre relatives soit : la gestion du suivi des tches : savoir la signalisation dun dbut, dune interruption, ou dune fin dun suivi. En plus de la possibilit de pouvoir visualiser les proprits dune tche donne. Pendant le suivi dune tche le systme cre et modifie fur et mesure le fichier XML contenant les informations relatives aux suivis. lutilisateur : concernant la configuration de ses paramtres, ou le nettoyage de son disque dur des fichiers dj exports. La configuration des paramtres de lutilisateur concerne lactivation ou la dsactivation soit de lavertissement de limport ou de lexport, en plus de loption de la suppression automatique qui entranera selle est active le nettoyage implicite aprs chaque synchronisation. la synchronisation avec la base de donnes : en effectuant limport et lexport soit dun ou vers un fichier local, ou la mise jour directes avec le serveur de la base de donnes. Durant tout le suivi, notre systme utilise des fichiers XML pour lextraction des donnes et des informations relatives aux tches et aux interruptions. Il gnre aussi des fichiers XML contenant les rsultats des suivis effectus. Lutilisateur a le choix dimporter localement les fichiers XML dimport, et dexporter le fichier rsultant pour une synchronisation par lentremise du Web ou autre.


-- 41 --

CHAPITRE 3


: Utilisateur

TaskMgmtForm

SessionDemon

InterruptionForm

EvaluationForm

UserProfile ConfigForm

TaskProperties Form

slectioner une tche. dbut tche (play).

dbut traitement tche.

interrompre tche(pause). dbut traitement pause. play. cration et affichage.

saisir informations de pause. fin traitement pause.

fin tche (stop). cration.

saisir informations tche. configurer profile. fin traitement tche. cration et affichage. sauvegarde de la configuration. visualiser les proprits d'une tche selectionne. cration et affichage.

Figure 15 : Diagramme de squences du scnario du suivi des tches.

Diagramme de squences de la synchronisation : La synchronisation est lopration qui permet lchange dinformation entre la partie cliente de notre application et sa partie cote base de donnes travers internet (voir la figure 16). Quand lutilisateur choisit de synchroniser, lobjet TaskMgmtForm instancie lobjet ExportClass qui se charge dtablir la connexion avec la servlet ServletXport ainsi que lenvoi du fichier XML exporter vers celle-ci. Cette servlet cre lobjet DbSideWriterEntity qui aura la tche doprer une mise jour de la base de donnes partir des informations contenues dans le fichier export. Au cas o une erreur est survenue pendant lenvoi, la servlet le signale lobjet Projet de Fin dEtude : ENSIAS 2004 -- 42 --

CHAPITRE 3


ExportClass qui affiche alors un message derreur pour lutilisateur. Dans le cas contraire, le fichier export est pass lobjet DbSideWriterEntity . Si une erreur survient lors de la mise jour de la base de donnes, cet objet envoie un message derreur lobjet ExportClass qui le transmettra lutilisateur sans entamer la procdure dexport. Sinon, la confirmation du succs de la mise jour est envoye ExportClass . Ensuite lobjet TaskMgmtForm instancie lobjet ImportClass qui sera charg de se connecter la servlet dimport reprsente par lobjet ServletImport et dimporter un fichier XML dimport qui sera gnr selon le scnario de la figure 11 par lobjet DbSideReaderEntity . Ce dernier objet sera cr par la servlet dimport. Si tout va bien, le fichier XML dsir sera envoy lobjet ImportClass qui va le sauvegarder dans le dossier personnel de lutilisateur courant. Sinon, un message derreur est transmis ImportClass puis est affich lcran.

TaskMgmtForm : Utilisateur synchro...

ImportClass

ExportClass

ServletImport DbSideReaderEntity

ServletXport

DbSideWriterEntity

instanciation.

connexion et envoi du fichier xml exporter. message d'erreur s'il existe. passage du fichier xml exporter

message d'erreur d'export s'il existe.

confirmation ou message d'erreur. confirmation ou message d'erreur.

instanciation.

connexion et ordre d'import.

ordre d'import.

fichier d'import ou message d'erreur. message d'erreur d'import s'il existe.

fichier d'import ou message d'erreur.

Figure 16 : Diagramme de squences du scnario de la synchronisation.


-- 43 --

CHAPITRE 3 3.4.2. Diagrammes de classes


Un diagramme de classes est une collection d'lments de modlisation statiques qui permet de reprsenter la structure statique dun systme, et en particulier les types dobjets manipuls dans le systme, leurs structures internes et les relations entre eux. Aprs avoir dfini les objets de notre systme, nous prsentons, dans ce qui suit, la structure statique de notre projet en terme de classes et relations classes selon les packages qui les regroupent. Package SynchronizeClientSide : Ce package contient 3 classes (voir figure 17): ImportClass : cette classe est charge dtablir la connexion avec le serveur, de tlcharger le fichier XML des informations qui concernent lutilisateur courant puis dextraire les donnes de ce fichier. XportClass : cette classe se charge de se connecter avec le serveur et de lui envoyer le fichier XML de lexport tout en rcuprant la rponse du serveur, partir de laquelle sera indiqu lutilisateur une confirmation dune synchronisation russite ou une information de la survenance dune erreur lors de cette opration. CallServlet : cette classe permet dinitier les connexions http avec les servlets de la partie serveur et de rcuprer la rponse de ce dernier. Elle est utilise par les deux classes ImportClass et XportClass lors de la synchronisation avec le serveur. Package dbSide : Ce package contient quatre classes (voir figure 17): WritingServletSwing et WritingServletWeb : ces classes prennent en charge la requte de lexport en provenance de lutilisateur, et assure la gestion de lopration de lexport. La premire classe est destine interagir avec les requtes provenant des clients java de notre application tandis que la seconde est charge de satisfaire les requtes effectues via la page Web de lexport. ReadingServletSwing et ReadingServletWeb : ces classes prennent en charge la requte de limport de donnes, et assure lenvoi du fichier XML de limport vers la partie client. Comme les deux classes de lexport dcrites ci-dessus la premire classe gre les requtes en provenance de lapplication swing tandis que la deuxime classe se charge des requtes issues de la page Web de limport. FromDbToXml : cette classe prend en charge lextraction des donnes ncessaires de la base de donnes et la gnration du fichier XML de limport, ce fichier qui servira aprs de base de donne locale contenant toutes les informations ncessaires un utilisateur pour quil puisse procder aux suivis des tches quil va effectuer. Projet de Fin dEtude : ENSIAS 2004 -- 44 --

CHAPITRE 3


FromXmlToDb : comme son nom lindique, cette classe se charge de la mise jour de la base de donnes partir des informations contenu dans le fichier XML de lexport gnr par notre application se trouvant du cot client lors des suivis effectus par ce dernier.

ImportClass userPath pwd login fileLength message current done 1..n ImportClass() ImportFromServer() CallServlet() ClientSocket() ExtractData() ExtractConnectionVariable() GetCurrent() GetMessage() IsDone() 1..n ReadingServletSwing login pwd XmlFilePath PortNumber DoGet() SettingPortNumber() ServerSocket() 0..1

ServletCall url response 1..n ServletCall() 1..n CallServletFct() 1 1

XportClass fileLength message current done 1..n XportClass() XportToServer() CallServlet() ClientSocket() GetCurrent() GetMessage() IsDone()

Xml 1..n WritingServletSwing XmlFilePath PortNumber DoGet() SettingPortNumber() ServerSocket() 0..1

DAL

1 FromDbToXml login pwd FromDbToXml() GenerateXml() establishConnection() accessGranted() InitialiseXmlFile() ExtractUserInfo() GetUserTasks() GetInterruptions() SerialiseXmlFile() CloseConnection()

1 FromXmlToDb FromXmlToDb() DoUpdate() GetInterruptTime() dateToString() getGCalendarFromString() getInterruptionTime() startOfTask()

Figure 17 : Diagramme de classes regroupant les deux packages SynchronizeClientSide et DbSide


-- 45 --

CHAPITRE 3 Package XML : Ce package contient 3 classes (voir figure 18):


XmlWriter : cest une classe utilitaire qui contient toutes les fonctions possibles pour crer et modifier un fichier XML dune manire simple tout en ayant des noms significatifs.

XmlReader : cest une classe utilitaire qui contient toutes les fonctions possibles pour effectuer la lecture ou la recherche dans un fichier XML. Serialiser : cest une classe utilise pour enregistrer les donnes dans un fichier XML dune manire appropri et conforme.XmlWriter CreateXmlInstance() Initialise() GetRoot() CreateTag() CreateAttribute() AddText() ChangeAttribute() ChangeText() DeleteTag() Serialise()

XmlReader Initialise() FindTagByChild() FindTagByAttribute() FindFirstElement() GetTextTag() GetTextAttribute() FindAllTags() GetText()

Serialiser Serialiser() Serialise() SerialiseNode()

Figure 18 : Diagramme de classes du package XML Package JobsLogsSwing : Ce package contient 13 classes. IdentificationForm : cette classe reprsente linterface graphique de lidentification dun utilisateur. WelcomeForm : cette classe reprsente les interfaces graphiques du processus qui prend en charge les nouveaux utilisateurs. WarningXportForm : cette classe reprsente linterface graphique indiquant lutilisateur quil doit procder un export des suivis dj effectus afin dactualiser les donnes sur lesquelles il travaille. Cette fentre apparat automatiquement lorsque le dlai indiqu par lutilisateur dans la configuration de son profile, est dpass. Projet de Fin dEtude : ENSIAS 2004 -- 46 --

CHAPITRE 3


WarningImportForm : cette classe reprsente linterface graphique utilise pour avertir lutilisateur quune dure donne (fixe et peut tre configure par lutilisateur) a dcoule sans quil ait effectu un import de ses donnes.

TaskMgmtForm : cette classe reprsente linterface graphique capitale de lapplication, elle permet principalement le suivi des tches, la synchronisation ainsi que la gestion du profile de lutilisateur.

InterruptionsForm : cette classe reprsente linterface graphique concernant la saisie de la pause effectue. Elle permet de saisir le type et la description de la pause effectue par lutilisateur.

EvaluationForm : cette classe reprsente linterface graphique qui apparat aprs la fin dun suivi pour saisir le nombre dunits ralises et indiquer si la tche a t accomplie ou non laide dune case cocher.

PropertiesForm : cette classe reprsente linterface graphique qui contient certaines proprits de la tche courante. UserProfileConfigForm : cette classe reprsente linterface graphique permettant lutilisateur de configurer son profile. Il a la possibilit de : Activer/Dsactiver lavertissement de limport et saisir sa dure. Activer/Dsactiver lavertissement de lexport. Saisir ladresse URL du serveur de donnes. Activer/Dsactiver la suppression automatique des fichiers XML des suivis synchroniss avec succs. Il faut signaler que par dfaut notre application ne supprime pas ces fichiers, mais elle les met dans un rpertoire ddi et donne lutilisateur la possibilit de les supprimer partir du menu de lapplication.

SessionDemon : dans le but dappliquer le modle MVC dans la ralisation de notre application, et donc sparer les interfaces utilisateurs et les traitements,cette classe a t cre pour regrouper toute la logique relative au comportement de notre application aprs louverture dune session suite un accs russi.

BeginningDemon : cette classe contient tous les traitements que gre notre application dans la phase didentification ou dinscription dun nouvel utilisateur avant quune nouvelle session soit ouverte.

SysTray : cest la classe racine de lapplication, elle se charge de lancer une icne de lapplication dans la Tray Bar et de grer toutes les actions de lutilisateur. ProgressBar : la synchronisation avec le serveur de donnes comporte plusieurs -- 47 --


CHAPITRE 3


oprations. Parmi ces oprations figurent ltablissement de la connexion, lenvoi du fichier XML et le traitement de ce dernier pour agir sur la base de donnes. Ces oprations peuvent ainsi prendre quelque temps pour tre effectues (selon le rseau et la taille des fichiers changer). De ce fait cette classe a t mise en place pour indiquer lutilisateur ltat actuel du processus de synchronisation et lui donner aussi la possibilit de linterrompre.

WelcomeForm INVALID ABORT ERROR OK WelcomeForm() 1 GoBack() GoNext() Validate() 0..1 SelectPath() IsPathValid()0..1

SysTray taskMgtForm IdentificationForm IdentificationForm() Valider() NewUser()0..1

SysTray() CloseApplication() NewSession() CloseSession() InitSysTray()0..1

1..n

BeginningDemon userPath configPath login1..n

0..1

ProgressBar INVALID ABORT ERROR OK ProgressBar() Export() Import() BeginTimerImport() BeginTimerXport() SetTextUser() SetCurrentProgress()1

0..n

GetUserPath() OldUser() NewUser() CreateNewUser() VerifyXportWarning() 0..1 VerifyImportWarning() ImportFromFile() 0..1 ImportData() ImportFromServer() IsPwdValid() ApplicationGo()0..1

WarningImportForm1 1

WarningXportForm WarningXportForm() Validate()1

WarningImportForm() Validate()

1

0..n

Xml

SynchronisClientS ide

1

InterruptionForm InterruptionForm() FillInterruptionsList() Validate()1 0..n

SessionDemon INVALID ABORT ERROR OK userPath configPath login

0..1

EvaluationForm EvaluationForm() Validate()1

0..1

TaskMgmtForm TaskMgmtForm() Interrupt() Play() Stop() Import() Xport() Synchronize() GetConfiguration() Clear() GetProperties() FillTasksList() CloseSession()

0..n

1..n 1

BeginSession() BeginJobsLogs() BeginInterruption() EndSession() 0..n EndJobsLogs() EndInterruption() ExtractInterruptions() 0..n ExtractTasks() FormatDate() 0..n GetProperties() ImportFromFile() ImportFromServer() Xport() Synchronize() Clear() SetConfiguration() GetConfiguration() VerufyXportWarning() GetCryptedPwd()

PropertiesForm listProperties1

PropertiesForm()

1

UserProfileConfigForm UserProfileConfigForm() Validate()

Figure 19 : Diagramme de classes du package JobsLogsSwing. Projet de Fin dEtude : ENSIAS 2004 -- 48 --

CHAPITRE 3


Dans cette partie on sest content de prsenter les classes du package JobsLogsSwing (voir figure 19), le package quivalent pour le terminal mobile est pratiquement le mme.

ConclusionDans ce chapitre, nous avons dcrit la phase danalyse et conception de notre projet. Nous avons prsent le langage utilis pour modlisation savoir UML. Ensuite nous avons prsent et dfini quelques diagrammes du formalisme UML relatifs notre projet et ce, afin dillustrer son fonctionnement. Le chapitre suivant est ddi la phase de ralisation et implmentation de notre application.


-- 49 --

CHAPITRE 4

Ralisation et mise en oeuvre

CHAPITRE 4

Ralisation et mise en uvre

Introduction :Ce chapitre est consacr la phase ralisation du projet. Tout dabord, nous allons prsenter quelques outils utiliss dans la mise en uvre de notre projet de fin dtude. Ensuite, nous aborderons un scnario dutilisation de notre application.

4.1. Outils de dveloppement :Pour raliser notre projet, nous avons eu recours plusieurs technologies et outils de dveloppement tels que Java, JSP et XML. 4.1.1. Java Server Pages (JSP) et les servlets: Les pages Web de notre projet sont implmentes en utilisant JSP. Cette technologie permet dintroduire du code Java dans des balises prdfinis lintrieur dune page HTML. Les JSP possdent plusieurs avantages tels que : Lindpendance de la plate-forme dexcution car elles sont une extension des servlets Java, et donc hritent de tous les avantages de Java ; La facilit dintgrer des balises JSP dans une page HTML. Ceci permet aux graphistes de concevoir la prsentation de leur ct et aux dveloppeurs de raliser des scripts ou des composants java rutilisables ; La rapidit ainsi que la facilit du dploiement des fichiers JSP car le serveur Web compile et excute automatiquement les JSP quand la premire demande arrive. Une servlet est un programme qui s'excute ct serveur en tant qu'extension de celui-ci. Elle reoit une requte du client, elle effectue des traitements et renvoie le rsultat. La liaison entre la servlet et le client peut tre directe ou par un intermdiaire comme par exemple un serveur http. Mme si pour le moment la principale utilisation des servlets est la gnration de pages html dynamiques utilisant le protocole http et donc un serveur web, n'importe quel protocole reposant sur le principe de requte/rponse peut faire usage d'une servlet. Ecrite en java, une servlet en retire ses avantages : la portabilit, l'accs toutes les API de java dont JDBC pour l'accs aux bases de donnes, ... Une servlet peut tre invoque plusieurs fois en mme temps pour rpondre plusieurs requtes simultanes. Projet de Fin dEtude : ENSIAS 2004 -- 50 --

CHAPITRE 4 4.1.2. eXtensible Markup Language (XML) :

Ralisation et mise en oeuvre

Nous avons opt pour le langage XML pour lchange des donnes entre le serveur et les clients afin dexploiter toutes les possibilits offertes par XML. Ce langage permet de dfinir une structure explicite servant de modle pour les documents XML. Cette structure est dfinit laide dune grammaire sous forme darbre appel DTD (Document Type Definition). Ceci rend le fichier XML plus facile manipuler quun fichier texte simple. Le choix de XML est justifi aussi par lexistence de lAPI JAXP (Java API for XML Processing) implment en java ainsi quune API nomme KXML (cest un parseur XML destin aux terminaux mobiles dont les ressources sont limites). Ces deux API permettent de manipuler les fichiers XML dune manire simple et efficace

Documents

Rapport GesPro