Ma It Rise

Universit de Tunis Institut Suprieur de Gestion
Mmoire de matrise en Informatique Applique la Gestion

Conception et Ralisation dun logiciel de facturation pour une polyclinique prive

Ralis par :
Manel BOUZID Mohamed Anis BACHTOBJI
Encadr par :
Pr. Mohamed Salah GOUIDER

Anne Universitaire 2002/2003

Polyclinique Taoufik
A mes trs chers parents

Pour tout lamour dont vous mavez entour, pour tout ce que vous avez fait pour moi. Je ferai de mon mieux pour rester un sujet de fiert vos yeux avec lespoir de ne jamais vous dcevoir. Que ce modeste travail, soit lexaucement de vos veux tant formuls et de vos prires quotidiennes.
A mes trs chers surs et frre

Vous occupez une place particulire dans mon cur. Je vous ddie ce travail en vous souhaitant un avenir radieux, plein de bonheur et de succs.
A mes trs chers amis

En souvenir de nos clats de rire et des bons moments. En souvenir de tout ce quon a vcu ensemble. Jespre de tout mon cur que notre amiti durera ternellement.
Manel.
A mes trs chers parents

Je vous dois ce que je suis aujourdhui grce votre amour, votre patience et vos innombrables sacrifices. Que ce modeste travail, soit pour vous une petite compensation et reconnaissance envers ce que vous avez fait dincroyable pour moi. Que dieu, le tout puissant, vous prserve et vous procure sant et longue vie afin que je puisse mon tour vous combler.
A mes trs chers surs et frres

Aucune ddicace ne serait exprimer assez profondment ce que je ressens envers vous. Je vous dirais tout simplement, un grand merci, je vous aime.
A mes trs chers amis

En tmoignage de lamiti sincre qui nous a lie et des bons moments passs ensemble. Je vous ddie ce travail en vous souhaitant un avenir radieux et plein de bonnes promesses.
Mohamed Anis.
A notre encadreur Monsieur Mohamed Salah GOUIDER.

Nous vous remercions pour le grand honneur que vous nous avez fait en nous proposant le sujet de ce mmoire de fin dtude. Nous avons eu lhonneur et le privilge de travailler sous votre assistance et de profiter de vos qualits humaines, professionnelles et de votre grande exprience. Vous nous avez guid tout le long de ce travail dont vous avez mis cur, llaboration avec lamabilit et le dynamisme qui vous caractrisent. Puisse ce modeste travail, vous satisfaire et tmoigner de notre gratitude et connaissance pour laide et les conseils que vous nous avez prodigus, ainsi que pour le savoir que vous nous avez inculqu.
Mohamed Anis et Manel.
Avant-propos
yant atteint la quatrime anne de matrise en Informatique applique la Gestion, un projet de fin dtude nous est demand daccomplir. Notre choix sest rapport concevoir et raliser un produit logiciel.
Aprs de nombreuses recherches et demandes de stages, nous avons russi obtenir laccord des responsables de la polyclinique Taoufik grce Mr. Guider, notre professeur et encadreur. Nous nous sommes trouvs dans un groupe de huit personnes, amens raliser un logiciel de facturation, de gestion de pharmacie et de personnel : tous les besoins informatiques dune polyclinique part la comptabilit. La rpartition des tches de chaque binme sest faite par module, c--d que chaque binme doit raliser un module. Ceci dit, les modules doivent tre
intgrs au sein dun mme systme et raliss avec les mmes mthodes et outils. Nous avons plusieurs dcisions prendre en groupe surtout lorsquil sagira de mettre en place la base de donnes et de concevoir les interfaces utilisateurs. Nous avons choisi nos outils dune manire cohrente avec notre philosophie de travail. En effet, nous voulons que notre systme soit ouvert, extensible, volutif et ergonomique tout en gardant son efficacit. Lobjectif de la direction, aprs notre dpart, tant la mise en place du systme en intranet et internet.
Sommaire
Introduction gnrale ....................................................................................... 1 Prsentation de la polyclinique Taoufik .................................... ..5 Chapitre I : La phase dinception .................................................................................. ..8 I.1 - Contexte du systme : ........................................................................................................ 8 I.1.1- Circuit du dossier patient : ........................................................................................ 9 I.1.2- La facture :.............................................................................................................. 10 I.1.3 - Les conventions : .................................................................................................... 11 I.2 - Besoins fonctionnels et besoins non fonctionnels :.......................................................... 11 I.3- Cas dutilisation initiaux : ............................................................................................... 13
-I-
I.3.1- Diagramme de cas dutilisation initial: ................................................................... 14 I.3.2- Description dtaille des cas dutilisation :............................................................. 14 I.3.3- Priorit des cas dutilisation :.................................................................................. 17 I.4- Risques critiques : ............................................................................................................. 17 I.5- Les interfaces utilisateurs : .............................................................................................. 18 I.6 Analyse des cas dutilisation prioritaires : ..................................................................... 20 I.6.1- Analyse du cas dutilisation Crer un dossier patient : ...................................... 20 I.6.2- Analyse du cas dutilisation Crer un patient :.................................................. 23 I.6.3- Analyse du cas dutilisation Rechercher un patient :......................................... 25 Conclusion : ............................................................................................................................. 27 Chapitre II : La phase delaboration ........................................................................... ..28 II.1 Capture des besoins :..................................................................................................... 29 II.1.1- Modle final de cas dutilisation : ......................................................................... 29 II.1.2- Description des cas dutilisation :.......................................................................... 31 II.2 Analyse : ....................................................................................................................... 32 II.2.1- Analyse des cas dutilisation secondaires :............................................................. 32 II.2.1.1- Analyse du cas dutilisation Modifier un patient : .............................. 32 II.2.1.2- Analyse du cas dutilisation Supprimer un patient :............................ 34 II.2.1.3- Analyse du cas dutilisation Modifier un dossier patient : .................. 36 II.2.1.4- Analyse du cas dutilisation Annuler un dossier patient : ................... 38 II.2.1.5- Analyse du cas dutilisation Rechercher un dossier patient : ............... 40 II.2.1.6- Analyse du cas dutilisation Passer une prestation une facture patient :.................................................................................................................. 43 II.2.1.7- Analyse du cas dutilisation passer un produit une facture patient :.................................................................................................................. 45 II.2.1.8- Analyse du cas dutilisation Editer facture patient :......................... 48 II.2.2- Analyse des nouveaux cas dutilisation identifis : ............................................... 50
-II-
II.2.2.1- Analyse du cas dutilisation Sidentifier : ............................................ 50 II.2.2.2- Analyse du cas dutilisation Paramtrer mdecins : ............................. 52 II.2.2.3 Analyse du cas dutilisation Paramtrer chambres : .............................. 54 II.2.2.4- Analyse du cas dutilisation Paramtrer cuisine : ................................ 56 II.2.2.5- Analyse du cas dutilisation Paramtrer prestations :.......................... 58 II.2.2.6- Analyse du cas dutilisation Paramtrer conventions : ........................ 60 II.2.2.7- Analyse du cas dutilisation Paramtrer fluides et appareillage : ........ 62 II.2.2.8- Analyse du cas dutilisation Paramtrer tarifs accompagnant :........... 63 II.2.2.9- Analyse du cas dutilisation Enregistrer rglement :............................ 65 II.2.2.10- Analyse du cas dutilisation Passer un produit alimentaire une facture patient :.................................................................................................................. 67 II.2.2.11- Analyse du cas dutilisation Enregistrer accompagnant : .................. 69 II.2.2.12- Analyse du cas dutilisation Passer un fluide ou appareillage une facture patient : ..................................................................................................... 71 II.3 Conception : .................................................................................................................. 73 II.3.1-Conception des cas dutilisation prioritaires :......................................................... 73 II.3.1.1- Conception du cas dutilisation Crer un dossier patient : ................... 73 II.3.1.2- Conception du cas dutilisation Crer un patient : ............................... 76 II.3.1.3- Conception du cas dutilisation Rechercher un patient : ...................... 76 II.3.2-Conception des cas dutilisation secondaires : ........................................................ 83 II.3.2.1- Conception du cas dutilisation Modifier un patient : ......................... 83 II.3.2.2- Conception du cas dutilisation Supprimer un patient :....................... 85 II.3.2.3- Conception du cas dutilisation Modifier un dossier patient : ........... 87 II.3.2.4- Conception du cas dutilisation Annuler un dossier patient : ........... 89 II.3.2.5- Conception du cas dutilisation Rechercher un dossier patient : .......... 91 II.3.2.6- Conception du cas dutilisation Passer une prestation une facture patient :.................................................................................................................. 94
-III-
II.3.2.7- Conception du cas dutilisation Passer un produit une facture patient : .................................................................................................................................. 96 II.3.2.8- Conception du cas dutilisation Editer facture patient :...................... 99 II.4 Implmentation: ......................................................................................................... 102 II.4.1-Construction dun schma initial de la base de donnes : .....................................102 II.4.1.1- Description et diagrammes des classes entits prioritaires:......................102 II.4.1.2- Rgles de passage dun diagramme de classes une base de donnes relationnelle: ...........................................................................................................104 II.4.1.3- Schma initial de la base de donnes :......................................................104 II.4.2-Implmentation des cas dutilisation prioritaires : ...............................................106 II.5 Test : ...........................................................................................................................109 II.5.1-Test du cas dutilisation Crer patient : ..........................................................109 II.5.2-Test du cas dutilisation Rechercher patient : .................................................110 II.5.3-Test du cas dutilisation Crer dossier : ...........................................................110 Conclusion : ...........................................................................................................................110 Chapitre III : La phase de construction.......................................................................111 III.1 Conception des nouveaux cas dutilisation : .............................................................137 III.1.1- Conception de cas dutilisation Sidentifier :................................................112 III.1.2- Conception de cas dutilisation Paramtrer mdecins :.................................114 III.1.3- Conception de cas dutilisation Paramtrer chambres : ................................116 III.1.4- Conception de cas dutilisation Paramtrer cuisine : ....................................118 III.1.5- Conception de cas dutilisation Paramtrer prestations : .............................120 III.1.6- Conception de cas dutilisation Paramtrer conventions :............................122 III.1.7- Conception de cas dutilisation Paramtrer fluides et appareillage :...........124 III.1.8- Conception de cas dutilisation Paramtrer tarifs accompagnant : ..............126 III.1.9- Conception de cas dutilisation Enregistrer rglement : ...............................128
-IV-
III.1.10- Conception de cas dutilisation Passer un produit alimentaire une facture patient :.........................................................................................................................130 III.1.11- Conception de cas dutilisation Enregistrer accompagnant :......................133 III.1.12- Conception de cas dutilisation Passer un fluide ou un appareillage une facture patient : ............................................................................................................ 135 III.2 Implmentation :....................................................................................................... 137 III.2.1- Construction du schma final de la base de donnes :........................................137 III.2.1.1-Description et diagramme des classes entits importantes : ....................137 III.2.1.2-Schma final de la base de donnes : .......................................................144 III.2.2- Architecture matrielle mise en place : ...............................................................150 III.2.3- Implmentation des cas dutilisation secondaires et nouveaux: ........................152 III.3 Test :..........................................................................................................................154 III.3.1-Test du cas dutilisation Modifier un patient : .............................................154 III.3.2-Test du cas dutilisation Supprimer un patient : ...........................................155 III.3.3-Test du cas dutilisation Editer facture patient : ..........................................155 III.3.4-Test du cas dutilisation Sidentifier : ...........................................................155 III.3.5-Test des cas dutilisation de paramtrage : .........................................................155 III.3.6-Test des cas dutilisation de passations des biens et des services : ......................156 III.3.7-Test du cas dutilisation Enregistrer accompagnant : ...................................156 Conclusion : ...........................................................................................................................157 Chapitre IV : La phase de transition ..........................................................................158 Conclusion gnrale .......................................................................................160 Annexe (A) : Le processus unifi et UML ...................................................................163 I - Unified Modeling Language :..........................................................................................164 I.1 Lapproche Oriente Objet :....................................................................................164 I.2 La notation UML :................................................................................................168
-V-
II Le processus unifi :.......................................................................................................171 Annexe (B) : Rational Rose, Java et Oracle.................................................................175 I Rational Rose 98i :..........................................................................................................174 II Oracle JDeveloper :........................................................................................................175 III Oracle 9i :.....................................................................................................................180 Annexe (C) : Les interfaces utilisateurs.......................................................................184 Glossaire .....................................................................................................................193
-VI-
Introduction Gnrale
ette introduction fera lobjet dune brve prsentation de lapplication que nous allons concevoir et raliser, des outils et des mthodes choisis, suivi du plan gnral du processus de dveloppement.
Notre tche consiste raliser le module de facturation, intgr dans la totalit du systme de gestion de la polyclinique. Bien que lapplication semble un peu classique, nous ferons face plusieurs difficults surtout que les outils dimplmentation utiliss ne sont pas faciles manipuler. Limplmentation nest pas la seule difficult surmonter, il faut savoir que la facturation au sein dune polyclinique est beaucoup plus complexe et diffrente que celle dans une entreprise commerciale ou industrielle. En effet, dans ces
Projet de fin dtude
Introduction Gnrale
types dentreprises, il sagit toujours de passer un produit dans une facture client. Informatiquement parlant, on ne fait pas la distinction entre deux produits ou services dune mme entreprise, en loccurrence entre un cran, une imprimante et un graveur sil sagit dune entreprise de vente de matriel informatique, ou entre un carburateur, un amortisseur et des patins de freins, sil sagit dune entreprise de vente de pices auto. Dans un systme de gestion dune polyclinique, il faut distinguer entre produits : prestations, mdicaments, usages uniques car ils nont pas du tout les mmes caractristiques (attributs). En plus de cette ambigut, il faut grer les conventions tablies avec diffrentes organisations. Ces conventions agissent directement sur la facturation et le rglement. En fait, les deux clauses les plus importantes dune convention portent sur la remise et la prise en charge. La remise agira sur la facturation puisque elle affectera les montants payer, le taux de prise en charge touchera le dispatching du rglement, entre patient (employ) et organisation (employeur). Ceci dit, ce stade du processus de conception, tout nous semble difficile et dur raliser. Cest pour cela que notre choix sest port sur le
Processus
Unifi.
En effet, le processus unifi est une solution de dveloppement logiciel adapt tous types de projets. Ses traits distinctifs tiennent en trois notions : pilot par les cas dutilisation, centr sur larchitecture et itratif et incrmental (voir Annexe (A)). Le processus unifi rpte un certain nombre de fois, une srie de cycles constituant la construction dune gnration du systme. Tout cycle se termine par la livraison dune version du produit aux clients et se droule suivant quatre phases : lincubation, llaboration, la construction et la transition. Chacune de ces phases peut se drouler en une ou plusieurs itrations. Il faut noter que loutil
Rational Rose 98i nous aidera normment dessiner et
grer les diffrents diagrammes UML.
Projet de fin dtude
Introduction Gnrale
En ce qui concerne limplmentation, nous utiliserons
JDeveloper,
un outil
puissant, complet et intgr avec Oracle, notre systme de gestion de bases de donnes. JDeveloper nest pas le seul outil dimplmentation intgr avec Oracle, mais nous avons choisi de dvelopper avec Java cause de ses points forts : Portabilit. Appropriation au WEB. Interfaces graphiques avances (avec les bibliothques graphiques Swing, AWT) etc. Quant au systme de gestion de base de donnes, nous avons eu recours
Oracle9i, la solution convenable un systme si riche dinformations vu le trs

grand nombre de patients qui consultent quotidiennement la polyclinique, et aussi du personnel qui y travaille (prs de 400 employs). A part sa gestion impeccable dune norme quantit denregistrements, Oracle9i offre plusieurs services et outils qui sont plus dtaills dans lannexe (B). Ayant prsent les outils et les mthodes adopts, nous allons exposer maintenant le plan de conception. Notre uvre se subdivisera en quatre principaux chapitres. Dans le premier chapitre intitul
Inception ,
nous commencerons par
comprendre le contexte du systme, dterminer les principaux cas dutilisation, numrer les besoins fonctionnels et les besoins non fonctionnels, et dgager les risques critiques, pouvant nuire au bon droulement du projet. Puis, au sein de
Llaboration ,
deuxime chapitre de ce travail, nous
tenterons dapprofondir la comprhension du systme par un processus continu de collecte dinformations auprs des experts du domaine et darriver, la fin de la phase, obtenir une spcification, une analyse et une conception dtailles des cas dutilisation. Nous avons jug que cette phase est la plus importante car nous devons passer dune architecture candidate, construite lors de la phase dincubation, une architecture stable.
Projet de fin dtude
Introduction Gnrale
Au niveau du troisime chapitre :
La construction , larchitecture tant stable,
le produit sapparente alors lapplication, satisfaisant les exigences des utilisateurs. Finalement, dans le dernier chapitre de ce mmoire :
la transition ,
nous
prsenterons comment le produit est mis en place et dploy chez la polyclinique.
Prsentation de la polyclinique Taoufik
<< La vie humaine mrite quon lui accorde plus de prix >>.
HABIB BOURGUIBA
(SFAX, le 4 juin 1961)
e projet de construction dune clinique polyvalente Tunis a t soumis au Conseil dAdministration de la socit Taoufik au mois de Janvier 1974. La concrtisation de lide eut lieu aprs six ans. Les
trois objectifs, lpoque taient de :
Projet de fin dtude
Prsentation de la polyclinique
1- Participer, par lmulation et la ralisation, lamlioration des techniques, mthodes et services hospitaliers et cliniques dans le pays. 2- Offrir aux mdecins hospitalo-universitaires, dans le respect de la rglementation en vigueur, un instrument et une ambiance de travail en quipe, comparables aux meilleurs standards internationaux. 3- Rpondre aux nouveaux besoins de la sant ns du dveloppement touristique que connat la Tunisie. Actuellement, la polyclinique Taoufik comporte sept niveaux : Sous-Sol : principales installations domestiques, services gnraux, chaufferie, unit de physiothrapie, unit de Radio-isotope. Rez-de-chausse : principales units cliniques, moyens opratoires, salles de consultations, services de diagnostics, service de rception. Les services administratifs regroupent les bureaux affects aux personnes suivantes : ladministrateur, le directeur administratif et financier, le caissier, lconome, trois employs de bureau. Premier tage : Maternit. Deuxime tage : psychiatre. Troisime tage : Chirurgie gnrale, Hpital du jour, ranimation. Quatrime tage : Cardiologie. Cinquime tage : appartements de fonction et bureaux.
Dans ce qui suit, nous prsentons une description brve des diffrents services et laboratoires de cette institution.
Urgences :
En principe, les cas considrs comme urgences sont les suivants : Les maternits anticipes. Les accidents du travail. Les accidents de la route. Les malades coronaires.
Unit de radiologie :
Cette unit comporte : Un bureau.
Projet de fin dtude
Prsentation de la polyclinique
Une salle dattente pour les clients externes. Une salle dattente pour les malades internes. Une salle de radiologie gnrale. Une salle de radiologie spcialise, radiographie incluse. Un cabinet de dveloppement des radios.
Les malades internes et les malades externes sont admis sparment.
Laboratoire dHmatologie :
Rserve rfrigre de sang. Emplacement dattente des donneurs de sang. Un bureau pour le technicien. Deux salles avec lits de repos.
Laboratoire de Biochimie : Laboratoire de Bactriologie : Salles de consultations : Bloc opratoire :

Cette socit embauche aux environs de 400 personnes rparties entre rceptionnistes, mdecins, administrateurs, cuisiniers, secrtaires dtage, anesthsistes, concierges, techniciens, infirmiers, femmes de mnage etc.
Chapitre
(I)
La phase dinception
a phase dinception consiste comprendre le contexte du systme. Il sagit de dterminer les fonctionnalits et les acteurs les plus pertinents, de prciser les risques les plus critiques et didentifier les
cas dutilisation initiaux. Ceci dit, notre description va sembler trop dtaille pour une premire phase du processus, mais il faut signaler quun systme prexiste, contenant les principales fonctionnalits.
I.1 - Contexte du systme :

Pour concevoir et raliser le systme de facturation chez une polyclinique, il nous tait indispensable de collecter les informations ncessaires auprs des spcialistes du domaine.
Projet de fin dtude
La phase dinception
Aprs avoir structur les informations collectes, nous avons remarqu que presque tout, se droule autour du dossier patient. Ainsi nous allons prsenter le parcours du dossier depuis ladmission jusqu la sortie du patient, les composants dune facture et les clauses dune convention
I.1.1- Circuit du dossier patient :

1- Admission :
Le patient se prsente la rception de la polyclinique, et donne la lettre dhospitalisation la rceptionniste. Cette dernire vrifie le document, saisit une masse dinformations concernant le patient et lui affecte un numro de chambre et un mdecin : cette opration sintitule Cration dun dossier patient .
2-Passation des prestations1 :

En sinstallant dans ltage appropri, le patient commence consommer diverses prestations. Chaque consommation est accompagne par une passation, la facture du patient. Il faut noter que ces prestations ne sont pas toutes passes un mme tage, chaque prestation est passe au service o elle sest faite (analyse, opration chirurgicale, imagerie). On doit alors en conclure, que chaque secrtaire dtage doit tre capable de saisir la prestation convenable, la facture du patient appropri.
3-Edition de la facture :
Lorsque le patient est prt quitter la polyclinique, il se prsente la caisse avec un bon de sortie sign par son mdecin. Notre caissier (ou facturier) doit son tour tamponner le bon (il signe que le rglement va tre effectu), puis saisit le numro de dossier de ce patient, et lance
Cest un service ou un bien offert par la polyclinique, une prestation peut tre une analyse, une imagerie, une intervention chirurgicale, une exploration fonctionnelle, un repas.
Projet de fin dtude
La phase dinception
10
ldition de sa facture. Le montant de la facture est compos des montants des types de prestations consommes ainsi que du montant de sjour.
4-Rglement :
Un patient peut tre pris en charge ou ne pas ltre. Il peut tre pris en charge 100%, et payer uniquement les extras, une facture est gnre automatiquement lorganisation qui le prend en charge. Il peut tre galement pris en charge un pourcentage infrieur 100%. Dans ce cas, un dispatching aura lieu pour une facture patient et une facture organisation. Il faut noter que des remises sont possibles. Ces remises font les termes de conventions entre la polyclinique et plusieurs organisations.
I.1.2- La facture :
Une facture est une note dtaille des marchandises vendues, des services excuts Bibliorom Larousse.
Cette dfinition ne nous met pas tout de suite dans le contexte, mais ds que nous remplaons les mots marchandises et services , par respectivement, mdicaments et usages uniques et prestations , la dfinition sclaircit. En effet, la facture est compose des lignes suivantes : Sjour : cest le prix unitaire dune nuite, multipli par le nombre de jours que le patient a pass dans la clinique. On ajoute ceci, le montant dun ventuel accompagnement. Bloc opratoire. Analyse. Imagerie. Ranimation. ECG : Electrocardiogramme. Pharmacie : lensemble des mdicaments et usages uniques que le patient a consomms.
Projet de fin dtude
La phase dinception
11
Fluide et appareillage : reprsente les fluides 1 consomms et les appareils utiliss par notre patient.
I.1.3 - Les conventions :

