Vous êtes sur la page 1sur 18

Leçon n° 1 : Diagramme de cas d’utilisation

Introduction
La modélisation des besoins d’un système implique de définir ce qu’il doit
faire, d’un point de vue externe au système, sans avoir à préciser comment. Dans ce
cas, on élabore le diagramme de cas d’utilisation pour spécifier le comportement
attendu du système. Ainsi, un diagramme de cas d’utilisation permet de visualiser le
système entier comme une boite noire, permettant de voir ce qui se passe à l’extérieur
du système ainsi que la façon dont le système réagit par rapport aux éléments
externes. Le diagramme de cas d'utilisation permet de décrire l'interaction entre le
système et un acteur (utilisateur du système). C'est un moyen de recueillir et de
décrire les besoins des acteurs du système.

I. Formalisme
La figure n°1, ci-dessous, illustre un diagramme de cas d’utilisation d’un
système de distribution de billets automatique. Le système à modéliser apparait dans
un cadre, les utilisateurs sont représentés par des petits bonshommes et les grandes
fonctionnalités (les cas d’utilisation) par des ellipses. L’ensemble des cas d’utilisation
contenus dans le cadre constitue le système. Les petits bonhommes sont appelés des
acteurs. Ils sont connectés au système par des simples traits appelés associations aux
cas d’utilisation et mettant en évidence les interactions possibles entre le système et le
monde extérieur. Chaque cas d’utilisation modélise une façon particulière et
cohérente d’utiliser un système pour un acteur donné.
System

Retirer argent

Client

Consulter Compte

Figure n°1 : Diagramme de cas d’utilisation modélisant un système DAB


I.1 Le système
Le système constitue le domaine d’étude, il est entouré par un cadre à fin de séparer
le système à modéliser du domaine extérieur.
Exemples de système :

 Système de gestion d’octroi des crédits


 Système de gestion d’un parc informatique, etc.

I.2 Acteur

I.2.1 Définition
Un acteur est un utilisateur du système. Il représente un ensemble cohérent de rôles
joués par les utilisateurs vis-à-vis du système. Un acteur communique et interagit avec les
cas d'utilisation du système en échangeant des messages. Un acteur représente un
rôle qu’un homme, une machine ou un même un autre système joue avec le système.
Exemple : Une personne qui travaille pour une banque sera le Gestionnaire de Prêts. Si elle a
son compte dans la même banque, elle jouera aussi le rôle du Client.

System

Cas d'utilisation

Rôle de l'acteur

Figure n°2 : Notation d’un acteur dans un diagramme de cas d’utilisation


Remarques :

R1) Il ne faut pas confondre un acteur et une personne utilisant le système, en effet :

 Une même personne peut jouer plusieurs rôles par rapport au système étudié
et être modélisée par plusieurs acteurs. Par exemple, une personne qui
travaille pour une banque aura le rôle Gestionnaire de prêts. Si elle a un
compte dans la même banque, elle jouera aussi le rôle du Client.
 Plusieurs personnes peuvent jouer un même rôle. Elles seront alors modélisées
par le même acteur.
 Un acteur n’est pas forcément une personne physique.

R2) Chaque acteur du système doit être nommé, Pour lui attribuer un nom, il faut
penser à son rôle vis-à-vis d’un système. Ainsi, pour un logiciel de gestion de
paie le nom correct de l’acteur est Comptable plutôt que Mr X. Le nom d’un
acteur peut être accompagné d’une brève description textuelle.
Figure n°3 : Commentaire décrivant le rôle de l’acteur « Guichetier » dans le système
bancaire

I.2.2 Types d’acteurs


En plus des utilisateurs humains qui utilisent le système à travers une
interface graphique, les acteurs peuvent être :

 Des logiciels : Ce sont des logiciels externes au système et qui communiquent


avec lui. Par exemple le Système de carte visa dans le cas d’un système de
vente en ligne
 Des matériels : Ce sont les périphériques manipulés par le système. Par
exemple des robots ou des automates qui envoie des données au système ou
qui est piloté par le système.

I.3 Cas d’utilisation (use case)

I.3.1 Définition
Un Cas d’utilisation :

 Est une représentation d’une fonctionnalité (ensemble des actions) réalisées par le
