Dr.

Rim Samia Kaabi

Digramme de cas d’utilisation et

notions transversales d’UML

17 avril 2012

1
 Plan

Notions transversales d’UML

Classeur

Paquetage

Stéréotype

note

Eléments des diagrammes de cas d’utilisation

Diagramme de CU??

Acteur

UC

Représentation

2
 Plan

Relations dans les diagrammes de CU

Relation entre acteurs et CU

Relation entre CU

Relation entre acteur

Exemple

Modélisation des besoins avec le diagramme de CU

Comment identifier les acteurs

Comment recenser les cas d’utilisation

Description textuelle des CU

Remarque

3
Notions transversales du langage UML

4
 Classeur

un cas d'utilisation

5
Note

6
Eléments des diagrammes de cas
d’utilisation

7
 Cas d’utilisation : définition

Un cas d'utilisation est une manière spécifique d'utiliser un

système.

Les acteurs sont à l'extérieur du système ; ils modélisent tout
ce qui interagit avec lui.
Attention
Il est primordial de définir clairement les bornes/frontières du
système.

Tous les acteurs interagissent directement avec le système

Un cas d'utilisation est l'expression d'un service réalisé de

bout en bout, avec un déclenchement, un déroulement et une
fin, pour l'acteur qui l'initie.

8
 Cas d’utilisation : définition

Un cas d’utilisation représente un besoin, 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

Le cas d’utilisation est une abstraction fonctionnelle

un cas d'utilisation

9
 Acteur

Un rôle joué par une personne externe, un processus ou une

chose qui interagit avec le système modélisé.

10
2 catégories d’acteurs
•Acteur principal pour un CU lorsque ce cas rend un
service à cet acteur. Il obtient un résultat observable du
système
•Acteur secondaire est sollicité pour des informations
complémentaires

11
Représentation d’un diagramme de CU

12
Relations dans les diagrammes de CU

13
 Relation entre cas d’utilisation et
acteurs

Les acteurs impliqués dans un cas d'utilisation lui sont liés par
une association.
Un acteur peut utiliser plusieurs fois le même cas d'utilisation.

14
 Relations entre les cas d’utilisation

2 types de relations
•Les dépendances stéréotypées: inclusion et extension
•La généralisation/spécialisation
 Relations entre les cas d’utilisation

Relation d’inclusion

-« utilise» ou « include »: définit le fait qu’un use case

contient le comportement défini dans un autre use case.

<< Utilise >>

Cas d'utilisation A Cas d'utilisation B

 Relations entre les cas d’utilisation
Relation d’inclusion
 Relations entre les cas d’utilisation

Relation d’extension

-« étend » ou « extend »: définit le fait qu’une instance d’un use case peut
être augmentée avec un comportement quelconque défini dans un use
case étendu
<< Etend >>

Cas d'utilisation A Cas d'utilisation B

19
 Relations entre les cas d’utilisation

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.

20
•Relations de généralisation

21
 Relations entre acteurs

Une seule relation possible : la généralisation.

22
Exemple complet de diagramme de
CU

23
Modéliser les besoins avec les diagrammes
de CU

24
 Recenser les cas d’utilisation

Il n'y a pas une façon unique de repérer les cas d'utilisation.

Il faut se placer du point de vue de chaque acteur et déterminer
comment il se sert du système, dans quels cas il l'utilise, et à quelles
fonctionnalités il doit avoir accès.

Il faut éviter les redondances et limiter le nombre de cas en se
situant au bon niveau d'abstraction (par exemple, ne pas réduire un
cas à une action).

Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il
faut rester au niveau des grandes fonctions du système.

Trouver le bon niveau de détail pour les cas d'utilisation est un problème
difficile qui nécessite de l'expérience.

25
 Description textuelle 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
n'expose pas de façon détaillée le dialogue entre les
acteurs et les cas d'utilisation.

26
 Description textuelle

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
pour un client.

