III.

Diagrammes des cas d’utilisation

 Modélisation des besoins

Avant de développer un système, il faut savoir

précisément à QUOI il devra servir, c.à.d. à quels
besoins il devra répondre.

Avec UML, on modélise les besoins au moyen de diagrammes de

cas d'utilisation
 Origine

 Formalisés par Ivar Jacobson : Object-Oriented Software Engineering

(Addison-Wesley, 1992)
 Décrivent le comportement du système (actions et de réactions), selon le
point de vue de l’utilisateur
 Chaque cas d’utilisation décrit le comportement du système suite à une
stimulation externe
 Modèle

Acteurs + Cas d’utilisation + Relations

 Objectifs

 Modélisation du système du point de vue des utilisateurs.

 Faire l'inventaire des fonctionnalités offertes par le système et ses limites

 Organisation des besoins entre eux, de manière à faire apparaître des
relations.

 Notation très simple et compréhensible par tous, elle permet donc la

communication avec l'utilisateur.
 Acteurs

 Un acteur est une entité externe qui interagit avec le système (fournir, recevoir,
échanger de l’information)

« acteur »
Nom de l’acteur

 On trouve les acteurs en observant les utilisateurs directs du système ainsi que
les autres systèmes qui interagissent avec le système
 Acteurs – Les utilisateurs-

 Un acteur représente un rôle joué par un utilisateur qui interagit avec le

système
 La même personne physique peut jouer le rôle de plusieurs acteurs (vendeur,
client)
 Plusieurs personnes peuvent également jouer le même rôle, et donc agir
comme le même acteur (tous les clients)
 Un acteur correspond à un rôle, pas à une personne physique.
 Cas d’utilisation

 Notation

Nom du cas d’utilisation

 Les cas d’utilisations représentent le dialogue entre l’acteur et le système de

manière abstraite
 Permet à un acteur d'atteindre un but (c'est une manière d'utiliser le système).
 Ensemble de scénarios au sein d’une description unique
 Les cas d’utilisations doivent être vus comme des classes de scénarios

Un cas d'utilisation est l'expression d'un service rendu par le système, réalisé de
bout en bout (sans interruption), avec un déclenchement, un déroulement et une
fin, pour l'acteur qui l'initie
 Système

Notation

 Permet de préciser les limites du système étudié.

 Modélisé par un ensemble de cas d'utilisation.
 Ne contient pas d’acteurs.

Remarque
 A un niveau d’abstraction plus élevé, UML permet de représenter tous les cas d’utilisation d’un
système par un simple rectangle. Ce rectangle est appelé classeur.
Exemple :
Borne interactive d’une banque
 Quelques notions de modélisation

Classeur
Un classeur est un élément de modèle qui décrit une unité comportementale ou
structurelle.

Un classeur modélise un concept discret doté :

 d’une identité (i.e. un nom) ;
 d’un état (i.e. des attributs) ;
 d’un comportement (i.e. des opérations) ;
 une structure interne facultative.

Exemple : acteurs, cas d’utilisation, classes, etc.

 Quelques notions de modélisation

Paquetage
 Un paquetage permet d’organiser des éléments de modélisation en groupes.
 Un paquetage peut contenir tout type d’élément de modèle : des classes, des cas
d’utilisation, des interfaces, etc.
Remarques
 UML permet de regrouper des cas d’utilisation en paquetage. Le regroupement se fait par
acteur ou par domaine fonctionnel.
 Un diagramme de cas d’utilisation peut contenir plusieurs paquetages et des paquetages
peuvent être inclus dans d’autres paquetages.
 Quelques notions de modélisation

Espace de noms
Les espaces de noms sont des paquetages, des classeurs, etc.

 Peuvent être imbriqués les uns dans les autres.

 Pour accéder au contenu sans ambiguïté, on utilise des noms qualifiés.
 Par exemple, si un paquetage B est inclus dans un paquetage A et contient une classe X,
le nom qualifié de X est A :: B :: X
 Détermination des Cas d’utilisation

 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 de changements externes?
 Le système devra-t-il informer l’acteur de conditions internes au système
 Il faut éviter les redondances et limiter le nombre de cas en se situant au bon
niveau d'abstraction (par exemple, ne pas réduire un cas à une seule action).
 Il ne faut pas faire apparaître les détails des cas d'utilisation, mais il faut rester
au niveau des grandes fonctions du système.
 Exemple de Cas d’utilisation

Frontière du sujet Borne interactive d’une banque Nom du sujet

Acteur

Retirer argent cas d'utilisation

Effectuer un virement
Client

Consulter compte
Association
 Relations entre cas d'utilisation et acteurs

 Relie un acteur à un cas d'utilisation montrant que l'acteur participe au cas

d'utilisation
 Point de vue besoin : représente la possibilité d'atteindre un but.
 Point de vue système : représente un échange de messages (communication).
 Un acteur peut utiliser plusieurs fois le même cas d'utilisation.

association Cas d’utilisation

acteur
 Relations entre cas d'utilisation et acteurs

 Acteur primaire « primary » : acteur déclenchant le cas

 Acteur secondaire « secondary » : acteur sollicité par le cas
 Relations entre cas d'utilisation et acteurs

Il est possible d'ajouter une multiplicité sur l'association du coté du cas

d'utilisation
 Nombre de fois qu'un acteur peut interagir avec un cas d'utilisation.
 * : une infinité de fois
 n : exactement n fois
 n..m : entre n et m fois

 Une multiplicité n'implique pas nécessairement que les cas sont utilisés en
même temps.
 Relations entre cas d'utilisation

 Include

