Institut Supérieur d’informatique et de Multimédia de Sfax

Département d’informatique

Chapitre 2
UML: Diagramme de cas
d’utilisation
Assuré par:
Mme Faiza GHOZZI
Mme Karima DHOUIB
Mme Souhir BOUAZIZ

ISIM-Sfax, 2020-2021
 Introduction
DAB

retirer argent
<<include>>

Aspect fonctionnel : s'authentifier

Diagramme de package client

Diagramme de cas d’utilisation

Aspect statique :
Diagramme de classes
Diagramme de composants
Diagramme de structure composite
Diagramme de déploiement

Aspect dynamique :
Diagramme de séquence /collaboration
Diagramme de état- transition
Diagramme d’objet
Diagramme d’activités
Diagramme de temps
Diagramme général d’interaction

41
 Introduction
Les use cases (UC) ont été initialement proposé par OOSE de
Jacobson pour :
délimiter le système étudié,
améliorer la compréhension du fonctionnement du
système,
définir les relations entre le système et son
environnement.
Décrivent le comportement d’un système (action/réaction)
Spécifications
du point de vue utilisateurs :
L’utilisateur modélise ses besoins etUse non l’analyste (comme
Cases
avec Merise
Position des UC dans un processus de modélisation
Analyse Tests :
42
 Diagramme de UC : concepts de base
Modéliser les domaines et les sous-domaines
Fixer les frontières
Modèle métier
Acteur : personne ou système qui interagit avec le
système étudié en échangeant de l’information.
acteur

Package1 package : domaine, sous-domaine.

Utilise Relation

communique Relation

43
Diagramme de UC : exemple

44
 Concepts de base : les acteurs
Définition 1 :
Représente un rôle joué par une entité externe (utilisateur humain,
dispositif matériel, ou autre système) qui interagit directement avec
le système étudié
Définition 2 :
Une entité externe agissant sur le système qui peut
Échanger de l’information avec ce système
consulter ou modifier l'état du système,
Les acteurs sont :
Déterminés en examinant les :
Utilisateurs directs du système
Responsables de l’exploitation et/ou de la maintenance
Autres systèmes interagissant avec le système
Représentés sous forme de petits personnages ou sous forme de
rectangle avec le mot clé <<acteur>>
45
 Concepts de base : les acteurs
Un acteur peut être :
Principal :
Utilise les fonctions principales du système
Secondaire :
Effectue des tâches administratives ou de maintenance
Matériel externe:
Les dispositifs matériels :
Autres que les machines où s’exécute l’application
faisant partie du domaine de l’application et
nécessaires au fonctionnement du système
Les autres systèmes avec qui le système doit interagir.
Exemple d’un distributeur de billets bancaires:
Client, personne rechargeant le distributeur, imprimante, groupement
bancaire

46
 Concepts de base : les acteurs
Les acteurs :
Doivent être décrits d’une manière simple et précise
Avec des phrases en langage naturel
Peuvent être reliés par des liens de généralisation/spécialisation
Utilisateur / Administrateur
Exemple d’acteurs :
Humains :
les utilisateurs du logiciel à travers son interface graphique
Logiciels :
déjà disponibles qui communiquent avec le système grâce à une
interface logicielle
Matériels :
robots et automates qui exploitent les données du système ou qui sont
pilotés par le système

47
 Concepts de base : les acteurs
Exemple d’acteurs :

48
 Concepts de base : les cas d’utilisation
Définition 1 :
Un ensemble d'actions réalisées par le système, en réponse à une
action d'un acteur
Définition 2 :
Modélise une fonctionnalité d’un système ou d’une classe

Les cas d’utilisation :

Sont déterminés en observant et en précisant
Acteur par acteur les scénarios du point de vue utilisateur
Sont décrits en termes :
d’informations échangées et
d’étapes d’utilisation du système.

49
 Concepts de base : les cas d’utilisation
Un cas d’utilisation :
Regroupe une famille de scénarios d’utilisation
Est une abstraction du dialogue système/utilisateurs

Quand un acteur interagit avec le système:

Le cas d’utilisation instancie un scénario

L'ensemble des cas d’utilisation décrit les objectifs du système

50
 Cas d’utilisation
Objectif et interaction ?
Objectifs des utilisateurs : ce que les utilisateurs attendent du
système
Interactions avec le système : les mécanismes permettant de
satisfaire ces objectifs.
Exemple : développement un outil de traitement de texte
Objectif : définir un style du document
Interactions : choisir les polices, choisir les tailles, choisir la mise
en page, etc.
Il s’agit donc de définir les objectifs, puis déterminer les interactions
pour atteindre les objectifs.

© K. DHOUIB (ISIMS - 2020 /

2021) -- CSI 51
Cas d’utilisation

Exemple : développement d’un système ATM

Quelques descriptions dans le scénario suivant :
Retirer argent
Introduire la carte
Entrer le code PIN
Choisir le montant à retirer
Confirmer le montant
Prendre la carte
Prendre l’argent
Prendre les tickets
Toutes ces descriptions sont elles des cas d’utilisation ???
La réponse est NON,
Ces descriptions sont plutôt des interactions car elles ne satisfont pas un
objectif de l’utilisateur.
L’objectif de l’utilisateur, dans ce cas, est de « retirer de l’argent »: c’est le cas
d’utilisation.

52
Définition

Un diagramme de cas d’utilisation est utile pour :

Les utilisateurs pour exprimer les besoins
Les analystes pour comprendre le système
Les programmeurs pour réaliser le nouveau système
Les testeurs pour vérifier le nouveau système

53
 Concepts de base : relations entre cas
d’utilisation
Association :
Relation entre un acteur et un cas d’utilisation
Un acteur déclenche un cas d’utilisation :

CasUtilisation
Acteur

Relation d’inclusion :
Entre des cas d'utilisation
L’instance du CU source contient aussi le comportement décrit par le
CU destination. <<inclut>>

CasUtilisation1 CasUtilisation2

54
Concepts de base : relations entre cas
d’utilisation

55
 Concepts de base : relations entre cas
d’utilisation
Relation d’inclusion (suite) :
La relation d’inclusion a un caractère obligatoire:
La source doit indiquer à quel endroit le CU cible doit être inclus
Permet de :
Décomposer les comportements et
Définir des comportements partageables entre plusieurs CU.
Relation d’extension :
Entre cas d'utilisation
L’instance du CU source ajoute son comportement au CU
destination (si la condition est réalisée).
Le CU destination étend son comportement par l’ajout de celui du
CU source, si la condition est vérifiée.
<<étend>>
[con ditio n d'extens i on]

Cas Utilis ation1 Cas Utilis ation2

56
 Concepts de base : relations entre cas
d’utilisation
Relation d’extension (suite) :
Peut être soumise à une condition :
Le comportement ajouté est inséré au niveau d’un point d’extension
Ce point d’extension est défini dans le CU destination
Permet de modéliser des variantes de comportement d’un CU
Selon les interactions des acteurs et l’environnement du système
la condition d’extension peut être spécifiée
à côté du mot-clés <<étend>>
Point d’extension :
Possède un nom
Décrit :
Un emplacement dans le CU destination où le comportement du CU
source sera inséré.
UML ne définit aucun format de description de point d’extension

57
Exemple: inclusion

DAB

retirer argent
<<include>>

s'authentifier

client

58
Exemple : Extension

59
 Concepts de base : relations entre cas
d’utilisation
Relation de généralisation :
Entre cas d'utilisation
Le cas d’utilisation Fils est une spécialisation du cas d’utilisation
Parent

CasUtilisationParent
V irem ent

CasUtilsationEnfant Vi rem ent P arInte rnet

Exemple : On désire représente par un diagramme de CU les

virements bancaires effectués par des clients:
Un client peut être local ou distant
Un client peut effectuer un virement via Internet ou direct (banque)
Dans tous les cas, on doit procéder à une identification du client
Dans le cas d’un virement dont le montant dépasse 500, on procède à une
vérification du solde du compte du client.
60
 Exemple: Généralisation/spécialisation

Le système voiture

Réparer

Garagiste

Réparer Diesel Réparer essence

61
Exemple1 : inclusion, extension et
généralisation

62
Exemple2: inclusion, extension et
généralisation

63
 Démarche
Identifier le domaine et les sous-domaines
Identifier les acteurs
Décrire les acteurs
Décrire les rôles: principal, secondaire
Actif/ passif
Identifier les cas d’utilisation/ par acteur
Décrire brièvement (résumé) chaque cas d’utilisation
Donner un ordre de priorité
Identifier les relations entre les CU et entre les acteurs
Représenter le diagramme
Décrire textuellement chaque cas d’utilisation

64
 Description des cas d’utilisation
Il n’existe pas de norme (UML) établie pour la description textuelle
des cas d’utilisation.

Généralement, on y trouve pour chaque cas d’utilisation :

son nom,
un bref résumé de son déroulement,
le contexte dans lequel il s’applique,
les acteurs qu’il met en jeu,
une description détaillée :
le déroulement nominal de toutes les interactions,
les cas nécessitant des traitements d’exception,
les effets du déroulement sur l’ensemble du système,
etc.

65
 Description des cas d’utilisation
Sommaire d’identification
Titre : ……………….. Type : …………………
Résumé :………………………………………………………………………………
Acteurs :
Date de création : Date de mise à jour :…………………………………
Version : Auteur(s) :

Description des Enchaînements :

Pré conditions :
Scénario nominal :
1.
2.
…
Enchaînements alternatifs :
A1…
A2…
Contraintes
….
66
 Description des cas d’utilisation
Quelques conseils :
Un cas d’utilisation doit être :
Simple
Décrit de manière claire et concise
Le nombre d’acteurs interagissant avec le CU doit être limité
Lors de la construction d’un CU, il faut se demander :
Quelles sont les tâches de l’acteur ?
Quelles informations l’acteur doit-il créer, sauvegarder, modifier, détruire
ou simplement lire ?
L’acteur devra-t-il informer le système des changements externes ?
Le système devra-t-il informer l’acteur des conditions internes ?

Modélisation objet avec UML

P.A. Muller, N. Gaertner

67
 Exemple de Cas d’utilisation
Fonctionnement des caisses enregistreuses d’un super marché :

Un client arrive à la caisse avec des articles à payer.

Le caissier enregistre le numéro d’identification de chaque article,
ainsi que la quantité si elle est > 1.
La caisse affiche le prix de chaque article et son libellé.
Quand tous les achats sont enregistrés, le caissier signale la fin de la
vente.
La caisse affiche alors la fin des achats et le prix total à payer.
Après la saisie des articles, le client peut présenter des coupons de
réduction pour certains articles
Le client choisit son mode de paiement :
Liquide : le caissier encaisse l’argent reçu, la caisse indique le montant à
rendre au client.

68
 Exemple de Cas d’utilisation
Un système de caisse enregistreuse de super marché :

Chèque : le caissier vérifie la solvabilité du client en transmettant une

requête à un centre d’autorisation via la caisse.
Carte de crédit : un terminal bancaire fait partie de la caisse et transmet
une demande d’autorisation en fonction du type de la carte.

La caisse enregistre la vente et imprime le ticket.

Le caissier donne le ticket au client.
Quand le paiement est terminé, la caisse transmet l’information sur le
nombre d’articles vendus au système de gestion des stocks.
chaque matin, le responsable du magasin initialise les caisses pour la
journée.

69
 Exemple de Cas d’utilisation
Sommaire d’identification
Titre : Traiter le passage en caisse
Résumé : ce CU commence lorsqu’un client arrive à une caisse avec des
articles à acheter. Le caissier enregistre les achats et récupère le paiement. A la
fin de l’opération, le client part avec les articles.
Acteurs : Caissier (P), Client (S), Gestion des stock (S)
Date de création : Date de mise à jour :…………………………………
Version : 1 Auteur(s) : ………………………………….
Description des Enchaînements :
Pré conditions : La caisse est en service : un caissier y est connecté
Scénario nominal :
Représente le déroulement normal d’un cas d’utilisation : les différentes
interactions utilisateur / système permettant l’exécution réussie du traitement

(voir suite)

70
 Exemple de Cas d’utilisation
Acteur Système
1. Ce CU commence quand un client arrive
à la caisse avec des articles qu’il veut
acheter.
2. Le caissier enregistre chaque article. S’il y 3. La caisse détermine le prix de l’article et
a plus d’un exemplaire par article, le caissier ajoute des informations sur l’article à la vente
indique également la quantité. en cours.
La caisse affiche la description et le prix de
l’article en question.
4. Après avoir enregistré tous les articles, le 5. La caisse calcule et affiche le montant total
caissier indique que la vente est terminée. de la vente.

6. Le caissier annonce le montant total au

client.
7. Le client choisit le type de paiement :
a. En cas de paiement …
b. En cas de …
c. En cas …
8. La caisse enregistre la vente et imprime …
9. Le caissier donne le ticket de caisse au
client.
71
 Exemple de Cas d’utilisation
Enchaînement alternatif :
Quand l’enchaînement précisé par le scénario nominal ne peut pas se
dérouler comme prévu :
Le cas d’utilisation converge tout de même.

Exemple:
Numéro d’identification d’un article est inconnu

l’enchaînement démarre au point 2 du scénario nominal.

3. La caisse indique que le numéro d’identification de l’article est
inconnu. L’article ne peut alors pas être pris en compte dans la vente
encours.

Le scénario reprend au point 2.

72
 Exemple de Cas d’utilisation
Enchaînement d’erreur :
Quand l’enchaînement précisé par le scénario nominal ne peut pas se
dérouler :
Le cas d’utilisation se termine par un échec.

Exemple:
Client ne pouvant payer (ou le centre d’autorisation refuse le
payement)
l’enchaînement démarre au point 6 du scénario nominal.
7. Le client ne peut pas payer le total avec aucun des moyens autorisés.
8. Le caissier annule l’ensemble de la vente et le cas d’utilisation se
termine en échec :
la vente ne peut pas avoir lieu

73
 Conclusion
Les cas d’utilisation :
Sont de bons moyens pour modéliser les besoins des utilisateurs par les utilisateurs.
Les avantages :
Un formalisme simple : Les concepts proposés sont faciles à comprendre et à
utiliser.
Les modélisations résultats (UC): Faciles à comprendre, à lire et à interpréter.
Un bon moyen de communication : client/concepteur et
concepteur/concepteur
Les limitations :
Subjectifs, dépendant de l’utilisateur : Peuvent être peu précis, ne reflétant
pas les besoins majeurs de l’utilisateur ou interprétés différemment.
Pas formels : pas de vérification automatique possible ni de génération des
autres diagrammes, …

74
 Conclusion

Les cas d’utilisation interviennent tout au long du cycle de

vie, depuis le cahier des charges jusqu’aux tests, en
passant par l’analyse, la conception, la réalisation et la
rédaction de la documentation pour l’utilisateur.

Les cas d’utilisation

servent de fil
conducteur pour
l’ensemble du
projet.

75
 Application : librairie en ligne

Développement d’un site web pour une librairie

L’objectif fondamental du futur site est de permettre aux
internautes de rechercher des ouvrages par thème,
auteur, mots-clés, etc, de se constituer un panier virtuel,
puis de pouvoir les commander directement sur le Web.
Analyse
Acteurs
Internaute
Cas d’utilisation
Chercher des ouvrages
Gérer son panier
Effectuer une commande

76
 Application : librairie en ligne

Diagramme première version

Chercher des
ouvrages

Internaute
Gérer son panier

Effectuer une
commande

77
 Application : librairie en ligne

Après une 2ème itération pour la définition des besoins du

projet, nous sommes arrivés à la conclusion qu’il était
nécessaire de distinguer deux profils d’internautes :
le Visiteur, inconnu du site web, mais qui peut néanmoins
rechercher des ouvrages et gérer un panier ; À tout
moment, il peut choisir de créer un compte, afin de
devenir client.

le Client, déjà connu par le site web, qui peut seul

effectuer une commande et en suivre l’état.

78
 Application : librairie en ligne
Diagramme en deuxième version

Créer un
compte Client

Visiteur
Chercher des
ouvrages

Client
Gérer son panier

Effectuer une
commande

79
 Application : librairie en ligne
Nous remarquons maintenant que les deux acteurs Client
et Visiteur partagent deux cas d’utilisation :
Chercher des ouvrages et
Gérer son panier. Créer un
Visiteur compte Client

Le diagramme Chercher des

devient alors : ouvrages

Internaute

Gérer son panier

Effectuer une
commande

Client

80