Acteurs : Guichetier, système central (secondaire)

Date : 18/05

Responsables : Toto

Version : 1.0

27
 Description textuelle
Séquencements :

Le cas d'utilisation commence lorsqu'un client demande le retrait

d'espèces en euros

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 Le système guichet interroge le système central pour s'assurer
que le compte est suffisamment approvisionné
6 Le système central effectue le débit du compte
7 Le système notifie au guichetier qu'il peut délivrer le montant
demandé

Enchaînement alternatif
1 En (5) : si le compte n'est pas suffisamment approvisionné ...

Post-conditions
Le guichetier ferme le compte 28
Le client récupère l'argent
 Description textuelle

Rubriques optionnelles
Contraintes non fonctionnelles :
•Fiabilité : les accès doivent être extrêmement sécurisés
•Confidentialité : les informations concernant le client ne
doivent pas être divulguer
Contraintes liées à l'interface homme-machine :
•Donner la possibilité d'accéder aux autres comptes du client
•Ne pas accéder à plusieurs comptes au même temps
•Toujours demander la validation des opérations de retrait

29
Description à l’aide d’un diagramme
d’interaction

30
Description à l’aide d’un diagramme
d’interaction

31
 Diagrammes de Cas d’Utilisation

« Un cas d’utilisation spécifie une séquence d’interactions, avec

ses variantes, entre les acteurs et le système, produisant un
résultat satisfaisant pour un acteur particulier »

Un cas d’utilisation est une abstraction de plusieurs chemins

d’exécution d’une utilisation du système

Pour décrire un cas d’utilisation, il faut décrire un maximum de

chemins d’exécution possibles pour la séquence d’actions
correspondant à ce cas. On étudiera donc un certain nombre de
scénarios d’un cas d’utilisation

 Un scénario est donc une instance de cas d’utilisation

32
 Cas d'utilisation et scénarios

Scénario = « instance » d’un cas d’utilisation ou sa « réalisation »

Un scénario est un accomplissement d’un cas d’utilisation

• initié par un message venant d’une instance d’acteur
• accomplit une séquence d’actions telle que spécifiée par le cas
d’utilisation
• les instances d’acteurs peuvent envoyer de nouveaux messages et
l’interaction continue
• jusqu’à ce que l’instance de cas d’utilisation ait répondu à toutes les
entrées

La réalisation d’un cas d’utilisation est accomplie comme une

transaction atomique
• elle ne peut être interrompue par une autre instance de cas
d’utilisation 33
 Cas d'utilisation et scénarios

Décrire le cas d’utilisation = décrire l’ensemble de

scénarios potentiels

Un scénario est composé de plusieurs chemins

• un chemin de base ou nominal
• l'ensemble le plus commun ou plus général d'interactions
• un ou plusieurs chemins alternatifs
• Variantes : itérations et alternatives
• Anomalies : l'ensemble des interactions traitant les cas d'erreur

34
 Acteurs et Cas d’Utilisation

Les cas d’utilisations représentent le dialogue

entre l’acteur et le système de manière abstraite

Ensemble de scénarios au sein d’une description

unique

Les cas d’utilisations doivent être vus comme des

classes de scénarios

35
 Transition vers les Objets
Cas1

<<include>>
Cas3
Cas2

Approche Objet
Approche Fonctionnelle
Cas3
Cas2
A
Système B
Cas1
Cas2 Cas3 CasX

E C
Cas1 Fonction Fonction Fonction Fonction Fonction
D
Fonction Fonction
F G

36
Les diagrammes de
contexte statique

37
 Le diagramme de contexte statique

• Le diagramme de contexte statique permet de positionner

le système dans son environnement selon un point de vue
matériel.
• Le système est donc décrit physiquement est non pas en
termes de fonctionnalités
• De plus, pour chaque type d’élément matériel extérieur au
système, il est précisé le nombre minimal et maximal,
appelés cardinalités, qui sont mis en jeu

38