Une convention est une sorte de contrat, tabli entre la polyclinique et une organisation. Une organisation peut tre une entreprise ou mme une ambassade. Voici les principaux clauses (ou articles) dune convention : Admission du patient : prsente dans les cette clause, le responsable dun de recouvrement conditions dadmission patient
(Documents et papiers ncessaires) ainsi que ses droits. Prise en charge : cette clause cite que les dtails de la PEC2 doivent tre indiqus dans la lettre de PEC que le patient doit prsenter. Ce document doit indiquer la nature des soins avec le taux de participation du patient aux frais, except les extras, les taxes et les droits de timbres. Frais dhospitalisation : cette clause prcise ce que comporte le prix dune prestation. Par exemple, le prix dune journe comprend le logement, lclairage, la climatisation, la tlvision, le blanchissage du linge, la pension (trois repas et un goter) et le service infirmier. Rglement : cette clause rappelle que le patient et lorganisation doivent respecter les taux de PEC, que le patient doit payer avant de quitter la polyclinique et que lorganisation doit rgler sa facture dans un dlai dtermin.
I.2 - Besoins fonctionnels et besoins non fonctionnels :

Le systme dont la polyclinique veut se doter, doit tre oprationnel, volutif, convivial et offrant les informations ncessaires temps rel.
Se dit dun corps (liquide ou gaz) dont les molcules sont faiblement lies, et qui peut ainsi prendre la forme du vase qui le contient, Exemple : O2. Dans la polyclinique, on facture les fluides par jour ou par heure. 2 PEC : Prise en charge.
Projet de fin dtude
La phase dinception
12
Pour ceci, le systme raliser doit satisfaire les exigences de la totalit des utilisateurs. Nous prsentons dans ce qui suit tous les besoins fonctionnels classs par acteur ainsi que les besoins non fonctionnels communs tous ces acteurs.
Besoins fonctionnels :
Un acteur est une personne, un matriel ou un logiciel qui interagit avec le systme dans le but de raliser une plus value. Les acteurs en interaction avec notre systme sont : Le Responsable admission (rceptionniste). La Secrtaire dtage. Le Facturier (caissier).
Le responsable admission (Rceptionniste):

Cration dun dossier patient. Modification dun dossier patient. Annulation dun dossier patient. Cration dun patient. Modification des informations propres un patient. Annulation dun patient.
La secrtaire dtage :
Passer une prestation (analyse, radio, mdicament, acte opratoire) une facture patient. Passer un produit (mdicament ou usage unique) une facture patient.
Le facturier :
Calcul automatique du nombre de jours du sjour du patient. Gnration de la facture patient - clinique. Gnration de la facture patient - mdecin. Editer la facture patient - clinique.
Projet de fin dtude
La phase dinception
13
Editer la facture patient - mdecin.
Besoins non fonctionnels :

A part les besoins fondamentaux, notre futur systme doit rpondre aux critres suivants :
la rapidit de traitement : En effet, vu le nombre important des

transactions quotidiennes, il est imprativement ncessaire que la dure dexcution des traitements sapproche le plus possible du temps rel.
La performance : Un logiciel doit tre avant tout performant c'est-dire travers ses fonctionnalits, rpond toutes les exigences des usagers dune manire optimale.
la convivialit : Le futur logiciel doit tre facile utiliser. En effet,

les interfaces utilisateurs doivent tre conviviales c'est--dire simples, ergonomiques et adaptes lutilisateur.
I.3- Cas dutilisation initiaux :

Les cas dutilisation initiaux traduisent les besoins capturs jusqu ce stade du processus. Comme nous avions indiqu auparavant, il est tout fait normal dans notre cas, que le nombre de cas dutilisations initiaux soit lev car le systme dinformation nest pas compliqu, et quen plus ce systme est dj informatis. Il nous a suffi alors, de dcouvrir le systme actuel, la compagnie dun agent de saisie pour dgager les fonctionnalits du systme futur.
Projet de fin dtude
La phase dinception
14
I.3.1- Diagramme de cas dutilisation initial:

<<extend>>
Crer un dossier patient <<extend>>
Crer un patient
Editer facture patient
Caissier
Rechercher un patient
<<include>>
<<include>>
Modifier un patient
Passer une prestation une facture patient Secrtaire d'tage
Rceptionniste
Supprimer un patient
Passer un produit une facture patient
Rechercher un dossier patient <<include>>
Modifier un dossier patient
<<include>>
Annuler un dossier patient
FigI.1 : Diagramme de cas dutilisations initial.
I.3.2- Description dtaille des cas dutilisation :
RECEPTIONNISTE :
Crer un dossier patient :
Projet de fin dtude
La phase dinception
15
Cette opration est ralise chaque fois quun nouveau patient se prsente (avec les documents ncessaires) la rception pour tre hospitalis. Lagent saisit un ensemble dinformations concernant le patient (par exemple le nom, le prnom, lge, ladresse, la nationalit etc.). Il faut noter quune fois le dossier patient cr, une facture est gnre automatiquement avec des rubriques (sjour, analyse, imagerie etc.) nulles (cest tout fait normal, car le patient na rien consomm pour linstant). Dornavant, le montant dune prestation, mdicament, fluide... pass, sera ajout automatiquement dans la rubrique convenable de la facture patient. Lintrt est le fait que : Lutilisateur peut consulter dune manire rapide la facture lheure actuelle, sans lancer une opration de calcul et de jointure coteuse. Le temps de rponse dune dition dune facture sera rapide.
Modifier un dossier patient :

Un dossier doit tre modifiable, un utilisateur peut se tromper en communiquant les informations qui le concernent, la rcupration de lerreur est envisage.
Annuler un dossier patient :

Nous devons toujours offrir lutilisateur la possibilit de la correction voire mme de lannulation. La rceptionniste a des contacts avec plusieurs types de patients, le cas le plus simple, cest quun patient se prsente pour tre hospitalis, un dossier qui lui correspond est cr, mais aprs quelques minutes il dcide de sen ailler sans se soigner.
Rechercher un dossier patient :

Toute opration de mise jour (modification ou annulation) dun dossier patient doit tre prcde par une opration de recherche de ce dossier. Le critre de recherche demand est le numro de dossier.
Crer un patient :
Projet de fin dtude
La phase dinception
16
Lorsquun patient se prsente la clinique pour tre hospitalis, la rceptionniste doit vrifier tout dabord sil vient pour la premire fois ou non. Dans le cas positif, elle doit crer un nouveau patient puis un nouveau dossier. Ceci dit, un patient peut avoir plusieurs dossiers patient et chaque sortie du patient saccompagne dun archivage de son dossier.
Modifier un patient :
Notre futur systme doit garantir la possibilit de modifier les informations relatives un patient quelconque.
Supprimer un patient :
Un patient peut se prsenter la rception avec les pices ncessaires pour son hospitalisation, mais annule sa demande au dernier moment. Dans ce cas, le patient doit tre supprim de la base de donnes car rellement, il na jamais consomm de prestations dans la polyclinique, il ne doit pas figurer dans notre systme.
Rechercher un patient :
Il sagit dune opration fondamentale au sein de notre futur systme. En effet, la rceptionniste pourra rechercher un patient quelconque nimporte quel moment aussi bien pour effectuer une mise jour que pour lui crer un nouveau dossier.
SECRETAIRE DETAGE :
Passer une prestation une facture patient :
La secrtaire dtage enregistre les bons de prestations que les infirmiers lui transmettent, pour la facture du patient concern. Cest lopration la plus frquente dans notre futur systme.
Passer un produit une facture patient :

En fait, la secrtaire des dtage est responsable ou galement usage de lenregistrement produits (mdicament unique)
consomms par le patient sils existent dans le petit stock de ltage.
Projet de fin dtude
La phase dinception
17
CAISSIER :
Editer la facture patient :
Lorsque le patient est prt sortir de la clinique, la facture qui lui correspond doit tre dite par un simple clic du caissier (facturier).
I.3.3- Priorit des cas dutilisation :

Afin de faciliter notre travail, il nous semble judicieux de rpartir les cas dutilisation initiaux en des cas prioritaires et autres secondaires. En fait, nous considrons les cas dutilisation Crer un dossier patient , Crer un patient , Rechercher un patient prioritaires, les autres cas dutilisation sont secondaires. Nous avons adopt ce choix dans le but de minimiser au maximum le risque de la non matrise du langage du programmation et afin dtre conforme en plus, la chronologie du circuit du dossier patient cit auparavant. En effet, ces cas dutilisation sont assez simples concevoir et implmenter, ce qui nous aidera dcouvrir le langage de programmation petit petit.
I.4- Risques critiques :

Avant de se lancer dans la conception, il faut dterminer les principaux risques, mettant en danger la ralisation du projet, afin de les attnuer le maximum possible. La dtermination de ces risques est trs importante, par exemple elle peut influencer la dfinition de lordre de priorit des cas dutilisation. En effet, si le langage de programmation prsente un risque, nous aurons intrt commencer par le cas dutilisation le plus simple. Nous faisons face deux types de risques :
Risques non techniques :

o Dlai de livraison : En effet, nous sommes contraris par le dlai de dpt du mmoire, fix trois mois du dbut de stage, et par lampleur de notre projet. o Difficult de lextraction des informations :
Projet de fin dtude
La phase dinception
18
En effet les employs de la polyclinique nacceptent pas souvent de nous livrer des informations. Lextraction de la bonne information nous semble une tche assez dlicate.
Risques techniques :
o La
non
matrise
du
langage
de
programmation :
Limplmentation avec un langage que nous ne matrisons pas, est un risque technique critique, surtout que le dlai de livraison est relativement court. o Lambigut du processus unifi : En effet, le point fort du processus unifi rside dans son ambigut car sil est adaptable divers types de projets, cest parce que sa dmarche est gnrique. Pour cela, nous sommes amens bien adapter le processus notre projet.
I.5- Les interfaces utilisateurs :

Dans le but dinciter lutilisateur nous fournir une information efficace, nous adoptons la dmarche du prototypage. Le prototypage motivent les employs nous livrer des informations. Dans ce qui suit, nous prsentons quelques prototypes des interfaces usagers ralises au cours de cette phase, mais il faut noter que les interfaces prototypes peuvent ne rien avoir avec les interfaces du futur systme. Daillers, elles sont construites avec un autre langage de programmation.
Projet de fin dtude
La phase dinception
19
FigI.2 : Prototype de linterface didentification
FigI.3 : Prototype de linterface dossier patient
Projet de fin dtude
La phase dinception
20
I.6 Analyse des cas dutilisation prioritaires :

I.6.1- Analyse du cas dutilisation Crer un dossier patient :
I.6.1.1- Traabilit entre le modle de cas dutilisation et le modle danalyse pour le cas dutilisation Crer un dossier patient :
Modle de cas d'utilisation trace

Rceptonniste Crer un dossier
Modle danalyse
Crer un dossier
Dossier
Facture
C_dossier
Interface dossier
FigI.4 : Traabilit entre le modle de cas dutilisation et le modle danalyse pour le cas dutilisation Crer un dossier patient .
I.6.1.2- : Diagramme de classes du modle danalyse pour le cas dutilisation Crer un dossier patient :
Projet de fin dtude
La phase dinception
21
Rceptonniste
Interface dossier
Dossier
C_dossier
Facture
FigI.5 : Diagramme de classes du modle danalyse pour le cas dutilisation Crer un dossier patient .
I.6.1.3- : Diagramme de collaboration du modle danalyse pour le cas dutilisation Crer un dossier patient :
Projet de fin dtude
La phase dinception
22
1: afficher_ interface _dossier
2: interface_ dossier_ affiche
: Rceptonniste
3: clique_ bouton_Crer
4: formulaire_ vierge_ affich
: Interface dossier
5: saisir_ informations()
10: message_ visualis 6: cration ()
9: afficher _message_rsultat ()
7: crer_ dossier ()
: Dossier
8: crer_ facture ()
: C_dossier
: Facture
FigI.6 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Crer un dossier patient .
Le cas dutilisation crer un dossier patient se droule comme suit : La rceptionniste demande la visualisation de son interface dossier (1), cette interface donnera cet agent la possibilit de choisir entre ces trois oprations : cration , modification ou annulation (2). Dans notre cas, la rceptionniste clique sur le bouton Crer (3). Ce clic entranera laffichage dun formulaire de saisie (4) et lui permettra de saisir la masse dinformations ncessaires pour crer un nouveau dossier patient (5). La cration de ce dossier (7) est accompagne dune cration de la facture patient correspondante (8). Jusque l, cette facture est vierge, et sa cration est compltement transparente la rceptionniste.
Projet de fin dtude
La phase dinception
23
Cet agent est inform du succs ou non de cette opration travers un message affich sur son terminal (10).
I.6.2- Analyse du cas dutilisation Crer un patient :

I.6.2.1- Traabilit entre le modle de cas dutilisation et le modle danalyse pour le cas dutilisation Crer un patient :
Modle de cas d'utilisation
Modle danalyse trace
Rceptonniste
Crer un patient
Crer un patient
Patient
C_patient
Interface patient
FigI.7 : Traabilit entre le modle de cas dutilisation et le modle danalyse pour le cas dutilisation Crer un patient .
I.6.2.2- : Diagramme de classes du modle danalyse pour le cas dutilisation Crer un patient :
Rceptonniste
Interface patient
Patient
C_patient
FigI.8 : Diagramme de classes du modle danalyse pour le cas dutilisation Crer un patient .
Projet de fin dtude
La phase dinception
24
I.6.2.3- : Diagramme de collaboration du modle danalyse pour le cas dutilisation Crer un patient :
1: afficher_ interface_ patient ()
2: interface_ affiche
: Rceptonniste
3: clique__bouton_Crer
4: formulaire_ patient _vierge_ affich Interface patient : 9: message_ visualis 6: cration ()
5: saisir_ informations()
8: afficher message_rsultat () 7: ajouter_patient()
: Patient
: C_patient
FigI.9 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Crer un patient .
Lorsque le patient se prsente avec une autorisation dhospitalisation sign par son mdecin, la rceptionniste lui demande tout dabord sil vient pour la premire fois ou non. Sil sagit dun nouveau patient, elle ajoute ce nouveau patient puis cre son dossier. Sinon, elle le cherche dans la base de donnes, et lui cre un nouveau dossier. Afin de pouvoir crer un nouveau patient, la rceptionniste choisit lopration crer dans son interface patient (2). Elle procde ensuite la saisie des informations relatives ce nouveau patient (5). Un message visualis sur son terminal lui informe de la russite ou non de lopration (9).
Projet de fin dtude
La phase dinception
25
I.6.3- Analyse du cas dutilisation Rechercher un patient :

I.6.3.1- Traabilit entre le modle de cas dutilisation et le modle danalyse pour le cas dutilisation Rechercher un patient : Modle de cas d'utilisation Modle danalyse trace
Rceptonniste Rechercher un patient Rechercher un patient
Patient
C_patient
Interface patient
FigI.10 : Traabilit entre le modle de cas dutilisation et le modle danalyse pour le cas dutilisation Rechercher un patient .
I.6.3.2- : Diagramme de classes du modle danalyse pour le cas dutilisation Rechercher un patient :
Rceptonniste
Interface patient
Patient
C_patient
FigI.11 : Diagramme de classes du modle danalyse pour le cas dutilisation Rechercher un patient .
Projet de fin dtude
La phase dinception
26
I.6.3.3- : Diagramme de collaboration du modle danalyse pour le cas dutilisation Rechercher un patient : - Scnario 1 : Recherche fructueuse.
2: interface _affiche
: Rceptonniste
3: clique_bouton_Rechercher 5: saisir _critre _de_ recherche ()
4: zone _de_ recherche_ affiche : Interface patient
10: donnes_ visualises 6: saisir_ variable_ de_ recherche () 7: recherche ()
9: afficher _formulaire _correspondant () 8: rechercher_ patient ()
: Patient
: C_patient
FigI.12 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Rechercher un patient .
-Scnario1-
- Scnario 2 : Recherche non fructueuse.

1: afficher _interface_ patient () 2: interface_ affiche
: Rceptonniste
3: clique_bouton _Rechercher () 5: saisir _critre_recherche()
4: zone de- recherche- affiche : Interface patient
10: message _visualis 6: saisir variable de recherche() 7: recherche ()
9: afficher_ message_erreur () 8: rechercher_ patient()
: Patient
: C_patient
FigI.13 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Rechercher un patient .
-Scnario2-
Projet de fin dtude
La phase dinception
27
Lors de la cration du dossier patient, si le patient en question figure dj dans notre base de donnes, la rceptionniste procde tout dabord sa recherche. Plusieurs critres de recherche sont possibles : code patient, nom, prnom, date de naissance Elle doit choisir un critre de recherche (5) puis saisir la variable de recherche correspondante (6). On entend par variable de recherche, le code du patient recherch si le critre de recherche est le code patient, le nom du patient recherch si le critre est le nom . Deux cas sont alors possibles : la recherche est soit fructueuse, soit dfaillante. Un formulaire correspondant au patient recherch est alors visualis sur lcran de la rceptionniste (10) lors dune recherche fructueuse (scnario1) sinon, un message derreur est alors affich sur cet cran (10) (scnario2) .
Conclusion :
Ayant ralis cette phase, nous avons russi rpondre aux questions suivantes : Le projet vaut-il la peine dtre entrepris ? Quels sont les principaux utilisateurs de notre futur systme ? Quelles fonctionnalits notre futur systme doit-il offrir pour satisfaire les besoins des diffrents acteurs ? Ce qui nous a permis de passer la phase dlaboration, dans laquelle nous entamerons la capture de nouveaux besoins, lanalyse des cas dutilisation secondaires et nouveaux, la conception des cas dutilisation prioritaires et secondaires, limplmentation des cas dutilisation prioritaires et enfin leurs tests respectifs.
Chapitre
(II)
La phase dlaboration
yant compris le contexte de notre systme lors de la prcdente phase, lobjectif maintenant est dapprofondir notre comprhension. En fait, nous sommes appels prsenter :
une spcification des nouveaux besoins identifis. un diagramme final de cas dutilisation. une analyse des cas dutilisation secondaires ainsi que des nouveaux cas identifis. une conception des cas dutilisation prioritaires et des cas dutilisation secondaires.
Projet de fin dtude
29
une implmentation des cas dutilisation prioritaires.
II.1 Capture des besoins :

La collecte dinformations est une activit trs importante au sein du processus unifi. En effet, au fur et mesure que nous avanons dans notre projet, des nouveaux besoins apparaissent, chaque besoin doit tre analys, conu, implment et enfin test. Le paramtrage est lune des fonctionnalits que nous avons captures dans cette phase. Dans notre cas, il sagit de paramtrer les tarifs des chambres, des types de prestations (analyse, radiologie, Oprations), des produits alimentaires (cuisine) et des fluides et appareillages. Il sagit aussi de saisir les conventions entre la polyclinique et diverses organisations. Une convention prcise deux importants accords tablis entre les deux membres : Les remises affectant les diffrentes rubriques dune facture. Exemple : 15% sur analyse, 25% sur sjour . Le taux de prise en charge : si le taux de PEC est de 25% par exemple, alors le patient paye 75% du montant de la facture, les 25% restantes, seront payes par lorganisation laquelle il appartient.
II.1.1- Modle final de cas dutilisation :

Dans ce qui suit, nous illustrons le modle final de cas dutilisation :
Projet de fin dtude
30
<<extend>>
Paramtrer mdecins Crer un dossier patient <<extend>> Paramtrer chambres Rechercher un patient Crer un patient
<<include>>
<<include>> Paramtrer cuisine <<include>> <<include>> paramtrer prestations <<include>> <<include>> <<include>> Paramtrer conventions <<include>>
Administrateur
Rceptionniste
Modifier un patient
Supprimer un patient
<<include>> Paramtrer fluide et appareill <<include>>
Rechercher un dossier patient <<include>> S'identifier <<include>> <<include>> Paramtrer tarif accompagnant <<include>>
<<include>> Modifier un dossier patient <<include>>
Passer une prestation une facture patient
Passer un produit une facture patient
Annuler un dossier patient Passer un produit alimentaire une facture patient Secrtaire d'tage
Enregistrer accompagnant Editer facture patient
Caissier
Passer un fluide ou appareill. une facture
Enregistrer rglement
FigII.1: modle final de cas dutilisation
Projet de fin dtude
31
II.1.2- Description des cas dutilisation :

La notion de scurit est trs importante au sein dun systme multiutilisateurs. Pour cette raison, il est indispensable dajouter un cas dutilisation Sidentifier . Comme schmatis auparavant (FigII.1), tous les acteurs doivent sidentifier avant de raliser nimporte quelle opration. Dans ce qui suit, nous prsentons la description des nouveaux cas dutilisation identifis.
CAISSIER :
Une autre fonctionnalit sajoute pour le caissier, cest lenregistrement du rglement. Une fois le paiement de la facture patient est effectu, le caissier doit le signaler informatiquement.
ADMINISTRATEUR:
Il est responsable de : la saisie des conventions avec les diverses organisations. La saisie des prestations (les tarifs des K - Opratoires, radiographie, bilans, explorations, ambulance) avec une possibilit de mise jour. La saisie des paramtres de la cuisine. La saisie des informations propres chaque chambre (type, tarification) ainsi quune possibilit de modification et/ou de suppression. La saisie des fluides et appareillages, ainsi que leurs tarifs. La saisie du tarif accompagnant.
SECRETAIRE DETAGE :
En plus des fonctionnalits cites au cours de la phase antrieure, cet agent doit pouvoir : Passer un produit alimentaire une facture patient. Enregistrer accompagnant.
Projet de fin dtude
32
Passer un fluide ou appareillage une facture patient.
II.2 Analyse :
II.2.1- Analyse des cas dutilisation secondaires :
II.2.1.1- Analyse du cas dutilisation Modifier un patient :
II.2.1.1.1-Traabilit entre le modle de cas dutilisation et le modle danalyse pour le cas dutilisation Modifier un patient : Modle du cas dutilisation Modle danalyse
trace
Rceptonniste Modifier un patient Modifier un patient
Patient
C_patient
Interface patient
FigII.2 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Modifier un patient . II.2.1.1.2- Diagramme de classes du modle danalyse pour le cas dutilisation Modifier un patient :
Projet de fin dtude
33
Rceptonniste
Interface patient
Patient
C_patient
FigII.3 : Diagramme de classes du modle danalyse pour le cas dutilisation Modifier un patient . II.2.1.1.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Modifier un patient :
: Rceptonniste
3: clique_bouton_ Modifier 5: modifier_ informations ()
4: formulaire_ correspondant_ affich : Interface patient 9: message_ visualis 6: modification ()
8: afficher_ message_rsultat () 7: modifier_ patient ()
: Patient
: C_patient
FigII.4 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Modifier un patient .
NB :
Ayant conu un cas dutilisation intitul Rechercher un patient , nous
navons pas intgr cette tche dans le cas dutilisation Modifier un patient . Cependant, il est important de signaler que la rceptionniste ne pourrait
Projet de fin dtude
34
modifier les informations propres un
patient quaprs avoir procd sa
recherche. Cette remarque est galement valable pour la suppression. Ce cas dutilisation se droule ainsi : La rceptionniste clique sur le bouton Modifier (3), puis, effectue les corrections adquates (5). Un message visualis sur son cran lui informe de droulement ou non de cette opration (9). II.2.1.2- Analyse du cas dutilisation Supprimer un patient :
II.2.1.2.1-Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Supprimer un patient : Modle du cas dutilisation
trace
Rceptonniste Supprimer un patient Supprimer un patient
Modle danalyse
Patient
C_patient
Interface patient
FigII.5 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Supprimer un patient . II.2.1.2.2- Diagramme de classes du modle danalyse pour le cas dutilisation Supprimer un patient :
Projet de fin dtude
35
Rceptonniste
Interface patient
Patient
C_patient
FigII.6 : Diagramme de classes du modle danalyse pour le cas dutilisation Supprimer un patient . II.2.1.2.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Supprimer un patient :
: Rceptonniste
3: clique_bouton_Supprimer
4: formulaire _correspondant_ affich
: Interface patient
5: confirmer_suppression ()
9: message_ visualis
6: suppression ()
8: afficher_ message_rsultat () 7: supprimer_ patient()
: Patient
: C_patient
FigII.7 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Supprimer un patient .
Projet de fin dtude
36
Lorsque la rceptionniste clique sur le bouton Supprimer (3), une bote de dialogue saffiche lui permettant de rechercher tout dabord le patient supprimer. Une fois ce dernier a t trouv, elle confirme sa demande de suppression (5).
II.2.1.3- Analyse du cas dutilisation Modifier un dossier patient :
II.2.1.3.1-Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Modifier un dossier patient :
Modle du cas dutilisation

