Modélisation &

Programmation Objet
[Link]@[Link]

1
Séance 7 : Diagramme de cas
d’utilisation

• Introduction

• Éléments du Diagramme de cas

d’utilisation

• Relations entre cas d’utilisation

• Relations entre acteurs

• Quelques notions de modélisation

• Modélisation des besoins avec UML

2
Introduction

3
Vue fonctionnelle du modèle UML
• La partie fonctionnelle du modèle UML d’une application permet de spécifier les
fonctionnalités offertes par l’application sans pour autant spécifier la façon
dont ces fonctionnalités sont réalisées par les objets de l’application.

• En UML, le diagramme de cas d’utilisation est l’un des diagramme les plus
importants qui représente l’aspect fonctionnel du système.

4
Qu’est ce qu’un diagramme de cas d’utilisation?

• Un diagramme de cas d'utilisation capture le comportement d'un système, d'un

sous-système, d'une classe ou d’un composant tel qu'un utilisateur extérieur le
voit.

• Objectif : Représenter les fonctions du système de point de vue de l’utilisateur,

ainsi que définir ses limites et ses relations avec l’environnement.

• Un cas d’utilisation : Ce que le système doit faire (comportement souhaité)

indépendamment de la réalisation.

5
Qu’est ce qu’un diagramme de cas d’utilisation?

Borne interactive d’une banque Nom du système

Frontière du système

S’authentifier
Exemple:
Consulter
solde
Acteur Cas
Client d’utilisation
Retirer argent
Association

6
Acteur
• Tout ce qui doit échanger de l’information avec le système;

• Un acteur est un rôle joué par une entité externe qui agit sur le système
(Comptabilité, service commercial, …), en échangeant de l’information (en entrée
et en sortie). Ainsi, une même personne (ou autre entité) peut jouer plusieurs
rôles.

• Un acteur peut être représenté de deux manières différentes :

• Classe «Acteur»
• Petit personnage Nom de l’acteur
(stick man) stéréotypée
Nom de l’acteur

7
Acteur
On distingue trois types d’acteurs :

• Humains: utilisateurs du logiciel à travers son interface graphique, par

exemple.
• Logiciels : disponibles qui communiquent avec le système grâce à une interface
logicielle (API, ODBC, …).
• Matériels : exploitant les données du système ou qui sont pilotés par le
système (Imprimante, robots, automates, …).

8
Acteur

Exemple:
Système
Secrétaire
Système de
Gestion de
Scolarité

Etudiant

«Acteur»
«Acteur»
Site Web de
Imprimante
l’établissement

9
Acteur
Du point de vue système, on distingue deux types d’acteurs :

• Un acteur principal: qui utilise les fonctions principales du système.

 Exemple : le client pour un distributeur de billets.
• Un acteur secondaire: qui effectue des tâches administratives ou de
maintenance, ou encore qui réagissent aux taches initiées par las acteurs
principaux.
 Exemple : la personne qui recharge la caisse contenue dans le
distributeur.

• Remarques:
 Un cas d’utilisation a au plus un acteur principal.
 En général, l’acteur principal initie le cas d’utilisation par ses
sollicitations.
 Un acteur secondaire est sollicité pour des informations complémentaires.
 Un cas d’utilisation a un ensemble, éventuellement vide, d’acteurs
secondaires.
10
Cas d’utilisation : Use Case
Un cas d’utilisation spécifie une fonction offerte par l’application à son
environnement.

Correspond à un rôle générique que l'utilisateur joue = une manière d'utiliser le

système

Il réalise un service de bout en bout, avec un déclenchement, un déroulement et une

fin, pour l’acteur qui l’initie.

Un cas d'utilisation est représenté par une ellipse en trait plein, contenant son
nom.
Nom du cas
d’utilisation

11
Relation : Entre acteur et cas d’utilisation
• Elle exprime l'interaction existant entre un acteur et un cas d'utilisation.

• La relation d’association entre un cas d’utilisation et un acteur est

représentée par un trait continu.

Cas
d’utilisation
Acteur

