Chapitre 2 

: Diagrammes de cas d’utilisation

I. Introduction

UML permet de donner une description globale et non détaillée du système / de l’application à
modéliser. Cette description a pour objectif de bien cerner le problème à résoudre, et d’identifier les
fonctionnalités clés. Cette description est le point de départ essentiel de tout développement orienté
objet, elle permet d’analyser les besoins des futurs utilisateurs. Cette description se base dans UML
sur les Diagrammes de Cas d’Utilisation D.C.U.

Les Cas d’Utilisation (C.U) ou User Case (U.C) ont, initialement été définis pas Ivar Jacobson en
1992 dans sa méthode OOSE. Ils permettent de décrire le comportement du système étudié selon le
point de vue de l’utilisateur, en phase d’analyse pour la compréhension des besoins. En effet un
DCU est recentre l’expression des besoins sur l’utilisateur, en partant du principe qu’un système est
construit, avant tout, pour ses utilisateurs.

L’élaboration du DCU passe par une phase de spécification des besoins qui va identifier et
documenter ce qui est demandé en terme de :
- Objectifs du projet
- Fonctions métier
Cela pour arriver à définir comment les utilisateurs veulent interagir avec le système et ce qui doit
être fait pour obtenir le résultats attendus.

Objectif d’un CU :

- Capturer le comportement attendu du système
- Spécifier ce que le système fait, mais pas comment il le fait
- Servir de moyen d’échange entre les différents intervenants (utilisateurs, concepteurs,
clients, experts)
- Servir de référence pour valider l’architecture logiciel qui sera développée.

II. Concepts de base 

II.1. Cas d’utilisation :

Un CU est une manière spécifique d’utiliser un système. Il décrit la séquence d’évènement dans
laquelle, un utilisateur va utiliser le système pour accomplir une tâche.
Un CU peut aussi être défini comme les fonctions du système futur visibles par les utilisateurs.

Exemple :
Cas d’utilisation du téléphone portable : répondre à un appel, envoyer un sms
Cas d’utilisation d’un site de messagerie : rédiger un mail, consulter les mail reçus

Au fait l’identification des CU passe d’abord par l’identification des acteurs qui vont modéliser les
utilisateurs du système.
En UML un CU est représenté par un oval plat à l’interieur duquel est inscrit le nom du CU.

Le nom d’un CU est généralement composé d’un verbe à l’infinitif avec un complément.

1
II.2. Acteur 
Entité externe qui interagit avec le système à travers un cas d’utilisation. L’acteur représente un rôle
joué vis-à-vis du système.
Un acteur peut être instancié par une ou plusieurs personnes physiques, comme il peut l'être par un
dispositif matériel ou un logiciel d'un autre système.
Un acteur peut intervenir dans plusieurs CU.

Un cas d’utlisation est alors défini par un ensemble d’actions réalisées par le système en réponse à
la stimulation d’un acteur.

Exemple d’acteurs :
Client pour un Distributeur Automatique de Billet DAB
Personne pour un téléphone portable
Un internaute pour un site
...
UML représente l’acteur par le stickman ainsi représenté :

Nom-acteur

II.3. Interaction / Association :

Elle lie un acteur à un CU est montre l’acteur ou les acteurs qui réalisent le CU.
Un acteur peut interagir avec le système via un nombre de CU
Un CU peut avoir plus d’un acteur.

UML représente l’interaction par un trait plein, liant le CU à ou aux acteurs qui le réalisent.

Exemple :

Tout système peut être représenté par un nombre de CU et d’acteurs

2
Le DCU regroupe les concepts :
 Acteur
 CU
 Relation entre les CUs

Acteur principal / acteur secondaire :

L’acteur principal est l’utilisateur qui interagit directement avec le système via un CU.
L’acteur secondaire est soit :
 L’acteur qui déclenche l’utilisation sans manipuler le système (ex : le client qui désire
acheter dans un système de caisse éléctronique, l’étudiant qui se présente pour s’inscrire)
 L’acteur qui interagit secondairement avec le CU pour le réaliser. Il n’est pas le déclencheur
du CU (ex : le système central des CCP Alger pour un distributeur de billet d’Algérie poste)

CU principal / Secondaire
Un CU principal est celui qui répond à un objectif clé du système. Il est, à lui seul, une finalité dans
l’utilisation du système.
Un CU secondaire est un CU complémentaire ou supplémentaire dans le fonctionnement du
système.
Exemple :
« Gérer contact » et « Gérer message » sont des CUs principaux
« atteindre page » dans Microsoft Word et « attribuer photo au contact » dans un téléphone protable
sont des CUs secondaires

II.4. Structuration d’un CU :

La structuration permet de mettre en évidence les différentes articulations qui réalisent un CU. Elle
permet aussi d’organiser les CUs collectés et de donner une meilleure représentation du futur
système. La structuration est une vision plus détaillée du CU, issue d’une meilleure compréhension
des besoins et des fonctionnalités requises dans le futur système.
On structure un CU pour :
- Identifier les comportements récurrents et partagés dans les UCs, et les mettre en facteur.
- Identifier et mettre en évidence les comportements optionnels dans un ou pluiseurs CUs.
- Généraliser un ensemble de CUs par un objectif ou une caractéristique commune.
- Spécialiser un CU.

UML offre 03 relations qui peuvent être utilisées pour structurer un CU :

