Sommaire

Chapitre 2, Section 3
« Cas d’utilisation »
2.3.1 Introduction
 Cas d’utilisation
 Acteur
 Scénario
2.3.2 Identification des cas d’utilisation
2.3.3 Documentation des cas d’utilisation
2.3.4 Diagramme de cas d’utilisation
2.3.5 Étude de cas

Chap.2, Sect.3, p.2

 2.3.1 Introduction
Qu’est-ce qu’un cas d’utilisation ?
Technique permettant d’identifier et de noter les
fonctionnalités du système qui sont significatives pour
ses utilisateurs (humains, matériels, logiciels, etc.)

 Permet de décrire les interactions du système avec son

environnement
 Expression du comportement du système (actions et
réactions) selon le point de vue des utilisateurs du
système
 Détermination des besoins fonctionnels des
utilisateurs cibles.
 Introduit par Ivar Jacobson en 1986.

Chap.2, Sect.3, p.3

 Introduction
Scénarios

 Décrit une exécution possible d’un cas d’utilisation.

 Séquence spécifique d’actions et d’interactions entre les
acteurs et le système.
 Instance d’un cas d’utilisation.
 Un cas d’utilisation est composé:
 Un scénario principal (main flow).
 Aucun ou plusieurs scénarios secondaires (alternative flows).

Chap.2, Sect.3, p.4

 Introduction
Exemple (informel)
Système de prêt dans une bibliothèque
Cas d’utilisation: Prêt d’un livre
 Description: …
 Acteur: Emprunteur de livres
 Pré-conditions:
L’emprunteur de livres se présente avec un exemplaire de livre à
emprunter et sa carte de lecteur.
 Scénario principal.
 La carte de lecteur est lue.
 Le système vérifie si (1) l’emprunteur est un membre « en règle »
de la bibliothèque et (2) s’il n’a pas dépassé le quota de livres en
prêt autorisé.
 Les deux vérifications sont réussies. Le code de l’exemplaire à
emprunter est entré et le système qui vérifie alors si l’exemplaire
est réservé.
 L’exemplaire n’étant pas réservé, le système enregistre le prêt. Un
ticket est émis indiquant la date de retour.
Chap.2, Sect.3, p.5
 Introduction
Exemple (informel)
Système de prêt dans une bibliothèque

 Scénario secondaire (A).

 Une des vérification n’est pas réussie: (1) l’emprunteur n’est pas un
membre « en règle » de la bibliothèque ou il a dépassé le quota de livres
en prêt autorisé.
 Le système signale le problème et refuse la demande de prêt.
 Scénario secondaire (B).
 Le code de l’exemplaire à emprunter est entré et le système signale que
l’exemplaire est réservé.
 La demande de prêt est refusée.

 Post-conditions: Si le cas d’utilisation s’est déroulé normalement, le prêt de

l’exemplaire a été enregistré par le système et l’emprunteur détient un ticket lui
indiquant l’échéance du prêt.

Chap.2, Sect.3, p.6

 Introduction
Acteur
 Représentation idéalisé d’une personne, d’un système, d’un processus,
d’une organisation ou d’une chose qui interagit (depuis l’extérieur) avec
le système.
 Rôle joué par cette personne, système, etc.

 L'acteur peut consulter ou modifier l'état du système. En réponse à

l'action d'un acteur, le système fournit un service qui correspond à la
fonctionnalité désirée..
 Remarques
 Une même personne (physique) peut être liée à plusieurs acteurs
(rôles) dans le système.
 Un même acteur (rôle) peut être joué par plusieurs entités ou individus
distincts.

 L’acteur interagit avec un cas d’utilisation par envoie de message.

 Possibilité d’établir une relation de généralisation entre acteurs (rôles).
Chap.2, Sect.3, p.7
 Introduction
Acteur

Catégories d’acteurs:
a) Acteurs principaux. Bénéficiaires directs du service
décrit par un cas d’utilisation. Ex. Emprunteur de livres.
b) Acteurs de support. Participant offrant un service qui
contribue à la réalisation du cas d’utilisation. Ex. Libraire.
c) Acteurs de coulisse. Bénéficiaires indirects d’un cas
d’utilisation, sans pour autant en être un bénéficiaire direct
ou un contributeur. Ex. Gestionnaire de la bibliothèque.

