UML Part2- diagramme des uses cases_mansouri

1. Université Hassan II de Casablanca
ENSET de Mohammedia
Département Mathématiques et Informatique
COURS
INGENIERIE SYSTEMES
2ème Partie :
Diagramme des Uses Cases
« Diagramme de cas d'utilisation »
Professeur :
M. Khalifa MANSOURI

2. 09/10/2017
2
Diagrammes Use Cases : Cas d’utilisation
Introduction
• Ce diagramme est l’apport de Ivar Jacobson à UML.
• La phase d’analyse des besoins nécessite :
– de comprendre les besoins à couvrir
– d’exprimer et de formaliser les besoins
• C’est le premier diagramme d’UML, il est utilisé dans l’activité de
spécification de besoins.
• Il assure la relation et les interactions possibles entre les utilisateurs et
les objets du système.
• Constat : Le système existe pour servir ses utilisateurs
• Cas d’utilisation (use cases) [Jacobson 92] = La description du comportement du
système du point de vue de son utilisateur
• Le Cas d’utilisation :
– facilite la structuration des besoins des utilisateurs
– représentation simple et expressive
– exprime les limites et les objectifs du système
– Permet de définir les limites du système et ses relations avec l’environnement
– Décrit, sous forme d’actions et de réactions, le comportement d’un système du
point de vue d’un utilisateur
– Sert à modéliser les aspects dynamiques d'un système (Contrairement aux
diagrammes de classes).
– Fait ressortir les acteurs et les fonctions offertes par le système.
– Utilisé pour modéliser les exigences (besoins) du client

3. 09/10/2017
3
Diagrammes Use Cases : Cas d’utilisation
Introduction
• Il fragmente l’objectif global du système en unités cohérentes ayant un sens
pour l’utilisateur. Il s’agit des cas d’utilisation (use cases).
• Il ne faut pas trop décomposer les cas d’utilisation pour ne pas retrouver une
décomposition fonctionnelle descendante hiérarchique .
• Il est courant d’avoir une quinzaine de cas d’utilisation, comprenant
chacun une dizaine de scénarios
• Le diagramme de cas d’utilisation n’est pas une fin en soi, mais il permet de:
• aider à démarrer l’analyse orientée objet en identifiant les classes candidates.

4. 09/10/2017
4
Diagrammes Use Cases : Cas d’utilisation
Introduction
• La maitrise d’ouvrage et l’utilisateur ont des connaissances modestes en
informatique :
• Le diagramme de cas d’utilisation permet d’exprimer, de recenser,
d’organiser et de représenter les principales fonctionnalités du système
nécessaires aux utilisateurs.
• Il représente, graphiquement , le comportement de tout le système, d’une
partie du système, d’une classe ou d’un composant.
• Le diagramme de cas d’utilisation c’est une vision orientée utilisateur. Il
répond à « qui fait quoi? ».
Nécessité de produire ce diagramme
pour réaliser
un logiciel conforme aux attentes des utilisateurs

5. 09/10/2017
5
Eléments des diagrammes de cas d’utilisation
• Comporte plusieurs éléments :
• Acteurs
• Cas d'utilisation
• Relations de dépendances, de généralisations et d'associations
• Chaque cas d'utilisation contient un ou plusieurs scénarios
• Les scénarios définissent comment le système devrait interagir avec les acteurs
pour atteindre un but ou une fonction spécifique d'un travail

6. 09/10/2017
6
Eléments des diagrammes de cas d’utilisation
Système de gestion des ventes
• Les éléments clés associés au cas d’utilisation sont:
Compléter le
bon de
commande
Consulter la
fiche produit
Imprimer la
facture
Sauvegarder la
base de
données
Vendeur
Administration
Administrateur
de la BD
Système de
ICloud
Le sujet étant le
système qui fait
l’objet de l’étude
Un rôle est associé à
l’acteur
Acteur
Cas d’utilisation