II.4.1. La relation d’inclusion : Permet de factoriser les interactions communes et récurrentes dans
plusieurs CUs. L’interaction ainsi identifiée est isolée, nommée et reliée au CUs d’origine par une
relation d’inclusion.
Un cas d’utilisation A inclut ou utilise un cas d’utilisation B signifie que lors de l’execution:
- Une instance de A engendre une instance de B et l’exécute.
- A dépend du déroulement et du résultat de B
- B n’existe pas seul et A n’existe pas sans B
UML représente l’inclusion par une flèche en pointillés qui pointe l’UC inclut.

3
Exemple :

 Lorsque le CU « Retirer argent » s’execute, il engendre une instance du CU

« Authentification » et l’exécute
 « Retirer argent » dépend du résultat de « authentification »
 « Authentification » n’existe pas seul et « Retirer argent » n’existe pas sans
« authentification »

II.4.2. La relation d’extension : Permet d’étendre les interactions d’un UC par des interactions
optionnelles. Ces dernières sont regroupées dans un CU qui peut venir compléter l’exécution du CU
de base à certains points appelés points d’insertion. La relation d’extension permet de séparer le
comportemant optionnel du comportment obligatoire d’un CU.

Un CU B étend un CU A signifie que :

 Une instance de A peut engendre une instance de B et l’exécuter dans certaines cas. B sait
alors où s’insérer dans A.
 B n’existe pas seul et A existe sans B
UML représente l’extension par une flèche en pointillées qui pointe le CU optionnel.

Exemple :

Le CU « propriété impression » étend le CU « imprimer » dans Microsoft Word.

Le CU « imprimer » peut engendrer une instance de « propriété impression » et l’executer
Le CU « imprimer » peut exister seul, ce qui n’est pas le cas de « propriété impression ».

II.4.3. Généralisation / Spécialisation : C’est le meilleur moyen offert par UML pour organiser les
CUs identifiés, c’est inspiré de l’héritage du paradigme O.O.
Lorsque un ensemble de CUs sont des formes différentes d’un même objectif métier, il est
préférable de les généraliser (ex : « ajouter contact », « modifier contact », « supprimer contact »
ont le même objectif métier : gérer les contacts).
Lorsqu’un CU peut avoir plusieures formes d’execution pour le même objectif métier, il est
préférable de le spécialiser en un nombre de CUs (ex : « recruter » est un UC qui se déroulera
différemment selon la personne recrutée : enseignant ou personnel administratif)
UML représente de la même manière la généralisation / spécialisation par une flèche pleine qui
pointe le CU générique.

4
Exemple :

III. Description de CU :

Après identification de tous les CUs, il est important d’élaborer pour chacun, une fiche descriptive
qui recapitule les connaissances acquises et en ajoute d’autres.
Définition1 : La description d’un CU est un document narratif qui décrit la séquence d’interactions
dans laquelle un acteur utilise le système pour arriver à un résultat qui satisfait l’objectif initial du
CU.
Définition 2 : Un scénario est une instance d’exécution d’un CU.
Un CU est une abstraction de plusieurs chemins d’exécution possibles d’une utilisation du système.
Mais, la Description d’un CU ne reviens pas à décrire tous ses chemins d’exécution possibles. Il
suffit de donner le scénario nominal.
Définition 3 : Un scénario nominal est le scénario le plus représentatif qui mènent à une
terminaison avec succés de l’UC.

La fiche descriptive d’un CU est constituée de 03 éléments :

 Une entête comportant : nom du CU, Acteurs (principal et éventuellement secondaire), But,
Type du CU (principal / Secondaire)
 Le scénario nomimal
 Une description des alternatives de déroulement

Fiche descriptive d’un CU :

Nom du CU : ....................

Acteur principal :.......................................... ; Acteur secondaire :..........................
But :.......................................................................................................................................................
................................................................................................................................................................
...............................................................................................................................................................
Type : ..............................................................
Scénario / Déroulement :
<Action en début>
<Action en cours>
<Action en fin>

Altenatives :....................................................................................
Remarques : Des clauses peuvent être ajoutée (documents manipulés, ..) ou supprimées en fonction
de la spécificité du développement.

5
Exemple :
Nom du CU : Remplir formulaire
Acteur principal : Internaut  ; Acteur secondaire : /
But :Le but de ce CU est de permettre à l’acteur de remplir dûement un formulaire qui sera validé
si toutes ses clauses obligatoires sont remplies.
Type : Secondaire
Scénario / Déroulement :
<Action en début> : Le formulaire est affiché
<Action en cours> : L’acteur rempli le formulaire
L’acteur valide par la touche « Accepter »
les clauses obligatoires sont vérifiées
Si elles sont toutes remplies, le formulaire est enregistré.
<Action en fin> : Le système affiche « votre inscription est validée »

Altenatives :
- Il y a des clauses obligatoires qui ne sont pas remplies
- L’acteur annule le CU

IV. Diagramme de contexte :

Le diagramme de contexte permet de visualiser les cas d’utilisation primaires d’un système. Ce qui
permet de voir rapidement les principales fonctions du système.
Plus particulièrement, le diagramme de contexte montre aussi les principaux acteurs et les limites
du système modélisé

IV. Elaboration du DCU

L’élaboration d’un DCU vient après une écoute ou une lecture qui permettent de bien comprendre
les besoins exprimés. Elle suit les étapes suivantes :

1. Identifier les acteurs (principaux et secondaire)

2. Identifer les CUs
3. Structurer les CUs
4. Elaborer un DCU global ou un DCU pour chaque acteur (si le global est trop chargé)
5. Elaborer les fiches techniques de chaque CU
6. Elaborer un diagramme de contexte si demandé.