système en réponse à une action d’un acteur.
 Constitue une description du comportement (actions +réactions) du système du
point de vue de son utilisateur.
 Est une suite d’interactions entre un acteur et le système.
 Permet d’atteindre un objectif aux yeux de l’utilisateur.
 Doit être utile.

Le cas d'utilisation est connecté à un acteur à travers une association représentée


par une ligne continue :

Remarque :

Un cas d’utilisation est caractérisé par :

 Un nom : Utiliser un verbe à l’infinitif (Ex : Réceptionner un colis)


 Des acteurs principaux : Ce sont les utilisateurs qui utilisent les fonctionnalités
principales du système à travers l’interface graphique du système.
 Des acteurs secondaires : qui regroupent les personnes qui exécutent les tâches
administration ou de maintenance.
Figure n°4 : Exemples de diagramme d’utilisation
I.3.2 Cas d’utilisation et scénarios
Un cas d’utilisation est une collection de scénarios de succès ou d’échec qui
décrit la façon dont un acteur particulier utilise un système pour atteindre un
objectif. Un scénario est une séquence spécifique d’actions qui illustre le
comportement. Les scénarios sont aux cas d’utilisation ce que les objets sont aux
classes : ils sont en fait des instances des cas d’utilisation. Le diagramme de cas
d’utilisation décrit les grandes fonctionnalités 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. On distingue trois types de scénarios :

 Un scénario nominal : celui qui satisfait les objectifs des acteurs par le chemin le
plus direct de succès.
 Un scénario alternatif : Il diverge du scénario nominal. C’est un embranchement
dans un scénario nominal mais y revient toujours et il possède une fin normal.
 Un scénario d’exception : Il intervient quand une erreur se produit. le scénario
nominal s’interrompt, sans retour au scénario nominal. Il s’agit d’un échec.

Figure n°5 : Illustration graphique des scénarios d’un cas d’utilisation


Chaque scénario est composé d’étapes qui peuvent être de trois sortes :
 un message d’un acteur vers le système,
 une validation ou un changement d’état du système,
 un message du système vers un acteur.
Les étapes sont numérotées séquentiellement afin de pouvoir facilement indiquer
par la suite les alternatives possibles
Exemple de scénarios nominal :

Cas d’utilisation : Retirer de l’argent au distributeur (DAB) avec une carte


bancaire.
1. Le client introduit sa carte dans le DAB.
2. Le DAB vérifie que la carte introduite est bien une carte bancaire.
3. Le DAB demande au client de fournir son code d’identification.
4. Le client entre son code d’identification.
5. Le DAB valide le code d’identification.
6. Le DAB demande une autorisation au système d’autorisation externe.
7. Le système d’autorisation externe donne son accord et indique le solde
hebdomadaire.
8. Le DAB demande au client de saisir le montant désiré du retrait.
9. Le client saisit son montant de retrait.
10. Le système vérifie que le montant de retrait est autorisé.
11. Le système délivre au client l’argent et la carte bancaire.

Exemple de scénarios d’alternatif :

5a. Le DAB détecte que le code saisi est erroné, pour la première ou deuxième fois.
1. Le DAB indique au client que le code est erroné.
2. Le DAB enregistre l’échec de l’opération et le cas d’utilisation reprend à
l’étape 4 du scénario nominal.

Exemple de scénarios d’exception :

2a. La carte introduite n’est pas reconnue par le DAB.


1. Le DAB éjecte la carte et le cas d’utilisation se termine en échec.
5b. Le DAB détecte que le code saisi est erroné, pour la troisième fois.
1. Le DAB indique au client que le code est erroné pour la troisième fois.
2. Le DAB confisque la carte.
3. Le DAB informe le système d’autorisation externe et le cas d’utilisation se
ter mine en échec.
I.4 Organisation des cas d’utilisation
Pour clarifier un diagramme, UML permet d’établir des relations entre les cas
d’utilisation. Il existe principalement deux types de relations permettant d’organiser
les cas d’utilisations :
 Les dépendances stéréotypées : sont des dépendances dont la portée est
explicitée par le nom du stéréotype. Les stéréotypes les plus utilisés
sont l’inclusion : <<include>> et l’extension <<extend>>.
 La généralisation.

