Chapitre 2

Les Diagrammes de cas d’Utilisation

et Diagrammes d’Activités

Chapitre 2: Use Cases et Diagrammes d’Activités 1

 Les cas d’utilisation : Définition (1)

Les cas d’utilisation (use cases) ont été formalisés

par Ivar Jacobson. Les cas d’utilisation décrivent,
sous la forme d’actions et de réactions, le
comportement d’un système du point de vue d’un
utilisateur.
Un cas d’utilisation est une manière spécifique
d’utiliser un système. C’est l’image d’une
fonctionnalité du système, déclenchée en réponse à
la stimulation d’un acteur externe.

Chapitre 2: Use Cases et Diagrammes d’Activités 2

 Définition (2)

•Permet de représenter le comportement d'un

système vu du côté utilisateur
•Traduit une spécification d'utilisation du
système
•Représente des ensembles de scénarios
•Très utile en phase d'analyse des besoins car
structure les besoins des utilisateurs finals
•Correspond (plus ou moins) à une
décomposition fonctionnelle du système

Chapitre 2: Use Cases et Diagrammes d’Activités 3

 Intérêt des cas d’utilisation

Utilisateur C

Ensemble des besoins

Utilisateur A Utilisateur B

Les cas d’utilisation partitionnent Cahier des charges

l’ensemble des besoins d’un
système
Chapitre 2: Use Cases et Diagrammes d’Activités 4
 Concepts fournis par les Cas d'utilisation
1-Les acteurs
2-Les cas d'utilisation
3-Les relations entre acteurs et cas d'utilisation
4-Les relations entre acteurs
5-Les relations entre cas d'utilisation
6-Les paquetages

Chapitre 2: Use Cases et Diagrammes d’Activités 5

 1-Acteur

Système

Un acteur représente un rôle joué par une personne

ou une chose qui interagit avec un système.
Chapitre 2: Use Cases et Diagrammes d’Activités 6
 4 grandes catégories d’acteurs
• Les acteurs principaux…les personnes qui
utilisent les fonctions principales du système.
• Les acteurs secondaires…les personnes qui
effectuent des tâches administratives ou de
maintenance.
• Le matériel externe…les dispositifs matériels
incontournables qui font partie du domaine de
l’application et qui doivent être utilisés.
• Les autres systèmes… les systèmes avec lesquels
le système doit interagir.
Chapitre 2: Use Cases et Diagrammes d’Activités 7
 2-Cas d’Utilisation

•Représente une fonctionnalité (macro ou

micro) du système
•Est un ensemble de scénarios nominaux et
non nominaux
•Equivalent à une classe dont les instances
sont des scénarios
•Interviennent tout au long du cycle de vie

Cas d'utilisation X

Chapitre 2: Use Cases et Diagrammes d’Activités 8

 3-Acteurs et Cas d'utilisation

Relation de communication
• La communication peut être :
– directionnelle ou pas
– étiquetée ou pas
• Supporte un flot de données

Personne Conduire

Entretenir

Chapitre 2: Use Cases et Diagrammes d’Activités 9

 4-Relation entre acteurs

• Uniquement de la généralisation
• Sémantique : tout ce que peut faire
le père, le fils peut le faire ! Utilisateur

Superviseur

Chapitre 2: Use Cases et Diagrammes d’Activités 10

 5-Relations entre cas d'utilisation

• Généralisation : traditionnelle !
• <<inclut>> : relation d'inclusion traduisant une
obligation et permettant la réutilisation
• <<étend>>: relation d'extension non obligatoire
<<inclut>>

Use case Father

<<étend>>

Use case Child

Annotation

Chapitre 2: Use Cases et Diagrammes d’Activités 11

 5.1-La relation d’inclusion (1)
La relation d’inclusion a un caractère obligatoire, la
source spécifiant à quel endroit le cas d’utilisation cible
doit être inclus.

<<include>>

Virement Identification
Client distant <<extend>>

montant > 500 frs

Virement par internet Vérification solde compte

Chapitre 2: Use Cases et Diagrammes d’Activités 12

 5.1-La relation d’inclusion (2)

La relation "Include" est une relation entre 2

instances de cas d'utilisation telle que la
réalisation de l'un nécessite la réalisation de
l'autre.

Chapitre 2: Use Cases et Diagrammes d’Activités 13

 5.2-La relation d’extension (1)
