Pfe

Ecole nationale d'ingnieurs de Tunis
--- ,--+-'' ,-' --'

Universit de Tunis El Manar

Dpartement TIC

Projet de Fin dEtudes

Ralis par :
Amal AMAMI
Asma SEDIKI

Pour obtenir le
Diplme National dIngnieur
en
Informatique

Elaboration dun systme dinformation du centre Mdico-Social
des Communications

Soutenu le 15 Juin 2007 devant le jury compos de :
Prsident : M. Ali FRIHIDA
Rapporteur : Mme Minyar SASSI
Encadrants : Mme Zohra SBAI (ENIT)
M. Nam HAMDI (MTC)

Organisme : Ministre des Technologies de la Communication (MTC)
Adresse : 3 bis, rue d'Angleterre - 1000 RP Tunis

Anne : 2006-2007 Rf : PFE /TIC-07

B.P.37 le Belvdre 1002 Tunis Tunisie 37 ,--'-' 1002 -,-
'-' 729 872 71 216 Fax : --'+' 700 874 71 216 Tl:
Email : enit@enit.rnu.tn --'` -,-'

Remerciements

C'est avec beaucoup d'gard que nous tenons remercier Mr Ali Frihida pour avoir accept
de juger notre travail, et Mme Minyar Sassi pour lintrt quelle a bien voulu porter ce
travail en acceptant de lexaminer et den tre le rapporteur.
Nous tmoignons notre gratitude envers nos encadreurs Mme Zohra Sba et M. Nam
Hamdi pour nous avoir fait confiance, en nous proposant ce sujet. Nous les remercions
galement pour leurs suggestions pertinentes ainsi que leurs assistances qui nous ont permis
de mener terme ce projet.

Nous ne saurons terminer sans rendre hommage tout le cadre enseignant de lcole
Nationale des Ingnieurs de Tunis.

Ddicace

Je ddie ce travail

Mes parents,
Pour leur amour, leur comprhension, leur bienveillance et leurs sacrifices.

Mes chers frres et ma chre sur,
Pour les moments que nous avons partags ensemble.

Ma tante Faouziya et mon Oncle Mahjoub,
Pour mavoir considr comme leur fille, pour leur bont et leur affection.

Ma tante Mabrouka,
Parce quelle tait toujours prte mcouter et maider.

Mes amis,
Parce quils nont jamais cess de croire en moi et de supporter mes btises.

Asma Sediki

Ddicace

A mon pre et ma mre,
Cest grce votre amour, votre immense affection, vos encouragements, la
confiance que vous mavez accorde ainsi que vos innombrables sacrifices que
jarrive aujourdhui au terme de ce travail.
Jespre que vous trouvez dans ce travail le tmoignage de ma profonde
reconnaissance et mon ternel attachement.
A mon frre Michal,
En tmoignage de mon affection profonde, avec tous mes vux de le voir russir
dans sa vie.
A tous mes amis, toute ma famille et tous ceux qui me sont chers.
Je ddie ce travail esprant avoir rpondre leurs souhaits de me voir russir.
Amal AMAMI

TABLE DES METIERES

INTRODUCTION GENERALE ......................................................................................................................... 1
CHAPITRE I ANALYSE DU CAHIER DES CHARGES ............................................................................ 3
1. INTRODUCTION .......................................................................................................................................... 4
2. PRESENTATION DE LORGANISME DACCUEIL ............................................................................................ 4
2.1. Rles et contributions ...................................................................................................................... 4
2.2. Etablissements et entreprises publiques sous-tutelle ....................................................................... 4
3. CAHIER DES CHARGES ............................................................................................................................... 5
3.1. Etude de l'existant ........................................................................................................................... 5
3.2. Spcification des besoins ................................................................................................................. 6
3.3. Le dossier mdical lectronique ...................................................................................................... 7
3.4. La rservation en ligne .................................................................................................................... 8
3.5. Public vis ....................................................................................................................................... 8
3.6. Performances exiges ...................................................................................................................... 8
3.7. Support du produit .......................................................................................................................... 8
3.8. Bnfices attendus ........................................................................................................................... 9
3.8.1. Le mdecin ................................................................................................................................................. 9
3.8.2. Le patient .................................................................................................................................................... 9
3.8.3. Le ministre ................................................................................................................................................ 9
4. CAPTURE DES BESOINS .............................................................................................................................. 9
4.1. Les utilisateurs ................................................................................................................................ 9
4.1.1. Le patient .................................................................................................................................................. 10
4.1.2. Le mdecin ............................................................................................................................................... 10
4.1.3. Le paramdical : ....................................................................................................................................... 10
4.1.4. Ladministrateur ....................................................................................................................................... 10
4.2. Besoins fonctionnels ...................................................................................................................... 10
4.3. Besoins non fonctionnels ............................................................................................................... 11
5. CONCLUSION ........................................................................................................................................... 12
CHAPITRE II CHOIX DE LARCHITECTURE .................................................................................... 13
1. INTRODUCTION ........................................................................................................................................ 14
2. PRESENTATION ET CHOIX DARCHITECTURE ............................................................................................ 14
2.1. SOA (Service Oriented Architecture) ............................................................................................ 14
2.1.1. Les composants......................................................................................................................................... 14
2.1.2. Applications ncessitant une architecture oriente service ....................................................................... 15
2.1.3. Avantages et faiblesses ............................................................................................................................. 15
2.2. EDA (Event-Driven Architecture) ................................................................................................. 16
2.2.1. Les Agents ................................................................................................................................................ 16
2.2.2. Les messages ............................................................................................................................................ 17
2.2.3. Applications ncessitant une architecture guide par vnement ............................................................. 18
2.2.4. Avantages et faiblesses ............................................................................................................................. 18
2.3. Choix de larchitecture.................................................................................................................. 19
3. SOA (SERVICE ORIENTED ARCHITECTURE) ............................................................................................ 19
3.1. Origine de la SOA ......................................................................................................................... 19
3.2. Les services : noyau de larchitecture oriente services ............................................................... 20
3.2.1. Respecte le couplage lche (faible) ........................................................................................................... 20
3.2.2. Activable distance et interoprable ........................................................................................................ 20
3.2.3. Asynchrone ............................................................................................................................................... 20
3.2.4. Expose un contrat dutilisation (interface) ................................................................................................ 21
3.2.5. Respecte le pattern darchitecture SOA .................................................................................................... 21
3.3. Description de l'architecture ......................................................................................................... 22
3.3.1. Les couches de larchitecture SOA ........................................................................................................... 22
3.3.2. Interaction entre les services dans un processus ....................................................................................... 23
3.4. Les protocoles et les standards ..................................................................................................... 24
3.5. Services Web ................................................................................................................................. 25
3.5.1. SOAP (Simple Object Access Protocol) ................................................................................................... 26

3.5.2. WSDL (Web Services Description Language) ......................................................................................... 26
3.5.3. UDDI (Universal Description Discovery and Integration) ....................................................................... 26
3.6. BPEL (Business Process Execution Language) ............................................................................ 27
3.7. Standards de conception ............................................................................................................... 27
3.7.1. UML (Unified Modeling Langage) .......................................................................................................... 28
3.7.2. BPMN (Business Process Management Notation) .................................................................................... 28
3.7.3. Choix du standard de la conception .......................................................................................................... 29
3.8. Cycle de dveloppement dune application ................................................................................... 29
3.8.1. Spcification ............................................................................................................................................. 30
3.8.2. Conception gnrale ................................................................................................................................. 30
3.8.3. Conception (service mtier) ...................................................................................................................... 30
3.8.4. SOA-Architecture oriente services (niveau architecture applicative) ..................................................... 31
3.8.5. Modle logique & implmentation technique du modle logique ............................................................ 31
3.8.6. Spcification interne ................................................................................................................................. 31
3.8.7. Implmentation du logicieltest ................................................................................................................ 32
4. CONCLUSION ........................................................................................................................................... 32
CHAPITRE III CONCEPTION .................................................................................................................. 33
1. INTRODUCTION ........................................................................................................................................ 34
2. CONCEPTION GENERALE .......................................................................................................................... 34
2.1. Identification des acteurs .............................................................................................................. 34
2.2. Identification des cas dutilisation et leurs priorits ..................................................................... 34
2.3. Diagramme des cas dutilisation ................................................................................................... 35
2.3.1. Cas dutilisation Rserver rendez-vous ............................................................................................... 37
2.3.2. Cas dutilisation Etablir statistiques .................................................................................................... 37
2.3.3. Cas dutilisation Grer calendrier ....................................................................................................... 38
2.3.4. Cas dutilisation Dcaler date de consultation .................................................................................... 39
2.3.5. Cas dutilisation Gestion dossier mdical ........................................................................................... 39
2.3.6. Cas dutilisation Supprimer Examen .................................................................................................. 40
3. CONCEPTION DETAILLEE ......................................................................................................................... 41
3.1. Conception des services mtiers.................................................................................................... 41
3.1.1. Diagrammes dactivits ............................................................................................................................ 41
3.1.2. Diagramme de classes sans oprations ..................................................................................................... 43
3.2. SOA (niveau darchitecture applicative) ....................................................................................... 45
3.2.1. Les catgories ........................................................................................................................................... 45
3.2.2. Diagrammes de squence opration .......................................................................................................... 45
3.2.3. Diagrammes de squences service ............................................................................................................ 46
3.3. Modle logique et son implmentation technique ......................................................................... 47
3.3.1. Les paquetages .......................................................................................................................................... 47
3.3.2. Les faades et les interfaces ...................................................................................................................... 57
3.3.3. Les services Web ...................................................................................................................................... 57
3.3.4. Les processus ............................................................................................................................................ 58
4. CONCLUSION ........................................................................................................................................... 58
CHAPITRE IV REALISATION ET TESTS .............................................................................................. 57
1. INTRODUCTION ........................................................................................................................................ 60
2. ENVIRONNEMENT ET OUTILS DE DEVELOPPEMENT .................................................................................. 60
2.1. Langage de programmation .......................................................................................................... 60
2.2. Technologies ................................................................................................................................. 60
2.2.1. JSP (Java Servlet Pages) ........................................................................................................................... 61
2.2.2. Le modle Struts ....................................................................................................................................... 61
2.3. Serveur .......................................................................................................................................... 61
2.3.1. Critres de choix ....................................................................................................................................... 61
2.3.2. Prsentation des serveurs .......................................................................................................................... 62
2.3.3. Choix du serveur ....................................................................................................................................... 62
2.4. Environnement de dveloppement ................................................................................................. 63
2.5. SGBD (Systme de gestion de base de donnes) ........................................................................... 63
2.6. Logiciel de conception .................................................................................................................. 64
2.7. Configuration matrielle ............................................................................................................... 64
3. BASE DE DONNEES ................................................................................................................................... 64
4. IMPLEMENTATION DES CLASSES .............................................................................................................. 68
5. LES SERVICES WEB .................................................................................................................................. 68
5.1. Gnration du service Web ........................................................................................................... 68

5.2. Dploiement .................................................................................................................................. 69
5.3. Tests .............................................................................................................................................. 69
5.4. Gnration des classes mandataires (proxy) ................................................................................ 70
6. DEVELOPPEMENT DES PROCESSUS ........................................................................................................... 70
6.1. Implmentation des processus ....................................................................................................... 70
6.2. Dploiement des processus ........................................................................................................... 73
6.3. Tests des processus ....................................................................................................................... 73
6.4. Gnration des classes mandataires ............................................................................................. 73
7. DEVELOPPEMENT DES INTERFACES .......................................................................................................... 74
7.1. Ralisation de laction form .......................................................................................................... 75
7.2. Ralisation de laction .................................................................................................................. 75
7.3. Ralisation des pages JSP ............................................................................................................. 75
7.4. Configuration de la validation de formulaire ............................................................................... 75
8. INTERFACE UTILISATEUR ......................................................................................................................... 75
8.1. Test de linterface .......................................................................................................................... 77
9. CONCLUSION ........................................................................................................................................... 78
CONCLUSION ET PERSPECTIVES .............................................................................................................. 79
BIBLIOGRAPHIE .............................................................................................................................................. 81
ANNEXES ........................................................................................................................................................... 83

LISTE DES TABLEAUX

Tableau 1 : Identifications des cas dutilisation ....................................................................... 35
Tableau 2 : Description du cas dutilisation Rserver rendez-vous ..................................... 37
Tableau 3 : description du cas dutilisation Etablir statistique ........................................... 38
Tableau 4:Description du cas dutilisation Dcaler date de consultation ............................ 39
Tableau 5 : Description du cas d'utilisation Supprimer examen ........................................ 41
Tableau 6 : Description de lopration : VerificationReservation ..................................... 43
Tableau 7: Les services Mtiers du systme dinformation ..................................................... 43

LISTE DES FIGURES

Figure 1: Composants d'une SOA ............................................................................................ 15
Figure 2 : Le mcanisme dinscription/publication dans EDA ............................................... 16
Figure 3 : Couplage lche entre les services ........................................................................... 20
Figure 4 : Communication interdite entre services .................................................................. 21
Figure 5 : Communication entre les services en respectant les nomes de la SOA ................... 22
Figure 6 : Les couches SOA .................................................................................................... 23
Figure 7 : Architecture SOA ................................................................................................... 24
Figure 8: Structure dun message SOAP .................................................................................. 26
Figure 9 : Cycle de dveloppement ......................................................................................... 30
Figure 10 : Diagramme des cas d'utilisation global du systme .............................................. 36
Figure 11 : Diagramme du cas d'utilisation Grer calendrier............................................... 38
Figure 12: Diagramme de cas d'utilisation Grer dossier patient ....................................... 40
Figure 13 : Diagramme dactivits calculer date rservation spcialit ................................ 42
Figure 14 : Diagramme de classes sans oprations .................................................................. 44
Figure 15 : Diagramme de squence opration operationCreerVisiteControle ................. 46
Figure 16:Diagramme de squence du service imprimer ordonnance ............................... 47
Figure 17 : Les catgories, les processus et les services Web composant le systme ............. 48
Figure 18 : Dpendances entre les packages du modle logique ............................................. 48
Figure 19 : Classes de la catgorie Rservation ....................................................................... 49
Figure 20 : Classes de la catgorie Dossier Patient ............................................................ 50
Figure 21 : Service Web ServiceMetierCalendrier ............................................................ 58
Figure 22: Les classes du processus ReserverVisiteSpec ...................................................... 58
Figure 23 : Modle relationnel du package rservation ........................................................... 65
Figure 24 : Rsultat du test de lopration CalculerDateSp .............................................. 69
Figure 25 : La partie du processus rservation par Mdecin qui correspond au switch2 .. 71
Figure 26 : Processus rservation par Mdecin .................................................................. 72
Figure 27: Flux visuel de lexcution du processus ReserverMedecin .............................. 74
Figure 28: Formulaire de Rservation ...................................................................................... 76
Figure 29: Rsultat de la rservation ....................................................................................... 76
Figure 30: Les rservations dun mdecin ............................................................................... 77
Figure 31 : Formulaire Ajout Agent ................................................................................... 77

Introduction Gnrale
1
Introduction Gnrale