I.4.1 Relation d’inclusion


Un cas A est inclus dans un cas B, illustré par le stéréotype <<include>>, si le
comportement décrit par le cas A est inclus dans le comportement du cas B : on dit
alors que le cas B
dépend de A.

Figure n°6 : Formalisme de la relation d’inclusion entre cas d’utilisation

Les liens d’utilisation permettent de :


 Factoriser les cas d’utilisation qui peuvent servir pour d’autres cas
d’utilisation, en faisant l’extraction d’une séquence d’interactions communes
présentes dans le scénario de plusieurs cas d’utilisation.
Exemple :

Figure n°7 : Relation de dépendance « include » entre cas d’utilisation pour Factoriser les
cas d’utilisation
 Simplifier les cas d’utilisations en montant leur décomposition
Exemple :

Figure n°8 : Relation de dépendance « include » entre cas d’utilisation pour décomposer
un cas complexe
Remarques :

R1) Le cas d’utilisation inclus n’est jamais tout seul, il fait toujours partie d’un cas
d’utilisation qui l’englobe.

R2) L’inclusion peut être assimilée au cas d’utilisation principal qui tire un comportement du
cas d’utilisation fournisseur.

I.4.2 Relation d’extension


Si le comportement d’un cas d’utilisation B peut être étendu par le
comportement du cas d’utilisation A, on dit alors que le cas d’utilisation A étend le
cas d’’utilisation B. Une extension est souvent soumise à condition. Le cas
d'utilisation B peut exister tout seul, il peut aussi être complété par le cas d’utilisation
A, sous certaines conditions.
L'extension est utilisée pour modéliser la partie d'un cas d'utilisation
considérée comme facultative dans le comportement du système. Elle permet de
séparer le comportement obligatoire du comportement optionnel.
Figure n°9 : Formalisme de la relation d’extension entre cas d’utilisation
Exemples :

Figure n°10 : Exemples de Relation de dépendance « extend » entre cas d’utilisation


I.4.3 Relation de généralisation
Un cas d’utilisation A est une généralisation d’un cas d’utilisation B si le cas
d’utilisation B est un cas particulier de A. Cette relation consiste à dire que l’on a un cas
d’utilisation dit « de base » (le cas d’utilisation A), générique, qui décrit des séquences
d’évènements et d’autres cas d’utilisation (Cas s’utilisation B) qui héritent de ce
comportement de base et le spécialise suivant différents critères. La 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.

Figure n°11 : Formalisme de la relation de généralisation entre cas d’utilisation

Exemples :
System

Traiter règlement

Comptable

Traiter Traiter
règlement règlement
par chèque en espèces

Figure n°12 : Exemples de relation de généralisation entre cas d’utilisation

I.5 Relation de généralisation 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
(tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas
vrai,

Figure n°13 : Exemples de relation de généralisation entre acteurs


II. Description textuelle des cas d’utilisation
Bien que de nombreux diagrammes d’UML permettent de décrire un cas
d’utilisation (diagramme de séquence, diagramme de collaboration), 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 deux
parties : sommaire d’identification et d’une description de scénarii, à savoir :
1- Sommaire d’identification : contient les informations suivantes :
• le nom du cas d’utilisation ;
• un résumé de son objectif ;
• les acteurs impliqués (principaux et secondaires) ;
• les dates de création et de mise à jour de la description courante ;
• le nom des responsables ;
• un numéro de version.
2- Description des scénarii : Elle contient toujours un scénario nominal qui
correspond au fonctionnement nominal du cas d’utilisation (par exemple, un
retrait d’argent qui se termine par l’obtention des billets demandés par
l’utilisateur). Ce scénario nominal commence par préciser l’événement qui
déclenche le cas (l’utilisateur introduit sa carte bancaire par exemple) et se
développe en trois points :

a. Les pré-conditions. Elles indiquent dans quel état est le système avant
que se déroule la séquence (le distributeur est alimenté en billets par
exemple).
b. Les scénarii :
i. Le scénario nominal,
ii. le scénario alternatif,
iii. le scénario d’exceptions.
c. Les post-conditions. Elles indiquent dans quel état se trouve le système
après le déroulement de la séquence nominale (une transaction a été
enregistrée par la banque par exemple).
Remarques :
R1) Parfois la séquence correspondant à un cas d’utilisation a besoin d’être appelée
dans une autre séquence (par exemple quand une relation d’inclusion existe
entre deux cas d’utilisation). Signifier l’appel d’une autre séquence se fait de la
façon suivante : « appel du cas X », où X est le nom du cas.

