UML Cas2Dutilisation

UML 2
Diagramme de cas
d’utilisation
Hanifi Majdoulayne
2022 - 2023
Introduction
 UML permet de construire plusieurs modèles d’un système :
 le système du point de vue des utilisateurs,
 la structure interne,
 une vision globale ou détaillée.
 Les modèles se complètent et doivent être cohérents.

 Ils sont élaborés tout au long du cycle de vie du développement d’un système (depuis le
recueil des besoins jusqu’à la phase de conception).
 Dans ce chapitre, nous allons étudier un des modèles , en l’occurrence le diagramme de
cas d’utilisation.
 Il permet de recueillir, d’analyser et d’organiser les besoins.
 C’est à ce niveau que commence l’étape d’analyse d’un système.
Introduction
 Le développement d’un nouveau système, doit répondre à un ou plusieurs besoins.
 Par exemple, une banque a besoin d’un guichet automatique pour que ses clients puissent
retirer de l’argent même en dehors des heures d’ouverture de la banque.
 Celui qui commande le logiciel est le client et celui qui réalise le logiciel est le développeur.
 Le client intervient constamment au cours du projet, notamment pour :

 définir et exprimer ses besoins ;
 valider les solutions proposées par le développeur ;
 valider le produit livré.
3
Introduction
 UML sert à formaliser les besoins, pour être compréhensible par toutes les personnes impliquées
dans le projet.
 Souvent, le client et les utilisateurs ne sont pas des informaticiens.
 Il leur faut donc un moyen simple d’exprimer leurs besoins.
 C’est précisément le rôle du diagrammes de cas d’utilisation.
 Il permet de recenser les grandes fonctionnalités d’un système.
4
Définitions
 Un diagramme de cas d’utilisation est un diagramme de comportement qui permet

de décrire les besoins auxquels doit répondre l’application.
 C’est un des premiers diagrammes à écrire pour commencer l’analyse.
 Il est principalement utilisé pour :

 permettre au client de définir ses besoins.
 traduire le cahier des charges.
 démarrer l’analyse et le développement.
5
Définitions
 Un diagramme de cas d’utilisation comprend les entités suivantes :

 acteurs
 cas d’utilisation
 système
 Le diagramme des cas d’utilisation apporte une vision utilisateur et absolument pas une vision
informatique.
 Il ne nécessite aucune connaissance informatique et l’idéal serait qu’il soit réalisé par le client.
 Le diagramme des cas d’utilisation n’est pas un inventaire exhaustif de toutes les fonctions du
système.
 Il ne liste que des fonctions générales essentielles et principales sans rentrer dans les détails.
6
Les éléments d’un diagramme des cas d’utilisation :
 Acteurs :
 Avant de rechercher les besoins, la première tâche consiste à définir les limites du système (c.à.d. ce
qui est inclus ou pas dans le système), puis à identifier les différentes entités intervenantes sur le
système.
Ces entités sont appelées acteurs.
 Un acteur se représente par un petit bonhomme ayant son nom inscrit dessous
acteur
 Un acteur est un utilisateur externe au système. Cela peut être :
 Une personne.
 Du matériel (capteurs, moteurs, relais…).
 Un autre système
7
Définitions
 Système :
 Le système permet de définir la frontière entre « l’interne » et « l’externe »

(l’utilisateur, etc.).
 Les acteurs sont extérieurs au système.

 Exemple : Le DAB (Distributeur Automatique de Billet)
8
 Système :
Définitions
 Un DAB permet à tout détenteur de carte bancaire de retirer de l’argent.
 Si le détenteur de carte est un client de la banque propriétaire du DAB, il peut en plus

consulter les soldes de ses comptes et effectuer des virements entres ces différents
comptes.
 Les transactions sont sécurisées c’est-à-dire :

 Le DAB consulte le Système d’Information de la banque (S.I. Banque) pour les opérations que
désire effectuer un client de la banque (retraits, consultation soldes et virements).
 Le DAB consulte le Système d’Autorisation Globale Carte Bancaire (Sys. Auto.) pour les retraits