12
Relation : Entre acteur et cas d’utilisation
Association avec multiplicité :

• La multiplicités (0..1, 1, 1..*, 0..*, n, n..m, *) permet de définir le nombre

d'utilisations possibles du cas d'utilisation.

• Par exemple, lorsqu’un acteur peut interagir

plusieurs fois avec un cas d’utilisation, Système de partage de fichiers
le symbole * qui signifie plusieurs est
ajouté à l’extrémité du cas.
Télécharger
* fichier
Internaute

13
Relation : Entre cas d’utilisation

Il existe principalement deux types de relations :

• les dépendances stéréotypées, qui sont explicitées par un stéréotype. Les plus utilisées
sont : l’inclusion et l’extension.
• la généralisation/spécialisation.

14
Relation : Entre cas d’utilisation
L’inclusion Borne interactive d’une banque

• Elle indique que le cas d'utilisation source

contient aussi le comportement décrit dans le
cas d'utilisation destination.
Consulter
• Un cas A est inclus dans un cas B si le solde
comportement décrit par le cas A est S’authenti
inclus dans le comportement de B. fier
• Elle permet de factoriser une partie Retirer
commune à plusieurs cas d’utilisation Client argent
et de décomposer un cas complexe en
sous cas plus simples.

Remarques :
• Un cas d’utilisation est dit interne sil n’est pas relié directement à un acteur.
• Les relations entre cas d’utilisation ne sont pas obligatoires (mais recommandées).
Elles permettent de clarifier et d’enrichir les cas d’utilisation.
15
Relation : Entre cas d’utilisation
L’extension

• Le cas d’utilisation source B ajoute, sous certaines conditions, son comportement au

cas d’utilisation destination A. En d’autres termes, le cas d’utilisation B peut être
appelé au cours de l’exécution du cas d’utilisation A.

• Le comportement ajouté s’insère au niveau d’un point d’extension définit dans le cas
d’utilisation destination.

A
B
«extend» Point d’insertion

16
Relation : Entre cas d’utilisation
Borne interactive d’une banque
L’extension : exemple
Consulter
compte

Retirer argent

S’authentifier
Effectuer virement
Client
Point d’extension : vérification
Solde {après avoir demandé le
montant}
Condition:
{Si montant>200} «extend»
Points d’extension:
vérification du Solde
Vérifier solde

17
Relation : Entre cas d’utilisation
La généralisation

• Il peut également exister une relation d'héritage entre les cas d'utilisation.
• Cette relation exprime une relation de spécialisation/généralisation au sens
classique.
• Un cas A est une généralisation d’un cas B si B est un cas particulier de A.

B A

18
Relation : Entre cas d’utilisation
La généralisation:
Système d’agence de voyage

Exemple Réserver un
billet

Réserver par Réserver par

Client téléphone Internet

19
 Système d’agence de voyage
Relation : Entre acteurs
La généralisation: Passer une
commande

• La seule relation possible Préposé aux Suivre une

entre deux acteurs est la commandes commande
généralisation.
Chercher
• Un acteur A est une un fichier
généralisation d’un
acteur B si l’acteur
A peut être substitué
par l’acteur B. Gérer le
stock
Directeur
des ventes

20
Étapes de construction du diagramme des cas d'utilisation
Pour modéliser le diagramme des cas d'utilisation, il faut:

• Identifier les acteurs qui entourent le système. Certains acteurs utilisent le

système pour accomplir des tâches (acteurs principaux), d'autres effectuent des
tâches de maintenance ou d'administration (acteurs secondaires).

• Organiser les acteurs selon une hiérarchisation de généralisation/spécialisation.

• Intégrer les acteurs au diagramme en spécifiant les cas d'utilisation aux quels
ils se rapportent

