Vous êtes sur la page 1sur 26

Chapitre 1: Le diagramme de

cas d’utilisation

Responsable : Achraf MTIBAA


Année Universitaire 2018-2019

1
Chapitre 1: Le diagramme de cas d’utilisation

◼ 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.

2
1-Définitions
Définition 1:
Un cas d’utilisation (use case) modélise une interaction entre
le système informatique à développer et un utilisateur ou
acteur interagissant avec le système.

Définition 2:
Un cas d’utilisation décrit un ensemble d’actions réalisées par
le système qui produit un résultat observable pour un acteur.

Spécifications

Use Cases

Analyse Tests

3
Définitions
◼ Les cas d’utilisation :
 servent de base à la traçabilité des exigences d'un système
dans un processus de développement intégrant UML.
 se limitent aux préoccupations "réelles" des utilisateurs :
◼ ne présentent pas de solutions d'implémentation et

◼ ne forment pas un inventaire fonctionnel du système.

◼ Un cas d’utilisation avec UML :


 est la solution pour représenter au niveau conceptuel, les
besoins des utilisateurs (Merise ne permet pas cette
modélisation).
 permet de structurer les besoins des utilisateurs et les objectifs
(fonctionnalités) correspondants d'un système.
 identifie les utilisateurs du système (acteurs) et leurs interactions
avec le système.
 permet de classer les acteurs et structurer les objectifs du
système. 4
Définitions
◼ Les cas d’utilisation :
 Recentrent l’expression des besoins sur les utilisateurs
 ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et
organiser les besoins
 Partitionnent l’ensemble des besoins d’un système.

◼ Les besoins:
 définissent le contour du système à modéliser
◼ ils précisent le but à atteindre,

 permettent d'identifier les fonctionnalités principales (critiques)


du système.

5
2-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
6
3-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>>

7
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.

8
5-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 représentés par des ellipses
 Peuvent être contenus dans un rectangle (représentant le
système)
 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.

9
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


◼ Utilité des cas d’utilisation pour :
 les utilisateurs : exprimer les besoins
 Les analystes : comprendre
 Les programmeurs : réaliser
 Les testeurs : vérifier

10
Concepts de base : les cas d’utilisation

◼ Une fois identifiés, les acteurs doivent être décrits d’une


manière claire et concise, en trois ou quatre lignes
maximum.
◼ Lorsqu’il y a beaucoup d’acteurs dans un système, il est
conseillé de les regrouper par catégories afin de faciliter
la navigation dans le modèle des cas d’utilisation
◼ Les cas d’utilisation doivent être vus comme des classes
dont les instances sont les scénarios.
◼ Un scénario correspond au flot de messages échangés
par les objets.

11
Concepts de base : relations entre cas
d’utilisation
◼ Association (relation de communication):
 Relation entre un acteur et un cas d’utilisation
 Un acteur déclenche un cas d’utilisation :

CasUtilisation
Acteur

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

12
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>>
[condition d'extension]

CasUtilisation1 CasUtilisation2
13
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

14
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
Virement

CasUtilsationEnfant
VirementParInternet

◼ Exemple : On désire représenter 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.

15
Exemple

Virement Client Local


Client Distant
<<étend>>
Montant > 500
<<Inclut>>

VirementInternet
Identification Vérification solde compte

16
Exemple

◼ Et voici le point d’extension :

Virement

Points d’extension
• Vérification supplémentaire:
après identification

17
MOO (UML)
Description des cas d’utilisation
(Suite Chapitre I)

Responsable : Achraf MTIBAA


Année Universitaire 2018-2019

18
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.

19
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
….
20
Exemple de Cas d’utilisation

Sommaire d’identification
Titre : Traiter le passage en caisse
Résumé : 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) : Etudiants 2ème année
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)

21
Exemple de Cas d’utilisation

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 a 3. La caisse détermine le prix de l’article et ajoute
plus d’un exemplaire par article, le caissier des informations sur l’article à la vente en cours.
indique également la quantité. 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 de
caissier indique que la vente est terminée. 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.


22
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.

23
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

24
◼ 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.
◼ 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
25
journée.
Exemple de Cas d’utilisation

Responsable Initialier la caisse


Magasin

<<étend>>

Prendre en compte coupons


Caissier Traiter le passage en caisse
<<Acteur>>
<<inclut>> Gestion des stocks

Client <<Acteur>>
Traiter le Paiement Centre autorisation
cartes

<<Acteur>>
Centre autorisation
chèques
Paiement Liquide Paiement Chèque Paiement Carte

26