Chapitre 3

Diagramme des cas

d’utilisation
 Les cas d’utilisation use cases (UC) ont été
initialement proposés par OOSE de Jacobson (1992)
pour :
• Décrire le comportement d’un système :
{Actions}+{Réactions}
 L’idée derrière l’invention des UC est :
Le système existe pour servir ses utilisateurs
La description du comportement du système doit
être faite du point de vue de son utilisateur et
non de celle de l’analyste

 Les cas d'utilisation (UC) représentent les

fonctionnalités que le système doit savoir faire du
point de vue des utilisateurs.
2
1. Intérêt des UC
Les UC permettent de :
 connaître le comportement du système sans
spécifier comment ce comportement sera réalisé.
 recentrer l'expression des besoins sur les
utilisateurs
Eviter de dériver vers des spécifications
inadaptées et inutiles.
 représenter et structurer les fonctionnalités du
système de façon simple et expressive.
 définir les limites précises et les objectifs du
système.

3
De plus les cas d’utilisation :
 Pilotent toutes les activités de conception, de la
spécification de ce qui doit être fait jusqu’à la
maintenance.
 Constituent des instruments de validation et de
test du système en cours et en fin de
construction.

Cas d’utilisation

Analyse Conception Test

Les UC balisent les différentes activités et
étapes du processus de développement
4
2. Acteurs
 Définition
 Un acteur représente un rôle joué par une entité externe
(personne, dispositif matériel, ou autre système) qui
interagit directement avec le système étudié.
 Un acteur peut :
 échanger de l’information avec le système
 consulter ou modifier l'état du système
 Notation

Client

5
 Les acteurs se déterminent en observant les rôles des
utilisateurs du système, ceux qui sont responsables de
son exploitation ou de sa maintenance, ainsi que les
rôles des autres systèmes ou dispositifs qui
interagissent avec le système en question.

 Ne pas confondre acteur et personne utilisant le

système :
• La même personne peut jouer le rôle de plusieurs
acteurs
• Plusieurs personnes peuvent jouer le même rôle

6
 Un acteur peut participer à des relations de
généralisation avec d'autres acteurs

Utilisateur Acheteur

 La généralisation/spécialisation est la seule relation qui

peut exister entre acteurs.

7
3. Cas d’utilisation
 Définition
 Un UC représente une exigence fonctionnelle envers
le système dans son ensemble.
 Il décrit un ensemble de séquences d’actions
réalisées par le système qui produit un résultat
observable pour un acteur.
 Exemple et Notation

Gérer commande Calculer devis

Gérer fournisseurs

8
Les acteurs sont connectés aux cas d'utilisation
uniquement par une association qui indique que
l'acteur et le UC communiquent entre eux,
chacun pouvant envoyer et recevoir des
messages.

Consulter
Commandes
Client

9
 4. Diagramme de UC
 Définition
Le diagramme de UC représente les UC identifiés et
les acteurs associés à chacun.
 Exemple
Rechercher des ouvrages

Diagramme des UC Internaute Gérer son panier

relatif à un projet de
développement d'un Effectuer une commande
site web pour une
librairie. Libraire Maintenir le catalogue

Maintenir les infos éditoriales

Webmaster Maintenir le site

10
 5. Scénarios d’un UC
Définition
Un scénario est une suite spécifique d'interactions
entre les acteurs et le système. C'est une instance
du UC, un chemin particulier dans sa combinatoire.

Un UC est donc une collection de scénarios de

succès ou d'échec qui décrit la façon dont un acteur
particulier utilise un système pour atteindre un
objectif.
(scénarios)

Représentation des scénarios d’un UC. 11

  Chaque scénario est composé d'étapes qui peuvent
être de trois sortes :
• Un message d'un acteur au système
• Une validation ou un changement d'état du
système
• Un message du système vers un acteur
 Les scénarios constituent un excellent moyen de
guider le processus de développement logiciel.

 Exemple

Le UC Gérer Commande englobe les trois scénarios :

 Créer une nouvelle commande
 Consulter une commande
 Annuler une commande
12
Types de scénarios
Les scénarios d’un UC peuvent être classés en
• Scénarios principaux : un scénario principal est le
cas nominal, l’instance principale du cas
d’utilisation. Il s’agit souvent du chemin normal
d’exécution du UC qui n’implique pas d’erreur.
• Scénarios alternatifs : ils représentent des cas
d’exécution moins fréquents, mais qui permettent
d’assurer une exécution correcte du UC.
• Exceptions : il ne permettent pas de terminer le
UC correctement.

13
6. Description d’un UC
 La description d’un UC peut se faire de plusieurs
manière, de la plus informelle (textuelle) à la plus
formelle (diagramme d’états/transitions par
exemple).

 La description textuelle est importante car elle

constitue la forme de description la plus claire et la
plus compréhensible pour les non-informaticiens.

 Elle constitue la base du travail d’analyse des besoins

et de la discussion avec les utilisateurs.

 La description d’un UC se concentre sur ce qui doit

être fait dans le cas d’utilisation, et non sur la
manière de le faire.
14
 La fiche de description textuelle d’un cas