Il est vident aujourdhui que les technologies dinformations et des communications (TIC)
ont fait preuve defficacit dans une multitude de domaines. Ainsi, gouvernements et
particuliers sont en train dadopter les solutions informatises pour amliorer la qualit de
leurs services et produits. Lun des secteurs o les TIC sont en pleine expansion est la sant
puisque les dirigeants et les mdecins sont de plus en plus conscients des apports des TIC
pour ce secteur. Cest ainsi que plusieurs tablissements sanitaires ont choisi de se procurer
dun systme dinformation mdical.
Un Systme d'Information Mdical (SIM) est un systme d'information appliqu aux mtiers
de la sant, et plus particulirement aux tablissements de sant. Il est constitu de lensemble
des informations et des traitements ncessaires laccomplissement des missions de
ltablissement de sant. Lun des composants standards du SIM est le dossier mdical du
patient. Ce dernier regroupe toutes les donnes du patient qui sont ncessaires aux dcisions
diagnostiques et thrapeutiques. Il est destin par essence comporter la trace d'lments
personnels et intimes concernant le malade et donc le dossier mdical est couvert par le secret
mdical.
Mdecins et administrateurs s'accordent pour voir dans un SIM le moyen d'amliorer la
qualit des soins tout en permettant une gestion plus rationnelle de l'activit mdicale. En
effet le systme dinformation mdical permet de faciliter lexercice professionnel quotidien
par la fourniture d'outils de classification permettant de retrouver les informations rapidement
selon plusieurs critres. De plus, les mdecins peuvent accder aux dossiers des patients dune
faon permanente. Enfin, la raction des dirigeants devient immdiate grce aux rapports,
statistiques et donnes qui sont fournis instantanment.
Cest dans ce cadre que le MTC a propos de crer un systme dinformation (SI) pour le
centre Mdico-Social. Ce centre est sous la tutelle du MTC, il fournit des consultations
mdicales pour les agents du ministre. Vu les activits limites du centre Socio-Mdical, le
SI doit permettre uniquement la gestion des dossiers mdicaux des patients et la rservation
des rendez-vous en ligne.
Introduction Gnrale
2
La structure du prsent rapport est fortement inspire du travail ralis. Il est rparti sur quatre
chapitres. Le premier sintresse lanalyse du cahier des charges et la spcification des
besoins. Le second est consacr aux choix dune architecture pour le SI. En effet aprs avoir
compar quelques architectures, nous allons dtailler larchitecture lue. La conception, faite
travers les diagrammes UML , est lobjet du troisime chapitre. Le quatrime chapitre
dtaille ltape de ralisation, prsente les outils et les technologies utiliss pour achever
limplmentation et dcrit les tests effectus pour dtecter les anomalies du SI ralis.

Chapitre I Analyse du cahier des charges

Chapitre 1 : Analyse du cahier des charges
4
1. Introduction
Dans ce chapitre, nous allons prsenter dans un premier lieu lorganisme dans lequel nous
avons effectu notre stage. Dans un second lieu, nous allons dfinir le cahier des charges qui
dcrit lexistant et met en vidence les bnfices attendus de ce travail. Enfin nous allons
dgager les besoins fonctionnels et non fonctionnels ainsi que les utilisateurs qui vont
interagir directement avec cette application.
2. Prsentation de lorganisme daccueil
Le Ministre des Technologies de la Communication (MTC) est une administration publique
charge de la mise en place d'un cadre rglementaire qui organise le secteur des
tlcommunications, la planification, le contrle et la tutelle en vue de permettre au pays
d'acqurir les nouvelles technologies.
2.1. Rles et contributions
Le ministre est charg notamment de :
coordonner entre les structures charges des tudes stratgiques dans le domaine de la
Poste, des Tlcommunications et de la technologie de l'Information [16],
laborer des normes techniques,
encadrer les programmes de la recherche et les activits industrielles en vue de leur
adaptation aux besoins du secteur [16],
laborer les tudes de rentabilit tarifaires et les modalits de fixation des tarifs des
Tlcommunications et des tarifs postaux,
fixer les conditions et les modalits relatives la mise en place et l'exploitation des
services valeur ajoute des tlcommunications,
suivre lactivit des Entreprises sous tutelle du ministre du point de vue technique et
financier [16],
collecter et analyser des statistiques relatives au secteur et proposer des programmes
insrer dans les plans de dveloppement et en valuer les rsultats [16].
2.2. Etablissements et entreprises publiques sous-tutelle
Ecole Suprieure des Communications.
5
Institut Suprieur des Etudes Technologiques en Communications.
Ple Technologique "El gazala" des Technologies de la Communication.
Centre d'Information, de la formation, de documentation et des tudes dans les
technologies de la communication.
Tunisie Tlcom.
La Poste Tunisienne.
Agence Nationale de Certification Electronique.
Agence Nationale des Frquences.
Agence Nationale de la Scurit Informatique.
Agence Tunisienne de l'Internet.
Office National de la Tldiffusion.
Centre National de l'Informatique.
Centre d'Etudes et de Recherche des Tlcommunications.
Centre Mdico-Social des communications.
3. Cahier des charges
Le projet consiste concevoir un SI pour le centre Mdico-Social. Ce centre est un
tablissement sous tutelle du MTC (ministre des technologies de communication), il
propose un ensemble de consultations, spcialises et gnrales, pour les agents travaillants au
MTC ou dans un organisme sous tutelle du ministre. Lobjectif est dassurer :
la rservation des consultations en ligne,
la gestion des dossiers mdicaux des patients.
3.1. Etude de l'existant
Le ministre dispose dun second centre localis au sud de la Tunisie. Ce centre est
relativement peu quip et ne propose pas de consultation pour certaines spcialits mdicales
et par la suite il redirige un nombre considrable de ses patients vers le centre de Tunis.
La rservation pour des consultations gnralistes se fait directement au niveau du guichet du
centre Mdico-Social du MTC. Un agent qui prsente sa carte dadhsion peut avoir au
mme jour une consultation chez un gnraliste. Le problme le plus crucial se pose pour les
consultations chez des spcialistes o les demandes sont plus nombreuses et le nombre des
mdecins est assez limit. Actuellement la rservation se fait de trois manires :
Soit en se prsentant directement au guichet.
6
Soit en appelant le centre par tlphone.
Soit encore il sagit dune visite de contrle fixe auparavant par un mdecin.
Un agent prend en charge son conjoint et ses enfants. Le dossier de l'agent est cre lors de sa
premire visite au centre en prsentant sa carte d'adhsion. Il est unique pour chaque agent et
peut tre consult par tous les mdecins du centre. Lors d'une visite mdicale, le patient est
tenu payer un tarif bien dtermin. Il consulte, ensuite, le mdecin qui doit prciser dans la
fiche du patient la date, les signes, le diagnostic ainsi que les prescriptions.
3.2. Spcification des besoins
L'objectif du projet est de concevoir et raliser une application pour la gestion des dossiers
mdicaux des patients ainsi qu'une application de rservation en ligne. Les principales
fonctionnalits assurer sont :
la rservation des rendezvous pour un patient enregistr auparavant,
lajout, la suppression dun agent et la mise jour de ses informations personnelles,
la mise jour des horaires de consultations,
lajout et la suppression des mdecins,
Lannulation et le dcalage des rendez-vous des patients par le centre,
lannulation des rendez-vous par les patients,
la consultation de la liste des rservations de toute la famille,
la consultation du dossier mdical et la visualisation des informations gnrales dun
patient donn, les diffrentes consultations quil a eu chez tous les mdecins
(diagnostic, symptmes, date de visite, mdecin traitant, prescriptions,etc.), ses
radiologies et ses analyses,
la consultation par un mdecin de la liste des patients quil doit examiner pour une
date particulire,
lajout dune nouvelle consultation (diagnostic, symptmes, date de visite
prescriptions, lettre de liaison),
lajout danalyses et de radiologies au dossier dun patient,
l'impression des ordonnances, et des courriers permettant aussi bien de communiquer
avec l'extrieur que de constituer un dossier archive sur papier (congs de maladie,
hospitalisation, examens complmentaires, etc.).
7
3.3. Le dossier mdical lectronique
La famille dun agent possde un seul dossier mdical identifi uniquement par le numro de
matricule de lagent. Le dossier mdical contient les informations suivantes :
le numro de matricule de lagent,
nom et prnom de lagent,
date de recrutement,
grade,
poste de travail,
adresse professionnelle,
adresse personnelle,
numro de tlphone personnel,
numro de tlphone professionnel,
prnom du conjoint,
prnoms des enfants et leurs dates de naissances,
les maladies chroniques.
Au sein du dossier mdical, chaque membre de la famille possde lensemble danalyses et de
radiologies quil a effectu ainsi que sa propre fiche mdicale qui contient :
numro de matricule,
type du membre A (agent), C (conjoint), ou E (enfant),
nom et prnom,
date de naissance,
dates de consultations,
nom et prnom du mdecin qui a examin le patient,
symptmes et observations pour chaque consultation,
le diagnostic du mdecin,
les prescriptions.
Une prescription peut tre :
des mdicaments ainsi que les doses prescrites,
des analyses,
des actes infirmiers,
des actes techniciens suprieurs (kin, orthophonie..),
des radiologies,
un cong de maladie.
8
3.4. La rservation en ligne
Pour rserver un rendez-vous un patient choisit un mdecin spcialiste ou gnraliste pour
une consultation ultrieure en prcisant son numro de matricule et son prnom. Le mdecin
peut tre choisi par le patient selon le nom ou la date de visite la plus proche. La consultation
d'un spcialiste n'est accepte qu'avec une lettre de liaison fournie par un gnraliste. A la fin
de la procdure de rservation l'agent reoit une confirmation de la date et l'heure de
consultation et peut aussi imprimer le coupon de la rservation. Il est aussi possible pour un
agent d'annuler une ou plusieurs rservations.
3.5. Public vis
Le dossier mdical lectronique est destin tous les mdecins du centre Mdico-Social. En
effet cette application permettra dune part de faciliter et optimiser la consultation des
antcdents, des analyses et des radiologies dun patient par son mdecin et dautre part
dinformatiser la tche de cration dun dossier. La rservation en ligne est principalement
destine aux agents du MTC afin de rserver un rendez-vous en vue dune consultation au
centre mdico-social.
3.6. Performances exiges
Afin de satisfaire les diffrents utilisateurs, il faut assurer un certain niveau de performance :
La gestion de la scurit vu le caractre confidentiel des informations.
Simplicit dutilisation (assister le mdecin dans la saisie des comptes rendus dune
visite, guider le patient lors de la rservation).
Accs facile aux donnes recherches.
Mise jour facile des informations.
Des outils pour automatiser la rdaction des comptes rendu des visites, les
prescriptions et les certificats par le mdecin.
Rapidit daccs aux donnes mme avec une base de donnes importantes.
3.7. Support du produit
Lapplication de rservation va tre hberge sur Internet alors que le dossier mdical
lectronique va tre dploy sur le rseau local du centre.
9
3.8. Bnfices attendus
La ralisation de ce SI intresse principalement:
3.8.1. Le mdecin
Le mdecin a pour intrt de :
Avoir la possibilit dexaminer des cas de patients avant de les rencontrer (listes des
patients examiner pour une date donne).
Avoir laccs aux dossiers des patients dune faon permanente.
Partager tous les dossiers avec plusieurs mdecins pouvant accder au mme temps.
Avoir un accs facile et permanents aux statistiques sans avoir besoins les tablir.
Recherche aise de patients cibls.
Le secret mdical est plus respect (les dossiers des patients ne peuvent tre consult
que par les mdecins).
3.8.2. Le patient
Le patient a pour intrt de :
Se librer de la contrainte dapport et de conservation des radiologies et des rsultats
danalyses.
Gagner en termes de dplacement et de temps.
3.8.3. Le ministre
Le ministre a pour intrt de :
Avoir des donnes prcises et compltes sur ltat sanitaire des agents.
Avoir des statistiques et des informations prcises sur les congs de maladies et par
consquence sur le rendement des agents.
4. Capture des besoins
Cette partie sintresse identifier les utilisateurs et spcifier dune faon dtaille les besoins
fonctionnels et non fonctionnels.
4.1. Les utilisateurs
Les personnes intresses par ce SI sont essentiellement :
10
4.1.1. Le patient
Il sera capable de :
Effectuer une rservation distance et recevoir une confirmation de la date de la
consultation.
Annuler une rservation distance.
Consulter lensemble de ses rservations.
4.1.2. Le mdecin
Grce ce systme, il pourra :
Accder facilement la liste des patients quil va examiner une date donne.
Planifier une visite de contrle pour un patient la fin ou au cours de sa consultation.
Grer le dossier mdical du patient (ajout/suppression/consultation des rsultats dun
examen, ajout/consultation du compte rendu dune visite).
Impression des ordonnances et des congs de maladies.
4.1.3. Le paramdical :
A travers cette application, le paramdical gagne en terme de temps de recherche et peut
aisment :
Ajouter, supprimer un agent et mettre jour les donnes des agents.
Mettre jour lemploi de consultation (les mdecins, les dates de consultations).
Mettre jour la liste des mdecins (ajout, modification, suppression et dsactivation).
4.1.4. Ladministrateur
Un administrateur a la possibilit daccder tout type de donnes. Ainsi il peut vrifier le
bon fonctionnement du travail au centre et visualiser des statistiques pour prparer les
rapports annuels ou superviser le rendement du personnel du centre.
4.2. Besoins fonctionnels
Les besoins fonctionnels expriment les services offerts lutilisateur et les fonctionnalits
envisages que nous allons prsenter lors de cette tape. Lapplication de rservation en ligne
doit assurer :
la rservation dune consultation ou lannulation dune rservation effectue,
la consultation de la (les) rservations(s) dun agent,
11
la consultation de la liste des patients ayant effectu des rservations chez un mdecin
donn et une date choisie,
la possibilit de mettre jour lemploi des consultations des mdecins,
la mise jour des informations dun agent ainsi que la liste des personnes quil prend
en charge (le conjoint (e) et ses enfants).
La mise jour de la liste des mdecins
Lapplication du dossier mdical dossier Mdical doit assurer :
La consultation du dossier Mdical dun patient donn (informations gnrales sur
lagent et les personnes prises en charge)
la possibilit un mdecin de planifier une visite de contrle pour son patient,
La consultation de lhistorique des visites effectues par les membres de la famille,
Limpression dune ordonnance ou dun cong de maladie,
Lajout dune nouvelle visite (signes, prescriptions, diagnostic, examens, etc.),
La consultation de diffrentes statistiques.
Toutes ces fonctionnalits impliquent videmment une authentification pralable de tout
utilisateur pour quil puisse grer uniquement les actions permises par ses droits daccs.
4.3. Besoins non fonctionnels
Les besoins fonctionnels permettent de dcrire des contraintes techniques dans le but de
rendre des besoins fonctionnels oprationnels car il ne faut en aucun cas ngliger les facteurs
de performance, fiabilit, fonctionnalit, prise en charge des risques afin de pouvoir remdier
aux problmes de performance du systme (rapidit, temps de rponse, rutilisation, temps de
chargement des pages, etc.). Les besoins que nous avons pu extraire sont :
Ceux qui se rapportent la scurit indiquant les droits daccs comme par exemple
au bout de N tentatives le systme interdit intgralement laccs prvenant ainsi tout
risque dintrusion. En effet bnficier dun login et dun mot de passe dfinissant les
droits daccs de tout utilisateur sparment constitue en lui-mme une mesure de
scurit qui va permettre dviter les mauvaises intentions de certains utilisateurs
telles que la modification ou la suppression de donnes.
Temps de rponse rapide: accs rapide la base, chargement rapide des pages, temps
de rponse aux requtes des utilisateurs court.
Sauvegarde immdiate en cas de panne.
Interface Homme Machine conviviale, ergonomique et simple.
Lintgration de nouvelles applications doit tre simple, facile et rapide,
12
Larchitecture doit tre conforme larchitecture choisie par les dveloppeurs.
Lapplication doit tre paramtrable et extensible et offre la possibilit dajouter de
nouvelles spcialits, diagnostic, signes et prescription lorsquils ne sont pas
disponibles dans les listes de choix.
5. Conclusion
En dgageant le cahier des charges, nous avons pu comprendre les dtails de lexistant, dfinir
les fonctionnalits que notre SI est cens assurer et mettre en vidence les bnfices attendus
de ce travail. Dautant plus que nous avons essay de dterminer lensemble des besoins
fonctionnels et non fonctionnels et les utilisateurs de cette application.

Chapitre II Choix de larchitecture

