Medicdb PDF

ANALYSE UML
Projet MedicDB
Version 0.04
Interface3 - 2011
Document d'analyse UML

Projet MedicDB
Projet MedicDB
by WAD11
Dossier d'analyse UML pour la ralisation du projet MedicDB.
Keywords WAD11, UML, DB Classification Public
Publisher: ......... WAD11 Version: ............ 0.04 Issued on: ........ 12-Oct-2011
Page 2/37

Projet MedicDB
Projet MedicDB
by WAD11
History
Version 0.01 0.02 0.03 0.04 Date 04/11/2011 07/10/2011 10/10/2011 12/10/2011 WAD11 WAD11 WAD11 WAD11 Author Description Nouvelle version. Consolidation des use cases. Consolidation des sequence diagrams. Consolidation du class diagram. Action(*) Sections All All All All
I/U/R/D I/U/R/D I/U/R/D I/U/R/D
(*) Action: I = Insert, R = Replace, U = Update, D = Delete, Q = Quality Review
Reviewed by
Date Version Name Comment
Page 3/37

Projet MedicDB
Projet MedicDB
by WAD11
Table of contents
1 2 3
INTRODUCTION .................................................................................................... 6 CAHIER DES CHARGES........................................................................................... 7 DIAGRAMMES DE CAS DUTILISATION .................................................................. 8 3.1 3.2 3.3 3.4 3.5 3.6 SE CONNECTER AU SYSTEME ....................................................................................... 8 ADMINISTRATION DU SYSTEME .................................................................................. 10 GESTION DU CALENDRIER ........................................................................................ 13 GESTION DES PATIENTS .......................................................................................... 14 GESTION DES RENDEZ-VOUS .................................................................................... 15 GESTION DES EXAMENS MEDICAUX ............................................................................. 17 AUTHENTIFICATION DE LUTILISATEUR ......................................................................... 21 CREATION DUNE SIGNALETIQUE PATIENT ...................................................................... 22 CREATION DUNE SIGNALETIQUE PATIENT (VERSION DETAILLEE) ........................................... 23 AUTHENTIFICATION DES UTILISATEURS ........................................................................ 24
Liste des identifiants uniques ...................................................................................... 25 Liste des identifiants uniques ...................................................................................... 27 Liste des identifiants uniques ...................................................................................... 27 Liste des identifiants uniques ...................................................................................... 28 Liste des identifiants uniques ...................................................................................... 29
DIAGRAMMES DE CAS SEQUENCE ........................................................................ 21 4.1 4.2 4.3
DIAGRAMMES DE CAS CLASSES ........................................................................... 24 5.1 5.2 5.3 5.4 5.5 5.6 5.7
5.1.1 5.2.1 5.3.1 5.4.1 5.5.1
PERSONNEL DE LA CLINIQUE ..................................................................................... 25 SPECIALITES MEDICALES ......................................................................................... 27 AGENDA DU MEDECIN ............................................................................................. 28 SIGNALETIQUE DES PATIENTS ................................................................................... 28 RENDEZ-VOUS DES PATIENTS ................................................................................... 30 DUREE MOYENNE DES EXAMENS ................................................................................. 30
Liste des identifiants uniques ...................................................................................... 31
5.7.1
5.8 DOSSIER MEDICAL DU PATIENT .................................................................................. 31 5.9 DOSSIER MEDICAL ................................................................................................ 32 5.10 EXAMEN CLINIQUE ............................................................................................... 33 6 ANNEXE ............................................................................................................... 35 6.1 EXEMPLE DE CAS DUTILISATION ................................................................................ 35
Page 4/37