des porteurs de cartes non clients de la banque.
 Le DAB nécessite des opérations de maintenance tel que la recharge de billets, la

récupération des cartes avalées, etc.
9
 Système :
Définitions
 les différents acteurs interagissant avec le DAB :
10
Définitions
 Cas d’utilisation :
 Un cas d’utilisation décrit une interaction entre un acteur et le système.
 Il représente l’objectif de l’utilisateur lorsqu’il utilise le système.
 Les cas d’utilisation sont intérieurs au système.
11
Définitions
 La découverte des cas d’utilisation constitue normalement la première phase
d’analyse du système.
 Elle est élaborée en général par entretiens avec les utilisateurs et les
intervenants du système.
 On élabore le diagramme dans l’ordre suivant :
 Identification du système.
 Identification des acteurs principaux et secondaires.
 Identification des buts des acteurs (cas d’utilisation)
12
Définitions
cas d’utilisation
acteur
 On représente en UML un cas d’utilisation par une ellipse contenant en général

une phrase verbale à l’infinitif.
 L’ensemble des cas d’utilisation contenus dans le cadre constitue « un sujet ».
 Les acteurs sont connectés par des traits (associations ) aux cas d’utilisation et
mettent en évidence les interactions possibles entre le système et le monde
extérieur.
13
Diagramme de cas d’utilisation
Exemple 1:
Guichet automatique Nom du sujet
Retirer de
l’argent Cas d’utilisation
tion
ci a
o
ass
Effectuer un
virement
client
Consulter
compte
Diagramme de cas d’utilisation modélisant un guichet automatique 14

Relations entre cas d’utilisation
 Pour clarifier un diagramme, UML permet d’établir des relations entre les cas
d’utilisation.
 Il existe principalement deux types de relations :
1. les dépendances stéréotypées : “include”, “extend”.

2. la généralisation/spécialisation.
15
1. La relation d’inclusion “include” :
 Un cas A est inclus dans un cas B si le comportement décrit par le cas A “appelle” le comportement du cas
B.
 On dit alors que le cas B dépend de A.
 Cette dépendance est symbolisée par le stéréotype “include”.
 Par exemple, l’accès aux informations d’un compte bancaire inclut nécessairement une phase
d’authentification avec un mot de passe.
B
A e>>
<<includ Consulter
un compte
Imprimer
Solde Compte <<in
clude
>>
S’identifier
16
Exemple :
17
18
2. La relation d’extension « extend »:
 Un cas d’utilisation A étend un cas d’utilisation B lorsque le cas d’utilisation A peut être appelé au cours de
l’exécution du cas d’utilisation B.
 Exécuter B peut éventuellement entraîner l’exécution de A : contrairement à l’inclusion, l’extension est
optionnelle. Cette dépendance est symbolisée par le stéréotype << extend >> .
 La relation <<extend>> indique qu’un cas d’utilisation est enrichi d’un comportement additionnel.
B A
<e x t end>>
Commander < Commander
Nourriture une boisson
> Boire une

Manger
<<extend> boisson
Nourriture
19
20
3. La relation de généralisation :
 Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept
d’héritage dans les langages orientés objet.
B A
<< géneralisation >>
payer par
carte payer
 Le symbole utilisé pour la généralisation est une flèche en trait plein dont la pointe est un triangle fermé. La flèche pointe vers
le cas le plus général.
 Remarque : Attention à l’orientation des flèches : si le cas A inclut B on trace la flèche de A vers B, et si B étend A, la flèche
est dirigée de B vers A.
21
La relation de généralisation :
payer
Payer en liquide Payer par chèque Payer par carte
22
Relations entre acteurs
 La seule relation possible entre deux acteurs est la généralisation.
 Si un acteur A est une généralisation d’un acteur B, tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse
n’est pas vrai.
23
Relations entre acteurs
 Dans cet exemple, le directeur des ventes est un préposé aux commandes avec un pouvoir supplémentaire
(en plus de pouvoir passer et suivre une commande, il peut gérer le stock).
 Le préposé aux commandes ne peut pas gérer le stock.