Dans une relation d’extension entre cas d’utilisation, le
cas d’utilisation source ajoute son comportement au cas
d’utilisation destination (cible). L’extension peut être
soumise à une condition.

<<include>>

Virement Identification
Client distant <<extend>>

montant > 500 frs

Virement par internet Vérification solde compte

Chapitre 2: Use Cases et Diagrammes d’Activités 14

 5.2-La relation d’extension (2)

On dit qu’un cas d’utilisation X étend un cas

d’utilisation Y lorsque le cas d’utilisation X peut
être appelé au cours de l’exécution du cas
d’utilisation Y

Chapitre 2: Use Cases et Diagrammes d’Activités 15

 Extension et Inclusion

<<include>>

Virement Identification
Client distant <<extend>>

montant > 500 frs

Virement par internet Vérification solde compte

Chapitre 2: Use Cases et Diagrammes d’Activités 16

 6-Paquetages
• Servent à
délimiter le
système et The System

<<inclut>>
les sous-
systèmes UC1
UC3

UC2

Acteur2

Acteur1

Chapitre 2: Use Cases et Diagrammes d’Activités 17

 Cas d’utilisation et scénarios
Scénario 1 Scénario 2 Scénario 3

Cas
d’utilisation

Un cas d’utilisation décrit, de manière abstraite,

une famille de scénarios.
Chapitre 2: Use Cases et Diagrammes d’Activités 18
 Les scénarios (1)
Les cas d’utilisation se déterminent en observant
et en précisant, acteur par acteur, les séquences
d’interaction -les scénarios- du point de vue de
l’utilisateur.
Un cas d’utilisation regroupe une famille de
scénarios d’utilisation selon un critère
fonctionnel.
Les cas d’utilisation sont des abstractions du
dialogue entre les acteurs et le système: ils
décrivent des interactions potentielles, sans entrer
dans le détail de chaque scénario.
Chapitre 2: Use Cases et Diagrammes d’Activités 19
 Les scénarios (2)

Les cas d’utilisation doivent être vus comme

des classes dont les instances sont les
scénarios. Chaque fois qu’un acteur interagit
avec le système, le cas d’utilisation instantie
un scénario; ce scénario correspond au flot
de messages échangés par les objets durant
l’interaction particulière qui correspond au
scénario.

Chapitre 2: Use Cases et Diagrammes d’Activités 20

 Maquette
[PAM-97] Le maquettage à base de constructeurs
d’interfaces utilisateur est très souvent le meilleur
moyen d’aider l’utilisateur final à articuler ses
désirs. L’examen des interactions entre
l’utilisateur et la maquette procure alors une
source non négligeable de scénarios, et donc de
moyens de valider le modèle de cas d’utilisation.
[LMP-98 p61] Une maquette est un ensemble
d’enchaînements d’écrans permettant de simuler
un nombre limité de fonctionnalités du système.
Elle s’appuie sur des objets métier simulés et des
accès en bases de données fictifs.
Chapitre 2: Use Cases et Diagrammes d’Activités 21
 Une représentation textuelle

Use case « Retrait en espèce »

• Le guichetier saisit le numéro de compte du client.
• L’application valide le compte auprès du système central.
• L’application demande le type d’opération au guichetier.
• Le guichetier sélectionne un retrait de 200 F.
• Le système « guichet » interroge le système central pour
s’assurer que le compte est suffisamment approvisionné.
• Le système central effectue le débit du compte.
• Le système notifie au guichetier qu’il peut délivrer le
montant demandé.

Chapitre 2: Use Cases et Diagrammes d’Activités 22

 Diagrammes d’Activités (1)

Ressemble furieusement aux vieux

organigramme
identifier les activités (en s ’appuyant

sur use case)

identifier les transitions entre activités

Chapitre 2: Use Cases et Diagrammes d’Activités 23

 Diagrammes d’Activités (2)

Les diagrammes d'activité sont la

représentation du comportement d'une
opération ou d'un cas d'utilisation en
terme d'action.
Un diagramme d'activités représente l'état
de l'exécution d'une méthode, sous la
forme d'un déroulement d'étapes.

Chapitre 2: Use Cases et Diagrammes d’Activités 24

 Activité

Une activité est un automate à deux états

