Rapport GesProréseaux de Communication

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
Dsignation
API
Application Programming Interface
BD
Base de donnes
BL
Business Layer
CDC
Connected Device Configuration
CLDC
Connected Limited Device
CVM
Compact Virtual Machine
DAL
Data Access Layer
DOM
Document Object Model
J2EE
Java 2 Entreprise Edition
J2ME
Java 2 Micro Edition
J2SE
Java 2 Standard Edition
JRE
Java Runtime Environment
JSP
Java Server Pages
JVM
Java Virtual Machine
KVM
Kilo Virtual Machine
MIDlet
Nom compos partir de MIDP et rappelant applet et servlet
MIDP
Mobile Information Device Profile
MVC
Model View Controller
OS
Operating System
PDA
Portable Digital Assistante
PL
presentation Layer
PSP
Personnal Software Process
POSE
Palm OS Emulator
RMS
Record Management System
SSII
Socit de Service en Ingnierie Informatique
UML
Unified Modeling Language
UI
User Interface
XML
eXtensible Markup Language
Projet de Fin dEtude : ENSIAS 2004
-- 1 --
Listes des figures et tableaux
Liste des tableaux

Tableau 1
Formulaire PSP pour lhistorique de projet
12
Tableau 2
Formulaire PSP pour lestimation du projet
12
Tableau 3
Liste des packages de CLDC
23
Tableau 4
Liste des packages du MIDP
24
Tableau 5
Identification des cas dutilisation
28
Tableau 6
Comparaison entre larchitecture 2-tiers et 3-tiers
73
Liste des figures
Figure 1
Schma gnral de lapplication
14
Figure 2
Schma global du MVC
18
Figure 3
Architectures J2ME
22
Figure 4
Les diffrentes configurations de larchitecture J2ME
24
Figure 5
Package MIDP et CLDC
25
Figure 6
Modle du cycle de vie dune Midlet
26
Figure 7
Diagramme des cas dutilisation
29
Figure 8
Diagramme des composants du systme environnant
30
Figure 9
Empaquetage des classes cot serveur
32
Figure 10
Diagramme de packages
34
Figure 11
Scnario de lecture de la base de donnes
35
Figure 12
Scnario dcriture dans la base de donnes
36
Figure 13
Scnario nouvel utilisateur
37
Figure 14
Scnario didentification
38
-- 2 --
Figure 15
Diagramme de squences du scnario suivi des tches
40
Figure 16
Diagramme de squences du scnario synchronisation
42
Figure 17
Diagramme de classes regroupant les deux packages

SynchronizeClientSide et DbSide
44
Figure 18
Diagramme de classes du package XML
45
Figure 19
Diagramme de classes du package JobsLogsSwing
48
Figure 20
Structure de la partie serveur
51
Figure 21
Fonctionnement du client PC
53
Figure 22
Ecran didentification
56
Figure 23
Licne de lapplication dans le tray bar
56
Figure 24
Processus de cration du profile utilisateur (1)
57
Figure 25
57
Figure 26
58
Figure 27
Structure du rpertoire personnel dun utilisateur
58
Figure 28
Fentre principale de gestion des tches
58
Figure 29
Le sous-menu Import
59
Figure 30
Le menu Import de licne du tray bar
59
Figure 31
Le sous-menu Export
59
Figure 32
Le menu Export de licne du tray bar
59
Figure 33
Le sous-menu Synchronize
60
Figure 34
Le menu Synchronize de licne du tray bar
60
Figure 35
Lcran de configuration
60
Figure 36
Lcran daccueil du client PDA
61
Figure 37
Lcran New user du client PDA
61
Figure 38
Lcran de choix des tches du client PDA
62
Figure 39
Lcran des interruptions (pauses) du client PDA
62
Figure 40
Lcran des rsultats du client PDA
63
Figure 41
La page principale du module Web
63
Figure 42
La page dexport du module Web
64
-- 3 --
Figure 43
La page dimport du module Web
64
Figure 44
La rponse du serveur une requte du module Web
65
Figure 45
Architecture Client/Serveur trois niveaux
72
Figure 46
Quelques types de PDA
74
Figure 47
Exemple du fichier XML dimport
81
Figure 48
Exemple du fichier XML des interruptions
82
Figure 49
Exemple du fichier XML dexport
83
Figure 50
Exemple du fichier XML de la configuration
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.
-- 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
CHAPITRE
1
Contexte gnral du projet
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

:
9 Dfinir ou redfinir larchitecture cible ;
9 Assurer lvolution humaine ;
9 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 ;
-- 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
-- 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 :
Date
Start
Stop
Interruption Delta
Time
Activity Comments C
Time
Tableau 1 : Formulaire PSP pour lhistorique de projet

