Conception et réalisation d’un système d’information pour le recouvrement des factures au sein d’une institution sanitaire. Cas du centre de santé Mapendo.

III.5. DIAGRAMME DE SEQUENCES

^{Remise Facture()}

^{EtablirFacture()}

				^Application
^Patient	^Receptionniste InfirmierTraitant InfirmierTitulaire Gestionnaire Facture

^{DemanderSoins()}

^{PatientIdentifier()}

^{OrienterPatient()}

^{ExplicationMaladie()}

^{ConsultationPatient()}

^{PresentationPatient()}

^{ExamenPatient()}

^{Hospitalisation/PrescritionMedicament()}

^{ResultatPrelevé()}

^{ResultatPrelevé()}

^{PaiementFacture()}

^Ajouter()

^Supprimer()

^Modifier()

^Imprimer()

^{sd Sequence}

Ce diagramme permet de décrire les scénarios de chaque cas d'utilisation en mettant l'accent sur la chronologie des opérations en interaction avec les objets²⁴.

²⁴ Joseph Gabay et David Gabay, Mise en oeuvre guidée avec études de cas, édition Dunod, Paris 2008, p 11.

51

· Scénario: Représente une succession particulière d'enchaînements, s'exécutant du début à la fin du cas d'utilisation, un enchaînement étant l'unité de description de séquences d'actions²⁵.

· Ligne de vie : Représente l'ensemble des opérations exécutées par un objet²⁶.

· Message: Un message est une transmission d'information unidirectionnelle entre deux objets, l'objet émetteur et l'objet récepteur. Dans un diagramme de séquence, deux types de messages peuvent être distingués :

> Message synchrone : Dans ce cas l'émetteur reste en attente de la réponse à son message avant de poursuivre ses actions²⁷.

> Message asynchrone : Dans ce cas, l'émetteur n'attend pas la réponse à son message, il poursuit l'exécution de ses opérations²⁸.

²⁵ Pascal ROQUES, UML 2 par la pratique étude de cas et exercices corrigés, ÉDITIONS EYROLLES, Septembre 2006, p 18.

26 Joseph Gabay et David Gabay, Mise en oeuvre guidée avec études de cas, édition Dunod, Paris 2008, p 91et/ou 106.

²⁷ Ibid.

²⁸ Ibid.

52

III.6. DIAGRAMME DE COMMUNICATION

^{sd Communication}

^Patient

^facture

^{1. Accueil}

^Patient

^{2. identifier}

^patient

^{8. Consultation} +

^EXamens

^{Receptionniste}

^{11. Paiement}

^facture

^Gestionnaire

^{9. Hospitaliser} /

^Non

^{InfirmierTraitant}

^{4. orienter}

^patient

^{3. Enregistrer}

^{10. Elaborer}

^facture

^{5. dianostic}

^{6. dianostic}

^envoye

^{InfirmierTitulaire}

^Application

^{12. Remise}

Ce diagramme est une autre représentation des scénarios des cas d'utilisation qui met plus l'accent sur les objets et les messages échangés.

53

III.7. DIAGRAMME D'ACTIVITES

^{act Activite}

	^InfirmierTraitant			^InfirmierTitu			^Gestionnaire
^Receptionniste
^Identification ^patient
			^patient
			^Hospitalisation ^gueri]

54

Ce diagramme donne une vision des enchaînements des activités propres à une opération ou à un cas d'utilisation. Il permet aussi de représenter les flots de contrôle et les flots de données²⁹.

· Action : correspond à un traitement qui modifié l'état de système. L'enchaînement des actions constitue le flot de contrôle³⁰.

· Le passage d'une action à une autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d'une action et provoquent le début d'une autre (elles sont automatiques)³¹.

· Activité : représente le comportement d'une partie du système en termes d'actions et

de transitions³².