UML :Diagramme de cas d'utilisation (cours)

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