24
Comment identifier les acteurs ?
 Les acteurs d’un système sont les entités externes à ce système qui interagissent (saisie de données,
réception d’information, …) avec lui.
 Les acteurs sont à l’extérieur du système et dialoguent avec lui.
 Ces acteurs permettent de cerner l’interface que le système va devoir offrir à son environnement.
 Chaque acteur doit être nommé. Ce nom doit refléter son rôle, car un acteur représente un ensemble
cohérent de rôles joués vis-à-vis du système.
25
 Les différents acteurs d’un système peuvent être :

• des utilisateurs (ex : responsable clientèle, responsable d’agence, administrateur, …) ;
• les périphériques manipulés par le système (imprimantes, hardware d’un distributeur de billet, …) ;
• des systèmes informatiques externes au système, mais qui interagissent avec lui, etc.
 Pour faciliter la recherche des acteurs, on peut imaginer les frontières du système.
 Tout ce qui est à l’extérieur et qui interagit avec le système est un acteur, tout ce qui est à l’intérieur est une
fonctionnalité à réaliser.
26
 En général, les utilisateurs ne sont pas difficiles à trouver.
 Mais il faut veiller à ne pas oublier les personnes responsables de l’exploitation et de la maintenance du système.
 Par exemple, un logiciel de surveillance qui limite les accès à un bâtiment doit avoir un administrateur chargé de créer des groupes de personnes
et leur donner des droits d’accès.
 Il ne s’agit pas ici des personnes qui installent et paramètrent le logiciel avant sa mise en production, mais des utilisateurs du logiciel dans son
fonctionnement.
27
 Un cas d’utilisation a toujours au moins un acteur principal pour qui le système produit un résultat observable, et éventuellement d’autres acteurs
ayant un rôle secondaire.
 Par exemple, l’acteur principal d’un cas de retrait d’argent dans un distributeur automatique de billets est la personne qui fait le retrait, tandis que
le système qui vérifie le solde du compte est un acteur secondaire ( celui qui participe à la réalisation du cas d’utilisation ).
 En général, l’acteur principal initie le cas d’utilisation par ses sollicitations.
28
Acteurs
 Bon acteur secondaire
• « le garagiste demande au système comptable d’éditer la facture pour facturer le client »
 Mauvais acteur secondaire

• « le garagiste demande les problèmes rencontrés et les informations générales de la voiture au client pour enregistrer le bon de travail »
29
Acteurs
 Bien choisir son acteur
30
Comment recenser les cas d’utilisation ?
 L’ensemble des cas d’utilisation décrit exhaustivement les exigences fonctionnelles du système.
 Chaque cas d’utilisation correspond à une fonction métier du système, selon le point de vue d’un de ses acteurs (exemple du distributeur de
billet : Retirer de l’argent ou Distribuer de l’argent ).
 Aussi, pour identifier les cas d’utilisation, il faut se placer du point de vue de chaque acteur et déterminer comment et surtout pourquoi il se sert
du système.
 Il faut éviter les redondances et limiter le nombre de cas en se situant à un bon niveau d’abstraction.
 Nommez les cas d’utilisation avec un verbe à l’infinitif suivi d’un complément en vous plaçant du point de vue de l’acteur, et non pas de celui du
système.
 Il n’y a pas de notion temporelle dans un diagramme de cas d’utilisation.
31
 Système : Réstaurant
32
 Généralisation des acteurs
33
Un cas d’utilisation
 Un Cas d’utilisation
• décrit comment un acteur utilise le système pour parvenir à son but ;

• et ce que le système fait pour que l’acteur puisse atteindre son but.
 Le cas d’utilisation décrit comment le système et ses acteurs collaborent
• Un cas d’utilisation est une action, qui a pour origine un dialogue entre un acteur et le système et dont le résultat est un produit mesurable.
34
Énoncé
 On considère le système suivant de gestion d’un DAB (Distributeur automatique de billets) :
• Le distributeur délivre de l’argent à tout porteur de carte (carte Visa ou carte de la banque)
• Pour les clients de la banque, il permet :
 la consultation du solde du compte
 le dépôt d’argent (chèque ou numéraire)