R2) Les acteurs n’étant pas sous le contrôle du système, ils peuvent avoir des
comportements imprévisibles. La séquence nominale ne suffit donc pas pour
décrire tous les comportements possibles. À un scénario nominal, s’ajoutent
fréquemment des scénarii alternatifs et des scénarios d’exceptions, qui se
décrivent de la même façon.
III. Les étapes d’élaboration d’un diagramme de cas d’utilisation

1. Définir les bornes du système.


2. Identifier les acteurs et les cas d'utilisation :
 Qui utilisera les fonctionnalités principales du système ?
 Qui a besoin du support du système pour effectuer ses tâches
quotidiennes ?
 Qui doit mettre à jour, administrer et veiller au fonctionnement du
système ?
 Quels systèmes de matériel le système logiciel doit- il manipuler ?
 Avec quels autres systèmes le système interagit-il ?
 Qui a un intérêt pour les résultats produits ?
3. Définir les relations entre les cas d'utilisation.
4. Valider et vérifier le modèle.
QCM Diagramme de cas d’utilisation
A une question correspond une seule réponse juste. Indiquer la lettre de la bonne
réponse.

1- Les cas d’utilisation correspondent à un ensemble d’interactions entre un


utilisateur et le système.
A) Vrai
B) Faux
2- Un cas d’utilisation prend en compte les objectifs non fonctionnels d’un
utilisateur.
A) Vrai
B) Faux
3- Dans un cas d’utilisation, un acteur représente un utilisateur jouant un rôle
précis dans l’utilisation du système.
A) Vrai
B) Faux
4- Pour les acteurs primaires, l’objectif du cas d’utilisation est essentiel.
A) Vrai
B) Faux
5- Pour les acteurs secondaires, l’objectif du cas d’utilisation est également
essentiel.
A) Vrai
B) Faux
6- Un acteur est une personne interne au système.
A) Vrai
B) Faux
7- Un acteur est obligatoirement une personne physique.
A) Vrai
B) Faux
8- La relation de communication lie un acteur au système.
A) Vrai
B) Faux
9- Tous les cas d’utilisation ont une relation de communication directe avec un
acteur.
A) Vrai
B) Faux
10- La relation de généralisation/spécialisation est une relation liant deux cas
d’utilisation.
A) Vrai
B) Faux
Corrigé QCM Diagramme de cas d’utilisation
A une question correspond une seule réponse juste. Indiquer la lettre de la bonne
réponse.

1- Les cas d’utilisation correspondent à un ensemble d’interactions entre un


utilisateur et le système.
A) Vrai
B) Faux
2- Un cas d’utilisation prend en compte les objectifs non fonctionnels d’un
utilisateur.
A) Vrai
B) Faux
3- Dans un cas d’utilisation, un acteur représente un utilisateur jouant un rôle
précis dans l’utilisation du système.
A) Vrai
B) Faux
4- Pour les acteurs primaires, l’objectif du cas d’utilisation est essentiel.
A) Vrai
B) Faux
5- Pour les acteurs secondaires, l’objectif du cas d’utilisation est également
essentiel.
A) Vrai
B) Faux
6- Un acteur est une personne interne au système.
A) Vrai
B) Faux
7- Un acteur est obligatoirement une personne physique.
A) Vrai
B) Faux
8- La relation de communication lie un acteur au système.
A) Vrai
B) Faux
9- Tous les cas d’utilisation ont une relation de communication directe avec un
acteur.
A) Vrai
B) Faux
10- La relation de généralisation/spécialisation est une relation liant deux cas
d’utilisation.
A) Vrai
B) Faux
Exercice d’application
SYSTEME LOGICIEL D’UNE CAISSE ENREGISTREUSE
Il s’agit d’un système simplifié de caisse enregistreuse de supermarché. Le
déroulement normal d’utilisation de la caisse est le suivant :
 Un client arrive à la caisse avec des articles à payer.
 Le caissier enregistre le numéro d’identification de chaque article, ainsi
