Rapport

Intermédiaire UML:
Gestion de Clinique
Réalisé par :
Gorrab Firas
Ebdelli Khaled
Chetali Houda
Encadré par :

2014/2015
ECOLE SUPERIEURE PRIVEE D’INGENIERIE ET DE TECHNOLOGIES

Projet en UML

« Gestion Clinique »

Réalisé par :
Chetali Houda
Gorrab Firas
Ebdelli Khaled

Encadré par :
Mme. Sfaxi Henda
 Sommaire
1. Introduction
2. Etude fonctionnelle
2.1 Diagramme de contexte statique
2.2 Diagramme de cas d’utilisation
2.2.1. Diagramme de cas d’utilisation global
2.2.2. Diagramme de cas d’utilisation raffiné
2.3 Diagramme de séquence système
2.4 Description textuelle
3. Etude statique
3.1 Diagramme de classe
 1. Introduction
Ce projet de <<gestion de clinique>> élaboré au sein du module UML
consiste à étudier le système de gestion d’une clinique de façon à ce que ses
fonctionnalités soient dégagées par rapport aux besoins pour pouvoir le
concevoir et implémenter son code.

2. Etude fonctionnelle :
2.1 Diagramme de contexte statique :
Le diagramme de contexte statique délimite le domaine d’étude en précisant
 ce qui est à la charge du système et
 en identifiant l’environnement extérieur au système étudié avec lequel ce dernier
communique.

 Les acteurs externes. Un acteur externe est un entité externe au système étudié qui
Ses composants sont :

 Un processus unique symbolisant le Système Information étudié :

interagit avec le système.

 Echange entre le système étudié et son environnement

Figure 1 diagramme de contexte statique

2.2 Diagramme de cas d’utilisation :

Les diagrammes de cas d'utilisation sont des diagrammes UML utilisés pour
donner une vision globale du comportement fonctionnel d'un
système logiciel. Ils sont utiles pour des présentations auprès de la direction
ou des acteurs d'un projet, mais pour le développement, les cas
d'utilisation sont plus appropriés. Un cas d'utilisation représente une unité
discrète d'interaction entre un utilisateur (humain ou machine) et un système.
Il est une unité significative de travail. Dans un diagramme de cas
d'utilisation, les utilisateurs sont appelés acteurs (actors), ils interagissent
avec les cas d'utilisation (use cases).

2.2.1. Diagramme de cas d’utilisation global :

Figure 2 : diagramme de cas d'utilisation global

2.2.2. Diagramme de cas d’utilisation raffiné :

Figure 3: diagramme de cas d'utilisation détaillé

 2.4 Description textuelle :

Le diagramme de cas d'utilisation décrit les grandes fonctions d'un système du point de vue des
acteurs, mais n'expose pas de façon détaillée le dialogue entre les acteurs et les cas d'utilisation.
Bien que de nombreux diagrammes d'UML permettent de décrire un cas, il est recommandé de
rédiger une description textuelle, car c'est une forme souple qui convient dans bien des situations.

Une description textuelle couramment utilisée se compose de trois parties.

1. La première partie permet d'identifier le cas, elle doit contenir les informations qui suivent.

Nom :

o utiliser une tournure à l'infinitif (ex. : Réceptionner un colis).

Objectif :

o une description résumée permettant de comprendre l'intention principale du cas

d'utilisation. Cette partie est souvent renseignée au début du projet dans la phase
de découverte des cas d'utilisation.

Acteurs principaux :

o ceux qui vont réaliser le cas d'utilisation (la relation avec le cas d'utilisation est
illustrée par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas
d'utilisation).

Acteurs secondaires :

o ceux qui ne font que recevoir des informations à l'issue de la réalisation du cas
d'utilisation.
2. séquence nominale) et des séquences d'exceptions (qui interviennent quand une erreur se
produit).

Les préconditions :