• Toute transaction est sécurisée et nécessite par conséquent une authentification
• Dans le cas où une carte est avalée par le distributeur, un opérateur de maintenance se charge de la récupérer.
• C’est la même personne qui collecte également les dépôts d’argent et qui recharge le distributeur.
 Questions
• Enrichissez votre diagramme avec des cas d’utilisation
35
Diagramme de contexte
 Système informatique de la banque: gère les comptes des clients.

 Système d’autorisation de cartes bancaires: permet de valider l’utilisation d’une carte pour un retrait
36
 Porteur de carte :
• Retirer de l’argent.
 Client banque :
• Retirer de l’argent.
• Consulter le solde de son compte courant.
• Déposer de l’argent (du numéraire ou des chèques).
 Opérateur de maintenance :
• Recharger le distributeur.
• Maintenir l’état opérationnel (récupérer les cartes avalées,
récupérer les chèques déposés, remplacer le ruban de papier,
etc.).
 Système d’autorisation (Sys. Auto.) :
 Système d’information (SI) banque :
37
Recharger le Opérateur de maintenance

distributeur
Maintenir l’état
opérationnel 38
Règles d’utilisation
 Un cas d’utilisation
• Correspond à une et une seule tâche métier -> pas de « et » dans le nom
• Actions correctrices :
 Eclater en deux cas d’utilisation
 Renommer le cas d’utilisation
39
Règles d’utilisation
 Mettre en place un découpage fonctionnel
• Utilisation des packages
 Réduire la complexité des modèles
 Mettre en avant les grands pôles de la solution
40
Démarche
 La modélisation des cas d’utilisation commence par l’identification du contexte, c’est-à-dire du périmètre
 Celui-ci est utilisé par des acteurs (rôles), qu’il faut définir
• Attention, une personne peut jouer plusieurs rôles
 Pour chaque acteur, il faut identifier ses objectifs, ses besoins et ce qu’il attend du système
41
Système de formation Emedia
42
Description textuelle des cas d’utilisation
 Ce n’est pas obligatoire, mais il est recommandé de rédiger une description

textuelle de chaque cas d’utilisation afin de les détailler.
 Une description textuelle classique se compose de trois parties :
 Partie 1 : Identification.
- Titre : Nom du cas d’utilisation
- Résumé : description du cas d’utilisation.
- Acteurs : descriptions des acteurs principaux et secondaires.
- Dates : Date de création et date de mise à jour.
43
 Partie 2 : Description des scénarios..
- Les pré-conditions : État du système avant que le cas d’utilisation puisse être déclenché.
- Les Scénarios (un scénario est une instance d’un cas d’utilisation).
 Il y a plusieurs types de scénarios :
1. Le scénario nominal qui correspond à un déroulement normal d’un cas d’utilisation.
2. Les scénarios alternatifs qui sont des variantes du scénario normale.
3. Les scénarios d’exceptions qui décrivent ce qui se passe lors d’une erreur.
- Les post-conditions : Elles décrivent l’état du système après l’issue de chaque scénario.
44
 Partie 3 : Exigence non fonctionnelle.
 La partie 3 peut être omise, mais si elle est présente, elle permet de préciser des spécifications non
Fonctionnelles : qui sont importantes voire critiques aux yeux des utilisateurs et qui assurent le bon
fonctionnement du système.
Exemple :
 Prix maximum de la solution à développer
 Prévoir le niveau de charge, par exemple 100000 utilisateurs simultanés, pour que le système ne se
bloque pas
 Sécurité du système : traçage des mises à jour des données dans le système, gestion de la
confidentialité, gestion de l’intégrité des données, protection des données personnelles …
45
Exemple de description textuelle : Le cas d‘utilisation ‘Retirer de l’argent’ du DAB
 Partie 1 : Identification
 Titre : Retirer de l’argent.
 Résumé : Ce cas d’utilisation permet aux possesseurs de carte bancaire de retire de l’argent.
 Acteur principale : Un porteur de carte bancaire.
 Acteurs secondaires : Le Système d’Information de la banque et le Système d’Autorisation
 Date : 16/01/2023
