Rapport GesPro

Universit Mohammed V-Souissi Ecole Nationale Suprieure dInformatique et dAnalyse des Systmes
Mmoire de projet de fin dtude

pour lobtention du titre
dIngnieur dtat en informatique

option 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
Ddicace
A 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
Abrviation
API 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
Dsignation
Application 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 tableaux

Tableau 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 --
Sommaire
Liste 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 --
Introduction
Le 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 1
Introduction
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 : CACIOPEE

Nous 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
Conclusion
Ce 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
CHAPITRE 2
Introduction
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 besoins

Le 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 propose

2.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 technique

2.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 J2ME

2.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 J2ME

2.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 J2ME

2.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
Conclusion
Dans 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
CHAPITRE 3
Introduction
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 UML

UML (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 fonctionnels

3.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
<<utilise>>
<<utilise>>
<<utilise>> Identification <<Etendre>>
Utilisateur Import des donnes <<utilise>> Lire de la base de donnes Base de Donnes
<<Etendre>> Ecrire dans la base de donnes Export des donnes
Figure 7 : Diagramme des cas dutilisation.
3.3. Spcifications techniques

3.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
<<Application>>
Serveur
<<Application>>
<<Application>>
<<Application>>
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 logicielle

3.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 dynamiques

3.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 login

1..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
WarningImportForm
1 1
WarningXportForm WarningXportForm() Validate()

1
WarningImportForm() Validate()
0..n
Xml
SynchronisClientS ide
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 listProperties
1
PropertiesForm()
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.
Conclusion
Dans 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) :
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 et de naviguer dans leur structure en utilisant un ensemble de classes. Lannexe D donne une description plus riche de ce langage.
4.2. Implmentation de lapplication

4.2.1. Implmentation de la partie serveur La partie serveur de notre application se compose de trois couches savoir la couche prsentation (Presentation Layer PL), la couche traitement ou mtier (Business Layer BL) et la couche accs aux donnes (Data Access Layer DAL). Concernant la couche prsentation, elle contient six servlets, trois pour lexport et les trois autres pour limport. Par exemple, les servlets dexport sont la servlet destine interagir avec le client Palm, la servlet ddie au client PC et la servlet charge de satisfaire aux demandes en provenance du module Web de notre application. Idem pour les servlets dimport. En ce qui concerne la couche traitement, elle comporte les classes qui sont charges deffectuer des traitements sur les donnes de lapplication. Quant la couche accs aux donnes, dj dveloppe par CACIOPEE, elle permet aux classes de la couche traitement daccder aux informations contenues dans la base de donnes Pheonix de lorganisme daccueil (voir la figure 20).
-- 51 --
CHAPITRE 4
Figure 20 : Structure de la partie serveur. Le fonctionnement de la partie serveur de notre application est le suivant : quand une demande de connexion arrive sur une servlet dimport, celle-ci va transmettre aux classes des traitements dimport le login ainsi que le mot de passe en provenance du client qui a initi cette connexion. Apres vrification de ses deux donnes, si elles ne sont pas valides, un message derreur est renvoy la servlet concerne qui transmettra ce message au client. Sinon, les donnes ncessaires la construction des fichiers XML importer seront extraites de la base de donnes laide de la couche DAL. Ces fichiers seront construits par les classes de la couche traitement dimport. Ils seront ensuite passs la servlet concerne afin de le transmettre vers le client. Quand une demande de connexion arrive sur une servlet dexport en provenance dun client, celui-ci transmet des donnes au format XML. Apres que la servlet concerne ait reue ces donnes, elle les sauvegarde dans un fichier puis transmet sa rfrence au module du traitement dexport. Ce module se charge de mettre jour la base de donnes partir de ce fichier tout en utilisant la couche accs aux donnes. Que lopration de mise jour choue ou seffectue avec succs, un message est transmis la servlet concerne qui le transmettra son tour au client. Notons que lchange des fichiers XML entre cette partie et la partie cliente se fait travers les sockets. 4.2.2. Implmentation de la partie client PC Les diffrents composants de ce client interagissent entre eux dans le but de satisfaire aux besoins Projet de Fin dEtude : ENSIAS 2004 -- 52 --
CHAPITRE 4 de son utilisateur.
La figure 21 reprsente le fonctionnement de ce client, lexception du fonctionnement relatif aux nouveaux utilisateurs. Ltat Accueil reprsente ltat dans lequel ce client offre son utilisateur la possibilit de saisir son login et son mot de passe ou de crer son profile quand il sagit dun nouvel utilisateur. Si cest le cas, cet utilisateur fournit son login, le chemin de son rpertoire personnel et son mot de passe et ventuellement ladresse du serveur ou les chemins des fichiers dimport. Une fois que cette opration ait termin avec succs, le fichier de configuration de lapplication sera mis jour par lajout du profile de cet utilisateur. En plus, un dossier ayant le login de cet utilisateur est cre dans son rpertoire personnel. Ce dossier comportera ses fichiers dimport et ses fichiers dexport. Le profile de chaque utilisateur contient les informations suivantes : le login de cet utilisateur, le chemin de son rpertoire personnel, ltat de lavertissement dimport et sa dure, ltat de lavertissement dexport et sa date, ladresse du serveur et loption de suppression automatique des fichiers exports. Il reste noter que le mot de passe de chaque utilisateur est crypt avant dtre enregistr par lapplication ou envoy comme argument la partie serveur. Pour cela nous avons eu recours une mthode de cryptage adopte par CACIOPEE pour la scurisation de laccs son logiciel de gestion de projet PHOENIX. Une fois que lopration didentification, faite par le dmon de dmarrage, sait termin avec succs, ce dernier consulte le profile de lutilisateur courant. Si lavertissement dimport est actif et que sa dure est dpasse, lutilisateur sera averti de la ncessit deffectuer une opration dimport. Ensuite, ce dmon teste ltat de lavertissement dexport. Quand il est active et que le dlai de lexport soit dpass, une fentre davertissement de lexport sera affiche invitant lutilisateur courant choisir entre : exporter immdiatement ; ne pas exporter ; reporter lexport une date ultrieure.
Sil choisit la premire option, lapplication procde une opration de synchronisation, c'est-dire une opration dexport vers le serveur suivi de limport des donnes mises jour dans la base de donnes. Sil sagit de la troisime option, le dmon de dmarrage modifie le profile de lutilisateur courant en modifiant le dlai de lexport. Ensuite, la fentre de gestion des projets saffiche. Si les fichiers imports nexistent pas dans leurs emplacements, la liste des tches sera vide et les boutons ainsi que les sous-menus de gestion des Projet de Fin dEtude : ENSIAS 2004 -- 53 --
CHAPITRE 4
tches ( play , pause , stop ) seront dsactivs. Sinon, seuls les boutons pause et stop seront dsactivs. Lorsque lutilisateur choisit une tche et clique sur play (pour dmarrer un suivi), le dmon de session enregistre un certain nombre dinformations concernant le suivi entam par cet utilisateur. Dans ce cas, seul le bouton play sera dsactiv. Puis, dans le cas o lutilisateur clique sur le bouton stop , le dmon de session procde aux oprations suivantes : le traitement li la fin dun suivi sera effectu ; le fichier dexport sera mis jour par les informations concernant ce suivi ; les boutons pause et stop seront dsactivs.
Si lutilisateur choisi de cliquer sur le bouton pause , pour effectuer une pause, le traitement li au dbut dune pause sera effectu afin de collecter des informations la concernant et ncessaire pour la construction du fichier de lexport. Lutilisateur ne pourra dans ce cas que mettre fin sa pause par une clique sur le bouton play , sachant que ce dernier sera le seul bouton activ aprs le dmarrage dune pause. Aprs avoir termin son suivi, lutilisateur aura la possibilit de synchroniser avec le serveur via le sous-menu Synchronize du menu Action de ce client. Lopration de synchronisation consiste en un export du fichier des suivis vers le serveur, si une erreur survient alors un message sera affich pour informer lutilisateur, sinon ce client procde limport des donnes du serveur. Etant donn que cette opration peut durer plusieurs minutes, selon la taille des fichiers et le dbit du rseau, une fentre avec une barre de progression va safficher lui permettant de visualiser ltat davancement de cette opration, et lui donnant la possibilit de linterrompre. Lorsque lutilisateur dsire quitter ce client, ce dernier vrifie dabord si une pause est dbute. Si cest le cas, la fentre de fin de pause va safficher et ds que lutilisateur valide ce quil a entr, les traitements relatifs la fin dune pause seront effectus. Ensuite, la fentre des rsultats dun suivi sera affiche et ds que lutilisateur valide les informations quil a fournies, savoir le nombre dunits ralises et la compltude de la tche, les traitements de la fin dun suivi vont tre effectus. Puis, le dmon de session va tester sil faut dclencher lavertissement de lexport. Parmi les actions possibles figure la modification du profile dun utilisateur. Quand ce dernier valide ses modifications, le fichier XML de configuration, contenant son profile, sera modifi. De plus, lutilisateur a la possibilit dimporter les fichiers ncessaires partir dun emplacement local. Il peut galement exporter le fichier dexport contenant les informations de ses suivis vers un emplacement local. Projet de Fin dEtude : ENSIAS 2004 -- 54 --
CHAPITRE 4
La structure des fichiers de notre application (fichier de configuration, fichier dexport et fichier dimport), ainsi quune description de leurs contenus seront dtailles dans lannexe C.
Figure 21 : Fonctionnement du client PC. Projet de Fin dEtude : ENSIAS 2004 -- 55 --
CHAPITRE 4 4.2.3. Implmentation de la partie client Palm
Le fonctionnement de ce client est presque le mme que celui du client PC. La diffrence existe au niveau des technologies utilises. Le schma de la figure 21 peut servir dcrire ce client condition domettre les oprations dimport et dexport de fichiers. Les fichiers XML de
lapplication utiliss au niveau du client PC sont remplacs au niveau du client Palm par le stockage persistent fourni par J2ME. Il sagit de lAPI javax.microedition.rms qui contient un ensemble de classes permettant de crer, modifier et supprimer des enregistrements (Record) dans des blocs denregistrements (RecordStore). Ces enregistrements permettent de sauvegarder des donnes de type tableau de byte par ce client et de les rcuprer plus tard tant donn que ce type de stockage est persistant.
4.3. Exemple dutilisation :