que la quantité si elle est supérieure à un.
 La caisse affiche le prix de chaque article et son libellé.
 Lorsque tous les achats sont enregistrés, le caissier signale la fin de la
vente.
 La caisse affiche le total des achats.
 Le client choisit son mode de paiement :
 Liquide : le caissier encaisse l’argent reçu, la caisse indique la
monnaie à rendre au client.
 Chèque : le caissier vérifie la solvabilité du client en transmettant
une requête à un centre d’autorisation via la caisse.
 Carte de crédit : un terminal bancaire fait partie de la caisse. Il
transmet une demande d’autorisation à un centre d’autorisation
en fonction de type de la carte.
 La caisse enregistre la vente et imprime un ticket.
 Le caissier donne le ticket de caisse au client.

Après la saisie des articles, le client peut présenter au caissier des coupons
de réductions pour certains articles. Lorsque le paiement est terminé, la
caisse transmet les informations sur le nombre d’articles vendus au
système de gestion de stocks.
Tous les matins, le responsable du magasin initialise les caisses pour la
journée.

Questions :
1- Élaborer le diagramme de cas d’utilisation du système de la caisse
enregistreuse en suivant la démarche suivante :
a. Identifier les acteurs.
b. Identifier les objectifs de chaque acteur.
c. Représenter les cas d'utilisation.
d. Représenter les associations entre acteurs et cas d’utilisation
e. Élaborer une structuration des cas d’utilisation, si elle
existe.
2- Élaborer une description textuelle du cas d’utilisation « Traiter passage
en caisse »
Proposition de Corrigé
Système logiciel d’une caisse enregistreuse
 Le diagramme de cas d’utilisation du système de la caisse enregistreuse.

Diagramme de cas d’utilisation du système de la caisse enregistreuse


2-
Description textuelle du cas d’utilisation « Traiter le passage en caisse »

Sommaire d’identification
Titre : « Traiter le passage en caisse »

But : détailler les étapes permettant au caissier d’enregistrer les achats d’un client et
récupérer le paiement.
Acteur principal : Caissier

Acteur secondaire : Client

Date de création : 20/04/2017

Date de mise à jour : 27/04/2017

Version : 1

Description des scénarios


Le cas d’utilisation commence quand un client arrive à la caisse avec des articles qu’il
souhaite acheter.
Préconditions
- La caisse est ouverte (en service) ; un caissier y et connecté.
Scénario nominal
1. Le caissier enregistre chaque article. S’il ya a plus d’un exemplaire par article, le
caissier indique également la quantité. Puis il appuie sur le bouton de validation.
2. La caisse détermine le prix de l’article et ajoute les informations sur l’article à la vente
en cours. La caisse affiche la description et le prix de l’article en question.
3. Après avoir enregistré tous les articles, le caissier indique que la vente est terminée.
4. La caisse calcule et affiche le montant total de la vente.
5. Selon le mode de paiement du client :
a. En cas de paiement en espèce, exécuter le cas d’utilisation « Traiter le
paiement en liquide » ;
b. En cas de paiement par carte de crédit, exécuter le cas d’utilisation « Traiter le
paiement par carte de crédit» ;
c. En cas de paiement par chèque, exécuter le cas d’utilisation « Traiter le
paiement par chèque » ;
6. La caisse enregistre la vente qui vient d’être effectué et imprime un ticket.
Scénario alternatif
A1 : Le numéro d’identification est inconnu
L’enchaînement A1 démarre au point 2 du scénario nominal.

2. La caisse indique au caissier que le numéro d’identification de l’article est inconnu.


L’article ne peut pas être pris en compte dans la vente en cours.

Le scénario nominal reprend au point 1.


Scénario d’exception
E1 : Le client ne peut pas payer

L’enchaînement E1 démarre au point 5 du scénario nominal.

5. Le client ne peut pas payer le total avec aucun moyen de paiement autorisé.

6. Le caissier annule l’ensemble de la vente et le cas d’utilisation est terminé.

Vous aimerez peut-être aussi