UML:

Diagramme des
cas d’utilisation
Dimanche 12 Février 2023
Besoins utilisateurs
● Avant de développer un système, il faut savoir précisément à
QUOI il devra servir, càd à quels besoins il devra répondre.
Modéliser les besoins permet de :
● Faire l'inventaire des fonctionnalités attendues ;
● Organiser les besoins entre eux, de manière à faire
apparaître des relations (réutilisations possibles, ...).

● Avec UML, on modélise les besoins au moyen

de diagrammes de cas d'utilsation
Diagramme des cas
d’utilisation
● Un diagramme de cas d'utilisation capture le
comportement d'un système, d'un sous-système, d'une
classe ou d'un composant tel qu'un utilisateur extérieur le
voit. Il scinde la fonctionnalité du système en unités
cohérentes, les cas d'utilisation, ayant un sens pour les
acteurs. Les cas d'utilisation permettent d'exprimer le
besoin des utilisateurs d'un système, ils sont donc une vision
orientée utilisateur de ce besoin au contraire d'une vision
informatique.
Exemple
 Acteur
● Un acteur est l'idéalisation d'un rôle joué par une personne externe,
un processus ou une chose qui interagit avec un système.
● Il se représente par un petit bonhomme avec son nom (i.e. son rôle)
inscrit dessous.
Il est également possible de représenter un acteur sous la forme d'un
classeur stéréotypé. Ou un mélange des deux
 Acteur
● Élément extérieur du système qui interagit avec le système.
● Rôle typique jouée par un humain ou un système connexe par rapport au
système. Exemple: Guichetier, Client, Responsable commercial …
● Une même personne peut jouer plusieur rôles:
● Exemple: [Link] est directeur mais aussi commercial.
● Plusieurs personnes peuvent jouer plusieurs rôles:
● Paul et Pierre sont les deux des clients.
● Un acteur n’est pas forcément un être humain (dispositif matériel,
système logiciel etc.)
● Exemple: un distributeur de billets (GAB) peut être vu comme un acteur
● Un acteur exécute un ou plusieurs cas d’utilisations.
 Quelles sont les entités extérieures au système qui
interagissent directement avec le système ?
 Acteur: Description
● Pour chaque acteur, choisir:
● Un identificateur représentant de son rôle
● Donner une brève description textuelle
● Exemple:
 Acteur: utilité
La définition d’acteur permet:
• D’identifier les cas d’utilisation
• Exemple: Que peut faire un guichetier ? C’est quoi les
opérations que fait un client ? Quels sont les fonctions
d’un directeur ?
• De voir le système de différents points de vue (une vue
par acteur)
• De déterminer les droits d’accès par type d’acteur
• De fixer des ordres de priorité entre acteurs.
 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.