46
Exemple de description textuelle : Le cas d‘utilisation Retirer de l’argent du DAB
 Partie 2 : Description des scénarios.
 Pré-conditions :
 Le DAB contient des billets.
 Les connexions avec le Système d’Autorisation et le Système d’information de la banque sont opérationnelles.
 Scénario nominal :
1) Le Porteur de carte introduit sa carte dans le DAB.
2) Le DAB vérifie que la carte introduite est bien une carte bancaire.
3) Le DAB demande le code de la carte au Porteur de carte.
4) Le Porteur de carte saisit son code.
5) Le DAB compare ce code avec celui qui est codé sur la carte.
6) Le DAB demande une autorisation au Système Globale d’autorisation. 47

 Scénario nominal :
7) Le Système d’Autorisation globale donne son accord et indique le crédit hebdomadaire.
8) Le DAB demande le montant désiré au Porteur de carte.
9) Le Porteur de carte saisit le montant.
10) Le DAB vérifie si le montant demandé est inférieur ou égale au crédit hebdomadaire.
11) Le DAB rend la carte et demande au Porteur de carte de la retirer.
12) Le Porteur de carte reprend sa carte.
13) Le DAB demande au Porteur de carte s’il désire un ticket.
14) Le Porteur de carte accepte le ticket.
15) Le DAB délivre le ticket et les billets.
16) Le Porteur de carte prend les billets et le ticket. 48

 Scénarios alternatifs :
• Scénario alternatif SA1: Le code est erroné pour la première ou la deuxième fois.
o SA1 commence au point 5 du scénario nominal.
o Le DAB indique que le code est erroné.
o Le DAB enregistre l’échec.
o Le scénario reprend au point 3 du scénario nominal.
• Scénario alternatif SA2: Le montant demandé est trop élevé.
o Le DAB affiche le montant max et demande au Porteur de carte de ressaisir un montant.
o Le scénario reprend au point 9 du scénario nominal. 49

 Scénarios alternatifs :
• Scénario alternatif SA3 : Le ticket est refusé.
o L’utilisateur refuse le ticket.
o Le DAB délivre les billets.
o L’utilisateur prend les billets.
50
 Scénarios d’exception:
• Scénario d’exception SE1: Carte non valide.
o SE1 commence au point 2 du scénario nominal.
o Le DAB Indique que la carte n’est pas valide restitue la carte et met fin au cas.
• Scénario d’exception SE2 : Le code est erroné pour la troisième fois.
o Le DAB Indique que le code est erroné pour la troisième fois, confisque la carte et met fin au cas.
• Scénario d’exception SE3 : Retrait non autorisé.
o Le DAB Indique que tout retrait est impossible, restitue la carte et met fin au cas.
51
 Scénarios d’exception:
• Scénario d’exception SE4: Carte non reprise.
o Au bout de 30s, le DAB confisque la carte et met fin au cas.
• Scénario d’exception SE5: Billets non pris.
o Au bout de 30s, le DAB reprend les billets et met fin au cas.
• Scénario d’exception SE6: Annulation de la transaction.
o SE6 peut démarrer entre les points 4 et 9 du scénario nominal.
o Le DAB éjecte la carte et met fin au cas.

52
 Post-conditions:
 Les détails de la transaction doivent être enregistrés (montant, numéro carte, date…) aussi bien en cas de
succès que d’échec.
 Partie 3 : Exigences non fonctionnelles
 La saisie du code confidentiel ne doit pas faire apparaître le code à l’écran.
 Le compte du client ne doit pas être débité tant que les billets n’ont pas été distribués.
53
Conclusion
 Les phases de recueil des besoins et d’écriture des spécifications sont longues et fastidieuses.
 Mais quand elles sont bien menées, elles permettent de lever toutes les ambiguïtés du cahier
des charges et de recueillir les besoins dans leurs moindres détails.
 Les spécifications permettant d’approfondir les besoins.
 Le diagramme de cas d’utilisation est un premier modèle d’un système.
 A ce niveau, nous connaissons précisément ce qui entre et ce qui sort du système, mais, en
