Vous êtes sur la page 1sur 29

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

Vous aimerez peut-être aussi