Projet MedicDB
Projet MedicDB
by WAD11
Table of figures
Figure 3-1: Se connecter au systme ............................................................................... 8 Figure 3-2: Administration du systme ........................................................................... 10 Figure 3-3: Gestion du calendrier .................................................................................. 13 Figure 3-4: Gestion des patients.................................................................................... 14 Figure 3-5: Gestion des rendez-vous.............................................................................. 16 Figure 3-6: Gestion des examens mdicaux .................................................................... 18 Figure 4-1: Autentification de l'utilisateur ....................................................................... 21 Figure 4-2: Cration d'une signaltique patient ............................................................... 22 Figure 4-3: Cration dun signaltique patient (dtaill) ................................................... 23 Figure 5-1: Diagramme de classe gnral ....................................................................... 24 Figure 5-2: Identification des utilisateurs ........................................................................ 25 Figure 5-3: Personnel de la clinique ............................................................................... 26 Figure 5-4: Spcialits mdicales .................................................................................. 27 Figure 5-5: Agenda du mdecin..................................................................................... 28 Figure 5-6: Signaltique des patients ............................................................................. 29 Figure 5-7: Mdecin traitant ......................................................................................... 29 Figure 5-8: Rendez-vous des patients ............................................................................ 30 Figure 5-9: Dure moyenne des procdures mdicales ..................................................... 31 Figure 5-10: Dossier mdical ........................................................................................ 32 Figure 5-11: Dossier mdical ........................................................................................ 33 Figure 5-12: Examen clinique........................................................................................ 34
Page 5/37

Projet MedicDB
PublicErreur ! Nom de proprit de document inconnu.
Introduction
Ce document a pour objectif de fournir le dossier danalyse UML conu par les stagiaires du groupe WAD11 pour la ralisation du projet MedicDB1. Lobjectif de ce dossier est de permettre aux stagiaires de mettre en pratique les concepts thoriques tudis durant les formations danalyse DB et danalyse UML. Sur base du cahier des charges du systme MedicDB, les stagiaires sont invites analyser tape par tape les fonctionnalits du systme jusqu aboutir la modlisation du systme. Comme le cours se concentre sur laspect Base de donnes , les stagiaires pourront figer leur analyse jusquau modle permettant la cration et la manipulation des donnes. Pour la modlisation UML, les stagiaires sont invites utiliser le logiciel Visual Paradigm Community Edition . lissu du projet danalyse, un dossier danalyse unique sera consolid en reprenant les ides communes en phase avec le sujet propos. Ce document (son contenu et ses diagrammes) a pour vocation dtre consolid itration par itration.
1 Le sujet du projet MedicDB a t propos par M. Abdelkarim Moulai (Dynaclic SPRL) en Septembre 2011.
Page 6/37

Projet MedicDB
Cahier des charges
Vous venez dtre engag pour concevoir la base de donnes dun cabinet mdical nayant pas encore dinfrastructure informatique. Cette base de donnes sera utilise par le personnel mdical, le personnel de gestion ainsi que par des applications tierces. Suite aux runions avec les diffrentes personnes concernes, voici les informations qui en ressortent et dont il faut absolument tenir compte. Toutes les personnes dans le systme possdent les caractristiques suivantes : un nom, un prnom, une adresse et un numro de tlphone. En effet, ces coordonnes standard sont utiles et ncessaires au bon fonctionnement du systme. Plusieurs mdecins peuvent travailler dans le cabinet mdical. Chaque mdecin possde une spcialit (pneumologie, mdecine gnrale, pdiatrie, etc.). Les patients sont aussi caractriss par leur date de naissance, leur sexe et leur numro didentification de la scurit sociale (par exemple : numro de registre national). Chaque patient possde un mdecin rfrant (qui doit obligatoirement tre un mdecin gnraliste) travaillant dans le cabinet mdical. Des consultations se font une date, une heure de dbut et ont une dure en minutes. Les consultations ont un objet qui est la raison de la venue du patient. Ce sont les secrtaires qui prennent les rendez-vous pour les consultations, sans remplir lobjet (cest au mdecin de l e faire). Les heures de rendez-vous vont de 8h 18h, du lundi au vendredi (valable pour tous les mdecins). Une secrtaire peut travailler pour plusieurs mdecins, mais un mdecin na quune seule secrtaire. Les mdecins peuvent prescrire des mdicaments ou des examens complmentaires. Les prescriptions des examens contiennent uniquement le nom de lexamen (par exemple : prise de sang). Les prescriptions des mdicaments, en plus dindiquer le mdicament, informent sur la dure (en jours) et la posologie (par exemple : 1 glule / jour ). Les mdicaments sont caractriss par un nom, une seule substance active et un prix (par exemple : Dafalgan, paractamol, X). Il faut aussi pouvoir dire si le mdicament est un gnrique ou non (par exemple : Dafalgan nest pas un produit gnrique). Enfin, une liste dincompatibilits avec dautres substances actives doit tre disponible afin de permettre dalarmer le mdecin si le patient prend dj un mdicament qui entre en conflit avec celui de la prescription. Certains patients, atteints de pathologie(s), doivent tre suivis. Les pathologies ont un nom, une date de dbut et ventuellement une date de fin. Une pathologie peut prsenter des contre-indications pour lun ou lautre mdicament (cette information sera util e pour alerter le mdecin en cas de prescription inadquate).
Page 7/37

