Centre universitaire Faculté des sciences et de la
Abdelhafid Boussouf technologie
Mila
Département math et
informatique
Génie logiciel
Chapitre 3
Diagramme de cas d’utilisation
Mme. [Link]
2022/2023
II. Diagramme de cas d’utilisation
01 Introduction
02 Les éléments du diagramme de cas d’utilisation
03 Description des cas d’utilisation
04 Exemple
01 Introduction
1- Objectif:
Permet d’élaborer le cahier des charges ou le document de spécification des besoins
du logiciel
Permet de structurer les besoins des utilisateurs, les objectifs correspondants d'un
système
Permet de déterminer les besoins fonctionnels de chaque acteur (le Qui? et le Quoi?)
Ils identifient les utilisateurs du système et leur interaction avec celui-ci
Ils permettent de définir les limites du système et les relations entre le système et
son environnement
01 Introduction
2- Définition:
Constitue la première étape de l’analyse UML en :
Modélisant les besoins des utilisateurs
Identifiant les grandes fonctionnalités et les limites du système
Représentant les interactions entre le système et ses utilisateurs
Le diagramme des cas d’utilisation décrit les fonctionnalités d’un système d’un point
de vue utilisateur
Le diagramme des cas d’utilisation ne liste que des fonctions générales essentielles
et principales sans rentrer dans les détails
01 Introduction
3- Notation:
Nom du système
Cas
d’utilisation1
Cas Acteur
d’utilisation2
02 Les éléments du diagramme de cas d’utilisation
1- Acteur:
Représente un rôle joué par une entité externe (utilisateur humain, dispositif matériel,
ou autre système) qui interagissent directement avec le système.
Un acteur peut consulter et /ou modifier l’état du système en émettant et/ou en
recevant des messages susceptibles d’être porteurs de données
1.1. Comment les présenter ?:
Les acteurs se représentent sous la forme d’un petit personnage (stick man) ou sous la
forme d’une case rectangulaire (appelé classeur) avec le mot clé « actor ». Chaque
acteur porte un nom.
Nous utilisons :
- le stick man si l’acteur est humain <<Actor>>
nom acteur
- le classeur si l’acteur est du matériel ou un autre système.
02 Les éléments du diagramme de cas d’utilisation
1.2. Acteur principale:
Un acteur est qualifié de principal pour un cas d'utilisation lorsque ce cas rend
service à cet acteur.
Personnes utilisant les fonctions principales du système (utilisateur humain)
1.3. Acteur secondaire:
Personnes qui effectuent des tâches administratives ou de maintenance (utilisateur
humain, dispositif matériel, un autre logiciel)
02 Les éléments du diagramme de cas d’utilisation
1.4. Relation entre les acteurs : la généralisation:
L’intérêt de la généralisation, c’est de
montrer que certains acteurs héritent
de tous les cas d’utilisation d’autres
acteurs, et qu’ils ont en plus leur cas
d’utilisation spécifiques
02 Les éléments du diagramme de cas d’utilisation
2- 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.
Un cas d’utilisation se représente par une ellipse contenant le nom du cas
d’utilisation (phrase commençant par un verbe à l’infinitif)
Cas
d’utilisation1
02 Les éléments du diagramme de cas d’utilisation
2.1. Relation entre acteurs et cas d’utilisation:
Chaque acteur est associé à un ou
plusieurs cas d’utilisations, la
relation d’association.
Elle est représentée par un trait
reliant l’acteur et le cas d’utilisation
Association
02 Les éléments du diagramme de cas d’utilisation
2.2. Relation entre cas d’utilisation:
a- Inclusion:
La relation d’inclusion sert à
enrichir un cas d’utilisation par un <<include>>
autre cas d’utilisation
Cette relation est représentée par
une flèche pointillée reliant les deux
cas d’utilisation et munie du
stéréotype « include »
02 Les éléments du diagramme de cas d’utilisation
2.2. Relation entre cas d’utilisation:
b- Extension:
Comme la relation d’inclusion, la
<<include>>
relation d’extension enrichit un cas
d’utilisation par un autre cas
d’utilisation de sous fonction mais
celui-ci est optionnel.
Cette relation est représentée par <<include>>
une flèche en pointillée reliant les
deux cas d’utilisation et munie du
stéréotype « extend »
02 Les éléments du diagramme de cas d’utilisation
2.2. Relation entre cas d’utilisation:
c- Généralisation ou de spécialisation:
Il est également possible de
spécialiser un cas d’utilisation en
un autre cas d’utilisation.
La relation de généralisation est
représentée par une flèche avec
une extrémité triangulaire
03 Description des cas d’utilisations
1- Définition:
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.
Chaque cas d'utilisation doit être documenté pour qu'il n'y ait aucune ambiguïté
concernant son déroulement et ce qu'il recouvre précisément.
1.1. Description textuelle:
Une description textuelle classique se compose de trois parties : identification,
description des scénarios et exigence non fonctionnelle
03 Description des cas d’utilisations
03 Description des cas d’utilisations
1.2. Exemple:
Acteur Client.
Objectif Ajouter une commande.
Pré condition le cas d’utilisation commence lorsque l’utilisateur est s’authentifié.
Post condition Le client passe une commande
Scénario nominal 1. Le client demander de remplir le formulaire de commande
2. Le système affiche le formulaire.
3. le client saisie ces informations nécessaire (nom, prénom, adresse, …).
4. le système enregistre les informations , il renvoie un message de réussite.
Scénario d’erreur 4-a- Le client n’a pas remplit un champ obligatoire ou a saisie des informations non
(alternative) valides.
Le système indique au client « le champ non accepté avec une couleur rouge et le
scénario reprend à partir de 2 ».
Exigences suppléme /
ntaires
04 Exemple
Guichet automatique
de banque :
Bibliographies
Uml 2 pratique de la modélisation, Benoît Charroux, Yann Thierry-Mieg, Aomar Osma
ni [Link]
Uml 2 par la pratique, Pascal roques
Les cahiers du programmeur, Pascal roques
Uml en action, Pascal roques
…….