dont le franchissement de la transition
entre ces derniers est conditionné par une
fin d'activité.
Etats-Actions

Chapitre 2: Use Cases et Diagrammes d’Activités 25

 Transitions

Dans le diagramme d'activité, il existe deux types de

transitions :
Transitions automatiques
Transitions gardées

Chapitre 2: Use Cases et Diagrammes d’Activités 26

 Transition automatique

les transitions automatiques ( une flèche simple) qui est

franchie quand l'activité précédente est finie: Transition
sans déclencheur ou transition de terminaison.
Elles sont généralement utilisés pour démarrer un
diagramme d’activités

Chapitre 2: Use Cases et Diagrammes d’Activités 27

 Transition gardée (1)

Les transitions gardées ( une flèche avec une

condition entre crochets ) qui est franchie si la
condition est vérifiée.

Chapitre 2: Use Cases et Diagrammes d’Activités 28

 Transition gardée (2)

La décision est matérialisée expilicitement

Chapitre 2: Use Cases et Diagrammes d’Activités 29

 Synchronisation

Les diagrammes d'activités permettent aussi de

visualiser les activités qui s'exécutent en
parallèle au moyen de barres de
synchronisation.

Chapitre 2: Use Cases et Diagrammes d’Activités 30

 Exemples de Synchronisation (1)

Décision de Arrêter
Aérer
refroidir chauffage

Arrêter Mesurer
Aérer
chauffage Température

Chapitre 2: Use Cases et Diagrammes d’Activités 31

Exemples de Synchronisation (2)

Chapitre 2: Use Cases et Diagrammes d’Activités 32

 Découpage (1)

Afin d'organiser un diagramme d'activités selon

les différents responsables des actions
représentées, il est possible de définir des
« couloirs d'activités » ou travée.

Il est même possible d'identifier les objets

principaux, qui sont manipulés d'activités en
activités et de visualiser leur changement d‘état
.

Chapitre 2: Use Cases et Diagrammes d’Activités 33

Découpage (2)

Chapitre 2: Use Cases et Diagrammes d’Activités 34

 Flots entre Activités et Objets
Il est possible de visualiser les objets qui ont été
crée par les activités. Pour cela, on relie par une
flèche en pointillé l'objet et l'activité qui l'a crée.

Chapitre 2: Use Cases et Diagrammes d’Activités 35

 Exemple Récapitulatif

• Un jeu de dés
• Le joueur lance 10x 2 dés
• Si le total fait 7, il marque 10 points à son
score
• En fin de partie, son score est inscrit dans le
tableau des scores.
[Un exemple de Pascal Molli]

Chapitre 2: Use Cases et Diagrammes d’Activités 36

 Analyse des Besoins
• Un premier Use-case
• Identifier les acteurs?
• Identifier les cas d’utilisations possibles du
système
• Ses fonctionnalités externes !

Chapitre 2: Use Cases et Diagrammes d’Activités 37

 Use Case

• Play:
– Acteur: Player
– Descr: Le joueur prend 10x
Play
les dés, à chaque fois que le
Player
total fait 7, +10pts
• View High Score
View High Score – Acteur: Player
– Descr: Le joueur consulte en
read only les high score

Chapitre 2: Use Cases et Diagrammes d’Activités 38

 Diagramme d’Activités

menu

[highscore] [start] [exit]

view Start
Play Highscore turn=0
Player
Roll
Dice
turn++
View High Score [true]

Turn<10

[false]
Update
highscore

Chapitre 2: Use Cases et Diagrammes d’Activités 39

 Récapitulons

Les use cases, permettent de modéliser les besoins

des clients d'un système et doivent aussi posséder
ces caractéristiques.
Ils ne doivent pas chercher l'exhaustivité, mais
clarifier, filtrer et organiser les besoins !

Les use cases ne doivent donc en aucun cas décrire

des solutions d'implémentation. Leur but est justement
d'éviter de tomber dans la dérive d'une approche
fonctionnelle, où l'on liste une litanie de fonctions que
le système doit réaliser.
Les Diagrammes d’Activités permettent d’identifier les
activités (en s ’appuyant sur use case)
Chapitre 2: Use Cases et Diagrammes d’Activités 40
Cas d’Utilisation des Cas d’Utilisation !!!

Chapitre 2: Use Cases et Diagrammes d’Activités 41