trace
Rceptonniste Modifier un dossier patient
Modle danalyse
Modifier un dossier patient
Dossier
C_dossier
Interface dossier
FigII.8 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Modifier un dossier patient . II.2.1.3.2- Diagramme de classes du modle danalyse pour le cas dutilisation Modifier un dossier patient :
Projet de fin dtude
37
Rceptonniste
Interface dossier
Dossier
C_dossier
FigII.9 : Diagramme de classes du modle danalyse pour le cas dutilisation Modifier un dossier patient . II.2.1.3.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Modifier un dossier patient :
1: afficher_ interface_ dossier ()
2: interface _dossier_ affich
: Rceptonniste
3: clique_bouton_Modifier 5: modifier _informations ()
4: formulaire_ patient_affich 9: message_ visualis
: Interface dossier
6: modification ()
8: afficher_ message_rsultat () 7: modifier_ dossier ()
: Dossier
: C_dossier
FigII.10 : Diagramme de collaboration du modle danalyse pour le cas dutilisation

Modifier un dossier patient .
Projet de fin dtude
38
NB :
Ayant conu un cas dutilisation intitul Rechercher un dossier patient , nous
navons pas intgr cette tche dans le cas dutilisation Modifier un dossier patient . Cependant, il est important de signaler que la rceptionniste ne pourrait modifier les donnes dun dossier patient quaprs avoir procd sa recherche. Cette remarque est galement valable pour la suppression.
Pour que la rceptionniste puisse modifier des informations auparavant saisies, elle doit visualiser son interface dossier (1). Ensuite, elle clique sur le bouton Modifier (3). Le formulaire rempli correspondant au numro de dossier modifier, est visualis sur le poste de la rceptionniste (4). Cette dernire procde aux changements adquats (5). Et elle sera informe du bon accomplissement ou non de cette opration travers un message (9).
II.2.1.4- Analyse du cas dutilisation Annuler un dossier patient :
II.2.1.4.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Annuler un dossier patient : Modle du cas dutilisation Modle danalyse
trace
Rceptonniste
Annulerr un dossier patient
Annuler un dossier patient
Dossier
C_dossier
Interface dossier
FigII.11 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Annuler un dossier patient .
Projet de fin dtude
39
II.2.1.4.2 -Diagramme de classes du modle danalyse pour le cas dutilisation Annuler un dossier patient :
Rceptonniste
Interface dossier
Dossier
C_dossier
FigII.12 : Diagramme de classes du modle danalyse pour le cas dutilisation Annuler un dossier patient . II.2.1.4.3 -Diagramme de collaboration du modle danalyse pour le cas dutilisation Annuler un dossier patient :
1: afficher_ interface_ dossier ()
2: interface _dossier_ affich
: Rceptonniste
3: clique_bouton_Annuler
4: formulaire _correspondant_ affich 9: message_ visualis 6: annulation ()
: Interface dossier
5: comfirmer_ annulation ()
8: afficher_ message_rsultat () 7: annuler_dossier ()
: Dossier
: C_dossier
FigII.13 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Annuler un dossier patient .
Projet de fin dtude
40
Aprs avoir visualis son interface dossier (1), la rceptionniste clique sur le bouton Annuler (3). Une bote de dialogue saffiche lui permettant de rechercher
tout dabord le dossier patient annuler. Une fois ce dernier a t trouv, elle confirme sa demande dannulation (5).
Lagent sera inform du bon droulement ou non de cette opration travers un message visualis sur son cran (9). II.2.1.5- Analyse du cas dutilisation Rechercher un dossier patient :
II.2.1.5.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Rechercher un dossier patient :
Modle du cas dutilisation Modle danalyse
trace
Rceptonniste Rechercher un dossier patient Rechercher un dossier patient
Dossier
C_dossier
Interface dossier
FigII.14 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Rechercher un dossier patient .
Projet de fin dtude
41
II.2.1.5.2-Diagramme de classes du modle danalyse pour le cas dutilisation Rechercher un dossier patient :
Rceptonniste
Interface dossier
Dossier
C_dossier
FigII.15 : Diagramme de classes du modle danalyse pour le cas dutilisation Rechercher un dossier patient . II.2.1.5.3-Diagramme de collaboration du modle danalyse pour le cas dutilisation Rechercher un dossier patient :
- Scnario 1 : Recherche fructueuse.
1: afficher_ interface_ dossier () 2: interface_ affiche
: Rceptonniste
3: clique_ bouton_Rechercher 5: saisir_ critre_ de_ recherche() 6: saisir_ variable_recherche()
4: zone_ de_ recherhe_ affiche : Interface dossier 10: donnes_visualises
7: recherche ()
9: afficher_ formulaire_correspondant () 8: rechercher_ dossier ()
: Dossier
: C_dossier
FigII.16 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Rechercher un dossier patient .
-Scnario1-
Projet de fin dtude
42

1: afficher_ interface_dossier () 2: interface_affiche
: Rceptonniste
3: clique_bouton_Rechercher 5: saisir _critre_ de_ recherche()
4: zone_ de _recherhe_ affiche : Interface dossier 10: message_ visualis
6: saisir _variable_ de_ recherche()
7: recherche ()
9: afficher_ message_erreur () 8: rechercher_dossier ()
: Dossier
: C_dossier
FigII.17 : Diagramme de collaboration du modle danalyse pour le cas dutilisation Rechercher un dossier patient .
-Scnario2Pour que la rceptionniste puisse rechercher un dossier patient, elle devra cliquer sur le bouton Rechercher (3), prciser le critre de recherche (5) ainsi que la variable de recherche (6). Dans notre cas le critre de recherche est soit le numro du dossier, le nom du patient, son prnom. Nous entendons par la variable de recherche le numro du dossier du patient recherch, son nom . Deux possibilits sont alors envisageables : Le succs de la recherche : dans ce cas le formulaire correspondant au dossier patient recherch est visualis sur lcran de la rceptionniste (10) (scnario1).
- Lchec de la recherche : un message derreur est affich sur le poste de

cet agent (10) (scnario2).
Projet de fin dtude
43
II.2.1.6- Analyse du cas dutilisation Passer une prestation une facture patient :
II.2.1.6.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Passer une prestation une facture patient : Modle du cas dutilisation Modle danalyse
trace
Secrtaire d'tage Passer une prestation une facture patient Passer une prestation une facture patient
Tarif
Facture Ligne_prestation
C_facture
Interface facturation prestation
FigII.18: Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Passer une prestation une facture patient .
II.2.1.6.2-Diagramme de classes du modle danalyse pour le cas dutilisation Passer une prestation une facture patient :
Projet de fin dtude
44
Secrtaire d'tage
Interface facturation prestation
Ligne_prestation
C_facture
Facture
Tarif
FigII.18 Bis : Diagramme de classes du modle danalyse pour le cas dutilisation Passer une prestation une facture patient . II.2.1.6.3-Diagramme de collaboration du modle danalyse pour le cas dutilisation Passer une prestation une facture patient :
Projet de fin dtude
45
2: interface_affiche 1: afficher_interface_facturation_prestation ()
: Secrtaire d'tage
3: ajouter_prestation ()
9: message_visualis
: Interface facturation prestation
4: ajout ()
8: afficher_message_rsultat () 5: ajouter_ prestation ()
: Ligne_prestation 7: mise__jour () 6: extraire_prix_u ()
: C_facture
: Facture Tarif
FigII.19: Diagramme de collaboration du modle danalyse pour le cas dutilisation Passer une prestation une facture patient .
La secrtaire dtage demande la visualisation de linterface facturation prestation (1). Linterface affiche lui permettra dajouter la prestation adquate la facture du patient (3). Cette opration induit la mise jour de lentit Ligne_prestation . Sachant le nombre de la prestation, nous devons connatre le prix unitaire du coefficient de la prestation facture (6). La rubrique (type de la prestation) doit tre mise jour dans la facture (7) Un message signalant le droulement ou non de lopration est visualis sur le poste de cet agent (9). II.2.1.7- Analyse du cas dutilisation passer un produit une facture patient :
Projet de fin dtude
46
II.2.1.7.1 -Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Passer un produit une facture patient : Modle du cas dutilisation Modle danalyse
trace
Secrtaire d'tage Passer un produit une facture patient Passer un produit une facture patient
Facture
Ligne_produit
C_facture Interface facturation produit
FigII.20 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Passer un produit une facture patient . II.2.1.7.2-Diagramme de classes du modle danalyse pour le cas dutilisation Passer un produit une facture patient :
Projet de fin dtude
47
Secrtaire d'tage
Interface facturation produit
Ligne_produit
C_facture
Facture
FigII.21 : Diagramme de classes du modle danalyse pour le cas dutilisation Passer un produit une facture patient . II.2.1.7.3-Diagramme de collaboration du modle danalyse pour le cas dutilisation Passer un produit une facture patient :
1: afficher_interface_facturation_produit () 2: interface_affiche
: Secrtaire d'tage
3: ajouter_produit ()
8: message_visualis
: Interface facturation produit
4: ajout () 7: afficher_message_rsultat ()
5: ajouter_ produit ()
: Ligne_produit 6: mise__jour ()
: C_facture
: Facture
FigII.22: Diagramme de collaboration du modle danalyse pour le cas dutilisation Passer un produit une facture patient .
Projet de fin dtude
48
Il est important de signaler quun produit peut tre un mdicament ou un usage unique. Ce cas dutilisation se droule comme suit : La secrtaire dtage demande laffichage de linterface facturation produit (1) lui permettant denregistrer la consommation dun ou de plusieurs produits une facture patient(3). Cette fonctionnalit saccompagne dune mise jour de lentit Ligne_Produit , ainsi que le montant du type de la prestation en question dans lentit Facture . II.2.1.8- Analyse du cas dutilisation Editer facture patient :
II.2.1.8.1-Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Editer facture patient : Modle du cas dutilisation
trace
Caissier Editer la facture patient Editer la facture patient
Modle danalyse
Dossier
Catgorie_CH
Sjour
Facture
C_facture
Interface dition
FigII.23 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Editer facture patient . II.2.1.8.2-Diagramme de classes du modle danalyse pour le cas dutilisation Editer facture patient :
Projet de fin dtude
49
Caissier
Interface dition
Catgorie_CH Dossier Sjour
Facture
C_facture
FigII.24 : Diagramme de classes du modle danalyse pour le cas dutilisation Editer facture patient . II.2.1.8.3-Diagramme de collaboration du modle danalyse pour le cas dutilisation Editer facture patient :
1: afficher_ interface_ dition ()
2: interface_dition_ affich
: Caissier
3: clique_bouton_Editer_facture
12: message_ visualis
: Interface dition
4: saisir_numro_facture__imprimer () 5: imprimer_facture ()
:Catgorie_CH :Dossier
9: gnrer_ facture () 7: extraire_prix () 8: extraire_date_entre ()
11: afficher_ rsultat_impression ()
6: extraire_sejour ()
10: extraire_ facture () : Facture : C_facture
:Sjour
FigII.25: Diagramme de collaboration du modle danalyse pour le cas dutilisation Editer facture patient .
Le cas dutilisation Editer facture patient se droule ainsi :
Projet de fin dtude
50
Le caissier demande la visualisation de son interface dition (1), puis clique sur le bouton Editer facture (3). Une bote de dialogue saffiche lui demandant de saisir le numro de facture imprimer (4). Mais avant limpression, la facture doit tre gnre (5). En effet, toutes les rubriques sont dj mises jour sauf la rubrique Sjour . Alors on doit extraire le sjour du patient (6). Ensuite, les prix des chambres o a rsid le patient (7). Sachant la date de sortie (celle de ldition de la facture), nous devons connatre la date dentre du patient (8) pour enfin calculer le montant du sjour du patient et donc gnrer la facture (9). Enfin, on extrait la facture (10) pour limprimer.
II.2.2- Analyse des nouveaux cas dutilisation identifis :

II.2.2.1- Analyse du cas dutilisation Sidentifier :
NB : Lacteur Utilisateur modlis ci-dessous est gnrique c.--d. il englobe

tous les usagers de notre systme.
II.2.2.1.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Sidentifier :
Projet de fin dtude
51

trace
Utilisateur S'identifier
Modle danalyse
S'identifier
Accs
C_identification Interface identification
FigII.26 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Sidentifier . II.2.2.1.2- Diagramme de classes du modle danalyse pour le cas dutilisation Sidentifier :
Utilisateur
Interface identification
Accs
C_identification
FigII.27 : Diagramme de classes du modle danalyse pour le cas dutilisation Sidentifier .
Projet de fin dtude
52
II.2.2.1.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Sidentifier :
1: afficher_interface_identification ()
2: interface_affiche
: Utilisateur
3: saisir_nom_user ()
8: message_visualis 5: identification ()
: Interface identification
4: saisir_mot_de_passe ()
7: afficher_message_rsultat () 6: identifier_utilisateur ()
: Accs
: C_identification
FigII.28: Diagramme de collaboration du modle danalyse pour le cas dutilisation Sidentifier .

II.2.2.2- Analyse du cas dutilisation Paramtrer mdecins :
II.2.2.2.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer mdecins :
Projet de fin dtude
53

trace
Paramtrer mdecins Administrateur
Modle danalyse
Paramtrer mdecins
Mdecin
C_param
Interface paramtrage
FigII.29 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer mdecins . II.2.2.2.2- Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer mdecins :
Administrateur
Mdecin
C_param
FigII.30 : Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer mdecins .
Projet de fin dtude
54
II.2.2.2.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer mdecins :
1: afficher_interface_paramtrage () 2: interface_affiche
: Administrateur
3: clique _bouton _Paramtrer_mdecins
4: interface_mdecin_affiche 9: message_visualis
: Interface paramtrage
5: paramtrer_mdecins () 6: pramtrage_mdecins ()
7: paramtrer_mdecins ()
8: afficher_message_rsultat ()
: Mdecin
: C_param
FigII.31: Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer mdecins .
II.2.2.3 Analyse du cas dutilisation Paramtrer chambres :
II.2.2.3.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer chambres : Modle du cas dutilisation
trace
Administrateur Paramtrer chambres
Modle danalyse
Paramtrer chambres
Chambre
C_param
FigII.32 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer chambres .
Projet de fin dtude
55
II.2.2.3.2- Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer chambres :
Administrateur
Chambre
C_param
FigII.33 : Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer chambres .
II.2.2.3.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer chambres :
: Administrateur
3: clique _bouton _Paramtrer_chambres
4: interface_chambre_affiche 9: message_visualis
5: paramtrer_chambres () 6: pramtrage_chambres ()
7: paramtrer_chambres ()
: Chambre
: C_param
FigII.34: Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer chambres .
Le cas dutilisation Paramtrer chambres se droule ainsi :
Projet de fin dtude
56
Ladministrateur demande la visualisation de son interface de paramtrage (1), choisit ensuite lopration paramtrer_chambres (3). Aprs avoir effectuer les transformations convenables (5), notre agent sera inform du droulement ou non de cette opration travers un message_rsultat (9).
II.2.2.4- Analyse du cas dutilisation Paramtrer cuisine :
II.2.2.4.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer cuisine : Modle du cas dutilisation
trace
Administrateur Paramtrer cuisine Paramtrer cuisine
Modle danalyse
cuisine
C_param
FigII.35 : Traabilit entre le modle de cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer cuisine . II.2.2.4.2- Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer cuisine :
Projet de fin dtude
57
Administrateur
cuisine
C_param
FigII.36 : Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer cuisine . II.2.2.4.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer cuisine :
1: afficher_interface_paramtrage ()
: Administrateur
3: clique_bouton_paramtrer_cuisine 5: paramtrer_cuisine ()
4: interface_cuisine_affiche 9: message_visualis
6: paramtrage_cuisine ()
8: afficher_message_rsultat () 7: paramtrer_cuisine ()
: Cuisine
: C_param
FigII.37: Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer cuisine .
Pour pouvoir paramtrer les produits alimentaires et leurs tarifs,
ladministrateur demande laffichage de linterface cuisine (4) en cliquant sur
Projet de fin dtude
58
le bouton paramtrer_cuisine (3), puis effectue les modifications adquates (5). II.2.2.5- Analyse du cas dutilisation Paramtrer prestations :
II.2.2.5.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer prestations :

trace
Administrateur Paramtrer prestations
Modle danalyse
Paramtrer prestations
Prestation
C_param
FigII.38 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer prestations .
II.2.2.5.2- Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer prestations :
Projet de fin dtude
59
Administrateur
Prestation
C_param
FigII.39 : Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer prestations . II.2.2.5.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer prestations :
: Administrateur
3: clique_bouton_Paramtrer_prestations
4: interface_prestations-affiche : Interface paramtrage 9: message_visualis 6: paramtrage_prestations()
5: paramtrer_prestations ()
8: afficher_message_rsultat () 7: paramtrer_prestations ()
: Prestation
: C_param
FigII.40: Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer prestations .
Projet de fin dtude
60
Aprs avoir choisi lopration Paramtrer prestations (3), notre agent procde une saisie ou modification des paramtres propres aux prestations en question (5). II.2.2.6- Analyse du cas dutilisation Paramtrer conventions :
II.2.2.6.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer conventions :

trace
Administrateur Paramtrer conventions
Modle danalyse
Paramtrer conventions
Convention
C_param
FigII.41 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer conventions . II.2.2.6.2- Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer conventions :
Projet de fin dtude
61
Administrateur
Convention
C_param
FigII.42 : Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer conventions . II.2.2.6.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer conventions :
: Administrateur 3: clique_bouton_Paramtrer_conventions
4: interface_convention_affiche : Interface paramtrage
5: paramtrer_conventions ()
9: message_visualis 6: paramtrage_conventions ()
8: afficher_message_rsultat () 7: paramtrer_conventions ()
: Convention
: C_param
FigII.43: Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer conventions .
Pour pouvoir raliser cette fonctionnalit, ladministrateur doit afficher linterface de paramtrage (1), cliquer sur le bouton Paramtrer conventions (3) puis effectuer les transformations adquates (5).
Projet de fin dtude
62
II.2.2.7- Analyse du cas dutilisation Paramtrer fluides et appareillage :
II.2.2.7.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer fluides et appareillage :

trace
Administrateur Paramtrer fluides et appareillage
Modle danalyse
Paramtrer fluides et appareillage
Fluid_app
C_param
FigII.44 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer fluides et appareillage .1 II.2.2.7.2- Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer fluides et appareillage :
Fluid_app : fluides et appareillage.
Projet de fin dtude
63
Administrateur
FigII.45 : Diagramme de classes du modle danalyse pour le cas dutilisation paramtrer fluides et
appareillage .
Fluid_app
C_param
II.2.2.7.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer fluides et appareillage :
1: afficher_interface-paramtrage ()
: Administrateur
3: clique_bouton-Paramtrer_fluides et appareillage
: Interface paramtrage 4: interface_fluides_et_appareillage_affiche 9: message_visualis 6: paramtrage_fluides_et_appareillage ()
5: paramtrer_fluides_et_appareillage ()
8: afficher_message_rsultat () 7: paramtrer_fluides_et_appareillage ()
: Fluid_app
: C_param
FigII.46: Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer fluides et appareillage .
Ladministrateur demande la visualisation de linterface paramtrage (1), clique ensuite sur le bouton Paramtrer fluides et appareillage (3). Ce clic entrane laffichage de linterface fluides et appareillage (4) lui permettant de raliser les transformations adquates (5).
Projet de fin dtude
64
II.2.2.8- Analyse du cas dutilisation Paramtrer tarifs accompagnant :
II.2.2.8.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer tarifs accompagnant : Modle du cas dutilisation Modle danalyse
trace
Administrateur Paramtrer tarifs accompagnant Paramtrer tarifs accompagnant
Accompagnant
C_param
FigII.47 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Paramtrer tarifs accompagnant . II.2.2.8.2- Diagramme de classes du modle danalyse pour le cas dutilisation Paramtrer tarifs accompagnant :
FigII.48 : Diagramme de classes

Administrateur Interface paramtrage
du modle danalyse pour le cas dutilisation Paramtrer tarifs

accompagnant .
Accompagnant C_param
Projet de fin dtude
65
II.2.2.8.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer tarifs accompagnant :
1: afficher_interface_paramtrage ()
: Interface paramtrage : Administrateur 3: clique_bouton_Paramtrage_tarifs_accompagnant 4: interface_accompagnant affiche 5: paramtrer_tarifs_acc () 9: message_visualis 6: paramtrage_tarifs_acc ()
8: afficher_message_rsultat () 7: paramtrer_tarifs_acc ()
: Accompagnant
: C_param
FigII.49: Diagramme de collaboration du modle danalyse pour le cas dutilisation Paramtrer tarifs accompagnant .
Aprs avoir affich linterface accompagnant (4), ladministrateur procde un paramtrage des tarifs (5). Un message visualis sur son cran lui informe du succs ou de lchec de cette opration (9). II.2.2.9- Analyse du cas dutilisation Enregistrer rglement :
II.2.2.9.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Enregistrer rglement :
Projet de fin dtude
66

trace
Caissier Enregistrer rglement
Modle danalyse
Enregistrer rglement
Rglement
C_rglement
Interface dition
FigII.50 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Enregistrer rglement . II.2.2.9.2- Diagramme de classes du modle danalyse pour le cas dutilisation Enregistrer rglement :
Caissier
Interface dition
FigII.51 : Diagramme de classes du modle danalyse pour le cas dutilisation Enregistrer