Projet MedicDB
Diagrammes de cas dutilisation
Cette section dcrit les diffrents cas dutilisation (use case) que nous avons dduite la lecture du cahier des charges et des discussions entre les membres du groupe WAD11. Nous avons pris le parti de borner le systme lapplication en devenir MedicDB plutt que de tenter danalyser toutes les interactions pouvant survenir dans une Clinique mdicale. Cela sous-entend que le patient ne sera pas reprsent en tant quacteur du systme. En effet, le cahier des charges ne stipule pas que le patient participe activement sur le systme. Il est noter que nous avons pris le parti de surcharger les diagrammes de cas dutilisation en y reprsentant les relations de type Include ou Extend et ceci afin de permettre aux stagiaires de mieux cerner le contexte du systme. Dans une analyse real-world , on essaiera dviter autant que possible dalourdir les schmas.
3.1 Se connecter au systme

La procdure dauthentification au systme permet didentifier les utilisateurs et de fournir les droits qui leur sont attribus.
Figure 3-1: Se connecter au systme Nom Rsum Acteurs UC01-Login to the system Procdure de connexion des utilisateurs. Primaire: Secondaire: User /
Page 8/37

Projet MedicDB
Liens
Include Extend
/ /
vnement dclencheur Pr-conditions Post-conditions Description
Lutilisateur se connecte au systme. Lutilisateur fournit son login et son mot de passe. Le systme autorise ou non laccs lutilisateur. La procdure de connexion des utilisateurs a pour objectif de dterminer si lutilisateur est autoris se connecter au systme. Les droits des utilisateurs seront par ailleurs utiliss pour donner ou interdire laccs certaines fonctions du systme requrant des privilges adquats. Scnario nominal
tape # 1.
Actions acteur (vnement externe) Lutilisateur se connecte au systme en fournissant les informations suivantes : Login Mot de passe
Rponse du systme
2.
Le systme recherche dans la base de donnes le profil de lutilisateur sur base du login. Le mot de passe est compar avec celui transmis par lutilisateur. Le systme autorise laccs lutilisateur et lui prsente la page daccueil du systme. Scnarios alternatifs
3. 4.
tape # 2.a 2.a.1 2.a.2
Action alternative acteur
Rponse alternative systme Le login est inconnu. Le systme trace une information lattention de ladministrateur. Le systme retourne un message lutilisateur linvitant recommencer la procdure. Le mot de passe est invalide. Le systme retourne un message lutilisateur linvitant recommencer la procdure.
3.a 3.a.1
Page 9/37

Projet MedicDB
3.a.2
Le systme retourne un message lutilisateur linvitant recommencer la procdure ou demander un nouveau mot de passe.
3.2 Administration du systme

Le diagramme suivant montre les fonctions minimales requises pour grer le systme MedicDB. Les oprations dadministration sont prises en charge par un administrator possdant les droits adquats.
Figure 3-2: Administration du systme Nom Rsum Acteurs UC02-Manage Staff Gestion des utilisateurs du systme. Primaire: Administrateur
Page 10/37

Projet MedicDB
Secondaire: Liens Include Extend vnement dclencheur Pr-conditions Post-conditions Description
/ UC01-Login to the system /
Ladministrateur gre les utilisateurs et/ou leurs droits. Lutilisateur sest correctement identifi au systme et possde les droits adquats pour ladministrer. / La gestion des utilisateurs permet dajouter, de supprimer, de modifier, de consulter ou de rechercher les utilisateurs du systme ainsi de grer leurs droits dutilisation de MedicDB et des donnes. Les utilisateurs regroupent tant le personnel soignant (mdecins, infirmires) que le personnel administratif (secrtaire, administrateur, direction). Chaque utilisateur est dfini dans le systme par les informations suivantes : Login Password Nom Prnom Sexe (M/F) Titre (Docteur;Infirmire;Technicien;Secrtaire;Administrateur; Directeur;etc.) Service (Urgence;Labo; etc.) Spcialit (Gnraliste;ORL;Cardiologue;Radiologue;etc.) Tel Bureau Tel Mobile Email Rue Localit Ville Pays
Le Login est un identifiant unique dans le systme.
Nom Rsum Acteurs
UC03-Manage Drugs Gestion des mdicaments. Primaire: Secondaire: Administrateur /
Page 11/37