Chapitre 2 : Choix de larchitecture
14
1. Introduction
Une architecture permet d'organiser et d'assembler des composants entre eux afin de
construire l'application souhaite. Larchitecture est gnralement base sur un langage ADL
(Architecture Definition Language) qui met en place un ensemble dartefacts (composant,
connecteur, liaison, port, interface, etc.) et une syntaxe concrte permettant aux dveloppeurs
de dcrire la structure des applications [5]. Ce chapitre sintresse au choix dune architecture
convenable notre SI. En effet nous allons prsenter dune faon gnrale les architectures
candidates, ensuite nous allons dterminer notre choix darchitecture pour finir avec une tude
dtaille de larchitecture choisie.
2. Prsentation et choix darchitecture
Compte tenu de lexistence dun second centre mdical et dune ventuelle intgration dans
un SI global pour le ministre, nous avons choisi dtudier deux architectures permettant
lextensibilit et la rpartition de notre systme. Ces deux architectures, qui simposent
aujourdhui vu leurs avantages et leurs souplesses, sont: la SOA (Service Oriented
Architecture) et lEDA (Event Driven Architecture). Dans la suite nous allons prsenter ces
architectures et choisir celle qui est la plus adquate notre application.
2.1. SOA (Service Oriented Architecture)
L'architecture oriente services peut tre considre comme un modle de composition qui
connecte diffrentes units fonctionnelles d'une application, les services, par des interfaces
bien dfinies et des contrats entre ces services. L'ide sous-jacente est de cesser de construire
le SI de l'entreprise autour d'applications et de construire une architecture logicielle globale
dcompose en services correspondant aux processus mtiers de l'entreprise. [12] Ainsi, tous
les messages ou toutes les requtes ayant pour destination un service spcifique sont envoys
l'adresse unique du service.
2.1.1. Les composants
SOA est constitue de trois composants primaires (figure 1) :
Le consommateur : Il correspond l'application cliente (ou un autre service) et fait
appel au service pour une tche prcise.
Le fournisseur : Le fournisseur de services est lorganisation qui dlivre un service.
15
Le rpertoire de services : Le rpertoire de services a un rle primordial dans la SOA.
C'est lui qui reoit la requte du consommateur, dcouvre le fournisseur adquat, et
agit en tant quintermdiaire entre consommateur et fournisseur. En s'assurant que les
fournisseurs de services informent rgulirement les rpertoires de leurs nouveauts,
le consommateur peut constamment profiter de celles-ci sans pour autant devoir
mettre jour ses mthodes. Un rpertoire peut tre priv, c'est--dire interne
l'entreprise, ou public.

Figure 1: Composants d'une SOA
2.1.2. Applications ncessitant une architecture oriente service
SOA est utilise lorsque les tapes du processus sont sous un seul contrle et en particulier
dans les applications caractriss par :
Interaction verticale entre les couches hirarchiques de dcomposition fonctionnelle.
Processus demander-rpondre tels que des dialogues homme machine lorsque
l'utilisateur attend une rponse.
Processus avec une nature transactionnelle.
2.1.3. Avantages et faiblesses
Les avantages de ladoption dune telle architecture sont multiples, en effet :
SOA apporte une agilit supplmentaire au niveau de l'implmentation des services.
Les interfaces sont entirement indpendantes de la plateforme matrielle, du systme
d'exploitation ou mme du langage de programmation utilis pour implmenter les
services. Cela permet des services dploys sur diffrents systmes d'interagir
ensemble facilement [12].
La rutilisation des services et la rduction des fonctions redondantes.
Il est facile de faire voluer une partie des services sans consquence pour les autres
services associs [5].
La maintenance est facile et la tolrance aux pannes est considrable.
Cependant, plusieurs faiblesses freinent lutilisation de SOA grande chelle :
Effort consquent en termes de modlisation.
16
Un manque de modles muler.
Des outils relativement immatures.
Des soucis de scurit de la part des dveloppeurs.
2.2. EDA (Event-Driven Architecture)
EDA dfinit une architecture et une mthodologie pour concevoir les applications et les
systmes dans lesquels les vnements se transmettent entre les composants du logiciel. Dans
cette architecture, la communication est lance par un ou plusieurs vnements provenant
dun nud source, lvnement produit se propage toutes les parties intresses (humains ou
automates) [7]. Une structure intermdiaire (programme) permet de gnrer des messages
appropris chacun des abonns cet vnement et denvoyer ces messages simultanment
(figure 2) [3]. Les parties intresses valuent lvnement et dcident ou non de rpondre par
des actions. Ces actions peuvent inclure linvocation des services, le dclenchement dun
processus et/ou la publication dune information. Deux types de composants sont prsents
dans EDA : les agents et les messages.

Figure 2 : Le mcanisme dinscription/publication dans EDA [7]
2.2.1. Les Agents
EDA possde trois types dagents savoir les gnrateurs dvnements, les organiseurs et les
consommateurs dvnements.
i. Les gnrateurs dvnements
Ces composants surveillent l'environnement et produisent des messages (vnements) qui
dcrivent un certain aspect de l'tat de l'environnement.
ii. Les organiseurs
17
Etant donne la varit des gnrateurs dvnements, ce nest pas la totalit des vnements
qui vont tre gnrs dans le format requis pour le traitement d'vnements. Dans ces cas, ces
vnements doivent se transformer au format requis avant d'tre livrs aux consommateurs
finaux. Cette tche est assure par les organiseurs qui reoivent une multitude de flux de
messages, les traitent, et produisent des flux de messages leur tour [3].
iii. Les consommateurs dvnements
Ce sont les parties qui consomment les vnements. Aprs rception, les vnements sont
valus par rapport des rgles de traitement et les actions sont inities. Les rgles de
traitement des vnements et les actions sont dfinies en accord avec les besoins des parties
intresses mais pas avec ceux des gnrateurs dvnements [3].
iv. Interaction entre les agents
Lorsquun organiseur reoit un vnement de la part dun gnrateur, il transmet des
messages aux consommateurs. Si ceux-ci ne sont pas prsents, lorganiseur stocke les
messages et les transmet plus tard.
2.2.2. Les messages
EDA possde deux types de messages : les messages dvnement et les messages de
contrle.
i. Messages dvnements
Un message dvnement peut tre :
Simple : Concerne les vnements directement relis aux changements spcifiques de
conditions (qui sont mesurables). Ils sont utiliss pour reprsenter un flux de travail en
temps rel.
Stream : Concerne les vnements ordinaires (ordres, RFID, etc.) et remarquables. Ils
sont utiliss pour reprsenter des flux dinformations lintrieur et lextrieur de
lentreprise et ncessitent donc le respect de la contrainte de temps.
Complexe : Un vnement complexe est le rsultat dinfrence de plusieurs
vnements simples et ordinaires ce qui ncessite la prise dune dcision concernant la
considration et limpact de chacun des vnements puisque la corrlation entre ces
vnements peut tre occasionnelle, temporelle, ou spatiale. Il est ncessaire dutiliser
18
des interprteurs d'vnements sophistiqus, de dfinitions et assortiments de modle
d'vnement, et de techniques de corrlation. [3]
ii. Messages de contrle
Un message de contrle contient des commandes qui spcifient ou mettent jour les contrats
spcifiant le type de flux dvnements devant tre reu ou envoy par un nud. Ce qui
implique limportance cruciale de ce type de message dans la dtermination de lefficacit de
lapplication de lEDA. [7]
2.2.3. Applications ncessitant une architecture guide par vnement
EDA est conseille pour les systmes o il ya une indpendance entre les tapes dun
processus :
Communication horizontale entre les ranges dans une chane de processus [3].
Processus se droulant comme en Workflow (Annexe 1).
2.2.4. Avantages et faiblesses
EDA prsente plusieurs avantages :
Les diteurs dcoupls d'vnements d'interactions : diteurs d'vnement ne se
rendent pas compte de l'existence des abonns d'vnements [7].
Dveloppement et maintenance (ajout de nouveaux modules) des grandes applications
distribues incluant des activits imprvisibles, parallles ou asynchrones.
Efficacit lors de lenvoie des mmes donnes plusieurs sources puisque dans ce cas
lenvoi se fait une seule fois alors quen SOA lenvoi se fait pour chaque destination
part.
La reconfiguration et lassemblage des composants dans un nouveau processus sont
plus rapides, faciles est peu coteux [7].
Favorise la rutilisation des composants dans des applications multiples.
Mais cette architecture souffre de faiblesses qui freinent lvolution de son utilisation :
Les normes sont trs inacheves, ainsi tous les programmes doivent employer le mme
produit middleware d'un mme fournisseur [3].
Inexprience des crateurs d'application et des architectes concevant des applications
de traitement d'vnements complexes.
Des produits d'usage universel de middleware d'EDA sont vendus par de petits
fournisseurs avec peu de rfrences de production [3].
19
Les dveloppeurs doivent assembler et intgrer les outils de dveloppement, de
gestion et les quipements de scurit.
2.3. Choix de larchitecture
Apres avoir tudi ces deux architectures et en se basant sur les fonctions assurer par notre
SI nous avons choisi dadopter larchitecture SOA pour plusieurs raisons :
Les normes et les modles ainsi que les concepts sont plus clairs en SOA quen EDA
compte tenu de linexprience des dveloppeurs pour larchitecture guide par les
vnements.
SOA a fait preuve de son efficacit dans plusieurs projets.
La documentation pour les tapes de conception et de dveloppement est disponible
pour SOA.
Lapplication de rservation peut tre inscrite dans une vision demande rponse.
La notion dvnements dans notre SI nest pas redondante de faon adopter
larchitecture guide par vnement.
Les fonctionnalits assures par chaque service sont celles qui guident notre
application.
3. SOA (Service Oriented Architecture)
Dans la suite nous allons prsenter en dtails larchitecture SOA ainsi que tous les modles et
les concepts qui lui sont lis. Vu la nature de notre systme (Application Web) nous allons
utiliser les services Web tout en notant quen gnral une telle architecture peut se mettre en
uvre sans Services Web.
3.1. Origine de la SOA
La SOA nest pas une dmarche entirement nouvelle. Lide de concevoir des architectures
orientes services est ne au dbut des annes 1990 avec lapparition des solutions
Client/Serveur. Les architectures SOA ont t popularises avec l'apparition des standards
comme les Services Web dans l'e-commerce [6]. Elles sont laboutissement des retours
dexpriences lis majoritairement deux technologies : lEAI (Annexe 1) et les Services
Web.
Aujourdhui, les besoins douverture du SI, les gnrations rcentes des serveurs
dapplication (J2EE, .NET) et les Services Web (SOAP, WSDL) donnent une nouvelle
20
importance au SOA. Il sagit de btir des architectures applicatives adaptes aux serveurs
dapplication, capables dexposer des services interoprables et de collaborer entre les
entreprises.
3.2. Les services : noyau de larchitecture oriente services
Un service dans une architecture SOA est un traitement qui respecte les cinq proprits
dtailles dans la suite, trois de ces proprits sont obligatoires savoir le couplage lche avec
les autres services, respecter le pattern darchitecture SOA, exposer un contrat dutilisation.
3.2.1. Respecte le couplage lche (faible)
Un service ne peut appeler un autre service directement que sil appartient la mme
catgorie (voir 3.2.5). Il dlgue cette fonction un traitement spcialis dans lenchanement
(fonction dorchestration). On associe galement la proprit du couplage faible (figure 3)
lindpendance de lactivation du service vis--vis des technologies dimplmentation. Pour
ce faire, lactivation se ralise par lenvoi (et la rception) dun message XML. [8]

Figure 3 : Couplage lche entre les services [8]
3.2.2. Activable distance et interoprable
Un service expose une interface dutilisation qui est la mme indpendamment de la
localisation du service sur les rseaux. Lappel au service fonctionne quelque soit le langage
et le systme dexploitation du client. Un service dont lactivation se ralise toujours au sein
dune mme machine virtuelle utilise un appel local (pas dactivation distance ncessaire).
[8]
3.2.3. Asynchrone
Un service fonctionne de manire asynchrone cest--dire quil ne bloque pas le client
pendant quil sexcute. Ce principe est intressant pour rduire les goulets dtranglement
(performance, robustesse).
21
3.2.4. Expose un contrat dutilisation (interface)
Un service expose un contrat dutilisation dcrit en deux parties. Une partie abstraite qui
dclare les messages dentre et de rponse du traitement offert. Une partie concrte qui dcrit
les standards et protocoles techniques utiliss pour lactivation du service (XML, RPC,
SOAP-HTTP, etc.) [8]. Selon les choix dimplmentation et de dploiement, il est possible
davoir plusieurs parties concrtes pour une mme partie abstraite. On nomme aussi le contrat
dutilisation par le terme dinterface de service. Cette proprit est respecte entirement
lorsque lon met en uvre les services Web. En effet, le document WSDL permet disoler les
parties abstraite et concrtes.
3.2.5. Respecte le pattern darchitecture SOA
Le pattern darchitecture SOA consiste crer une architecture applicative qui dcompose les
traitements sous la forme de services rattachs des paquets de classes. Ces paquets forment
des Catgories, chacune dote dune faade daccs qui contient lensemble des services
quelle expose (on parle aussi de port). Un service a le droit dinteragir uniquement avec les
classes de sa catgorie.
En SOA, lencapsulation ne se fait pas uniquement au niveau le plus lmentaire de la classe
mais aussi au niveau suprieur des catgories UML. Cette proprit est entirement respecte
dans la pratique. Cest partir de cette proprit que lon dcouvre les services. Sur la figure
4, on voit plusieurs violations des principes du couplage faible car les services sappellent
directement entre eux aussi bien au niveau dune catgorie quentre deux catgories. [8]

Figure 4 : Communication interdite entre services
La figue 5 montre lapproche retenir et qui contribue larchitecture SOA. Une fonction
dorchestration apparat et prend en charge les appels entre services nappartenant pas la
mme catgorie. Ainsi, chaque catgorie reste isole des autres.
22

Figure 5 : Communication entre les services en respectant les nomes de la SOA
3.3. Description de l'architecture
Pour comprendre larchitecture SOA, il est possible de la reprsenter comme un ensemble de
couches qui interagissent les unes avec les autres.
3.3.1. Les couches de larchitecture SOA
La figure 6 reprsente les couches suivantes :
Couche 6 : LESB (Entreprise Service Bus) a un rle de mdiateur (middleware) entre
le consommateur et le producteur du service (figure 7), il permet ainsi de raliser le
couplage lche. Le Bus de Service doit tre capable de recevoir les messages
synchrones ou asynchrones quelque soit le protocole qui les transmet et doit aussi
diriger un message vers sa destination en se basant sur les rgles de configuration. Il
doit aussi offrir la possibilit de transformer le message dans le format exig par la
destination. Ainsi il contrle le flux de messages entre le consommateur et le
fournisseur, le bus de service est lunique pour pouvoir grer, contrler et faire
respecter les niveaux des services.
Couche 5 : Un consommateur est une application cliente qui fait appel directement
aux services ou bien au processus.
Couche 4 : Un processus est lorchestration de plusieurs oprations qui sont
coordonns par un orchestrateur (Business service orchestrator) afin de rpondre une
demande faite par un consommateur. Une opration peut tre compose dun ou
plusieurs services.
23
Couche 3 : Le service est le noyau de larchitecture SOA, il a t dj dcrit dans ce
chapitre. Il fournit un traitement lorsquil est invoqu par un processus ou par un
client.
Couche 2 : Une catgorie est un ensemble de classes lis smantiquement, elle
reprsente un objet mtier ou sujet mtier partir duquel sont construits un ensemble
de services. Elle est dote dune faade qui lui permet dexposer ses services. Et un
service dune catgorie peut faire appel des mthodes des classes de sa catgorie. La
cartographie du diagramme de classes en catgories forme lossature de SOA. Cette
dmarche est dterminante plusieurs niveaux :
o Permet la dcomposition des processus sous la forme de services rattachs aux
catgories.
o Autorise lorganisation des quipes de conception et de dveloppement par
catgorie afin de contrler les interactions entre des intervenants multiples.
Couche 1 : Cest lensemble de mthodes implmentes, chaque mthode appartient
une classe donne.