Chap.2, Sect.3, p.8

 2.3.2 Identification des cas
d’utilisation
À la découverte des cas d’utilisation…
 S’interroger sur les principaux buts et objectifs du système qui
sont d’intérêt pour l’utilisateur
 tentation à éviter: faire la liste des tâches et procédures du
système.
 A propos des sous-objectifs:
 Il est pertinent d’y penser, mais pas toujours nécessaire de les
expliciter…
 A mettre en évidence si ces sous-objectifs se répètent et sont
réutilisés dans le modèle. Ex. Authentifier un membre.
 Savoir juger du bon niveau de granularité à adopter pour assurer
une décomposition (en objectifs et sous-objectifs) qui demeure claire
et compréhensible.
Chap.2, Sect.3, p.9
 Identification des cas d’utilisation
Méthode pour définir les cas d’utilisation
1. Bien définir les frontières du système.
 Cf. Ingénierie système, diagramme de contexte.
2. Identifier les acteurs principaux.
 Qui démarre et arrête le système ?
 Qui gère et/ou initie les mises à jour ?
 Le « temps » est-il un acteur (ex. si le système réagit aux événements
temporels…) ?
 Qui administre le système ?
 Etc.
3. Pour chacun des acteurs, identifier les objectifs principaux qu’ils
souhaitent voir réaliser puisqu’ils en sont les bénéficiaires directs.
4. Définir les cas d’utilisation à partir des objectifs principaux définis en 3.
Utiliser un verbe d’action pour nommer chaque cas.
Chap.2, Sect.3, p.10
 2.3.3 Documentation des cas
d’utilisation
Documents
 Essentiel: Document textuel décrivant chaque cas d’utilisation
 scénarios, acteurs, pré et post conditions, etc.
 Patrons proposés: usecases.org, variation sur deux colonnes (Wirfs-Brock
1993)
 Complémentaire: Diagramme de cas d’utilisation UML.
 Nom des cas d’utilisation, acteurs, relations.

Type de description (textuelle)

 Brève: Un paragraphe par scénario.
 Pratique: Quelques paragraphes pour décrire chaque scénario.
 Détaillée: Description de chacune des étapes composant chacun des
scénarios, avec informations concernant les pré et post conditions,
etc.
Chap.2, Sect.3, p.11
 Documentation des cas d’utilisation
Patron de description détaillée des cas d’utilisation
(usecases.org)
Cas utilisation <no> : <nom>
1. INFORMATIONS CARACTÉRISTIQUES
 Acteurs principaux:
 Objectifs contextuels:
* Pour chaque partie impliquée, décrire les intérêts et bénéfices espérés
par la réalisation de ce cas d'utilisation. Quels sont les objectifs de ce cas
d'utilisation aux vues de chacune des parties ?
 Pré-conditions:
* Spécifient quelles sont les conditions (importantes) qui doivent
absolument être satisfaites avant de pouvoir exécuter l'un ou l'autre des
scénarios du cas d'utilisation.
 Post-conditions:
* Spécifient quelles sont le conditions qui doivent être satisfaites après
l'exécution du cas d'utilisation.
 Déclencheur:
* Action/événement qui déclenche l'exécution du cas d'utilisation.
Chap.2, Sect.3, p.12
 Documentation des cas d’utilisation
Patron de description détaillée des cas d’utilisation
(usecases.org)

2. SCÉNARIO PRINCIPAL (« Le cours normal des choses (sans branchements) »)

 <Numéro de l'étape> <action>

 …

* Décrire chacune des étapes de ce scénario depuis l'événement

déclencheur jusqu'à la réalisation du but.
- Pas de branchement conditionnel.
- Ne pas faire d'hypothèses concernant les interfaces!

* Type d'action composant une étape:

- interaction entre acteurs
- validation (du système)
- changement d'état du système (ex. enregistrement d'une donnée)
Chap.2, Sect.3, p.13
 Documentation des cas d’utilisation
Patron de description détaillée des cas d’utilisation
(usecases.org)