rglement .
Rglement
C_rglement
Projet de fin dtude
67
II.2.2.9.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Enregistrer rglement :
1: afficher_interface_dition () 2: interface_affiche
: Caissier
3: clique_bouton_Enregistrer_rglement 5: enregistrer_rglement ()
4: interface_rglement_affiche : Interface dition 9: message_visualis 6: enregistrement_rglement () 8: afficher_message_rsultat ()
7: enregistrer_rglement ()
: Rglement
: C_rglement
FigII.52: Diagramme de collaboration du modle danalyse pour le cas dutilisation Enregistrer rglement.
Une fois, la facture patient est paye, un rglement informatique doit avoir lieu. Le caissier charg de cette tche choisit alors lopration Enregistrer rglement de linterface dition (3). Ce choix aboutissant laffichage de linterface rglement (4), lui permet denregistrer ce paiement (5). II.2.2.10- Analyse du cas dutilisation Passer un produit alimentaire une facture patient :
II.2.2.10.1- Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Passer un produit alimentaire une facture patient :
Projet de fin dtude
68
Modle danalyse
trace
Secrtaire d'tage
Passer un produit alimentaire une facture patient
Passer un produit alimentaire une facture patient
Facture
Ligne_prodalim C_facture
FigII.53 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Passer un produit alimentaire une facture patient .2 II.2.2.10.2- Diagramme de classes du modle danalyse pour le cas dutilisation Passer un produit alimentaire une facture patient :
Secrtaire d'tage
Interface facturation prodalim
Ligne_prodalim
C_facture
Facture
FigII.54 : Diagramme de classes du modle danalyse pour le cas dutilisation Passer un produit alimentaire une facture patient .
2
prodalim : produit alimentaire.
Projet de fin dtude
69
II.2.2.10.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Passer un produit alimentaire une facture patient :
1: afficher_interface_facturation_prodalim () 2: interface_affiche
: Secrtaire d'tage
3: ajouter_prodalim ()
8: message_visualis ()
: Interface facturation prodalim
4: ajout () 7: afficher_message_rsultat () 5: ajouter_prodalim ()
: Ligne_prodalim
6: mise__jour ()
: C_facture
: Facture
FigII.55: Diagramme de collaboration du modle danalyse pour le cas dutilisation Passer un produit alimentaire une facture patient.
Pour pouvoir passer un produit alimentaire une facture patient, la secrtaire dtage doit visualiser tout dabord linterface facturation prodalim (1). Cette interface lui permettra denregistrer ce mouvement (3) tout en mettre jour lentit Facture (6). II.2.2.11- Analyse du cas dutilisation Enregistrer accompagnant :
II.2.2.11.1-Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Enregistrer accompagnant :
Projet de fin dtude
70
Modle danalyse
trace
Secrtaire d'tage
Enregistrer accompagnant
Enregistrer accompagnant
Accompagnant
C_accompagnant Interface accompagnant
FigII.56 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Enregistrer accompagnant . II.2.2.11.2- Diagramme de classes du modle danalyse pour le cas dutilisation Enregistrer accompagnant :
Secrtaire d'tage
Interface accompagnant
Accompagnant
C_accompagnant
FigII.57 : Diagramme de classes du modle danalyse pour le cas dutilisation Enregistrer accompagnant .
Projet de fin dtude
71
II.2.2.11.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Enregistrer accompagnant :
1: afficher_interface-accompagnant ()
: Secrtaire d'tage
3: enregistrer_acc ()
7: message_affiche
: Interface accompagnant
4: enregistrement_acc ()
5: enregistrer_acc ()
: Accompagnant
: C_accompagnant
FigII.58: Diagramme de collaboration du modle danalyse pour le cas dutilisation Enregistrer accompagnant.
A la fin de chaque journe, la secrtaire dtage parcourt toutes les chambres et enregistre la liste des accompagnants. Pour accomplir cette fonctionnalit informatiquement, notre agent demande la visualisation de linterface accompagnant (1) lui permettant denregistrer ce mouvement (3). II.2.2.12Analyse du cas dutilisation Passer un fluide ou
appareillage une facture patient :
II.2.2.12.1-Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Passer un fluide ou appareillage une facture patient :
Projet de fin dtude
72
Modle danalyse
trace
Secrtaire d'tage
Passer un fluide ou appareillage une facture patient
Passer un fluide ou appareillage une facture patient
Facture
Ligne_fluid_app C_facture
Interface facturation fluid_app
FigII.59 : Traabilit entre le modle du cas dutilisation et le modle danalyse pour le cas dutilisation Passer un fluide ou appareillage une facture patient . II.2.2.12.2- Diagramme de classes du modle danalyse pour le cas dutilisation Passer un fluide ou appareillage une facture patient :
Secrtaire d'tage
Interface facturation fluid_app
Ligne_fluid_app
C_facture
Facture
FigII.60 : Diagramme de classes du modle danalyse pour le cas dutilisation Passer un fluide ou appareillage une facture patient .
Projet de fin dtude
73
II.2.2.12.3- Diagramme de collaboration du modle danalyse pour le cas dutilisation Passer un fluide ou appareillage une facture patient :
1: afficher_interface_facturation_fluid_app ()
3: ajouter_fluid_app () : Secrtaire d'tage : Interface facturation fluid_app 8: message_affich () 4: ajout ()
7: afficher_message_rsultat () 5: ajouter_fluid_app ()
: Ligne_fluid_app
6: mise__jour ()
: C_facture
: Facture
FigII.61: Diagramme de collaboration du modle danalyse pour le cas dutilisation Passer un fluide ou appareillage une facture patient .
Pour ajouter un fluide ou appareillage une facture patient, la secrtaire dtage demande la visualisation de linterface facturation fluid_app (1), puis enregistre le mouvement effectu (3). Cet ajout est accompagn dune mise jour de lentit Facture (6). Un message informant lagent du succs ou de lchec de cette opration, est visualis sur son cran (8).
II.3 Conception :
II.3.1-Conception des cas dutilisation prioritaires :
II.3.1.1- Conception du cas dutilisation Crer un dossier patient :
II.3.1.1.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Crer un dossier patient :
Projet de fin dtude
74
Interface dossier
(from Use Case View)
C_dossier
Dossier
Facture
Modle danalyse
trace
<<control>> C_dossier
trace
<<entity>> Dossier
<<boundary>> souris
<<boundary>> ecran
<<entity>> Facture
Modle de conception
<<boundary>> clavier
<<boundary>> Interface dossier

<<entity>> Classe persistante
FigII.62 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Crer un dossier patient .
II.3.1.1.2-Diagramme de classes du modle de conception pour le cas dutilisation Crer un dossier patient :
Projet de fin dtude
75
<<boundary>> souris Rceptonniste


<<boundary>> clavier <<entity>> Dossier

<<boundary>> ecran
<<entity>> Facture
FigII.63 : Diagramme de classes du modle de conception pour le cas dutilisation

Crer un dossier patient .
II.3.1.1.3 -Diagramme de squence du modle de conception pour le cas dutilisation Crer un dossier patient :
Projet de fin dtude
76
: ecran
: Rceptonniste
: clavier
: souris
:Interface dossier
: C_dossier
: Dossier
: Facture
afficher_interface_dossier ()
afficher_interface ()
interface_affiche
clique_bouton_Crer
afficher_formulaire_vierge ()
afficher_formulaire_vierge ()
formulaire_affich
saisir_informations (dos)
cration (dos)
crer_dossier (dos)
afficher_message_rsultat ( )
crer_facture (num_dos)
message_affich
FigII.64 : Diagramme de squence du modle de conception pour le cas dutilisation

Crer un dossier patient .3
II.3.1.2- Conception du cas dutilisation Crer un patient :
II.3.1.2.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Crer un patient :
dos : nouvelle instance de la classe entit Dossier cre par la secrtaire dtage. Les attributs de cette classe seront prsents lors de limplmentation. num_dos : numro de dossier permettant didentifier la facture crer.
Projet de fin dtude
77
Interface patient C_patient

(from Use Case View) (from Use Case View) (from Use Case View)
Patient
trace
<<boundary>> ecran <<boundary>> souris <<control>> C_patient
trace
<<entity>> Patient
Modle danalyse Modle de conception
<<boundary>> Interface patient

FigII.65 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Crer un patient . II.3.1.2.2-Diagramme de classes du modle de conception pour le cas dutilisation Crer un patient :
Projet de fin dtude
78
<<boundary>> souris

Rceptonniste
<<control>> C_patient
<<boundary>> ecran
<<entity>> Patient

Crer un patient .
II.3.1.2.3 -Diagramme de squence du modle de conception pour le cas dutilisation Crer un patient :
Projet de fin dtude
79
: ecran : Rceptonniste
:clavier
:souris
: Interface patient
:C_patient
: Patient
afficher_interface_patient ()
interface affiche
cliquer sur le bouton Crer () afficher_formulaire_vierge () formulaire_vierge_affich
saisir_informations ( pat) cration (pat) crer_patient (pat)
afficher_message_rsultat () message_visualis

Crer un patient .4
II.3.1.3- Conception du cas dutilisation Rechercher un patient :
II.3.1.3.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Rechercher un patient :
pat : instance de la classe entit Patient cre par la secrtaire dtage.
Projet de fin dtude
80
Interface patient
C_patient
Patient
trace
trace
<<entity>> Patient
<<boundary>> souris
<<boundary>> ecran

FigII.68 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Rechercher un patient . II.3.1.3.2-Diagramme de classes du modle de conception pour le cas dutilisation Rechercher un patient :
Projet de fin dtude
81
<<boundary>> Interface patient <<boundary>> souris

(f rom Use Case View)
Rceptonniste
<<control>> C_patient <<boundary>> clavier

<<entity>> Patient
<<boundary>> ecran

Rechercher un patient .
II.3.1.3.3 -Diagramme de squence du modle de conception pour le cas dutilisation Rechercher un patient :
Projet de fin dtude
82
:ecran : Rceptonniste
:clavier
:souris
:Interface patient
:C_patient
:patient
afficher_interface_patient () afficher_interface () interface_affiche
clique_bouton_Rechercher afficher_zone_de_recherche () afficher_zone_de_recherche () zone_de_recherche_affiche
saisir_critre_de_recherche (critre) saisir_variable_de_recherche (var )
Recherche (var)
rechercher_patient (var) [ succs] afficher_formulaire_correpondant () formulaire_affich

Rechercher un patient .5 -Scnario 1-
var : la valeur de la variable qui correspond au critre de recherche choisi.
Projet de fin dtude
83
:clavier
:souris
:Interface patient
:C_patient
:patient
afficher_interface_patient () afficher_interface () interface_affiche
clique_bouton_Rechercher afficher_zone_de_recherche () afficher_zone_de_recherche () zone_de_recherche_affiche
recherche (var)
rechercher_patient (var)
[ chec] afficher_message_erreur () message_affich

Rechercher un patient . -Scnario 2-
II.3.2-Conception des cas dutilisation secondaires :

II.3.2.1- Conception du cas dutilisation Modifier un patient :
II.3.2.1.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Modifier un patient :
Projet de fin dtude
84
Interface patient
C_patient
Patient
trace
trace
<<boundary>> souris
<<boundary>> ecran
<<entity>> Patient

FigII.72 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Modifier un patient . II.3.2.1.2-Diagramme de classes du modle de conception pour le cas dutilisation Modifier un patient :
<<boundary>> souris

(from Use Case Vi ew)
Rceptonniste
<<boundary>> ecran
<<entity>> Patient
FigII.73: Diagramme de classes du modle de conception pour le cas dutilisation

Modifier un patient .
Projet de fin dtude
85
II.3.2.1.3 -Diagramme de squence du modle de conception pour le cas dutilisation Modifier un patient :
:clavier
:souris
:Interface patient
C_patient
:Patient
afficher_interface_patient () afficher_interface_patient () interface_affiche
clique_bouton_Modifier afficher_formulaire_correspondant () afficher_formulaire_correspondant () formulaire_correspondant_affich
modifier_informations ( pat) modification (pat) modifier_patient (pat) afficher_message_rsultat () message_visualis

Modifier un patient . II.3.2.2- Conception du cas dutilisation Supprimer un patient :
II.3.2.2.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Supprimer un patient :
Projet de fin dtude
86
Interface patient
C_patient
Patient
trace
Modle danalyse
trace
<<boundary>> souris
<<boundary>> ecran
<<entity>> Patient
Modle de conception

FigII.75 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Supprimer un patient . II.3.2.2.2-Diagramme de classes du modle de conception pour le cas dutilisation Supprimer un patient :
<<boundary>> souris
Rceptonniste
<<boundary>> ecran
<<entity>> Patient

Supprimer un patient .
Projet de fin dtude
87
II.3.2.2.3 -Diagramme de squence du modle de conception pour le cas dutilisation Supprimer un patient :
:clavier
:souris
:Interface patient
C_patient
:Patient
afficher_interface_patient () afficher_interface_patient () interface_affiche
clique_bouton_Supprimer afficher_formulaire_correspondant () afficher_formulaire_correspondant () formulaire_affich
confirmer_suppression ( codep ) suppression (codep) supprimer_patient (codep) afficher_message_rsultat () message_visualis
FigII.77 : Diagramme de squence du modle de conception pour le cas dutilisation Supprimer un patient . 6
II.3.2.3- Conception du cas dutilisation Modifier un dossier patient :
II.3.2.3.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Modifier un dossier patient :
codep : code patient.
Projet de fin dtude
88
Interface dossier
C_dossier
Dossier
Modle danalyse
trace
trace
<<boundary>> souris
<<boundary>> ecran
<<entity>> Dossier
Modle de conception

FigII.78 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Modifier un dossier patient . II.3.2.3.2-Diagramme de classes du modle de conception pour le cas dutilisation Modifier un dossier patient :
<<boundary>> souris Rceptonniste

<<boundary>> clavier <<entity>> Dossier

<<boundary>> ecran

Modifier un dossier patient .
Projet de fin dtude
89
II.3.2.3.3 -Diagramme de squence du modle de conception pour le cas dutilisation Modifier un dossier patient :
:clavier
:souris
:Interface dossier
:C_dossier
:dossier
afficher_interface_dossier () afficher_interface () interface_affiche
clique_bouton_Modifier afficher_formulaire_correspondant () afficher_formulaire_correspondant () formulaire_affich
modifier_informations (dos) modification (dos) modifier_dossier (dos) afficher_message_rsultat () message_visualis
FigII.80 : Diagramme de squence du modle de conception pour le cas dutilisation Modifier un dossier patient . 7
II.3.2.4- Conception du cas dutilisation Annuler un dossier patient :
II.3.2.4.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Annuler un dossier patient :
num_dos : numro de dossier.
Projet de fin dtude
90
Interface dossier
C_dossier
Dossier
Modle danalyse
trace
trace
<<boundary>> souris
<<boundary>> ecran
<<entity>> Dossier
Modle de conception

FigII.81 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Annuler un dossier patient . II.3.2.4.2-Diagramme de classes du modle de conception pour le cas dutilisation Annuler un dossier patient :
<<boundary>> souris
Rceptonniste

<<entity>> Dossier
<<boundary>> ecran

Annuler un dossier patient .
Projet de fin dtude
91
II.3.2.4.3 -Diagramme de squence du modle de conception pour le cas dutilisation Annuler un dossier patient :
:clavier
:souris
:Interface dossier
:C_dossier
:Dossier
afficher_interface_dossier ()
afficher_interface_dossier () interface_affiche
clique_bouton_Annuler afficher_formulaire_correspondant () formulaire_affich afficher_formulaire_correspondant ()
confirmer_annulation ( num_dos )
annulation (num_dos) annuler_dossier (num_dos)
FigII.83 : Diagramme de squence du modle de conception pour le cas dutilisation Annuler un dossier patient .
II.3.2.5- Conception du cas dutilisation Rechercher un dossier patient :
II.3.2.5.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Rechercher un dossier patient :
Projet de fin dtude
92
Interface dossier
C_dossier
Dossier
Modle danalyse
trace
trace
<<boundary>> souris
<<boundary>> ecran
<<entity>> Dossier
Modle de conception

FigII.84 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Rechercher un dossier patient . II.3.2.5.2-Diagramme de classes du modle de conception pour le cas dutilisation Rechercher un dossier patient :
<<boundary>> souris
Rceptonniste

<<entity>> Dossier
<<boundary>> ecran

Rechercher un dossier patient .
Projet de fin dtude
93
II.3.2.5.3 -Diagramme de squence du modle de conception pour le cas dutilisation Rechercher un dossier patient :
:clavier
:souris
:Interface dossier
:C_dossier
:Dossier
afficher_interface_dossier () afficher_interface_dossier () interface_affiche
clique_bouton_Rechercher afficher_zone_de_recherche () zone_de_recherche_affiche
afficher_zone_de_recherche ()
recherche (var) rechercher_dossier (var)
[ succs] afficher_formulaire_correpondant () formulaire_affich

Rechercher un dossier patient . -Scnario 1- Scnario 2 : Recherche non fructueuse.
Projet de fin dtude
94
:clavier
:souris
:Interface dossier
:C_dossier
:Dossier
afficher_interface_dossier () afficher_interface_dossier () interface_affiche
clique_bouton_Rechercher afficher_zone_de_recherche () zone_de_recherche_affiche
afficher_zone_de_recherche ()
saisir_critre_de_recherche (critre_choisi) saisir_variable_de_recherche (var )
recherche (var) rechercher_dossier(var)
[ chec] afficher_message_erreur () message_affich

Rechercher un dossier patient . -Scnario 2II.3.2.6- Conception du cas dutilisation Passer une prestation une facture patient :
II.3.2.6.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Passer une prestation une facture patient :
Projet de fin dtude
95
C_facture Interface facturation prestation

Tarif
Ligne_prestation
Facture
Modle danalyse
trace
trace
<<boundary>> souris
<<boundary>> ecran
<<control>> C_facture
<<entity>> Tarif
<<entity>> Ligne_prestation
<<entity>> Facture
Modle de conception
<<boundary>> Interface facturation prestation

FigII.88 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Passer une prestation une facture patient . II.3.2.6.2-Diagramme de classes du modle de conception pour le cas dutilisation Passer une prestation une facture patient :
<<boundary>> Interface facturation prestation
<<boundary>> souris
Secrtaire d'tage
<<boundary>> ecran
<<entity>> Facture
<<entity>> Ligne_prestation
<<entity>> Tarif
FigII.89 : Diagramme de classes du modle de conception pour le cas dutilisation Passer une prestation
une facture patient .
Projet de fin dtude
96
II.3.2.6.3 -Diagramme de squence du modle de conception pour le cas dutilisation Passer une prestation une facture patient :
:ecran
:clavier
;souris
: Secrtaire d'tage
:Interface facturation prestation
:C_facture
:Ligne_prestation
:Facture
:Tarif
afficher_interface_facturation_prestation ()
afficher_interface_facturation_prestation ()
interface_affiche
ajouter_prestation ( cp, num_dos, quantit) ajout ( cp, num_dos, quantit)

ajouter_prestation ( cp, num_dos, quantit )
extraire_prix_u ( coef)
mise__jour ( mtpre, rubrique, num_dos)
afficher_message_rsultat ()
message_visualis

Passer une prestation une facture patient .8
II.3.2.7- Conception du cas dutilisation Passer un produit une facture patient :
II.3.2.7.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Passer un produit une facture patient :
cp : code prestation. mtpre : montant de la prestation ajouter. rubrique : cest la rubrique de la facture o doit figurer le produit en question. coef : coefficient de la prestation.
Projet de fin dtude
97

C_facture
Ligne_facture
Facture
Modle danalyse
trace
<<boundary>> souris <<boundary>> ecran <<control>> C_facture
trace
<<entity>> Ligne_produit
<<entity>> Facture
Modle de conception
<<boundary>> Interface facturation produit

FigII.91 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Passer un produit une facture patient . II.3.2.7.2-Diagramme de classes du modle de conception pour le cas dutilisation Passer un produit une facture patient :
Projet de fin dtude
98
<<boundary>> souris
<<boundary>> Interface facturation produit

Secrtaire d'tage
<<boundary>> ecran <<entity>> Ligne_facture <<entity>> Facture

FigII.92 : Diagramme de classes du modle de conception pour le cas dutilisation Passer un produit une
facture patient .
II.3.2.7.3 -Diagramme de squence du modle de conception pour le cas dutilisation Passer un produit une facture patient :
Projet de fin dtude
99
:ecran : Secrtaire d'tage
:clavier
:souris
:Interface facturation produit
:C_facture
:Ligne_produit
:Facture
afficher_interface_facturation_produit () afficher_interface_facturation_produit () interface_affiche
ajouter_produit ( cpd, num_dos, quantit) ajout ( cpd, num_dos, quantit) ajouter_produit ( cpd, num_dos, quantit)
mise__jour ( mtpd, rubrique, num_dos) afficher_message_rsultat () message_visualis

Passer un produit une facture patient .9 II.3.2.8- Conception du cas dutilisation Editer facture patient :
II.3.2.8.1-Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Editer facture patient :
cpd : code produit. mtpd : montant du produit ajouter. rubrique : cest la rubrique de la facture o doit figurer le produit en question.
Projet de fin dtude
100
Interface dition C_facture

(from Use Case View) (from Use Case View)
Catgorie_CH
Dossier
Sjour
Facture
trace
<<boundary>> souris <<boundary>> ecran
trace
trace
<<entity>> Dossier
Modle danalyse
<<entity>> Sjour
<<entity>> Facture
<<boundary>> Interface dition

<<entity>> Catgorie_CH
<<boundary>> imprimante
Modle de conception
FigII.94 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Editer facture patient . II.3.2.8.2-Diagramme de classes du modle de conception pour le cas dutilisation Editer facture patient :
<<boundary>> souris <<boundary>> Interface dition
<<boundary>> clavier Secrtaire d'tage

<<boundary>> ecran
<<entity>> Dossier
<<entity>> Sjour
<<entity>> Facture
<<entity>> Catgorie_CH
<<boundary>> imprimante <<entity>> Classe persistante

Editer facture patient .
dutilisation Editer facture patient :
II.3.2.8.3 -Diagramme de squence du modle de conception pour le cas
10
:ecran
:clavier
:imprimante
:souris
:Interface dition
:C_facture
:Facture
:Sjour
:Catgorie_CH
:Dossier
: Caissier
afficher_interface_dition ()
Projet de fin dtude
interface_affiche
afficher_interface_dition ()
clique_bouton_Editer_facture
saisir_numro_facture__imprimer (num_dos)
imprimer_facture (num_dos)
extraire_sjour (num_dos)

extraire_prix (cat)
cat : catgorie des chambres o a rsid le patient. mtsjour : montant du sjour.

date_entre ( num_dos)
gnrer_facture (num_dos, mtsjour)
extraire_facture (num_dos)
Editer facture patient 10.