Figure 6 : Les couches SOA [17]
3.3.2. Interaction entre les services dans un processus
Dans cette partie, un service est simul une opration. Afin de dcrire ce mcanisme, nous
avons besoin de dfinir tout dabord lannuaire de services. En effet, l'annuaire de services
rfrence l'ensemble des services (et des contrats associs) disponibles au sein du systme, il
24
participe ainsi activement la mise en uvre d'une cartographie dynamique du systme
(figure 7). Dans un modle de bus, l'annuaire peut tre autoaliment par le service
(enregistrement et mise jour des contrats). Linteraction des services, dans un processus, est
dcrite dans la figure 7 :
Le service consommateur cherche un service fournisseur dans lannuaire.
Lannuaire retourne le contrat du service cherch au consommateur.
Le consommateur cre une instance du processus ou du service fournisseur.
Le fournisseur peut tre un processus ou un service et dans les deux cas linstance
sexcute et la rponse est retourne au consommateur.

Figure 7 : Architecture SOA [7]
3.4. Les protocoles et les standards
Larchitecture SOA repose sur un ensemble de protocoles et de standards qui doivent tre
communs lensemble des agents (fournisseurs de services et consommateurs de services).
Dans la suite nous allons numrer les standards les plus utiliss et nous allons dcrire ensuite
chaque standard:
La gestion d'un annuaire de services avec : UDDI (Universal Description Discovery
and Integration) normalis par l'OASIS [17].
La description des interfaces des services avec : WSDL (Web Services Description
Language) recommand par le W3C [17].
25
Linvocation (ou l'appel) du service (la requte transmise au service) avec : SOAP
(Simple Object Access Protocol) recommand par le W3C [17].
Le format des donnes changes avec : XML (extensible Markup Language)
recommand par le W3C.
Le transport des donnes avec les protocoles Internet : HTTP et TCP/IP qui sont des
normes RFC.
Lexcution et lorchestration des processus avec le langage de modlisation de
processus BPEL [17].
La conception avec : UML ou BPMN.
Remarque : UDDI, SOAP, WSDL sont les trois piliers des services Web.
3.5. Services Web
Depuis la fin des annes 90, Internet est en extension constante. Les entreprises apprcient
particulirement cette infrastructure communicante et elles utilisent de plus en plus les
technologies lies au Web dans leurs systmes d'information. Un besoin de standard s'est
rapidement fait sentir dans l'change des donnes entre les applications ou les domaines
interentreprises. C'est dans ce cadre que les services Web, issus du consortium W3C, sont
devenus un standard pour permettre l'change d'informations entre les applications
interagissant les unes avec les autres. [2]
Les services Web permettent l'appel d'une mthode ou d'un objet distant en utilisant un
protocole Web pour transport (http en gnral) et XML pour formater les changes. Les
services Web fonctionnent sur le principe du client serveur :
un client appelle les services Web,
le serveur traite la demande et renvoie le rsultat au client,
le client utilise le rsultat.
L'appel de mthodes distantes n'est pas une nouveaut mais la grande force des services Web
est d'utiliser des standards ouverts et reconnus : HTTP et XML. L'utilisation de ces standards
permet d'crire des services Web dans plusieurs langages et de les utiliser sur des systmes
d'exploitation diffrents. Les services Web utilisent des changes de messages au format
XML. Les services Web utilisent trois technologies savoir SOAP, UDDI et WSDL.
26
3.5.1. SOAP (Simple Object Access Protocol)
SOAP est utilis pour le service d'invocation et permet l'change de messages dans un format
particulier. SOAP peut tre utilis pour :
l'appel de mthodes (SOAP RPC),
l'change de message (SOAP Messaging).

Figure 8: Structure dun message SOAP
SOAP dfinit la structure principale du message (figure 8), dite enveloppe qui contient
deux parties : la tte (Header) et le corps (Body). Le corps est compos d'un ou plusieurs
blocs. Un bloc contient des donnes ou un appel de mthode avec ces paramtres. Tous ces
lments sont cods dans le message XML avec un tag particulier mettant en oeuvre un
espace de nommage particulier dfini dans les spcifications de SOAP. Un message SOAP
peut aussi contenir des pices jointes contenues chacune dans une partie optionnelle nomme
Attachment Part. Ces parties sont au mme niveau que la partie SOAP Part. [15]
3.5.2. WSDL (Web Services Description Language)
WSDL est une norme qui utilise XML pour dcrire des services Web. L'utilisation de WSDL
n'est pas obligatoire mais elle est utilise par la plupart des outils pour faciliter la gnration
automatique de certains objets dont le but est de faciliter l'utilisation du service. [15]
3.5.3. UDDI (Universal Description Discovery and Integration)
Cest un protocole et un ensemble de services pour utiliser un annuaire afin de stocker les
informations concernant les services Web et de permettre un client de les retrouver. [15]
27
3.6. BPEL (Business Process Execution Language)
Le langage BPEL a t lanc linitiative de Microsoft et IBM en rponse linitiative de
BPMI (Annexe 1). Depuis, ce langage a reu le support de la plupart des acteurs du march, y
compris de BPMI. Il vient en complment de la spcification sur les services Web. Depuis
2003, cest lorganisme de standardisation OASIS (Annexe 1) qui a en charge lvolution du
langage BPEL [1]. BPEL est un langage fond sur XML et permettant de dcrire des
orchestrations compltement excutables. En quelques mots, BPEL permet de dcrire des
actions communicationnelles (envois et rceptions de message dont les types sont dcrits en
WSDL et XML Schema), et de lier ces actions au travers d'oprateurs de flot de contrle (par
exemple la squence, le choix, l'itration, et les clauses throw/catch pour le traitement des
exceptions) [2]. En tant que langage d'implantation de services, BPEL est incorpor dans
plusieurs outils de construction d'applications base de services.
En BPEL, la logique des interactions entre un service et son environnement est dcrite par le
biais d'une composition d'actions lmentaires de communication (mission, rception ou
mission/rception). Ces actions sont relies les unes aux autres par un flot de contrle
spcifi par des constructions telles que la composition parallle (avec un nombre fix de
branches), squentielle, et conditionnelle, des rgles de type vnement-action et des clauses
de capture/transmission d'erreur. La manipulation des donnes s'effectue par le biais de
variables, comme dans un langage de programmation imprative. [17] Plus prcisment, un
processus exprim en BPEL est construit partir d'activits primitives qui peuvent tre
composes pour dfinir d'autres activits plus complexes.
Dans le langage BPEL, tout est service : un processus excutable est l'implantation d'un
service qui s'appuie sur d'autres services. Lorsqu'une ressource, telle qu'une base de donnes,
un fichier, ou une application patrimoniale, est utilise par un service, il est ncessaire
d'exposer le SGBD, le systme de gestion de fichiers, ou l'application comme des services.
3.7. Standards de conception
La conception est une tape primordiale dans le dveloppement dune application ainsi le
choix dune mthode de conception doit tre prcis et adquat aux besoins de lapplication.
Ladoption dune architecture SOA nous a incites comparer les deux standards UML et
BPMN.
28
3.7.1. UML (Unified Modeling Langage)
Propos par lOMG pour la conception oriente objet, UML 1.X (1.1, 1.2, 1.3, 1.4) dispose
dun modle dactivit qui prsente certaines fonctionnalits pour la modlisation des
processus. Cependant, sa porte reste limite la conception objet et son mtamodle
comporte certaines erreurs smantiques (activit = tat) qui en rduisent dautant le caractre
oprationnel. Ces faiblesses ont t reconnues par lOMG qui a profondment revu ce modle
dans la version 2 dUML. La fin de lanne 2004 devrait voir laboutissement de la
spcification UML 2.0 de lOMG, fruit dun long processus de maturation. Les modles
dactivits dUML 2.0 ont t totalement revus par rapport aux versions 1.X. Les erreurs
notables des spcifications 1.X ont t corriges et le nouveau modle offre une base robuste
pour lanalyse des processus. [1]
i. Avantages
Il prsente lavantage doffrir neuf diagrammes assez disparates et recouvrent la
plupart de vue pour la conception dune application.
Existence doutils qui gnrent partir des processus dfinis en UML les fichiers
correspondant en BPEL et WSDL.
ii. Limites
UML sadresse encore essentiellement des concepteurs de processus automatiss. Le
modle dactivit dUML 2.0 ne peut pas fournir, tel quel, un support danalyse et de
communication pour les processus "mtier", en effet UML s'adresse plutt aux dveloppeurs
pratiquant la programmation objet.
3.7.2. BPMN (Business Process Management Notation)
A la suite du langage dexcution BPML (Business Process Management Langage), BPMI a
lanc une nouvelle initiative sur la notation graphique des processus. Cest ainsi qua t
publie la spcification BPMN 1.O en mai 2004. BPMN prsente une avance indniable
dans la formulation graphique des processus. Elle introduit, en particulier, la notion de
message et de flux dinformation qui manquait la plupart des reprsentations traditionnelles
de processus. Un des objectifs principaux de BPMN, dans sa version 1.0, a t la possibilit
de reprsenter les processus excutables. Les rgles de correspondance avec le langage
dexcution BPEL viennent complter le dispositif. [1]
29
i. Avantages
BPMN s'adresse en principe aux analystes business.
BPMN va permettre plus facilement de passer rapidement de la thorie la pratique.
En effet, aprs une validation de la modlisation du processus par simulation, les
outils de BPMN vont tre capables de gnrer du langage d'excution oprationnelle
de ce processus, s'appuyant sur XML et pris en compte par un moteur de processus
spcialis.[4]
ii. Limites
BPMN ne propose qu'un seul diagramme, il s'agit du diagramme de processus, trs proche du
diagramme dactivit d'UML. Il est assez difficile de reprsenter toutes les vues dune
application dans un seul diagramme.
3.7.3. Choix du standard de la conception
Nous avons choisi dadopter UML dans la conception de notre systme puisque :
BPMN dfini un diagramme unique qui na aucun concept de la modlisation
structurelle de lapplication.
BPMN ne sintresse pas la modlisation des besoins.
La notion de processus nest pas dominante dans notre application.
Les processus ne sont pas compliqus et donc ne ncessite pas des moyens
sophistiqus pour les concevoir.
3.8. Cycle de dveloppement dune application
Le cycle de dveloppement des applications adoptant une architecture oriente service est
particulier vu quil est guid par la notion de service. La figure 9 prsente les diffrentes
tapes de ce cycle.

30

Figure 9 : Cycle de dveloppement [8]
3.8.1. Spcification
Cette tape permet de dgager le cahier de charge de lapplication et de spcifier les besoins
fonctionnels et non fonctionnels assurer.
3.8.2. Conception gnrale
Dterminer les acteurs qui interagissent avec lapplication ainsi que les cas dutilisation est le
but de cette phase, elle correspond au diagramme des cas dutilisation en UML.
3.8.3. Conception (service mtier)
Cette tape modlise les processus et les donnes du systme et donc la notion de service
mtier est introduite ds ce niveau. En UML, ce stade correspond au niveau du modle
organisationnel des traitements (Diagramme dactivits) et du modle des donnes
(Diagramme de classes) [8]. Un service mtier contient une ou plusieurs oprations. Ces
oprations peuvent tre dgages depuis le diagramme dactivits puisquune opration est
une ou plusieurs activits conscutives. Pour chaque opration, il faut spcifier :
les prconditions,
31
les postconditions,
les exceptions,
le message dentre,
le message de rponse,
objectifs et principes de fonctionnement de lopration. [8]
Aprs avoir dgag les services mtiers, un contrat est rdig pour chaque service mtier. Ce
contrat dutilisation dfinit les engagements du fournisseur et les conditions dusage
respecter par le consommateur [8]. Pour chaque service mtier, il contient :
une description gnrale du service,
la description des oprations,
architecture des donnes : La partie du diagramme de classes qui contient les classes
voques en entres et sorties par les oprations du service,
rgles gnrales (version du soap pour un service Web, scurit, utilisation doutils de
reporting, etc.),
contact support fournisseur,
contact support consommateur,
adresse (serveur, WSDL, etc.).
3.8.4. SOA-Architecture oriente services (niveau architecture applicative)
Il faut noter quun service ici est diffrent dun service mtier, il prsente le noyau de
larchitecture SOA et nous lavons dj dcrit dans ce chapitre. En effet une opration peut
contenir un ou plusieurs services. Cette phase sintresse rpartir les classes sur des
catgories, dgager les services invoqus par chacune des oprations dtermines dans la
phase prcdente et dcomposer ces services en des mthodes. Les diagrammes utiliss
pendant ce stade sont les diagrammes de squences et le diagramme de classes.
3.8.5. Modle logique & implmentation technique du modle logique
Cette tape construit un modle logiciel (framework) qui supporte lensemble des concepts
issus de la modlisation. Cest une organisation de classes, dinterfaces, de faades et de
packages qui normalisent lorganisation du logiciel. [8]
3.8.6. Spcification interne
Il sagit de la spcification dtaille des services et des traitements dorchestration.
32
3.8.7. Implmentation du logicieltest
Il sagit du codage, de dploiement et du test de lapplication.
4. Conclusion
Le choix de larchitecture ainsi que son tude dtaille nous a permis de connatre la nature
des composants dans notre systme et la nature des relations entre ces lments. De plus ce
chapitre a prsent les diffrents standards qui vont tre utiliss pendant les tapes de
conception et dimplmentation.

Chapitre III Conception

Chapitre 3 : Conception
34
1. Introduction
La conception a pour objectif de formaliser les tapes prliminaires du dveloppement d'un
systme afin de le rendre plus fidle aux besoins du client. Ce chapitre va mettre en vidence
la particularit de ce stade pour une architecture SOA en prsentant la conception gnrale et
la conception dtaille du systme. La conception dtaille est ralise en trois tapes
conscutives, la premire est la conception des services mtiers, la seconde est le niveau
darchitecture interne et la troisime est le modle logique.
2. Conception gnrale
Cette tape consiste identifier les acteurs mis en jeu ainsi que les cas dutilisations.
2.1. Identification des acteurs
Les acteurs sont les utilisateurs potentiels du systme, ils sont identifis partir du cahier de
charge. Les acteurs principaux de notre SI sont :
Patient : Le systme lui permet de grer lensemble de ses
rservations (ajout/suppression/ consultation).
Mdecin: Il utilise le systme pour grer le dossier mdical dun patient, planifier les
visites de contrles et consulter la liste de patients ayant rserv pour une date donne.
Les acteurs secondaires du systme sont :
Paramdical : Le systme lui permet de grer la liste des mdecins, des agents,de
mettre jour le calendrier des consultations.
Administrateur : Il utilise le systme pour tablir des statistiques concernant les
patients, les maladies et les mdecins.
2.2. Identification des cas dutilisation et leurs priorits
Les diffrents cas dutilisation dispatchs par acteur sont rsums dans le tableau suivant:
Acteur Nom du cas dutilisation Priorit
affecte
Phase de
dveloppement
Patient
Rserver rendez-vous 1 1
Consulter rservation 1
Annuler rservation 1
Patient/
Mdecin spcialiste/
Paramdical
Sauthentifier 2
35
Paramdical
Ajouter/Modifier
agent/Mdecin/spcialit
1

2
Grer calendrier 1
Supprimer Agent/dsactiver
mdecin
2
Mdecin spcialiste
Rserver une visite de contrle 2
Consulter liste des patients 2
Ajouter fiche patient/ Visite
mdicale
1 3
Consulter Dossier Mdical/
Fiche patient/ Visite mdicale
1
Ajouter/Supprime/Consulter
rsultats dun examen
1
Imprimer Congs/ Imprimer
ordonnance
2
Administrateur
Consulter statistiques 2
Tableau 1 : Identifications des cas dutilisation
2.3. Diagramme des cas dutilisation
Les diffrents cas dutilisation sont rpartis entre les diffrents acteurs comme reprsents
dans la figure 10.


36
<<include>>
Mettre jour Dossier
mdical
Rserver rendez-vous
Annuler rservation
Consulter rservation
Agent du
ministere
s'authentifier
<<include>>
<<include>>
<<include>>
Grer calendrier
<<include>>
Supprimer Agent
<<include>>
Modifier Info Adhrant
<<include>>
Ajouter Adhrant
<<include>>
Dcaler date de
consultation
paramedical
<<include>>
Supprimer Fiche
Supprimer dossier
<<include>>
Rserver visite de
contrle
<<include>>
Grer dossier patient
<<include>>
medecin
Administrate
ur
Etablir statistiques
<<include>>
<<include>>