7. 09/10/2017
7
Eléments des diagrammes de cas d’utilisation :
Acteur
• UML n’emploi pas le terme d’utilisateur mais d’acteur.
• Acteur :
 Un acteur est l’idéalisation d’un rôle joué par une personne externe, un
processus ou une élément qui interagit avec un système (Comptabilité,
service commercial, …), en échangeant de l’information (en entrée et en
sortie)
 Le terme acteur ne désigne pas seulement des utilisateurs humains mais
également les autres systèmes (machines, programmes, …)
Remarques :
• La même personne physique peut jouer le rôle de plusieurs acteurs (Chef
d’agence est un client de la banque).
• D’autres part, plusieurs personnes peuvent jouer le même rôle, et donc agir
comme un même acteur (plusieurs personnes peuvent jouer le rôle
d’administrateur).

8. 09/10/2017
8
Eléments des diagrammes de cas d’utilisation :
Acteur
 Un acteur se représente par un petit bonhomme avec son nom inscrit
dessous :
Client
Exemple de représentation d’un acteur
 Il est également possible de représenter un
acteur sous la forme d’un classeur stéréotypé
<< actor >>
Une autre manière de représentation d’ un acteur

9. 09/10/2017
9
Eléments des diagrammes de cas d’utilisation :
Acteur
 Les acteurs peuvent être de trois types :
 Humains : utilisateurs du logiciel à travers son interface graphique,
par exemple.
 Logiciels : disponibles qui communiquent avec le système grâce à une
interface logicielle
 Matériels : exploitant les données du système ou qui sont pilotés par
le système (Imprimante, robots, automates, …)
Secrétaire
Etudiant
Système de Gestion
Scolaire
<<acteur>>
Imprimante
<<acteur>>
Site Web de l'établissement

10. 09/10/2017
10
Eléments des diagrammes de cas d’utilisation :
Acteur
• Mais du point de vue système on distingue deux types :
 Acteurs principaux : utilisent les fonctions principales du système. Par
exemple, le client pour un distributeur de billets.
C’est celui pour qui le cas d’utilisation produit un résultat observable
C’es aussi celui qui déclenche le cas d’utilisation et par la suite toutes les
échanges nécessaires pour réaliser le cas d’utilisation
 Acteurs secondaires : effectuent des tâches administratives ou de
maintenance. Par exemple, la personne qui recharge la caisse contenue dans
le distributeur.
Sont souvent sollicités pour des informations complémentaires; ils peuvent
uniquement consulter ou informer le système lors de l’exécution du cas
d’utilisation.
Client Banque
Payer par
carte
« Secondaire »
dans la mesure du possible, disposez les acteurs principaux à gauche des cas d’utilisation
et les acteurs secondaires à droite.

11. 09/10/2017
11
Eléments des diagrammes de cas d’utilisation :
Acteur
Comment identifier les acteurs ?
 Qui est intéressé par un certain besoin ?
 Par qui le système est utilisé dans l’organisation?
 Qui bénéficiera de l’utilisation du système ?
 Qui fournira au système l’information, qui l’utilisera et qui la maintiendra ?
 Qui va supporter et maintenir le système ?
 Quelque chose est il produite automatiquement par le système?
Attention !
• Un acteur correspond à un rôle et pas à une personne physique
• Une même personne physique peut être représentée par plusieurs acteurs si
elle joue plusieurs rôles
• Si plusieurs personnes jouent le même rôle, il sont représentées par le même
acteur
• Un acteur n’est pas forcément humain

12. 09/10/2017
12
Eléments des diagrammes de cas d’utilisation :
Acteur
 Un acteur peut être une
spécialisation d'un autre acteur
déjà défini.
 Dans ce cas, on utilise la relation
de généralisation/spécialisation.
Acteur général
Acteur spécialisé

13. 09/10/2017
13
Eléments des diagrammes de cas d’utilisation
Vendeur
Administration
Administrateur
de la BD
Logiciel de
Comptabilité
Une personne
Une organisation
Une personne
Un système
externe
Un autre
logiciel
Système de
ICloud
« Actor »
rôle
Stéréotype
Rôle
Acteur
Personnage
stylisé
« Actor »
Vendeur
« Actor »
Administration
« Actor »
Admin BD
« Actor »
Logiciel Compta
« Actor »
System Icloud

