Conception des systèmes
d’information
1
DIAGRAMME DE CAS
D’UTILISATION
RESPONSABLE DU COURS : HÉLA LIMAM
ANNÉE UNIVERSITAIRE : 2021 - 2022
Sommaire
2
Objectif du diagramme de cas d’utilisation
Définition du cas d’utilisation
Acteurs dans les cas d'utilisation
Cas d’utilisation, Scénario
Relations entre cas d’utilisation
Description des cas d’utilisation
Diagramme de cas d’utilisation
Etapes pour établir un diagramme
Utilité du diagramme de cas d’utilisation
Objectif du diagramme de cas d’utilisation
3
Bien identifier :
les besoins des utilisateurs
la manière dont sera utilisé le système
Bien comprendre :
qui sont les utilisateurs
les tâches qu’ils doivent réaliser
Décrire :
comment l’utilisateur interagit avec le système
pour accomplir les tâches qui lui sont fixées
Définitions du cas d’utilisation
4
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.
Constatations:
- Modélise : pas de détails (pas d’algorithme des interactions)
- les actions représentées par les CU sont automatisées et non
manuelles
Ils sont utilisables pour tout projet, indépendamment
d’UML et de l’approche objet.
Acteurs dans les cas d'utilisation
5
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>>
Acteurs dans les cas d'utilisation
6
Il existe 4 grandes catégories d'acteurs :
les acteurs principaux. Cette catégorie regroupe les personnes qui
utilisent les fonctions principales du système. Dans le cas d'un distributeur
de billets, il s'agit des clients.
les acteurs secondaires. Cette catégorie regroupe les personnes qui
effectuent des tâches administratives ou de maintenance. Dans le cas d'un
distributeur de billets, il s'agit de la personne qui recharge la caisse du
distributeur.
le matériel externe. Cette catégorie regroupe les dispositifs matériels
autres que les ordinateurs comme les périphériques. Dans le cas d'un
distributeur de billets, il s'agit de l'imprimante, du lecteur de carte, de la
trieuse de billets.
les autres systèmes. Cette catégorie regroupe les systèmes avec
lesquels le système interagit. Dans le cas d'un distributeur de billets, il
s'agit du groupement bancaire qui gère l'ordinateur central qui relie tous
les distributeurs.
Acteurs dans les cas d'utilisation
7
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
Cas d’utilisation, Scénario
8
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.
Cas d’utilisation, Scénario
9
exemple :
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
Relations entre cas d’utilisation
10
Extension :
spécifier des interactions optionnelles entre 2 cas
tenant compte de cas exceptionnels
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.
Note : le
< < é te n d > > comportement
[c o n d it io n d ' exte n s i o n ] du CU1 s’il existe
étend le
C a s U ti li s a ti o n 1 C a s U ti l i s a ti o n 2 comportement
du CU2
exemple :
Relations entre cas d’utilisation
11
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 <<extend>>
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
La relation d’extension
12
Extension (suite):
24/09/2021
Relations entre cas d’utilisation
13
Inclusion :
l’instance du CU source contient aussi le comportement décrit par le
CU destination.
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.
Note : le
< < i n c l u t> > comportement du
CU1 nécessite le
C a s U ti l i s a ti o n 1 C a s U ti l i s a ti o n 2
comportement du
CU2
exemple :
Relations entre cas d’utilisation
14
Généralisation / Spécialisation :
rassembler des actions communes en « super-cas »
décrire des variantes d’un cas général (« sous-cas »)
notion d’héritage
Le cas d’utilisation Fils est une spécialisation du cas d’utilisation Parent
CasUtilisationParent
CasUtilsationEnfant
exemple :
Exemple 1
15
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.
Exemple 2
16
Dans un établissement scolaire, on désire gérer la réservation des salles
de cours ainsi que du matériel pédagogique (ordinateur portable ou/et
Vidéo projecteur). Seuls les enseignants sont habilités à effectuer des
réservations (sous réserve de disponibilité de la salle ou du matériel).
Le planning des salles peut quant à lui être consulté par tout le monde
(enseignants et étudiants).
Par contre, le récapitulatif horaire par enseignant (calculé à partir du
planning des salles) ne peut être consulté que par les enseignants.
Enfin, il existe pour chaque formation un enseignant responsable qui
seul peut éditer le récapitulatif horaire pour l’ensemble de la
formation.
Description des cas d’utilisation
17
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.
Description des cas d’utilisation
18
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 :
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
1.
2.
…
Enchaînements alternatifs :
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.
Alt1…
Alt2…
Scénario 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.
E1 :
E2 :
….
Post-condition
Description des cas d’utilisation
19
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
Diagramme de cas d’utilisation
20
diagramme de cas d’utilisation :
un ensemble de cas d’utilisation, liés aux acteurs impliqués
des relations entre cas d’utilisation (inter-dépendances)
une description des cas d’utilisation (textuelle, scénarios)
Etapes pour établir un diagramme
21
définir les bornes du système
identifier les acteurs et les cas d’utilisation
définir les relations entre les cas d’utilisation
valider le diagramme avec les utilisateurs
Utilité du diagramme de cas d’utilisation
22
Utile quand les utilisateurs sont amenés à intervenir :
expression des besoins
Décrire l’existant, découvrir les besoins
Guider le recueil d’information (interviews, …)
modélisation du futur système
Décrire concrètement les différents processus du système
D’autres diagrammes complèteront cette description
tests et validation
Mise en avant de la logique utilisateur
Structuration des tests, validation
mise en œuvre
Vue « utilisateur » des actions du système
Structurer les manuels d’utilisation
Résumé
23
identifier, comprendre, représenter :
manières d’utiliser un système
périmètre, acteurs impliqués
notions : cas d’utilisation, acteur
liens entre cas d’utilisation : extension, inclusion, héritage
description de cas d’utilisation :
nature, acteurs impliqués, actions
règles de gestion, documents utilisés et produits
intervient en phase amont :
définir et valider les exigence
définir des scénarios de tests
structurer les manuels d’utilisation
Conclusion
24
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, …
Exemple 2 complet
25
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.
COMPLÉTEZ LES DESCRIPTIONS TEXTUELLES AVEC DES DIAGRAMMES
DYNAMIQUES SIMPLES !
26
Pour documenter les cas d’utilisation, la description textuelle est indispensable,
car elle seule permet de communiquer facilement et précisément avec les
utilisateurs.
La description textuelle est également l’occasion de s’entendre sur la
terminologie employée, ainsi que d’identifier le contexte d’exécution de l’un ou
de l’autre des enchaînements. En revanche, le texte présente des désavantages
puisqu’il est difficile de montrer comment les enchaînements se succèdent ; en
outre la maintenance des évolutions s’avère souvent périlleuse.
Il est donc recommandé de compléter la description textuelle par un ou plusieurs
diagrammes dynamiques, qui apporteront un niveau supérieur de formalisation.
À vous de décider en fonction de votre contexte si vous montrez
ces diagrammes au futur utilisateur, ou si vous les utilisez uniquement
comme support d’analyse pour lui poser des questions supplémentaires, et
ainsi mieux valider votre texte.
COMPLÉTEZ LES DESCRIPTIONS TEXTUELLES AVEC DES DIAGRAMMES
DYNAMIQUES SIMPLES !
27
COMPLÉTEZ LES DESCRIPTIONS TEXTUELLES AVEC DES DIAGRAMMES
DYNAMIQUES SIMPLES !
28
Exemple de description d’un cas d’utilisation : Description via
des diagrammes de séquences
Diagrammes de
séquences "systèmes"
Méthodologie de
conception UML
29
DIAGRAMME DE SÉQUENCE