Figure 10 : Diagramme des cas d'utilisation global du systme

37
2.3.1. Cas dutilisation Rserver rendez-vous
Titre du cas dutilisation : Rserver rendez-vous
But : Permet un patient de rserver une consultation chez un spcialiste ou un gnraliste du
centre
Acteur : patient
Pr condition : Le patient sest authentifi
Post condition : rservation effectue
Enchanement :
1- Lacteur choisit deffectuer une rservation
2- Le systme charge la page de rservation
3- Lacteur choisit le prnom du patient, la spcialit et/ou le nom du mdecin et prcise
sil dispose dune lettre de liaison ou non
4- Le systme vrifie les choix
5- Le systme affiche la date et lheure prvues pour la consultation
6- Lacteur affirme sa rservation
7- Le systme termine la rservation et confirme le succs de la rservation
Enchanements alternatifs
Lacteur ne dispose pas dune lettre de liaison
4- Le systme affiche un message
Lacteur a dj effectu une rservation chez un mdecin de mme spcialit
6 - Le systme affiche un message prcisant quune rservation existe
Flux de donnes dans le systme
Prnom du patient, lettre de liaison (oui ou non), spcialit et/ou mdecin.
Exceptions possibles gnres
Vous avez dj effectu une rservation chez un mdecin de mme spcialit
Vous devez avoir une lettre de liaison pour rserver chez ce mdecin
Tableau 2 : Description du cas dutilisation Rserver rendez-vous
2.3.2. Cas dutilisation Etablir statistiques
Titre du cas dutilisation : Etablir statistiques
But : Permet dtablir des statistiques

38
Acteur : Administrateur
Pr condition : Ladministrateur sest authentifi
Enchanement :
1- Lacteur choisit lune des statistiques
2- Le systme demande lacteur de prciser ou de choisir un ensemble de paramtres
(date, nom, code, etc.) selon le type de statistique
3- Lacteur valide sa demande
4- Le systme value la validit des paramtres
5- Le systme tablie les statistiques et les affiches
Enchanement alternatif:
5-paramtres non valides
6-signaler lerreur et demande de correction
Paramtres de la statistique choisie
Tableau 3 : description du cas dutilisation Etablir statistique
2.3.3. Cas dutilisation Grer calendrier
La gestion du calendrier, confie au paramdical, implique la mise jour de la liste des
mdecins, des spcialits ainsi que celle de lemploi de consultation (figure 11).

Ajouter mdecin
Grer calendrier
paramedical
Mettre jour liste medecin
Mettre jour emploi des
consultations
<<extend>>
<<extend>>
dsactiver mdecin
<<extend>>
<<extend>>
Supprimer mdecin
<<extend>>
Modifier mdecin
<<extend>>

Figure 11 : Diagramme du cas d'utilisation Grer calendrier

39
2.3.4. Cas dutilisation Dcaler date de consultation
Titre du cas dutilisation : Dcaler date de consultation
But : Permet un paramdical de dcaler un ensemble de rservations dune semaine et de
bloquer la date indique pour que personne ne puisse faire une autre rservation cette date.
Acteur : Paramdical
Pr condition : Le paramdical sest authentifi
Enchanement :
1- Lacteur choisit de bloquer une date de consultation
2- Le systme charge le formulaire contenant la liste des mdecins
3- Lacteur choisit la date bloquer et le mdecin
4- Le systme vrifie la correspondance de cette date avec un jour de consultation du
mdecin, bloque cette date et dcale les rservations faite pour cette date de
consultation.
5- Le systme confirme le succs de la tche.
La date entre ne correspond pas un jour de consultation du mdecin indiqu
5- Le systme indique que le format de la date nest pas valide.
Numro de mdecin, date bloquer.
Tableau 4:Description du cas dutilisation Dcaler date de consultation
2.3.5. Cas dutilisation Gestion dossier mdical
Le mdecin est le seul acteur capable de grer les dossiers mdicaux des patients vu le
caractre confidentiel des informations lies aux maladies et aux examens effectus par les
patients (figure 12).

40
Ajouter fiche
Consulter fiche patient
Ajouter visite
Modifier visite
Supprimer visite
Consulter visite
Ajouter Examen
Consulter Examen
Supprimer Examen
Imprimer prescription
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
<<extend>>
Grer dossier patient
<<extend>>
<<extend>>
medecin
<<extend>>
Consulter liste patients
<<extend>>

Figure 12: Diagramme de cas d'utilisation Grer dossier patient
2.3.6. Cas dutilisation Supprimer Examen
Titre du cas dutilisation : Supprimer Examen
But : Permet de supprimer le fichier contenant les rsultats dun examen
Acteur : Mdecin.
Pr condition : Fichier existe
Post condition : Fichier supprim du disque dur du serveur
Enchanement :
1- Le mdecin choisit un examen et valide son choix
2- Le systme affiche un message demandant au mdecin de confirmer la suppression de
lexamen
3- Le mdecin confirme son choix
4- Le systme supprime le fichier du disque
5- Le systme supprime le fichier de la base de donnes

41
3- Le mdecin annule lopration
prnom et matricule du patient dans le dossier patient
Problme lors de la suppression opration non effectue
Tableau 5 : Description du cas d'utilisation Supprimer examen
3. Conception Dtaille
3.1. Conception des services mtiers
Cest au niveau de la modlisation des processus que lon spcifie les services mtiers
exposs aux consommateurs. Plus prcisment, il sagit des oprations qui composent ces
services.
3.1.1. Diagrammes dactivits
Le diagramme dactivits reprsente un modle de traitement modlis sous la forme dun
enchanement dactivits, il permet de dcrire un processus. Nous avons pris en exemple le
diagramme dactivits calculer date rservation spcialit (figure 13) qui correspond au
processus Rserver Visite par Spcialit et au cas dutilisation Rservez rendez vous
spcialit . Il permet de retourner la date de rservation la plus proche pour une spcialit
choisie. Chaque activit dans ce diagramme correspond une opration.

42
calculer date
vrifier si
rservation existe
vrifier spcialit et
lettre de liaison
lettre et spcialit non
compatibles
rservation existe dj
date de rservation
Systme

Figure 13 : Diagramme dactivits calculer date rservation spcialit
La description de lopration verificationReservation qui correspond lactivit vrifier
si rservation existe est reprsent si dessous :
Opration : verificationReservation
Description : Cette opration permet de dterminer si un agent possde dj une
rservation pour une spcialit prcise.
Prconditions :
Lettre de liaison non requise pour la spcialit ou lettre de liaison requise et le patient la
possde.
Postconditions :
Si le patient possde une rservation pour cette spcialit alors le processus se termine
Sinon le processus continue et lopration correspondant lactivit calculer date est
excute.
Message dentre :

43
Matricule_agent : chaine de caractres
Prenom :chaine de caractres
Spcialit : entier
Message de rponse :
Rsultat : boolen
Exceptions :
Spcialit inexistante
Matricule non trouv
Prnom nexiste pas dans la famille de lagent
Tableau 6 : Description de lopration : VerificationReservation
3.1.2. Diagramme de classes sans oprations
Le diagramme de classe a pour but d'crire de faon formelle les donnes qui seront utilises
par le systme. Il sagit de dterminer lensemble des classes ainsi que les cardinalits des
relations qui existent entre elles. Ces classes sont prsentes dans la figure 5. Ce diagramme
et les diagrammes dactivits permettent de dgager et de regrouper les oprations sous
formes de services Mtiers. A la fin de ltape de conception des services mtiers, nous avons
pu dgager huit services mtiers qui sont prsents dans le tableau 7.

Service Mtier Description
ServiceMetierCalendrier Regroupe les oprations lies la gestion du
calendrier des consultations.
ServiceMetierEnfant Regroupe les oprations qui permettent la
gestion des enfants des agents.
ServiceMetierMedecin Regroupe les oprations lies la gestion des
mdecins et des spcialits mdicales.
ServiceMetierFiche Regroupe les oprations qui permettent la
gestion des fiches des patients ainsi que leurs
examens.
ServiceMetierReservation Regroupe les oprations lies la gestion des
rservations effectues par les patients
ServiceMetierVisite Regroupe les oprations qui permettent la
gestion des visites y compris les prescriptions,
le diagnostic et les symptmes.
ServiceMetierOrdonnance Regroupe les oprations lies la gestion des
ordonnances et des congs de maladies.
ServiceMetierAgent Regroupe les oprations qui permettent la
gestion des agents et les organismes o ils
travaillent.
Tableau 7: Les services Mtiers du systme dinformation

44

Reservation
NUM_RES : Integer
DATE_RES: Date
prenom : String
Specialite
CodSpec : Integer
LibSpec : String
lettre : Boolean
Medecin
Nom : String
Prenom : String
CodMed : Integer
NbHeur : Integer
NbePat : Integer
Password : String
active : Boolean
1
1..n
1
1..n
Organisme
CODE : Integer
LIB : String
MALAD_CH
maladie : String
codeMaladie : Integer
EmploiConsultation
jour : String
heure : Integer
NumCons : Integer
DateBloque : Date
1
1..n
1
1..n
Enfants
Prenom : String
DatNais : Date
CodEnf : Double
TypePrescription
typeP : String
idP : Integer
(fromDossier Patient)
Examen
idExam : Integer
nom : String
lien : String
Signes
nom : String
idS : Integer
specialite : Integer
Diagnostic
NomD : String
IdDiag : Integer
Prescription
IdPrescription : Integer
Conges
IdC : Integer
nombreJours : Integer
Visite
dateV : Date
codeMed : Integer
IdV : Integer
0..1
0..n
0..n
0..n 0..n
0..1
0..n
0..1
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
1
0..1
1
Fiche
Prenom : String
Membre : String
idFiche : Integer
0..n
1
0..n
1
0..n 1 0..n 1
AgentDuMinstere
ADH_MATRIC : String
Nom : String
Prenom : String
ADH_ADRESS : String
ADH_DATNA : Date
ADH_SITF : String
ADH_PREC : String
GRADE: String
DAT_REC : Date
NUM_TEL : Integer
addresseProf : String
telProf : Integer
n
1
n
1
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
1
0..n
1
0..n
1 0..n 1 0..n

Figure 14 : Diagramme de classes sans oprations
catgorie Reservation
catgorie Dossier Patient