Le comportement de B est obligatoire pour réaliser le comportement de A

La relation d’inclusion permet de :

 Factoriser une partie commune à plusieurs cas d’utilisation.

 Décomposer un cas complexe en sous cas plus simples.
 Relations entre cas d'utilisation

 Exemple

Borne interactive d’une banque

Retirer argent « Inclut »

« Inclut »
Effectuer un virement S’authentifier
Client
« Inclut »
Consulter compte
 Relations entre cas d'utilisation

 Extend :
Le comportement de B est optionnel et ne se déclenche que par une condition
dans le comportement de A
 Relations entre cas d'utilisation

 Exemple

Borne interactive d’une banque

Retirer argent
« Inclut »
Effectuer un virement
Point d’extension :
vérificationSolde {après
avoir demandé le montant}
« Inclut »
« étend »
S’authentifier
Client Vérifier le solde

« Inclut »
Condition: {Si montant>200} Consulter compte
Points d’extension: vérificationSolde
 Relations entre cas d'utilisation

Exemple inclusion / extension

 « Faire quelque chose » inclut « Faire ceci aussi »;
 « Faire ceci aussi » est obligatoirement exécuté pendant le déroulement du
cas « Faire quelque chose »
 « Faire ceci aussi » étend « Faire autre chose »;
 « Faire ceci aussi » peut être exécuté pendant le déroulement du cas « Faire
autre chose »
 Relations entre cas d'utilisation

Dépendances d’inclusion et d’extension

Les inclusions et les extensions sont représentées par des dépendances :

 Lorsqu'un cas « B » inclut un cas « A » : « B » dépend de « A ».
 Lorsqu'un cas « B » étend un cas « A » : « B » dépend aussi de « A ».
 On note toujours la dépendance par une flèche pointillée.
 Lorsqu'un cas « B » dépend d'un cas « A », toute modification de « A » sera
susceptible d'avoir un impact sur « B ».
 Relations entre cas d'utilisation

Réutilisabilité avec les inclusions et les extensions

Exemple
 Les relations entre les cas d'utilisation permettent la réutilisabilité du cas
« s'authentifier »  il sera inutile de développer plusieurs fois un module
d'authentification.
 Relations entre cas d'utilisation

Décomposition grâce aux inclusions et aux extensions

 Quand un cas est trop complexe (faisant intervenir un trop grand nombre
d'actions), on peut procéder à sa décomposition en cas plus simples.
 Relations entre cas d'utilisation

Généralisation
Le cas A est une généralisation du cas B (flèche allant de « B » à « A »)

 Un cas d'utilisation « A » est une généralisation d'un cas « B » si « B » est un
cas particulier de « A ».
 « A » peut être remplacé par « B » pour un cas précis.
 Cette relation est présente dans la plupart des diagrammes UML et se traduit
par le concept d'héritage dans les langages orientés objet.

Ne l'utiliser que si ça peut apporter de la lisibilité à la

spécification.
 Relations entre cas d'utilisation

 Exemple

Un virement est un cas particulier (une

sorte) de paiement
 Relations entre acteurs

 Communications externes non modélisées.

 Une seule relation possible : la généralisation
 Mise en œuvre des cas d’utilisations

 Identifier la plupart des cas d’utilisations (<20).

 Décrire brièvement chaque cas d’utilisation (2 à 3 phrases)
 Décrire en détails chaque cas d’utilisation
 Debut
 Fin
 Interaction entre acteur et le cas d’utilisation
 Chronologie
 Echange d’informations
 Exercice 1

Système « Distributeur automatique de billets »

On cherche à modéliser un distributeur automatique de billets (DAB). Ce

distributeur sera utilisé par des clients qui veulent pouvoir choisir une opération
parmi le retrait d’argent (rapide ou normal) et la consultation du solde de leur
compte.
Pour chaque opération, il faudra s’identifier.
 Le distributeur devra permettre d’éditer des tickets pour chaque opération si
l’utilisateur le souhaite.
 Un système d’autorisation permettra de vérifier le solde des comptes dans le
cas d’un retrait important.

Réaliser le diagramme de cas d’utilisation qui décrit le système à

produire.
 Exercice 1

Système « Distributeur automatique de billets »

 Exercice 2

Système « Gestion d’un établissement scolaire »

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

Réaliser le diagramme de cas d’utilisation qui décrit le système à

produire.
 Exercice 2

Système « Gestion d’un établissement scolaire »

 Exercices: cas d’utilisation

SIA

 Identifier tous les acteurs de l’application SIA

 Identifier tous les cas d’utilisation de l’application SIA
 Donner le diagramme des cas d’utilisation de l’application SIA
 Exercice 3

Système d’Inscription Automatique

Au début de chaque session, les étudiants demandent un catalogue

contenant une liste des cours disponibles durant la session. Pour aider les
étudiants dans leurs choix, des informations sur chaque cours sont fournies
(enseignant, département, pré-requis, etc.). Le système permettra aux
étudiants de choisir 4 cours dans une session. En plus, chaque étudiant
choisira deux cours optionnels en cas d’annulation ou de saturation d’un
cours parmi les 4 précédemment choisis. Le nombre d’étudiants dans un
cours est entre 3 et 10. Un cours contenant moins de 3 étudiants est annulé.
Le processus d’inscription d’un étudiant est validé, le système envoie les
informations au système de paiement. L’étudiant peut donc payer ses frais de
scolarité. Un enseignant peut indiquer les cours qu’il veut assurer, consulter la
liste des étudiants inscris dans un cours donné.