3. Diagramme de cas d`utilisation (use case)

3. Diagramme de cas d’utilisation (use case)
Le diagramme de cas d’utilisation participe aux vues statiques du système d’information.
3.1 Origine
Les diagrammes des cas d’utilisation sont similaires en apparence avec ceux de OOSE (Object
Oriented Software Engineering) de Ivar Jacobson.
3.2 Définition
Un cas d’utilisation décrit une utilisation du système, sous forme d’un ensemble de séquences
d’actions, par un acteur particulier
Il modélise l’un des aspects (comportement / service) du système par rapport à cet acteur
Chaque cas d’utilisation décrit une fonction Métier du système selon le point de vue d’un des
acteurs.
L’ensemble des cas d’utilisation doit décrire exhaustivement les exigences attendues du système
et identifie les utilisateurs (acteurs) et leur interaction avec le système.
Les cas d’utilisation décrivent le QUOI et non le COMMENT, dans le cadre du « métier » de
l’acteur. Les cas d’utilisation ne doivent donc en aucun cas décrire des solutions
d’implémentation.
3.3 Composants du diagramme
Les diagrammes de cas d’utilisation se composent d’acteurs (représentés par des silhouettes) et
des cas d’utilisation (représentés par des ellipses). Les traits entre les cas d’utilisation et les
acteurs représentent les interactions.
etudiant
Inscrire
Formation
Cas d’utilisation
Ensemble d'actions réalisées par le système, en réponse à un stimuli d'un acteur.
Un cas d’utilisation est défini par un nom auquel on peut associer un commentaire. Sa
représentation graphique est une ellipse
Cours UML – R. Chapuis
Page : 1
inscrire
Propriétés
Il est possible d’associer une spécification à chaque cas d’utilisation. Il s’agit d’une
description sous forme de texte de la séquence normale d'actions associée à un cas
d'utilisation. Par exemple pour le cas « inscrire » :
1 - saisir les informations personnelles
2 - saisir les informations pédagogiques
3 - enregistrer le numéro d'étudiants
4 - calculer le montant des droits universitaire
5 - enregistrer le paiement des droits universitaires
6 - fournir la carte d'étudiant
Il est possible d’associer à chaque cas la liste des classes et interfaces utilisées pour mettre
en oeuvre le cas d'utilisation.
Les cas d’utilisation peuvent être organisés en paquetages (packages).
L'ensemble des cas d’utilisation décrit les objectifs (le but) du système.
Acteur
Un acteur personnifie un utilisateur humain ou non humain, ou bien un groupe d'utilisateurs qui
interagissent avec un système. Un acteur est représenté graphiquement par une silhouette
Etudiant
Dans un diagramme de cas d’utilisation, les acteurs peuvent être stéréotypés en : :
Acteur principal :
Il déclenche les actions accomplies par un cas d'utilisation. L'acteur principal est celui qui
demande qu'une action soit accomplie par le cas d'utilisation, c'est aussi celui pour qui le cas
d'utilisation produit un résultat observable.
Les acteurs principaux sont situés sur la gauche du cas d'utilisation. Pour indiquer qu'un
acteur est un acteur principal d'un cas d'utilisation, l'association (ou interaction) doit être
dessinée depuis l'acteur vers le cas d'utilisation.
Acteur secondaire :
Il assiste le cas d'utilisation dans l'accomplissement des actions mais il ne les déclenche pas.
Les acteurs secondaires peuvent être sollicités pour des informations complémentaires. Lors
Cours UML – R. Chapuis
Page : 2
de l'exécution d'un cas d'utilisation, ils peuvent uniquement informer le système et / ou
recevoir des résultats.
Les acteurs secondaires sont situés à droite du cas d'utilisation. Pour indiquer qu'un acteur est
un acteur secondaire d'un cas d'utilisation, l'association (interaction) doit être dessinée depuis
le cas d'utilisation vers l'acteur.
Un acteur secondaire pour un cas d’utilisation peut également être l'acteur principal pour un
autre cas d'utilisation.
Et dans le même temps en :
Humain
Non humain : Système (matériels, logiciels).
Propriété
Un acteur est identifié par un nom auquel on peut ajouter un commentaire.
Association (ou interaction)
Une association est une relation unidirectionnelle qui décrit un lien entre :
Un acteur et un cas d'utilisation
Un cas d'utilisation et un acteur
Une association entre un acteur et un cas d'utilisation est une association d'entrée. Une
association entre un cas d'utilisation et un acteur est une association de sortie.
Entrée
Etudiant
inscrire
Propriétés :
Une association est identifié par un nom auquel on peut ajouter un commentaire.
Avec PowerAmc, il est possible d'afficher le sens (entrée, sortie) de l'association
Cours UML – R. Chapuis
Page : 3
3.3 Exemples
Diagramme de cas d’utilisation d’un guichet automatique bancaire
Retirer de l'argent
Client
déposer de l'argent
Faire des virements entre comptes
Consulter le solde d'un compte
Employé
Ravitaller distributeur
Réparer distributeur
Agent de maintenance
Cours UML – R. Chapuis
Page : 4
3.4 Dépendance
Une dépendance est une relation entre deux cas d'utilisation dans laquelle toute modification
effectuée sur l'un (l'élément influent) affecte l'autre (élément dépendant).
UML définit trois types de dépendances standardisées entre cas d’utilisation :
Une relation d’inclusion : formalisée par la dépendance « include »
Une relation d’extension : formalisée par la dépendance « extend »
Une relation de généralisation / spécialisation
La relation d’inclusion <<include>>
Lors de la description des cas d’utilisation, il apparaît qu’il existe des sous-ensembles communs à
plusieurs cas d’utilisation, il convient donc de factoriser ces fonctionnalités en créant de
nouveaux cas d’utilisation qui seront utilisés par les cas d’utilisation qui les avaient en commun.
A élément dépendant
<<include>>
B élément influant
Un cas d’utilisation A utilise un cas d’utilisation B signifie que :
une instance de A va engendrer une instance de B et l’exécuter,
A dépend de B,
B n’existe pas tout seul et A n’existe pas sans B
Exemple
« Déposer de l’argent », « Retirer de l’argent », « Faire des virements entre comptes » et «
Consulter le solde d’un compte» incorporent de façon explicite le cas d’utilisation « authentifier
», à un endroit spécifié dans leurs spécifications.
Cours UML – R. Chapuis
Page : 5
Retirer de l'argent
<<include>>
déposer de l'argent
<<include>>
Autentifier
<<include>>
Faire des virements entre comptes
<<include>>
Consulter le solde d'un compte
La relation d’extension <<extend>>
Elle permet d'étendre les interactions et donc les fonctions décrites par les interactions. Le cas de
base peut fonctionner tout seul, mais il peut également être complété par un autre, sous certaines
conditions, et uniquement à certains points particuliers de sa spécification (point d’insertion). On
utilise principalement cette relation pour séparer le comportement optionnel (les variantes) du
comportement obligatoire.
A élément influant
<<extend>>
B élément dépendant
Le cas d’utilisation B étend le cas d’utilisation A signifie que :
Une instance de A va engendrer une instance de B et l’exécuter sous certaines conditions.
Il faut indiquer dans la spécification textuelle de A le "point d'insertion" de B.
Cours UML – R. Chapuis
Page : 6
Les cas d'utilisation A et B peuvent s'exécuter indépendamment.
La relation <<extend>> montre une possibilité d'exécution d'interactions qui augmenteront les
fonctionnalités du cas étendu, mais de façon optionnelle, non obligatoire, alors que la relation
<<include>> suppose une obligation d’exécution des interactions.
Exemple
Pendant l'exécution du cas d'utilisation "retirer de l'argent" on permet au client de consulter le
solde de son compte juste avant de choisir le montant de son retrait.
Retirer de l'argent
<<extend>>
Vérification montant
Consulter le solde
Dans la spécification du cas d'utilisation A on définit le point d'insertion :
…
7 – le système d'autorisation a reconnu le code de la acrte et autorise le retrait
8 – le GAB demande le montant désiré du retrait
Point d'insertion : Vérification montant
9 – le client saisit le montant désiré de retrait
…
Relation de généralisation entre cas d’utilisation
La relation d'héritage ou de généralisation entre cas est plus subtile. Cette relation est à prendre
au sens classique de spécialisation, inhérent à 'héritage. Ici, la généralisation peut être vue aussi
comme un "polymorphisme" de cas.
Exemple
Dans un système d'agence de voyage, un acteur touriste peut participer à un cas de base qui est
"Réserver voyage", qui suppose par exemple des interactions basiques au comptoir de l'agence.
Une réservation peut aussi être réalisée par téléphone ou internet. On voit qu'il ne s'agit pas de
relation <<extend>> car la réservation par Internet n'étend pas les interactions ni les
fonctionnalités du cas 'Réserver voyage". Elle les traduit différemment. Les interactions Internet
ne sont pas une option des interactions comptoir. Par contre les deux cas "Réserver voyage" et
"Réserver voyage par Internet" sont liés : la réservation par Internet est un cas particulier de
réservation. De façon générale en objet, une situation de cas particulier se traduit par une relation
de généralisation.
Cours UML – R. Chapuis
Page : 7
reserver voyage
Client
reserver par téléphone
réserver par internet
3.4 Scénario
Un scénario est une succession particulière d'actions qui s'exécutent du début à la fin du cas
d'utilisation. Pour chaque cas d'utilisation, on distingue trois types de scénario :
- le scénario nominal
- les scénarios alternatifs
- les scénarios d'erreur
Exemple :
Pour le cas d'utilisation "inscrire" :
le scénario nominal est :
1 - saisir les informations personnelles
2 - saisir les informations pédagogiques
3 - enregistrer le numéro d'étudiant
4 - calculer le montant des droits universitaire
5 - enregistrer le paiement des droits universitaires
6 - fournir la carte d'étudiant
un scénario alternatif est :
1 - saisir les informations personnelles
2 - saisir les informations pédagogiques
3a - l'étudiants est déjà enregistré à l'Université
on conserve alors le même numéro
4 - calculer le montant des droits universitaire
5 - enregistrer le paiement des droits universitaires
6 - fournir la carte d'étudiant
un scénario d'erreur est
1 - saisir les informations personnelles
2 - saisir les informations pédagogiques
2a - les prérequis de l'étudiant ne permettent pas 'inscrire l'étudiant à la formation
7 - le cas d'utilisation est terminé
Cours UML – R. Chapuis
Page : 8