d’utilisation n’est pas normalisée par UML. Nous
proposons la structuration suivante :
• Identification (obligatoire)
 nom du UC
 objectif
 acteurs reliés au cas
 date de création
 date de modification
 numéro de version

15
• Description des scénarios (obligatoire),
 Préconditions: Conditions nécessaires pour
démarrer le UC.
 postconditions : Conditions qui doivent être
satisfaites dans le système après la fin du UC.
 événement déclencheur du UC
 scénarios nominaux
 scénarios alternatifs
 événement d’arrêt
 exceptions

16
 • Besoins d’IHM (optionnel),
 Contraintes d’interface homme-machine : ce
qu’il est nécessaire de montrer, en relation avec
les opérations que l’utilisateur peut déclencher…
• Contraintes non-fonctionnelles (optionnel).
 Temps de réponse, volumétrie, disponibilité,
confidentialité, performances, concurrence, etc.

 La description des scénarios nominaux du UC doit

présenter les échanges d’informations entre le
système et les acteurs.
 Il est recommandé de compléter la description
textuelle par un ou plusieurs diagrammes dynamiques
pour montrer la succession des enchaînements.
17
Exemple : Cas d’utilisation de gestion de commandes.

Identification : Gérer commandes

Acteurs : Vendeur
Objectif :
Ce UC est utilisé pour passer et suivre les commandes
clients.
Date de création : 09/09/2015
Date de mise à jour : 14/09/2015
Version : 1.1
Description des scénarios
Précondition : Le vendeur est authentifié
Au moins un produit est disponible.
Postconditions :La date de la commande validée
est inférieure à la date du jour.
Le client ayant passé la commande
validée figure dans la liste des
18
clients.
Scénario nominal
Le UC débute quand le vendeur demande de créer une
nouvelle commande.
a) Identification du client
Le système propose au vendeur de chercher le
client selon plusieurs critères (numéro, nom,
nom incomplet, …)
Le vendeur saisit un critère de recherche.
Le système affiche la liste des clients répondant
au critère de recherche. Si aucun client n’est
trouvé, il faut exécuter Exception 1.
Le vendeur sélectionne le client.
Le système affiche toutes les informations
nécessaires sur ce client (adresse, téléphone,
CA).

19
b) Saisie des produits commandés
Le vendeur demande la liste des produits.
Le système affiche la liste de tous les produits.
Pour tout produit commandé :
Le vendeur sélectionne un produit et saisit la quantité
commandée.
Le système affiche le PHT du produit sélectionné ainsi
que le MHT et le TVA.
Après la saisie de tous les produits commandés, le
système affiche le THT et le TTC de la commande.
c) Saisie de la date
Le vendeur saisit la date de passation de la commande.
Le système vérifie qu’elle est inférieure à la date du jour.
En cas d’anomalie, il faut exécuter Exception 2.

20
 d) Validation de la commande
Le vendeur demande la validation de la commande.
Le système vérifie que toutes les données obligatoires
sont saisies. S’il y’a une information manquante, il faut
exécuter Exception 3.
Le scénario se termine lorsque le système enregistre la
commande et lui affecte un numéro.

Scénarios alternatifs :
1 . Modifier une commande existante
…
2 . Consulter les commandes existantes
…
3. Annuler une commande existante
… 21
Exceptions :
1. Le système affiche le message : «Client non trouvé » et
le UC s’arrête.
2. Le système refuse la saisie, affiche le message : « date
de la commande doit être inférieure à la date du jours »
et donne la main au vendeur pour saisir une autre date
de commande
3. Le système affiche le message : « L’information …. est
manquante » et donne la main au vendeur pour
compléter l’information qui manque.

22
7. Relations entre UC
Relation d’inclusion
<<inclut>>

UC1 UC2

• Le UC source (UC1) incorpore le comportement

décrit par le UC destination (UC2) en un point
d'insertion déterminé.

UC2

UC1 contient UC2. 23

 • Le UC destination (UC2) n'est jamais tout seul, il
fait toujours partie d'un UC qui l'englobe (UC1).
• L’inclusion permet d'éviter de décrire la même
suite d'interactions plusieurs fois, et ce en rangeant
le comportement commun dans un UC propre.

 Exemple

Suivre <<inclut>> S’authentifier

Commandes

Gérer Clients <<inclut>>

24
 Description textuelle
Au niveau de la description du UC englobant (UC1)
l’inclusion se traduit par :
• une précondition ou
• une étape dans la description du scénario nominal
qui consiste en un appel du UC inclus (UC2).

25
Relation d’extension
<<étend>>

UC1 UC2
• Une instance du UC destination (UC2) étend son
comportement par l’ajout de celui du UC source
(UC1).

UC2

UC1
UC1 étend UC2. 26
 • Le cas de base (UC2) peut fonctionner tout seul,
mais il peut également être complété par un
autre, sous certaines conditions, et uniquement
à certains points appelés points d’extension. Ces
points d’extension sont définis dans le UC
destination (UC2).
• Cette relation permet de modéliser des
variantes de comportement d’un UC.
• L'extension peut être soumise à une condition.
 Exemple :