14. 09/10/2017
14
Eléments des diagrammes de cas d’utilisation :
Acteur
Vendeur
Administration
Administrateur
de la BD
Logiciel de
Comptabilité
La représentation graphique classique de l’acteur
peut être remplacée par une autre plus significative
Système de
ICloud
Acteur

15. 09/10/2017
15
Eléments des diagrammes de cas d’utilisation : Cas
d’utilisation
 Cas d’utilisation
 Un cas d’utilisation est une unité cohérente représentant une fonctionnalité
visible de l’extérieur.
 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 modélise donc un service rendu par le système, sans
imposer le mode de réalisation de ce service.
 Un cas d’utilisation se représente par une ellipse en trait plein contenant le nom
du cas (un verbe à l’infinitif), et optionnellement, au-dessus du nom, un
stéréotype.
Nom du cas
<<use case>>
 Dans le cas où l’on désire présenter les attributs ou les opérations du cas
d’utilisation, il est préférable de le représenter sous la forme d’un classeur
stéréotypé << use case >>..
Nom Cas Utilisation

16. 09/10/2017
16
Eléments des diagrammes de cas d’utilisation : Cas
d’utilisation
Les cas d’utilisations
 Permettent de modéliser les attentes (besoins) des utilisateurs
 Représentent les fonctionnalités du système
 Suite d’événements, initiée par des acteurs, qui correspond à une utilisation
particulière du système
 L’image d’une fonctionnalité du système, déclenchée en réponse à la stimulation
d’un acteur externe.
 servent à spécifier les fonctionnalités métiers du système futur sans spécifier
comment elles vont être faites.
 représente un ensemble de séquences d’actions réalisées par le système et
produisant un résultat observable intéressant pour un acteur particulier.
 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é.
 Un cas d’utilisation c’est un verbe à l’infinitif suivi d’un complément
 Un cas d’utilisation est exprimé selon le point de vue acteur et non celui de système
Par exemple, le cas d’utilisation d’un distributeur de billets par l’acteur « Porteur de
CB » doit être intitulé « Retirer de l’argent » (point de vue de l’acteur), et non «
Distribuer de l’argent » (point de vue du système).

17. 09/10/2017
17
Eléments des diagrammes de cas d’utilisation : Cas
d’utilisation
Identification des 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,
• à quelles fonctionnalités il doit avoir accès.
• Pour chaque acteur, il convient de :
• Rechercher les différentes intentions avec lesquelles il utilise le système
• Déterminer dans le cahier des charges les services fonctionnels attendus du
système
• Les cas d’utilisation sont repérés à partir du cahier du charge
• Il n’y a pas une manière unique et totalement objective de repérer les cas d’utilisation

18. 09/10/2017
18
Eléments des diagrammes de cas d’utilisation : Cas
d’utilisation
Identification des cas d’utilisation
• Pour chaque cas d’utilisation candidat il faut :
• Vérifier qu’il fournit une valeur ajoutée « notable » à l’acteur, toujours dans le
cadre de son métier,
• contrôler qu’un événement externe au système en déclenche l’exécution
(sauf exceptionnellement pour des traitements « batch », comme la transmission
comptable vers un SAP).
• Quelles sont les tâches de chaque acteur?
• Est-ce qu’un acteur crée, enregistre, modifie, enlève ou consulte une information dans
le système?
• Quel cas d’utilisation sera responsable de ces tâches?
• 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 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.
• Il ne doit pas y avoir de notion temporelle dans un diagramme de cas d’utilisation
(sera pris en compte dans le diagramme de séquence par exemple pour décrire le
scénario).

