Diagrammes de cas d’utilisation

Use case diagrams

Introduction

 Le diagramme de cas d’utilisation (CU) permet de recueillir,

d’analyser et d’organiser les besoins.
 Avec lui débute l’étape d’analyse d’un système.
 Expression du comportement du système (actions et
réactions), selon le point de vue de l’utilisateur
 Décrivent le système et les relations entre le système et
l’environnement

Prof. Asmaa El Hannani ISIC-S2 64

1
 Intérêts

 Permettent de délimiter les frontières du système

 Constituent un moyen d’exprimer les besoins d’un système
 Utilisés par les utilisateurs finaux pour exprimer leurs attentes
et leurs besoins
 Permettent d’impliquer les utilisateurs dès les premiers stades
du développement
 Constituent une base pour les tests fonctionnels

Prof. Asmaa El Hannani ISIC-S2 65

Diagrammes des cas d'utilisation

 Le diagramme des cas d'utilisation regroupe dans un même

schéma plusieurs éléments :
 Acteurs
 Cas d'utilisation
 Relations de dépendances, de généralisations et d'associations

 Le système étant délimité par un cadre rectangulaire.

Prof. Asmaa El Hannani ISIC-S2 66

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

 La frontière du système est représentée par un cadre.

 Le nom du système figure à l’intérieur du cadre, en haut.
 Les acteurs sont à l’extérieur
 Les cas d’utilisation à l’intérieur.
Borne interactive d’une banque

Prof. Asmaa El Hannani ISIC-S2 67

Acteurs

 UML n’emploi pas le terme d’utilisateur mais d’acteur.

 Acteur : entité (personne ou système) externe qui agit sur le
système (Comptabilité, service commercial, …), en
échangeant de l’information (en entrée et en sortie)
 L'acteur peut consulter ou modifier l'état du système.
 En réponse à l'action d'un acteur, le système fournit un service
qui correspond à son besoin.
 Les acteurs peuvent être classés (hiérarchisés) en faisant une
sorte d’héritage.

Prof. Asmaa El Hannani ISIC-S2 68

3
 Acteurs

Remarques:

 La même personne physique peut jouer le rôle de plusieurs

acteurs (Chef d’agence est un client de la banque).

 D’autres part, plusieurs personnes peuvent jouer le même rôle,

et donc agir comme un même acteur (plusieurs personnes
peuvent jouer le rôle d’administrateur).

Prof. Asmaa El Hannani ISIC-S2 69

Représentation d’un acteur

 Un acteur peut être représenté de deux manières différentes :

 Par un petit bonhomme ayant son nom

inscrit dessous.
Nom acteur

 Par un rectangle contenant le stéréotype « Acteur »

«acteur » avec son nom juste en dessous . Nom Acteur

 Il est recommandé d’ajouter un commentaire sur l’acteur pour

préciser son rôle.
Prof. Asmaa El Hannani ISIC-S2 70

4
 Représentation d’un acteur

<<acteur>>
Secrétaire Site Web de l'établissement

Etudiant
Système de Gestion
Scolaire
<<acteur>>
Imprimante

Prof. Asmaa El Hannani ISIC-S2 71

Comment les identifier ?

 Les acteurs candidats sont systématiquement :

 Les utilisateurs humains directs : faites donc en sorte
d’identifier tous les profils possibles, sans oublier
l’administrateur, l’opérateur de maintenance, etc. ;

 Les autres systèmes connexes qui interagissent aussi

directement avec le système étudié, souvent par le biais de
protocoles bidirectionnels.

Prof. Asmaa El Hannani ISIC-S2 72

5
 Types d’acteurs

Les acteurs peuvent être de trois types :

 Humains : utilisateurs du logiciel à travers son interface
graphique, par exemple.

 Logiciels : disponibles qui communiquent avec le système

grâce à une interface logicielle (API, ODBC, …)

 Matériels : exploitant les données du système ou qui sont

pilotés par le système (Imprimante, robots, automates, …)

Prof. Asmaa El Hannani ISIC-S2 73

Type d’acteurs

Mais du point de vue système on distingue deux types :

 Acteurs principaux : utilisent les fonctions principales du

système.
 Par exemple, le client pour un distributeur de billets.

 Acteurs secondaires : effectuent des tâches administratives ou

de maintenance.
 Par exemple, la personne qui recharge la caisse contenue dans le
distributeur.

Prof. Asmaa El Hannani ISIC-S2 74

6
 Relations entre acteurs

 Un acteur peut être une spécialisation d'un

autre acteur déjà défini.
Acteur général

 Dans ce cas, on utilise la relation de

généralisation/spécialisation:

 Remarque: C’est la seule relation possible

entre deux acteurs !
Acteur spécialisé

Prof. Asmaa El Hannani ISIC-S2 75

Cas d'utilisation

 Un cas d’utilisation est une unité cohérente représentant

une fonctionnalité visible de l’extérieur.

 Il réalise un service de bout en bout, avec un

déclenchement, un déroulement et une fin, pour l’acteur
qui l’initie.

 Un cas d’utilisation modélise donc un service rendu par

le système, sans imposer le mode de réalisation de ce
service.