Projet MedicDB
Liens
Include Extend
UC01-Login to the system /
vnement dclencheur Pr-conditions Post-conditions Description
Ladministrateur gre les mdicaments. Lutilisateur sest correctement identifi au systme et possde les droits adquats pour ladministrer. / La gestion des mdicaments implique de pouvoir ajouter, supprimer, de modifier, consulter ou rechercher des mdicaments. Les mdicaments sont identifis au travers des informations suivantes : Nom Substance Description Posologie Contre-indication Prix Gnrique (oui/non)
Le Nom du mdicament est un identifiant unique dans le systme. La liste des mdicaments a pour objectif daider les mdecins dans ltablissement des prescriptions et dtecter les incompatibilits mdicamenteuses ainsi que les contre-indications suite des pathologies existantes.
Nom Rsum Acteurs
UC04-Manage Types of Medical Consultation Gestion des types de consultations mdicales. Primaire: Secondaire: Administrateur / UC01-Login to the system /
Liens
Include Extend
vnement dclencheur Pr-conditions Post-conditions
Ladministrateur gre les types de consultations mdicales. Lutilisateur sest correctement identifi au systme et possde les droits adquats pour ladministrer. /
Page 12/37

Projet MedicDB
Description
Le cas dutilisation permet dajouter, de supprimer, de modifier, de consulter ou de rechercher les types de consultation mdicale. Chaque type de consultation est dfini dans le systme par les informations suivantes : Nom Description Dure moyenne
Le Nom est un identifiant unique dans le systme.
3.3 Gestion du calendrier

Afin de pouvoir organiser les rendez-vous des patients, il est impratif que la clinique mdicale dispose dun systme de calendrier partag dans lequel on puisse retrouver les priodes de disponibilits de chaque mdecin.
Figure 3-3: Gestion du calendrier Nom Rsum Acteurs UC05-Manage the calendar Gestion du calendrier des mdecins. Primaire: Secondaire: Liens Include Extend vnement dclencheur Pr-conditions Mdecin Secrtaire UC01-Login to the system /
Le mdecin met jour ou consulte son calendrier. La secrtaire met jour ou consulte le calendrier dun ou de plusieurs mdecins. Lutilisateur sest correctement identifi au systme et possde les droits adquats pour grer le calendrier du ou des mdecins.
Page 13/37

Projet MedicDB
Post-conditions Description
/ La gestion du calendrier permet dajouter, de supprimer, de modifier, de consulter ou de rechercher des rendez-vous et/ou des priodes dindisponibilits. Chaque mdecin doit mettre jour son calendrier pour prciser ses priodes dindisponibilits. Cette tche peut tre dlgue la secrtaire. Une secrtaire a la capacit de grer le calendrier dun ou plusieurs mdecins auquel elle est affecte. Le calendrier ne concerne que les jours ouvrables de la Clinique (du lundi au vendredi) pour une plage horaire comprise entre 8h et 18h.
3.4 Gestion des patients

Chaque signaltique des patients est maintenue dans le systme.
Figure 3-4: Gestion des patients Nom Rsum Acteurs UC06-Manage Patient Gestion des patients. Primaire: Secondaire: Liens Include Extend vnement dclencheur Pr-conditions Post-conditions Secrtaire Mdecin UC01-Login to the system /
La secrtaire met jour ou consulte une signaltique du patient. Le mdecin consulte une signaltique du patient. Lutilisateur sest correctement identifi au systme et possde les droits adquats pour accder aux signaltiques des patients. /
Page 14/37