45
3.2. SOA (niveau darchitecture applicative)
A ce niveau de conception la notion de catgorie est introduite, ainsi les classes vont tre
rparties sur des catgories. De plus le diagramme de classes va tre achev puisque nous
allons dcomposer les oprations en des services et les services en des mthodes laide des
diagrammes de squences.
3.2.1. Les catgories
En respectant les rgles de dcoupe du diagramme de classes (classe matresse, rgles de
composition et de compltude, rgle d'autonomie, etc.) nous avons pu rpartir les classes sur
deux catgories.
i. Les classes de la catgorie rservation
La catgorie reservation renferme toutes les classes utilises pour grer et accomplir la
rservation en ligne (figure 14). La classe de poids fort dans cette catgorie est la classe
AgentduMinistre. Un agent peut possder plusieurs enfants et effectuer plusieurs
rservations. Chaque rservation est lie une consultation dfinie par lheure, le jour et le
mdecin consult.
ii. Les classes de la catgorie Dossier Patient
La catgorie Dossier Patient renferme les classes lies la consultation mdicale
(prescriptions, examen, signes, symptmes, etc.). La classe de poids fort dans cette catgorie
est la classe Fiche appartenant un seul dossier mdical. Elle reprsente la fiche dun
patient et donc elle est lie aux examens et visites effectus par le patient (figure 14).
3.2.2. Diagrammes de squence opration
Les diagrammes de squences dune architecture SOA peuvent tre conus par opration ce
qui permet didentifier les services invoqus dans une opration particulire. Par exemple
lopration operationCreerVisiteControle (figure 15) permet de rserver un rendez vous en
prcisant le mdecin et la date de consultation. Cette opration invoque deux services
appartenant la catgorie Reservation .Le premier service est
serviceNumConsMedFromDate , il permet de retourner le numro de consultation (chaque
consultation est dfinie par un jour, une heure et un mdecin) partir du code du mdecin et
de la date de rservation. Le second service est serviceAjoutReservation , il permet

46
denregistrer la rservation en fournissant le nom du patient, le numro de sa matricule, le
numro de consultation et la date de rservation.
oprationCreerVisiteControl
e
IOreservationImp
1: serviceNumConsMedFromDate(Integer codMed, Date d)
2: serviceAjoutReservation(String prenom, String matricule, Integer umC, Date d)

Figure 15 : Diagramme de squence opration operationCreerVisiteControle
3.2.3. Diagrammes de squences service
Les diagrammes de squence dune architecture SOA sont conus aussi par service c'est--
dire quun diagramme de squence montre linteraction dun service avec les mthodes des
classes appartenant la mme catgorie. Par exemple le service ServiceAjouterVisite
(figure 16) qui permet denregistrer une visite y compris les prescriptions, les symptmes et le
Diagnostic. Ce service plusieurs mthodes qui assurent
La rcupration de dernier identifiant de visite dans une fiche dun patient.
La sauvegarde des informations gnrales concernant la visite comme le numro de la
fiche du patient, la date de la visite et lidentifiant du mdecin.
La sauvegarde des prescriptions.
La sauvegarde du diagnostic.
La sauvegarde du cong de maladie sil existe.
La sauvegarde des symptmes de la maladie.


47
Service ajouter
visite
: Visite : PresriptionP : DiagnosticP : Conges : SigneP
enregistrVisite(Integer, Integer)
numVisite(Integer)
enregistrerPrsPatient(Integer, Integer, String, Integer)
enregistrerdiagPatient(Integer, Integer, String, Integer)
enregistrerCong(Integer, Integer, String, Integer)
enregistrerSignPatient(Integer, String, Integer, Integer)

Figure 16:Diagramme de squence du service imprimer ordonnance
3.3. Modle logique et son implmentation technique
Lobjectif de continuit du travail entre la conception des services mtiers, larchitecture SOA
et limplmentation du logiciel conduit la construction dun modle logique qui rifie, sous
la forme de classes, les concepts manipuls. Ce modle est dterminant pour amliorer la
traabilit entre la conception et le logiciel, pour respecter les principes de larchitecture de
services et donc augmenter la qualit.
3.3.1. Les paquetages
Larchitecture SOA impose de rpartir les classes sur des catgories (paquetages) et
dencapsuler chaque service Web et chaque processus dans un paquetage part (figure 17).
Les catgories et les Services web ont t dcrits prcdemment. Les processus sont au
nombre de six et sont :
BloquerDate,
ReservationSp,
ReservationMedecin,
SupprimerAgent,
SupprimerMedecin,
MAHistorique.

48
reservation
<<objet metier>>
Servi ceMeti erReservati on
<<web servi ce>>
servi ceMeti erMedeci n
<<web servi ce>>
Dossi erPati ent
<<objet meti er>>
Servi ceMeti erEnfant
<<web servi ce>>
Servi ceMeti erCalendrier
<<web servi ce>>
Servi ceMeti erAgent
<<web servi ce>>
Servi ceMeti erFi che
<<web servi ce>>
Servi ceMeti erVi site
<<web servi ce>>
Servi ceMeti er
ordonnance
<<web servi ce>>
Bl oquerDate
<<processus>>
Reservati onMedeci n
<<processus>>
Reservati onSp
<<processus>>
Suppri merMedeci n
<<processus>>
Suppri merAgent
<<processus>>
MAHi stori que
<<processus>>

Figure 17 : Les catgories, les processus et les services Web composant le systme

Reservati onMedeci n
<<processus>>
Servi ceMeti erAgent
<<web servi ce>>
Servi ceMeti erReservati on
<<web servi ce>>
servi ceMeti erMedeci n
<<web servi ce>>
reservati on
<<obj et meti er>>

Figure 18 : Dpendances entre les packages du modle logique

49
IOreserv ation
serv iceAjouterAgent()
serv iceModif ierAgent()
serv iceCalculerDateReserv ation()
serv iceCalculerDateResserv ation()
serv iceAjouterReserv ation()
serv iceDecalerReserv ation()
serv iceAnnulerReserv ation()
serv iceConsulterReserv ationPrenom()
serv iceConsulterReserv ationMedecinDate()
serv iceReserv erVisiteControle()
serv iceAjouterEnf ant()
serv iceSupprimerEnf ant()
serv iceSupprimerAgent ()
serv iceAjouterSceance()
Serv iceAjouterMedecin()
serv iceConsulterEmploi()
serv iceSupprimerSceance()
serv icePrenomExiste()
serv iceNumConsMedFromDate()
serv iceSpecialiteLettreLiaison()
serv iceReserv ationExiste()
serv iceCodMedecin()
serv iceConsulterAgent()
serv iceConsulterEnf ant()
serv iceConsulterMed()
serv iceList eEnf ants()
<<Interface>>
IOreserv ationImp
serv iceCalculerDateResserv ation()
serv iceVerif ierPossiReserv ation()
serv iceAnnulerReserv ation()
serv iceConsulterReserv ationPrenom()
serv iceConsulterReserv ationMedecinDate()
serv iceReserv erVisiteCont role()
serv iceSupprimerAgent()
serv iceConsulterEmploi()
serv icePrenomExiste()
serv iceCodMedecin()
serv iceConsulterAgent()
serv iceConsulterEnf ant()
serv iceConsulterMed()
serv iceListeEnf ants()
Reserv ation
NUM_RES : Integer
DATE_RES : Date
prenom : String
DerniereDateResMed()
nbReserv ationMedDate()
Serv iceSupprimerReserv at ion()
Reserv ation()
serv iceVerif ierPossiReserv ation()
Reserv ation()
serv iceReserv ationExistMatr()
Reserv ationExiste()
serv iceVerf ierReserv ationNumCons()
serv iceListeReserv ationMedDate()
serv iceListeReserv ationPrenom()
depasserDate()
serv iceMAJres()
Specialite
CodSpec : Integer
LibSpec : String
lettre : Boolean
Specialite()
listeSpecialite()
serv iceChercherSpecialite()
ChercherSpecialite()
serv iceList eSpecialite()
serv iceAjouterSpec()
Serv iceSupprimerSpecialite()
Medecin
Nom : String
Prenom : String
CodMed : Integer
NbHeur : Integer
NbePat : Integer
Password : String
activ e : Boolean
listeMedecin()
serv iceAjouterMedecin()
serv iceModif ierMed()
serv iceAcces()
Medecin()
ChercherMedecin()
serv iceSupprimerMedecin()
serv iceInf oMedecin()
serv iceListeMedecin()
listeMedecin()
serv iceListeMedecin()
serv iceChercherMedecin()
serv iceAf f ecterPassword()
serv iceModif StatutMed()
1
1.. n
1
1.. n
Organisme
CODE : Integer
LIB : String
serv iceRechercherOrganisme()
serv iceList eOrganisme()
Organisme()
Organisme()
serv iceAjouterOrgnisme()
serv iceRechercherOrganisme()
Enf ants
Prenom : String
DatNais : Date
CodEnf : Double
serv iceListeEnf antsAgent()
serv iceChercherEnf ant ()
Enf ants()
supprimerListeEnf antsAgent()
rechercherEnf ant()
MALAD_CH
maladie : String
codeMaladie : Integer
MALAD_CH()
EmploiConsultation
jour : String
heure : Integer
NumCons : Integer
DateBloque : Date
ListeConsultationMedecin()
getDateBloque()
listeEmploiSpec()
nbConsultation()
chercherSceance()
EmploiConsultation()
prochaineCons()
serv iceBloqueDate()
NumConsParSpec()
serv iceChercherSceance()
serv iceVerif ierPossAjSceance()
serv iceSupprimerListeConsult()
depasserBloque()
serv iceMAJDateBl()
serv iceEmploi()
1
1.. n
1
1.. n
AgentDuMinstere
ADH_MATRIC : String
Nom : String
Prenom : String
ADH_ADRESS : String
ADH_DATNA : Date
ADH_SITF : String
ADH_PREC : String
GRADE : String
DAT_REC : Date
NUM_TEL : Integer
telProf : Integer
ChercherAgentMatricule()
serv iceChercherPrenomDansAgent()
serv iceRechercherAgent()
AgentDuMinstere()
serv iceSupprimerAgent()
listMaladies()
AgentDuMinstere()
serv iceChercherAgentMatricule()
1
1
1
1
1
0..n
1
0..n
0..n
0.. n
0..n
0.. n
0..n
0.. n
0..n
0.. n

Figure 19 : Classes de la catgorie Rservation

50

IODossierImp
serviceAfficherPrescriptions()
serviceAjouterPrescription()
serviceAfficherPresTyp()
serviceafficherSignesSp()
serviceAjouterSigne()
serviceAfficher signesP()
serviceAfficherDiagnostic()
serviceAjouterDiag()
serviceAfficherDiagP()
serviceImprimerConge()
serviceConsulterCongs()
serviceSupprimerVisite()
serviceAjouterVisite()
serviceConsulterVisite()
serviceImprimerOrdonnance()
ServicelisteExamens()
serviceAjouterExam()
serviceSupprimerExamen()
serviceAjouterFiche()
serviceConsulterFiche()
serviceListeFiches()
TypePrescription
typeP: String
idP: Integer
recupererTyp()
typePrescript()
Conges
IdC : Integer
nombreJours : Integer
enregistrerCong()
chercherConges()
serviceConsulterCongs()
serviceImprimerConge()
Prescription
IdPrescription: Integer
recupererPr()
chercherPrescription()
ajouterPrescription()
serviceAfficherPrescriptions()
serviceAjouterPrescription()
serviceAfficherPresTyp()
> enregistrerPrsPatient()
afficherPrescr()
prescriptionType()
supprimerPrescription()
0..n
0..1
0..n
0..1
Diagnostic
NomD : String
IdDiag : Integer
chercherdiagnostic()
ajouterDiagnostic()
serviceAfficherDiagnostic()
serviceAjouterDiag()
serviceAfficherDiagP()
afficherDiagPatient()
enregistrerdiagPatient()
supprimerdiagnostic()
Signes
nom: String
idS: Integer
specialite: Integer
recuperSigneSp()
chercherSigne()
serviceafficherSignesSp()
serviceAjouterSigne()
serviceAfficher signesP()
enregistrerSignPatient()
supprimerSignes()
Visite
dateV: Date
codeMed: Integer
IdV: Integer
enregistrVisite()
numVisite()
chercherVisite()
serviceAjouterVisite()
serviceConsulterVisite()
serviceImprimerOrdonnance()
0..1
1
0..1
1
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
0..n
Examen
idExam: Integer
nom: String
lien: String
CopierExam()
enregistrerexam()
nombreExams()
opname()
lienExam()
ServicelisteExamens()
supprimerFichier()
supprimerexam()
serviceAjouterExam()
serviceSupprimerExamen()
Fiche
Prenom: String
Membre: String
idFiche: Integer
rechercherFiche()
enregistrerFiche()
nbreFiches()
rechercherFichNom()
serviceAjouterFiche()
serviceConsulterFiche()
serviceListeFiches()
0..n
1
0..n
1
0..n 1 0..n 1
AgentDuMinstere
ADH_MATRIC : String
Nom: String
Prenom: String
ADH_ADRESS: String
ADH_DATNA: Date
ADH_SITF : String
ADH_PREC : String
GRADE: String
DAT_REC : Date
NUM_TEL: Integer
telProf : Integer
ChercherAgentMatricule()
serviceModifierAgent()
serviceChercherPrenomDansAgent()
serviceRechercherAgent()
serviceAjouterAgent()
AgentDuMinstere()
serviceModifierAgent()
serviceSupprimerAgent()
listMaladies()
AgentDuMinstere()
serviceChercherAgentMatricule()
(fromreservation)
0..n
1
0..n
1
IODossier

Figure 20 : Classes de la catgorie Dossier Patient

57
3.3.2. Les faades et les interfaces
Les notions de faade et dinterfaces sont assez rcurrentes dans la conception des systmes
qui adoptent larchitecture SOA. En effet une faade contient les services de la catgorie et
ralise une interface afin de respecter les principes de dveloppement par interface( figures 19
20). Cette reprsentation isole le contenu de la catgorie et favorise lencapsulation de ses
ressources.
i. Faade
Une faade est une classe concrte dont les mthodes masquent limplmentation dautres
mthodes situes dans une ou plusieurs autres classes. La faade nest pas un type particulier
des langages de programmation objet. Seul un strotype UML permet de la distinguer. [8]
ii. Interface
Une interface est une classe abstraite java (interface) dont les mthodes sont toutes
implmentes par une autre classe (implements, realize). Linterface masque limplmentation
des mthodes. La programmation par interface permet de dissocier les implmentations de
leurs dfinitions sous la forme de contrat (linterface). [8]
3.3.3. Les services Web
Chaque service mtier est rang dans un paquetage associ une faade. Selon les principes
de la programmation par interface, la faade ralise une classe dInterface. La figure 21
reprsente le service Web ServiceMetierCalendrier qui regroupe toutes les oprations lies
la gestion de lensemble des sances de consultations.

58
ServiceMetierCalendrier
operationAjouterSceance()
oprationChercherSceance()
operationSupprimerSceance()
operationSupprimerSceanceMed()
operationBloqueDate()
operationVerifierPossAjSceance()
oprationDebloquerCon()
oprationSupprimerListecons()
operationCalendrier()
<<faade,web service>>
IServiceMetierCalendrier
<<Interface>>
IServiceMetierCalendrierImp
operationCalendrier()
<<faade>>
<<realize>>

Figure 21 : Service Web ServiceMetierCalendrier
3.3.4. Les processus
Chaque processus est rang dans un paquetage qui contient une classe processus dote dune
mthode pour le processus (et si ncessaire, une autre par sous processus). Cette classe ralise
une interface selon le principe de la programmation par interface. La figure 22 reprsente le
processus ReserverVisiteSpec permettant de retourner la date la plus proche pour la
rservation dun rendez-vous pour une spcialit de mdecine.
IReserverVisiteSpec
IReserverVisiteSpec()
<<Interface>>
IReserverVisiteSpecImpl
IReserverVisiteSpec()
<<realize>>

Figure 22: Les classes du processus ReserverVisiteSpec
4. Conclusion
Ce chapitre a dtaill les tapes de conception de notre SI en se basant sur les diagrammes
UML. Ainsi, nous avons pu identifier les composants de notre systme ainsi que les relations
qui existent entre ces composants. A la fin de la conception, nous allons pouvoir aborder
limplmentation en se basant sur le diagramme de classe.

Chapitre IV Ralisation et tests

Chapitre 4 : Ralisation et tests
60
1. Introduction
La ralisation et les tests sont deux tapes critiques dans le cycle de vie dun logiciel, elles
permettent de concrtiser la conception. Cest leffort observable par les utilisateurs finaux
qui permet de vrifier la fiabilit de lapplication ralise. Ce chapitre sintresse ces tapes
en dcrivant en premier lieu lenvironnement de travail ainsi que lensemble doutils et de
technologies utilises pour lachever. En deuxime lieu, les tapes de limplmentation de la
base de donnes, des services Web, des processus, du dveloppement de linterface ainsi que
les tests effectus vont tre expliques.
2. Environnement et outils de dveloppement
2.1. Langage de programmation
Notre choix de langage de programmation sest orient assez vite vers Java pour multiples
raisons [9] :
Orient objet : rutilisabilit et conomie en terme de code.
Scuris : Java a t conue pour tre exploite dans des environnements serveur et
distribus.
Dynamique : Java a t conue pour sadapter un environnement qui volue, et
permet ldition des liens entre modules objets dynamiquement au moment de
lexcution.
Portable : Il est possible d'excuter des programmes Java sur tous les environnements
qui possdent une JVM.
Complet : Java possde une trs riche bibliothque et permet entre autre la
connectivit des bases de donnes, le dveloppement d'applications multitches. .
Fiable : Java a t conu pour que les programmes qui l'utilisent soient fiables sous
diffrents aspects.
2.2. Technologies
Etant donn la nature de notre SI, et que le langage de programmation utilis est Java, nous
avons adopt le standard JSP.
61
2.2.1. JSP (Java Servlet Pages)
JSP est une technologie base sur Java qui permet aux dveloppeurs de gnrer
dynamiquement du code HTML, XML ou tout autre type de page Web. La technologie
permet au code Java et certaines actions prdfinies d'tres ajouts dans un contenu statique.
Afin damliorer la prsentation et laffichage et automatiser le dveloppement des pages JSP
nous proposons dutiliser Struts. [15]
2.2.2. Le modle Struts
Struts est un framework open-source pour dvelopper des applications Web. Son intrt
principal est d'obtenir une meilleure structuration du code. Il en dcoule donc une meilleure
flexibilit ainsi qu'une volutivit accrue. L'application de ce modle permet une sparation
en trois parties distinctes de l'interface, des traitements et des donnes de l'application. Struts
se concentre sur la vue et le contrleur. Pour la vue, Struts utilise par dfaut des JSP avec un
ensemble de plusieurs bibliothques de tags personnaliss pour faciliter leur dveloppement.
L'implmentation du modle est laisse libre aux dveloppeurs.
Pour le contrleur, Struts propose une unique servlet par application qui lit la configuration de
l'application dans un fichier au format XML. Cette servlet de type ActionServlet reoit toutes
les requtes de l'utilisateur concernant l'application. En fonction du paramtrage, elle instancie
un objet de type Action qui contient les traitements et renvoie une valeur particulire la
servlet. Celle ci permet de dterminer la JSP qui affichera le rsultat des traitements
l'utilisateur.
Les donnes issues de la requte sont encapsules dans un objet de type ActionForm. Struts
va utiliser l'introspection pour initialiser les champs de cet objet partir des valeurs fournies
dans la requte. Struts utilise un fichier de configuration au format XML (strutsconfig.xml)
pour connatre le dtail des lments qu'il va grer dans l'application et comment ils vont
interagir lors des traitements. [15]
2.3. Serveur
Les serveurs sont des logiciels qui aident dployer et contrler un grand nombre
d'applications qui sont la plupart du temps distribu [10].
2.3.1. Critres de choix
Le choix de notre serveur repose sur plusieurs critres :
62
Conteneur Web : Le serveur doit assurer le dploiement des pages Web
Moteur dexcution BPEL : Le serveur doit permettre lexcution des processus BPEL
directement ou lintgration dun moteur BPEL.
Cot : Notre choix doit se limiter des serveurs gratuits et de prfrence open source.
Scurit : Le serveur doit grer efficacement les services, tels que l'authentification et
l'autorisation.
2.3.2. Prsentation des serveurs
Parmi les serveurs dapplications gratuits et open source sur le march, nous avons compar
deux serveurs approuvs pour le dploiement de processus BPEL :
JBoss est un serveur trs lger, qui gre la scurit, open Source, certifi J2EE 1.4 et
donc implmente l'ensemble des spcifications J2EE. Grce son dveloppement
100% Java, il est compltement portable [10]. Il permet dintgrer le moteur
dexcution jbpm-BPEL qui est un moteur lger permettant lexcution de processus
BPEL simples.
Oracle : Cest un serveur dapplication gratuit et trs complet (contient les
fonctionnalits disponibles dans tous les serveurs dapplication et mme la gestion des
workflow, des processus BPEL, etc.). Les possibilits offertes par ce serveur sont trs
nombreuses et reposent uniquement sur les standards ouverts (Java, SOAP, XML,
etc.). Il permet lexcution des processus BPEL compliqus mais il est lourd par
rapport JBoss. Oracle a effectu un effort tout particulier afin de fournir les outils
ncessaires pour assurer une scurit optimale. Il fournit les services ncessaires pour
[13] :
o Lauthentification
o Lautorisation
o Le contrle daccs
o La dtection dintrusion
o La protection des donnes
2.3.3. Choix du serveur
La comparaison des deux serveurs montre quOracle Application Server 10g est plus adquat
notre application vu que :
Il est plus performant que JBoss ct scurit
63
Lexcution des processus BPEL est une des fonctionnalits offertes par dfaut et
donc le serveur permet la gestion efficace et transparente de ce processus.
2.4. Environnement de dveloppement
Le choix de lenvironnement de dveloppement a t conditionn par le choix du serveur
dapplication. En effet en choisissant oracle server 10 g , nous avons orient notre choix vers
un EDI( Environnement de Dveloppement Intgr) dvelopp par oracle pour viter les
problmes lis au dploiement. De plus nous avons cherch un EDI qui intgre ou permet
dintgrer un dessinateur (designer) BPEL. Le candidat unique rpondant ces exigences tait
JDeveloper 10g.
JDeveloper est un environnement de dveloppement intgr (Integrated Development
Environment en anglais), gratuit, dvelopp par Oracle qui permet de construire des
applications et des services Web bass sur les langages Java, SQL, et XML. Oracle
JDeveloper 10g a t conu dans le but de faciliter le dveloppement dapplication J2EE et
intgre les outils pour modeler, coder, dbugger, tester, profiler, tuner et dployer des
applications. Avec JDeveloper 10g, Oracle a compltement refondu son outil de
dveloppement en proposant une nouvelle interface graphique avec le support du Dragn
Drop et une ergonomie de type RAD (Rapid Application Development). JDeveloper 10g
utilise le JDK 5.0 et supporte le standard J2EE 1.4 pour dvelopper les applications. Il peut
grer aussi un certain nombre de nouveaux standards comme EJB 3.0 (Entreprises JavaBeans)
et JSF (JavaServer Faces). [14]
2.5. SGBD (Systme de gestion de base de donnes)
Un SGBD est un logiciel qui permet dinteragir avec une base de donnes. Il doit garantir,
dune part la description et la manipulation des donnes, et dautre part la rsolution des
problmes de concurrence et de protection daccs aux donnes. Le SGBD que nous allons
choisir doit tre :
gratuit ou open source,
conu pour la gestion des bases de donnes relationnelles,
rapide et efficace.
Lun des gestionnaires de base de donnes les plus populaires et qui rpond ses exigences
est MySQL. En effet MySQL est un serveur de bases de donnes relationnelles SQL
dvelopp dans un souci de performances leves. Il est multi-thread, multi-utilisateurs. C'est
64
un logiciel libre dvelopp sous double licence en fonction de l'utilisation qui en est faite :
dans un produit libre (open-source) ou dans un produit propritaire. [11]
2.6. Logiciel de conception
Dans le chapitre 2 nous avons choisi le formalisme de conception UML. Nous avons choisi
par la suite Rational Rose qui est un environnement complet de modlisation visuelle bas sur
le langage UML. Il prend en charge la gnration de code pour plusieurs langages (C, C++,
Java, etc.). Il permet aussi de gnrer un script SQL pour la description des bases de donnes.
2.7. Configuration matrielle
Ce projet a t ralis sur deux ordinateurs dont les caractristiques sont les suivantes :

3. Base de donnes
Aprs avoir implment le diagramme de classes correctement, la base de donnes a t
gnre automatiquement par Rational Rose. Nous avons obtenu vingt et une tables dont les
champs sont les attributs des classes qui leurs correspondent et les cls trangres ont t
identifis des autres tables. Les tapes suivre pour pouvoir gnrer le script de la base de
donnes partir du diagramme de classes sont :
Indiquer les classes persistantes (celles qui vont devenir des tables).
Indiquer pour ces classes les cls primaires.
Gnrer le schma pour chaque package et construire le modle objet qui correspond
au modle relationnel dune base de donnes. La figure 24 prsente le modle objet du
package rservation.
Gnrer de chaque schma le script SQL.
Excuter le script SQL sous MySQL Apache.
Le 1
er
ordinateur :
- Microprocesseur : Pentium4 ; 3.20 GHz
- Mmoire : 1 Go
- Disque dur : 120 Go

Le 2me ordinateur :
- Microprocesseur : Pentium(R) ; 1.7 GHz
- Mmoire : 512 Mo
- Disque dur : 80 Go

65
Enfants
Prenom: VARCHAR(255)
DatNais : SMALLINT
CodEnf : SMALLINT
ADH_MATRIC : VARCHAR(255)
<<PK>> PK_Enfants190()
<<FK>> FK_Enfants204()
<<Index>> TC_Enfants386()
Organisme
CODE: SMALLINT
LIB: VARCHAR(255)
<<PK>> PK_Organisme193()
MALAD_CH
maladie: VARCHAR(255)
codeMaladie: SMALLINT
<<PK>> PK_MALAD_CH191()
Specialite
CodSpec : SMALLINT
LibSpec : VARCHAR(255)
<<PK>> PK_Specialite196()
AgentDuMinstere
ADH_MATRIC : VARCHAR(255)
Nom: VARCHAR(255)
ADH_ADRESS: VARCHAR(255)
ADH_DATNA: SMALLINT
ADH_SITF : VARCHAR(255)
ADH_NBENF : SMALLINT
ADH_PREC: VARCHAR(255)
GRADE: VARCHAR(255)
DAT_REC : SMALLINT
NUM_TEL: SMALLINT
NUM_DOS: SMALLINT
CODE: SMALLINT
<<PK>> PK_AgentDuMinstere187()
<<Unique>> TC_AgentDuMinstere391()
<<FK>> FK_AgentDuMinstere211()
<<FK>> FK_AgentDuMinstere207()
<<Index>> TC_AgentDuMinstere397()
<<Index>> TC_AgentDuMinstere390()
1
0..*
1
0..*
1
0..*
1
0..*
maladiesAgent
NUM_DOS: SMALLINT
codeMaladie: SMALLINT
<<PK>> PK_17197()
<<FK>> FK_17205()
<<FK>> FK_17206()
<<Index>> TC_17387()
<<Index>> TC_17388()
1
0..*
1
0..*
Medecin
Nom: VARCHAR(255)
CodMed: SMALLINT
NbHeur : SMALLINT
NbePat : SMALLINT
Password: VARCHAR(255)
CodSpec : SMALLINT
<<PK>> PK_Medecin192()
<<FK>> FK_Medecin212()
<<Index>> TC_Medecin399()
1
1..*
1
1..*
DossierMedical
NUM_DOS: SMALLINT
<<PK>> PK_DossierMedical188()
0..1
1
0..1
1
1
0..*
1
0..*
EmploiConsultation
jour : VARCHAR(255)
heure: SMALLINT
NumCons : SMALLINT
DateBloque: SMALLINT
CodMed: SMALLINT
<<PK>> PK_EmploiConsultation189()
<<FK>> FK_EmploiConsultation210()
<<Index>> TC_EmploiConsultation395()
1
1..*
1
1..*
Reservation
NUM_RES: SMALLINT
DATE_RES: SMALLINT
prenom: VARCHAR(255)
NumCons : SMALLINT
NUM_DOS: SMALLINT
<<PK>> PK_Reservation195()
<<FK>> FK_Reservation209()
<<FK>> FK_Reservation208()
<<Index>> TC_Reservation392()
<<Index>> TC_Reservation393()
1
0..*
1
0..*
1
0..*
1
0..*

Figure 23 : Modle relationnel du package rservation
68
4. Implmentation des classes
Les diffrentes classes ont t gnres automatiquement depuis le diagramme de classes.
Ceci en suivant les tapes voques ci-dessous :
Nous avons slectionn les classes gnrer.
Nous avons construit un modle pour chaque package.
Nous avons gnr le code des classes depuis chaque modle.
Sous JDeveloper, nous avons implment la totalit des classes prsentes dans le
diagramme de classes et nous avons cr une classe manipulant laccs la base de
donnes.
5. Les services Web
Un service Web est un ensemble doprations, chaque opration assure un traitement
particulier. Dans cette section, nous allons dcrire les tapes de ralisation des services Web
ainsi que les tests associs.
5.1. Gnration du service Web
Il existe deux approches pour gnrer un service Web :
Lapproche top-down : permet de gnrer le service Web partir du fichier de
description WSDL.
Lapproche bottom-up : consiste gnrer le service Web partir dune classe, cette
mthode est toujours facile et rapide.
Nous avons utilis lapproche bottom-up. Ainsi, aprs avoir implment les classes
correspondantes aux diffrents services, nous avons gnr les services Web. Chaque service
contient :
Un fichier contrat WSDL qui dcrit une Interface publique d'accs un service Web.
Une interface implmente par la classe.
Un fichier de mappage qui indique les variables dentres et celles de sortie pour
chaque opration du service Web.
69
5.2. Dploiement
A la suite de ltape prcdente, les services Web sont dploys sur oracle server laide dun
fichier de dploiement mis jour par JDeveloper. Le fichier dploy est un fichier war qui a
t gnr lors du dploiement par JDeveloper.
5.3. Tests
Oracle application Server offre une interface permettant de tester les diffrents services Web
dploy sur le serveur. A partir de la page de test du service Web il est possible de choisir une
de ses oprations. Aprs avoir prpar les scnarios de tests, nous excutons lopration
plusieurs fois en changeant les valeurs des paramtres dentre chaque excution. La figure
23 prsente le rsultat dun test de lopration CalculerDateSp . Cette opration permet de
calculer la date de rservation la plus proche pour une spcialit mdicale. Le seul paramtre
dentre est la spcialit, le rsultat de cette opration est objet de type Reservation, il contient
en particulier la date de rservation et le numro de consultation.

Figure 24 : Rsultat du test de lopration CalculerDateSp

70
5.4. Gnration des classes mandataires (proxy)
Afin de communiquer avec un service Web, un client fait appel une classe proxy qui gre la
tche de mappage des paramtres aux lments XML puis d'envoi du message SOAP sur le
rseau. Ainsi, un client de service Web peut appeler les mthodes de la classe proxy qui
communiquent avec un service Web sur le rseau en traitant les messages SOAP destination
et en provenance du service. Le proxy est gnr partir de la description du service en
langage WSDL, il utilise SOAP sur HTTP pour communiquer avec le service Web.
6. Dveloppement des processus
Un processus BPEL est le rsultat dorchestration de plusieurs services (un service est une
opration dans un service Web dans notre cas).
6.1. Implmentation des processus
Tous les processus que nous avons implments sont synchrones puisque le client a besoin
dune rponse immdiate pour tous les processus. A chaque nouveau processus plusieurs
fichiers sont gnrs automatiquement, parmi lesquelles :
Le fichier schma du processus (ayant lextension xsd), il contient le mappage des
entres et des sorties du processus en des types prdfinis.
Le fichier de description WSDL du processus contient les dfinitions des services
Web.
Le fichier BPEL qui dcrit en BPEL le processus contient :
o La liste des services participants au processus.
o La liste des messages et des documents XML.
o La logique dorchestration : lensemble des activits qui arrangent le flux de
messages travers les services appels par le processus.
Il est possible de visualiser un processus sous forme dun code ou dun diagramme, mais il est
beaucoup plus facile dutiliser le mode diagramme pour diter un processus. Dans la suite
nous allons dcrire le processus ReservationMedecin. La figure 26 prsente lensemble des
activits de ce flux, llment switch 2 de cette figure correspond lenchainement d crit
dans la figure 25.
Ce processus permet de calculer la date de rservation la plus proche chez un mdecin
particulier.
Les paramtres dentres du processus sont :
71
le prnom du patient,
le numro de matricule,
le numro du mdecin,
la spcialit,
la lettre de liaison (Boolen).
Le rsultat est :
la date de rservation calcule,
le numro de consultation du mdecin correspondant la date de rservation calcule,
un entier particulier pour chaque niveau de vrification.
Dans une premire tape le processus permet de vrifier si la lettre de liaison est indispensable
pour la spcialit demande en faisant appel une opration du service Web Reservation .
Dans le cas dfavorable (lettre de liaison indispensable et patient ne possde pas de lettre de
liaison) le processus retourne lentier 2.Dans les autres cas, le processus vrifie si le patient
possde une rservation pour la mme spcialit. Si la rservation existe, le processus
sachve et retourne lentier 1.
Dans le cas contraire, le processus fait appel une opration du service Web Reservation
pour calculer la date la plus proche dune visite chez le mdecin et par la suite, il sachve et
retourne lentier 0, la date de rservation et le numro de consultation.

Figure 25 : La partie du processus rservation par Mdecin qui correspond au switch2
72

Figure 26 : Processus rservation par Mdecin
73
6.2. Dploiement des processus
A fin de pouvoir dployer un processus, deux fichiers sont gnrs automatiquement par
JDeveloper :
Le fichier build.properties permet la configuration du dploiement du processus.
Le fichier build.xml permet la compilation, le dploiement, la validation du processus,
la gnration dun rapport etc. Ce fichier sexcute avec loutil Ant (voir Annexe 1).
En lanant le dploiement, le processus est valid puis deux fichiers war et ear sont gnrs et
enregistrs sous un rpertoire du serveur. A tout processus dploy correspond un service
Web contenant une opration unique.
6.3. Tests des processus
Le test des processus est similaire au test des services Web. Il consiste crer diffrentes
instances de chaque processus en variant les valeurs dentres et observer ensuite
lenchanement du processus. Oracle Server Application nous permet de localiser lerreur
laide du flux visuel du processus (figure 28). Ainsi, nous pouvons vrifier les diffrents
chemins possibles du processus. En cas derreur le processus retourne un message et son
excution sarrte au point de lanomalie ce qui permet de connatre aisment la cause de
lerreur.
6.4. Gnration des classes mandataires
De la mme faon quun service Web, un client peut communiquer avec un processus en
faisant appel une classe proxy qui gre la tche de mappage des paramtres aux lments
XML puis d'envoi du message SOAP sur le rseau. Ce proxy contient un ensemble de
mthodes permettant au client de crer une instance du processus, de la lancer et de lui
attribuer des paramtres et de rcuprer le rsultat de son excution.
74

Figure 27: Flux visuel de lexcution du processus ReserverMedecin
7. Dveloppement des interfaces
Pour le premier module - rservation en ligne - nous avons dvelopp une application Web
qui assure toutes les fonctionnalits dgages lors de lanalyse des besoins. Pour le deuxime
module dossier mdical - nous avons implment quelques interfaces client. Comme nous
lavons dj prcis, le modle Struts est utilis pour le dveloppement surtout quil est
configur dans JDeveloper. De plus notre IDE permet de gnrer et de mettre jour
75
automatiquement lactionServlet et le fichier de configuration Struts_config.xml. Dans la
suite, nous allons prciser les principales tches ralises pendant la phase de dveloppement.
7.1. Ralisation de laction form
Cette tche correspond la ralisation dune classe contenant des attributs qui sont des
paramtres dans un formulaire (page JSP) ainsi que leurs getters et leurs setters.
7.2. Ralisation de laction
Cette tche se rsume par la ralisation d'une action qui sera dclenche une fois que le
formulaire est valid. Cette action fait appel une mthode du proxy dun service Web ou
dun processus.
7.3. Ralisation des pages JSP
La vue ou la page visible par lutilisateur est ralise pendant cette tche. Le dveloppement
des JSP permet de dcrire des pages Web (HTML) dans lesquelles on insre des portions de
code Java faisant appel aux actions.
7.4. Configuration de la validation de formulaire
La validation des paramtres saisis par l'utilisateur peut tre configure dans un fichier de
configuration de Struts de format XML en spcifiant plusieurs critres de validations comme
la taille des champs, si ils sont obligatoires ou non etc. les messages affichs lorsque la
validation choue sont saisis dans un fichier dextension properties.
8. Interface utilisateur
Dans cette partie, nous prsentons quelques imprims cran de linterface utilisateur pour
donner une ide plus prcise sur les fonctionnalits offertes.
Aprs son authentification, un patient peut effectuer un ensemble doprations savoir la
rservation dun rendez-vous, la consultation de la liste des rservations de toute la famille et
lannulation dune rservation.
Pour rserver un rendez vous (figure 29), lutilisateur doit choisir le membre de la famille qui
va consulter le mdecin, et doit spcifier sil possde une lettre de liaison ou non. Il est
possible de rserver un rendez-vous en spcifiant uniquement la spcialit ou en spcifiant la
spcialit et le mdecin.
76
Aprs la validation de la demande, le systme affiche la date et lheure du rendez-vous ainsi
que le nom du mdecin, la spcialit et le prnom du patient (figure 30).

Figure 28: Formulaire de Rservation

Figure 29: Rsultat de la rservation
Le paramdical est responsable de ladministration du systme. Linterface lui permet
deffectuer des mises jour sur le calendrier des consultations, les agents et les mdecins et
dafficher la liste des rservations par jour, par mdecin et par semaine.
La figure 31 prsente la liste des rservations pour un mdecin pour une date choisie par le
paramdical.
77

Figure 30: Les rservations dun mdecin
8.1. Test de linterface
Linterface web est le produit accessible par lutilisateur. A la diffrence des tests prcdents,
le test de linterface nest pas concentr uniquement sur le rsultat retourn mais doit aussi
sassurer de la cohrence des valeurs entres par lutilisateur. Dans cette phase de test nous
avons vrifi la bonne redirection entre les diffrentes pages de nos applications et le bon
fonctionnement des validations des formulaires.
Dans le formulaire de lajout dun agent (prsent dans la figure 32), nous avons vrifi que
les entres du formulaire ne sont transmises que si lutilisateur introduit des valeurs valides
sinon un message dalerte indiquant les paramtres invalides ou les champs manquants
saffiche.

Figure 31 : Formulaire Ajout Agent
78
9. Conclusion
Dans ce chapitre, nous avons prsent les diffrentes technologies et outils utiliss pour
raliser un SI pour le MTC. Ensuite, nous avons dtaill les tapes de limplmentation de
notre application en soumettant au fur et mesure le produit de chaque tape une srie de
tests.

Conclusion et perspectives
79
CONCLUSION ET PERSPECTIVES
Ce rapport prsente le travail ralis pendant notre projet de fin dtude effectu au sein du
MTC. Au terme de ce projet, nous avons ralis un SI pour le centre Mdico-Social du
ministre. Notre premire tche tait llaboration du cahier des charges en tudiant lexistant
et en spcifiant les besoins des diffrents utilisateurs du SI. Ensuite et aprs une tude faite
sur les nouvelles architectures applicatives, nous avons choisi dadopter larchitecture SOA.
Le service est un concept fondamental dans cette architecture et par ailleurs nous avons suivi,
lors de limplmentation, les tapes de dveloppement des services propre SOA. Enfin, nous
avons implment et test le SI. Le choix des technologies et des outils de dveloppement a
t guid par la nature du SI (Web) et les concepts de service et processus de larchitecture
SOA.
Ce travail nous a t enrichissant plus dun titre. Sur le plan formation, il nous a permis de
valider et dappliquer nos connaissances acquises pendant nos tudes en cycle dingnieur. En
particulier, il tait une occasion pour utiliser et tester une multitude doutils (serveurs, IDE,
logiciels de conception, etc.), pour consolider nos acquis relatifs aux technologies Web tel que
les services Web et le modle Struts et pour comprendre et se familiariser avec larchitecture
SOA.
Sur le plan pratique, ce travail nous a permis de mesurer les qualits attendues dun ingnieur
notamment sa capacit apprendre et entreprendre dans un court dlai.
Au cours de ce travail, nous avons rencontr plusieurs difficults ce qui nous a fait coter en
terme de temps. En effet nous avons adopt dans un premier lieu le standard de conception
BPMN. Ainsi, nous avons t amenes tester plusieurs produits (Eclarus et Ebpmn.)
permettant de modliser des processus en BPMN et de gnrer par la suite leurs descriptions
en BPEL. Cependant la plus part de ces outils ne fonctionnaient pas correctement (ne
permettent pas de gnrer la description des processus en BPEL) ou bien valident un
processus qui gnre des erreurs lorsquil est import sur lIDE.
Conclusion et perspectives
80
Comme perspectives futures de ce travail, nous estimons amliorer notre SI en implmentant
une application de payement en ligne et en ajoutant un module permettant de notifier les
patients de tout dcalage ou annulation de leurs rendez-vous par SMS.

BIBLIOGRAPHIE
[1] Antoine LONJON, Modlisation des processus mtiers et standardisation,
http://solutions.journaldunet.com, Septembre 2004.
[2] DUMAS & M.-C. FAUVET, Intergiciel et Construction d'Applications Rparties,
INRIA, Janvier 2007.
[3] K. Mani CHANDY & Jonathan LURI CARMONA & Robert ALEXANDER,
Event-Driven Architecture vs. Publish-Subscribe Systems ,
http://www.developer.com, Avril 2007
[4] Claude CHIARAMONTI, BPMN et UML : Concurrents ou complmentaires ?,
http://www.credible.asso.fr, Janvier 2006
[5] Guillaume DUFRENE, Rapport de stage : Modle de composants et architectures
orientes services, Laboratoire d'Informatique Fondamentale de Lille, 2006.
[6] C. SZYPERSKI, Component Software: Beyond Object-Oriented Programming,
Addi- son Wesley / ACM Press, New York, 2002.
[7] Jean-Louis MARECHAUX, Combining Service-Oriented Architecture and Event-
Driven Architecture using an Enterprise Service Bus, IBM, Mars 2006
[8] Pierre BONNET, Architecture SOA : Meilleures Pratiques ,
http://www.orchestranetworks.com, 2007.
[9] Bruce ECKEL, Thinking in Java, Prentice Hall PTR 3 edition, Dcembre 2002
[10] Elyse FONTEP & Phuong Anh HOANG, Les serveurs dapplication, Universit
de lyon 1, Dcembre 2006
[11] http:// www-fr.mysql.com
[12] 9id, Les avantages de la SOA , http://www.itnsa.com, Mars 2007
[13] Antoine AUG, Oracle Application Server 10g , Ecole Suprieure dinformatique
SupInfo, 2006

[14] ORACLE, Introduction to the JDeveloper IDE, http://www.oracle.com, Mai 2007
[15] Jean-Michel DOUDOUX, Dveloppons en Java , http://www.jmdoudoux.fr,
2006
[16] Ministre des Technologies de la Communication, http://www.infocom.tn
[17] Occello AUDREY, Introduction lArchitecture Oriente Service ,
http://www.polytech.unice.fr, 2006.

ANNEXES

1
Annexe 1 : Dfinitions

Ant : Cest un projet du groupe ApacheJakarta. Son but est de fournir un outil crit en Java
pour permettre la construction d'applications (compilation, excution de taches post et pr
compilation etc). Ces processus de construction sont trs importants car ils permettent
d'automatiser des oprations rptitives tout au long du cycle de vie de l'application
(dveloppement, tests, recette, mise en production, etc.).
EAI (Enterprise Application Integration) : Cest une architecture intergicielle permettant des
applications htrognes de grer leurs changes. On la place dans la catgorie des
technologies informatiques d'intgration mtier (Business Integration) et d'urbanisation. Sa
particularit est d'changer les donnes en temps rel.
BPMI (Business Process Management Initiative) : Cest une organisation non commerciale,
visant faciliter le dveloppement et lutilisation de processus business par des socits,
quelque soit leur secteur dactivit ou leur taille, au sein de leur propre rseau ou sur Internet
(ces processus pouvant par ailleurs faire interagir diffrentes applications dissmines chez
diffrents partenaires ou fournisseurs).
La mission de cet organisme est donc de promouvoir et de dvelopper lutilisation des
technologies de la gestion de processus (BPM, Business Process Management), grce
llaboration de standards pour la modlisation, le dploiement, lexcution, la maintenance et
loptimisation des processus.
OASIS (Organization for the Advancement of Structured Information Standards) : Cest le
consortium international qui conduit le dveloppement, la convergence, et l'adoption des
standards E-business. Fond en 1993, OASIS possde plus de 5000 participants qui
reprsentent plus de 600 organisations et individus dans plus de 100 pays.
Workflow : Le Workflow est la gestion lectronique des processus mtiers, totalement ou
partiellement, pendant laquelle documents, informations ou tches sont passs dun
participant un autre pour agir sur ces premiers, et ceci selon des rgles procdurales.