4.3.1. Utilisation du client pour PC : Quand un utilisateur dmarre le client version PC de notre projet, la fentre de la figure 22 est affiche lcran. Cette fentre invite cet utilisateur saisir son login ainsi que son mot de passe puis de cliquer sur le bouton Connect dans le cas o cet utilisateur existe dj dans le fichier de configuration de lapplication. Quand il sagit de sa premire utilisation, il aura cliquer sur le bouton New User .
Figure 22 : Ecran didentification Outre lcran de la figure 22, une icne saffiche dans le tray bar de Windows comme le montre la figure 23. Cette icne est utilise pour faciliter laccs lapplication ainsi que son utilisation.
-- 56 --
CHAPITRE 4
Figure 23: Licne de lapplication dans le tray bar Quand il sagit de la premire utilisation de lapplication et que lutilisateur a cliqu sur le bouton New User , la fentre de la figure 24 saffiche et linvite saisir son login et son mot de passe.
Figure 24 : Processus de cration du profile utilisateur (1) Il faut noter quil sagit du login ainsi que du mot de passe de lutilisateur qui sont enregistrs dans la base de donnes Phoenix de CACIOPEE. Aprs quil ait saisit ces informations, lutilisateur sera invit spcifier le chemin o son rpertoire personnel sera sauvegard grce la fentre de la figure 25.
Figure 25 : Processus de cration du profile utilisateur (2) Projet de Fin dEtude : ENSIAS 2004 -- 57 --
CHAPITRE 4
La dernire tape dans le processus de cration du profile dun nouvel utilisateur lui permet dimporter les informations relatives ses tches, ainsi quaux diffrents types dinterruptions dfinis dans la base de donnes. Cette opration dimport se fait soit en spcifiant un fichier local pour les interruptions et un autre pour les tches soit en donnant ladresse URL du serveur et dans ce cas lopration dimport pourra chouer si un problme de connexion survient. Il reste noter que lutilisateur a la possibilit dachever cette dernire tape sans avoir effectuer limport de ses donnes (voir la figure 26).
Figure 26 : Processus de cration du profile utilisateur (3) Lorsque les tapes dcrites prcdemment sont termines, lutilisateur aura un rpertoire personnel qui lui est rserv. Ce rpertoire est dcrit par la figure suivante :
Figure 27 : Structure du rpertoire personnel dun utilisateur. Comme le montre la figure 27, le rpertoire personnel de chaque utilisateur est compos de deux sous rpertoires : le dossier import contenant tous les fichiers imports et le dossier xport qui contient le fichier dexport et le dossier xportedFiles utilis pour y sauvegarder les fichiers exports, ces derniers fichiers peuvent tre supprims par lutilisateur laide de notre application. Aprs avoir termin les tapes dcrites prcdemment, ou lorsque lutilisateur existe dj et quil a t identifi avec succs, la fentre de la figure 28 saffiche : Projet de Fin dEtude : ENSIAS 2004 -- 58 --
CHAPITRE 4
Figure 28 : Fentre principale de gestion des tches. La liste droulante choose task permet lutilisateur de choisir la tche sur laquelle il dsire travailler. Le degr durgence de chaque tche est signal laide de boules colores. Une boule bleue signifie que la date actuelle est suprieure la date estime du dbut de la tche. Une boule verte signifie que la date actuelle est comprise entre la date estime de dbut et celle de la fin de la tche. Quant la boule rouge, elle indique que la date actuelle est suprieure la date de fin estime et que la tche nest pas encore termine. Il faut noter que cette liste droulante nest remplie que lorsque le fichier import des tches de lutilisateur courant existe dans son dossier personnel, autrement elle sera vide et aucune action ne sera possible sauf limport des donnes ainsi que la fermeture de lapplication. Afin de pouvoir importer les donnes, lapplication offre son utilisateur la possibilit de les importer partir dun emplacement local (voir les deux figures 29 et 30). Une fois que les fichiers dsirs sont spcifis, lapplication les reproduit dans le dossier personnel de lutilisateur courant et la liste droulante des tches est remplie.
Figure 29 : Le sous-menu Import
Figure 30 : Le menu Import de licne du tray bar
Quand lutilisateur dsire exporter le fichier dexport contenant le suivi des tches quil a effectues vers un emplacement local sur le disque, il aura la possibilit de choisir Export comme le montrent les deux figures suivantes : Projet de Fin dEtude : ENSIAS 2004 -- 59 --
CHAPITRE 4
Figure 31 : Le sous-menu Export
Figure 32 : Le menu Export de licne du tray bar
Lorsque lutilisateur dsire effectuer limport de ses donnes avec un ventuel export de ses suivis, lapplication lui donne la possibilit de satisfaire ses besoins en choisissant loption Synchronize comme le montrent les figures 33 et 34.
Figure 33 : Le sous-menu Synchronize
Figure 34 : Le menu Synchronize de licne du tray bar
Comme nous lavons dj mentionn, le dossier xportedFiles du rpertoire personnel de chaque utilisateur contient les fichiers exports. Ces fichiers peuvent tre supprims grce au sousmenu Clear du menu Action de notre application. Cette suppression peut tre effectue de faon automatique aprs chaque export russi, mais pour y arriver lutilisateur doit modifier son profile comme le montre la figure suivante :
-- 60 --
CHAPITRE 4
Figure 35 : Lcran de configuration. A laide de lcran de configuration, lutilisateur a la possibilit de modifier son profile. Cette modification peut toucher lavertissement dexport, lavertissement dimport et/ou sa dure, loption de suppression automatique des fichiers exports avec succs et ladresse du serveur Web qui hberge la partie serveur de notre application. 4.3.2. Utilisation du client PDA Dans le but de permettre la mobilit des utilisateurs de notre application, une version de la partie client destine fonctionner sous PALM a t dveloppe. Au dbut nous avons envisag dutiliser les fichiers ainsi que les connections http pour effectuer lchange des donnes entre ce client et le serveur. Mais aprs ltude que nous avons fait de J2ME, nous avons trouv quavec lAPI MIDP 1.0 utilise, lexploitation des fichiers sous PALM nest pas possible car limplmentation de cette API fournie par SUN MICROSYSTEMS ne le permet pas. Quand lutilisateur dmarre ce client, il aura la possibilit de saisir son login ainsi que son mot de passe. Dans le cas o il sagit de sa premire utilisation, il devra pointer sur New user (voir la figure 36).
Figure 36 :Lcran daccueil du client PDA. Projet de Fin dEtude : ENSIAS 2004 -- 61 --
CHAPITRE 4
Dans ce cas, le client PALM demande ce nouvel utilisateur de fournir son login, son mot de passe, et ladresse du serveur afin de pouvoir vrifier ce mot de passe, et dimporter les donnes ncessaires sur les tches de cet utilisateur et sur les types des pauses reconnues par lorganisme daccueil (voir la figure 37).
Figure 37 :Lcran New user du client PDA. Quand la validation des informations fournies par le nouvel utilisateur a russi ou quand lidentification dun utilisateur dj existant est faite avec succs, les donnes relatives aux tches importes sont traites puis affiches comme le montre la figure suivante :
Figure 38 :Lcran de choix des tches du client PDA. Une fois que lutilisateur choisit la tche quil souhaite, le client PALM linvite pointer (par le pointeur de son PALM par exemple) sur un bouton play afin de dmarrer le suivi de la tche choisie. Ensuite, il naura que la possibilit deffectuer une pause (en pointant sur un bouton pause ) ou darrter ce suivi en pointant sur un bouton stop . Lorsque cest la premire possibilit qui est choisie par lutilisateur, ce client linvite saisir une description de la pause Projet de Fin dEtude : ENSIAS 2004 -- 62 --
CHAPITRE 4
effectue ainsi que de choisir le type de pause convenable comme le montre la figure suivante :
Figure 39 :Lcran des interruptions (pauses) du client PDA. Si cest la seconde possibilit qui est choisie par lutilisateur, ce client lui demande de fournir le nombre dunits ralises et de spcifier si la tche courante a t accomplie cent pour cent comme le montre la figure suivante :
Figure 40 :Lcran des rsultats du client PDA. En ce qui concerne la fonctionnalit de synchronisation, qui consiste en un export suivi dun import des donnes mises jour, il est accessible partir du menu de ce client PALM. 4.3.3. Utilisation du module Web Parfois, les dveloppeurs de lorganisme daccueil se trouvent obligs de se dplacer chez un client. Une situation rencontre est que ce dernier ne permet aux dveloppeurs dutiliser que les connections HTTP travers son rseau et sans utiliser leurs propres ordinateurs. La solution ce problme rside dans le dveloppement dun module Web qui permettra deffectuer les oprations dimport et dexport des donnes via le Web. Ce module sera intgr au site Web de CACIOPEE. Projet de Fin dEtude : ENSIAS 2004 -- 63 --
CHAPITRE 4 La figure suivante reprsente la page principale de ce module :
Figure 41 : La page principale du module Web. A partir de la page de la figure 41 lutilisateur a la possibilit dexporter les informations qui concernent le suivi des tches quil a effectues chez le client (voir la figure 42), et dimporter les donnes ncessaire pour accomplir sa (ses) mission(s) (voir la figure 43).
Figure 42 : La page dexport du module Web.
-- 64 --
CHAPITRE 4
Figure 43 : La page dimport du module Web. A partir de la page dexport illustre par la figure 42, lutilisateur peut effectuer un export vers le serveur. Ce dernier renvoie une page Web contenant sa rponse la requte de lutilisateur en indiquant si cette dernire a t satisfaite, ou si une erreur est survenue tout en spcifiant le type de cette erreur (voir la figure 44).
Figure 44 : La rponse du serveur une requte du module Web.
Conclusion
Dans ce chapitre, nous avons prsent quelques outils utiliss pour implmenter notre application. Ensuite, nous avons donn une brve description de limplmentation des modules du projet. Et enfin, pour illustrer le fonctionnement de cette application, nous avons prsent quelques exemples de son utilisation.
-- 65 --
Conclusion
Notre projet de fin dtudes consistait en la conception et la ralisation dune application de gestion des suivis des tches qui composent un projet. Pour mettre en uvre ce projet, nous tions amens, dans un premier lieu, tablir une tude conceptuelle du sujet afin de dgager les diffrents modules de cette application ainsi quune tude des outils et technologies susceptibles de convenir sa ralisation. Dans un second lieu, nous avons fait une analyse et conception du projet en se basant sur le formalisme UML. Un certain nombre de diagrammes ont t labors afin de mieux dcouper le projet, ce qui a facilit sa mise en uvre. Finalement, nous avons implment les diffrents modules de cette application. Le rsultat de cette dernire phase rpond aux exigences et aux besoins dj cits dans ce rapport. Ce projet nous a permis de renforcer nos connaissances concernant larchitecture J2EE, J2ME ainsi que XML. Il tait galement une occasion pour nous de consolider et de forger nos comptences en matire de dveloppement informatique. Durant les quatre mois de notre projet de fin dtude, nous avons pu aboutir aux objectifs fixs au dbut de ce projet. Le travail ralis peut tre amlior. En effet, ds quune implmentation de la MIDP aura permis laccs aux fichiers locaux et sera disponible, lutilisation de ces derniers va simplifier normment lutilisation du client Palm.
-- 66 --
Bibliographie
Ouvrages
[5] R.ORFALID, D.HARKEY, J.EDWARDS, Client/Server survival guide third edition, John Wiley & Sons, 1999.
Adresses Internet
[1] http://www.fresco.org/docs/fr/html/x234.html [2] http://www.dotnetguru.org/articles/J2MEvsSDE/J2MEvsSDE.htm [3] http://www.cellconcept.com/faq_midp.html# [4] http://uml.developpez.com/lp/index-cours.html [6] http://www.tomshardware.fr/articletendance.php?IdArticle=370&NumPage=1 [7] http://www.javaworld.com/javaworld/javatips/jw-javatip94.html [8] http://perso.wanadoo.fr/jm.doudoux/java/tutorial/glossaire.htm
-- 67 --
Glossaire
API CDC
Cest une bibliothque qui regroupe des fonctions sous forme de classes pouvant tre utilises pour dvelopper. Configuration J2ME pour des appareils embarqus possdant certaines ressources et une connexion Internet tels que des set top box, certains PDA haut de gamme, des systmes de navigations pour voiture, etc. Architecture qui sappuie sur un concept de rpartition des traitements et des donnes sur un ensemble de systmes comprenant la fois des serveurs centraux, des dpartements et des micros. Configuration J2ME pour des appareils possdant de faibles ressources et une interface utilisateur rduite tels que des tlphones mobiles, des PDA, etc. machine virtuelle Java construite pour les terminaux connects de forte capacit. Couche intermdiaire entre la base de donnes applications destines lutiliser. et toutes les
Client/Serveur
CLDC
CVM DAL DOM J2EE
Spcification et API pour reprsenter et parcourir document XML sous la forme d'un arbre en mmoire. C'est une version du JDK qui contient la version standard plus un ensemble de plusieurs API permettant le dveloppement d'applications destines aux entreprises : EJB, Servlet, JSP, JNDI, JMS, JTA, JTS, ... C'est une version du JDK qui contient le ncessaire pour dvelopper des applications capables de fonctionner dans des environnements limits tels que les assistants personnels (PDA), les tlphones portables ou les systmes de navigation embarqus. C'est une version du JDK qui contient le ncessaire pour dvelopper des applications et des applets. API pour parcourir un document XML (DOM et SAX) et le transformer avec XSLT. Environnement permettant l'excution de programmes Java lors de leurs diffusions. C'est une technologie comparable aux ASP de Microsoft mais utilisant Java. C'est une page HTML enrichie de tag JSP et de code -- 68 --
J2ME
J2SE JAXP JRE JSP
Java. Une JSP est traduite en Servlet pour tre excute. Ceci permet de sparer la logique de prsentation et la logique de traitement contenu dans un composant serveur tel que des Servlets, des EJB ou des Beans. JVM Machine virtuelle de Java qui est la base mme de sa portabilit sur la plupart des plates-formes. En ralit, le code Java est compil en instructions comprhensibles par la machine virtuelle qui elle-mme interprtera ces instructions pour que l'ordinateur puisse les comprendre. C'est pour cela que chaque plate-forme doit disposer de sa propre machine virtuelle pour fonctionner. Une petite machine virtuelle Java construite pour les terminaux contraint. Application mobile dvelopp avec CLDC et MIDP. API conue pour tirer le meilleur parti d'un type de terminal prcis (taille de l'cran, cran tactile, type de rseau ...). MVC PDA Un modle de conception largement rpandu qui permet de sparer l'interface graphique, les traitements et les donnes manipules. Cest un ordinateur de poche disposant dun agenda, dun carnet dadresses et dautres logiciels. Les PDA sont quips dun clavier ou dun cran tactile. Les trois systmes dexploitation les plus rpandus : Palm OS (pour les Palm Pilot), Windows CE (pour les Pocket PC) et Epoc (pour les Psion). Cest le nom des assistants personnels fonctionnant sous le systme d'exploitation Pocket PC de Microsoft. Cest un mulateur de PDA Palm, qui sert concevoir et tester des applications tournant sur Palm OS directement sur PC, et sans avoir ncessairement sous la main un de ces PDA. Cest une mthode conue par Watts Humphrey de Software Engeneering Institute, afin de contrler les projets et damliorer leur qualit. Elle vise identifier les points faibles, les points forts de lingnieur et laider mieux grer son temps et amliorer lestimation de ses tches. Fourni un mcanisme travers lequel les MIDlets peuvent sauvegarder des donnes et les rcuprer aprs. API pour traiter squentiellement un document XML en utilisant des vnements. C'est un composant Java qui s'excute ct serveur dans un environnement ddi pour rpondre des requtes. L'usage le plus -- 69 --
KVM MIDlet MIDP
Pocket PC POSE
PSP
RMS SAX Servlet
frquent est la gnration dynamique de page Web. On les compare souvent aux applets qui s'excutent ct client mais elles n'ont pas d'interface graphique. UML WEB XML Cest un langage unifi utilis surtout dans le cadre des projets orients objets. Cest le service le plus utilis sur Internet permettant la navigation sur les pages Web. Meta langage extensible driv de SGML permettant de structurer des donnes.
-- 70 --
Annexes
-- 71 --
Annexe A
Architecture Client/Serveur trois niveaux
ANNEXE
Notre projet a t conu et ralis selon une architecture C/S (Client/Serveur) trois niveaux. Dans la prsente annexe, nous dcrivons cette architecture, et nous expliquons les avantages quelle offre par rapport aux autres architectures client/serveur.
Larchitecture C/S est une architecture qui permet de subdiviser un processus informatis en, aux moins, deux tches moins complexes (Client et Serveur) avec un moyen de communication qui permet ces sous processus de cooprer entre eux. Il existe plusieurs variantes de larchitecture C/S. La premire gnration du C/S est larchitecture deux niveaux ou 2-tiers. Elle a deux approches : Approche centre sur le client : consiste placer les parties prsentation et traitement sur le client, et la logique daccs aux donnes sur le serveur. Approche centre sur le serveur : consiste regrouper les parties traitement et accs aux donnes sur le serveur, et ne garder que la partie prsentation sur le client. Ces deux approches de larchitecture C/S 2-tiers peuvent provoquer des problmes majeurs tels que : La charge de traitements considrable sur le client (premire approche) ; La perturbation du trafic rseaux sur les jeux de rsultats volumineux que peuvent gnrer les requtes de la base de donnes (BD) ; Labsorption complte des ressources du serveur de donnes, car chaque session ouverte ncessite une connexion la BD ; La difficult de la maintenance et de dploiement. Pour remdier aux limites de cette architecture, on a pens insrer un niveau supplmentaire, entre le client et le serveur (cf. figure 1), pour encapsuler les traitements mtier de lapplication. On a appel ce type darchitecture, larchitecture C/S trois niveaux ou 3-tiers [5].
-- 72 --
Annexe A
T roisim e couche: A ccs aux donnes
BD
D euxim e couche: O bjets m tier Prem ire couche: Prsentation
Figure 45 : Architecture Client/Serveur trois niveaux Couche prsentation : reprsente l'interface Homme/Machine. Elle permet aux utilisateurs de dialoguer avec le systme. Couche objets mtier ou traitement : cest une couche logicielle entre linterface utilisateur et la base de donnes. Ce niveau reprsente l'ensemble des fonctionnalits et des rgles mtier de l'application tels que les contrles et la vrification du calcul qui sexcutent au niveau du client. Couche accs aux donnes : constitue la base de cette architecture car elle offre tous les services ncessaires daccs aux sources de donnes. Ces services seront utiliss par la couche dobjets mtier ou traitement de cette architecture. Larchitecture C/S 3-tiers [5] prsente de nombreux avantages tels que : La facilit de maintenance et lextensibilit : chacun de ces niveaux est implment indpendamment des deux autres, ce qui assure une autonomie des niveaux. On peut donc ajouter ou modifier dans le code de n'importe quel niveau sans affecter les autres. La rutilisation : les units de code redondant utilises dans plusieurs applications peuvent tre rassembles en des composants ou services. Cela favorise le dveloppement rapide des applications. Ainsi, bien que les systmes deux niveaux aient leur place dans le monde des applications simples, les systmes C/S trois niveaux sont aujourdhui considrs comme la solution idale pour lentreprise dont les besoins sont en volution perptuelle. Le tableau ci-dessous compare ces deux gnrations du C/S, 2-tiers et 3-tiers.
-- 73 --
Annexe A
Critres Administration Scurit Encapsulation des donnes Performance Rutilisation des applications Facilit de dveloppement Base de donnes htrognes Dploiement
2-Tiers Complexe Basse Basse Faible Faible Haute Non Complexe
3-Tiers Moins complexe Haute Haute Bonne Excellente Haute Oui Simple
Tableau 6 : Comparaison entre larchitecture 2-tiers et 3-tiers
-- 74 --
Annexe B
Prsentation des PDAs
ANNEXE
Dans la prsente annexe nous allons faire tout dabord une introduction gnrale sur les PDA [6]. Ensuite nous prsenterons les principaux membres de ses familles. Et enfin, nous allons dcrire les diffrents critres sur lesquels on peut se baser pour distinguer entre les diffrents types de PDA. 1. Introduction La simplicit d'utilisation des PDA (Personal Digital Assistants) (voir figure 45), et la multiplication de leurs applications ont favoris leur dmocratisation dans l'entreprise. Plannings, agendas et carnet d'adresses restent porte de main et sont toujours jour. Les PDA, ou agendas lectroniques, prennent l'avantage sur les blocs-notes papier. Ils savent se synchroniser avec les outils du PC (notamment les logiciels Microsoft tel Outlook), et ce de manire trs aise. De plus, ils offrent quelques fonctions qui peuvent tre intressantes. Particulirement la gestion des comptes, lutilisation de la calculatrice (ou du convertisseur de monnaies, de mesures...). Les organiseurs de poche ont pour vocation initiale de remplacer la fois lagenda, le carnet dadresses et la bote de Post-It. Ils peuvent tre considrs comme des appareils de lecture permettant d'apporter quelques modifications (nom, numro de tlphone ou rendez-vous). Plusieurs dentre eux mritent aujourdhui pleinement lappellation plus honorifique de PC de poche tant leurs caractristiques et leurs fonctions tendent les faire se rapprocher des ordinateurs de travail.
Figure 46 : Quelques types de PDA
Bien que trs diffrents les uns des autres la fois en terme de puissance et de fonctions, toutes les familles du PDA proposent aujourdhui des logithques tendues venant complter les tches de Projet de Fin dEtude : ENSIAS 2004 -- 75 --
Annexe B
base des organiseurs : jeux, dessin, plans de villes, et mme pour certains lecteurs de MP3 et de vidos. Autre similitude, ils suivent tous les mmes principes de saisie dinformation et de communication avec lordinateur : La saisie Pour rentrer des informations, trois moyens existent: passer par lcran tactile et le stylet, par le clavier si lagenda sen trouve pourvu, ou encore synchroniser les informations avec lordinateur.
La premire solution impose un apprentissage car chaque lettre doit tre crite selon un certain modle. Le systme de reconnaissance dcriture intgr les transforme au fur et mesure en caractres dimprimerie. Une alternative existe pour les retors cette tape dapprentissage : les Palms et les Pocket PC proposent la possibilit de faire apparatre un clavier virtuel lcran et de simplement cliquer sur les touches de ce mini clavier laide du stylet pour crire vos textes. La synchronisation Tous ont naturellement adopt des modes de navigation assez proches les uns des autres, avec des raccourcis sous formes de touches pointant vers les applications les plus couramment utilises (agenda, carnet dadresse), puis un classement par type dapplication. Ils synchronisent leurs donnes (gnralement celles qui ont t modifies dans le carnet dadresses, lagenda et la liste des tches) par lintermdiaire dun cble srie ou USB et dun simple clic par la souris du PC avec votre gestionnaire de messagerie : il sagit gnralement du logiciel Outlook ou dun outil propritaire quand il est livr avec lagenda. 2. Familles de PDA Les modles qui seront prsents par la suite sont pour le moins htroclites. Leur prix, limage de la cadence des processeurs qui les animent ou de la taille mmoire livre en standard, varie du simple sextuple, voire loctuple. En rsum, trois grandes familles se partagent aujourdhui un march pour le moins concurrentiel :
-- 76 --
Annexe B 2.1 Les Palm OS
Outre les Pilot de la socit Palm, il existe quelques appareils compatibles (ils utilisent le mme systme d'exploitation, Palm OS), tels le Handspring de Visor et Clie de Sony. Le systme d'exploitation Palm OS est un modle quant la simplicit d'utilisation. Toutes les fonctions sont facilement et rapidement accessibles. Par contre, il n'offre pas de fonctions trs avances, tel l'envoi ou la rception d'emails et la connexion Internet (pas de modem). La couleur n'apparatra qu'avec Palm OS 4.0... La grande force de ces appareils est leur lgret et leur simplicit d'usage. Ils sont utiles pour des usages "ponctuels" et certains modles sont quips d'un port infrarouge qui permet de raliser des changes entre appareils compatibles. Le gros dfaut des Palm, et en mme temps le gros avantage du Handspring de Visor, est le connecteur d'extension. Le 'SpringBoard' du Visor, sans quivalent chez les Palm Pilot, permet d'ajouter de la mmoire ou un modem votre appareil et donc de lui ajouter des fonctionnalits. Aujourd'hui, la plupart des modles possdent 8 Mo de mmoire vive, ce qui est largement suffisant pour stocker ses contacts, et quelques logiciels complmentaires (dictionnaire, guide, logiciels spcialiss...). La diffrence de prix se fait sur la nature de la source d'alimentation, piles (non rechargeables) ou batterie (qui se recharge lorsque l'outil est sur son socle). Dans une moindre mesure, une taille plus petite et le design du botier contribuent augmenter le prix. La couleur est apparue trs rcemment sur certains modles hauts de gamme de Palm Pilot. Enfin, les appareils fonctionnant sous Palm OS disposent d'une logithque trs impressionnante, tant en Freeware qu'en Shareware, ce qui peut tre un point trs intressant. 2.2 Les Pockets PC Cette famille des PDA fonctionne avec un systme d'exploitation de la famille Windows, savoir Windows CE. Ce type dorganiseurs de poche est propos par Hewlett-Packard, Compaq, Casio et dautres constructeurs. Windows CE est accompagn de versions lgres des logiciels Word, Excel et PowerPoint, ce qui permet lutilisateur de consulter ses documents traditionnels en dplacement. Les documents trop complexes (mise en page, modles, liens...) ne sont pas lisibles correctement. En outre, certains modles permettent de consulter des emails, des pages Web et mme des fichiers sons (par exemple au format MP3). A noter que la couleur est disponible sur tous les modles, ce qui est un luxe agrable, mais coteux en nergie ! Ainsi, un appareil avec une grosse batterie et un cran monochrome peut fonctionner sept fois plus longtemps qu'un Pocket PC couleur.
-- 77 --
Annexe B 2.3 Les Psions
Les Psion sont des modles d'une classe part. En effet, leur systme d'exploitation est propritaire, mais trs bien adapt ces appareils. L'intrt des Psion rside principalement dans leur vritable clavier. Celui-ci vous permet de taper rellement des textes plus longs que quelques lignes (une lettre par exemple), tche beaucoup trop longue faire avec le systme de reconnaissance manuscrite des autres modles. Mais cet intrt est rserv un cercle limit du fait du prix de l'appareil. A noter que les dernires versions du Psion disposent d'un dictaphone et permet donc l'enregistrement de messages vocaux. Le march des Psion est donc relativement limit, mais ces appareils sont trs bien adapts pour disposer d'un "semblant de PC" autonome et trs bien quip. 2.4 Les autres. Il existe encore certains modles tels que : Olivetti, Avigo 10... Utilisant des systmes d'exploitation propritaires, disposant de peu de mmoire et rarement d'une synchronisation avec un PC. Ces modles sont en gnral bien moins chers que les appareils des autres classes, mais leurs capacits en sont d'autant limites. Pour une utilisation professionnelle, ces appareils sont les moins utiliss, car ils ne rpondent aucun standard et une volution vers une autre classe d'appareils sera rellement complique (systme d'exploitation compltement diffrent par exemple). De plus, il n'existe aucun logiciel, commercial ou non, pour ces outils, ce qui limite d'autant leur utilit. 3. Critres de distinction Pour faire une comparaison entre tous les appareils disponibles sur le march encombr des agendas lectroniques, il est ncessaire de faire une liste des diffrents critres valorisant un organiseur de poche par rapport un autre. Ces paramtres de choix sont classs selon trois catgories : Le confort d'emploi L'cran et le dispositif de saisie Les crans doivent tre du type sensitif. Ils s'utilisent avec un stylet. Sur les Psion, ce dispositif sert la slection de donnes, mais sur les modles dpourvus de clavier, Palm ou Pocket PC, il constitue le seul moyen d'effectuer la saisie de texte. La priode d'apprentissage pour matriser le systme de reconnaissance de l'criture est plus longue sur Projet de Fin dEtude : ENSIAS 2004 -- 78 --
Annexe B
un Palm que sur un Pocket PC. En contrepartie, elle donne de meilleurs rsultats. Les crans des Psion sont plus grands que ceux des ordinateurs sans clavier. Sur ces derniers, les crans sont de tailles comparables. Chaque gamme possde des modles monochromes et couleur. Le confort apport par la couleur est apprciable, surtout pour la navigation sur Internet, mais, revers de la mdaille, l'autonomie de l'ordinateur en souffre. L'autonomie L'autonomie est l'un des points essentiels qui distinguent les ordinateurs de poche les uns des autres. Selon les modles, elle varie de 7 heures 30 minutes 50 heures. Ces carts trs importants s'expliquent principalement par la consommation d'nergie des diffrents types d'crans (couleur ou monochrome, rtro clair ou non) et par la capacit des sources d'alimentation (batteries ion-lithium, NiMH ou piles). C'est ainsi qu'un Visor avec sa grosse batterie et son cran monochrome fonctionne jusqu' sept fois plus longtemps qu'un Pocket PC couleur. L'encombrement et le poids La taille des ordinateurs de poche est fonction de la prsence du clavier. Le plus compact des modles tests est le Palm Vx. Viennent ensuite les autres organiseurs du mme nom, puis les Visor et les Pocket PC. La documentation La qualit de la documentation est importante. En effet, bien que l'utilisation quotidienne des organiseurs de poche ne pose gure de problmes, vous devez pouvoir vous renseigner rapidement sur telle ou telle application. En outre, la synchronisation des donnes qu'ils contiennent avec les ordinateurs de bureau et la connexion Internet se rvlent parfois moins faciles raliser que prvu. La capacit de communication Avec le PC Les ordinateurs de poche doivent communiquer convenablement avec les principaux logiciels utiliss. C'est le cas, en particulier, avec Outlook de Microsoft. Dans ce domaine cependant, les Pocket PC ont quelques petites longueurs d'avance. En effet, Windows CE se synchronise trs bien avec les versions de Windows des PC de bureau. La mise jour Projet de Fin dEtude : ENSIAS 2004 -- 79 --
Annexe B
des donnes est automatique. Ds que le Pocket PC est sur son socle, toute modification des donnes sur l'un ou l'autre appareil est instantanment rpercute sur lautre. Avec les Palm, cette synchronisation automatique doit tre valide par l'utilisateur. Avec Internet Tous les ordinateurs ne sont pas gaux devant Internet. L'cran couleur et la prsence de Pocket Explorer avantage nettement les Pocket PC, mme si les Psion disposent d'un cran large et d'une panoplie complte de logiciels et de priphriques. Les Palm, quand eux, sont rellement limits. Cela dit, avec tous les modles, les utilisateurs peuvent saisir leur courrier. Ce dernier sera envoy par les PC aprs synchronisation. De mme, les emails reus par ces derniers sont recopis sur les organiseurs. Il reste que, pour rdiger des emails, les modles avec clavier son prfrables. L'quipement Les logiciels et les matriels Les Pocket PC disposent de nombreux logiciels. En outre, ces appareils permettent tous de lire des fichiers MP3 (les Visor en sont aussi capables, mais l'aide d'une extension fournie en option). De plus, ils peuvent enregistrer quelques minutes de dialogue. Les Psion et quelques Palm font galement office de dictaphone. Et eux aussi disposent de nombreux logiciels dont, entre autres, des logiciels d'itinraire incorporant des cartes routires. Les modles les plus polyvalents sont les Pocket PC, puis viennent les Psion et, enfin, les Palm.
-- 80 --
Annexe C
Fichiers XML utiliss par lapplication
ANNEXE
Notre application utilise deux types de fichiers XML : des fichiers pour la communication entre la partie cliente et la partie serveur, et un fichier XML pour la configuration de la partie cliente. Les fichiers ddis cette communication sont diviss en deux catgories : Fichiers dimport :
Les fichiers dimport reprsentent un aliment pour la partie client, qui lui permettent de dmarrer et dassurer les suivis des tches. De ce fait, lutilisateur est oblig de les importer immdiatement avant tout usage de lapplication, que a soit travers le WEB ou travers la partie cliente de notre application. Le premier fichier import est le fichier XML import.xml (cf. figure 47). Il contient des informations relatives lutilisateur ainsi que celles relatives ses tches qui ne sont pas encore accomplies. Ce fichier a comme attribut de racine la date de limport, cette date est utile pour lavertissement de limport.
Figure 47 : exemple du fichier XML dimport Projet de Fin dEtude : ENSIAS 2004 -- 81 --
Annexe C
Le deuxime fichier indispensable pour lapplication est celui des interruptions (cf. figure 48). Ces interruptions sont extraites de la base de donnes et elles sont communes tous les utilisateurs. Chaque interruption est caractrise par son code et son nom. Lintrt de sparer le fichier des interruptions et celui des tches rside dans le fait que les types dinterruptions sont indpendants des utilisateurs, ainsi ce fichier peut tre rutilis par plusieurs utilisateurs en cas de besoins. De plus parfois lutilisateur a besoin dactualiser seulement ses tches ou ses interruptions uniquement.
Figure 48 : Exemple du fichier XML des interruptions
Fichier dexport :
Le fichier dexport reprsente une synthse des suivis effectus par lutilisateur (cf. figure 49), ces suivis sont regroups par tche. Chaque suivi est caractris par sa date de dbut, sa date de fin et son delta_time qui reprsente la dure effective du suivi. En effet, cette valeur est gale la dure du suivi de laquelle on retranche la somme des dures des interruptions effectues pendant ce suivi. De plus chaque suivi est valu par les deux critres : completed et units , le premier indique si la tche a t bien complte aprs ce suivi, tandis que le deuxime nous informe sur le nombre dunits ralises pendant ce suivi. Chaque interruption est caractrise aussi par son nom, sa description, sa date de dbut et sa date de fin. Les interruptions dun mme suivi sont regroupes dans une balise interruptions .
-- 82 --
Annexe C
Figure 49 : Exemple du fichier XML dexport
En ce qui concerne le fichier de configuration, il contient les profiles des divers utilisateurs de lapplication (cf. figure 50). Plusieurs proprits et variables sont dfinies pour chaque utilisateur, savoir: path : cette balise contient la valeur de la variable du chemin de lutilisateur, cest laide de cette variable que lapplication reconnat le chemin personnel de lutilisateur, duquel elle peut extraire et vrifier les informations propre au profil de cet utilisateur et charger les tches qui lui sont relatives. Cette information ne sera pas utilise au niveau du client Palm. warningImport : cette balise contient deux proprits savoir state et duration , la premire indique si lavertissement de limport est active ou pas, alors que la deuxime prcise le dlai de limport. Une fois que ce dlai soit dpass et que state est 1, lavertissement dimport se dclenche.
-- 83 --
Annexe C
Fichiers XML utiliss par lapplication warningXport : cette balise, similaire la prcdente, contient aussi deux proprits qui sont state et duration , la premire indique si lavertissement de lexport est active ou pas, alors que la deuxime prcise la date de cet avertissement. autoClear : la proprit state de cette balise indique lapplication si loption de la suppression automatique des fichiers exports est active ou pas. Lorsque cette option est dsactive lutilisateur sera averti avant deffectuer cette suppression. serverConfiguration : Le serveur, qui hberge notre partie serveur du projet, peut changer dadresse au cours du temps, cest pour cette raison que le profile de chaque utilisateur contient une balise contenant ladresse de ce serveur. Cette information peut tre modifie par lutilisateur lors de lutilisation de lapplication.
Figure 50 : Exemple du fichier XML de la configuration
-- 84 --
Annexe D
XML (eXtensible Markup Language)
ANNEXE
Nous avons utilis le langage XML pour reprsenter la structure dune base de donnes. Dans cette annexe, nous nous proposons de prsenter ce langage et quelques unes de ses caractristiques.
1. Prsentation de XML
XML (eXtensible Markup Language) est un langage HTML amlior permettant de dfinir de nouvelles balises. Cest un sous-ensemble de SGML (Standard Generalized Markup Language), dfini par le standard ISO8879 en 1986. XML a repris la majeure partie des fonctionnalits de SGML et il la prsente dune manire simplifie. Contrairement HTML, qui est considrer comme un langage dfini et fig (avec un nombre limit de balises), XML peut tre considr comme un mtalangage permettant de dfinir d'autres langages, c'est--dire dfinir de nouvelles balises permettant de dcrire la prsentation d'un texte. La force de XML rside dans sa capacit dcrire n'importe quel domaine de donnes grce son extensibilit. Il va permettre de structurer, poser le vocabulaire et la syntaxe des donnes qu'il va contenir. En ralit les balises XML dcrivent le contenu plutt que la prsentation. Ainsi, XML spare le contenu de la prsentation, ce qui permet d'afficher un mme document sur diffrentes formes de prsentation.
2. Mise en page de XML

XML est un format de description de donnes et non de leur reprsentation, comme c'est le cas avec HTML. La mise en page des donnes est assure par un langage de mise en page. A l'heure actuelle, il existe trois solutions pour mettre en forme un document XML : CSS (Cascading Style Sheet), la solution la plus utilise actuellement, tant donn qu'il s'agit d'un standard qui a dj fait ses preuves avec HTML XSL (eXtensible StyleSheet Language), un langage de feuilles de style extensible dvelopp spcialement pour XML. Toutefois, ce nouveau langage n'est pas reconnu pour l'instant comme un standard officiel
-- 85 --
Annexe D
XSLT (eXtensible StyleSheet Language Transformation). Il s'agit d'un langage propritaire Microsoft, dvelopp spcialement pour Internet explorer, permettant de transformer un document XML en document HTML accompagn de feuilles de style.
3. Structure des documents XML

XML fournit un moyen de vrifier la syntaxe d'un document grce aux DTDs (Document Type Definition). Il s'agit d'un fichier dcrivant la structure des documents y faisant rfrence un langage adapt. Ainsi un document XML doit suivre scrupuleusement les conventions de la notation XML et peut ventuellement faire rfrence une DTD dcrivant l'imbrication des lments possibles. Un document suivant les rgles de XML est appel document bien form. Un document XML possdant une DTD et tant conforme celle-ci est appel document valide.
4. Dcodage dun document XML

XML permet de dfinir un format d'change selon les besoins de l'utilisateur et offre des mcanismes pour vrifier la validit du document produit. Il est donc essentiel pour le receveur d'un document XML de pouvoir extraire les donnes du document. Cette opration est possible l'aide d'un outil appel analyseur (en anglais parser). Cet analyseur permet d'une part d'extraire les donnes d'un document XML (on parle d'analyse du document ou de parsing) dautre part de vrifier ventuellement la validit du document. Il existe deux analyseurs standards, qui correspondent deux modles de traitements diffrents des documents. Dans le premier modle, lanalyseur lit le flot de donnes XML en entre et interprte les marques de balisage au fur et mesure quil les rencontre. Chaque construction reconnue est immdiatement signale. LAPI standard qui implmente ce modle et le rend disponible aux applications sappelle SAX, acronyme de Simple API for XML. Dans le second modle, lanalyseur compile lensemble du document et en construit une reprsentation interne sous forme darbre. Ainsi ce modle propose un ensemble des fonctions pour naviguer dans cet arbre. LAPI standard qui implmente ce modle est DOM.
5- Avantages de XML
Les principaux atouts de XML : La lisibilit : aucune connaissance ne doit thoriquement tre ncessaire pour comprendre un contenu d'un document XML ; Une structure arborescente : permet de modliser la majorit des problmes informatiques ; Universalit et portabilit : les diffrents jeux de caractres sont pris en compte ; Lextensibilit : un document XML doit tre utilisable dans tous les domaines d'applications. Grce ses avantages, XML est particulirement adapt l'change de donnes et de documents. Projet de Fin dEtude : ENSIAS 2004 -- 86 --

Rapport GesPro

Transféré par

Droits d'auteur :

Formats disponibles

Rapport GesPro

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Rapport GesPro

Transféré par

Droits d'auteur :

Formats disponibles

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

Mmoire de projet de fin dtude

dIngnieur dtat en informatique

Ralis par : Issam ELASLAOUI. Hamid MAZOUAR.

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

Anne universitaire 2003-2004

Liste des abrviations

Projet de Fin dEtude : ENSIAS 2004

Listes des figures et tableaux

Liste des tableaux

Liste des figures

Projet de Fin dEtude : ENSIAS 2004

Projet de Fin dEtude : ENSIAS 2004

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

Projet de Fin dEtude : ENSIAS 2004

Projet de Fin dEtude : ENSIAS 2004

Projet de Fin dEtude : ENSIAS 2004

Contexte gnral du projet

Contexte gnral du projet

1.1. Organisme daccueil : CACIOPEE

Projet de Fin dEtude : ENSIAS 2004

CHAPITRE 1 Division de Knowledge Management.

Contexte gnral du projet

Contexte gnral du projet

Projet de Fin dEtude : ENSIAS 2004

CHAPITRE 1 Les principales activits de cette division sont :

Contexte gnral du projet

Contexte gnral du projet

CHAPITRE 1 Stop : le temps darrt dexercer cette activit ;

Contexte gnral du projet

Contexte gnral du projet

Partie cliente PDA

Serveur dapplications Serveur de BD

Figure 1 : Schma gnral de lapplication

Projet de Fin dEtude : ENSIAS 2004

Contexte gnral du projet

Projet de Fin dEtude : ENSIAS 2004

2.1. Spcification des besoins

Projet de Fin dEtude : ENSIAS 2004

2.2. La solution propose

Projet de Fin dEtude : ENSIAS 2004

CHAPITRE 2 2.2.2. Le principe MVC

Projet de Fin dEtude : ENSIAS 2004

2.3. Etude technique

2.3.1.1. Le POSE (Palm OS Emulator)

2.3.1.2. Programmation sur Desktop

2.3.1.3. Programmation embarque

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

2.3.3. Prsentation de la plate-forme J2ME

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

Figure 3 : Architectures J2ME

Projet de Fin dEtude : ENSIAS 2004

Figure 4 : Les diffrentes configurations de larchitecture J2ME

Projet de Fin dEtude : ENSIAS 2004

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

Figure 6 : Modle du cycle de vie dune Midlet.

Projet de Fin dEtude : ENSIAS 2004

Projet de Fin dEtude : ENSIAS 2004

3.1. Prsentation du langage de modlisation UML

indpendant des langages orients objet) ;