Génie Logiciel
Chapitre 3:
Diagramme UML de cas d’utilisation : une fonctionnelle
Niveau: 3ième année License informatique
Année: 2023/2024
1
Modélisation des besoins
Avant de développer un système, il faut savoir
précisément à « QUOI » il devra servir, cad à
quels besoins il devra répondre.
Modéliser les besoins permet de :
Faire l'inventaire des fonctionnalités attendues ;
Organiser les besoins entre eux, de manière à faire
apparaître des relations (réutilisations possibles, ...).
Avec UML, on modélise les besoins au moyen de
diagrammes de cas d'utilisation.
2
Exemple de diagramme de cas d'utilisation
3
Cas d'utilisation
Un cas d'utilisation est un service rendu à l'utilisateur, il
implique des séries d'actions plus élémentaires.
Un acteur est une entité extérieure au système
modélisé, et qui interagit directement avec lui.
Un cas d'utilisation est l'expression d'un service réalisé
de bout en bout, avec un déclenchement, un
déroulement et une fin, pour l'acteur qui l'initie.
4
Acteurs et cas d'utilisation
5
Relations entre cas d'utilisation et acteurs
Les acteurs impliqués dans un cas
d'utilisation lui sont liés par une association.
Un acteur peut utiliser plusieurs fois le même
cas d'utilisation.
6
Relations entre cas d'utilisation
Inclusion : le cas A inclut le cas B (B est une partie obligatoire de A).
Extension : le cas B étend le cas A (B est une partie optionnelle de A).
Généralisation : le cas A est une généralisation du cas B (B est une
sorte de A).
7
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 B ---> A qui se
lit « B dépend de A ».
Lorsqu'un élément A dépend d'un élément B, toute modification de
B sera susceptible d'avoir un impact sur A.
Les « include » et les « extend » sont des stéréotypes (entre
guillemets) des relations de dépendance.
Attention!!!
Le sens des flèches indique la dépendance, pas le sens de la
relation d'inclusion.
8
Réutilisabilité avec les inclusions et les
extensions
Les relations entre cas permettent la réutilisabilité du cas
(s'authentifier) : il sera inutile de développer plusieurs
fois un module d'authentification.
9
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.
10
Généralisation
Un virement est un cas particulier de paiement.
Un virement est une sorte de paiement.
La flèche pointe vers l'élément général.
Cette relation de généralisation/spécialisation est présente dans la
plupart des diagrammes UML et se traduit par le concept d'héritage
dans les langages orientés objet.
11
Relations entre acteurs
Une seule relation possible : la généralisation.
12
Identification des acteurs
Les principaux acteurs sont les utilisateurs du système.
Attention!!!
Un acteur correspond à un rôle, pas à une personne physique.
Une même personne physique peut être représentée par plusieurs acteurs si elle a
plusieurs rôles.
Si plusieurs personnes jouent le même rôle vis-à-vis du système, elles seront
représentées par un seul acteur.
En plus des utilisateurs, les acteurs peuvent être :
Des périphériques manipulés par le système (imprimantes...) ;
Des logiciels déjà disponibles à intégrer dans le projet ;
Des systèmes informatiques externes au système mais qui interagissent
avec lui, etc.
Pour faciliter la recherche des acteurs, on se fonde sur les
frontières du système.
13
Acteurs principaux et secondaires
L'acteur est dit principal pour un cas d'utilisation lorsque l'acteur est
à l'initiative des échanges nécessaires pour réaliser le cas
d'utilisation.
Les acteurs secondaires sont sollicités par le système alors que le
plus souvent, les acteurs principaux ont l'initiative des interactions.
Le plus souvent, les acteurs secondaires sont d'autres systèmes informatiques
avec lesquels le système développé est inter-connecté.
14
Recenser les cas d'utilisation
Il n'y a pas une manière mécanique et totalement
objective de repérer les cas d'utilisation.
Il faut se placer du point de vue de chaque acteur et déterminer
comment il se sert du système, dans quels cas il l'utilise, et à
quelles fonctionnalités il doit avoir accès.
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.
Trouver le bon niveau de détail pour les cas d'utilisation est
un problème difficile qui nécessite de l'expérience.
15
Description des cas d'utilisation
Le diagramme de cas d'utilisation décrit les grandes
fonctions d'un système du point de vue des acteurs,
mais n'expose pas de façon détaillée le dialogue entre
les acteurs et les cas d'utilisation.
Un simple nom est tout à fait insuffisant pour décrire un
cas d'utilisation.
Chaque cas d'utilisation doit être documenté pour qu'il n'y
ait aucune ambiguïté concernant son déroulement et ce
qu'il recouvre précisément.
16
Description textuelle
Exemple de description textuelle d’un cas d’utilisation
17