3. SCÉNARIOS SECONDAIRE (EXTENSIONS)

 <numéro étape modifiée/étendue> <numéro(lettre) extension>
<condition> : <séquence d'actions>
 …

* Décrire les extensions (branchement du scénario principal. Chaque

extension (i.e. scénario secondaire) réfère à une étape du scénario
principal et décrit une séquence d’actions alternative.

Chap.2, Sect.3, p.14

 Documentation des cas d’utilisation
Patron de description détaillée des cas d’utilisation
(usecases.org)

4. EXIGENCES SPÉCIALES

Décrire les exigences non fonctionnelle (performance, fiabilité,

contraintes de conception, etc.) directement liées à ce cas
d'utilisation.

5. LISTE DE ALTERNATIVES ET CONTRAINTES TECHNOLOGIQUES

Décrire les outils, technologies, formats de données, etc. imposés ou

suggérés pour la réalisation de ce cas d'utilisation.

Chap.2, Sect.3, p.15

 Documentation des cas d’utilisation
Patron de description détaillée des cas d’utilisation
(usecases.org)

 Exemple: Purchase Order (tif ici)

(tiré du livre de C. Larman « Applying UML and Patterns »)

Chap.2, Sect.3, p.16

 2.3.4 Diagramme de cas d’utilisation
Un diagramme de cas d’utilisation
est composé de…

 Acteurs
Nom_acteur

 Cas d’utilisation Cas d’utilisation

 Relations (entre cas d’utilisation, entre acteurs,

entre acteurs et cas d’utilisation)

Chap.2, Sect.3, p.17

 Diagramme de cas d’utilisation
Exemple 1 - Système de prêt dans une bibliothèque
Bibliothèque

Réserver un livre
Consulter
le catalogue navigateur
Emprunter un
exemplaire de livre
emprunteur
de livres
Prolonger un prêt

Retourner un
Pourquoi le exemplaire de livre
bibliothécaire
n’est pas
acteur du cas bibliothécaire
« Réserver
Mettre à jour
un livre »?
le catalogue

Chap.2, Sect.3, p.18

 Diagramme de cas d’utilisation
Exemple 2 – Vente par catalogue au téléphone
Vente par catalogue au téléphone

Vérifier
disponibilité
objet vendeur

Déposer une
commande

client commis
Exécuter la
commande

Vérifier
solvabilité
superviseur
Chap.2, Sect.3, p.19
 Diagramme de cas d’utilisation
Exemple 3 – Distributeur de billets
Distributeur de billets
Le technicien de
maintenance éteint
Consulter le le distributeur avant
solde du compte de ravitailler
visualise le coffre.

Retirer de
débite l’argent

client technicien
Allumer/éteindre
On ne peut le distributeur
retirer de l’argent
que dans la limite
du stock du coffre Ravitailler
du distributeur le coffre

Chap.2, Sect.3, p.20

 Diagramme de cas d’utilisation
Rappel - Cas d’utilisation
Cas
d’utilisation

 Unité cohérente représentant une fonctionnalité du système visible de

l’extérieur.
 Ensemble d'actions réalisées par le système, en réponse à une action d'un
acteur. Représente un dialogue (une séquence de messages échangés) entre
des acteurs et le système.
 Un cas d’utilisation doit être initié par au moins un acteur et avoir au moins
avoir un acteur bénéficiaire i.e. qui a besoin du cas d’utilisation ou en tire
profit.
 Cas d’utilisation interne: cas d’utilisation présenté à une partie du système…
 Unité fonctionnelle indépendante (n.b. les cas d’utilisation s’exécutent de façon
indépendante bien qu’ils puissent utiliser des objets communs.)
 Des relations (d’utilisation, d’extension, de généralisation) peuvent liés les cas
d’utilisation entre eux.

Chap.2, Sect.3, p.21

 Diagramme de cas d’utilisation
Relation entre acteurs
Généralisation

Toute personne emprunteur

de livres
autorisée à être
emprunteur de journaux
est autorisée à être
emprunteur de livres.

emprunteur
de journaux

Chap.2, Sect.3, p.22

 Diagramme de cas d’utilisation
Exemple – Système de prêt dans une bibliothèque
Bibliothèque

Réserver un livre
Consulter
le catalogue navigateur
Emprunter un
exemplaire de livre
emprunteur
de livres
Prolonger un prêt

Retourner un
exemplaire de livre

Emprunter un bibliothécaire
journal
emprunteur Mettre à jour
Retourner un
de journaux le catalogue
journal
Chap.2, Sect.3, p.23
 Diagramme de cas d’utilisation
Relations entre cas d’utilisation

1. « INCLUDE »
2. « EXTEND »
3. généralisation

 Ces relations sont utilisées pour favoriser

 la modularité
 la réutilisation.
 Remarques:
 Éviter de se donner trop de mal à vouloir établir des relations entre
cas d’utilisation. On les utilise pour clarifier et mettre en évidence
certains comportements.
 La sémantique de ces relations en UML n’est pas standardisée…
Chap.2, Sect.3, p.24
 Diagramme de cas d’utilisation
« INCLUDE »
Cas d’utilisation A « include » Cas d’utilisation C
(base) (inclusion)

Cas d’utilisation B « include »

(base)

 Le cas d’utilisation inclus

 est appelé à un endroit explicite dans le scénario principal du cas
d’utilisation de base et s’insère dans celui-ci.
 est nécessairement exécuté si le cas de base est instancié.
 On utilise la relation « include » pour
 Factoriser des sous-fonctions qui sont communes à d’autres cas
d’utilisation.
 Décomposer en sous-unités un cas d’utilisation complexe.

Chap.2, Sect.3, p.25

 Diagramme de cas d’utilisation
Exemple 1 – « INCLUDE »
Système de prêt dans une bibliothèque

Réserver un livre « include »

Vérifier réservation

emprunteur Emprunter un « include »

de livres exemplaire de livre

Cas d’utilisation X « Réserver un livre »

…
Scénario principal:
1. …
2: Inclure « Vérifier réservation ».
3: …
…
Chap.2, Sect.3, p.26
 Diagramme de cas d’utilisation
« EXTEND »
Cas d’utilisation A
Cas d’utilisation C « extend» (X) (extension)
(base)

extension points Cas d’utilisation B

X, Y (extension)
« extend» (X,Y)
 Permet d’étendre, de façon structurée, le comportement d’un cas
d’utilisation de base en utilisant un autre cas d’utilisation à un point
d’extension spécifique.
 Les points d’extension sont définis à l’intérieur d’un cas d’utilisation de
base, là où un comportement/traitement particulier est nécessaire.
 Lorsqu’on atteint un point d’extension, on se branche sur le ou les
cas d’utilisation traitant ce point d’extension.
 Le cas d’utilisation d’extension doit offrir un traitement spécifique au
point d’extension en question.
 Si plusieurs cas d’utilisation extension sont activés par un même point
d’extension, l’ordre de leur exécution est non déterministe.
Chap.2, Sect.3, p.27
 Diagramme de cas d’utilisation
« EXTEND »

 Le cas d’utilisation d’extension

 est appelé à un endroit explicite (point d’extension) dans le cas
d’utilisation de base (cf. scénarios secondaires…).
 n’est pas nécessairement exécuté même si le cas de base est
instancié. N’est exécuté que si un des points d’extension
correspondants est atteint.
 On utilise la relation « extend » pour
 Mettre en évidence un scénario secondaire suffisamment complexe
pour en faire un cas d’utilisation.

Chap.2, Sect.3, p.28

 Diagramme de cas d’utilisation
Exemple – « EXTEND »
Emprunter un
exemplaire d’un livre
Refuser le prêt
« extend »
Extension points (quota_atteint)
emprunteur quota_atteint
de livres
• Le cas d’utilisation « Refuser le prêt » est activé seulement si on atteint le point d’extension
quota_atteint dans un des scénarios du cas d’utilisation « Emprunter un exemplaire d’un livre ».
On revient ensuite au scénario du cas d’utilisation de base.
Cas d’utilisation Y « Emprunter un exemplaire »
…
Scénario principal: …
Scénarios secondaires (extensions):
…
4a: Nombre de livres empruntés supérieur à la limite:
Point d’extension « quota atteint ».
…
Chap.2, Sect.3, p.29
 Diagramme de cas d’utilisation
Exemple – « EXTEND »

Emprunter un Refuser le prêt

exemplaire de livre « extend »

emprunteur de livres

Chap.2, Sect.3, p.30

 Diagramme de cas d’utilisation
« Include » vs « Extend »
Include
 Sens de la relation: le cas de base
référence le cas inclus
 Exécution: Inconditionnelle.Le cas
inclus est toujours exécuté par le
cas de base (scénario principal).
 Dépendance: le cas de base n’est
pas nécessairement autonome et
bien formé si on omet le cas inclus.
 Visibilité: Le cas de base voit le cas
inclus et peut dépendre de ses
effets dans le cadre de son scénario
principal.
Chap.2, Sect.3, p.31
Extend
 Sens de la relation: le cas d’extension
référence le cas de base.
 Exécution: Conditionnelle. Le cas
d’extension n’est pas nécessairement
exécuté par le cas de base.
 Dépendance: le cas de base est
nécessairement autonome et bien formé
même en l’absence du cas d’extension.
 Visibilité: Le cas de base ne voit pas le
cas d’extension et ne doit pas dépendre
de ces effets dans le cadre de son
scénario principal.
 Diagramme de cas d’utilisation

Généralisation

Emprunter

Emprunter Emprunter
un journal un livre

 Permet à un sous cas d’utilisation de spécialiser le

comportement d’un cas d’utilisation de base.

Chap.2, Sect.3, p.32

 Diagrammes de cas d’utilisation
Comment construire un diagramme de cas
d’utilisation ?
Approche dirigée par les cas d’utilisation

1. Identifier les tâches significatives du système visibles de

l’extérieur. (cas d’utilisation).
2. Identifier quels sont les acteurs qui interagissent avec
chacune de ces tâches.
3. Structurer les cas d’utilisation. Identifier les relations
d’héritage, « include », « extend » et découvrir ainsi les
éventuels cas d’utilisation internes (limiter la hauteur de
la hiérarchie de relation à 2).
Variante: Approche dirigée par les acteurs.
Chap.2, Sect.3, p.33
 Diagramme de cas d’utilisation
Remarques
 Les exigences d’un système sont essentiellement centrée
sur les besoins de l’utilisateur.
 On se concentre ici sur les préoccupations réelles des
utilisateurs ; pas de solutions d'implémentation, pas
d’inventaire fonctionnel du système.

Les cas d’utilisation serviront de base à la validation et à

la traçabilité du système. Ils seront le fil conducteur de
tout le développement.

Ils ne doivent pas chercher l'exhaustivité, mais clarifier,

filtrer et organiser les besoins !
Chap.2, Sect.3, p.34
 Diagramme de cas d’utilisation
Quelques outils

 Rational Requisite Pro

 Enterprise Architect
 D’autres ?

Chap.2, Sect.3, p.35

 2.3.5 Étude de cas
Système d’achat en ligne
 Une fabricant d’ordinateurs offre la possibilité d’acheter ses ordinateurs via
Internet. Le client peut choisir un ordinateur sur la page web du fabricant. Les
ordinateurs sot classés en trois catégories: les serveurs, les ordinateurs de table
et les portables. Le client peut choisir une configuration standard ou peut
spécifier, en ligne, la configuration désirée. Les composants configurables (tels
la mémoire) sont présentés dans des listes d’options à choisir. Pour chaque
nouvelle configuration, le système est capable de calculer le prix.
 Pour faire une commande, le client doit remplir un formulaire déterminant les
modes d’expédition et de paiement. Les modes de paiement acceptés sont les
cartes de crédit et les chèques visés. Une fois la commande entrée, le système
envoie un courriel de confirmation au client avec les détails de sa commande.
En attendant la livraison de son ordinateur, le client peut consulter, via Internet,
l’état de sa commande à tout moment.
 Le traitement de la commande nécessite les étapes suivantes: vérifier la
solvabilité du client, commander la configuration désirée à l’entrepôt, imprimer
la facture et demander à l’entrepôt de livrer l’ordinateur au client.

Chap.2, Sect.3, p.36