imprimer_facture (num_dos)
afficher_rsultat_impression ()
message_visualis
afficher_message_rsultat ()
message_visualis
101
Projet de fin dtude
102
II.4 Implmentation:
Dans la phase courante, cette activit se dcompose de deux grandes parties ; la construction dun schma initial de la base de donnes et limplmentation des cas dutilisation prioritaires. La premire partie est ralise en trois tches ; la description et la ralisation du diagramme des classes entits dgages de lactivit de conception des cas dutilisations prioritaires, la prsentation des rgles de passage dun diagramme de classes une base de donnes relationnelle et enfin le schma initial de la base de donnes. La deuxime partie est labore sur deux tapes ; les traabilits entre modles de conception et modles dimplmentation et ensuite les diagrammes de composants.
II.4.1-Construction dun schma initial de la base de donnes :

II.4.1.1- Description et diagrammes des classes entits prioritaires: La description des classes entits, dgages de la conception des cas dutilisations prioritaires, est reprsente sous formes de tableaux. Chaque tableau reprsente une classe entit et se compose dattributs et de mthodes.
Description de la classe entit Patient :
Projet de fin dtude
103
Patient Attributs
CPAT NOM PRENOM ADRESSE TELEPHONE DATE_NAISSANCE NATIONALITE GENRE_ID Nom Prnom Adresse Tlphone Date de naissance Nationalit Genre didentification (Passeport, CIN...) Numro de la pice didentification
Libell
Code Patient
Type
VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR DATE VARCHAR VARCHAR
Contraintes
Cl primaire
NPIECE_ID
VARCHAR
Mthodes
crer_patient rechercher_patient
Type retourn
boolen Patient
paramtres
Patient pat String critre, String var
Description de la classe entit Dossier : Dossier Attributs

ND DATE_ENTREE RESPONSABLE TEL_RESP ADR_RESP CPAT CM CC
Libell
Code Dossier String Date dentre du Date patient Personne responsable String du patient Tlphone du String responsable Adresse du responsable String Code patient String Code mdecin String Code convention String
Type
Mthodes
crer_dossier
Type retourn
boolen
paramtres
Dossier dos
Description de la classe entit Facture :
Projet de fin dtude
104
Attributs
ND DATE MONTANTHT MONTANTTTC
FACTURE Libell
String Date Float Float Float Float Float Float Float Float Float
Type
Code Dossier Date de facturation Montant hors taxes Montant tous taxes compris SEJOUR Montant du sjour ANALYSE Montant des analyses RADIO Montant des radios ACTE_OPERATOIRE Montant des actes opratoires USAGE_UNIQUE Montant des usages uniques ECG Montant des ECG FLUIDE Montant des fluides et appareillages
Mthodes
crer_facture
Type retourn
boolen
paramtres
String num_dos
Le diagramme de classes dcrit un ensemble dobjets qui partagent les mmes attributs, mthodes et relations. <<entity>> Patient
possde
1 1..*
<<entity>> Dossier
correspond
1
FigII.97 : Diagramme des classes entits des cas dutilisation prioritaires.
<<entity>> Facture
II.4.1.2- Rgles de passage dun diagramme de classes une base de donnes relationnelle:
Les rgles de passage :

Affecter une table chaque classe. Une association un plusieurs engendre la migration de la cl primaire de la table mre la table fille.
Projet de fin dtude
105
Une association plusieurs plusieurs est reprsente par une table ayant pour cl primaire la concatnation des cls primaires des deux tables associes.
Les rgles de normalisation :

Une table est sous la troisime forme normale si, tout moment, chaque ligne est constitue dun identificateur dobjet unique associ un certain nombre dattributs indpendants [5]. II.4.1.3- Schma initial de la base de donnes : La table : Patient
Colonne
CPAT NOM PRENOM ADRESSE TELEPHONE DATE_NAISSANCE NATIONALITE GENRE_ID NPIECE_ID
PATIENT Libell
Code Patient Nom Prnom Adresse Tlphone Date de naissance Nationalit Genre didentification (Passeport, CIN...) Numro de la pice didentification La table : Dossier
Type
VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR DATE VARCHAR VARCHAR VARCHAR
Contraintes
Cl primaire
Colonne
ND DATE_ENTREE RESPONSABLE TEL_RESP ADR_RESP CPAT CM CC
DOSSIER Libell
Type
Contraintes
Cl primaire
Code Dossier VARCHAR Date dentre du DATE patient Personne responsable VARCHAR du patient Tlphone du VARCHAR responsable Adresse du responsable VARCHAR Code patient VARCHAR Code mdecin VARCHAR Code convention VARCHAR La table : Facture
Cl trangre Cl trangre Cl trangre
Colonne
ND DATE MONTANTHT MONTANTTTC
FACTURE Libell
Code Dossier Date de facturation Montant hors taxes Montant tous taxes
Type
Contraintes
VARCHAR Cl primaire DATE FLOAT FLOAT
Projet de fin dtude
106
SEJOUR ANALYSE RADIO ACTE_OPERATOIRE USAGE_UNIQUE ECG FLUIDE
compris Montant du sjour Montant des analyses Montant des radios Montant des actes opratoires Montant des usages uniques Montant des ECG Montant des fluides et appareillages
FLOAT FLOAT FLOAT FLOAT FLOAT FLOAT FLOAT
II.4.2-Implmentation des cas dutilisation prioritaires :

Limplmentation des cas dutilisations prioritaires permettra de livrer un premier incrment de lapplication. Les cas dutilisation prioritaires sont : crer patient , rechercher patient et crer dossier . Lobjectif des deux premiers cas dutilisation, est daboutir la ralisation du troisime, car pour crer un dossier patient, deux cas sont possibles ; soit le patient en question est dj venu, la rceptionniste le cherche alors dans la base de donnes et lui cre un dossier, soit le patient vient pour la premire fois, la rceptionniste lui cre alors une fiche, ensuite un dossier. On remarque alors que les trois cas dutilisation prioritaires sont dpendants, et quaucun deux ne peut fonctionner seul. Nous allons alors, les implmenter ensemble pour mettre en vidence lacheminement dune interface une autre, ainsi que les dpendances entre les classes dgages lors de lactivit de conception. Limplmentation sera labore en deux tapes, la premire tape consiste raliser la traabilit entre le diagramme dtats-transitions des interfaces et le diagramme des composants interfaces (il sagit des interfaces utilisateurs). La deuxime consiste raliser le diagramme de composants. Le diagramme de composants dcrit linteraction des lments physiques dans lenvironnement de ralisation. II.4.2.1- Traabilit entre le diagramme dtats-transitions et le diagramme de composants des cas dutilisation prioritaires : Cette traabilit permet de dgager les interfaces utilisateurs Java que nous devons implmenter. Il existe deux classes mres dinterfaces utilisateurs en
Projet de fin dtude
107
Java. Toutes nos futures classes interfaces hriteront de lune delles : JFrame de la bibliothque Swing et Frame de la bibliothque AWT .
Interface de recherche Patient
trace
"file" Patient.java
[Patient inexistant]
Interface Patient
[Patient existant]
Interface dossier patient
trace
"file" Dossier.java
trace
FigII.98 : Ralisation des interfaces des cas dutilisation prioritaires

II.4.2.2- Le diagramme de composants des cas dutilisation prioritaires : Nous rappelons quaucun des trois cas dutilisation prioritaires ne peut fonctionner seul. cause de cette dpendance, nous allons laborer un seul diagramme de composants pour les trois cas dutilisation. Dans la figure (II.98), on comprend que les classes interfaces utilisent les classes de
contrle, les classes de contrle utilisent les classes entits, et les classes entits hritent de la classe persistante qui extrait (et met jour) les donnes des tables de la base de donnes. Cet enchanement sera clair dans lexemple suivant : Nous allons prsenter les consquences dun clic sur le bouton crer de linterface DOSSIER . Linterface est en coute de lutilisateur grce ces lignes de code : bouton.addActionListener(new java.awt.event.ActionListener() { public void actionPerformed(ActionEvent e) { bouton_actionPerformed(e);
Projet de fin dtude
108
} }); Lorsque lutilisateur clique sur le bouton Crer , la mthode cration() de la
classe de contrle C_dossier est execute. Cette mthode appelle la mthode

crer_dossier(pat) de la classe entit Dossier . Or, cette mthode insre les donnes travers une autre mthode hrite de la classe classe persistante nomme execute_update(req) .
"file" Interface Dossier.java
"import"
"file" C_dossier.java
"import"
"file" Dossier.java
"file" C_recherche.java "import" "file" Interface Patient.java
hrite "import" "file" Patient.java "import"
"import"
"file" C_patient.java hrite
"table" DOSSIER
"file" Classe Persistante.java
"table" PATIENT
FigII.99 : Diagramme de composants des cas dutilisations prioritaires

Nous allons maintenant laborer un diagramme de composants gnrique, pour montrer la compilation dun fichier Java.
"file" Fichier.Java
"compile"
"file" Fichier.class
FigII.100 : Compilation dun fichier Java
Projet de fin dtude
109
II.5 Test :
Cette activit consiste tester les rsultats de limplmentation pour sassurer du bon droulement des fonctionnalits du systme. Lors de lvaluation des tests effectus, si nous dtectons une anomalie quelconque, nous devrions la corriger. Les tches excuter sont alors : La conception des tests. La ralisation des tests. Lvaluation des tests. La correction dventuelles anomalies. Les cas dutilisation implments jusque l sont les cas dutilisation prioritaires, voici leurs tests.
II.5.1-Test du cas dutilisation Crer patient :