● Un cas d'utilisation se représente par une ellipse (ovale) contenant
le nom du cas (un verbe à l'infinitif), et optionnellement, au-dessus
du nom, un stéréotype
 Cas d’utilisation
● Un cas d’utilisation n’est pas un symbole dans le diagramme des cas
d’utilisation.
● C’est une manière de décrire une suite d’interaction entre un acteur et le
système
● Un diagramme des cas d’utilisation comporte plusieurs cas d’utilisation (use
case) qui interagissent entre eux pour constituer le système.
● Un cas d’utilisation est relié par une association « participe à » à un
acteur.
● L’ensemble des cas d’utilisation décrivent exhaustivement les
fonctionnalités du système (1UC = 1 fonctionnalité)
● => pour un acteur, quelles sont les manières différentes d’utiliser
le système ?
 Cas d’utilisation :
● Description
Pour chaque cas d’utilisation, choisir:
● Un identificateur simple et représentatif, commencer par un verbe à
l’infinitif, puis un complément du point de vue acteur et pas système.
Exemple: retirer l’argent pour un GAB.
● Réaliser une description détaillée et claire qui précise ce que fait le
système et ce que fait l’acteur.
● Eviter les chevauchements des associations (associations croisées)
● Si un cas d’utilisation contient plusieurs interactions, il faut le découper en
plusieurs UC.
 Système
● Un système est représenté par un rectangle, avec le nom du système en haut. Tous les
cas d’utilisation doivent être à l’intérieur du rectangle.
 Acteur principal et
Acteur principal: Déclenchesecondaire
le cas d’utilisation, fait appel au système (A
gauche du système).
Acteur secondaire : participe au cas d’utilisation, est appelé par le système (à
droite du système).
Représentation du diagramme
UC
 Relations entre acteur et UC
● Association:
● ● Relation entre acteurs et cas d'utilisation
● ● Représente la possibilité pour l'acteur de déclencher le cas

Une relation d'association est 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. Le symbole *
signifie plusieurs .exactement n s'écr
it tout simplement n, n..m signifie
entre n et m, etc. Préciser une
multiplicité sur une relation n'implique
pas nécessairement que les cas sont
utilisés en même temps.
 Cas d’utilisation interne
Quand un cas n'est pas directement relié à un acteur, il est qualifié de cas d'utilisation interne.
 Relations entre UC

● Il existe principalement deux types de relations :

● les dépendances stéréotypées, qui sont explicitées par
un stéréotype (les plus utilisés sont l'inclusion et
l'extension) ;
● et la généralisation/spécialisation.
● Une dépendance se représente par une flèche avec un
trait pointillé . Si le cas A inclut ou étend le cas B, la
flèche est dirigée de A vers B.
● Le symbole utilisé pour la généralisation est un flèche
avec un trait plein dont la pointe est un triangle fermé
désignant le cas le plus général.
Exemple : Borne interactive d’une
banque
Exemple 2: distributeur de billets
(GAB)
 Relation d’inclusion
● Relations entre cas
« include »
d'utilisation ● Inclusion : X
« includes » Y  X implique
Y Y est nécessaire
(obligatoire) pour X
 Relation d’extension
● Extension : X « extends » Y
 X peut être provoqué par
Y , X est optionnel
pour Y
● Attention au sens
 Relation de généralisation
● Généralisation : X est un
cas particulier de Y
 Relations entre acteurs
● La seule relation possible entre
deux acteurs est la
généralisation : un acteur A est
une généralisation d'un acteur
B si l'acteur A peut être
substitué par l'acteur B. Dans
ce cas, tous les cas d'utilisation
accessibles à A le sont aussi à
B, mais l'inverse n'est pas vrai.
Relations entre acteurs
 DUC: A retenir
● Diagramme de cas d'utilisation
● Conseil :
● Rester lisible
● ● Pas plus de 6 ou 8 cas dans un diagramme
● ● Au besoin, faire plusieurs diagrammes (si cas disjoints entre
acteurs, pour détailler un cas...)
● ● Relations entre cas seulement si nécessaires et pas trop lourdes
Pour les détails,
● privilégier la description textuelle
 Description textuelle des cas
● d’utilisation
Diagrammes de cas d'utilisation
● ● Utiles pour discussion avec le client car intuitifs et concis
● ● Pas suffisants pour l'équipe de développement Nécessité
d'une description détaillée des scénarios représentés par
chacun des cas :
● ● Description textuelle en langue naturelle structurée
● ● Vocabulaire précis correspondant aux diagrammes
 Description textuelle DUC
● Description textuelle d'un cas d'utilisation
● ● Nom du cas d'utilisation
● ● Brève description
● ● Acteurs
● ● Contexte
● ● Données en entrée et pré-conditions
● ● Données en sortie et post-conditions
● ● Scénario principal pour ce cas d'utilisation Étapes à suivre pour
réaliser ce cas
● ● Variantes, cas d'erreur Déviations des étapes du scénario principal,
scénarios alternatifs, scénarios d'erreur
 Scénario d’utilisation,
● Séquences d'étapes
exemple
● ● décrivant une interaction entre l'utilisateur et le système
● ● permettant à l'utilisateur de réaliser un objectif Système :
Site de vente en ligne
● Scénario : Effectuer une commande Le client s'authentifie
dans le système puis choisit une adresse et un mode de
livraison. Le système indique le montant total de sa commande
au client. Le client donne ses informations de paiement. La
transaction est effectuée et le système en informe le client par
e-mail.
 Scénario d’erreur, exemple

● Système : Site de vente en ligne

● Scénario : Effectuer une commande Le client s'authentifie
dans le système puis choisit une adresse et un mode de
livraison. Le système indique le montant total de sa
commande au client. Le client donne ses informations de
paiement. La transaction n'est pas autorisée, le
système invite le client à changer de mode de
paiement. Le client modifie ses informations. La
transaction est effectuée et le système en informe le client
par e-mail.
 Cas d’utilisation: Scénario
● Cas d'utilisation : Effectuer une commande Scénario principal :
● 1. Le client s'authentifie dans le système
● 2. Le client choisit une adresse et un mode de livraison.
● 3. Le système indique le montant total de sa commande au client.
● 4. Le client donne ses informations de paiement.
● 5. La transaction est effectuée et le système en informe le client par
e-mail.
● Cas particulier : 5a. La transaction n'est pas autorisée, le système
invite le client à changer de mode de paiement. Retour à l'étape 4.
Description textuelle UC
 UC Description textuelle:
●
parties
Une description textuelle couramment utilisée se compose de trois parties.
● La première partie permet d'identifier le cas, elle doit contenir les informations qui
suivent.
● Nom :
○ utiliser une tournure à l'infinitif (ex. : Réceptionner un colis).
● Objectif :
○ une description résumée permettant de comprendre l'intention principale du cas
d'utilisation. Cette partie est souvent renseignée au début du projet dans la phase
de découverte des cas d'utilisation.
● Acteurs principaux :
○ ceux qui vont réaliser le cas d'utilisation (la relation avec le cas d'utilisation est
illustrée par le trait liant le cas d'utilisation et l'acteur dans un diagramme de cas
d'utilisation).
 UC Description textuelle:
● Acteurs secondaires : parties
○ ceux qui ne font que recevoir des informations à l'issue de la réalisation du cas
○ d'utilisation.
● Dates :
○ les dates de création et de mise à jour de la description courante.
● Responsable :
○ le nom des responsables.
● Version :
○ le numéro de version.
 UC Description textuelle:
● parties
La deuxième partie contient la description du fonctionnement du cas sous la forme
d'une séquence de messages échangés entre les acteurs et le système. Elle contient
toujours une séquence nominale qui décrit de déroulement normal du cas. À la
séquence nominale s'ajoutent fréquemment des séquences alternatives (des
embranchements dans la séquence nominale) et des séquences d'exceptions (qui
interviennent quand une erreur se produit).
● Les préconditions :
○ elles décrivent dans quel état doit être le système (l'application) avant que ce cas
d'utilisation puisse être déclenché.
● Des scénarii :
○ ces scénarii sont décrits sous la forme d'échanges d'événements entre l'acteur et
le système. On distingue le scénario nominal, qui se déroule quand il n'y a pas
d'erreur, des scénarii alternatifs qui sont les variantes du scénario nominal et enfin
les scénarii d'exception qui décrivent les cas d'erreurs.
● Des postconditions :
○ elles décrivent l'état du système à l'issue des différents scénarii.
 UC Description textuelle:
parties
● La troisième partie de la description d'un cas d'utilisation est une rubrique
optionnelle. Elle contient généralement des spécifications non fonctionnelles
(spécifications techniques…). Elle peut éventuellement contenir une
description des besoins en termes d'interface graphique.
 Cas d’utilisation détaillé
● Nom : Commander
● Acteur : Client
● Données d'entrée : Produits sélectionnés par le client Le cas d'utilisation
commence lorsque le client clique sur le bouton « Commander »
● Scénario principal :
● 1. Le système demande au client de saisir son identifiant et son mot de passe
● 2. Le client saisit son identifiant et son mot de passe et valide
● 3. Le système demande au client de choisir son adresse de livraison parmi sa liste
d'adresses ou d'en saisir une nouvelle
● 4. Le client choisit une adresse de livraison et valide
● 5. Le système demande au client de choisir un mode d'expédition parmi une liste
prédéfinie (à préciser)
● 6. Le client choisit un mode d'expédition et valide
 Cas d’utilisation détaillé

● 7. Le système affiche un récapitulatif de la commande, indique le montant

total de la livraison et demande au client de choisir un mode de paiement
parmi une liste prédéfinie (à préciser)
● 8. Le client choisit un mode de paiement et valide
● 9. Le système demande au client de saisir ses informations de paiement
● 10. Le client saisit ses informations de paiement et valide
● 11. Le système informe le client que la transaction s'est effectuée
correctement et un e-mail récapitulatif de la commande est envoyé au client
 Cas d’utilisation détaillé

● Scénario d'erreur : Client inconnu 3a. Le client n'est pas connu du système.
Le système affiche un message d'erreur Retour à l'étape 1.
● Scénario alternatif : Nouvelle adresse de livraison
● 4a. Le client saisit une nouvelle adresse de livraison et valide Le scénario
reprend à l'étape 5
● Scénario alternatif : Modifications des choix de livraison
● 8a. Le client demande à modifier son adresse de livraison. Retour à l'étape 3.
● 8b. Le client demande à modifier le mode de livraison. Retour à l'étape 5.
Scénario d'erreur : Transaction impossible 11a. Le système informe le client
que ses informations de paiement sont incorrectes. Retour à l'étape 9.
Lien entre diagramme et texte:
exemple
 DUC: paquetage
● Un paquetage (package) est un
regroupement d'éléments de
modèle et de diagrammes. Il
permet ainsi d'organiser des
éléments de modélisation en
groupes
● Un paquetage se représente
comme un dossier avec son nom
inscrit dedans