Diagrammes UML : Cas d’Utilisation (Use

Case)

Dr Ibrahima GAYE

22 mai 2021
Références

I https ://www.uml.org/
I Le génie logiciel et ses applications, I. Sommerville,
InterEditions, 1988
I UML 2 en action, Pascal Roques, Franck Vallée, Eyrolles,
2004
I Object-Oriented Analysis and Design, with applications,
3rd Ed. BOOCH, Grady, et al. Addison-Wesley, 2007.
I Jacques Printz.Le genie logiciel.Que sais-je ? Presses
Universitaires de France, 2002.
I Bertrand Meyer.Conception et Programmation Orient ´ee
Objet.Eyrolles, 2000.
I Pierre-Alain Muller and Nathalie Gaertner.Mod ´elisation
Objet avec UML.Eyrolles, 2000.
I Pascal Roques.UML en action.Eyrolles, 2003.
Contexte
Souvent, les maitres d’ouvrage ne sont pas de spécialistes en
informatique alors il faut des moyens très simples pour qu’ils
expriment leurs besoins.
Le cas d’Utilisation ou le Use Case est un moyen graphique
très simple de modélisation de processus métiers
I Représentation des fonctionnalités du système
I Il est composé :
I d’acteurs : utilisateurs du système à représenter
I rôle joué par une personne ou une chose extérieure qui
interagit avec le système
I de cas d’utilisation : fonctionnalités proposées par le
système
I ”classes” dont les instances sont des scénarios
Acteur

Représentation
I Pour chaque acteur :
I choisir un identificateur représentatif du rôle
I mettre, éventuellement, une brève description textuelle
Acteur

types d’acteurs

I Humains : utilisateurs du logiciel (via l’interface graphique)

I Logiciels : autres logiciels qui interagissent avec le logiciel
I Matériels : matériels qui exploitent les données du logiciel
ou qui sont pilotés par le logiciel
I Remarque : Ne pas confondre acteur et personne utilisant
le système :
I Une même personne peut jouer plusieurs rôles
I Plusieurs personnes peuvent jouer un même rôle
Cas d’utilisation

Représentation

I client GAB : un acteur du système

I Retirer argent : un cas d’utilisation (une fonctionalité du
système) que peut effectuer l’acteur client GAB
Cas d’utilisation

I représente une fonctionnalité déclenchée suite à une

action initiée par un acteur.
I correspond à une manière spécifique d’utiliser le système
I suite d’interactions entre un acteur et le système.
I décrit un ensemble de scénarios.
Exemple simple

Gestion GAB
Relation entre les CAS

Une dépendance entre deux cas se preprésente par une

flcheavecuntraitpointill.
Il y’a deux types de relations :
I Extension (extends)
I A "include" B : le cas B inclut obligatoirement le cas A i(.e.
la fonctionnalité A ne peut faire qu’après avoir effectué B)
I Utilisation (inclusion) (include)
I A "extends" B : Les cas A est une extention optionnelle du
cas B (i.e. la fonctionnalité A peut se faire ou non après la
fonctionnalité B
Relation entre les CAS

Exemple
Relation entre les CAS

La Relation extends
I Tous les use cases fils
I sont des cas particuliers du use case père
I héritent des caractéritisques du père
Relation entre les CAS

La Relation include
I Permet de décomposer un use case complexe en
plusieurs use cases plus simples.
Relation entre les acteurs

Généralisation/Spécification
Un aceur A est une généralisation d’un acteur B si A peut être
substitué par B. Dans ce cas, tous les cas d’utilisations
accessibles à A le sont sont aussi à B.
Le symbole utilisé pour la généralisation est une flêch avec un
trait plein dont la pointe est un triangle fermé désignant le cas
le plus général
Relation entre les acteurs
Généralisation/Spécification