Cette tche consiste crer un patient dans la base de donnes. Nous avons cr un patient fictif dont voici les attributs : CPAT NOM PRENOM ADRESSE TELEPHONE DATE_NAISSANCE NATIONALITE GENRE_ID NPIECE_ID 0257803 Belhadj Mohamed 26 rue Farhat Hachad Rades 71425678 21/10/1954 TUNISIENNE CIN 00254789
Le formulaire vierge tant affich, nous avons saisi les informations ci-dessus. En validant, le patient doit figurer dans notre base de donnes.
Projet de fin dtude
110
Nous avons vrifi lexistence dune ligne patient dont le code est 0257803 travers Oracle Entreprise Manager (application oracle dtaille dans lannexe (B). la vrification est russie.
II.5.2-Test du cas dutilisation Rechercher patient :

Lors de limplmentation de ce cas dutilisation, nous avons dcid de laisser la libert lutilisateur pour choisir le critre de recherche. Une fois le critre de recherche est dfini, lutilisateur doit prciser la valeur quil recherche. Nous avons alors, chercher diffrents patients selon tous les critres possibles. Les critres de recherche possibles sont : code patient, nom, prnom, date de naissance et pice didentification.
II.5.3-Test du cas dutilisation Crer dossier :

Comme pour le cas dutilisation crer un patient , pour tester ce cas dutilisation, nous avons cr un dossier, ensuite nous avons vrifi lexistence du dossier cr directement dans la base de donnes. La vrification est russie.
Conclusion :
Dans cette phase, nous avons termin de capturer tous les besoins des utilisateurs, analys tous les cas dutilisation et conu la plupart dentre eux. Le produit principal de cette phase est lincrment cration dun dossier patient . Ainsi, grce lactivit de conception de cette phase, nous pensons maintenant que larchitecture est suffisamment stable pour quelle puisse guider les deux prochaines phases : la construction et la transition.
Chapitre
(III)
La phase de construction
objectif de la phase de construction est daboutir un produit final, exploitable par les utilisateurs. Dans cette phase nous allons prsenter larchitecture matrielle mise en
place, construire le schma final de la base de donnes et implmenter les cas dutilisation nouveaux et secondaires et les tester.
III.1 Conception des nouveaux cas dutilisation identifis lors de la phase antrieure :
Projet de fin dtude
112
III.1.1- Conception de cas dutilisation Sidentifier :

III.1.1.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Sidentifier :
Interface identification
C_identification
Accs
Modle danalyse
trace
trace
<<boundary>> souris
<<boundary>> ecran
<<c ontrol>> C_identification

<<entity>> Accs
Modle de conception
<<boundary>> Interface identification

FigIII.1 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Sidentifier .
III.1.1.2- Diagramme de classes du modle de conception pour le cas dutilisation Sidentifier :
Projet de fin dtude
113
<<boundary>> souris
<<boundary>> Interface identification

Utilisateur
<<control>> C_identification
<<boundary>> ecran
<<entity>> Accs
FigIII.2 : Diagramme de classes du modle de conception pour le cas dutilisation

Sidentifier . III.1.1.3 - Diagramme de squence du modle de conception pour le cas dutilisation Sidentifier :
Projet de fin dtude
114
:ecran : Utilisateur
:clavier
:souris
:Interface identification
:C_identification
:Accs
afficher_interface_identification ()
afficher_interface_identification () interface_affiche
saisir_nom_usager (nu) saisir_mot_de_passe ( mp) identification (nu, mp) identifier_utilisateur (nu, mp) afficher_message_rsultat () message_visualis
FigIII.3 : Diagramme de squence du modle de conception pour le cas dutilisation

Sidentifier .1
III.1.2- Conception de cas dutilisation Paramtrer mdecins :

III.1.2.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer mdecins :
NU : Nom de lutilisateur. MP : Mot de passe de lutilisateur.
Projet de fin dtude
115
C_param
Mdecin
Modle danalyse
trace
<<c ontrol>> C_param
trace
Mdecin
<<boundary>> souris
<<boundary>> ecran
Modle de conception
<<boundary>> Interface paramtrage

FigIII.4: Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer mdecins .
III.1.2.2- Diagramme de classes du modle de conception pour le cas dutilisation Paramtrer mdecins :
<<boundary>> souris

<<control>> C_param
Administrateur
<<boundary>> clavier <<entity>> Mdecin <<boundary>> ecran

FigIII.5 : Diagramme de classes du modle de conception pour le cas dutilisation Paramtrer mdecins .
Projet de fin dtude
116
III.1.2.3 - Diagramme de squence du modle de conception pour le cas dutilisation Paramtrer mdecins :
:ecran : Administrateur
:clavier
:souris
:Interface paramtrage
C_param
:Mdecin
afficher_interface_paramtrage ()
afficher_interface_paramtrage () interface_affiche
clique_bouton_Paramtrer_mdecins afficher_interface_mdecin () afficher_interface_mdecin () interface_affiche paramtrer_mdecins ( med) paramtrage_mdecins ( med) paramtrer_mdecins ( med)

Paramtrer mdecins .2
III.1.3- Conception de cas dutilisation Paramtrer chambres :

III.1.3.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer chambres :
med : informations de lentit Mdecin paramtres par ladministrateur.
Projet de fin dtude
117
Modle danalyse
C_param
Chambre
trace
<<boundary> > souris
trace
<<c ontrol>> C_param
<<boundary>> ecran
<< entity>> Chambre

Modle de conception

FigIII.7 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer chambres .
III.1.3.2- Diagramme de classes du modle de conception pour le cas dutilisation Paramtrer chambres :

<<boundary>> souris
Administrateur
<<control>> C_param
<<boundary>> ecran
<<entity>> Chambre

Paramtrer chambres .
Projet de fin dtude
118
III.1.3.3 - Diagramme de squence du modle de conception pour le cas dutilisation Paramtrer chambres :
:clavier
:souris
C_param
:Chambre
afficher_interface_paramtrage () afficher_interface_paramtrage () interface_affiche
clique_bouton_Paramtrer_chambres afficher_interface_chambres () afficher_interface_chambres () interface_affiche paramtrer_chambres ( ch) paramtrage_chambres ( ch) paramtrer_chambres ( ch) afficher_message_rsultat () message_visualis

Paramtrer chambres .3
III.1.4- Conception de cas dutilisation Paramtrer cuisine :

III.1.4.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer cuisine :
ch : informations de lentit Chambre paramtres par ladministrateur.
Projet de fin dtude
119
C_param
Modle danalyse
Cuisine
trace
<<boundary>> souris
<< boundary>> ecran
trace
<<control>> C_param
<<entity>> Cuisine
(from Use Case V iew)
Modle de conception

FigIII.10 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer cuisine .
III.1.4.2- Diagramme de classes du modle de conception pour le cas dutilisation paramtrer cuisine :
<<boundary>> souris

Administrateur
<<control>> C_param
<<boundary>> ecran
<<entity>> Cuisine

Paramtrer cuisine .
Projet de fin dtude
120
III.1.4.3 - Diagramme de squence du modle de conception pour le cas dutilisation Paramtrer cuisine :
:clavier
:souris
C_param
:Cuisine
clique_bouton_Paramtrer_cuisine afficher_interface_cuisine () afficher_interface_cuisine () interface_affiche paramtrer_cuisine ( cui) paramtrage_cuisine ( cui) paramtrer_cuisine ( cui)

Paramtrer cuisine .4
III.1.5- Conception de cas dutilisation Paramtrer prestations :

III.1.5.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer prestations :
cui : informations de lentit Cuisine paramtres par ladministrateur.
Projet de fin dtude
121
C_param
Prestation
Modle danalyse
trace
trace
<<boundary>> souris
<<boundary>> ecran
<<control>> C_param
<<entity>> Prestation
Modle de conception

FigIII.13 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer prestations .
III.1.5.2- Diagramme de classes du modle de conception pour le cas dutilisation paramtrer prestations :
<<boundary>> souris

Administrateur
<<control>> C_param
<<boundary>> ecran

Paramtrer prestations .
Projet de fin dtude
122
III.1.5.3 - Diagramme de squence du modle de conception pour le cas dutilisation Paramtrer prestations :
:clavier
:souris
C_param
:Prestation
clique_bouton_Paramtrer_prestations afficher_interface_prestations() afficher_interface_prestations () interface_affiche paramtrer_prestations ( pre) paramtrage_prestations ( pre) paramtrer_prestations ( pre)

Paramtrer prestations .5
III.1.6- Conception de cas dutilisation Paramtrer conventions :

III.1.6.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer conventions :
pre : informations de lentit Prestation paramtres par ladministrateur.
Projet de fin dtude
123
(fro m Use Ca se Vie w)
C_param
Convention
Modle danalyse
trace
<<boundary>> souris
<<boundary>> ecran
trace
<< c ontrol>> C_param
<<entity>> Convention
Modle de conception

FigIII.16 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer conventions .
III.1.6.2- Diagramme de classes du modle de conception pour le cas dutilisation paramtrer conventions :
<<boundary>> souris
Administrateur
<<control>> C_param
<<boundary>> ecran

Paramtrer conventions .
Projet de fin dtude
124
III.1.6.3 - Diagramme de squence du modle de conception pour le cas dutilisation Paramtrer conventions :
:clavier
:souris
C_param
:Convention
clique_bouton_Paramtrer_conventions afficher_interface_conventions () afficher_interface_conventions () interface_affiche paramtrer_conventions ( co) paramtrage_conventions ( co) paramtrer_conventions ( co)

Paramtrer conventions .6
III.1.7- Conception de cas dutilisation Paramtrer fluides et appareillage :

III.1.7.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer fluides et appareillage :
co : informations de lentit Convention paramtres par ladministrateur.
Projet de fin dtude
125
C_param
Fluid_app
Modle danalyse
trace
<<boundary>> souris <<boundary>> ecran <<control>> C_param
trace
<<entity>> Fluid_app
Modle de conception

FigIII.19 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer fluides et appareillage .
III.1.7.2- Diagramme de classes du modle de conception pour le cas dutilisation paramtrer fluides et appareillage :
<<boundary>> souris

Administrateur
<<control>> C_param
<<boundary>> ecran <<entity>> Fluid_app
FigIII.20 : Diagramme de classes du modle de conception du cas dutilisation

Paramtrer fluides et appareillage .
Projet de fin dtude
126
III.1.7.3 - Diagramme de squence du modle de conception pour le cas dutilisation Paramtrer fluides et appareillage :
:clavier
:souris
C_param
:Fluid_app
clique_bouton_Paramtrer_fluides_et appareillage afficher_interface_fluides_et appareillage () afficher_interface_fluides_et appareillage () interface_affiche paramtrer_fluides_et appareillage ( fa) paramtrage_fluides_et appareillage ( fa) paramtrer_fluides_et appareillage ( fa) afficher_message_rsultat () message_visualis

Paramtrer fluides et appareillage .7
III.1.8- Conception de cas dutilisation Paramtrer tarifs accompagnant :

III.1.8.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer tarifs accompagnant :
fa : informations de lentit Fluid_app paramtres par ladministrateur.
Projet de fin dtude
127
C_param
Accompagnant
Modle danalyse
trace
<<boundary>> souris
<<boundary>> ecran
trace
<<control>> C_param
<<entity>> Accompagnant
Modle de conception

FigIII.22 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Paramtrer tarifs accompagnant .
III.1.8.2- Diagramme de classes du modle de conception pour le cas dutilisation paramtrer tarifs accompagnant :
<<boundary>> souris

Administrateur
<<control>> C_param
<<boundary>> ecran

Paramtrer tarifs accompagnant .
Projet de fin dtude
128
III.1.8.3 - Diagramme de squence du modle de conception pour le cas dutilisation Paramtrer tarifs accompagnant :
:clavier
:souris
C_param
:Accompagnant
clique_bouton_Paramtrer_tarifs_accompagnant afficher_interface_accompagnant () afficher_interface_accompagnant () interface_affiche paramtrer_tarifs_acc ( acc) paramtrage_tarifs_acc ( acc) paramtrer_tarifs_acc (acc) afficher_message_rsultat () message_visualis
FigIII.24 : Diagramme de squence du modle de conception pour le cas dutilisation Paramtrer tarifs accompagnant .8
III.1.9- Conception de cas dutilisation Enregistrer rglement :

III.1.9.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Enregistrer rglement :
acc : informations de lentit Accompagnant paramtres par ladministrateur.
Projet de fin dtude
129
Interface rglement
C_rglement
Rglement
Modle danalyse
trace
<<boundary>> souris <<boundary>> ecran <<control>> C_rglement
trace
<<entity>> Rglement
Modle de conception
<<boundary>> Interface rglement

FigIII.25 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Enregistrer rglement .
III.1.9.2- Diagramme de classes du modle de conception pour le cas dutilisation Enregistrer rglement :
<<boundary>> souris <<boundary>> Interface rglement
<<control>> C_rglement
Caissier
<<boundary>> ecran
<<entity>> Rglement
FigIII.26 : Diagramme de classes du modle de conception pour le cas dutilisation Enregistrer rglement .
Projet de fin dtude
130
III.1.9.3 - Diagramme de squence du modle de conception pour le cas dutilisation Enregistrer rglement :
:ecran : Caissier
:clavier
:souris
:Interface rglement
:C_rglement
:Rglement
afficher_interface_dition () afficher_interface_dition () interface_affiche
clique_bouton_Enregistrer_rglement afficher_interface_rglement () afficher_interface_rglement () interface_affiche
enregistrer_rglement (reg) enregistrement_rglement (reg) enregistrer_rglement (reg) message_visualis afficher_message_rsultat ()
FigIII.27 : Diagramme de squence du modle de conception pour le cas dutilisation Enregistrer rglement .9
III.1.10- Conception de cas dutilisation Passer un produit alimentaire une facture patient :
III.1.10.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Passer un produit alimentaire une facture patient :
reg : informations de lentit Rglement paramtres par ladministrateur.
Projet de fin dtude
131
Interface facturation prodalim

C_facture
Ligne_prodalim
Facture
trace
trace
<<entity>> Ligne_prodalim
<<boundary>> souris
<<boundary>> ecran
<<entity>> Facture
<<boundary>> Interface facturation prodalim

FigIII.28 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Passer un produit alimentaire une facture patient .
III.1.10.2- Diagramme de classes du modle de conception pour le cas dutilisation Passer un produit alimentaire une facture patient :
Projet de fin dtude
132
<<boundary>> souris
<<boundary>> Interface facturation prodalim

Secrtaire d'tage
<<boundary>> ecran <<entity>> Ligne_prodalim <<entity>> Facture

FigIII.29 : Diagramme de classes du modle de conception du cas dutilisation

Passer un produit alimentaire une facture patient .
III.1.10.3 - Diagramme de squence du modle de conception pour le cas dutilisation Passer un produit alimentaire une facture patient :
Projet de fin dtude
133
:clavier
:souris
:Interface facturation prodalim
:C_facture
:Ligne_prodalim
:Facture
afficher_interface_facturation_prodalim () afficher_interface_facturation_prodalim () interface_affiche
ajouter_prodalim ( cpa, num_dos, quantit) ajout ( cpa, num_dos, quantit) ajouter_prodalim ( cpa, num_dos, quantit)
mise__jour ( mtpa, rubrique, num_dos) afficher_message_rsultat () message_visualis

Passer un produit alimentaire une facture patient .10
III.1.11- Conception de cas dutilisation Enregistrer accompagnant :

III.1.11.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Enregistrer accompagnant :
10
cpa : code produit alimentaire. mtpa : montant du produit alimentaire ajouter. rubrique : cest la rubrique de la facture o doit figurer le produit alimentaire en question.
Projet de fin dtude
134
Interface accompagnant
(f rom Use Case Vi ew)
C_accompagnant
Accompagnant
Modle danalyse
trace
<<boundary>> souris <<boundary>> ecran
trace
<<c ontrol>> C_accompagnant
Modle de conception
<<boundary>> Interface accompagnant

FigIII.31 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Enregistrer accompagnant .
III.1.11.2- Diagramme de classes du modle de conception pour le cas dutilisation Enregistrer accompagnant :
<<boundary>> souris
<<boundary>> Interface accompagnant

<<control>> C_accompagnant
Secrtaire d'tage
<<boundary>> ecran

Enregistrer accompagnant .
Projet de fin dtude
135
III.1.11.3 - Diagramme de squence du modle de conception pour le cas dutilisation Enregistrer accompagnant :
:ecran :clavier :souris : Interface accompagnant :C_accompagnant :Accompagnant
: Secrtaire d'tage
afficher_interface_accompagnant ()
afficher_interface_accompagnant () interface_affiche
enregistrer_acc ( num_dos, nbr) enregistrement_acc ( num_dos, nbr) afficher_message_rsultat () message_visualis enregistrer_acc ( num_dos, nbr)
FigIII.33 : Diagramme de squence du modle de conception pour le cas dutilisation Enregistrer accompagnant .11
III.1.12- Conception de cas dutilisation Passer un fluide ou un appareillage une facture patient :
III.1.12.1- Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Passer un fluide ou appareillage une facture patient :
nbr : nombre daccompagnants . Il est important de signaler que les noms daccompagnants nont aucune utilit pour notre systme et cest uniquement leur nombre qui nous importe.
11
Projet de fin dtude
136
Interface facturation
C_facture
Ligne_fluid_app
Facture
Modle danalyse
trace
trace
<<entity>> Ligne_fluid_app
<<boundary>> souris
<<boundary>> ecran
<<entity>> Facture
Modle de conception
<<boundary>> Interface facturation fluid_app

FigIII.34 : Traabilit entre le modle danalyse et le modle de conception pour le cas dutilisation Passer un fluide ou appareillage une facture patient .
III.1.12.2- Diagramme de classes du modle de conception pour le cas dutilisation Passer un fluide ou appareillage une facture patient :
<<boundary>> souris
<<boundary>> Interface facturation fluid_app

Secrtaire d'tage
<<boundary>> ecran <<entity>> Ligne_fluid_app <<entity>> Facture


Passer un fluide ou appareillage une facture patient .
Projet de fin dtude
137
III.1.12.3 - Diagramme de squence du modle de conception pour le cas dutilisation Passer un fluide ou appareillage une facture patient :
:clavier
:souris
:Interface facturation fluid_app
:C_facture
:Ligne_fluid_app
:Facture
afficher_interface_facturation_fluid_app () afficher_interface_facturation_fluid_app () interface_affiche
ajouter_fluid_app( cfa, num_dos, quantit) ajout ( cfa, num_dos, quantit) ajouter_fluid_app ( cfa, num_dos, quantit)
mise__jour ( mtfa, rubrique, num_dos) afficher_message_rsultat () message_visualis

Passer un fluide ou appareillage une facture patient .12
III.2 Implmentation :
Au cours de cette phase, nous poursuivons la construction du schma de la base de donnes et limplmentation des cas dutilisation restants.
III.2.1- Construction du schma final de la base de donnes :

III.2.1.1-Description et diagramme des classes entits importantes :
On entend par classes entits importantes, les classes entits qui proviennent de la conception des cas dutilisation secondaires et nouveaux et qui peuvent figurer dans le diagramme des classes. En effet, dans la conception, nous avons
12
cfa : code du fluide ou appareillage. mtfa : montant du fluide ou appareillage ajouter . rubrique : cest la rubrique o doit figurer le fluide ou appareillage en question.
Projet de fin dtude
138
anticip la construction de la base de donnes en mentionnant les entits Ligne_prestation , Ligne_prodalim , Ligne_produit , Ligne_fluid_app . Ces entits sont en fait des classes-associations entre la classe entit Facture et chacune des entits Prestation , Cuisine , produit et Fluide_app .
Description de la classe entit Patient :

En poursuivant la conception des cas dutilisation secondaires, des nouvelles mthodes mergent. Elles sont dcrites dans le tableau ci-dessous.
Mthodes
modifier_patient supprimer_patient
Type retourn
boolen boolen
paramtres
Patient pat String codep
Description de la classe entit Dossier : Mthodes

modifier_dossier supprimer_dossier rechercher_dossier
Type retourn
boolen boolen Dossier
paramtres
Dossier dos String num_dos String critre, String var
Description de la classe entit Facture : Mthodes

mise__jour gnrer_facture extraire_facture
Type retourn
boolen void Facture
paramtres
String mt, String rubrique, String num_dos String num_dos, Float mtsjour String num_dos
Description de la classe entit Accs :
Projet de fin dtude
139
Accs Attributs
NP MP
Libell
Nom dutilisateur Mot de passe String String
Type
Mthodes
identifier_utilis ateur
Type retourn
boolen
paramtres
string nu, string mp
Description de la classe entit Mdecin : Mdecin Attributs

CM NOM PRENOM ADRESSE TELEPHONE SPECIALITE
Libell
Code mdecin Nom du mdecin Prnom du mdecin Adresse du mdecin Tlphone du mdecin Spcialit du mdecin String String String String String String
Type
Mthodes
paramtrer_mdeci ns
Type retourn
boolen
paramtres
Mdecin med
Description de la classe entit Chambre : Chambre Attributs

CCH ETAT
Libell
Code de la chambre Etat doccupation String String
Type
Mthodes
paramtrer_chambr es
Type retourn
boolen
paramtres
Chambre ch
Description de la classe entit Cuisine :
Projet de fin dtude
140
Cuisine Attributs
CCS DESIGNATION PRIX
Libell
code produit alimentaire Dsignation du code produit alimentaire prix du produit alimentaire String String String
Type
Mthodes
paramtrer_cuisine
Type retourn
boolen
paramtres
Cuisine cui
Description de la classe entit Prestation :
Prestation Attributs
CP DESIGNATION COEFFICIENT NOMBRE
Libell
Code prestation Dsignation du code prstation Coefficient de la prestation Nombre String String String String
Type
Mthodes
paramtrer_presta tions
Type retourn
boolen
paramtres
Prestation pre
Description de la classe entit Convention :
Projet de fin dtude
141
Convention Attributs
CC ORGANISATION CONVENTION R_SEJOUR R_ANALYSE R_RADIO
Libell
Code convention Organisation Convention Remise sur sjour Remise sur analyse Remise sur radio String String String Float Float Float
Type
Mthodes
paramtrer_conven tions
Type retourn
boolen
paramtres
Convention co
Description de la classe entit Fluide_app : Fluide-app Attributs

CF DESIGNATION UNITE PRIX
Libell
Code fluide/appareil Dsignation fluide/appareill. Unit de mesure du fluide/appaeill. Prix du fluide/appareill. String String String Float
Type
Mthodes
paramtrer_fluid _app
Type retourn
boolen
Paramtres
fluide_app fa
Description de la classe entit Accompagnant :
Projet de fin dtude
142
Accompagnant Attributs
ND DATE_E NOMBRE
Libell
Code du dossier du patient accompagn date dentre de/des (l) accompagnant(s) Nombre des accompagnants String Date Integer
Type
Mthodes
paramtrer_tarifs _acc enregistrer_acc
Type retourn
boolen boolen
Paramtres
Accompagnant acc string num_dos, integer nbr
Description de la classe entit Rglement : Rglement Attributs

ND MONTANTTTC MODE_PAYEMENT
Libell
Code dossier Montant TTC rgler Mode du payement String Float String
Type
Mthodes
enregistrer_rgle ment
Type retourn
boolen
Paramtres
Rglement reg
Description de la classe entit Catgorie_CH : Catgorie_CH Attributs

CATEGORIE PRIX
Libell
Catgorie de chambres Prix de la nuite String Float
Type
Mthodes
extraire_prix Float
Type retourn
Paramtres
String categorie
Projet de fin dtude
143
NB : Les chambres de la polyclinique ne sont pas toutes de la mme catgorie, on

distingue trois grands types : normal , VIP et ranimation . Nous avons fait cette distinction, car dune catgorie une autre, le prix de la nuite change, do lintrt de lentit Catgorie_CH qui assigne toute catgorie de chambre un prix de nuite.
Description de la classe entit Tarif : Tarif Attributs

COEFFICIENT TYPE_PRESTATION TVA PRIX
Libell
Coefficient dun type de prestation Designation du type prestation TVA du type prstation Prix du coefficient String String Float Float
Type
Mthodes
extraire_prix Float
Type retourn
Paramtres
String coefficient
NB :
lentit tarif est lentit des types de prestations , les types de prestation sont
analyses , radios et oprations de coefficients respectivement B , R et K . Ces coefficients ont chacun un prix unitaire. Lintrt de cette entit est dassigner chaque coefficient (type de prestation) un prix unitaire. Ensuite pour dterminer le prix dune prestation, on multiplie son nombre par le prix unitaire de son coefficient.
Le diagramme de classes suivant reprsente les associations entre toutes les classes entits du systme, dcrites lors de la phase courante et la phase antrieure.
Projet de fin dtude
144
entity Tarif
<<entity>> Rglement
<<entity>> Patient
1 0..n 1 1 1..n
<<entity>> Tarif
0..1
1 1..n
<<entity>> Dossier
1..n 1..n 1
1..n
<<entity>> Mdecin
0..n
Ligne_prestation
1 1 0..n 1 0..n 0..n

<<entity>> Chambre
<<entity>> Cuisine
1 0..n
Ligne_prodalim
0..n
<<entity>> Facture
1..n
1 Catgorie_CH
<<entity>>
0..n
0..n
Sejour
0..n 0..n
<<entity>> Produit
Ligne_produit
Ligne_fluid_app
<<entity>> Fluid_app
<<entity>> Accs
FigIII.37 : Diagramme de classes final
Les rgles de passage du diagramme de classes vers la base de donnes, ainsi que les rgles de normalisation tant dj prsents dans la phase dlaboration, lors de lactivit dimplmentation, nous allons tablir alors le schma final de la base de donnes travers le diagramme de classes cidessus.
III.2.1.2-Schma final de la base de donnes :

Voici le schma final de la base de donnes, reprsent sous forme de tableaux. Notons bien que les trois tables Patient , Dossier et Facture ont t dj reprsentes dans la phase dlaboration.
Projet de fin dtude
145
Description de la table Accs : Accs Colonne

NP MP
Libell
Nom dutilisateur Mot de passe
Type
VARCHAR VARCHAR
Contraintes
Cl primaire Cl primaire
Description de la table Mdecin : Mdecin Colonne

CM NOM PRENOM ADRESSE TELEPHONE SPECIALITE
Libell
Code mdecin Nom du mdecin Prnom du mdecin Adresse du mdecin Tlphone du mdecin Spcialit du mdecin
Type
VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR
Contraintes
Cl primaire
Description de la table Chambre : Chambre Colonne

CCH CATEGORIE ETAT
Libell
Code de la chambre Catgorie de la chambre Etat doccupation
Type
VARCHAR VARCHAR VARCHAR
Contraintes
Cl primaire
Description de la table Cuisine :
Projet de fin dtude
146
Cuisine Colonne
CCS DESIGNATION PRIX
Libell
code produit cuisine Dsignation du code produit alimentaire prix du produit alimentaire
Type
VARCHAR VARCHAR VARCHAR
Contraintes
Cl primaire
Description de la table Prestation : Prestation Colonne

CP DESIGNATION COEFFICIENT NOMBRE
Libell
Code prestation Dsignation du code prestation Coefficient de la prestation Nombre
Type
VARCHAR VARCHAR VARCHAR VARCHAR
Contraintes
Cl primaire
Description de la table Convention : Convention Colonne

CC ORGANISATION CONVENTION R_SEJOUR R_ANALYSE R_RADIO
Libell
Code convention Organisation Dsignation Remise sur sjour Remise sur analyse Remise sur radio
Type
VARCHAR VARCHAR VARCHAR FLOAT FLOAT FLOAT
Contraintes
Cl primaire
Description de la table Fluide_app :
Projet de fin dtude
147
Fluide-app Colonne
CF DESIGNATION UNITE PRIX
Libell
Code fluide/appareil Dsignation fluide/appareill. Unit de mesure du fluide/appaeill. Prix du fluide/appareill.
Type
VARCHAR VARCHAR VARCHAR FLOAT
Contraintes
Cl primaire
Description de la table Accompagnant : Accompagnant Colonne

ND DATE_E NOMBRE
Libell
Code du dossier du patient accompagn date dentre de/des (l) accompagnant(s) Nombre des accompagnants
Type
VARCHAR DATE NUMBER
Contraintes
Cl trangre
Cl primaire
Description de la table Rglement : Rglement Colonne

ND MONTANTTTC MODE_PAYEMENT
Libell
Code dossier Montant TTC rgler Mode du payement
Type
VARCHAR FLOAT VARCHAR
Contraintes
Cl primaire
Description de la table Ligne_perstation :
Projet de fin dtude
148
Colonne
ND CP DATEF HEURE QUANTITE PRIX NB
Ligne_prestation Libell
Code Dossier Code prestation Date de facturation Heure de facturation Quantit de prestation Prix unitaire prestation Numro du bon
Type
VARCHAR VARCHAR DATE VARCHAR NUMBER FLOAT VARCHAR
Contraintes
Cl trangre Cl trangre Cl primaire Cl primaire
Unique
Description de la table Ligne_produit : Ligne_produit Colonne

ND CPDT DATEF HEURE QUANTITE PRIX NB
Libell
Code Dossier Code produit Date de facturation Heure de facturation Quantit de produit Prix unitaire dun produit Numro du bon
Type
VARCHAR VARCHAR DATE VARCHAR NUMBER FLOAT VARCHAR
Contraintes
Cl trangre Cl trangre Cl primaire Cl primaire
Unique
Description de la table Ligne_prodalim :
Projet de fin dtude
149
Ligne_prodalim Colonne
ND CCS DATE_F HEURE_F QUANTITE NB
Libell
Code dossier Code du produit alimentaire
Type
VARCHAR VARCHAR DATE VARCHAR NUMBER VARCHAR
Contraintes
Cl trangre Cl trangre Cl primaire Cl primaire Unique
Description de la table Sjour : Sjour Colonne

ND CCH DATE_E HEURE_E
Libell
Code dossier Code du produit alimentaire
Type
VARCHAR VARCHAR DATE VARCHAR
Contraintes
Cl trangre Cl trangre Cl primaire
Description de la table Catgorie_CH : Catgorie_CH Colonne

CATEGORIE PRIX
Libell
Catgorie de chambres Prix de la nuite
Type
VARCHAR FLOAT
Contraintes
Cl primaire
Description de la table Tarif :
Projet de fin dtude
150
Tarif Colonnes
COEFFICIENT TYPE_PRESTATION TVA PRIX
Libell
Coefficient dun type de prestation Dsignation du type prestation TVA du type prestation Prix du coefficient
Type
VARCHAR VARCHAR FLOAT FLOAT
Contraintes
Cl primaire
III.2.2- Architecture matrielle mise en place :

Larchitecture que nous allons utiliser est larchitecture clients-serveur. Nous avons espr rpartir lapplication sur une architecture multi-niveaux, mais la contrainte de temps nous en a empch, vu la complexit du systme construire. Larchitecture clients-serveur implique que lapplication rside sur le PC Client alors que la Base de Donnes est hberge sur un serveur situ quelque part dans lentreprise. Dans ce qui suit, un schma qui clarifie la situation :
Projet de fin dtude
151
FigIII.38: Architecture clients-serveur
Voici le diagramme de dploiement qui reprsente la rpartition physique des micro-ordinateurs clients, contenant chacun une copie de lapplication, et le serveur de donnes.
Projet de fin dtude
152
PC Pharmacie PC Facturation PC Recouvrement
Le PC du service informatique est physiquement prs du serveur.
PC Informatique Serveur de base de donnes
PC Etage 1
PC Etage 4
PC Etage 2
PC Etage 3
FigIII.39 : Diagramme de dploiement
III.2.3- Implmentation des cas dutilisation secondaires et nouveaux:

Le travail dimplmentation est un travail pratique. Il sagit dimplmenter les mthodes dgages lors de lactivit de conception dans la phase courante et prcdente. Nous avons prfr de ne pas entrer dans les dtails techniques, et de donner plutt une ide gnrale sur les fichiers physiques (qui sont logiquement des classes Java) travers le diagramme de composants. Nous allons traiter un cas dutilisation gnrique, car la structure du travail dimplmentation se rpte pour tous les cas dutilisation. Pour tout cas dutilisation de notre systme, les classes dgages sont toujours les suivantes : Une seule classe interface utilisateur.
Projet de fin dtude
153
Une seule classe de contrle. Une classe entit ou plus. Limplmentation de tous les cas dutilisation du systme passent par ces tapes : Implmentation de la classe persistante : il sagit dcrire les lignes de code qui permettent, par hritage, toutes les classes entit daccder la base de donnes. Trois sous-tapes nous faut pour le russir ; lenregistrement du driver de connexion (pour notre un cas objet sun.jdbc.odbc.JdbcOdbcDriver()), ensuite laffectation
connection de la connexion au pilote ODBC adquat et enfin la dfinition dun objet Statement qui nous permettra de manipuler les donnes. Implmentation des classes entit : les classes entit hritent de la classe persistante, on doit le mentionner dans la spcification de la classe (public class Xxxxxx extends Persistent {-------}). Ces classes, comme nous les avons dj dcrites, ont des attributs et des mthodes. Ces proprits doivent tre implmentes suivant leurs conceptions. Implmentation des classes de contrle : les classes contrles instancient les classes entit pour manipuler les donnes. Ce sont les classes importantes, car ils reprsentent une intermdiaire entre lutilisateur (linterface utilisateur) et les donnes dont ce dernier a besoin. Implmentation des classes interfaces utilisateurs : Les classes interfaces ncessite un double travail ; un travail graphique o il sagit de dessiner les contrles qui dclenchent divers vnements, et un travail textuel o il sagit dcrire le code relatif. Pour ce dernier travail, on doit instancier la classe de contrle convenable pour, gnralement, utiliser ses mthodes dans les vnements des contrles de la classe. Exemple : un clic sur le bouton rechercher dclenche la mthode rechercher (param) de la classe de contrle, dj instancie dans la classe interface. Voici un diagramme de composants gnrique, qui clarifie ce que nous venons dexpliquer : on suppose que la conception dun cas dutilisation nomm paramtrage a dgag la classe interface Interface
Projet de fin dtude
154
paramtrage , la classe de contrle contrle paramtrage et les deux classes entits Chambre et Catgorie .
"file" Interface paramtrage.java
"import"
"file" Contrle paramtrage.java
"import"
"import"
"file" Chambre.java
"table" CATEGORIE
"file" Catgorie.java
"hrite"
"hrite"
"file" Classe persistante.java
"table" CHAMBRE
FigIII.40 : Diagramme de composants du cas dutilisation
Paramtrage
III.3 Test :
Prsentons maintenant les tests effectus sur le reste des cas dutilisation dj implments pour pouvoir les valuer.
NB :
nous jugeons inutile de prsenter le test du cas dutilisation Rechercher un
dossier patient puisquil est identique celui du cas dutilisation Rechercher un patient effectu lors de la phase antrieure.
III.3.1-Test du cas dutilisation Modifier un patient :

Pour modifier un patient, il faut procder tout dabord sa recherche. Vu que nous avons conu un cas dutilisation Rechercher un patient
Projet de fin dtude
155
indpendamment, nous supposons que cette recherche soit fructueuse (le patient a t trouv) et que la modification est possible. Une fois le formulaire du patient est rempli, nous procdons la modification de tous les champs, ensuite nous vrifions la russite ou non de la mise jour directement partir de la base de donnes.
III.3.2-Test du cas dutilisation Supprimer un patient :

Idem pour ce cas dutilisation, qui doit tre prcd par la recherche. Le formulaire propre au patient supprimer est visualis et une bote de dialogue saffiche nous demandant de confirmer la suppression. Un message sera alors visualis nous informant du succs ou de lchec de cette opration. Si le message est positif, nous vrifions la suppression du patient manuellement , c d directement de la base de donnes.
III.3.3-Test du cas dutilisation Editer facture patient :

Pour pouvoir diter la facture patient, il faut saisir le numro du dossier (numro de la facture) correspondant du patient en question. La facture sera alors gnre automatiquement et un ordre dimpression est lanc limprimante. Les montants des rubriques de la facture gnre doivent tre correctes, nous devons les vrifier manuellement.
III.3.4-Test du cas dutilisation Sidentifier :

Chaque utilisateur possde un nom dutilisateur et un mot de passe. Le nom dutilisateur est commun tous les utilisateurs dun mme groupe (les facturiers, les rceptionnistes, les secrtaires dtages etc.). Quant au mot de passe, il est propre chaque utilisateur. Prenons lexemple dun facturier ayant comme nom dutilisateur facturier et comme mot de passe mab . Si lune de ces deux variables est fausse, la connexion au systme impossible. est
III.3.5-Test des cas dutilisation de paramtrage :
Projet de fin dtude
156
Les cas dutilisation de paramtrage sont presque tous implments de la mme faon. Nous avons dcid alors, de dcrire un seul test qui sera valable pour tous. Le paramtrage consiste en la mise jour dune ou de plusieurs valeurs. Prenons lexemple de la mise jour dun coefficient. Il sagit gnralement de la mise jour du prix unitaire. Par exemple un B cotait deux cents millimes, aprs la mise jour il cote deux cents vingt millimes. Pour tester la russite ou non de cette opration, nous devons visualiser le changement du prix dans la base de donnes. Si le test est ngatif, la rpercussion sera un peu lourde, car dans ce cas, toutes les prestations analyses auront un prix erron.
III.3.6-Test des cas dutilisation de passations des biens et des services :

L il sagit l dun double test : Aprs chaque passation, un test pour vrifier si le code du service ou du bien factur, le code dossier du patient, la date et lheure de facturation existent dans la table convenable (ligne_prestation, ligne_produit, ligne_fluide). Un deuxime test pour vrifier si la mise jour de la rubrique convenable dans la facture est mise jour ou non.
III.3.7-Test du cas dutilisation Enregistrer accompagnant :

Aprs une collecte dinformations propos de ce cas dutilisation, nous avons su que le nom de laccompagnant nimporte pas pour la polyclinique. Les informations saisir, comme nous lavions dj cites, sont ; le code dossier du patient accompagn, la date dentre de (ou des) accompagnant(s) et le nombre daccompagnants (gnralement un seul). Lenregistrement dun accompagnement consiste crer une ligne constitue des trois informations cites, dans la table accompagnant . Le seul test effectuer est celui de vrifier lexistence dune ligne introduite par le logiciel dvelopp, dans la base de donnes.
Projet de fin dtude
157
Conclusion :
Dans la phase de construction, nous avons achev limplmentation et les tests de tous les cas dutilisation, tout en respectant la conception labore. En dautres termes, nous dtenons la version finale du logiciel, installe dans notre environnement de dveloppement. La phase prochaine consistera installer le systme dans lenvironnement des utilisateurs.
Chapitre
(IV)
La phase de transition
En effet, le fait que nous avons dvelopp lapplication au mme endroit o se trouvaient les utilisateurs, nous a permis de tester lapplication au fur et mesure de sa construction. Les tests de lapplication sont de deux sortes, la vrification et la validation. La vrification consiste vrifier que le rsultat correspond la spcification. La validation consiste vrifier que le rsultat correspond vraiment ce que voulait lutilisateur.
e produit logiciel construit au terme de la phase antrieure tant valid et vrifi, La phase de transition consistera tout simplement installer lapplication dans lenvironnement des utilisateurs.
Projet de fin dtude
La phase de transition
159
Comme nous lavons signal dans lavant-propos, notre application de facturation est en fait un module dun logiciel de gestion de polyclinique. Ce systme comprend deux autres modules qui sont ; la gestion de la pharmacie et la gestion du personnel. Pour mettre en place lapplication, il faut que tous les modules soient prts, ce qui nest sincrement pas le cas jusqu ce moment. Cependant nous avons planifi ds le dbut que larchitecture du rseau sera de type clients-serveur. Le serveur contient seulement les donnes, nous y installerons donc Oracle 9i Server, ensuite nous exporterons la base de donnes de lenvironnement de dveloppement (nos micro-ordinateurs), lenvironnement des utilisateurs (le serveur). Chacun des micro-ordinateurs clients doit squiper dune copie de lapplication dveloppe. Lapplication tant teste par les responsables informatiques de la polyclinique, tous les risques sont carts et il sagira ensuite, de migrer les donnes du systme actuel de la polyclinique (application sur AS/400 dveloppe avec le GAP) vers la nouvelle base de donnes. Pour conclure cette phase, nous signalons que les ambitions des responsables informatiques ne sarrtent pas l, car ils envisagent plus tard, de passer une architecture trois-niveaux avec un serveur de donnes, un serveur dapplication et des micro-ordinateurs lgers , quips simplement dun navigateur WEB.
Conclusion Gnrale
a phase de conception du projet a dur plus que nous lavions prvue. En effet, il lui a fallu deux mois et demi, pour analyser le contexte auquel sattache notre travail et concevoir le futur systme. La tche
qui nous a embarrass le plus, consistait lapplication conforme du cycle de vie du processus unifi. La libert que nous a accorde ce processus (un processus gnrique) sest convertie en lourde responsabilit, la responsabilit daccomplir les bons choix. Si nous laborons un rsum global du mmoire, nous parlerons de quatre grandes phases :
Projet de fin dtude
Conclusion Gnrale
161
Linception, appele aussi incubation, a dur un mois. Pendant ce mois, il nous tait demand dassimiler le contexte du travail accomplir. La direction de la polyclinique nous a permis dexplorer le systme existant pendant une semaine. Accompagns par un agent de saisie informatique, nous avons russi dgager les points forts et faibles du systme. Ses points forts rsidaient tout simplement dans le fait quil rpond efficacement aux besoins des utilisateurs. Ses points faibles consistaient en la saisie de la mme information plusieurs fois, et en lutilisation excessive et exagre des codes. En effet les agents de saisie doivent tre en mesure dapprendre tous les codes dont ils ont besoin, sinon ils seront gns de les vrifier chaque opration. En plus de a, un nouvel employ doit passer une bonne priode, au cours de laquelle il doit apprendre plusieurs codes, avant de pouvoir utiliser aisment le systme actuel. Le dgagement des grandes fonctionnalits du systme existant na pas suffi pour aborder la phase de conception, il fallait dgager plus de besoins. Alors, il nous a fallu parler avec les acteurs du systme dinformations de la polyclinique pour enrichir notre modle initial de cas dutilisation. Et l nous nous tions confronts un problme dlicat : la dissimulation de linformation. La solution rside dans le processus unifi lui mme, et consiste au prototypage. Il fallait construire des interfaces prototypes et les prsenter aux personnes utilisant le systme actuel. Quatre jours taient indispensables pour construire des interfaces prototypes avec VB6 (Visual Basic 6.0 le langage que nous matrisons le plus). La solution tait merveilleusement brillante puisque ds que les acteurs ont vu les prototypes, toutes nos questions taient devenues moins difficiles quauparavant. Les lments livrer au terme de la phase dinception (acteurs, besoins et risques) tant dtermins, nous pouvions passer la phase suivante. La phase dlaboration a dur un mois, au cours duquel nous avons essay de stabiliser larchitecture du systme en enchanant les cinq activits gnriques. En effet, il sagissait de formuler, daffiner et danalyser la plupart des cas dutilisations, den concevoir une grande partie et dimplmenter les cas dutilisations prioritaires qui ont t dtermins lors de la premire phase.
Projet de fin dtude
Conclusion Gnrale
162
Ensuite nous avons entam la phase de construction. Dans cette phase, nous avions dj un modle final de cas dutilisations. Tous les cas dutilisation sont analyss et la plupart conus. Il sagissait alors de concevoir, dimplmenter et de tester le reste des cas dutilisation. Llment principal livrer au terme de cette phase est la premire version excutable du systme. Enfin nous tions arrivs la dernire phase du processus unifi, la phase de transition, o il sagissait dajuster des dtails mineurs du logiciel afin davoir la version finale et prte lutilisation. Une fois cette version est prte, nous avons install la base de donnes et lapplication dans lenvironnement des utilisateurs. Nous souhaitons que lapplication dveloppe sera aussi utile la polyclinique quelle fut pour nous, En fait, la fin de la ralisation de ce mmoire, nous avions accumul une masse importante de connaissances aussi bien sur le plan thorique que sur le plan pratique et que nous jugeons trs utile pour lavenir dune carrire professionnelle.
Annexe
(A)
Le Processus unifi et UML
endant plusieurs dcennies, le monde informatique a toujours rv dun processus qui puisse garantir le dveloppement efficace de logiciels de qualit, valable quelque soit la grandeur et la complexit du projet, et
prsentant de bonnes pratiques adaptes la mthode en question, surtout que, de nos jours, les logiciels demands sont de plus en plus imposants et exigeants quauparavant. Le processus unifi semble tre la solution idale pour remdier lternel problme des dveloppeurs. En effet, il regroupe les activits mener pour transformer les besoins dun utilisateur en un systme logiciel quelque soit la classe, la taille et le domaine dapplication de ce systme.
Projet de fin dtude
Annexe (A)
164
Le systme logiciel, selon notre processus, est un ensemble de composants, relis les uns aux autres par des interfaces dfinies. Le processus unifi utilise le langage UML (Unified Modeling Language). Ce langage de modlisation est une partie intgrante du processus unifi, ils ont t dailleurs dvelopps de concert. Essayons tout dabord de prsenter UML, car ses diagrammes sont utiliss dans chaque phase et activit du processus unifi, ensuite nous reviendrons sur la prsentation du processus unifi.
I - Unified Modeling Language :

I.1 Lapproche Oriente Objet :
Lapproche oriente objet est caractrise par trois notions fondamentales et indispensables qui sont lencapsulation, lhritage et le polymorphisme. Le phnomne dencapsulation sera clair lors de la prsentation des notions dobjet et de classe. Lhritage et le polymorphisme seront prsents par la suite. Il existe dautres notions qui caractrisent la POO : labstraction, lagrgation
La notion dobjet
On ne peut pas parler dUML sans parler de lapproche oriente objet. Dans la plupart des langages traditionnels (structurs), les traitements ont une vue limite sur les donnes sur lesquelles ils sappliquent. Alors que dans les langages de POO, un objet encapsule des informations et des comportements : Les informations sont les donnes portes par lobjet, on les nomme attributs. Les comportements sont les traitements applicables cet objet, on les nomme mthodes [1]. Prenons lexemple de lobjet voiture , cet objet peut avoir les attributs suivants : Immatriculation Marque
Projet de fin dtude
Annexe (A)
165
Couleur Propritaire Une voiture peut changer de couleur ou de propritaire, cet objet peut alors avoir les mthodes suivantes changerCouleur(couleur) et changerProprietaire(personne).
La notion de classe
Pour grer lencapsulation, tous les objets ayant les mmes proprits (attributs et mthodes) sont rassembls dans une famille. Une famille est une classe, les objets quelles rassemblent sont les instances. Les objets dune mme classe portent tous les attributs de leur classe, ces attributs peuvent avoir des valeurs diffrentes suivant les instances. En revanche, toutes les instances partagent les comportements dfinis dans la classe [1].
Instance 1 : Immatriculation : RHJ 233 Marque : Volvo Couleur : Bleu fonc Propritaire : Mr XXXX
Classe Voiture Attributs : - Immatriculation - Marque - Couleur - Propritaire Mthodes : - changerCouleur(c) - changerPropritaire(p)
Instance 2 : Immatriculation : BHD 735 Marque : Audi Couleur : Gris mtallis Propritaire : Mme YYYY
Fig. A.1 : La classe voiture et ses instances.
Lhritage :
Projet de fin dtude
Annexe (A)
166
Cest un mcanisme par lequel on dfinit une classe comme tant le cas particulier dune classe plus gnrale. En plus des mthodes et des attributs dont elles hritent, les sous-classes peuvent dfinir leurs propres mthodes et attributs. Hritage simple : une classe hrite les attributs et les mthodes dune seule classe mre.
Compte bancaire
Compte dpargne Fig. A.2 : Hritage simple.
Compte courant
Hritage multiple : une classe hrite les attributs et les mthodes de plusieurs classes mres. Mammifre
Herbivore
Carnivore
Homme Fig. A.3 : Hritage multiple.
Le polymorphisme :
Cest la possibilit pour un mme message de dclencher des traitements diffrents, suivant les objets auxquelles il est adress. Le mcanisme de polymorphisme permet donc de donner le mme nom des traitements diffrents [1].
Projet de fin dtude
Annexe (A)
167
Prenons lexemple simple de la mthode Min qui retourne un boolen. Cette mthode peut avoir comme paramtres deux entiers comme elle peut avoir deux chanes de caractres. On peut galement surcharger une mthode, c d ne pas fixer le nombre de ses paramtres. Exemple : la mthode somme qui retourne la somme dentiers peut tre appele de cette manire : somme(11,7) ou somme(15,2,9).
Labstraction :
Un objet est caractris par des donnes et des traitements, mais il est aussi caractris par une partie prive, une partie publique et une partie protge. Labstraction dfinit la visibilit et laccessibilit des attributs et mthodes : Publique : accessibilit toutes les classes. Protge : accessibilit limite la classe et ses ventuelles sousclasses. Prive : accessibilit limite seulement la classe [1]. Ceci dit, une classe abstraite est une classe qui ne peut avoir aucune instance directe, elle permet dorganiser un ensemble de classes de mme nature. Son rle est de factoriser un certain nombre de caractristiques dans le but de les spcialiser par la suite. La classe abstraite doit avoir des sous-classes concrtes ou abstraites. Uniquement les sous-classes concrtes peuvent tre instancies.
Lagrgation :
Cest une forme spciale dassociation qui relie deux classes, et qui permet de montrer quune classe est une partie intgrante dune autre classe. Cest une relation compos-composant. Il existe deux types dagrgations :
Projet de fin dtude
Annexe (A)
168
Agrgation par valeur : la dure de vie de la classe compose et celles des classes composantes sont dpendantes c d que si la classe compose est supprime, les classes composantes doivent tre supprimes. Agrgation par rfrence : la dure de vie de la classe compose et celles des classes composantes sont indpendantes.
I.2 La notation UML :

UML a t labor par trois mthodologistes, James Rambaugh, Grady Boosh et Ivar Jackobson, de la socit Rational. Soumise en janvier 1997 lOMG (Object Management Group) dans le cadre de la standardisation des mthodes des mthodes danalyse et de conception oriente objet, la version 1.0 dUML a trs vite obtenu le ralliement de nombreux acteurs du march (Microsoft, Oracle, Hewlett Packard) et de nombreux diteurs dAGL (ateliers de gnie logiciel). LOMG et Rational ont simultanment publi un premire version de UML 1.1 en juillet 1997, la version dfinitive tant annonce pour septembre 1997 [1]. UML est une norme de reprsentation, nous allons alors prsenter quelques diagrammes dUML :
Le diagramme de cas dutilisation :

Il permet de dcrire linteraction entre le systme et ses utilisateurs. Cest un moyen de recueillir et de dcrire les besoins des utilisateurs. Il est galement une reprsentation des fonctionnalits du systme selon le point de vue de lutilisateur final. Acteur : cest un utilisateur extrieur du systme, il a une bonne ide des fonctionnalits de lapplication car il participe leur dfinition. Un acteur peut tre : Humain : utilisateur du logiciel travers son interface graphique. Logiciel : un logiciel dj existant qui communique avec le systme grce une interface logicielle (API par exemple)
Projet de fin dtude
Annexe (A)
169
Matriel : robot, automate qui exploite les donnes du systme.
Cas dutilisation : un cas dutilisation est une suite dvnements souvent initie par un acteur, qui correspond une utilisation particulire (fonctionnalit) du systme. Exemple dun diagramme de cas dutilisation :
retrait argent Guichetier dpt argent Fig. A.4 : Diagramme de cas dutilisation. bilan Directeur
Le diagramme de classes :
Le diagramme de classes se prsente sous forme de rseau de classes et dassociations. Ce rseau modlise la structure de chaque objet, son rle au sein du systme ainsi que ses relations avec les autres objets [1]. Exemple dun diagramme de classes :
Socit
Division
Departement
1 *
Salari
Fig. A.5 : Diagramme de classes. Lassociation qui existe entre Socit et Dpartement est une association dagrgation, Socit est la classe composante, Dpartement est la classe compose. Celle qui relie Socit Salari est une association un plusieurs.
Projet de fin dtude
Annexe (A)
170
Le diagramme de collaboration :
Il illustre les liens et les messages qui circulent entre des objets probablement types diffrents (Interface, contrle et entit). Exemple :
1: clic() 3: saisir_montant() : Interface 2: interface_affiche() : Client 6: succs() 4: retrait()
: Compte 5: retrait()
: C_retrait
Fig. A.5 Bis : Diagramme de collaboration.
Le diagramme de composants :
Il montre lorganisation et la dpendance entre les diffrents composants dun systme. Il permet de spcifier larchitecture logicielle dans un environnement de dveloppement donn. Il illustre la dcomposition du systme en lments physiques Exemple :
Identification.java
qui
peuvent
tre
des
excutables,
des
bibliothques,
des
documents
import
Abonn.java
Fig. A.6 : Diagramme de composants.
UML prsente dautres diagrammes nous en citons le diagramme dtats transitions, de squence, dactivit et de dploiement. Ces diagrammes ne sont
Projet de fin dtude
Annexe (A)
171
pas dtaills dans ce mmoire, cependant les titres de quelques ouvrages qui en parlent se trouvent dans la partie bibliographie.
II Le processus unifi :
Pour dfinir le processus unifi, nous allons simplement dfinir les deux termes qui le composent : Processus : suite continue d'oprations constituant la manire de fabriquer1. En dautres termes, cest une succession de tches dans le but daccomplir un travail, un projet. Unifi : participe pass du verbe unifier, tre amen l'unit, se fondre en un tout2. En fait, les mthodes danalyse et de conception orientes objet, taient varies jusqu ce que Rambaugh, Jackobson et Boosh eut lide de les unifier. Le processus unifi sappuie sur les principes suivants :
Pilot par les cas dutilisation : comme nous avons dj vu, un

cas dutilisation reprsente une fonctionnalit qui satisfait un besoin dun utilisateur. Le processus suit une voie spcifique, en procdant par une srie denchanement dactivits, drives dun cas dutilisation. Un cas dutilisation est analys, conu, implment et enfin test.
Centr sur larchitecture : larchitecture logicielle reprsente les

aspects statiques et dynamiques du systme. Larchitecture merge des besoins de lentreprise, tels quils sont exprims par les utilisateurs et reflts par les cas dutilisation. larchitecture propose une vue densemble de la conception faisant ressortir les
1(c) Larousse. 2(c) Larousse.
Projet de fin dtude
Annexe (A)
172
caractristiques
essentielles
en
laissant
de
ct
les
dtails
secondaires. Il faut noter que tout produit est la fois forme et fonction. Lune ou lautre isolment ne saurait suffire. Les cas dutilisation et larchitecture doivent squilibrer pour crer un produit russi [2].
Itratif et incrmental : vu que les projets raliser sont de

plus en plus complexes et grands, lide est de dcouper le travail en mini-projets. Chacun dentre eux reprsente une itration qui donne lieu un incrment. Les itrations dsignent des tapes de lenchanement dactivits, tandis que les incrments correspondent des stades de dveloppement du produit [2].
Les phases du processus unifi : le processus unifi se

droule en quatre phases, incubation, laboration, construction et transition. Chaque phase rpte un nombre de fois une srie ditrations. Et chaque itration est compose de cinq activits : capture des besoins, analyse, conception, implmentation et test.
Projet de fin dtude
Annexe (A)
173
Cration Besoins Analyse Conception Implmentation Test

Iter 1 Iter 2
Elaboration
Construction
Transition
Iter n-1
Iter n
Fig. A.7 : Les cinq activits se droulant dans chaque phase.
Inception (Incubation):
cest
la
premire
phase
du
processus unifi. Il sagit de dlimiter la porte du systme, c d tracer ce qui doit figurer lintrieur du systme et ce qui doit rester lextrieur, identifier les acteurs, lever les ambiguts sur les besoins et les exigences ncessaires dans cette phase. Il sagit aussi dtablir une architecture
candidate, c d que pour une premire phase, on doit essayer de
construire une architecture capable de fonctionner. Dans cette phase, il faut identifier les risques critiques susceptibles de faire obstacles au bon droulement du projet.
Elaboration : cest la deuxime phase du processus. Aprs

avoir compris le systme, dgag les fonctionnalits initiales, prcis les risques critiques, le travail accomplir maintenant consiste stabiliser larchitecture du systme. Il sagit alors de raffiner le modle initial de cas dutilisation, voire capturer de nouveaux besoins, analyser et concevoir la majorit des cas dutilisation formuls, et si possible implmenter et tester les cas dutilisation initiaux.
Projet de fin dtude
Annexe (A)
174
Construction : dans cette phase, il faut essayer de capturer

tous les besoins restants car il nest pratiquement plus possible de le faire dans la prochaine phase. Ensuite, continuer lanalyse, la conception et surtout limplmentation de tous les cas dutilisation. A la fin de cette phase, les dveloppeurs doivent fournir une version excutable du systme.
Transition : cest la phase qui finalise le produit. Il sagit au

cours de cette phase de vrifier si le systme offre vritablement les services exigs par les utilisateurs, dtecter les dfaillances, combler les manques dans la documentation du logiciel et adapter le produit lenvironnement (mise en place et installation) [2].
Annexe
(B)
Rational Rose, Java et Oracle
ans cette annexe, nous allons prsenter les diffrents outils dont nous avons eu besoin pour accomplir le projet. Pour dessiner les modles danalyse et de conception, nous avons utilis le logiciel Rational Rose
98i. Quant au langage de programmation, il nous a t impos de travailler avec Oracle JDeveloper bas sur la technologie Java, et Oracle comme SGBD.
I Rational Rose 98i :

Rational Rose 98i de Rational Software corporation est un outil de modlisation de diagrammes UML.
Projet de fin dtude
Annexe (B)
176
Ces modles contiennent des classes, des cas dutilisation, des objets, des packages, des composants et des relations entre eux. Ces lments, reprsents par des icnes, traitent les proprits du modle et le caractrisent. La mthode de lapplication recommande lutilisation de deux vues pour chaque modle, une vue statique et une vue dynamique. Vue statique : cette vue permet de dcrire les objets et les relations qui interviennent dans le cadre de la problmatique. Il sagit dune description de la structure des objets et de leurs caractristiques, et aussi dune description des associations qui existent entre les diffrents objets. Vue dynamique : cette vue vise dcrire les relations temporelles et vnementielles entre les objets dcrits dans la vue statique, les tats des objets (modifications internes au cours du droulement de lapplication), les actions effectues par les objets dans un contexte donn etc. Ceci dit, Rational Rose 98i nest pas un simple outil de dessin de diagrammes UML, car il permet aussi de gnrer limplmentation des classes conues, et de gnrer le schma de la base de donnes partir du diagramme de classes aprs avoir prciser le langage de programmation et le SGBD.
II Oracle JDeveloper :
Oracle JDeveloper est un environnement complet et intgr de dveloppement et de cration dapplication Java multi-tiers. Il permet de dvelopper, dboguer et dployer des applications clients Java, HTML dynamique, applications serveurs et procdures stockes. Le produit de la compagnie Borland International utilise le fameux langage de programmation orient objet Java. Dans ce qui suit, nous prsentons les caractristiques de ce langage de programmation. Java devait tre un langage multi plate-forme qui permettrait, selon le concept propos par Sun Microsystems, son concepteur, d'crire une seule fois pour toutes, des applications capables de fonctionner dans tous les environnements. L'objectif tait de taille, puisqu'il impliquait la dfinition d'une machine virtuelle
Projet de fin dtude
Annexe (B)
177
Java (JVM) sur laquelle les programmes crits devaient fonctionner, ainsi que la ralisation de cette machine virtuelle dans tous les environnements concerns. Sun Microsystems se chargeait par ailleurs de la ralisation d'une machine virtuelle dans les environnements Solaris et Windows, laissant d'autres le soin d'en faire autant pour les autres environnements (et en particulier MacOS, le systme d'exploitation des Macintosh). Afin que le langage devienne un standard, Sun Microsystems promettait d'en publier les spcifications et de permettre tous d'utiliser gratuitement son compilateur. Ds l'annonce de Java, le monde de l'informatique se divisait en quatre camps: ceux qui pensaient, pour des raisons varies, que cela ne marcherait jamais, ceux qui pensaient, pour des raisons tout aussi varies, qu'il fallait absolument que a marche, ceux qui ne voulaient absolument pas que cela marche, et ceux qui trouvaient qu'il tait urgent d'attendre pour voir. Ceux qui pensaient que a ne marcherait jamais considraient essentiellement qu'une machine virtuelle interprtant un langage intermdiaire (appel bytecode) ne serait jamais suffisamment performante. Il faut dire que les exemples prcdents avaient laiss des traces. D'autres considraient qu'il serait impossible d'imposer un standard ouvert dans le monde des PC vou l'hgmonie d'un seul diteur dtenant le quasi-monopole des systmes d'exploitation. Java apparaissait effectivement comme une tentative de casser le monopole de Windows. En effet, ce monopole reposait (et repose encore !) sur un cercle vicieux : tous les PC (ou presque) doivent utiliser Windows parce que toutes les applications importantes sont dveloppes pour cet environnement. Pour que cela change, il faudrait que les diteurs portent leurs produits sous un environnement diffrent : cela ne serait pas du tout rentable, puisque trs peu de PC utilisent un autre environnement que Windows. En revanche, une application dveloppe en Java pourrait fonctionner (sans aucune modification, pas mme une recompilation) dans n'importe quel environnement disposant d'une JVM. Pour cette raison, un certain nombre d'diteurs et d'utilisateurs voulaient absolument que cela fonctionne et imaginaient voir l, la fin de la domination
Projet de fin dtude
Annexe (B)
178
de Microsoft!. Un diteur important (Corel) annona mme qu'il allait rcrire toutes ses applications en Java. La mme raison entranait Microsoft prendre immdiatement le contre-pied de Java en proposant une technologie concurrente. Les concepteurs de Windows, en effet, arguaient qu'il tait inefficace et inutile de dvelopper des applications pour une machine virtuelle et qu'il suffisait de dvelopper une interface commune pouvant tre adapte sous diffrents environnements. Ainsi, les dveloppeurs n'taient pas tenus d'utiliser un nouveau langage. Il leur suffisait de programmer en fonction d'une nouvelle interface de programmation: ActiveX. Bien sr, cette API ne serait ni ouverte (ce qui permettrait certains de prtendre que Microsoft se rserve des fonctions pour son usage personnel afin d'avantager ses propres applications) ni gratuite. La quatrime catgorie d'utilisateurs pensait probablement que les promesses de Java taient tout fait allchantes, mais qu'on n'a jamais crit des applications avec des promesses, et qu'il fallait donc rester l'coute pour voir ce que cela donnerait. En effet, la compagnie a pu tenir ses promesses, car la dernire version de Java est si performante, que pas mal de dveloppeurs ont choisi de ladopter pour construire des applications performantes, avec des interfaces de haute qualit (bibliothques Swing et AWT) et pouvant fonctionner sur plusieurs platesformes (write once, run everywhere).
Java est un langage orient objets : Java ne manipule que des

classes, on ne parle plus de procdures et de fonctions, il sagit maintenant dattributs et de mthodes. lapproche orient objets est, comme nous lavons dj dfinie dans lannexe A, caractrise par trois concepts fondamentaux : Hritage, Polymorphisme et Encapsulation. Java permet dimplmenter ces trois concepts (lhritage ne peut pas tre multiple).
Java est extensible linfini : Java est crit en Java. Toutes les
classes existant en Java devraient tre dfinies par extension dautres classes, en partant de la classe de base la plus gnrale : la classe Object.
Projet de fin dtude
Annexe (B)
179
Pour tendre Java, il suffit de dvelopper de nouvelles classes. Ainsi tous les composants crits pour traiter un problme particulier, peuvent tre ajouts au langage et utiliss pour rsoudre dautres problmes.
Java est un langage haute scurit : contrairement au langage

C++, Java a t dvelopp dans un souci de scurit maximale. L'ide matresse est qu'un programme comportant des erreurs ne doit pas pouvoir tre compil. Ainsi, les erreurs ne risquent pas d'chapper au programmeur et de survivre aux procdures de tests. De la mme faon, en dtectant les erreurs la source, on vite qu'elles se propagent en s'amplifiant.
Java est un langage simple apprendre : Java est un langage

relativement simple apprendre et lire. Beaucoup plus, en tout cas, que C++. Cette simplicit a aussi un prix. Les concepts les plus complexes (et aussi les plus dangereux) de C++ ont t simplement limins. Est ce que Java est alors, moins efficace ? Pas vraiment. Tout ce qui peut tre fait en C++ (sauf certaines erreurs graves de programmation) peut l'tre en Java.
Java est un langage compil : cest - dire qu'avant d'tre excut, il

doit tre traduit dans le langage de la machine sur laquelle il doit fonctionner. Cependant, contrairement de nombreux compilateurs, le compilateur Java traduit le code source dans le langage d'une machine virtuelle, appele JVM. Le code produit, appel bytecode, ne peut pas tre excut directement par le processeur de lordinateur. (Cependant, rien n'interdit de fabriquer un processeur qui excuterait directement le bytecode Java).Le bytecode est ensuite confi un interprteur, qui le lit et l'excute. En principe, l'interprtation du bytecode est un processus plus lent que l'excution d'un programme compil dans le langage du processeur. Cependant, dans la plupart des cas, la diffrence est relativement minime. Elle pose toutefois un problme pour les applications dont la vitesse d'excution est un lment critique, et en
Projet de fin dtude
Annexe (B)
180
particulier pour les applications temps rel ncessitant de nombreux calculs comme la simulation 3D anime [3].
JDBC (Java DataBase Connectivity)