• Structurer les cas d'utilisation pour faire apparaître les comportement partagés
(relation d'inclusion), les cas particuliers (généralisation/spécialisation) ou
options (relation d'extension).

21
Comment identifier les acteurs ?

• Les acteurs d’un système sont les entités externes à ce système qui interagissent avec
lui.

• Un acteur représente un ensemble cohérent de rôles joués vis-à-vis du système.

• Chaque acteur doit être nommé, le nom doit refléter le rôle.

• Plusieurs utilisateurs peuvent avoir le même rôle, et donc correspondre à un même

acteur.

• Une même personne physique peut jouer des rôles différents vis-à-vis du système et
donc correspondre à plusieurs acteurs.

22
Comment recenser les cas d’utilisation ?

• Se placer du point de vue de chaque acteur et déterminer comment il utilise le

système.
• Éviter la redondance.
• Ne pas faire apparaître les détails des cas d’utilisation (ne pas réduire un cas à une
action).
• Rester au niveau des grandes fonctions du système.
• Garder à l’esprit qu’il n’y a pas de notion temporelle dans un diagramme de cas
d’utilisation.

 N.B. L’ensembles des cas d’utilisation doit couvrir exhaustivement tous les besoins
fonctionnels du système.

23
Exercice d’application

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.
Modéliser cette situation par un diagramme de cas d'utilisation.

24
Exercice d’application

Dans un magasin, un commerçant dispose d’un système de gestion de son stock d’articles,
dont les fonctionnalités sont les suivantes :
• Edition de la fiche d’un fournisseur
• Possibilité d’ajouter un nouvel article (dans ce cas, la fiche fournisseur est
automatiquement éditée. Si le fournisseur n’existe pas, on peut alors le créer)
• Edition de l’inventaire. Depuis cet écran, on a le choix d’imprimer l’inventaire,
d’effacer un article ou d’éditer la fiche d’un article).

Modéliser cette situation par un diagramme de cas d’utilisation

25
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 il n’expose pas de façon détaillée le dialogue entre les acteurs
et les cas d’utilisation.
→ Nécessité de décrire ce dialogue
• Deux façons sont couramment utilisées pour décrire les cas d’utilisation :
 Description textuelle;
 Description à l’aide d’un diagramme de séquence (cours suivant);

26
Description textuelle des cas d’utilisation

Il est recommandé de rédiger une description textuelle en trois parties :

• Identifier le cas : Nom, Objectif, Acteurs principaux, Acteurs secondaires, Dates,
etc.
• Description du fonctionnement du cas :
 Les pré-conditions : État du système avant que ce cas d’utilisation puisse être
déclenché.
 Des scénarios : Décrits sous la forme d’échanges d’évènements entre l’acteur et le
système.
o Scénario nominal (quand il n’y a pas d’erreur)
o Scénarios alternatifs (variantes du scénario nominal)
o Scénarios d’exception (cas d’erreurs)
 Des post-conditions : État à l’issue des différents scénarios.
• Rubrique optionnelle (interface graphique, etc.).

27
Description textuelle des cas d’utilisation
Exemple : Description d’un retrait d’argent

Identification
Nom du cas : retrait d’espèce
But : détaille les étapes permettant à un guichetier d’effectuer l’opération de retrait
d’argent en espèce.
Acteur principal : Guichetier
Acteur secondaire : Système central.
Date : le 10/03/2007
Responsable : M. Larbi
Version : 1.0
Séquencement
Le cas d’utilisation commence lorsqu’un client demande le retrait d’argent en espèce.
Pré-conditions
Le client possède un compte (donne son numéro de compte)

28
Description textuelle des cas d’utilisation
Exemple : Description d’un retrait d’argent

Enchaînement nominal
1. Le guichetier saisit le numéro de compte client.
2. L’application valide le compte auprès du système central.
3. L’application demande le type d’opération au guichetier .
4. Le guichetier sélectionne un retrait du montant demandé par le client.
5. L’application demande au système central de débiter le compte.
6. Le système notifie au guichetier qu’il peut délivrer le montant demandé.
Post-conditions
Le guichetier ferme le compte et renvoie la carte.
Le client récupère l’argent.
Rubriques optionnelles
Contraintes non fonctionnelles
Fiabilité : Les accès doivent être extrêmement sûrs et sécurisés
Contraintes liées à l’interface homme-machine
Toujours demander la validation des opérations de retrait.
29