Name :
Job #
Date :
Date
Process
Actual
Time
Units Rate
Estimated
To Date
Time Units
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 ;
-- 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
-- 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
Serveur
dapplications
XML
Partie cliente
XML
Serveur
de BD
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
CHAPITRE
2
Etude du projet
Etude du projet
Introduction
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
Etude du projet
2.2.2. Le principe MVC

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
-- 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
-- 21 --
CHAPITRE 2
Etude du projet
Lua, Forth, Ruby, Lisp, Python,

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
-- 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
-- 24 --
CHAPITRE 2
Etude du projet
responsabilit. La matrice suivante rsume les packages et classes prsentes dans cette couche :
Java.io
Fournit la gestion des flux dentres/sorties
Java.lang
Classes de base du langage (types, )
Java.util
Contient les collections et classes utilitaires
Javax.microedition.io
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
Etude du projet
javax.microedition.lcdui
Fournit la gestion de linterface utilisateur (contrles, )
javax.microedition.midlet
Socle technique destin grer le cycle de vie des midlets
javax.microedition.rms
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

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

-- 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
Acteur
Utilisateur
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
-- 30 --
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>>
Swing
<<Application>>
XML.jar
DesktopIndicator.
DLL
<<Application>>
PDA
Web
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.
-- 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
-- 34 --
CHAPITRE 3
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.

-- 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.
-- 37 --
CHAPITRE 3
DAL
FromXmlToDb
DbSideWriterEntity
: Base de
donnes
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
-- 38 --
CHAPITRE 3
lobjet TaskMgmtForm et lutilisateur naura qu importer ces informations avant de profiter

de notre application
IdentificationForm
WelcomeForm
BegenningDemon
SessionDemon TaskMgmtForm
: Utilisateur
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
entrer login et mot

de passe.
Valider login et
mot de passe.
traitement de
dmarrage.
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
-- 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
TaskMgmtForm
: Utilisateur
SessionDemon
InterruptionForm
EvaluationForm
UserProfile
ConfigForm
TaskProperties
Form
slectioner une tche.

dbut tche (play).
dbut traitement
tche.
interrompre tche(pause). dbut traitement

pause.
play.
saisir informations de pause.

fin traitement pause.
fin tche (stop).

cration.
saisir informations tche.

configurer profile.
fin traitement tche.

sauvegarde de la configuration.
visualiser les proprits

d'une tche selectionne.
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
-- 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
ImportClass
ExportClass
ServletImport DbSideReaderEntity
ServletXport
DbSideWriterEntity
: Utilisateur
synchro...
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.
instanciation.
connexion et ordre
d'import.
fichier d'import ou
message d'erreur.
confirmation ou message d'erreur.

confirmation ou
message
d'erreur.
ordre d'import.
fichier d'import ou
message d'erreur.
message d'erreur
d'import s'il existe.
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.
-- 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
ServletCall
url
response
XportClass
fileLength
message
current
done
1..n ServletCall() 1..n

CallServletFct()
1
1
1..n
ImportClass()
ImportFromServer()
CallServlet()
ClientSocket()
ExtractData()
ExtractConnectionVariable()
GetCurrent()
GetMessage()
IsDone()
1..n
XportClass()
XportToServer()
CallServlet()
ClientSocket()
GetCurrent()
GetMessage()
IsDone()
Xml
1..n
1..n
ReadingServletSwing
login
pwd
XmlFilePath
PortNumber
WritingServletSwing
XmlFilePath
PortNumber
DoGet()
SettingPortNumber()
ServerSocket()
DoGet()
SettingPortNumber()
ServerSocket()
0..1
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
XmlReader
CreateXmlInstance()
Initialise()
GetRoot()
CreateTag()
CreateAttribute()
AddText()
ChangeAttribute()
ChangeText()
DeleteTag()
Serialise()
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.
-- 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
SysTray
taskMgtForm
IdentificationForm
WelcomeForm() 1
GoBack()
GoNext()
Validate()
0..1
SelectPath()
IsPathValid()
0..1
SysTray()
CloseApplication()
NewSession()
CloseSession()
InitSysTray()
IdentificationForm()
Valider()
NewUser()
0..1
0..1
1..n
BeginningDemon
userPath
configPath
login
0..1
1..n
ProgressBar
INVALID
ABORT
ERROR
OK
0..n
1
ProgressBar()
Export()
Import()
BeginTimerImport()
BeginTimerXport()
SetTextUser()
SetCurrentProgress()
GetUserPath()
OldUser()
NewUser()
CreateNewUser()
VerifyXportWarning() 0..1
VerifyImportWarning()
ImportFromFile()
0..1
ImportData()
ImportFromServer()
IsPwdValid()
ApplicationGo()
WarningImportForm
1
1
WarningXportForm
WarningImportForm()
Validate()
WarningXportForm()
Validate()
0..1
1
0..n
SynchronisClientS
ide
Xml
InterruptionForm
InterruptionForm()
FillInterruptionsList()
Validate()
0..n
TaskMgmtForm
TaskMgmtForm()
Interrupt()
Play()
Stop()
Import()
Xport()
Synchronize()
GetConfiguration()
Clear()
GetProperties()
FillTasksList()
CloseSession()
0..n
1..n
1
SessionDemon
INVALID
ABORT
ERROR
OK
userPath
configPath
login
0..1
EvaluationForm
EvaluationForm()
Validate()
0..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.