JDBC est une API qui dfinit laccs une base de donnes relationnelle. Spcifie par Sun-JavaSoft, cette API est indpendante des diteurs et sappuie sur les spcifications X/OPEN, SQL, et CLI. JDBC est trs proche dans sa conception dODBC, qui sappuie galement sur ces spcifications. JDBC permet dcrire du SQL statique et dynamique depuis Java. Dans ce cas, la structure des tables et les requtes sont dfinies au moment de lexcution. JDBC est livr par les diteurs sous forme de bibliothques de classes Java. Ces classes constituent la notion de driver JDBC. Les diffrentes versions de JDBC supportent les syntaxes et types SQL92. Les deux grandes spcifications de drivers JDBC qui existent lheure actuelle sont JDBC 1 et JDBC 2 qui est incluse dans je JDK 1.2. JDBC 2 se dcompose en deux parties : lAPI centrale (core) et les extensions. LAPI centrale fait partie de Java 2 Platform Standard Edition ; elle contient les API les plus communment utilises en mode client-serveur. Les extensions se trouvent dans Java 2 Platform Entreprise Edition. Ces extensions sont principalement utiles pour le dveloppement ct serveur ou serveur intermdiaire dune architecture multiniveau. On trouve notamment dans ces extensions les notions de pool de connexions et de transaction distribue XA. LAPI la plus utilise est JDBC 1. Reposant sur un JDK 1.1.x, elle est trs largement employe pour les applications clientes. Bien que JDBC soit une API Java, sa mise en uvre peut ncessiter la prise en compte de code non Java. Il en est ainsi avec lutilisation dun driver JDBCODBC ou dun driver reposant sur les couches client-serveur natives de la base de donnes. La majorit des diteurs disposent de drivers cent pour cent Java, tlchargeables depuis une applet [4].
Projet de fin dtude
Annexe (B)
181
Application Java Driver JDBC/ODBC Driver JDBC/OCI
Driver ODBC
Oracle Net8
Oracle Net8
Rseau TCP/IP
Fig. B.1 : Driver JDBC
III Oracle 9i :
Oracle 9i est un SGBD qui offre plusieurs services, gnralement exploitables partir de Oracle Enterprise Manager. OEM est une structure de gestion comprenant trois niveaux : 1. La console et ses outils intgrs offrent aux administrateurs une interface graphique permettant de grer la totalit de l'environnement Oracle. 2. Des serveurs Management Server et un rfrentiel de base de donnes offrent un niveau intermdiaire volutif servant au traitement des tches de gestion du systme. 3. Des agents Intelligent Agent, sont installs sur chaque noeud du rseau pour surveiller les services offerts par le noeud et pour excuter des tches lies au serveur Management Server. Il faut noter quon peut galement lancer la console en mode autonome lorsquon souhaite administrer des bases de donnes, mais quon na pas besoin de surveiller les vnements ni les travaux programms.
Projet de fin dtude
Annexe (B)
182
2 3
Fig. B.2 : Structure de gestion de lOEM LOEM offre plusieurs services dont voici les plus importants : Administration de la totalit de l'environnement Oracle, y compris les bases de donnes, les applications et les services. Diagnostic, modification et rglage de plusieurs bases de donnes. Programmation de tches sur plusieurs systmes diffrents intervalles. Surveillance de conditions de base de donnes sur tout le rseau. Administration de plusieurs noeuds et services rseau depuis de nombreux emplacements. Partage de tches avec d'autres administrateurs. Regroupement des services connexes pour faciliter les tches d'administration. Lancement d'outils Oracle et d'outils tiers intgrs. Instance Management permet d'effectuer les oprations suivantes : Dmarrage et arrt d'une base de donnes. Affichage et dition des valeurs des paramtres d'instance. Gestion des sessions utilisateur, et affichage du code SQL en cours d'excution et de son plan d'excution.
Projet de fin dtude
Annexe (B)
183
Gestion des transactions en suspens. Gestion des oprations excution longue. Contrle des ressources de traitement via des plans de ressource. Gestion de configurations stockes. Administration des verrous externes et des sessions consommant la plus grande quantit de ressources (si Diagnostics Pack est install). Schema Manager permet d'administrer des objets de schma comme les tables, les index et les objets Oracle8. Schema Manager permet d'effectuer les oprations suivantes : Cration d'objets de schma. Modification d'objets de schma. Suppression d'objets de schma. Affichage des dpendances portant sur les objets de schma Security Manager permet d'effectuer les oprations suivantes : Cration d'utilisateurs, de rles et de profils. Modification des utilisateurs, des rles et des profils. Suppression d'utilisateurs, de rles et de profils. Attribution de privilges et de rles aux utilisateurs de base de donnes. Storage Manager permet d'administrer les objets de stockage tels que les espaces disque logiques (Tablespace), les segments d'annulation, les fichiers de donnes et les fichiers de journalisation. Vous pouvez effectuer les oprations suivantes : Cration d'objets de stockage. Ajout de fichiers de donnes et de segments d'annulation un espace disque logique. Suppression d'objets de stockage. Mise en ligne ou hors ligne d'objets. Affichage des dpendances des objets. Oracle9i offre des fonctionnalits intgres de prise en charge de Data Warehouse via OLAP Services et des mta donnes OLAP stockes dans la base de donnes.
Annexe
(C)
Les interfaces utilisateurs
D
gnral.
ans cette annexe, nous prsentons quelques interfaces utilisateurs du logiciel de facturation. Nous avons choisi dexposer les interfaces principales, qui sont : lidentification, la recherche dun patient, la
cration dun patient, la cration dun dossier patient, la facturation de prestations, la facture, le paramtrage des conventions et le paramtrage
Fig C.1 : Interface didentification
Fig C.2 : Interface de recherche patient
Fig C.3 : Interface de cration patient
Fig C.4 : Interface de cration dun dossier patient
Fig C.5 : Interface de facturation de prestations
Fig C.6 : Interface de la facture clinique
Fig C.7 : Interface de paramtrage des conventions
Fig C.8 : Interface de paramtrages gnrals
Glossaire gnral
Projet de fin dtude
Glossaire gnral
194
Acteur : Dv. Cest un lment qui interagit avec le systme dans le but de satisfaire un besoin. Un acteur peut tre une personne, un logiciel ou un matriel. Admission : Cont. Chez une clinique, cest le fait de recevoir (accepter) un patient. Ladmission entrane plusieurs oprations informatiques ralises par la rceptionniste, dont la cration dun dossier patient. AGL : Dv. Atelier de Gnie Logiciel. Les ateliers de gnie logiciel sont apparus dans les annes 80 pour faciliter le travail de dveloppement de logiciels en quipe. API : Dv. Application Programming Interface. L'API est un concept contemporain de la programmation d'applications modulaires (prcurseur de la programmation oriente objet ). En effet, chaque fonction d'un programme est partiellement autonome dans la mesure o elle n'agit sur aucun autre module fonctionnel ou variable " globale " du programme ; on l'appelle en lui fournissant des paramtres en entre et elle s'achve l'aide de paramtres en sortie. Appareillage (ou Appareill.) : Cont. Cest un service offert par la polyclinique. Il consiste en la mise disposition dun appareil mdical pour un patient. Lunit de facturation de ce service est lheure ou la journe. Architecture : Dv. Cest lorganisation dun systme logiciel, elle reprsente la manire dont les dveloppeurs ont slectionn les lments structurels composants le systme, ainsi que leurs interfaces et leurs comportements tel quils sont spcifis dans les collaborations. AWT : Dv. Cest une bibliothque Java qui permet de construire des interfaces graphiques avances.
-A-
Projet de fin dtude
Glossaire gnral
195
Besoin : Dv. Etat de privation dun acteur, que le systme doit satisfaire travers lune de ses futures fonctionnalits. On distingue deux types de besoins : besoins fonctionnels, que le systme doit tre capable deffectuer, et besoins non fonctionnels, c d lis aux performances du systmes et aux contraintes de lenvironnement et de limplmentation. Bon de prestation : Cont. Chaque consommation dune prestation doit tre accompagne par un bon justificatif, comportant le code de la prestation, le code du dossier patient et la quantit consomme.
-B-C-
Cas dutilisation : Dv. Cest la description dune squence dactions donnant lieu un rsultat qui satisfait le besoin dun acteur. Ces progiciels disposent d'un ensemble d'outils composant un environnement plus ou moins complet de gestion et d'automatisation de la production de logiciels. Les grandes fonctions assures sont notamment : - la consignation des diffrents besoins. - la ralisation d'organigrammes fonctionnels. - la planification des tches de dveloppement. - la prparation de la documentation. - la programmation des diffrents modules du logiciel. Connection : Dv. Objet Java qui permet la connexion une base de donnes travers un driver JDBC.
Projet de fin dtude
Glossaire gnral
196
Convention : Cont. Cest une sorte de contrat tabli entre la polyclinique et une organisation. Ce contrat permet aux employs de lorganisation une hospitalisation moins coteuse (remises sur diffrentes rubriques de la facture) et une probable prise en charge des frais de leurs hospitalisations par lorganisation laquelle ils appartiennent.
ECG : Cont. Electrocardiogramme, cest un examen tout fait indolore qui permet denregistrer les courants lectriques gnrs par le cur. Encapsulation : Dv. Cest le mcanisme de regroupement des donnes et des comportements. Lencapsulation favorise la dissimulation de linformation. Extra : Cont. Cest une prestation que le patient peut sen passer, quil commande sa guise. Exemple : bouteille deau minrale, kinsie
-E-F-
Fluide : Cont. Se dit dun corps (liquide ou gaz) dont les molcules sont faiblement lies, et qui peut ainsi prendre la forme du vase qui le contient, Exemple : O2. Dans la polyclinique, on facture les fluides par jour ou par heure.
Projet de fin dtude
Glossaire gnral
197
Hritage : Dv. Cest un mcanisme par lequel on dfinit une classe comme tant le cas particulier dune classe plus gnrale. En plus des mthodes et des attributs dont elles hritent, les sous-classes peuvent dfinir leurs propres mthodes et attributs.
-H-J-K-
JDBC : Dv. Java DataBase Connectivity, cest une API qui dfinit laccs une base de donnes.
K opratoire : Cont. Coefficient opratoire, le nombre de K mesure l'importance de l'intervention chirurgicale et sert tablir sa tarification. Exemple : une appendicite est cote K 50.
Message : Dv. Spcification dune communication entre objets vhiculant des informations, donnant lieu en principe une activit.
-M-
Projet de fin dtude
Glossaire gnral
198
ODBC : Dv. ODBC signifie Open DataBase Connectivity. Il s'agit d'un format dfini par Microsoft permettant la communication entre des clients bases de donnes fonctionnant sous Windows et les SGBD du march. On distingue trois grandes familles de prestations : analyse, imagerie (radio), acte opratoire. Ces types de prestations possdent chacun, un coefficient (analyse => B, radio=> R, acte opratoire=> K). Ceci dit il y a une prestation qui nappartient aucune famille, et qui figure dans la facture comme tant une rubrique : cest lECG. Organisation : Cont. Cest une socit conomique ou politique qui est susceptible dtablir une ou plusieurs conventions avec la polyclinique.
-O-P-
Polymorphisme : Dv. Cest la possibilit pour un mme message de dclencher des traitements diffrents, suivant les objets auxquelles il est adress. POO : Dv. Programmation Orient Objet. Un langage de programmation orient objet doit tre fond sur trois notions indispensables : lencapsulation, le polymorphisme et lhritage. Prestation : Cont. Cest un service offert par la polyclinique travers des infirmiers (bilan, radio), des mdecins (oprations chirurgicales) etc. Prise en charge : Cont. Une organisation, en convention avec la polyclinique, peut offrir ces employs le privilge de payer leur place, une partie du montant de leurs factures. Cette partie est dtermine par un taux appel taux de prise en charge. Ce taux constitue un article de la convention tablie. Exemple : si le taux
Projet de fin dtude
Glossaire gnral
199
de prise en charge est de 75%, le patient paye 25% du montant de la facture et lorganisation paye le reste. Il faut noter que ce taux est appliqu au montant de la facture aprs en avoir soustraire les extras, qui seront pays par le patient. Produit : Cont. Cest un bien offert par la polyclinique. On distingue quatre grandes familles de produits : les mdicaments, les usages uniques, les fluides et les produits alimentaires. Prototype : Dv. Cest le premier exemplaire construit dun logiciel, destin en exprimenter les qualits en vue de la construction.
-RRemise sur rubrique : Cont. Une remise accorde par la polyclinique ne sapplique pas sur le montant total de la facture, mais sur les montants des rubriques qui la constituent, car gnralement, on applique une remise diffrente dune rubrique une autre. Cette diffrenciation est due aux marges de bnfices diffrentes des rubriques. Par exemple : on napplique pas de remise suprieur 15% sur les usages uniques, car la marge de bnfice nest pas grande, par contre, la remise sur le sjour peut aller jusqu 50%. ResultSet : Dv. Objet Java sous forme de matrice, servant stocker et manipuler le rsultat dune requte SQL select . Risque non technique : Dv. Risque li des aspects de gestion tel les ressources disponibles (individus, temps) Risque technique : Dv. Risque li des aspects techniques telles que la mthode de conception, les technologies dimplmentation
Projet de fin dtude
Glossaire gnral
200
-SStatement : Dv. Objet Java qui permet la manipulation des donnes dune base partir dune instance Connection . Swing : Dv. Cest une bibliothque Java qui permet de construire des interfaces graphiques avances.
-UUsage unique : Cont. Cest un produit offert par la clinique, qui ne peut tre utilis quune seule fois. Exemple : seringue etc. NB : Dv. est labrviation de Dveloppement , a veut dire que le terme dfinir est li au dveloppement de lapplication. Cont. est labrviation de Contexte du systme , a veut dire le terme dfinir est li au contexte du systme logiciel.
Bibliographie
[1] : Nathalie Lopez, Jorge Migueis et Emmanuel Pichon, Intgrer UML dans vos projets, Editions Eyrolles, 2000. [2] : Ivar Jackobson, Grady Boosh, James Rambaugh, Le processus unifi de dveloppement logiciel, Editions Eyrolles, 1999. [3] : Antoine Mirecourt, Pierre-Yves Saumont, Le dveloppeur Java 2, Editions Eyrolles, 1999.
[4] : Frdric Berqu, Serge Frezefond, Ludovic Sorriaux, Java-XML et Oracle, Editions Eyrolles, 2001. [5] : Ivar Jackobson, Manus Cristerson, Patrick Jonsson, Gunar Overgaard, Le gnie logiciel orient objet, Editions Addison Wesley.

