Vous êtes sur la page 1sur 5

Chapitre 3

Diagramme de cas
d’utilisation
Objectifs:
• Connaître l’utilité d’un diagramme de cas d’utilisation;
• Connaître les éléments d’un diagramme de cas d’utilisation;
• Savoir identifier les besoins et les représenter par un
diagramme de cas d’utilisation.
Mots clés:
Cas d’utilisation Acteur Besoin fonctionnel
Héritage Extension Inclusion 21

Chapitre 3: Diagramme de cas d’utilisation

Définition
Le diagramme des cas d’utilisation représente la structure des
grandes fonctionnalités nécessaires aux utilisateurs du système.

Éléments d’un diagramme de cas d’utilisation


Cas d’utilisation

Les cas d’utilisation permettent d’exprimer les besoins des


utilisateurs d’un système. Il permet de décrire ce que le futur
système devra faire, sans spécifier comment il le fera.

ajouter ligne facture

Figure 3.1: Représentation graphique d’un cas d’utilisation.


22

1
Chapitre 3: Diagramme de cas d’utilisation

Acteur

Un acteur est une entité externe qui interagit directement


avec le système étudié. Il peut être:
 Un utilisateur humain direct;

Figure 3.2: Représentation graphique d’un acteur humain.


Caissier
 un autre système connexe qui interagit directement avec
le système étudié

«actor»
Figure 3.3: Représentation graphique d’un acteur système.
SI Banque

23

Chapitre 3: Diagramme de cas d’utilisation

Relations dans les diagrammes de cas d’utilisation

Relations entre acteurs et cas d’utilisation

La relation entre un acteur et un cas d’utilisation est


dite association.

ajouter ligne facture

Caissier
Figure 3.4: Représentation graphique d’une association.

Quand un cas n’est pas directement relié à un acteur, il


est qualifié de cas d’utilisation interne.
24

2
Chapitre 3: Diagramme de cas d’utilisation

Relations entre cas d’utilisation

Relation d’inclusion

Un cas A inclut un cas B si le comportement décrit par le cas A


inclut le comportement du cas B : le cas A dépend de B. Lorsque
A est sollicité, B l’est obligatoirement, comme une partie de A.
«include»
ajouter ligne facture chercher produit

Caissier
Figure 3.5: Représentation graphique d’une relation d’inclusion.

Les inclusions permettent essentiellement de factoriser une


partie de la description d’un cas d’utilisation qui serait commune
à d’autres cas d’utilisation.
Les inclusions permettent également de décomposer un cas
complexe en sous-cas plus simples. 25

Chapitre 3: Diagramme de cas d’utilisation

Relation d’extension

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: contrairement à l’inclusion,
l’extension est optionnelle.
Une extension est souvent soumise à condition. Graphiquement,
la condition est exprimée sous la forme d’une note.

«e xte nd»
a jo uter l igne fa ture m od ifier qua ntité

C aissier
Co nd ition :{q ua ntité>1 }

Figure 3.6: Représentation graphique d’une relation d’extension.


26

3
Chapitre 3: Diagramme de cas d’utilisation

Relation d’héritage

Un cas A est une généralisation d’un cas B si B est un cas particulier


de A.

règlement espèces

régler facture règlement par chèque

règlement par carte

Figure 3.7: Représentation graphique d’une relation d’héritage entre cas d’utilisation.

27

Chapitre 3: Diagramme de cas d’utilisation

Relations entre acteurs


La seule relation possible entre deux acteurs est la
généralisation (héritage) .

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.

Caissier

Figure 3.8: Représentation graphique d’une


relation d’héritage entre acteurs. Gérant

28

4
Chapitre 3: Diagramme de cas d’utilisation

Représentation d’un diagramme de cas d’utilisation

Système de caisse enregistreuse


«include» chercher produit
ajouter ligne facture «extend»
modifier quantité
Caissier
régler facture
réglement espèces

réglement par chèque

«actor»
réglement par carte
SI banque

éditer récapitulatif des caisses


Gérant

Figure 3.9: Représentation graphique d’un diagramme de cas d’utilisation. 29

Chapitre 3: Diagramme de cas d’utilisation

Activité
Un gérant d’une bibliothèque désire automatiser la gestion des prêts. Les
besoins des utilisateurs sont exprimés comme suit :
 Commander un logiciel permettant aux utilisateurs de connaître les livres
disponibles, d'en réserver jusqu'à 2. A travers ce logiciel, l'adhérent peut
connaître la liste des livres qu'il a empruntés ou réservés ;
 Tout adhérent possède un mot de passe qui lui est donné à son inscription ;
 Un emprunt est toujours réalisé par les employés qui travaillent à la
bibliothèque. Après avoir identifié l'emprunteur, ils savent si le prêt est
possible (nombre max de prêts = 5), et s'il a la priorité (il est celui qui a
réservé le livre) ;
 Ce sont les employés qui mettent en bibliothèque les livres rendus et les
nouveaux livres. Il leur est possible de connaître l'ensemble des prêts
réalisés dans la bibliothèque.
Travail demandé :
Elaborer un diagramme de cas d’utilisation décrivant les besoins
des utilisateurs de ce système. 30

Vous aimerez peut-être aussi