Projet MedicDB
Description
La secrtaire permet dajouter, de supprimer, de modifier, de consulter ou de rechercher des signaltiques de patients. Le mdecin pour sa part peut consulter ou rechercher des signaltiques de patients. Par signaltique de patient, nous entendons les informations suivantes : Numro national Nom Prnom Sexe (M/F) Date de naissance Tel Priv Tel Bureau Tel Mobile Email Rue Localit Ville Pays
Le Numro national est une information unique au sein du systme. Le systme doit permettre denregistrer une signaltique de patient dont certaines donnes ne seront connues que plus tard (cas dun rendez-vous pris par tlphone). Dans cette hypothse, le systme devra attribuer un numro unique indpendant du numro national.
3.5 Gestion des rendez-vous

La prise de rendez-vous est ltape oblige avant une consultation mdicale.
Page 15/37

Projet MedicDB
Figure 3-5: Gestion des rendez-vous Nom Rsum Acteurs UC07-Manage appointment Gestion des rendez-vous. Primaire: Secondaire: Liens Include Secrtaire Mdecin UC01-Login to the system UC02-Manage Staff UC04-Manage Type of Medical Consultation UC05-Manage the calendar UC06-Manage Patient Extend vnement dclencheur Pr-conditions Post-conditions Description /
Le patient se prsente la secrtaire pour demander un rendez-vous ou mettre jour un rendez-vous existant. Le mdecin consulte les rendez-vous existants. Lutilisateur sest correctement identifi au systme et possde les droits adquats pour accder au rendez-vous. / La secrtaire permet dajouter, de supprimer, de modifier, de consulter ou de rechercher des rendez-vous.
Page 16/37

Projet MedicDB
Le mdecin peut consulter ou rechercher des rendez-vous. Le systme doit permettre denregistrer la signaltique du patient dont certaines donnes ne seront connues que plus tard (cas dun rendezvous pris par tlphone). Dans cette hypothse, le systme devra attribuer un numro unique indpendant du numro national. Lors dune prise de rendez-vous, la secrtaire procde comme suit : la signaltique du patient est recherche dans le systme. La fiche du patient est cre ou modifie le cas chant (voir UC06-Manage Patient); la secrtaire consulte la demande de rendez-vous pour dterminer la spcialit, les examens demands et ventuellement le mdecin recommand ; le mdecin et/ou la spcialit sont recherchs dans le systme (voir UC02-Manage Staff) ; la secrtaire recherche les disponibilits dans le calendrier (voir UC05-Manage Calendar) proche des desiderata du patient en tenant compte de la dure moyenne de lexamen (voir UC04Manage Type of Medical Consultation): o soit pour une spcialit requise; o soit pour un mdecin spcifique ; o soit pour une date et heure prcise ; lorsquune date de rendez-vous est convenue, le calendrier du mdecin est modifi en consquence (UC05-Manage Calendar) avec les informations suivantes : o Identit du patient o Examens pratiquer o Date du rendez-vous o Heure du rendez-vous o Dure moyenne de lexamen
3.6 Gestion des examens mdicaux

Ce diagramme de cas reprsente les cas dutilisation intervenant dans le cadre dun examen mdical.
Page 17/37

Projet MedicDB
Figure 3-6: Gestion des examens mdicaux Nom Rsum Acteurs UC08-Manage Medical Examination Gestion des examens mdicaux. Primaire: Secondaire: Liens Include Mdecin / UC01-Login to the system UC06-Manage Patient UC07-Manage appointment UC09-Manage Medical Record Extend UC03-Manage Drugs UC10-Prescribe Additional Exam UC11-Prescribe Medication vnement dclencheur Pr-conditions Post-conditions Le patient se prsente la consultation. Le mdecin pratique lexamen mdical du patient. Lutilisateur sest correctement identifi au systme et possde les droits adquats pour accder au rendez-vous. /
Page 18/37