-- 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
CHAPITRE
4
Ralisation et mise en oeuvre
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.
-- 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
-- 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
-- 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.
-- 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.

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

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

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

-- 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
-- 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.
-- 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
Cest une bibliothque qui regroupe des fonctions sous forme de

classes pouvant tre utilises pour dvelopper.
CDC
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.
Client/Serveur
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.
CLDC
Configuration J2ME pour des appareils possdant de faibles

ressources et une interface utilisateur rduite tels que des tlphones
mobiles, des PDA, etc.
CVM
machine virtuelle Java construite pour les terminaux connects de

forte capacit.
DAL
Couche intermdiaire entre la base de donnes

applications destines lutiliser.
DOM
Spcification et API pour reprsenter et parcourir document XML

sous la forme d'un arbre en mmoire.
J2EE
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, ...
J2ME
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.
J2SE
C'est une version du JDK qui contient le ncessaire pour dvelopper

des applications et des applets.
JAXP
API pour parcourir un document XML (DOM et SAX) et le

transformer avec XSLT.
JRE
Environnement permettant l'excution de programmes Java lors de

leurs diffusions.
JSP
C'est une technologie comparable aux ASP de Microsoft mais

utilisant Java. C'est une page HTML enrichie de tag JSP et de code
et toutes les
-- 68 --
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.
KVM
Une petite machine virtuelle Java construite pour les

terminaux contraint.
MIDlet
Application mobile dvelopp avec CLDC et MIDP.
MIDP
API conue pour tirer le meilleur parti d'un type de terminal prcis
(taille de l'cran, cran tactile, type de rseau ...).
MVC
Un modle de conception largement rpandu qui permet de sparer

l'interface graphique, les traitements et les donnes manipules.
PDA
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).
Pocket PC
Cest le nom des assistants personnels fonctionnant sous le systme

d'exploitation Pocket PC de Microsoft.
POSE
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.
PSP
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.
RMS
Fourni un mcanisme travers lequel les MIDlets peuvent

sauvegarder des donnes et les rcuprer aprs.
SAX
API pour traiter squentiellement un document XML en utilisant des

vnements.
Servlet
C'est un composant Java qui s'excute ct serveur dans un

environnement ddi pour rpondre des requtes. L'usage le plus
-- 69 --
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
Cest un langage unifi utilis surtout dans le cadre des projets

orients objets.
WEB
Cest le service le plus utilis sur Internet permettant la navigation sur

les pages Web.
XML
Meta langage extensible driv de SGML permettant de structurer

des donnes.
-- 70 --
Annexes
-- 71 --
Annexe A
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
2-Tiers
3-Tiers
Administration
Complexe
Moins complexe
Scurit
Basse
Haute
Encapsulation des donnes

Performance
Basse
Haute
Faible
Bonne
Rutilisation des applications
Faible
Excellente
Facilit de dveloppement
Base de donnes htrognes
Haute
Haute
Non
Oui
Dploiement
Complexe
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
-- 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
-- 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
-- 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

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

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
ANNEXE
XML (eXtensible Markup Language)
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.
-- 86 --

Rapport GesProréseaux de Communication

Transféré par

Informations du document

Titre original

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 GesProréseaux de Communication

Transféré par

Droits d'auteur :

Formats disponibles

Universit Mohammed V-Souissi

Ecole Nationale Suprieure

Mmoire de projet de fin dtude

dIngnieur dtat en informatique

Analyse, conception et ralisation dune application de

Anne universitaire 2003-2004

Liste des abrviations

Application Programming Interface

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

Portable Digital Assistante

Personnal Software Process

Record Management System

Socit de Service en Ingnierie Informatique

Unified Modeling Language

eXtensible Markup Language

Projet de Fin dEtude : ENSIAS 2004

Listes des figures et tableaux

Liste des tableaux

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

Liste des figures

Schma gnral de lapplication

Schma global du MVC

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

Scnario de lecture de la base de donnes

Scnario dcriture dans la base de donnes

Scnario nouvel utilisateur

Projet de Fin dEtude : ENSIAS 2004

Diagramme de squences du scnario suivi des tches

Diagramme de squences du scnario synchronisation

Diagramme de classes regroupant les deux packages

Diagramme de classes du package XML

Diagramme de classes du package JobsLogsSwing

Structure de la partie serveur

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