Prof. Asmaa El Hannani ISIC-S2 76

7
 Cas d'utilisation
 Un cas d’utilisation se représente par:

«use case »
 Une ellipse contenant son nom et Nom du cas
optionnellement, un stéréotype «use case Liste de propriétés
», au-dessus du nom, et une liste de
propriétés au-dessous.
Ou
 Un rectangle à deux compartiments; celui Nom du cas
du haut contient le nom du cas ainsi
Liste de propriétés
qu’une ellipse et celui du bas est optionnel
et peut contenir une liste de propriétés

Prof. Asmaa El Hannani ISIC-S2 77

Comment les identifier ?

 Pour chaque acteur, il convient de :

 rechercher les différentes intentions métier avec lesquelles il
utilise le système,

 déterminer dans le cahier des charges les services fonctionnels

attendus du système.

 Nommez les cas d’utilisation par un verbe à l’infinitif suivi

d’un complément, du point de vue de l’acteur (et non pas du
point de vue du système).

Prof. Asmaa El Hannani ISIC-S2 78

8
 Exercice 1

 Une agence de voyages organise des voyages où le voyage se

fait par train, et l’hébergement se fait en hôtel. Le client doit
disposer d’un taxi quand il arrive à la gare pour se rendre à
l’hôtel.

 Identifier les acteurs et les cas d’utilisation de l’agence de

voyage.

Prof. Asmaa El Hannani ISIC-S2 79

Relations entre acteurs et cas d’utilisation

 Relation d’association: C’est le chemin de communication entre

un acteur et un cas d’utilisation et est représenté un trait continu.

 Multiplicité: Lorsqu’un acteur peut interagir plusieurs fois avec un

cas d’utilisation, il est possible d’ajouter une multiplicité sur
l’association du côté du cas d’utilisation:
 * pour plusieurs;
 n pour exactement n;
 n..m pour entre n et m
 etc.

Prof. Asmaa El Hannani ISIC-S2 81

9
 Structuration des cas d'utilisation

 Après avoir identifié les acteurs et les cas d'utilisation, il est

utile de restructurer l'ensemble des cas d'utilisation que l'on a
fait apparaître afin de rechercher les :
 Comportements partagés

 Cas particuliers, exceptions, variantes

 Généralisations/spécialisations.

Prof. Asmaa El Hannani ISIC-S2 82

Structuration des cas d'utilisation

 UML définit trois types de relations standardisées entre cas

d'utilisation :
 Une relation d'inclusion, formalisée par la dépendance «include»

 Une relation d'extension, formalisée par la dépendance «extend»

 Une relation de généralisation/spécialisation

Prof. Asmaa El Hannani ISIC-S2 83

10
 Relation d'inclusion

 Un cas A est inclus dans un cas B 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.
« include »
B A

 Cette dépendance est symbolisée par le stéréotype «include»

 On utilise cette relation pour:

 éviter de décrire plusieurs fois un même enchaînement d'actions. On
factorise un comportement commun à plusieurs cas d'utilisation dans un
cas d'utilisation à part.
 décomposer un cas complexe en sous-cas plus simples.

Prof. Asmaa El Hannani ISIC-S2 84

Relation d'inclusion: Exemple

Borne interactive d’une banque

Effectuer un virement

« include »

Retirer de l’argent
« include »
Client
S’authentifier

Par exemple: « include »

L’accès aux informations d’un compte
Consulter comptes
bancaire inclut nécessairement une
phase d’authentification avec un mot
de passe.

Prof. Asmaa El Hannani ISIC-S2 85

11
 Relation d'extension

 On dit qu’un cas d’utilisation B étend un cas d’utilisation A

lorsque le cas d’utilisation B peut être appelé au cours de
l’exécution du cas d’utilisation A.
 Exécuter A peut éventuellement entraîner l’exécution de B

« extend » A
B
point d’extension

 Cette dépendance est symbolisée par le stéréotype « extend »

 Le comportement ajouté s’insère au niveau d’un point

d’extension définit dans A.

Prof. Asmaa El Hannani ISIC-S2 86

Relation d'extension

 Le cas d'utilisation étendu peut fonctionner tout seul, mais il

peut également être complété par un autre cas d'utilisation,
sous certaines conditions.

 Une extension est souvent soumise à une condition.

 Graphiquement, la condition est exprimée sous la forme d’une note.

 On utilise principalement cette relation pour séparer le

comportement optionnel (les variantes) du comportement
obligatoire.

Prof. Asmaa El Hannani ISIC-S2 87

12
 Relation d'extension : Exemple
Borne interactive d’une banque

Effectuer un virement

Retirer de l’argent
« include »
Extension points
verif_solde{ après avoir
demandé le montant }
Retirer de l’argent
« include »
Client Condition: si montant > 500DH « extend» S’authentifier
Extension point: verif_solde

Par exemple: Vérifier solde

« include »
La vérification du solde du compte
Consulter comptes
n’intervient que si la demande de
retrait d’argent dépasse 500 DHs.

Prof. Asmaa El Hannani ISIC-S2 88

Relations d’inclusion VS d'extension

 La relation «extend» montre une possibilité d'exécution des