revanche, nous ne savons toujours pas comment réaliser cette interface avec l’extérieur.
 Le chapitre suivant, quant à lui, présente le diagramme des classes, qui permet de modéliser la
structure interne d’un système.
54

UML Cas2Dutilisation

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

UML Cas2Dutilisation

Transféré par

Droits d'auteur :

Formats disponibles

UML 2

 Les modèles se complètent et doivent être cohérents.

 Le client intervient constamment au cours du projet, notamment pour :

 Souvent, le client et les utilisateurs ne sont pas des informaticiens.

 Il leur faut donc un moyen simple d’exprimer leurs besoins.

 C’est précisément le rôle du diagrammes de cas d’utilisation.

 Il permet de recenser les grandes fonctionnalités d’un système.

 Un diagramme de cas d’utilisation est un diagramme de comportement qui permet

 C’est un des premiers diagrammes à écrire pour commencer l’analyse.

 Il est principalement utilisé pour :

 Un diagramme de cas d’utilisation comprend les entités suivantes :

Ces entités sont appelées acteurs.

 Un acteur est un utilisateur externe au système. Cela peut être :

 Du matériel (capteurs, moteurs, relais…).

 Le système permet de définir la frontière entre « l’interne » et « l’externe »

 Les acteurs sont extérieurs au système.

 Un DAB permet à tout détenteur de carte bancaire de retirer de l’argent.

 Si le détenteur de carte est un client de la banque propriétaire du DAB, il peut en plus

 Les transactions sont sécurisées c’est-à-dire :

 Le DAB nécessite des opérations de maintenance tel que la recharge de billets, la

 les différents acteurs interagissant avec le DAB :

 Un cas d’utilisation décrit une interaction entre un acteur et le système.

 Il représente l’objectif de l’utilisateur lorsqu’il utilise le système.

 Les cas d’utilisation sont intérieurs au système.

 On représente en UML un cas d’utilisation par une ellipse contenant en général

Guichet automatique Nom du sujet

Diagramme de cas d’utilisation modélisant un guichet automatique 14

 Il existe principalement deux types de relations :

1. les dépendances stéréotypées : “include”, “extend”.

> Boire une

Payer en liquide Payer par chèque Payer par carte

 La seule relation possible entre deux acteurs est la généralisation.

 Le préposé aux commandes ne peut pas gérer le stock.

 Les acteurs sont à l’extérieur du système et dialoguent avec lui.

 Les différents acteurs d’un système peuvent être :

 En général, les utilisateurs ne sont pas difficiles à trouver.

 En général, l’acteur principal initie le cas d’utilisation par ses sollicitations.

 Mauvais acteur secondaire

 Il n’y a pas de notion temporelle dans un diagramme de cas d’utilisation.

• décrit comment un acteur utilise le système pour parvenir à son but ;

 Le cas d’utilisation décrit comment le système et ses acteurs collaborent

• Enrichissez votre diagramme avec des cas d’utilisation

 Système informatique de la banque: gère les comptes des clients.

 Système d’autorisation (Sys. Auto.) :

 Système d’information (SI) banque :

Recharger le Opérateur de maintenance

• Attention, une personne peut jouer plusieurs rôles

Système de formation Emedia

 Ce n’est pas obligatoire, mais il est recommandé de rédiger une description

 Une description textuelle classique se compose de trois parties :

- Titre : Nom du cas d’utilisation

- Résumé : description du cas d’utilisation.

- Acteurs : descriptions des acteurs principaux et secondaires.

- Dates : Date de création et date de mise à jour.

 Partie 2 : Description des scénarios..

 Il y a plusieurs types de scénarios :

1. Le scénario nominal qui correspond à un déroulement normal d’un cas d’utilisation.

2. Les scénarios alternatifs qui sont des variantes du scénario normale.

 Partie 3 : Exigence non fonctionnelle.

 Prix maximum de la solution à développer

 Titre : Retirer de l’argent.

 Acteur principale : Un porteur de carte bancaire.

 Acteurs secondaires : Le Système d’Information de la banque et le Système d’Autorisation