1. Modélisation des SI avec UML
-DIAGRAMME DES CAS D’UTILISATION-
PRÉPARÉ PAR: AMINE SENNOUNI
ENCADRÉ PAR: PR.BOUBKER SBIHI

2. Plan
2
 Introduction: UML
 Définitions
Diagramme de cas
 Acteur
 Cas d'utilisation
 Associations et cas d'utilisation
 Exercice d’application
 Conclusion

3. Introduction: UML
3
 UML permet de construire plusieurs modèles d’un système : certains
montrent le système du point de vue des utilisateurs, d’autres montrent
sa structure interne, d’autres encore en donnent une vision globale ou
détaillée. Les modèles se complètent et peuvent être assemblés.
 Ils sont élaborés tout au long du cycle de vie du développement d’un
système (depuis le recueil des besoins jusqu’à la phase de conception).
Dans cet exposé, nous allons étudier l’un des modèles , en l’occurrence
le premier à construire : le diagramme de cas d’utilisation.
 Il permet de recueillir, d’analyser et d’organiser les besoins. Avec lui
débute l’étape d’analyse d’un système.

4. UML: Diagramme de cas
4
Les diagrammes de cas
d'utilisation sont des diagrammes
UML utilisés pour donner une vision
globale du comportement fonctionnel d'un
système Logiciel
Ils sont utiles pour des
présentations auprès de Un cas d'utilisation
la direction ou des représente une unité
acteurs d'un projet, mais discrète d'interaction
pour le développement, entre un utilisateur
les cas d’utlisation sont (humain ou machine)
plus appropriés. et un système.

5. Diagramme de cas
5
Vue Vue
logique implémentation
diagrammes de classes diagrammes de composantes
diagrammes d'objets
Vue utilisateur
diagrammes de cas
diagrammes d'états
diagrammes d'activités diagrammes de déploiement
diagrammes de séquence
diagrammes de collaboration
Vue Vue
comportement déploiement

6. Définition
6
Définition des cas d’utilisation («use cases»)
 Permettent d’impliquer les utilisateurs dès les premiers stades
du développement pour exprimer leurs besoins.
 Décrivent les fonctionnalités offertes par le système (le
« quoi? » avant le « comment? ») :
 délimitation du système par l’ensemble des fonctions
qu’il offre,
 relations avec son environnement (acteurs).
 Modélisent à la fois les traitements (fonctionnalités) et les
communications (interactions) ≠ acteurs/flux de Merise.
Utilisables pour tout projet
indépendamment d’UML et de l’approche objet.

7. Définitions
7
Acteurs et cas
 Acteur : personne ou système qui interagit avec le
système étudié en échangeant de l’information.
Ex: utilisateurs directs du système (bénéficiaires des services),
responsables de son fonctionnement (ex: administrateur), autres
systèmes qui interagissent avec lui…
 Un acteur représente un rôle. La même personne
physique peut jouer le rôle de plusieurs acteurs et
plusieurs personnes physiques peuvent jouer le même
rôle et donc agir comme un même acteur.
 Cas : interaction avec le système par un acteur dans
une certaine intention; un service rendu par le
système; une fonctionnalité.

8. Diagrammes de cas d’utilisation
8
 Décrivent les interactions entre les acteurs et le
système représenté comme un ensemble de cas.
 Les interactions sont orientées (avec une flèche) ou
non.
 Découvrons comment ?

9. Diagrammes de cas d’utilisation
9
Groupement éventuel des cas en
Le système paquetage(s)
cas
d’utilisation interaction
X
acteur
acteur humain
Frontière cas
du d’utilisation acteur «<<actor>>
stick
système Y man »
acteur
L’acteur est source et/ou système
destination d’une interaction

10. Diagramme de cas
ACTEURS

11. Acteur
11
 Un acteur est la description d'un ensemble cohérent
de rôles qu'un utilisateur (personne ou système) joue
lorsqu'il interagit avec le système.
 Exemple :
<<acteur>>
Bibliothéquaire
Client

12. Représentation graphique d'un acteur
12
 Un acteur est une classe stéréotypée représentée par
un rectangle avec le stéréotype «acteur» ou par une
icône.
<<acteur>>
Bibliothéquaire
Client

13. Nommer un acteur
13
 Chaque acteur doit avoir un nom qui le distingue des