Projet MedicDB
Description
Lors du rendez-vous, le mdecin consulte la liste des rendez-vous pour identifier le patient et les examens demands ( UC07-Manage appointment). Le mdecin recherche la fiche du patient (UC06-Manage Patient) ainsi que son dossier mdical compos de ses antcdents (UC09Manage Medical Record). Pour chaque pathologie, le mdecin pourra retrouver les informations suivantes : Nom de la pathologie Date de dbut Date de fin ventuelle Liste des prescriptions (mdicaments, examens) La liste des mdicaments contre-indiqus
Lors de lexamen clinique, le mdecin peut valuer sil est requis de prescrire des mdicaments et/ou des examens cliniques supplmentaires. En cas de prescription dexamens cliniques (UC10-Prescribe Additional Exam), les informations suivantes seront reprises: Nom de lexamen Il nappartient au mdecin dorganiser la prise de rendez -vous pour le ou les examens cliniques. Le patient devra sadresser la secrtaire. En cas de prescription de mdicaments (UC11-Prescribe Medication), les informations suivantes seront reprises: Nom du mdicament Dure du traitement Posologie
De par sa formation, le mdecin est en mesure de dterminer les incompatibilits mdicamenteuses qui peuvent apparatre lors de ltablissement de la prescription ou en fonction des antcdents du patient (pathologies existantes). Pour saider dans cette a nalyse, le mdecin pourra consulter ou recherche dans la liste des mdicaments (UC03-Manage Drugs). Le mdecin mettra jour le dossier mdical du patient en y ajoutant les informations relatives la consultation. Ces informations seront ajoutes dans le cadre dune pathologie existante ou dune nouvelle pathologie (UC09-Manage Medical Record). On y retrouvera les informations suivantes:
Page 19/37

Projet MedicDB
Identifiant du mdecin Date et heure de la consultation Dure de la consultation Objet de la consultation Liste des examens pratiqus Prescription de mdicaments Prescription dexamens complmentaires
Page 20/37

Projet MedicDB
Diagrammes de cas squence
Cette section ne reprend que quelques diagrammes de squence qui ont pour objectif dillustrer les principes.
4.1 Authentification de lutilisateur

Laccs MedicDB ncessite dtre que lutilisateur soit correctement identifi par le systme.
Figure 4-1: Autentification de l'utilisateur
Page 21/37

Projet MedicDB
4.2 Cration dune signaltique patient

Le diagramme de squence suivant illustre les interactions ncessaires pour crer le signaltique dun patient.
Figure 4-2: Cration d'une signaltique patient
Page 22/37

Projet MedicDB
4.3 Cration dune signaltique patient (version dtaille)

Cet exemple dtaille la cration dune signaltique patient en faisant intervenir les classes de type boundary , control et entity .
Figure 4-3: Cration dun signaltique patient (dtaill)
Page 23/37

Projet MedicDB
Diagrammes de cas classes
La figure suivante reprsente le diagramme de classe du modle de donnes du systme MedicDB.
Figure 5-1: Diagramme de classe gnral Pour comprendre les diffrentes du modle de donnes, nous allons zoomer les principales fonctions du systme.
5.1 Authentification des utilisateurs

Les utilisateurs du systme sont dfinis dans la classe User.
Page 24/37

Projet MedicDB
Un utilisateur est identifi par son login et son mot de passe. La date de cration de lutilisateur est galement maintenue. Les droits dutilisation des fonctions du systme sont dfinis dans la classe Profiles. Nous pourrions retrouver des droits tels que : Administrateur : autorisation daccder toutes les fonctions du systme Crer fiche patient : autorisation daccder aux fonctions de cration d une signaltique patient Consulter dossier mdical : autorisation daccder au dossier mdical dun patient Etc.
Les autorisations de chaque utilisateur sont dfinies dans la classe dassociation UserProfile. Pour chaque profile, le droit est autoris (enabled = true) ou refus (enabled = false). Par dfaut, les droits ne sont pas autoriss.
Figure 5-2: Identification des utilisateurs
5.1.1 Liste des identifiants uniques Profile User UserProfile profileName login login + profileName
5.2 Personnel de la clinique

Pour simplifier, le personnel de la clinique est de type mdecin (classe Doctor) et secrtaire (classe Secretary). Nous partons du principe que le personnel mdical a un compte pour accder au systme MedicDB. Ce qui nous amne dire que du point de vue MedicDB, le personnel mdical est un utilisateur du systme (classe User) qui peut-tre de type mdecin ou secrtaire.
Page 25/37