19. 09/10/2017
19
Eléments des diagrammes de cas d’utilisation : Cas
d’utilisation
Exemple d’un diagramme cas d’utilisation
Client de la banque
Employé de caisse
Agent de maintenance
Retirer de l’argent
Déposer de l’argent
Effectuer un virement
entre comptes
Consulter le sole
d’un compte
Ravitailler
le distributeur
Réparer
le distributeur

20. 09/10/2017
20
Relations dans les diagrammes de cas d’utilisation
Après avoir identifié les acteurs et les cas d'utilisation, il est utile
de restructurer l'ensemble des cas d'utilisation que l'on a fait
apparaître afin de rechercher les :
• Comportements partagés
• Cas particuliers, exceptions, variantes
• Généralisations/spécialisations.

21. 09/10/2017
21
Relations dans les diagrammes de cas d’utilisation
Relations entre acteurs et cas d’utilisation
Diagramme de cas d’utilisation représentant un logiciel de partage de fichiers
 Une relation d’association est chemin de communication entre un acteur
et un cas d’utilisation et est représenté un trait continu

22. 09/10/2017
22
Relations dans les diagrammes de 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. Le symbole : *
signifie plusieurs , exactement n s’écrit tout simplement n, n..m signifie entre n et m, etc.
 La notion de multiplicité n’est pas propre au diagramme de cas d’utilisation. Elle est
relative au diagramme de classes.
 Acteurs principaux et secondaires
 Un acteur est qualifié de principal pour un cas d’utilisation lorsque ce cas rend service à
cet acteur.
 Les autres acteurs sont alors qualifiés de secondaires.
 En général, l’acteur principal initie le cas d’utilisation par ses sollicitations.
 Le stéréotype<< primary >> vient orner l’association reliant un cas d’utilisation à son
acteur principal,
 le stéréotype << secondary >> est utilisé pour les acteurs secondaires.
 Cas d’utilisation interne
 Quand un cas n’est pas directement relié à un acteur, il est qualifié de cas d’utilisation
interne.

23. 09/10/2017
23
Relations dans les diagrammes de 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és sont l’inclusion et l’extension),
• la généralisation/spécialisation.
 Une dépendance se représente par une flèche avec un trait
pointillé. Si le cas A inclut ou étend le cas B, la flèche est dirigée
de A vers B.
 Le symbole utilisé pour la généralisation est un flèche avec un
trait pleins dont la pointe est un triangle fermé désignant le cas
le plus général

24. 09/10/2017
24
Relations dans les diagrammes de cas d’utilisation
 Exemple de diagramme use case:

25. 09/10/2017
25
Relations dans les diagrammes de cas d’utilisation
On peux définir trois types de relations 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

26. 09/10/2017
26
Relations dans les diagrammes de cas d’utilisation
Passer
commande
Client
Authentification
Imprimer le BC
Relations entre cas d’utilisation: Inclusion, Extension, Généralisation
Imprimer

27. 09/10/2017
27
Relations dans les diagrammes de cas d’utilisation
Relation : Inclusion
 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 sont utilisés par les cas d'utilisation qui les avaient
en commun.
Un cas A inclut un cas B si le comportement décrit par le cas A inclut le comportement du cas B :
le cas A dépend de B.
 Lorsque A est sollicité, B l’est obligatoirement, comme une partie de A.
 Cette dépendance est symbolisée par le stéréotype << include >>.
 Les inclusions permettent essentiellement de factoriser une partie de la description d’un cas
d’utilisation qui serait commune à d’autres cas d’utilisation.
 Les inclusions permettent également de décomposer un cas complexe en sous-cas plus simples.
• A inclut B : le cas A inclut obligatoirement le comportement définit par le cas B; permet de
factoriser des fonctionnalités partagées
• Le cas d'utilisation pointé par la flèche (dans notre cas B) est une sous partie de l'autre cas
d'utilisation (A, dans notre exemple).
<<include>>
A
B