autres acteurs - Unicité du nom complet (noms des
packages englobant + le nom de l'acteur).
 En pratique les noms de acteurs sont des noms pris
dans le vocabulaire du domaine.
 Il est d'usage de capitaliser la première lettre de
chaque mot.
<<acteur>>
ClientBanque PréposéBanque

14. Types des acteurs
14
Utilisateurs
principaux
(client)
Périphériques
Utilisateurs externes
secondaires ( horloge
(directeur) interne)
Système externes
(système inter-
bancaire)

15. Généralisation entre acteurs
15
 Les acteurs peuvent avoir des associations de
généralisation
 Exemple :
Client
Particulier Entreprise

16. Acteurs vs utilisateurs
16
 Ne pas confondre les 2 notions
 Un acteur décrit un rôle
 Un utilisateur = personne utilisant le système
 Une même personne peut avoir deux rôles
 Maurice, directeur de banque et guichetier
 Plusieurs personnes peuvent avoir le même rôle
 Pierre et Paul sont 2 clients

17. Diagramme de cas
CAS D'UTILISATION

18. Cas d'utilisation
18
 Un cas est est une classe qui représente un ensemble
de fonctions ou de comportements fournis par un
système à un ou des acteurs.(exigences
fonctionnelles du système)
 Exemple :
Signer Contrat Assurance
Acheter Automobile

19. Représentation graphique d'un cas
19
 Un cas est représenté par une ellipse
 un ensemble de cas peut être placé dans un rectangle
qui symbolise le système

20. Nommer un cas
20
 Chaque cas doit avoir un nom qui le distingue des
autres cas - Unicité du nom complet (noms des
packages englobant + le nom du cas).
 En pratique les noms de cas sont des verbes pris
dans le vocabulaire du domaine.
Emprunter Livre
Accorder Crédit

21. Organiser les cas
21
niveau système Service
niveau sous-système Service
niveau classe Opération

22. Cas d’utilisation
22

23. Description du cas d’utilisation
23
Identification
Nom du cas : « Rechercher une vidéo ».
But : décrire les étapes permettant au
client de rechercher une vidéo via le
distributeur automatique.
Acteur principal : XXXX
Acteur secondaire : XXXX
Date de création : le jj/mm/aaaa.
Responsable : M. XXXX
Version : 1.0.

24. La description du cas d’utilisation
24
Chaque cas d’utilisation doit être précisé par une
description textuelle qui peut être structurée en
plusieurs sections :
 conditions au démarrage (pré-conditions),
 conditions à la terminaison (post-conditions),
 étapes du déroulement normal (« nominal »),
 variantes possibles et les cas d’erreurs,
 informations échangées entre acteur et système,
 contraintes non fonctionnelles (performance, sécurité,
disponibilité, confidentialité…).
Exemple : cas RetirerArgentDistributeur

25. Description du cas d’utilisation
25
• contient des billets ; en attente d’une opération : ni en panne, ni en maintenance.
précondition
• si de l’argent a pu être retiré, la somme sur le compte est égale à la somme qu’il y avait
avant moins le retrait. Sinon, la somme sur le compte est inchangée.
postcondition
• (1) le client introduit sa carte bancaire, (2) le système lit la carte et vérifie si la carte est
valide, (3) le système demande au client de taper son code, (4) le client tape son code
confidentiel, (5) le système vérifie que le code correspond à la carte, (6) le client choisit
Déroulement une opération de retrait, (7) le système demande le montant à retirer, etc.
normal

26. Description du cas d’utilisation
26
• (A) Carte invalide : au cours de l’étape (2), si la carte est jugée invalide, le système
affiche un message d ’erreur, rejette la carte et le cas d’utilisation se termine.
• (B) …
variantes
• (A) Performance : le système doit réagir dans un délai inférieur à 4 secondes,
quelque soit l’action de l’utilisateur.
• (B) Sécurité …
contraintes

27. La description du cas d’utilisation
27
 Les cas d’utilisations peuvent être vus comme des
classes de scénarios. Chaque scénario
correspond à une utilisation particulière ou une
manière d’exécution du cas d’utilisation, par un
acteur donné, dans des circonstances données.

28. Un exemple de scénario
28
• Le client insère sa carte dans le
distributeur d2103
Le système accepte la carte et lit le
numéro de compte
Le système demande le code
Le client tape ‘ 1234 ’
Le système indique que ce n’est
pas le bon code
Le système affiche un message et
propose de recommencer
…

29. Diagramme de cas
ASSOCIATIONS ET CAS D'UTILISATION

30. Généralisation
30
 L'association de généralisation entre cas d'utilisation
a la même sémantique que pour les classes
Valider usager
Vérifier Scanner
mot de passe rétine

31. « communique »
31
 La relation communique permet de modéliser les
échanges de messages entre acteurs et cas
d'utilisation
<<communique>>
Cas
Acteur

32. Relations entre cas
32
 A <<include>> B : le cas A inclut obligatoirement
le cas B (permet de décomposer et de factoriser).
 A <<extend>> B : le cas A est une extension
optionnelle du cas B à un certain point de son
exécution.

33. Relations entre cas
33
attention au
Client Commander sens des flèches
<<include>> <<include>>
<<extend>>
Choisir Payer
articles Demander
catalogue
<<xxx>> est un stéréotype UML c’est à dire un moyen de
caractériser et classer des éléments des modèles UML; certains sont
prédéfinis, mais les utilisateurs peuvent en définir d’autres.

34. « étend »
34
 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.
Points d'extension
Traiter une <<étend>>
(établir priorité) Traiter une
commande
commande
Points d'extension
urgente
établir priorité

35. « inclut »
35
 La relation inclut permet de modéliser l'inclusion de
cas d'utilisation pour éviter les répétitions
 Factoriser des sous-fonctions qui sont communes à
d’autres cas d’utilisation
Valider <<inclut>> Traiter une
Utilisateur commande

36. Exercice d’application: Enoncé
36
Modélisez avec un diagramme de cas
d’utilisation le fonctionnement d’une
banque qui interagit avec ses clients. Les
guichetiers créent les comptes, déposent
l’argent des clients dans les comptes, et
peuvent aussi fermer le compte, le
guichetier chef peut en plus de ceci annuler
ce compte. l’opération de dépôt d’argent
peut se faire de deux manières différentes:
en numéraire ou par voie de chèques.

37. Corrigé
37
Créer un compte
Guichetier Déposer
Fermer un compte
numéraire
Déposer de
l’argent sur un
compte
Déposer
chèques
Guichetier Annuler un
Chef compte

38. Explications relatives au corrigé
38
 Un ‘Guichetier Chef’ est un ‘Guichetier’ spécialisé
qui peut faire tout ce que peut faire un Guichetier
et, en plus, il peut annuler un compte.
 L’héritage simplifie le dessin (moins d’interactions
à dessiner).
 ‘Déposer chèques’ et ‘Déposer numéraire’ sont 2
spécialisations de ‘Déposer de l’argent sur un
compte’ (2 manières de faire).

39. Conclusion
39
 L’objectif de cette phase de la modélisation est donc de clairement
identifier les frontières du système et les interfaces qu’il doit offrir à
l’utilisateur. Si cette étape commence avant la conception de
l’architecture interne du système, il est en général utile, quand la
réflexion est suffisamment poussée, de poser les bases de la structure
interne du système, et donc d’alterner analyse des besoins et ébauche
des solutions envisagées.
 Le diagramme de cas d’utilisation est un premier modèle d’un système.
Que savons- nous sur le système après avoir créé ce diagramme ? Sur le
système lui-même, en interne, pas grand-chose à vrai dire. C’est encore
une boîte noire à l’architecture et au mode de fonctionnement interne
inconnus. Donc, a fortiori, à ce stade, nous ne savons toujours pas
comment le réaliser. En revanche, son interface avec le monde qui
l’entoure est partiellement connue : nous nous sommes placés du point
de vue des acteurs pour définir les spécifications fonctionnelles.

40. Références
40
 Ambler, S.W. (2003) The Elements of UML Style , Londres : Cambridge
University Press.
 Cockburn, A. (2001). Rédiger des cas d'utilisations efficaces , Paris : Eyrolles.
(voir aussi http://alistair.cockburn.us/ ) -Consulté le 24/12/2012-
 C. Larman, UML 2 et les Design Patterns, 2005, Campus Press.
 A. Cockburn, Rédiger des cas d’utilisation efficaces, 2002, Eyrolles.
 G. Overgaard, K. Palmkvist, Use Cases - Patterns and Blueprints, 2004,
Addison Wesley
 E. Yourdon, Managing Software Reqs - A Use Case Approach, 2003, Addison
Wesley
 D. Kulak, Use Cases: Requirements in context, 2003, Addison-Wesley
 K. Bittner, I. Spence, Use Case Modeling, 2003, Addison-Wesley