2
Annexe 2 : Description des cas dutilisation

Cas dutilisation Sauthentifier
Titre du cas dutilisation : Sauthentifier
But : Permet dauthentifier un utilisateur
Acteur : mdecin, agent du Ministre, paramdical.
Pr condition : Choisir le nom dutilisateur.
Post condition : Acteur authentifi
Enchanement :
6- Lacteur saisit son mot de passe et son login
7- Lacteur valide
8- Le systme vrifie les informations saisies par lacteur
9- Le systme charge linterface qui correspond lacteur authentifi
Lacteur saisi un mot de passe ou login non valide
3- Le systme affiche un message derreur
4- Lacteur entre de nouveau son login et son mot de passe
5- retour a 2
Lacteur saisi un mot de passe ou login non valide pour la N me fois
Le systme affiche un message derreur indiquant lacteur quil a dpass le nombre
limite dessai dauthentification
Nom utilisateur
Mot de passe
Mot de passe ou login incorrect

3
Cas dutilisation Rserver rendez vous
Titre du cas dutilisation : Rserver rendez-vous
But : Permet un agent de rserver une consultation chez un spcialiste ou un gnraliste du
centre
Acteur : Patient
Pr condition : Le patient sest authentifi
Post condition : rservation effectue
Enchanement :
6- Lacteur choisit deffectuer une rservation
7- Le systme charge la page de rservation
8- Lacteur choisit le prnom du patient et prcise sil dispose dune lettre de liaison ou
non
9- Le systme demande lacteur de choisir une spcialit et un mdecin
10- Lacteur entre son choix
11- Le systme vrifie les choix et affiche la date et heure prvues pour la consultation
12- Lacteur affirme sa rservation
13- Le systme termine la rservation et confirme le succs de la rservation
Lacteur ne dispose pas dune lettre de liaison
4- Le systme propose lacteur de consulter un gnraliste
Lacteur choisit de consulter un ophtalmo ou un gyncologue
6 - Le systme affiche un message prcisant que pour cette spcialit il est possible
deffectuer la consultation sans rservation
Lacteur naccepte pas la date de rservation propose par le systme
7- Lacteur naffirme pas sa rservation (rservation non effectue)
Prnom du patient, lettre de liaison (oui ou non), spcialit, mdecin, confirmation
Vous devez consulter un gnraliste

