Vous êtes sur la page 1sur 19

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