UMTS/FST/DMI Master1 : RISR

UML : Diagrammes des cas d’utilisations

1. Qu’est ce qu’un cas d’utilisation?

Un cas d’utilisation (use case) représente un ensemble de séquences d’actions réalisées par le
système et produisant un résultat observable intéressant pour un acteur particulier, il modélise
un service rendu par le système. Il exprime les interactions acteurs/système et apporte une
valeur ajoutée « notable » à l’acteur concerné.
Exemples: Achat billet, Ouverture compte, Livraison Client,Traiter commande, établir facture…
2. Acteur
Un acteur représente le rôle joué par quelque chose ou quelqu’un se trouvant dans
l’environnement du système étudié.il est en relation avec le métier de l’entreprise et interagit
avec le système dans différents cas d’utilisation , Il peut être un élément de la structure de
l’entreprise tel qu’une direction, un service ou un poste de travail

2.1 Types d’acteurs

Par défaut, le rôle d’un acteur est « principal ». Si ce n’est pas le cas on peut indiquer le rôle «
secondaire » sur l’acteur, Si un acteur a pour rôle unique de consommer des informations du
système sans modifier l’état de celui-ci au niveau métier alors son rôle est secondaire. Un
acteur peut aussi être un périphérique externe ou un système externe.

3. La portée des cas d’utilisation :

Les Cas d’utilisation interviennent tout au long du cycle de vie d’un projet
Exemple : DCU fig 2
4. Realation entre cas d’utilsation
1. Inclusion entre cas d’utilisation
Identifiez une partie commune aux différents cas d’utilisation et factorisez-la dans un
nouveau cas inclus dans ces derniers.
A « include » B : Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A
Fig3
2. Extension entre cas d’utilisation
On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A
peut être appelé au cours de l’exécution du cas d’utilisation B. Exécuter B peut
éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est
optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >>
Fig4
3. Relation de généralisation
Un cas A est une généralisation d’un cas B si B est un cas particulier de A. la
consultation d’un compte via Internet est un cas particulier de la consultation. Cette
relation de généralisation/spécialisation est présente dans la plupart des diagrammes
UML et se traduit par le concept d’héritage dans les langages orientés objet.
 5. Relations entre acteurs
La seule relation possible entre deux acteurs est la généralisation : un acteur A est une
généralisation d’un acteur B si l’acteur A peut être substitué par l’acteur B. Dans ce cas,
tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai.

Par exemple, la figure montre que le directeur des ventes est un préposé aux commandes avec un
pouvoir supplémentaire : en plus de pouvoir passer et suivre une commande, il peut gérer le stock. Par
contre, le préposé aux commandes ne peut pas gérer le stock.
 TD_4 : Cas d’utilisation
Exercice01 :
1°) Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi que du matériel
pédagogique (ordinateur portable ou/et Vidéo projecteur).Seuls les enseignants sont habilités à effectuer
des réservations (sous réserve de disponibilité de la salle ou du matériel).Le planning des salles peut quant
à lui être consulté par tout le monde (enseignants et étudiants).Par contre, le récapitulatif horaire par
enseignant (calculé à partir du planning des salles) ne peut être consulté que par les enseignants. Enfin, il
existe pour chaque formation un enseignant responsable qui seul peut éditer le récapitulatif horaire pour
l’ensemble de la formation.
Modéliser cette situation par un diagramme de cas d’utilisation

Consulter planning

U tilis ate ur s alle Cons ulter ré c ap hor air e e ns e ig nant

Réservation salle
Réservation

Enseignant

« include »
Réserver matériel

Vérification disponibilité

Responsable formation
Réserver vidéo Réserver portable

Editer récap formation