Projet MedicDB
Figure 5-3: Personnel de la clinique Ceci nest videmment quun exemple. Nous aurions pu opter pour dautres approches telles que : Classe MedicalStaff reprenant les informations communes (Adresse, tlphone, etc.) qui serait la super-classe de Doctor et Secretary. Utiliser les classes Address et ContactInformation qui seraient utilises pour tre compos avec Doctor et Secretary. Ces classes seraient ainsi pures des informations gnrales (streetName, postalCode, city, country, homePhone, homePhone, workPhone, mobilePhone, emailAddress).
Nous voyons galement le lien entre Secretary et Doctor qui signifie quun mdecin na quune seule secrtaire, mais quune secrtaire peut se charger des tches administratives de plusieurs mdecins.
Page 26/37

Projet MedicDB
5.2.1 Liste des identifiants uniques Doctor Secretary numInami numStaff
5.3 Spcialits mdicales

Un mdecing (classe Doctor) a une spcialit (classe MedicalSpeciality). Les spcialits mdicales peuvent tre de diffrentes sortes : Mdecine gnrale Cardiologie Urologie ORL Chirurgie abdominale Optamologie Etc.
Figure 5-4: Spcialits mdicales 5.3.1 Liste des identifiants uniques
Page 27/37

Projet MedicDB
MedicalSpeciality
nameSpeciality
5.4 Agenda du mdecin

La classe Appointement est utilise pour maintenir les indisponibilits du mdecin dans son agenda. Une indisponibilit est identifie par : Une date (ex : 03/11/2011) Une heure de dbut (ex : 15h) Une heure de fin (ex : 16h15)
Un mdecin peut dfinir plusieurs indisponibilits. De son ct, une indisponibilit fait toujours rfrence un et un seul mdecin.
Figure 5-5: Agenda du mdecin 5.4.1 Liste des identifiants uniques Appointement dateAppointement + startTime + endTime + numInami
5.5 Signaltique des patients

Les patients sont maintenus dans la classe Patient.
Page 28/37

Projet MedicDB
Figure 5-6: Signaltique des patients La figure suivante montre quun patient peut avoir un mdecin traitant. Ce lien est dfini au travers de lassociation physician. Un mdecin par contre peut-tre mdecin traitant de plusieurs patient. La cardinalit 0..1 entre Patient et Doctor montre que lon peut dfinir une signaltique dun nouveau patient sans connatre au pralable lidentit de mdecin traitant.
Figure 5-7: Mdecin traitant
5.5.1 Liste des identifiants uniques Patient numRegistreNational
Page 29/37

Projet MedicDB
5.6 Rendez-vous des patients

Avant de pouvoir confirmer la date et lheure de rendez -vous dun patient, lutilisateur vrifiera si le mdecin en question na pas dj introduit une indisponibilit pour la priode souhaite. En cas de succs, un nouveau rendez-vous (Appointement) sera introduit pour le patient (Patient) pour la priode souhaite et pour le mdecin concern (Doctor). La cardinalit 0..1 entre Appointement et Patient stipule quune entre dans Appointement peut exister sans faire intervenir de patient. Danc ce cas, nous sommes dans la situation dune entre dfinissant une indisponibilit dun mdecin.
Figure 5-8: Rendez-vous des patients
5.7 Dure moyenne des examens

Pour dterminer le temps moyen que prendrait un examen mdical, le systme rpertorie une liste de procdure mdicale (classe MedicalProcedure) dfinie par spcialit (classe MedicalSpeciality) et pour chacune delle la dure moyenne de consultation. Exemple : Spcialit Cardiologie Laboratoire Procdure mdicale exercice deffort Prise de sang Dure moyenne (minutes) 30 10
Page 30/37

Projet MedicDB
Figure 5-9: Dure moyenne des procdures mdicales
5.7.1 Liste des identifiants uniques MedicalProcedure nameSpeciality + nameProcedure
5.8 Dossier mdical du patient

Un patient possde un dossier mdical (classe MedicalRecord) qui reprend lhistorique de ses visites, de ses pathologies et des traitements et des examens quil a reus.
Page 31/37

Projet MedicDB
Figure 5-10: Dossier mdical
5.9 Dossier mdical

Le mdecin (classe Doctor) consulte son agenda (classe Appointement) pour dterminer lidentit du prochain patient (classe Patient). Le mdecin accde au dossier mdical du patient (classe MedicalRecord). Le dossier mdical rpertorie lensemble des examens mdicaux (classe MedicalExam) ralis par les mdecins une date donne. Le mdecin rdige lobjet de la consultation et les observations qui sy rapportent.
Page 32/37