Ma It Rise

Uploaded by

Document Information

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

Ma It Rise

Uploaded by

Copyright:

Available Formats

Universit de Tunis Institut Suprieur de Gestion

Mmoire de matrise en Informatique Applique la Gestion

Conception et Ralisation dun logiciel de facturation pour une polyclinique prive

Anne Universitaire 2002/2003

A mes trs chers parents

A mes trs chers surs et frre

A mes trs chers amis

A mes trs chers parents

A mes trs chers surs et frres

A mes trs chers amis

A notre encadreur Monsieur Mohamed Salah GOUIDER.

Mohamed Anis et Manel.

Projet de fin dtude

Rational Rose 98i nous aidera normment dessiner et

grer les diffrents diagrammes UML.

Projet de fin dtude

En ce qui concerne limplmentation, nous utiliserons

Oracle9i, la solution convenable un systme si riche dinformations vu le trs

nous commencerons par

deuxime chapitre de ce travail, nous

Projet de fin dtude

Au niveau du troisime chapitre :

La construction , larchitecture tant stable,

prsenterons comment le produit est mis en place et dploy chez la polyclinique.

Prsentation de la polyclinique Taoufik

trois objectifs, lpoque taient de :

Projet de fin dtude

Projet de fin dtude

Les malades internes et les malades externes sont admis sparment.

Laboratoire de Biochimie : Laboratoire de Bactriologie : Salles de consultations : Bloc opratoire :

I.1 - Contexte du systme :

Projet de fin dtude

I.1.1- Circuit du dossier patient :

2-Passation des prestations1 :

Projet de fin dtude

Projet de fin dtude

I.1.3 - Les conventions :

I.2 - Besoins fonctionnels et besoins non fonctionnels :

Projet de fin dtude

Le responsable admission (Rceptionniste):

Projet de fin dtude

Editer la facture patient - mdecin.

Besoins non fonctionnels :

la rapidit de traitement : En effet, vu le nombre important des

la convivialit : Le futur logiciel doit tre facile utiliser. En effet,

I.3- Cas dutilisation initiaux :

Projet de fin dtude

I.3.1- Diagramme de cas dutilisation initial:

Crer un dossier patient <<extend>>

Editer facture patient

Passer une prestation une facture patient Secrtaire d'tage

Passer un produit une facture patient

Rechercher un dossier patient <<include>>

Modifier un dossier patient

Annuler un dossier patient

FigI.1 : Diagramme de cas dutilisations initial.

I.3.2- Description dtaille des cas dutilisation :

Projet de fin dtude

Modifier un dossier patient :

Annuler un dossier patient :

Rechercher un dossier patient :

Projet de fin dtude

Passer un produit une facture patient :

consomms par le patient sils existent dans le petit stock de ltage.