4
Cas dutilisation Consulter rservation
Titre du cas dutilisation : Consulter une rservation
But : Permet un agent de consulter les rservations quil a effectues
Acteur : Patient
Pr condition : Le patient sest authentifi, rservation effectue
Enchanement :
14- Lacteur choisit de consulter ses rservations
15- Le systme vrifie sil lacteur a effectu une rservation
16- Le systme charge la page de consultation des rservations
Lacteur na pas effectu de rservation
4- Le systme affiche un message pas de rservation effectue
Prnom
pas de rservation effectue

Cas dutilisation Annuler rservation
Titre du cas dutilisation : Annuler une rservation
But : Permet un patient dannuler une rservation effectue
Acteur : Patient
Pr condition : Le patient sest authentifi, Dossier cr, rservation effectue
Enchanement :
17- Lacteur choisit dannuler une rservation
18- Le systme demande lacteur de choisir une rservation annuler
19- Lacteur choisit la rservation quil dsire annuler
20- Le systme vrifie la possibilit dannulation
21- Le systme affiche un message de succs dannulation
Lannulation na pas pu tre effectu
4- Le systme affiche un message indiquant lchec de lannulation

5
Numro rservation

Cas dutilisation Mettre jour emploi des consultations
Titre du cas dutilisation : mettre a jour emploi des consultations
But : Permet un paramdical de mettre jour lemploi des consultations
Acteur : Paramdical
Pr condition : Le paramdical sest authentifi
Enchanement :
22- Lacteur choisit de mettre jour le calendrier
23- Le systme charge la page du calendrier
24- Lacteur effectue les modifications dsires
25- Lacteur confirme ses modifications
26- Le systme vrifie la cohrence de ses modifications
27- Le systme confirme le succs de la mise jour
Les modifications sont incohrentes
6- Le systme demande a lacteur de vrifier les modifications quil a introduit
28- Lacteur modifie les informations incohrentes
29- Lacteur valide ses modifications
30- Retour a 5
Jour de consultation, heure de consultation, dure consultation, nom et prnom mdecin,
spcialit, nombre de patients par consultation

Cas dutilisation Consulter liste de patients
Titre du cas dutilisation : Consulter liste de patients
But : Permet un mdecin spcialiste de consulter la liste des patients ayant effectu une
rservation auprs de lui une date quil choisit
Acteur : Mdecin

6
Pr condition : Le mdecin sest authentifi
Enchanement :
31- Lacteur choisit de consulter sa liste de patients rservs
32- Le systme charge la page de la liste
Le mdecin choisit de consulter la liste pour une date ou une priode bien dtermine
33- Le systme demande lacteur de vrifier les modifications quil a introduites
34- Lacteur prcise une date ou priode dsire
35- Le systme recharge la page et affiche la liste des consultations programmes
Pas de rservation effectue pour cette date ou priode
5- Le systme affiche un message pas de rservation trouves pour cette date ou
priode
Date de rservation

Cas dutilisation Rserver une visite de contrle
Titre du cas dutilisation : Rserver une visite de contrle
But : Permet un mdecin spcialiste de planifier une visite de contrle pour un patient
pendant sa consultation
Acteur : Mdecin spcialiste
Pr condition : Le mdecin sest authentifi
Enchanement :
36- Lacteur choisit de effectuer une rservation pour son patient
37- Le systme charge la page du calendrier du mdecin
38- Lacteur choisit la date et lheure de la consultation
39- Le systme vrifie les valeurs entres
40- Le systme affiche une confirmation du succs de la rservation
Date et heure de la visite, nom et prnom du patient

7
Cas dutilisation Ajouter fiche
Titre du cas dutilisation : Ajouter fiche
But : Permet dajouter une fiche pour un membre de famille
Acteur : mdecin.
Pr condition : Patient existe dans le dossier, premire visite du patient.
Post condition : consulter la fiche
Enchanement :
10- Le mdecin choisit le nom dun membre de famille
11- Le mdecin valide la cration du fichier patient
12- Le systme cre automatiquement la fiche
Identifiant du patient

Cas dutilisation Consulter fiche patient
Titre du cas dutilisation : Consulter fiche patient
But : Permet de consulter la fiche dun patient y compris les informations gnrales (prnom,
date de naissance, .)
Acteur : mdecin.
Pr condition : fiche existe.
Enchanement :
13- Le mdecin choisit la fiche dun patient
14- Le systme tlcharge les informations lies la fiche
15- La fiche saffiche comportant toutes les visites et les informations gnrales sur le
patient.
Identifiant de la fiche

8
Cas dutilisation Ajouter visite
Titre du cas dutilisation : Ajouter visite
But : Permet dajouter une visite (signes, diagnostic, traitement) lors dune consultation
Acteur : mdecin.
Pr condition : fiche du patient existe
Post condition : possibilit dimpression dune ordonnance ou dun cong
Enchanement :
16- Le mdecin choisit dajouter une visite
17- Une page contenant trois parties, une pour les signes, la seconde pour le diagnostic et
la troisime pour les traitements saffiche.
18- Le mdecin saisi les informations ncessaires (saisie assiste par une liste de choix).
19- Il valide lenregistrement de la visite
3- Le mdecin ne trouve pas une information dans la liste de choix, il la saisie et elle
sajoute automatiquement la liste de choix.
Informations saisies par le mdecin

Pfe

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Pfe

Uploaded by

Copyright:

Available Formats

Ecole nationale d'ingnieurs de Tunis

--- ,--+-'' ,-' --'

You might also like