Projet MedicDB
Figure 5-11: Dossier mdical
5.10 Examen clinique

Lors de lexamen clinique, des pathologies (classe Pathology) peuvent tre identifies qui conduiront des examens cliniques additionnels (classe ExaminationPrescription) et/ou des prescriptions mdicamenteuses (classe DrugsPrescription). Pour chaque mdicament (classe DrugsPosology) sera tablie. Drugs) de la prescription, une posologie (classe
Le mdecin renforcer son examen clinique en vrifiant les incompatibilits mdicamenteuses qui pourraient intervenir dans le traitement labor pour le patient.
Page 33/37

Projet MedicDB
Figure 5-12: Examen clinique
Page 34/37

Projet MedicDB
Annexe
6.1 Exemple de cas dutilisation

Nom Rsum Acteurs Primaire: Secondaire: Liens Include Extend vnement dclencheur Pr-conditions Post-conditions Description Scnario nominal tape # Actions acteur (vnement externe) Rponse du systme
Scnarios alternatifs tape # 2.a 2.a.1 2.b 2.b.1 2.b.2 Action alternative acteur Rponse alternative systme
Page 35/37

Projet MedicDB
Page 36/37

Projet MedicDB
PublicErreur ! Nom de proprit de document inconnu. References
Acronyms
UML WAD11
Unified Modeling Language Web Application Developer Promotion 2011
Page 37/37

Medicdb PDF

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Medicdb PDF

Enviado por

Direitos autorais:

Formatos disponíveis

ANALYSE UML

Document d'analyse UML

Dossier d'analyse UML pour la ralisation du projet MedicDB.

Keywords WAD11, UML, DB Classification Public

Document d'analyse UML

I/U/R/D I/U/R/D I/U/R/D I/U/R/D

(*) Action: I = Insert, R = Replace, U = Update, D = Delete, Q = Quality Review

Document d'analyse UML

DIAGRAMMES DE CAS SEQUENCE ........................................................................ 21 4.1 4.2 4.3

Document d'analyse UML

Document d'analyse UML

Document d'analyse UML

Cahier des charges

Document d'analyse UML

Diagrammes de cas dutilisation

3.1 Se connecter au systme

Document d'analyse UML

vnement dclencheur Pr-conditions Post-conditions Description

tape # 2.a 2.a.1 2.a.2

Action alternative acteur

Document d'analyse UML

3.2 Administration du systme

Document d'analyse UML

Secondaire: Liens Include Extend vnement dclencheur Pr-conditions Post-conditions Description

/ UC01-Login to the system /

Le Login est un identifiant unique dans le systme.

Nom Rsum Acteurs

UC03-Manage Drugs Gestion des mdicaments. Primaire: Secondaire: Administrateur /

Document d'analyse UML

UC01-Login to the system /

vnement dclencheur Pr-conditions Post-conditions Description

Nom Rsum Acteurs

vnement dclencheur Pr-conditions Post-conditions

Document d'analyse UML

Le Nom est un identifiant unique dans le systme.

3.3 Gestion du calendrier

Document d'analyse UML

3.4 Gestion des patients

Document d'analyse UML

3.5 Gestion des rendez-vous

Document d'analyse UML

Document d'analyse UML

3.6 Gestion des examens mdicaux

Document d'analyse UML

Document d'analyse UML

Document d'analyse UML

Document d'analyse UML

Diagrammes de cas squence

4.1 Authentification de lutilisateur

Figure 4-1: Autentification de l'utilisateur

Document d'analyse UML

4.2 Cration dune signaltique patient

Figure 4-2: Cration d'une signaltique patient

Document d'analyse UML

4.3 Cration dune signaltique patient (version dtaille)

Figure 4-3: Cration dun signaltique patient (dtaill)

Document d'analyse UML

Diagrammes de cas classes

La figure suivante reprsente le diagramme de classe du modle de donnes du systme MedicDB.

5.1 Authentification des utilisateurs

Document d'analyse UML

Figure 5-2: Identification des utilisateurs

5.2 Personnel de la clinique