o elles décrivent dans quel état doit être le système (l'application) avant que ce cas
d'utilisation puisse être déclenché.

Des scénarios :

o ces scénarios sont décrits sous la forme d'échanges d'événements entre l'acteur et
le système. On distingue le scénario nominal, qui se déroule quand il n'y a pas
d'erreur, des scénarii alternatifs qui sont les variantes du scénario nominal et enfin
les scénarii d'exception qui décrivent les cas d'erreurs.
 Des post conditions :

o elles décrivent l'état du système à l'issue des différents scénarii.

Titre créer un dossier temporaire

Acteurs Personnel administratifs / Médecin de garde
Pré condition authentification possible
Scenario nominal 1-le médecin de garde demande l'interface voulue
2-le système affiche l'interface voulue
3-Le personnel saisie les informations
4-verification des données
5- enregistrement des données
6-notfier enregistrement réussi
Scenario alternatif 1- mettre a jours les dossiers temporaire
2- Le médecin saisie les nouvelles informations
3-Retour à l’étape du sce ario o i al
(2)
1- Le personnel oublie de saisir un champ obligatoire
2-Retour à l’étape du sce ario o i al
Scenario dossier déjà existant
d’exception
Post condition Le système enregistre les nouvelles modifications avec
succès
 Titre créer un dossier médical
Acteurs secrétaire
Pré condition authentification possible
Scenario nominal 1-la secrétaire saisie l'interface voulue
2- enregistrement des données
3-envoie des données
Scenario alternatif 1- mettre a jours les données
2- la secrétaire saisie les nouvelles informations
3-Retour à l’étape du sce ario o i al

Scenario dossier déjà existant

d’exception
Post condition Le système enregistre les nouvelles modifications Le
personnel saisie les informations

Titre ajouter lettre de sortie

Acteurs médecin traitant
Pré condition authentification possible
Scenario nominal 1-le médecin traitant demande l'interface voulue
2-le système affiche l'interface demandée
3 le médecin saisi la lettre de sortie
4- enregistrement

Scenario alternatif 1- oublie de saisir une information importante

2-retore a l’étape
3- Le médecin saisie les nouvelles informations

Post condition Le système enregistre les nouvelles modifications avec

succès /fermeture du dossier

Titre envoyer facture

 Acteurs Personnel administratifs
Pré condition authentification possible
Scenario nominal 1-personnel administratif demande l'interface
voulue
2-le système affiche l'interface
3-Le personnel saisie les informations
4-verification des données
5- enregistrement des données
6-notfier enregistrement réussi
Scenario alternatif 1- modifier la facture
2- Personnel administratifs saisie les nouvelles
informations
3-Retour à l’étape du sce ario o i al

Scenario facture déjà existant

d’exception
Post condition Le système enregistre les nouvelles modifications avec
succès

Titre archiver dossier

Acteurs Personnel administratifs
Pré condition S’authe tifier
Scenario nominal 1-Affichage du menu
2-Un personnel administratif demande de créer un
dossier archivé
3-Le personnel saisie les informations
4-Le système vérifie les données introduites
Scenario alternatif (1)
1- Personnel administratifs choisit de mettre à jour un
dossier archivé
2- Le médecin saisie les nouvelles informations
3-Retour à l’étape du sce ario o i al

Scenario archiver un dossier déjà existant

d’exception
Post condition Le système enregistre les nouvelles modifications avec
succès
 2.3 Diagramme de séquence système :

Les diagrammes de séquences sont la représentation graphique

des interactions entre les acteurs et le système selon un ordre chronologique
dans la formulation Unified Modeling Language.

Il permet de cacher les interactions d'objets dans le cadre d'un scénario

d'un Diagramme des cas d'utilisation. Dans un souci de simplification, on
représente l'acteur principal à gauche du diagramme, et les acteurs secondaires
éventuels à droite du système. Le but étant de décrire comment se déroulent les
actions entre les acteurs ou objets.
La dimension verticale du diagramme représente le temps, permettant de
visualiser l'enchaînement des actions dans le temps, et de spécifier la naissance
et la mort d'objets. Les périodes d'activité des objets sont symbolisées par des
rectangles, et ces objets dialoguent par le biais de messages.

Figure 4: diagramme séquence : envoyer demande prestation

Figure 5 diagramme séquence : consulter dossier médical
Figure 6 : diagramme séquence : créer dossier médical
3. Etude statique :
3.1. Diagramme de classe :
Le diagramme de classes est un schéma utilisé en génie logiciel pour présenter
les classes et les interfaces des systèmes ainsi que les différentes relations entre
celles-ci. Ce diagramme fait partie de la partie statique d'UML car il fait
abstraction des aspects temporels et dynamiques.
Une classe décrit les responsabilités, le comportement et le type d'un ensemble
d'objets. Les éléments de cet ensemble sont les instances de la classe.
Une classe est un ensemble de fonctions et de données (attributs) qui sont liées
ensemble par un champ sémantique. Les classes sont utilisées dans
la programmation orientée objet. Elles permettent de modéliser un programme et
ainsi de découper une tâche complexe en plusieurs petits travaux simples.
Les classes peuvent être liées entre elles grâce au mécanisme d'héritage qui
permet de mettre en évidence des relations de parenté. D'autres relations sont
possibles entre des classes, chacune de ces relations est représentée par un arc
spécifique dans le diagramme de classes.
Elles sont finalement instanciées pour créer des objets (une classe est un moule à
objet : elle décrit les caractéristiques des objets, les objets contiennent leurs
valeurs propres pour chacune de ces caractéristiques lorsqu'ils sont instanciés).