28. 09/10/2017
28
Relations dans les diagrammes de cas d’utilisation
Relation : Inclusion
<<include>>
<<include>>
<<include>>
<<include>>
Retirer de l'argent
Déposer de l'argent
Effectuer des virements
Consulter solde
S'authentifier
Les cas d'utilisation "Déposer de l'argent",
"Retirer de l'argent", "Effectuer des
virements" et "Consulter solde"
incorporent de façon explicite le cas
d'utilisation "S'authentifier", à un endroit
spécifié dans leurs enchaînements.
 Le cas « retirer de l’argent » inclut l’identification
 Le cas « déposer de l’argent » inclut aussi l’identification

29. 09/10/2017
29
Relations dans les diagrammes de cas d’utilisation
Relation : Inclusion
Passer
commande
Valider panier
• Quand un cas d’utilisation est assez complexe (beaucoup d’interactions avec le
système), on procède à le décomposer en cas plus simples.
S’authentifier
Payer

30. 09/10/2017
30
Relations dans les diagrammes de cas d’utilisation
Relation : Inclusion
On utilise cette relation pour éviter de décrire plusieurs fois un
même enchaînement d'actions. Ainsi, on est amené à factoriser
un comportement commun à plusieurs cas d'utilisation dans un
cas d'utilisation à part.
Remarques :
• La relation include n’a pour seul objectif que de factoriser une
partie de la description d’un cas d’utilisation qui serait commune
à d’autres cas d’utilisation.
• Le cas d’utilisation inclus dans les autres cas d’utilisation n’est
pas à proprement parlé un vrai cas d’utilisation car il n’a pas
d’acteur déclencheur ou receveur d’évènement. Il est juste un
artifice pour faire de la réutilisation d’une portion de texte.

31. 09/10/2017
31
Relations dans les diagrammes de cas d’utilisation
Relation : Inclusion
Résumé :
• Une instance du cas source inclut obligatoirement le
comportement décrit par le cas d’utilisation destination
• Permet de décomposer des comportements et de définir les
comportements partagées entre plusieurs cas d’utilisation
▬► Factoriser

32. 09/10/2017
32
Relations dans les diagrammes de cas d’utilisation
Relation : Extension
 On dit qu’un cas d’utilisation A étend un cas d’utilisation B lorsque le cas
d’utilisation A peut être appelé au cours de l’exécution du cas d’utilisation B.
 Exécuter B peut éventuellement entraîner l’exécution de A : contrairement
à l’inclusion, l’extension est optionnelle. Cette dépendance est symbolisée
par le stéréotype << extend >>.
 L’extension peut intervenir à un point précis du cas étendu. Ce point
s’appelle le point d’extension.
• Il porte un nom, qui figure dans un compartiment du cas étendu sous la
rubrique point d’extension,
• et il 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.

33. 09/10/2017
33
Relations dans les diagrammes de cas d’utilisation
Relation : Extension
 Le CU source (B) ajoute, sous certaines conditions, son comportement au CU
destination (A)
 En d’autres termes, le CU B peut être appelé au cours de l’exécution du CU A
 Le comportement ajouté s’insère au niveau d’un point d’extension définit dans
le CU destination
 Le cas d'utilisation de base (destination) peut fonctionner tout seul, mais il peut
également être complété par un autre cas d'utilisation, sous certaines conditions,
et uniquement à certains points particuliers de son flot d'événements (points
d'insertion).
 On utilise principalement cette relation pour séparer le comportement
optionnel (les variantes) du comportement obligatoire.
<<extend>>
B
A
Point d'insertion

34. 09/10/2017
34
Relations dans les diagrammes de cas d’utilisation
Relation : Extension
Exemple :
Au moment de l'authentification, il se peut que le guichet retient la
carte.
<<extend>>
Retenir la carte
S'authentifier

35. 09/10/2017
35
Relations dans les diagrammes de cas d’utilisation
Relation : Extension
Mettre à jour un
bon de
commande
client
Afficher un bon
de commande
• On utilise principalement cette relation pour séparer le comportement
optionnel (les variantes) du comportement obligatoire.
• Le cas d’utilisation A est complété par le cas d’utilisation B.
• Le cas d’utilisation A décrit la fonctionnalité de base, le cas d’utilisation B
spécifie les extensions.
• Le cas d’utilisation A peut être exécuté seul ou avec les extensions.
A: Cas principal
B: Cas d’extension

