UML :Diagramme de cas d'utilisation (cours)
Dernière mise à jour : 12 août 2021
Conception Orientée Objet avec UML
Diagramme de cas d’utilisation
Modélisation des besoins
Le diagramme de cas d’utilisation
Les éléments de modélisation
Les relations entre les éléments de modélisation
Description des cas d’utilisation
Avant de développer un système, il faut savoir précisément à quoi il devra servir
c'est a dire à quels besoins il devra répondre.
exemple d'un diagramme de cas d'utilisation :
prenons un exemple : système de vente en ligne
concepts de base : Acteur
Un acteur est une entité extérieure au système modélisé, et qui interagit directement avec lui.
Tout acteur doit communiquer avec le système.
Exemple d'acteurs
Des systèmes informatiques externes au système mais qui interagissent avec lui.
Des périphériques manipulés par le système (imprimantes,..).
Des utilisateurs (client, directeur, étudiant, administrateur,…).
Les concepts de base : Cas d’utilisation
Un cas d'utilisation est une description des besoins fonctionnels d'un système informatique.
C’est une représentation d’un ensemble de comportements fournis par un système àun ou des acteurs.
concepts de base : Paquetage
Permet de regrouper des cas d'utilisation.
Pratique si de nombreux cas sont identifiés.
Les relations entre les éléments de modélisation
1- «Cas d’utilisation»<->«Acteur»
-> Associations
2- «Cas d’utilisation»<->«cas d’utilisation»
a)Inclusion
b)Extension
c)Généralisation/spécialisation
3- «Acteur»<->«Acteur»
-> Généralisation
Association :
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)
Les relations entre cas d’utilisation et acteurs
Acteurs primaires et secondaires :
Acteur primaire « primary » : acteur déclenchant le cas
Acteur secondaire « secondary » : acteur sollicité par le cas
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
Les relations entre les éléments de modélisation
1. « Cas d’utilisation » <-> « Acteur » Associations
2. « Cas d’utilisation » <-> « cas d’utilisation »
a) Inclusion
b) Extension
c) Généralisation / spécialisation
3. « Acteur » <-> « Acteur » Généralisation
Les relations entre cas d’utilisation
a) Inclusion (stéréotype « include » ) :
le cas « A » inclut le cas « B » (flèche allant de « A » à « B »)
=> B est une partie obligatoire de A
Signifie qu'un cas d'utilisation « B » utilise intégralement la fonctionnalité du cas d'utilisation le plus général « A », en plus de lui ajouter des fonctionnalités additionnelles.
Si « A » inclut « B » alors « B » sera toujours inclus dans « A » et ne sera jamais exécuté de manière autonome.
Inclusion (stéréotype « include » ) :
Extension (stéréotype « extend » ) :
le cas « B » étend le cas « A » (flèche allant de « B » à « A »)
=> B est une partie optionnelle de A
Le cas d’utilisation « B » le plus spécifique n'inclut pas nécessairement tout le comportement du cas d’utilisation « A » qu'il spécialise
Extension (stéréotype « extend » ) :
Exemple général : 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 »
Dépendances d'inclusion et d'extension:
Les inclusions et les extensions sont représentées par des dépendances :
lorsqu'un cas "B" inclus 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épends d'un cas "A" , tout modification de "A" sera susceptible d'avoir un impact sur "B"
Réutilisabilité avec les inclusions et les extensions
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
Exemple:
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.
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.
Un virement est un cas particulier (une sorte) de paiement