interactions qui augmenteront les fonctionnalités du cas
étendu, mais de façon optionnelle, non obligatoire.

 La relation «include » suppose une obligation d'exécution

des interactions dans le cas de base.

Prof. Asmaa El Hannani ISIC-S2 89

13
 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.
A

 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.

Prof. Asmaa El Hannani ISIC-S2 90

Relation de généralisation: Exemple

Borne interactive d’une banque

Effectuer un virement

Retirer de l’argent
« include »
Extension points
verif_solde{ après avoir
demandé le montant }
« include »
Client Condition: si montant > 500DH « extend» S’authentifier
Extension point: verif_solde

Par exemple: Vérifier solde

« include »
La consultation d’un compte bancaire
Consulter comptes
via Internet est un cas particulier de la
consultation
Consulter depuis
internet

Prof. Asmaa El Hannani ISIC-S2 91

14
 Exercice 1 - suite

 Compléter le diagramme de cas d’utilisation de l’agence de

voyages .

 Certains clients demandent à l’agent de voyages d’établir une

facture détaillée. Cela donne lieu à un nouveau cas d’utilisation
appelé « Établir une facture détaillée ». Comment mettre ce cas
en relation avec les cas existants ?

 Le voyage se fait soit par avion, soit par train. Comment

modéliser cela ?

Prof. Asmaa El Hannani ISIC-S2 92

Description des cas d’utilisation

 Le diagramme de cas d’utilisation décrit les grandes fonctions

d’un système du point de vue des acteurs.

 Mais il n’expose pas de façon détaillée le dialogue entre les

acteurs et les cas d’utilisation.

 Ces détails sont des éléments de spécification qui peuvent être

soit fonctionnelles ou techniques.

Prof. Asmaa El Hannani ISIC-S2 94

15
 Description des cas d’utilisation

Deux façons sont couramment utilisées pour décrire les cas

d’utilisation :

 Description à l’aide d’un autre diagramme UML

 par exemple les diagrammes de séquence ou d’activité (étudiés
plus loin dans ce cours)

 Description textuelle

Prof. Asmaa El Hannani ISIC-S2 95

Diagramme de CU pour une banque

Exemple

Prof. Asmaa El Hannani ISIC-S2 96

16
 Description par diagramme de séquence

Prof. Asmaa El Hannani ISIC-S2 97

Description textuelle

 Pour décrire un cas, 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 de

trois parties:
 La première partie permet d’identifier le cas
 La deuxième partie contient la séquence de messages échangés
entre les acteurs et le système
 La troisième partie (optionnelle) contient des spécifications non
fonctionnelles (spécifications techniques, besoins en termes
d’interface graphique, …).

Prof. Asmaa El Hannani ISIC-S2 98

17
 Description textuelle du CU banque 1/3

Identification
Nom du cas : retrait d’espèces en euros.
Objectif : détaille les étapes permettant à un guichetier d’effectuer
l’opération de retrait d’euros demandé par un client.
Acteur principal : Guichetier.
Acteur secondaire : Système central.
Date : le 18/02/2012.
Responsable : M. Chaouki.
Version : 1.0.

Prof. Asmaa El Hannani ISIC-S2 99

Description textuelle du CU banque 2/3

Séquencement
Le CU commence lorsqu’un client demande le retrait d’espèces .
Pré-conditions
Le client possède un compte (donne son numéro de compte).
Enchaînement nominal
1. Le guichetier saisit le numéro de compte client.
2. L’application valide le compte auprès du système central.
3. L’application demande le type d’opération au guichetier.
4. Le guichetier sélectionne un retrait d’espèces de 200 euros.
5. L’application demande au système central de débiter le compte.
6. Le système notifie au guichetier qu’il peut délivrer le montant

Post-conditions
Le guichetier ferme le compte.
Le client récupère l’argent.
Prof. Asmaa El Hannani ISIC-S2 100

18
 Description textuelle du CU banque 3/3

 Rubriques optionnelles
 Contraintes non fonctionnelles
 Fiabilité : les accès doivent être extrêmement sûrs et sécurisés.
 Confidentialité : les informations concernant le client ne doivent
pas être divulguées.
 Contraintes liées à l’interface homme-machine
 Donner la possibilité d’accéder aux autres comptes du client.
 Toujours demander la validation des opérations de retrait.

Prof. Asmaa El Hannani ISIC-S2 101

Conclusion: Construction du diagramme CU

Pour modéliser le diagramme des cas d'utilisation, il faut :

 Identifier les acteurs qui entourent le système. Certains acteurs
utilisent le système pour accomplir des tâches (acteurs principaux),
d'autres effectuent des tâches de maintenance ou d'administration
(acteurs secondaires).
 Organiser les acteurs selon une hiérarchisation de
généralisation/spécialisation
 Intégrer les acteurs au diagramme en spécifiant les cas
d'utilisation auxquels ils se rapportent
 Structurer les cas d'utilisation pour faire apparaître les
comportement partagés (relation d'inclusion), les cas particuliers
(généralisation/spécialisation) ou options (relation d'extension)

Prof. Asmaa El Hannani ISIC-S2 102

19