36. 09/10/2017
36
Relations dans les diagrammes de cas d’utilisation
Relation : Extension

37. 09/10/2017
37
Relations dans les diagrammes de cas d’utilisation
Relation : d'héritage
 Il peut également exister une relation d'héritage entre cas d'utilisation.
 Cette relation exprime une relation de spécialisation/généralisation au sens
classique.
 Exemple :
Dans un système d'agence de voyage, un acteur "Touriste" peut participer à un
cas d'utilisation de base qui est "Réserver voyage", qui suppose par exemple, des
interactions basiques au comptoir de l'agence. Une réservation peut être réalisée
par téléphone ou par Internet.
• On voit qu'il ne s'agit pas d'une relation "extend", car la réservation par
Internet n'étend pas les interactions ni les fonctionnalités du cas d'utilisation
"Réserver voyage".
• Les deux cas d'utilisation "Réservation 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/spécialisation.

38. 09/10/2017
38
Relations dans les diagrammes de cas d’utilisation
Relation : d'héritage
 Exemples : Reserver voyage
Réserver voyage par téléphone Réserver voyage par Internet
Payer
client
Payer par carte
• Un virement est un cas particulier de paiement.
• Un virement est une sorte de paiement.
Payer par
virement

39. 09/10/2017
39
Relations dans les diagrammes de cas d’utilisation
Relation : d'héritage
 Exemples : Exemple : Un client peut consulter le compte via internet ou via
un Guichet Automatique Bancaire
 Un cas A est une généralisation d’un cas B si B est un cas particulier de A.
 Dans la figure , la consultation d’un compte via Internet est un cas particulier
de la consultation.
 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.

40. 09/10/2017
40
Relations dans les diagrammes de cas d’utilisation
Relations entre cas d’utilisation : Exercice
Un client peut effectuer un retrait bancaire. Le
retrait peut être effectué sur place ou par
Internet. Le client doit être identifié (en
fournissant son code d’accès) pour effectuer un
retrait, mais si le montant dépasse 500DH, la
vérification du solde de son compte est
réalisée.

41. 09/10/2017
41
Relations dans les diagrammes de cas d’utilisation
Relations entre cas d’utilisation : Solution
<<include>>
<<extend>>Virement
Virement par Internet
Virement sur place
Identification
Vérification solde compte
Client distant
Client local
Montant > 500 DH

42. 09/10/2017
42
Relations dans les diagrammes de cas d’utilisation
Relations entre acteurs
 La seule relation possible entre deux acteurs est la généralisation : un acteur A est
une généralisation d’un acteur B si l’acteur A peut être substitué 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.
 Le symbole utilisé pour la généralisation entre acteurs est une flèche avec un trait
plein dont la pointe est un triangle fermé désignant l’acteur le plus général.
 Par exemple, 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 gérer le stock.

43. 09/10/2017
43
Etapes de création d’un cas d’utilisation
Spécifier le sujet
Identifier les acteurs
Identifier les cas
d’utilisation
Identifier les relations

44. 09/10/2017
44
Etapes de création d’un 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 auxquels 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)

45. 09/10/2017
45
Cas d’utilisation et scénario
• Le système = ensemble de cas d’utilisation
• Le système possède les cas d’utilisation mais pas les
acteurs
• Un cas d’utilisation = ensemble de « chemins d’exécution »
possibles
• Un scénario
– Est un chemin particulier d’exécution
– Est une séquence d’événements
• Un scénario = Instance de cas d’utilisation
• Une instance d’acteur crée un scénario
• un scénario peut être représenté par un « diagramme de
séquence » qui décrit un échange particulier entre un ou
plusieurs acteurs et le système :

