Leçon n° 1 : Diagramme de cas d’utilisation
Introduction
La modélisation des besoins d’un système implique de définir ce qu’il doit faire, d’un point de vue externe au système, sans avoir à préciser comment. Dans ce cas, on élabore le diagramme de cas d’utilisation pour spécifier le comportement attendu du système. Ainsi, un diagramme de cas d’utilisation permet de visualiser le système entier comme une boite noire, permettant de voir ce qui se passe à l’extérieur du système ainsi que la façon dont le système réagit par rapport aux éléments externes. Le diagramme de cas d'utilisation permet de décrire l'interaction entre le système et un acteur (utilisateur du système). C'est un moyen de recueillir et de décrire les besoins des acteurs du système.
I. Formalisme
La figure n°1, ci-dessous, illustre un diagramme de cas d’utilisation d’un système de distribution de billets automatique. Le système à modéliser apparait dans un cadre, les utilisateurs sont représentés par des petits bonshommes et les grandes fonctionnalités (les cas d’utilisation) par des ellipses. L’ensemble des cas d’utilisation contenus dans le cadre constitue le système. Les petits bonhommes sont appelés des acteurs. Ils sont connectés au système par des simples traits appelés associations aux cas d’utilisation et mettant en évidence les interactions possibles entre le système et le monde extérieur. Chaque cas d’utilisation modélise une façon particulière et cohérente d’utiliser un système pour un acteur donné.
Figure n°1 : Diagramme de cas d’utilisation modélisant un système DAB I.1 Le système
Le système constitue le domaine d’étude, il est entouré par un cadre à fin de séparer le système à modéliser du domaine extérieur.
System
Client
Retirer argent
Exemples de système :
Système de gestion d’octroi des crédits
Système de gestion d’un parc informatique, etc.
I.2 Acteur
I.2.1 Définition
Un acteur est un utilisateur du système. Il représente un ensemble cohérent de rôles joués par les utilisateurs vis-à-vis du système. Un acteur communique et interagit avec les cas d'utilisation du système en échangeant des messages. Un acteur représente un rôle qu’un homme, une machine ou un même un autre système joue avec le système. Exemple : Une personne qui travaille pour une banque sera le Gestionnaire de Prêts. Si elle a son compte dans la même banque, elle jouera aussi le rôle du Client.
Figure n°2 : Notation d’un acteur dans un diagramme de cas d’utilisation
Remarques :
R1) Il ne faut pas confondre un acteur et une personne utilisant le système, en effet :
Une même personne peut jouer plusieurs rôles par rapport au système étudié et être modélisée par plusieurs acteurs. Par exemple, une personne qui travaille pour une banque aura le rôle Gestionnaire de prêts. Si elle a un compte dans la même banque, elle jouera aussi le rôle du Client.
Plusieurs personnes peuvent jouer un même rôle. Elles seront alors modélisées par le même acteur.
Un acteur n’est pas forcément une personne physique.
R2) Chaque acteur du système doit être nommé, Pour lui attribuer un nom, il faut
penser à son rôle vis-à-vis d’un système. Ainsi, pour un logiciel de gestion de paie le nom correct de l’acteur est Comptable plutôt que Mr X. Le nom d’un acteur peut être accompagné d’une brève description textuelle.
System
Rôle de l'acteur
Figure n°3 : Commentaire décrivant le rôle de l’acteur « Guichetier » dans le système
bancaire
I.2.2 Types d’acteurs
En plus des utilisateurs humains qui utilisent le système à travers une interface graphique, les acteurs peuvent être :
Des logiciels : Ce sont des logiciels externes au système et qui communiquent avec lui. Par exemple le Système de carte visa dans le cas d’un système de vente en ligne
Des matériels : Ce sont les périphériques manipulés par le système. Par exemple des robots ou des automates qui envoie des données au système ou qui est piloté par le système.
I.3 Cas d’utilisation (use case) I.3.1 Définition
Un Cas d’utilisation :
Est une représentation d’une fonctionnalité (ensemble des actions) réalisées par le système en réponse à une action d’un acteur.
Constitue une description du comportement (actions +réactions) du système du point de vue de son utilisateur.
Est une suite d’interactions entre un acteur et le système. Permet d’atteindre un objectif aux yeux de l’utilisateur. Doit être utile.
Le cas d'utilisation est connecté à un acteur à travers une association représentée par une ligne continue :
Remarque :
Un cas d’utilisation est caractérisé par :
Un nom : Utiliser un verbe à l’infinitif (Ex : Réceptionner un colis)
Des acteurs principaux : Ce sont les utilisateurs qui utilisent les fonctionnalités principales du système à travers l’interface graphique du système.
Des acteurs secondaires : qui regroupent les personnes qui exécutent les tâches administration ou de maintenance.
I.3.2 Cas d’utilisation et scénarios
Un cas d’utilisation est 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. Un scénario est une séquence spécifique d’actions qui illustre le comportement. Les scénarios sont aux cas d’utilisation ce que les objets sont aux classes : ils sont en fait des instances des cas d’utilisation. Le diagramme de cas d’utilisation décrit les grandes fonctionnalités d’un système du point de vue des acteurs, mais n’expose pas de façon détaillée le dialogue entre les acteurs et les cas d’utilisation. On distingue trois types de scénarios :
Un scénario nominal : celui qui satisfait les objectifs des acteurs par le chemin le plus direct de succès.
Un scénario alternatif : Il diverge du scénario nominal. C’est un embranchement
dans un scénario nominal mais y revient toujours et il possède une fin normal. Un scénario d’exception : Il intervient quand une erreur se produit. le scénario
nominal s’interrompt, sans retour au scénario nominal. Il s’agit d’un échec.
Figure n°5 : Illustration graphique des scénarios d’un cas d’utilisation
Chaque scénario est composé d’étapes qui peuvent être de trois sortes : un message d’un acteur vers le système,
une validation ou un changement d’état du système, un message du système vers un acteur.
Les étapes sont numérotées séquentiellement afin de pouvoir facilement indiquer par la suite les alternatives possibles
Exemple de scénarios nominal :
Cas d’utilisation : Retirer de l’argent au distributeur (DAB) avec une carte
bancaire.
1. Le client introduit sa carte dans le DAB.
2. Le DAB vérifie que la carte introduite est bien une carte bancaire. 3. Le DAB demande au client de fournir son code d’identification. 4. Le client entre son code d’identification.
5. Le DAB valide le code d’identification.
6. Le DAB demande une autorisation au système d’autorisation externe. 7. Le système d’autorisation externe donne son accord et indique le solde hebdomadaire.
8. Le DAB demande au client de saisir le montant désiré du retrait. 9. Le client saisit son montant de retrait.
10. Le système vérifie que le montant de retrait est autorisé. 11. Le système délivre au client l’argent et la carte bancaire.
Exemple de scénarios d’alternatif :
5a. Le DAB détecte que le code saisi est erroné, pour la première ou deuxième fois. 1. Le DAB indique au client que le code est erroné.
2. Le DAB enregistre l’échec de l’opération et le cas d’utilisation reprend à l’étape 4 du scénario nominal.
Exemple de scénarios d’exception :
2a. La carte introduite n’est pas reconnue par le DAB.
1. Le DAB éjecte la carte et le cas d’utilisation se termine en échec. 5b. Le DAB détecte que le code saisi est erroné, pour la troisième fois.
1. Le DAB indique au client que le code est erroné pour la troisième fois. 2. Le DAB confisque la carte.
3. Le DAB informe le système d’autorisation externe et le cas d’utilisation se ter mine en échec.
I.4 Organisation des 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 permettant d’organiser les cas d’utilisations :
Les dépendances stéréotypées : sont des dépendances dont la portée est explicitée par le nom du stéréotype. Les stéréotypes les plus utilisés sont l’inclusion : <<include>> et l’extension <<extend>>.
La généralisation.
I.4.1 Relation d’inclusion
Un cas A est inclus dans un cas B, illustré par le stéréotype <<include>>, si le comportement décrit par le cas A est inclus dans le comportement du cas B : on dit alors que le cas B
dépend de A.
Figure n°6 : Formalisme de la relation d’inclusion entre cas d’utilisation
Les liens d’utilisation permettent de :
Factoriser les cas d’utilisation qui peuvent servir pour d’autres cas d’utilisation, en faisant l’extraction d’une séquence d’interactions communes présentes dans le scénario de plusieurs cas d’utilisation.
Exemple :
Figure n°7 : Relation de dépendance « include » entre cas d’utilisation pour Factoriser les
cas d’utilisation
Exemple :
Figure n°8 : Relation de dépendance « include » entre cas d’utilisation pour décomposer
un cas complexe Remarques :
R1) Le cas d’utilisation inclus n’est jamais tout seul, il fait toujours partie d’un cas
d’utilisation qui l’englobe.
R2) L’inclusion peut être assimilée au cas d’utilisation principal qui tire un comportement du
cas d’utilisation fournisseur.
I.4.2 Relation d’extension
Si le comportement d’un cas d’utilisation B peut être étendu par le comportement du cas d’utilisation A, on dit alors que le cas d’utilisation A étend le cas d’’utilisation B. Une extension est souvent soumise à condition. Le cas d'utilisation B peut exister tout seul, il peut aussi être complété par le cas d’utilisation A, sous certaines conditions.
L'extension est utilisée pour modéliser la partie d'un cas d'utilisation considérée comme facultative dans le comportement du système. Elle permet de séparer le comportement obligatoire du comportement optionnel.
Figure n°9 : Formalisme de la relation d’extension entre cas d’utilisation
Exemples :
I.4.3 Relation de généralisation
Un cas d’utilisation A est une généralisation d’un cas d’utilisation B si le cas d’utilisation B est un cas particulier de A. Cette relation consiste à dire que l’on a un cas d’utilisation dit « de base » (le cas d’utilisation A), générique, qui décrit des séquences d’évènements et d’autres cas d’utilisation (Cas s’utilisation B) qui héritent de ce comportement de base et le spécialise suivant différents critères. La 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.
Figure n°11 : Formalisme de la relation de généralisation entre cas d’utilisation
Figure n°12 : Exemples de relation de généralisation entre cas d’utilisation
I.5 Relation de généralisation 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 (tous les cas d’utilisation accessibles à A le sont aussi à B, mais l’inverse n’est pas vrai,
Figure n°13 : Exemples de relation de généralisation entre acteurs
System Traiter règlement Traiter règlement par chèque Comptable Traiter règlement en espèces
II. Description textuelle des cas d’utilisation
Bien que de nombreux diagrammes d’UML permettent de décrire un cas d’utilisation (diagramme de séquence, diagramme de collaboration), il est recommandé de rédiger une description textuelle car c’est une forme souple qui convient dans bien des situations. Une description textuelle, couramment utilisée, se compose deux parties : sommaire d’identification et d’une description de scénarii, à savoir :
1- Sommaire d’identification : contient les informations suivantes :
• le nom du cas d’utilisation ; • un résumé de son objectif ;
• les acteurs impliqués (principaux et secondaires) ;
• les dates de création et de mise à jour de la description courante ; • le nom des responsables ;
• un numéro de version.
2- Description des scénarii : Elle contient toujours un scénario nominal qui
correspond au fonctionnement nominal du cas d’utilisation (par exemple, un
retrait d’argent qui se termine par l’obtention des billets demandés par
l’utilisateur). Ce scénario nominal commence par préciser l’événement qui
déclenche le cas (l’utilisateur introduit sa carte bancaire par exemple) et se développe en trois points :a. Les pré-conditions. Elles indiquent dans quel état est le système avant que se déroule la séquence (le distributeur est alimenté en billets par
exemple).
b. Les scénarii :
i. Le scénario nominal, ii. le scénario alternatif, iii. le scénario d’exceptions.
c. Les post-conditions. Elles indiquent dans quel état se trouve le système après le déroulement de la séquence nominale (une transaction a été
enregistrée par la banque par exemple).
Remarques :
R1) Parfois la séquence correspondant à un cas d’utilisation a besoin d’être appelée
dans une autre séquence (par exemple quand une relation d’inclusion existe entre deux cas d’utilisation). Signifier l’appel d’une autre séquence se fait de la façon suivante : « appel du cas X », où X est le nom du cas.
R2) Les acteurs n’étant pas sous le contrôle du système, ils peuvent avoir des
comportements imprévisibles. La séquence nominale ne suffit donc pas pour décrire tous les comportements possibles. À un scénario nominal, s’ajoutent fréquemment des scénarii alternatifs et des scénarios d’exceptions, qui se décrivent de la même façon.
III. Les étapes d’élaboration d’un diagramme de cas d’utilisation
1. Définir les bornes du système.
2. Identifier les acteurs et les cas d'utilisation :
Qui utilisera les fonctionnalités principales du système ?
Qui a besoin du support du système pour effectuer ses tâches quotidiennes ?
Qui doit mettre à jour, administrer et veiller au fonctionnement du système ?
Quels systèmes de matériel le système logiciel doit- il manipuler ?
Avec quels autres systèmes le système interagit-il ?
Qui a un intérêt pour les résultats produits ?
3. Définir les relations entre les cas d'utilisation. 4. Valider et vérifier le modèle.
QCM Diagramme de cas d’utilisation
A une question correspond une seule réponse juste. Indiquer la lettre de la bonne réponse.
1- Les cas d’utilisation correspondent à un ensemble d’interactions entre un utilisateur et le système.
A) Vrai B) Faux
2- Un cas d’utilisation prend en compte les objectifs non fonctionnels d’un utilisateur.
A) Vrai B) Faux
3- Dans un cas d’utilisation, un acteur représente un utilisateur jouant un rôle précis dans l’utilisation du système.
A) Vrai B) Faux
4- Pour les acteurs primaires, l’objectif du cas d’utilisation est essentiel.
A) Vrai B) Faux
5- Pour les acteurs secondaires, l’objectif du cas d’utilisation est également essentiel.
A) Vrai B) Faux
6- Un acteur est une personne interne au système.
A) Vrai B) Faux
7- Un acteur est obligatoirement une personne physique.
A) Vrai B) Faux
8- La relation de communication lie un acteur au système.
A) Vrai B) Faux
9- Tous les cas d’utilisation ont une relation de communication directe avec un acteur.
A) Vrai B) Faux
10- La relation de généralisation/spécialisation est une relation liant deux cas d’utilisation.
A) Vrai B) Faux
Corrigé QCM Diagramme de cas d’utilisation
A une question correspond une seule réponse juste. Indiquer la lettre de la bonne réponse.
1- Les cas d’utilisation correspondent à un ensemble d’interactions entre un utilisateur et le système.
A) Vrai B) Faux
2- Un cas d’utilisation prend en compte les objectifs non fonctionnels d’un utilisateur.
A) Vrai
B) Faux
3- Dans un cas d’utilisation, un acteur représente un utilisateur jouant un rôle précis dans l’utilisation du système.
A) Vrai B) Faux
4- Pour les acteurs primaires, l’objectif du cas d’utilisation est essentiel.
A) Vrai B) Faux
5- Pour les acteurs secondaires, l’objectif du cas d’utilisation est également essentiel.
A) Vrai B) Faux
6- Un acteur est une personne interne au système.
A) Vrai B) Faux
7- Un acteur est obligatoirement une personne physique.
A) Vrai B) Faux
8- La relation de communication lie un acteur au système.
A) Vrai B) Faux
9- Tous les cas d’utilisation ont une relation de communication directe avec un acteur.
A) Vrai B) Faux
10- La relation de généralisation/spécialisation est une relation liant deux cas d’utilisation.
A) Vrai B) Faux
Exercice d’application
SYSTEME LOGICIEL D’UNE CAISSE ENREGISTREUSE
Il s’agit d’un système simplifié de caisse enregistreuse de supermarché. Le
déroulement normal d’utilisation de la caisse est le suivant :
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 supérieure à un.
La caisse affiche le prix de chaque article et son libellé.
Lorsque tous les achats sont enregistrés, le caissier signale la fin de la
vente.
La caisse affiche le total des achats.
Le client choisit son mode de paiement :
Liquide : le caissier encaisse l’argent reçu, la caisse indique la
monnaie à 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. Il
transmet une demande d’autorisation à un centre d’autorisation
en fonction de type de la carte.
La caisse enregistre la vente et imprime un ticket.
Le caissier donne le ticket de caisse au client.
Après la saisie des articles, le client peut présenter au caissier des coupons
de réductions pour certains articles. Lorsque le paiement est terminé, la
caisse transmet les informations sur le nombre d’articles vendus au
système de gestion de stocks.
Tous les matins, le responsable du magasin initialise les caisses pour la
journée.
Questions :
1- Élaborer le diagramme de cas d’utilisation du système de la caisse
enregistreuse en suivant la démarche suivante :
a. Identifier les acteurs.
b. Identifier les objectifs de chaque acteur.
c. Représenter les cas d'utilisation.
d. Représenter les associations entre acteurs et cas d’utilisation
e. Élaborer une structuration des cas d’utilisation, si elle
existe.
2- Élaborer une description textuelle du cas d’utilisation « Traiter passage
en caisse »
Proposition de Corrigé
Système logiciel d’une caisse enregistreuse
Le diagramme de cas d’utilisation du système de la caisse enregistreuse.
Diagramme de cas d’utilisation du système de la caisse enregistreuse
2-
Description textuelle du cas d’utilisation « Traiter le passage en caisse » Sommaire d’identification
Titre : « Traiter le passage en caisse »
But : détailler les étapes permettant au caissier d’enregistrer les achats d’un client et
récupérer le paiement.
Acteur principal : Caissier Acteur secondaire : Client
Date de création : 20/04/2017 Date de mise à jour : 27/04/2017
Version : 1
Le cas d’utilisation commence quand un client arrive à la caisse avec des articles qu’il souhaite acheter.
Préconditions
- La caisse est ouverte (en service) ; un caissier y et connecté.
Scénario nominal
1. Le caissier enregistre chaque article. S’il ya a plus d’un exemplaire par article, le caissier indique également la quantité. Puis il appuie sur le bouton de validation.
2. La caisse détermine le prix de l’article et ajoute les informations sur l’article à la vente en cours. La caisse affiche la description et le prix de l’article en question.
3. Après avoir enregistré tous les articles, le caissier indique que la vente est terminée.
4. La caisse calcule et affiche le montant total de la vente.
5. Selon le mode de paiement du client :
a. En cas de paiement en espèce, exécuter le cas d’utilisation « Traiter le
paiement en liquide » ;
b. En cas de paiement par carte de crédit, exécuter le cas d’utilisation « Traiter le
paiement par carte de crédit» ;
c. En cas de paiement par chèque, exécuter le cas d’utilisation « Traiter le
paiement par chèque » ;
6. La caisse enregistre la vente qui vient d’être effectué et imprime un ticket.
Scénario alternatif
A1 : Le numéro d’identification est inconnu
L’enchaînement A1 démarre au point 2 du scénario nominal.
2. La caisse indique au caissier que le numéro d’identification de l’article est inconnu.
L’article ne peut pas être pris en compte dans la vente en cours. Le scénario nominal reprend au point 1.
Scénario d’exception
E1 : Le client ne peut pas payer
L’enchaînement E1 démarre au point 5 du scénario nominal.
5. Le client ne peut pas payer le total avec aucun moyen de paiement autorisé. 6. Le caissier annule l’ensemble de la vente et le cas d’utilisation est terminé.
