CHAPITRE 2
Modéliser les besoins client par un
diagramme de cas d’utilisation
1. Introduction au langage de modélisation UML
2. Définition du diagramme des cas d’utilisation
3. Acteurs
4. Cas d’utilisation
5. Relation entre acteurs et cas d’utilisation
6. Relations entre cas d’utilisation
7. Relation de généralisation ou de spécialisation
8. Description textuelle des cas d’utilisation
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Introduction au langage de modélisation UML
Modélisation
▪ Un modèle : une représentation abstraite d’un système destiné à en faciliter l’étude et à le documenter.
▪ C’est un outil majeur de communication entre les différents intervenants au sein d’un projet web.
▪ Chaque membre de l’équipe, depuis l’utilisateur jusqu’au développeur, utilise et enrichit le modèle différemment.
▪ C’est un outil pour maîtriser les systèmes devenant de plus en plus complexes.
▪ Il permet de faciliter la traçabilité du système, à savoir la possibilité de partir d’un de ses éléments et de suivre ses
interactions et liens avec d’autres parties du modèle.
PARTIE 1
Copyright - Tout droit réservé - OFPPT 50
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Introduction au langage de modélisation UML
Modélisation
Il accompagne le processus de développement du projet web (cycle de vie)
* Le système est comme une * Le modèle représente le * Le modèle correspond aux
boîte noire à part entière. système vu de l’intérieur concepts informatiques qui
sont utilisés par les outils, les
* Réaliser un modèle de * Il se compose d’objets langages ou les plates-
niveau contexte représentant une abstraction formes de développement
des concepts manipulés par
* Tracer précisément les les utilisateurs * Il sert ici à étudier,
frontières fonctionnelles du documenter,
système * Le modèle comprend communiquer et anticiper
deux points de vue : la une solution
structure statique et le
PARTIE 1
comportement dynamique
Activités de Activités d’analyse Activités de conception
spécification des exigences
Copyright - Tout droit réservé - OFPPT 51
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Introduction au langage de modélisation UML
Modélisation avec UML
▪ Le modèle en tant qu’abstraction d’un système s’accorde parfaitement bien avec les concepts orientés objet.
▪ Cela explique le succès de la modélisation objet dans la programmation orienté objet,
▪ Le standard industriel de modélisation objet est UML (Unified Modeling Language)
▪ UML est une synthèse de langages de modélisation objet antérieurs : Booch, OMT, OOSE. Principalement issu des travaux
de Grady Booch, James Rumbaugh et Ivar Jacobson
Nov 1997:
Adoption par
l’OMG Mar 2005 Déc 2017
Oct 1994 Juin 1996
UML 1.1 UML 2.0 UML 2.5
Booch’93 + OMT-2 UML 0.9
Oct 1995 Janv 1997 :
Mars 2003 Janv 2009
Soumission à
Unified
PARTIE 1
G. Booch l’OMG UML 1.5 UML 2.2
Method 0.8
Booch-91
UML 1.0
J. Rumbaugh
OMT-1
I. Jacobson OMG : Object Management Group
OOSE Partenaires
UML Définit le méta-modèle d’UML
Copyright - Tout droit réservé - OFPPT 52
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Introduction au langage de modélisation UML
UML
▪ UML est un langage visuel dédié à la spécification, la construction et la documentation d’un système d’information
▪ UML comporte treize types de diagrammes représentant autant de vues distinctes pour représenter des concepts
particuliers du logiciel, réparties en 3 niveaux :
Niveau Fonctionnel Niveau Structurel Niveau comportemental
• Diagramme Use Case • Diagramme de classes • Diagramme d’activités
(Cas d’utilisation) • Diagramme d’objets • Diagramme d’états-transitions
• Diagramme de composants • Diagrammes d’interaction
• Diagramme de déploiement • Diagramme de séquence
• Diagramme de paquetages • Diagramme de communication
• Diagramme de structures composites • Diagramme global d’interaction
PARTIE 1
• Diagramme de temps
▪ Dans ce chapitre, on va étudier les diagrammes mis en gras foncé dans le tableau
Copyright - Tout droit réservé - OFPPT 53
CHAPITRE 2
Modéliser les besoins client par un
diagramme de cas d’utilisation
1. Introduction au langage de modélisation UML
2. Définition du diagramme des cas d’utilisation
3. Acteurs
4. Cas d’utilisation
5. Relation entre acteurs et cas d’utilisation
6. Relations entre cas d’utilisation
7. Relation de généralisation ou de spécialisation
8. Description textuelle des cas d’utilisation
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Définition du diagramme des cas d’utilisation
Diagramme Cas d’Utilisation (DCU)
▪ Le diagramme de cas d’utilisation (DCU) est utilisé dans l’activité de spécification des besoins. Il montre les
interactions fonctionnelles entre les acteurs et le système à l’étude
▪ Le diagramme des cas d’utilisation permet de représenter la vision détaillée de l’application du point de vue de
l’utilisateur
▪ Il répond à la question : A qui et pour quoi faire?
Figure 11 : Diagramme Cas d’utilisation
PARTIE 1
Copyright - Tout droit réservé - OFPPT 55
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Définition du diagramme des cas d’utilisation
DCU - Démarche
▪ Voici les différentes étapes afin d’aboutir au modèle des cas d’utilisation
finaliser un ou
Identifier ajouter les plusieurs
Identifier les relations diagramme(s)
acteurs les cas entre cas de cas
d’utilisation d’utilisation d’utilisation
par package
PARTIE 1
Copyright - Tout droit réservé - OFPPT 56
CHAPITRE 2
Modéliser les besoins client par un
diagramme de cas d’utilisation
1. Introduction au langage de modélisation UML
2. Définition du diagramme des cas d’utilisation
3. Acteurs
4. Cas d’utilisation
5. Relation entre acteurs et cas d’utilisation
6. Relations entre cas d’utilisation
7. Relation de généralisation ou de spécialisation
8. Description textuelle des cas d’utilisation
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Acteurs
Acteurs - Définition
▪ Un acteur représente un rôle joué par une entité externe qui interagit directement avec le système étudié.
▪ Il peut être un utilisateur humain, un dispositif matériel ou un autre système.
▪ L’acteur est celui qui bénéficie de l’utilisation du système.
Exemples d’interaction avec le système :
• Consulter et/ou modifier directement l’état du système.
• Emettre et/ou en recevoir des messages susceptibles d’être porteurs de données
Remarques
PARTIE 1
• Ne pas confondre rôle et personne physique. Une même personne peut jouer successivement différents rôles par
rapport au système étudié, et être modélisée par plusieurs acteurs.
• un même rôle peut être tenu simultanément par plusieurs personnes, qui seront alors modélisées par le même acteur.
• Exemple : Une seule personne physique peut jouer successivement les rôles de manager et Webmaster vis à vis du site
web, il s’agit bien de deux acteurs distincts, de deux profils différents.
Copyright - Tout droit réservé - OFPPT 58
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Acteurs
Acteur principal vs Acteur secondaire
▪ Tous les acteurs n’utilisent pas forcément le système.
▪ Un acteur principal est celui pour qui le cas d’utilisation produit un résultat observable.
▪ Un acteur secondaire est un participant au cas d’utilisation. Il est souvent sollicité pour des informations complémentaires;
il peut uniquement consulter ou informer le système lors de l’exécution du cas d’utilisation.
Bonne pratique
• Faire figurer les acteurs principaux à gauche des cas d’utilisation
et les acteurs secondaires à droite.
PARTIE 1
• Utiliser la forme graphique du stick man pour les acteurs
humains
• Utiliser une représentation rectangulaire avec le mot-clé
<<actor>> pour les systèmes connectés
Figure 12 : Exemple Acteurs d’un site Librairie en Ligne
Copyright - Tout droit réservé - OFPPT 59
CHAPITRE 2
Modéliser les besoins client par un
diagramme de cas d’utilisation
1. Introduction au langage de modélisation UML
2. Définition du diagramme des cas d’utilisation
3. Acteurs
4. Cas d’utilisation
5. Relation entre acteurs et cas d’utilisation
6. Relations entre cas d’utilisation
7. Relation de généralisation ou de spécialisation
8. Description textuelle des cas d’utilisation
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Cas d’utilisation
Définition
▪ Un cas d’utilisation (use case) représente un ensemble de séquences d’actions qui sont réalisées par le système et qui
produisent un résultat observable intéressant pour un acteur particulier.
▪ Un cas d’utilisation modélise un service rendu par le système. Il exprime les interactions acteurs/système et apporte une
valeur ajoutée « notable » à l’acteur concerné.
▪ Pour chaque acteur identifié précédemment, on doit rechercher les différentes intentions (objectif métier) d’utilisation du
système
▪ Un cas d’utilisation peut faire participer plusieurs acteurs et qu’un acteur peut participer à plusieurs cas d’utilisation
Remarques
• Cas d’utilisation = ensemble d’actions concrétisant une intention
PARTIE 1
de l’acteur
• Erreur fréquente A éviter : Le cas d’utilisation se réduit systématiquement
à une seule action
• Bonne pratique : Nommer les cas d’utilisation par un verbe à l’infinitif suivi
d’un complément, du point de vue de l’acteur Figure 13 : Cas d’utilisation d’un internaute
dans un site Librairie en Ligne
Copyright - Tout droit réservé - OFPPT 61
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Cas d’utilisation
Comment découvrir les cas d’utilisation?
• Délimiter le périmètre du système
Système
• Qui utilisent le système
Acteurs • Qui fournissent un service au système
secondaires
• Qui utilisent le système pour atteindre un but
Acteurs
principaux
PARTIE 1
• Définir les cas d’utilisation correspondants à ces buts
Cas
d’utilisation
Copyright - Tout droit réservé - OFPPT 62
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Cas d’utilisation
Diagramme des Cas d’utilisation - Exemple
PARTIE 1
Copyright - Tout droit réservé - OFPPT 63
CHAPITRE 2
Modéliser les besoins client par un
diagramme de cas d’utilisation
1. Introduction au langage de modélisation UML
2. Définition du diagramme des cas d’utilisation
3. Acteurs
4. Cas d’utilisation
5. Relation entre acteurs et cas d’utilisation
6. Relations entre cas d’utilisation
7. Relation de généralisation ou de spécialisation
8. Description textuelle des cas d’utilisation
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation entre acteurs et cas d’utilisation
Relation d’association
▪ Une association est une relation entre éléments UML qui décrit un ensemble de liens.
▪ Elle est utilisée dans le cadre du diagramme de cas d’utilisation pour relier les acteurs et les cas d’utilisation par une
relation qui signifie simplement : « participe à ».
▪ Une association peut être sans flèches ou à flèches (sens du ou vers le système)
Les acteurs non humains ne font
Cet acteur ne fait que recevoir qu’envoyer des messages au
des messages du système sans système, sans recevoir
envoi (Sens unique de
transmission d’information)
PARTIE 1
Cet acteur va interagir dans les
Figure 15 : Cas d’utilisation d’un employé
deux sens avec le système
Figure 14 : Cas d’utilisation d’un internaute
Copyright - Tout droit réservé - OFPPT 65
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation entre acteurs et cas d’utilisation
Multiplicité
▪ Lorsqu'un acteur peut interagir plusieurs fois avec un cas d'utilisation, il est possible d'ajouter une multiplicité sur
l'association du côté du cas d'utilisation :
• plusieurs : avec le symbole *,
• exactement n : s'écrit tout simplement n,
• entre n et m : s’écrit n..m
PARTIE 1
Figure 16 : DCU d’un logiciel de partage de fichiers
Copyright - Tout droit réservé - OFPPT 66
CHAPITRE 2
Modéliser les besoins client par un
diagramme de cas d’utilisation
1. Introduction au langage de modélisation UML
2. Définition du diagramme des cas d’utilisation
3. Acteurs
4. Cas d’utilisation
5. Relation entre acteurs et cas d’utilisation
6. Relations entre cas d’utilisation
7. Relation de généralisation ou de spécialisation
8. Description textuelle des cas d’utilisation
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation entre cas d’utilisation
▪ Pour affiner le diagramme de cas d’utilisation, UML définit trois types de relations standardisées entre cas d’utilisation :
Une relation Une relation Une relation
d’inclusion, d’extension, de
formalisée par formalisée par généralisation
le mot-clé le mot-clé /
<<include>> <<extend>> spécialisation
PARTIE 1
Copyright - Tout droit réservé - OFPPT 68
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation entre cas d’utilisation
Relation d’inclusion
▪ Notée <<include>> (on trouve aussi <<uses>>),
▪ Le cas d’utilisation de base incorpore explicitement un autre, de façon obligatoire,
▪ Une relation include montre une fonctionnalité commune à plusieurs cas d’utilisation.
PARTIE 1
Figure 17 : Exemple DCU avec relation <<include>>
Copyright - Tout droit réservé - OFPPT 69
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation entre cas d’utilisation
Relation d’extension
▪ Notée <<extends>> ,
▪ Le cas de base peut fonctionner tout seul, mais il peut également être complété par un autre (optionnel avec une
condition préciser)..
Le cas d’utilisation X (Enregistrer
Client) étend le cas Y (Prendre
Commande) lorsque X peut être
appelé au cours de l’exécution du
cas d’utilisation Y
PARTIE 1
Figure 18 : Exemple DCU avec relation <<extend>>
Copyright - Tout droit réservé - OFPPT 70
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation entre cas d’utilisation
Point d’extension
▪ L'extension peut intervenir à un point précis du cas étendu (cas de base). Ce point s'appelle le point d'extension.
▪ Il porte un nom, qui figure dans un compartiment du cas étendu sous la rubrique points d'extension (extension points en
Anglais), et est éventuellement associé à une contrainte {…} indiquant le moment où l'extension intervient.
▪ Une extension est souvent soumise à condition. Graphiquement, la condition est exprimée sous la forme d'une note.
▪ Exemple : Dans un système e-banking, la vérification du solde du compte n'intervient que si la demande du montant
dépasse 200 Dhs.
Nom du point
d’extension
Contrainte
associée au point
d’extension
PARTIE 1
Figure 19 : Exemple Point d’extension sur un cas d’utilisation
Copyright - Tout droit réservé - OFPPT 71
CHAPITRE 2
Modéliser les besoins client par un
diagramme de cas d’utilisation
1. Introduction au langage de modélisation UML
2. Définition du diagramme des cas d’utilisation
3. Acteurs
4. Cas d’utilisation
5. Relation entre acteurs et cas d’utilisation
6. Relations entre cas d’utilisation
7. Relation de généralisation ou de spécialisation
8. Description textuelle des cas d’utilisation
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation de généralisation ou de spécialisation
Relation de généralisation/spécialisation entre acteurs
▪ Un acteur A est une généralisation d'un acteur B si l'acteur A peut être remplacé par l'acteur B. Dans ce cas, tous les cas
d'utilisation accessibles à A le sont aussi à B, mais l'inverse n'est pas vrai.
Acteur A
Généralisation
Acteur B
Exemple
PARTIE 1
• Le directeur des ventes est un préposé aux commandes
avec un pouvoir supplémentaire : en plus de pouvoir
passer et suivre une commande, il peut gérer le stock.
Par contre, le préposé aux commandes ne peut pas Figure 20 : Relation de généralisation entre acteurs concrets
gérer le stock.
Copyright - Tout droit réservé - OFPPT 73
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation de généralisation ou de spécialisation
Relation de généralisation/spécialisation entre acteurs
▪ Dans certaines situations, il arrive que deux acteurs, ou plus, présentent des similitudes dans leurs relations aux cas
d’utilisation.
▪ On peut l’exprimer en créant un acteur généralisé, éventuellement abstrait, qui modélise les aspects communs aux
différents acteurs concrets. Cette relation se traduit par le concept d'héritage dans les langages orientés objet.
Bonne Pratique
• Les deux acteurs principaux Client et Visiteur
partagent deux cas d’utilisation Chercher des
ouvrages et Gérer son panier
• Dans l’exemple, l’acteur Internaute est la
généralisation abstraite des rôles Visiteur et
Client.
PARTIE 1
Figure 21 : Acteur généralisé abstrait
Copyright - Tout droit réservé - OFPPT 74
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation de généralisation ou de spécialisation
Relation de généralisation/spécialisation entre cas d’utilisation
▪ Un cas d’utilisation A est une généralisation d'un cas d’utilisation B si B est un cas particulier de A.
▪ Exemple : « Faire un virement par Internet » est un cas particulier de « Faire un virement ».
PARTIE 1
Figure 22 : Généralisation entre cas d’utilisation
Copyright - Tout droit réservé - OFPPT 75
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Relation de généralisation ou de spécialisation
Exemple complet avec tous les types de relation
Relation d’inclusion
PARTIE 1
Relation de généralisation
Relation d’extension
Figure 23 : DCU d’un système de borne en ligne d’une banque (e-banking)
Copyright - Tout droit réservé - OFPPT 76
CHAPITRE 2
Modéliser les besoins client par un
diagramme de cas d’utilisation
1. Introduction au langage de modélisation UML
2. Définition du diagramme des cas d’utilisation
3. Acteurs
4. Cas d’utilisation
5. Relation entre acteurs et cas d’utilisation
6. Relations entre cas d’utilisation
7. Relation de généralisation ou de spécialisation
8. Description textuelle des cas d’utilisation
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Description textuelle des cas d’utilisation
Documentation 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. Il est recommandé de rédiger une description
textuelle de chaque cas d’utilisation
▪ Une description textuelle du cas d’utilisation se compose de trois parties :
Décrire les
Identifier le cas
Décrire les scénarios exigences non
d’utilisation
fonctionnelles
PARTIE 1
Copyright - Tout droit réservé - OFPPT 78
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Description textuelle des cas d’utilisation
Identification du cas d’utilisation
Identifier un cas d’utilisation par les informations suivantes :
• Nom : utiliser un verbe à l'infinitif (ex. : Consulter le solde de compte)
• Objectif : une description résumée permettant de comprendre l'intention
principale du cas d'utilisation.
• Acteurs principaux : ceux qui vont réaliser le cas d'utilisation.
• Acteurs secondaires : ceux qui ne font que recevoir des informations à l'issue de la
réalisation du cas d'utilisation.
• Dates : les dates de création et de mise à jour de la description courante.
• Responsable : le nom des responsables.
• Version : le numéro de version.
PARTIE 1
Copyright - Tout droit réservé - OFPPT 79
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Description textuelle des cas d’utilisation
Description des scénarios
Décrire un cas d’utilisation :
• Pré-conditions : définissent ce qui doit être vrai en amont du cas d’utilisation pour que
celui-ci puisse démarrer. Elles ne sont pas testées à l’intérieur du cas d’utilisation, mais
sont tenues pour acquises.
• Des scénarii : ces scénarii sont décrits sous forme d'échanges de messages entre l'acteur
et le système. On distingue le scénario nominal, qui se déroule quand il n'y a pas d'erreur,
des scénarii alternatifs qui sont les variantes du scénario nominal et enfin les scénarii
d'exception qui décrivent les cas d'erreurs.
• Post-conditions : définissent ce qui doit être vrai lorsque le cas d’utilisation se termine
PARTIE 1
avec succès, soit pour le scénario nominal ou pour le scénario alternatif
Copyright - Tout droit réservé - OFPPT 80
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Description textuelle des cas d’utilisation
Exigences non fonctionnelles
▪ C’est une rubrique optionnelle.
▪ Elle se rapporte spécifiquement à un cas d’utilisation plutôt qu’au système dans sa totalité
▪ Elle contient généralement des spécifications non fonctionnelles (spécifications techniques,…).
▪ Typiquement, pour un site web, il s’agira de performance, de sécurité ou d’ergonomie.
▪ On complètera par exemple la description des scénarios par des copies d’écran de la maquette
PARTIE 1
Copyright - Tout droit réservé - OFPPT 81
02 - Modéliser les besoins client par un diagramme
de cas d’utilisation
Description textuelle des cas d’utilisation
Exemple : documenter le cas d’utilisation « S’authentifier »
▪ Cas d’utilisation : S’authentifier
▪ Acteurs : Administrateur et autres utilisateurs.
▪ Objectif : Il permet à l’acteur de s’identifier en saisissant son login et mot de passe.
▪ Pré-condition : La connexion avec le système est opérationnelle.
▪ Post-condition :
• Acteur authentifié.
• La page d’accueil s’affiche.
▪ Scénario nominal : ▪ Scénario alternatif :
1. L’acteur ouvre l’application, 4.a. Erreur d’authentification : login ou mot de passe non valide.
2. Le système affiche la page d’authentification, 5. Le système affiche un message d’erreur.
3. L’acteur saisit le login et le mot de passe, Le scénario reprend au point 2.
4.b. Champs obligatoires vides.
4. Le système vérifie l’existence des données,
PARTIE 1
Le scénario reprend au point 2.
5. Le système affiche la page d’accueil.
▪ Exigences non fonctionnelles : Au bout de 3 tentatives échouées d’authentification, le système affiche un message de
verrouillage d’accès à durée limitée.
Copyright - Tout droit réservé - OFPPT 82