46. 09/10/2017
46
Cas d’utilisation et scénario
• Il représente une séquence d’interactions entre le système et ses acteurs.
• Il décrit une exécution particulière d’un cas d’utilisation du début à la fin.
• Chaque unité de description de séquences d’actions est appelée
enchaînement.
• Un scénario représente une succession particulière d’enchaînements, qui
s’exécute du début à la fin du cas d’utilisation.
• Un cas d’utilisation contient en général :
• Un début et une fin clairement définies
• Les différentes variantes des scénarios (nominal, alternatif, d’erreur)
• Les messages échangés pendant les interactions
• L’acteur principal d’un cas d’utilisation dispose donc de l’ensemble des
enchaînements pour réaliser une certaine tâche métier

47. 09/10/2017
47
Cas d’utilisation vers Scénario
Rôle acteur
UC
: ClasseActeur :Classe
Diagramme de cas d’utilisation
Diagramme de séquences : Scénario
Instance

48. 09/10/2017
48
Exemple de scénario décrit par un diagramme de
séquences
: Client :GAB
Carte bancaire
Code ?
Code
Menu action ?
Action Retrait
montant
Carte et argent
Compte
solvable

49. 09/10/2017
49
Cas d’utilisation : Exercices
EXERCICE 1 : Enoncé
Créer un diagramme de cas d’utilisation pour le problème suivant :
– 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.

50. 09/10/2017
50
Cas d’utilisation : Exercices
EXERCICE 1 : Solution

51. 09/10/2017
51
Cas d’utilisation : Exercices
EXERCICE 2 : Enoncé
Créer un diagramme de cas d’utilisation pour le problème suivant :
On considère le système suivant de gestion d’un DAB (Distributeur automatique
de billets) :
le distributeur délivre de l’argent à tout porteur de carte (carte Visa ou carte de
la banque)
pour les clients de la banque, il permet :
•la consultation du solde du compte
•Retirer de l`argent
•le dépôt d’argent (chèque ou numéraire)
Un porteur de carte visa peut consulter son solde et retirer de l`argent
toute transaction est sécurisée et nécessite par conséquent une authentification
dans le cas où une carte est avalée par le distributeur, un opérateur de
maintenance se charge de la récupérer. C’est la même personne qui collecte
également les dépôts de chèques et qui recharge le distributeur.

52. 09/10/2017
52
Cas d’utilisation : Exercices
EXERCICE 2 : Solution

53. 09/10/2017
53
Cas d’utilisation : Exercices
EXERCICE 3 : Enoncé
 Le déroulement normal d’utilisation d’un distributeur automatique de
billets est le suivant :
• le client introduit sa carte bancaire
• la machine vérifie alors la validité de la carte et demande le code au client
• si le code est correct, elle envoie une demande d’autorisation de
prélèvement au groupement de banques. Ce dernier renvoie le solde
autorisé à prélever.
• le distributeur propose alors plusieurs montants à prélever
• le client saisit le montant à retirer
• après contrôle du montant par rapport au solde autorisé, le distributeur
demande au client s’il désire un ticket
• après la réponse du client, la carte est éjectée et récupérée par le client
• les billets sont alors délivrés (ainsi que le ticket)
• le client récupère enfin les billets et son ticket
 Modéliser cette situation à l’aide d’un diagramme de séquence en ne
prenant en compte que le cas où tout se passe bien. NB : on identifiera
les scénarios qui peuvent poser problème en incluant des commentaires
dans le diagramme

54. 09/10/2017
54
Cas d’utilisation : Exercices
EXERCICE 1 : Solution

55. 09/10/2017
55
Cas d’utilisation : Exercices
EXERCICE 4 : Enoncé

56. 09/10/2017
56
Cas d’utilisation : Exercices
EXERCICE 4 : Solution
<<include>>
<<include>>
<<include>>
<<include>> <<extend>>
Client
Agent
Technicien
Déposer de l'argent
Retirer de l'argent
Consulter le solde
Effectuer des virements entre comptes
Ravitailler
Réparer
S'authentifier
Retenir la carte
Fournir un login et un mot
de passe