Gérer Clients
<<étend>>
Responsable
des ventes
Gérer Commandes 27
 Point d’extension
• Il possède un nom.
• Il décrit un emplacement dans le UC destination
(UC2) où le comportement du UC source sera
inséré.
• Format de description de point d’extension :

<Nom du UC>
Points d’extension
• <Nom du point > :
<Emplacement>
• …

Notation proposée pour le point d’extension

28
• Exemple

Gérer Clients

Responsable <<étend>>
des ventes
Gérer Commandes
Point d’extension
• Ajout Client : Client non trouvé

29
 Description textuelle :
Au niveau de la description textuelle du UC
destination (UC2), la relation d’extension se traduit
par l’appel du UC source (UC1) suite à une
condition.

30
 Relation de généralisation

UC Parent

UC Enfant
• Le UC enfant hérite du comportement de UC
parent et participe à toues les relations du parent.
• Le UC enfant peut compléter ou remplacer le
comportement du UC parent.
• Le cas d’utilisation parent peut être abstrait.
31
 Exemple

Internaute Rechercher
ouvrages

Effectuer Effectuer recherche

recherche rapide par thème
Effectuer recherche
avancée

32
8. Elaboration du modèle des UC
Identifier les
acteurs

Organiser les
acteurs

Identifier les UC

Définir un guide de
style

Décrire les UC Définir les

relations entre UC

Etapes d’élaboration d’un modèle de UC.

33
 Remarques
• Un grand nombre de UC est le signe d'un manque
d'abstraction et signifie que les objectifs du système
ne sont pas bien compris.
• Quelle que soit la taille et la complexité d'un système,
il y a relativement peu de UC mais beaucoup de
scénarios.
• La description d’un UC du système informatisé doit se
concentrer sur les interactions entre les acteurs et le
système, pas sur les interactions entre les acteurs.

34
Exemple

Identification
Nom : Enregistrer l’emprunt de documents
Acteur : Bibliothécaire
…
Description des scénarios:
Ce UC commence lorsque le client arrive au comptoir de
prêt pour emprunter des livres et des vidéos. (NON)
Ce UC commence lorsque le bibliothécaire fournit
l’identifiant de l’emprunteur.(OUI)
…

Ce UC se termine lorsque le Bibliothécaire donne le bulletin

et les ressources prêtées au Client. (NON)
Ce UC se termine lorsque le bulletin de prêt (contenant les
dates de retour, etc.) est imprimé par le système. (OUI)

35
• Il est possible de regrouper les acteurs, les cas
d’utilisations avec leurs descriptions en paquetages
quand
 le nombre d’acteurs et de cas d’utilisation est
important ou
 on veut mettre en commun des UC proches.

• Les UC ne sont pas formels : pas de vérification

automatique possible ni de génération automatique des
autres diagrammes.

36
9. Diagramme de UCs pour la modélisation
du métier
 La modélisation d’un SI avec UML comporte deux
préoccupations majeures :
• La modélisation du système métier de la société étudiée
afin de comprendre les structures statiques
organisationnelles de la société et ses processus
dynamiques (activités, informations, unités
organisationnelles)
• La modélisation du système informatisé dans le but de
construire un modèle de ce système

 Le système informatisé couvre la partie du

système métier qui peut être automatisée.

37
Etapes de modélisation du système métier

 Étude du périmètre et des intervenants

extérieurs à l’entreprise
 Étude des processus métier de l’entreprise
 Étude des travailleurs et des entités de
l’entreprise
 Étude du flux d’événements des processus
métier
 Étude des structures organisationnelles.

38
 Définition d’un processus métier

Un processus métier se compose d’une séquence

logique et chronologique d’une ou plusieurs
activités produisant un résultat mesurable à
valeur ajoutée pour les clients, les actionnaires et
les employés de l’organisation. Il est déclenché
par un événement interne, externe ou temporel.

39
 Remarques
 Dans UML, au niveau métier, les notions d’acteur interne
et d’acteur externe n’existent pas. Le concept d’acteur
signifie de fait acteur externe. Les acteurs internes (dans
MERISE) sont appelés travailleurs.

 Des icônes particulières sont proposées par Rational Rose

pour désigner les acteurs du métier et les travailleurs.

Acteur du métier Travailleur du métier

(Business actor) (Business worker)
40
 Remarques
 Dans la modélisation du métier, un cas d’utilisation
représente un processus métier. Rational Rose
propose l’icône suivante pour représenter les cas
d’utilisation (processus) métier :

Commander des produits

Attention!
 Les UC métier décrivent des tâches manuelles et
(eventuellement) des tâches informatisée.
 Les UC du système informatisé ne décrivent que des
tâches informatisée. 41
Remaque :

Il faut noter qu’un modèle de processus métier

décrit en général le métier, et non le système
informatisé. Certaines actions décrites sont
exécutées manuellement, sans interaction avec un
composant ou une application logicielle (par
exemple, l’action "Livrer produit" peut être
réalisée sans utilisation d’un élément logiciel).

42