Les diagrammes de cas d’utilisation IUT - Utilisation d’un dictionnaire du domaine - Des cas d’utilisations (Use-cases/UC) - Acteurs, use-cases, system UML - Processus de construction des Uses-case - Compléments

1. Analyse et Conception avec UML
Les diagrammes
de cas d’utilisation
blay@unice.fr
www.polytech.unice.fr/~blay
IUT Nice-Sophia Antipolis
Mars 2011
Site web du module :
http://anubis.polytech.unice.fr/iut/
1

2. Bibliographie
Principalement :
• cours IBM : Writing Good Use Cases (2006)
•Voir sur le site web les autres cours.
•Méthodologie en Ingénierie du logiciel, Modélisation Orientée
objet, M.Grimaldi – janvier 2010
2

3. Dict. U.C. Process. Compléments.
Plan du cours
 Utilisation d’un dictionnaire du domaine
 Des cas d’utilisations (Use-cases/UC)
 Acteurs, use-cases, system UML
 Processus de construction des Uses-case
 Compléments
3 /95

4. Dict. U.C. Process. Compléments.
UML au travail : Système d’inscriptions
L’université ESU désire automatiser son système d’inscription
‣ Le chef du service des inscriptions établit le programme des cours pour un
semestre
‣ Un cours peut être offert plusieurs fois
‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours secondaires
dans le catalogue des cours proposés
‣ Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation
est notifié
‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant
une certaine période de temps après leur inscription
‣ Les enseignants utilisent le système pour consulter leur emploi du temps
(tableau d’activités en fonction des cours qui tournent)
‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui
sont nécessaire à la procédure d’identification
4 /82

5. Dict. U.C. Process. Compléments.
UML au travail : Guichet automatique de banque
Le guichet automatique d’une banque (GAB) offre les
services suivants :
Distribution d’argent à partir d’une carte de la banque
ou d’une carte Visa.
Consultation de solde de compte, dépôt en numéraire et
dépôt de chèques pour les clients de la banque porteurs
d’une carte de la banque.
De plus,
Toutes les transactions sont sécurisées.
Il est parfois nécessaire de recharger le distributeur, .
5 /82 Voir UML2 par la pratique

6. Dict. U.C. Process. Compléments.
Intérêt du dictionnaire
 Outil de dialogue
 Informel, évolutif, simple a réaliser
 Etablir et figer la terminologie
– Permet de figer la terminologie du domaine
d'application.
– Constitue le point d'entrée et le référentiel
initial de l'application ou du système.
Homonymie
Synonymie
Polysémie 6 /95

7. Dict. U.C. Process. Compléments.
UML au travail : Système d’inscriptions
L’université ESU désire automatiser son système d’inscription
‣ Le chef du service des inscriptions établit le programme des cours pour
un semestre
‣ Un cours peut être offert plusieurs fois
‣ Les étudiants doivent sélectionner 4 cours primaires et 2 cours
secondaires dans le catalogue des cours proposés
‣ Dès qu’un étudiant s’est inscrit pour un semestre, le système de facturation
est notifié
‣ Les étudiants peuvent utiliser le système pour modifier leurs choix pendant
une certaine période de temps après leur inscription
‣ Les enseignants utilisent le système pour consulter leur emploi du temps
(tableau d’activités en fonction des cours qui tournent)
‣ Les utilisateurs du système d’inscription reçoivent des mots de passe qui
sont nécessaire à la procédure d’identification
7 /82

8. Dict. U.C. Process. Compléments.
UML au travail : Une ludothèque
(1) Nous voulons informatiser une ludothèque pour favoriser la
consultation des jeux proposés par la ludothèque.
(2) Les adhérents peuvent emprunter des jeux en s’adressant à un
conseiller qui enregistre l’emprunt.
(3)Les jeux empruntés sont rendus à un conseiller....
(4) Un adhérent peut réserver des jeux. Une réservation précise
l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti
quand le jeu revient en rayon.
(5) Pour organiser un événement le conseiller spécialisé doit alors
donner les informations suivantes : les jeux à tester, le nombre maximal et
minimal de participants attendus, la date, et l’heure de début de l’événement.
(6) Un adhérent peut s’inscrire pour participer à un événement à
condition qu’il y ait encore de la place.
(7) Un adhérent peut payer sa cotisation en ligne par un système de
paiement externe
8 /82

9. Dict. U.C. Process. Compléments.
Les diagrammes de cas d ’utilisation
Une des notations d ’UML (use-cases)
But :
‣ définir le système du point de vue des utilisateurs
‣ définir les limites précises du système
Notation très simple, compréhensible par tous
Permet de structurer :
‣ les besoins (cahier des charges)
‣ le reste du développement
‣ la progression d ’un cycle en spirale
Les cas d'utilisation sont nommés en utilisant la
terminologie décrite dans le dictionnaire Jean-Marie Favre
9 /95

10. Dict. U.C. Process. Compléments.
Les diagrammes de cas d ’utilisation
Une Notation très simple, compréhensible par tous
cf. http://linformalibre.f2lt.fr/index.php?title=Comprendre_Joomla_%C3%A0_l%27aide_d%27UML
10 /95

11. Dict. U.C. ✓Conclusion Process. Compléments.
Bénéfices des use-cases
Organisent les exigences d’un point de vue utilisateur
Définissent les exigences du système comme des
séquences logiques,
Permettent de vérifier que toutes les exigences sont
capturées et qu’elles correspondent à ce qu’attend le
demandeur.
Facilitent l’adéquation des demandeurs
‣ mais aussi des cas de tests, la documentation et la
réutilisation des exigences.
11 /95

12. Dict. U.C. ✓Conclusion Process. Compléments.
Des use-cases, pour qui?
Demandeurs (décrire et approuver)
Utilisateurs (comprendre)
Architectes logiciels (identification
des fonctions)
Concepteurs et développeurs
Testeurs (identifier les tests)
Managers (Planifier)
Rédacteurs de documentation
(prendre un point de vue utilisateur)
12 /95

13. Dict. U.C. ✓Conclusion Process. Compléments.
Dev. logiciel dirigé par les use-cases
13 /95

14. Dict. U.C. Process. Compléments.
Processus d’écriture des UC
Trouver les acteurs Etudiant Catalogue
des cours
Enregistrer des cours
Brève description: Ce UC permet à un étudiant
Trouver les UC d’enregistrer ses cours... Seuls les formations bien
construites sont acceptés. Le catalogue des cours est
notifié des inscriptions.
Description de «Enregistrer des cours»
Décrire les UC -Flot d’évènements
-Pas à pas
Specification de «Enregistrer des cours»
Détailler les UC - Flot d’évènements détaillés
- Exigences spéciales
- Pre/Postconditions
14 /95

15. Dict. U.C. Process. Compléments.
Processus d’écriture des UC
Trouver les acteurs
Important
Trouver les UC C’est un processus
itératif
Décrire les UC
Détailler les UC
15 /95

16. Dict. U.C. Process. ✓1. acteurs Compléments.
Processus d’écriture des UC
Trouver les acteurs Nommer et
brièvement
décrire les
Trouver les UC acteurs
trouvés
Décrire les UC
Détailler les UC
16 /95

17. Dict. U.C. Process. ✓1. acteurs Compléments.
Définir le périmètre du SI : Acteurs
Définir les acteurs externes
‣ physiques et logiques
‣ rôle et entité concrète
« Un acteur est une personne ou une chose qui
va interagir avec le système »
17 /95

18. Dict. U.C. Process. ✓1. acteurs Compléments.
Définir le périmètre du SI : Acteurs
Définir les acteurs externes
‣ physiques et logiques
‣ rôle et entité concrète
« Un acteur est une personne ou une chose qui
va interagir avec le système »
Etudiant
17 /95

19. Dict. U.C. Process. ✓1. acteurs Compléments.
Définir le périmètre du SI : Acteurs
Définir les acteurs externes
‣ physiques et logiques
‣ rôle et entité concrète
« Un acteur est une personne ou une chose qui
va interagir avec le système »
Etudiant
Chef du
Service des
inscriptions
17 /95

20. Dict. U.C. Process. ✓1. acteurs Compléments.
Définir le périmètre du SI : Acteurs
Définir les acteurs externes
‣ physiques et logiques
‣ rôle et entité concrète
« Un acteur est une personne ou une chose qui
va interagir avec le système »
Système
Enseignant Etudiant de facturation
Chef du
Service des
inscriptions
17 /95

21. Dict. U.C. Process. ✓1. acteurs Compléments.
Client
Acteurs
Un Acteur =
‣ élément externe qui interagit avec le système
‣ rôle qu’un utilisateur joue par rapport au système
ex: un enseignant, un guichetier
Une même personne peut jouer plusieurs rôles
ex: Marie est enseignante et étudiante
Maurice est directeur mais peut faire le guichetier
Plusieurs personnes peuvent jouer un même rôle
ex: Paul et Pierre sont deux clients
Un acteur n’est pas forcément un être humain
ex: un distributeur de billet peut être vu comme un acteur; un
gestionnaire de mot de passes
18 /95

22. Dict. U.C. Process. ✓1. acteurs Compléments.
Description des acteurs
Client
Pour chaque acteur :
‣ choisir un identificateur représentatif de son rôle
(un bon nom décrit la responsabilité des acteurs)
‣ donner une brève description textuelle
Un guichetier est un employé de la banque chargé
de faire l’interface entre le système informatique et
les clients qu’il reçoit au comptoir. Le guichetier peut
réaliser les opérations courantes : création d ’un
Guichetier
compte, dépôt et retrait d ’argent, etc.
Jean-Marie Favre 19 /95

23. Dict. U.C. Process. ✓1. acteurs Compléments.
Trouver les acteurs
Qui ou quoi utilise le système?
Qui ou quoi obtient de l'information de ce système ?
Qui ou quoi fournit des informations au système ?
Où dans la compagnie le système est-il utilisé ?
Qui ou quoi supporte et maintient le système?
Quels autres systèmes utilisent ce système?
20 /95

24. Dict. U.C. Process. ✓1. acteurs Compléments.
Décrire les acteurs
Student :
A person who signs
up for a course Student
- Qu'est-ce ou que l'acteur représente
- Pourquoi l'acteur est nécessaire
- Quel est l’intérêt de l’acteur dans le UC ?
Professor Registrar
21 /95

25. Dict. U.C. Process. ✓1. acteurs Compléments.
Décrire les acteurs
Student :
A person who signs
up for a course Student
- Qu'est-ce ou que l'acteur représente
- Pourquoi l'acteur est nécessaire
- Quel est l’intérêt de l’acteur dans le UC ?
Professor Registrar
Course Catalog
System
21 /95

26. Dict. U.C. Process. ✓1. acteurs Compléments.
UML au travail : Guichet automatique de banque
Le guichet automatique d’une banque (GAB) offre les
services suivants :
Distribution d’argent à partir d’une carte de la banque
ou d’une carte Visa.
Consultation de solde de compte, dépôt en numéraire et
dépôt de chèques pour les clients de la banque porteurs
d’une carte de la banque.
De plus,
Toutes les transactions sont sécurisées.
Il est parfois nécessaire de recharger le distributeur, .
22 /82 Voir UML2 par la pratique

27. Identification des acteurs
Quelles sont les entités externes qui interagissent avec le GAB ?
• Porteur de carte
Phrase 1 • Carte de crédit
• Lecteur de carte
• Distributeur de billets
Phrase 2 • Porteur de carte
client de la banque
Phrase 3 Le système est sécurisé (par
quoi?)
1. Le système
d’autorisation
2. Le système
d’information de
la banque
Phrase 4 • Opérateur de
maintenance

28. Dict. U.C. Process. ✓1. acteurs Compléments.
UML au travail : Une ludothèque
(1) Nous voulons informatiser une ludothèque pour favoriser la
consultation des jeux proposés par la ludothèque.
(2) Les adhérents peuvent emprunter des jeux en s’adressant à un
conseiller qui enregistre l’emprunt.
(3)Les jeux empruntés sont rendus à un conseiller....
(4) Un adhérent peut réserver des jeux. Une réservation précise
l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti
quand le jeu revient en rayon.
(5) Pour organiser un événement le conseiller spécialisé doit alors
donner les informations suivantes : les jeux à tester, le nombre maximal et
minimal de participants attendus, la date, et l’heure de début de l’événement.
(6) Un adhérent peut s’inscrire pour participer à un événement à
condition qu’il y ait encore de la place.
(7) Un adhérent peut payer sa cotisation en ligne par un système de
paiement externe 24 /82

29. Dict. U.C. Process. ✓1. acteurs Compléments.
Diagramme de contexte
25 /95

30. Le GAB est un système fondamentalement
mono-utilisateur: à tout instant, il n’y a qu’une
instance de chaque acteur (au maximum)
connecté au système!
Pour simplifier, nous utiliserons le terme Client banque pour
l’acteur Porteur de carte client de la banque.

31. Diagramme de contexte statique

32. Les acteurs humains Client banque et Porteur de carte sont
mutuellement exclusifs, ce qui n’est pas implicite d’après les
multiplicités des associations. On peut ajouter une contrainte
{XOR} (ou exclusif)

33. Une autre solution, un peu plus élaborée, consiste à
considérer que Client banque est une spécialisation de
Porteur de carte (héritage entre acteurs)

34. Dict. U.C. Process. ✓1. acteurs Compléments.
UML au travail : Une ludothèque
(1) Nous voulons informatiser une ludothèque pour favoriser la
consultation des jeux proposés par la ludothèque.
(2) Les adhérents peuvent emprunter des jeux en s’adressant à un
conseiller qui enregistre l’emprunt.
(3)Les jeux empruntés sont rendus à un conseiller....
(4) Un adhérent peut réserver des jeux. Une réservation précise
l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti
quand le jeu revient en rayon.
(5) Pour organiser un événement le conseiller spécialisé doit alors
donner les informations suivantes : les jeux à tester, le nombre maximal et
minimal de participants attendus, la date, et l’heure de début de l’événement.
(6) Un adhérent peut s’inscrire pour participer à un événement à
condition qu’il y ait encore de la place.
(7) Un adhérent peut payer sa cotisation en ligne par un système de
paiement externe
30 /82

35. Dict. U.C. Process. ✓2. U.C. Compléments.
Processus d’écriture des UC
Trouver les acteurs Nommer et
brièvement décrire
les UC trouvés
Trouver les UC Créer un
diagramme de UC
Etablir la plus-
value métier et les
Décrire les UC risques techniques
des UC
Détailler les UC
31 /95

36. Dict. U.C. Process. ✓1. UC Compléments.
Cas d’utilisation (UC)
32 /95

37. Dict. U.C. Process. ✓1. UC Compléments.
Cas d’utilisation (UC)
Un cas d’utilisation est un motif cohérent de comportement
‣ réalisé par le système.
32 /95

38. Dict. U.C. Process. ✓1. UC Compléments.
Cas d’utilisation (UC)
Un cas d’utilisation est un motif cohérent de comportement
‣ réalisé par le système.
Chaque cas d’utilisation est décrit par une séquence d’actions
connectées, effectuées par un dialogue entre des acteurs et le
système
‣ qui produit un résultat observable
‣ d’intérêt pour un ou plusieurs acteurs du système.
‣ ne révèle pas la structure interne du système.
32 /95

39. Dict. U.C. Process. ✓1. UC Compléments.
Cas d’utilisation (UC)
Un cas d’utilisation est un motif cohérent de comportement
‣ réalisé par le système.
Chaque cas d’utilisation est décrit par une séquence d’actions
connectées, effectuées par un dialogue entre des acteurs et le
système
‣ qui produit un résultat observable
‣ d’intérêt pour un ou plusieurs acteurs du système.
‣ ne révèle pas la structure interne du système.
Chaque cas d’utilisation est un flot complet et faisant du sens
du point de vue d’un acteur particulier.
32 /95

40. Dict. U.C. Process. ✓2. U.C. Compléments.
Trouver les use-cases
Quels sont les objectifs de chaque acteur?
‣ Pourquoi l'acteur utiliserait-il le système?
‣ Est-ce que l'acteur créera, stockera, modifiera,
supprimera ou lira des données dans le système? Si
oui, pourquoi?
‣ Est-ce que l'acteur nécessite d'informer le système sur
des événements externes ou des changements?
‣ Est-ce que l'acteur doit être informé de certains
événements dans le système?
Quels buts dois-je
atteindre en utilisant le
système? Acteur
33 /95

41. Dict. U.C. ✓cas d’utilisat. Process. Compléments.
Cas d’utilisation
Maintenir le Demander un
Enregistrer ses cours
Programme tableau de service
34 /82

42. Dict. U.C. ✓cas d’utilisat. Process. Compléments.
Cas d’utilisation
Identification des besoins des acteurs
‣ Chef du service des inscriptions – maintenir le
programme des études
‣ Enseignant – demander un tableau de service
‣ Etudiant – enregistrer ses cours
‣ Système de facturation – recevoir les informations de
facturation du système d’inscription
Maintenir le Demander un
Enregistrer ses cours
Programme tableau de service
34 /82

43. Dict. U.C. Process. ✓2. UC Compléments.
Nommer un use-case
 Enregistrer des Cours
?
 Enregistrement de cours
 Cours
 Utiliser le système d’enregistrement
 Accuser réception des cours
35 /95

44. Dict. U.C. Process. ✓2. UC Compléments.
Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
 Enregistrer des Cours
?
 Enregistrement de cours
 Cours
 Utiliser le système d’enregistrement
 Accuser réception des cours
35 /95

45. Dict. U.C. Process. ✓2. UC Compléments.
Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
Il doit commencer par un verbe et utiliser une simple
combinaison verbe-nom
 Enregistrer des Cours
?
 Enregistrement de cours
 Cours
 Utiliser le système d’enregistrement
 Accuser réception des cours
35 /95

46. Dict. U.C. Process. ✓2. UC Compléments.
Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
Il doit commencer par un verbe et utiliser une simple
combinaison verbe-nom
Définir clairement et sans ambiguïté le gain des résultats
observables
 Enregistrer des Cours
?
 Enregistrement de cours
 Cours
 Utiliser le système d’enregistrement
 Accuser réception des cours
35 /95

47. Dict. U.C. Process. ✓2. UC Compléments.
Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
Il doit commencer par un verbe et utiliser une simple
combinaison verbe-nom
Définir clairement et sans ambiguïté le gain des résultats
observables
Placez vous du point de vue de l'acteur qui déclenche le
cas d'utilisation
 Enregistrer des Cours
?
 Enregistrement de cours
 Cours
 Utiliser le système d’enregistrement
 Accuser réception des cours
35 /95

48. Dict. U.C. Process. ✓2. UC Compléments.
Nommer un use-case
Le nom doit être unique, intuitif et auto-explicatif
Il doit commencer par un verbe et utiliser une simple
combinaison verbe-nom
Définir clairement et sans ambiguïté le gain des résultats
observables
Placez vous du point de vue de l'acteur qui déclenche le
cas d'utilisation
Décrire le comportement fournit par le cas d'utilisation
 Enregistrer des Cours
?
 Enregistrement de cours
 Cours
 Utiliser le système d’enregistrement
 Accuser réception des cours
35 /95

49. Dict. U.C. Process. ✓2. UC Compléments.
Diagramme des UC
Objectif : visualiser les relations entre acteurs et cas
d’utilisation (communication)
Enregistrer ses cours Consulter
tableau de service
Etudiant Enseignant
S’inscrire
Système de Etablir le
facturation Programme Scolaire
Chef du Service
Des Inscriptions
36 /95

50. Dict. U.C. Process. ✓2. UC Compléments.
Communication : un dialogue
L’étudiant se connecte au système
Le système approuve la connexion.
L’étudiant requiert des informations
Enregistrer
Etudiant ses cours Catalogue
des cours
Le système affiche la liste des cours Le système transmet la requête
L’étudiant selectionne les cours Le Catalogue des cours retourne
des informations sur les cours.
Le système affiche l’edt approuvé
37 /95

51. Dict. U.C. Process. ✓2. UC Compléments.
UML au travail : Guichet automatique de banque
Le guichet automatique d’une banque (GAB) offre les
services suivants :
Distribution d’argent à partir d’une carte de la banque
ou d’une carte Visa.
Consultation de solde de compte, dépôt en numéraire et
dépôt de chèques pour les clients de la banque porteurs
d’une carte de la banque.
De plus,
Toutes les transactions sont sécurisées.
Il est parfois nécessaire de recharger le distributeur, .
38 /82 Voir UML2 par la pratique

52. Dict. U.C. Process. ✓2. UC Compléments.
Diagramme des cas d’utilisation
Porteur de carte:
Retirer de l’argent
Client banque:
Retirer de l’argent (bien sûr!)
Acteurs
Consulter le solde de son compte courant primaires
Déposer du numéraire
Déposer de l’argent (numéraire ou chèque)
Opérateur de maintenance
Recharger le distributeur
Maintenir l’état opérationnel
Système d’autorisation (Sys.Auto)
Acteurs
Néant secondaires
Système d’information de la banque (SI banque)
Néant
/82

53. Dict. U.C. Process. ✓2. UC Compléments.
Diagramme des cas d’utilisation
/82

54. Dict. U.C. Process. ✓2. UC Compléments.
Diagramme des cas d’utilisation
amélioration
/82

55. Diagramme des cas d’utilisation sans les
acteurs secondaires

56. Dict. U.C. Process. ✓2. UC Compléments.
UML au travail : Une ludothèque
(1) Nous voulons informatiser une ludothèque pour favoriser la
consultation des jeux proposés par la ludothèque.
(2) Les adhérents peuvent emprunter des jeux en s’adressant à un
conseiller qui enregistre l’emprunt.
(3)Les jeux empruntés sont rendus à un conseiller....
(4) Un adhérent peut réserver des jeux. Une réservation précise
l’emprunteur, le jeu et la date de la demande de réservation. L’adhérent est averti
quand le jeu revient en rayon.
(5) Pour organiser un événement le conseiller spécialisé doit alors
donner les informations suivantes : les jeux à tester, le nombre maximal et
minimal de participants attendus, la date, et l’heure de début de l’événement.
(6) Un adhérent peut s’inscrire pour participer à un événement à
condition qu’il y ait encore de la place.
(7) Un adhérent peut payer sa cotisation en ligne par un système de
paiement externe
43 /82

57. Dict. U.C. Process. ✓2. UC Compléments.
Le système
Le système est un ensemble de cas d’utilisation
Le système contient :
‣ les cas d ’utilisation,
‣ mais pas les acteurs.
Un modèle de cas d ’utilisation permet de définir :
‣ les fonctions essentielles du système,
‣ les limites du système,
‣ le système par rapport à son environnement.
44 /95

58. Dict. U.C. Process. ✓2. UC Compléments.
System
Frontière du système
Etablir
un emploi
du temps
Etudiant Enregistrer
ses cours
Catalogue
S’inscrire
des cours
Demander
Système de
un
tableau de facturation
service
Système de Enseignant
facturation Maintenir le
Programme
Chef du Service
45 /95 Des Inscriptions

59. Dict. U.C. ✓Desc. Process. Compléments.
Description succincte d’un UC
Sommaire d'identification :
■ Titre
■ Résumé
■ Acteurs
■ Date de création
■ Date de mise à jour
■ Version
■ Responsable
46 /95

60. Dict. U.C. Process. ✓2. UC Compléments.
Description textuelle du cas d'utilisation:
« RETIRER DE L’ARGENT »
Sommaire d'identification
Titre : Retirer de l'argent
Résumé : ce cas d'utilisation permet à un porteur de carte, qui n'est pas
client de la banque, de retirer de l'argent, si son crédit hebdomadaire le
permet.
Acteurs : Porteur de carte non client (principal), Sys. Auto. (secondaire).
Date de création : 03/01/07 Date de mise à jour : 09/02/07
Version : 1.0 Responsable : Pierre DUMONT
/82

61. Dict. U.C. Process. ✓3.décrire. Compléments.
Processus d’écriture des UC
Trouver les acteurs Décrire les flots
d’évènements
(bref)
Trouver les UC Saisir les scenarii
Collecter les
exigences
additionnelles
Décrire les UC
Détailler les UC
48 /95

62. Dict. U.C. Process. ✓3.décrire. Compléments.
Décrire une UC
Décrire chaque étape du UC par des phrases
courtes, organisées séquentiellement.
Use Case Name
Brief Description
Basic Flow
1. First step
2. Second step
3. Third step
Alternative Flows
1. Alternative flow 1
2. Alternative flow 2
3. Alternative flow 3
49 /95

63. Dict. U.C. Process. ✓3.décrire. Compléments.
Décrire une UC
Décrire chaque étape du UC par des phrases
courtes, organisées séquentiellement.
Use Case Name
Brief Description Structurer
Basic Flow le flot de
Numéroter base en
1. First step
et nommer 2. Second step étapes
les étapes. 3. Third step majeures
Alternative Flows
1. Alternative flow 1 Identifier
2. Alternative flow 2 les flots
3. Alternative flow 3 alternatifs.
49 /95

64. Dict. U.C. Process. ✓3.décrire. Compléments.
Pas à pas : enregistrer ses cours
Basic Flow
‣ 1.
L’étudiant se connecte.
‣ 2.
L’étudiant choisit d’enregistrer ces choix de cours.
‣ 3.
L’étudiant obtient des informations sur les cours.
‣ 4.
L’étudiant sélectionne les cours.
‣ 5.
L’étudiant soumet ses choix.
D’autres
‣ 6.
Le système valide les choix. alternatives?
Alternative Flows
‣ A1. Etudiant non identifié
‣ A2. L’étudiant quitte l’application avant soumission
‣ A3. Les choix ne sont pas valides
‣ A4. Le catalogue des Cours est non accessible.
50 /95

65. Dict. U.C. Process. ✓3.décrire. Compléments.
Décrire les UC
Un processus itératif : ne pas tout détailler, pas
trop tôt
Un processus de découverte : Décrire vous aide
à découvrir ce que vous ne connaissez pas. Une
brève description sert de point de départ.
Un processus d’évaluation : UC trop petit ou
trop gros ? partagé?
51 /95

66. Dict. U.C. Process. ✓3.décrire. Compléments.
Exigences additionnelles
Collecter les exigences système qui ne
peuvent pas être allouées à des UC
spécifiques dans des documents
additionnels.
52 /95

67. Dict. U.C. Process. ✓4.détailler Compléments.
Processus d’écriture des UC
Trouver les acteurs Détailler les flots
d'événements
Structurer les flots
Trouver les UC d'événements
Spécifier les
propriétés
additionnelles
Décrire les UC
Détailler les UC
53 /95

68. Dict. U.C. ✓Système Process. ✓4.détailler Compléments.
Description détaillée d’un UC
■ Description des scénarios:
■ Préconditions
■ Scénario Nominal
■ Flots alternatifs
■ Flots d'erreur
■ Postconditions
■ Exigences non fonctionnelles
■ Besoins d'IHM
54 /95

69. Dict. U.C. Process. ✓4.détailler Compléments.
Préconditions
 Décrire l'état dans lequel doit être le système avant que le UC
puisse commencer.
 Simples déclarations qui définissent l'état du système,
exprimées comme ses conditions qui doivent être remplies
 Il ne faut jamais se référer à d'autres UC qui doivent être
effectuées avant cet UC
 Devraient être énoncées clairement et devraient être
facilement vérifiables
 Facultatif: Utilisez uniquement si nécessaire pour clarifier
 Exemple
 UC «Inscription à des cours»
 Préconditions
 La liste des offres de cours pour le semestre a été créée et est disponible au
service d’inscription.
 L'élève a ouvert une session d’inscription dans le système
55 /95

70. Dict. U.C. ✓Système Process. ✓4.détailler Compléments.
Description détaillée d’un UC
■ Description des scénarios:
■ Préconditions
■ Scénario Nominal
■ Flots alternatifs
■ Flots d'erreur
■ Postconditions
■ Exigences non fonctionnelles
■ Besoins d'IHM
56 /95

71. Dict. U.C. Process. ✓4.détailler Compléments.
Détailler le flot de base
Register for Courses
1.1 Basic Flow
1. Log On.
This use case starts when someone accesses the
Décrire les étapes. Course Registration System and chooses to register for
courses. The system validates that the person accessing
the system is an authorized student.
2. Select “Create a Schedule ”.
The system displays the functions available to the
<Acteur> student. The student selects “Create a Schedule ”.
3. Obtain Course Information.
<fait> The system retrieves a list of available course offerings
from the Course Catalog System and displays the list to
the student .The student can search the list by
department, professor, or topic to obtain the desired
course information .
<Système> 4. Select Courses.
The student selects four primary course offerings and
<fait> two alternate course offerings from the list of available
offerings course offerings.
57 /95

72. Dict. U.C. Process. ✓4.détailler Compléments.
Formulation
 Utilisez la voix active
 Dire: “Le Professeur attribue des notes à chaque étudiant”
 Au lieu de : “Quand le Professeur a attribué les notes”
 Dire ce qui déclenche l’étape
 Dire: “Le UC commence quand le Prof. choisit de donner
une note.”
 Au lieu de : “Le UC commence quand le Prof. décide de ....
 Dire qui fait quoi (utiliser le nom d'acteur)
 Dire: “L'étudiant choisit ... …”
 Au lieu de: "L'utilisateur choisit ...…"
 Dire: “Le Système valide …”
 Au lieu de: "Le choix est validé …"
58 /95

73. Description textuelle du cas d'utilisation:
« RETIRER DE L’ARGENT »
Description des scénarios
Pré conditions
•La caisse du GAB est alimentée (il reste au moins un billet !).
•Aucune carte ne se trouve déjà coincée dans le lecteur.
Scénario nominal
1. Le porteur de carte introduit sa carte dans le lecteur de cartes du GAB.
2. Le GAB vérifie que la carte introduite est bien une carte bancaire.

74. 3. Le GAB demande au porteur de carte de saisir son code d'identification.
4. Le porteur de carte saisit son code d'identification.
5. Le GAB compare le code d'identification avec celui qui est codé sur la
puce de la carte.
6. Le GAB demande une autorisation au système d'autorisation.
7. Le système d'autorisation donne son accord et indique le solde
hebdomadaire.
8. Le GAB demande au porteur de carte de saisir le montant désiré du
retrait.
9. Le porteur de carte saisit le montant désiré du retrait.
10. Le GAB contrôle le montant demandé par rapport au solde
hebdomadaire.
11. Le GAB demande au porteur de carte s'il veut un ticket.
12. Le porteur de carte demande un ticket.
13. Le GAB rend sa carte au porteur de carte.
14. Le porteur de carte reprend sa carte.
15. Le GAB délivre les billets et un ticket.
16. Le porteur de carte prend les billets et le ticket.
17. Le GAB enregistre la transaction de retrait.

75. Description textuelle du cas d'utilisation:
RETIRER DE L’ARGENT (Représentation de C.Larman)
Une autre présentation dite de Larman consiste à séparer les
actions des acteurs et du système en deux colonnes:
Action d’acteur Action Système
1. Le porteur de carte introduit sa 2. Le GAB vérifie que la carte
carte dans le lecteur de cartes du introduite est bien une carte
GAB. bancaire.
3. Le GAB demande au porteur de
carte de saisir son code
d'identification.
4. Le porteur de carte saisit son 5. Le GAB compare le code
code d'identification. d’identification avec celui qui est
codé sur la puce de la carte.
6. Le GAB demande une autorisation
au système d'autorisation global.

76. 7. Le système donne son accord et 8. Le GAB de mande au porteur de
indique le solde carte de saisir le montant désiré
hebdomadaire. du retrait.
9. Le porteur de carte saisie le 10. Le GAB contrôle le montant
montant désiré demandé par rapport au solde
hebdomadaire
11. Le GAB demande au porteur de
carte s’il veut un ticket
12. Le porteur de carte demande 13. Le GAB rend sa carte au porteur
un ticket. de carte.
14. Le porteur de carte reprend sa 15. Le GAB délivre des billets et un
carte ticket.
16. Le porteur de carte prend les 17. Le GAB enregistre la transaction
billets et le ticket. de retrait.

77. Dict. U.C. ✓Système Process. ✓4.détailler Compléments.
Description détaillée d’un UC
■ Description des scénarios:
■ Préconditions
■ Scénario Nominal
■ Flots alternatifs
■ Flots d'erreur
■ Postconditions
■ Exigences non fonctionnelles
■ Besoins d'IHM
63 /95

78. Enchaînements alternatifs*
Al : code d'identification provisoirement erroné
L'enchaînement Al démarre au point 5 du scénario nominal.
6. Le GAB indique au porteur de carte que le code est erroné, pour la
première ou deuxième fois.
7. Le GAB enregistre l'échec sur la carte.
Le scénario nominal reprend au point 3.
A2 : montant demandé supérieur au solde hebdomadaire
L'enchaînement A2 démarre au point 10 du scénario nominal.
11. Le GAB indique au porteur de carte que le montant demandé est
supérieur au solde hebdomadaire.
Le scénario nominal reprend au point 8.
* Nous distinguons les enchaînements alternatifs (Ax) qui reprennent ensuite à
une étape du scénario nominal des enchaînements d'erreur (Ey) qui terminent
brutalement le cas d'utilisation en échec. L'objectif de l'acteur principal est donc
atteint par les scénarios nominaux et alternatifs mais pas par ceux d'erreur.

79. A3 : ticket refusé
L'enchaînement A3 démarre au point 11 du scénario nominal.
12. Le porteur de carte refuse le ticket.
13. Le GAB rend sa carte au porteur de carte.
14. Le porteur de carte reprend sa carte.
15. Le GAB délivre les billets.
16. Le porteur de carte prend les billets.
17. Le GAB enregistre la transaction de retrait.
Enchaînements d’erreur
El : carte non-valide
L'enchaînement El démarre au point 2 du scénario nominal.
3. Le GAB indique au porteur que la carte n'est pas valide (illisible,
périmée, etc.), la confisque ; le cas d'utilisation se termine en échec.

80. E2 : code d'identification définitivement erroné
L'enchaînement E2 démarre au point 5 du scénario nominal.
6. Le GAB indique au porteur de carte que le code est erroné, pour la
troisième fois.
7. Le GAB confisque la carte.
8. Le système d'autorisation est informé ; le cas d'utilisation se termine
en échec.
E3 : retrait non autorisé
L'enchaînement E3 démarre au point 6 du scénario nominal.
7. Le système d'autorisation interdit tout retrait.
8. Le GAB éjecte la carte ; le cas d'utilisation se termine en échec.
E4 : carte non reprise
L'enchaînement E4 démarre au point 13 du scénario nominal.
14. Au bout de 15 secondes, le GAB confisque la carte.
15. Le système d'autorisation est informé ; le cas d'utilisation se termine
en échec.

81. E5 : billets non pris
L'enchaînement E5 démarre au point 15 du scénario nominal.
16. Au bout de 30 secondes, le GAB reprend les billets.
17. Le système d'autorisation est informé ; le cas d'utilisation se termine
en échec.
E6 : annulation de la transaction
L'enchaînement E6 peut démarrer entre les points 4 et 12 du scénario
nominal.
4 à 12. Le porteur de carte demande l'annulation de la transaction en
cours.
Le GAB éjecte la carte ; le cas d'utilisation se termine en échec.
E4 : carte non reprise
L'enchaînement E4 démarre au point 13 du scénario nominal.
14. Au bout de 15 secondes, le GAB confisque la carte.
15. Le système d'autorisation est informé ; le cas d'utilisation se termine
en échec.

82. Dict. U.C. Process. ✓3.décrire. Compléments.
Décrire les flots d'événements
Flot de base
‣ Quel événement déclenche le cas d'utilisation?
‣ Comment le cas d'utilisation se termine-t-il?
‣ Comment le cas d'utilisation répète-t-il certains comportements?
Flots d’exceptions
‣ Y-a-t-il des situations facultatives dans le cas d'utilisation?
‣ Quel cas étrange pourrait se produire? Etape de
‣ Quelles variantes pourraient arriver? communication avec
Qu’est-ce qui peut mal tourner? les utilisateurs
‣
‣ Qu’est-ce qui ne peut pas se produire?
‣ Quels types de ressources peuvent être bloqués?
Pas dans le détail
68 /95

83. Dict. U.C. ✓Système Process. ✓4.détailler Compléments.
Description détaillée d’un UC
■ Description des scénarios:
■ Préconditions
■ Scénario Nominal
■ Flots alternatifs
■ Flots d'erreur
■ Postconditions
■ Exigences non fonctionnelles
■ Besoins d'IHM
69 /95

84. Dict. U.C. Process. ✓4.détailler Compléments.
Postconditions
 Décrire l'état dans lequel doit être le système à la fin du UC
 Utiliser lorsque l'état du système est une condition préalable
à un autre UC, ou lorsque les résultats possibles du UC ne
sont pas évidents pour le lecteur
 Il ne faut jamais se référer à d'autres UC qui doivent être
effectués avant cet UC
 Devraient être énoncées clairement et devraient être
facilement vérifiables
 Facultatif: Utilisez uniquement si nécessaire pour clarifier
 Exemple on peut commencer par les
postconditions avant même les
 UC «Inscription à des cours»
flots.
 Postconditions
 À la fin de ce cas d'utilisation, soit l'étudiant a été inscrit à des cours, soit
l’inscription a échoué et aucune modification n'a été apportée à aux cours...
70 /95

85. Dict. U.C. Process. ✓4.détailler Compléments.
Exemple de description détaillée d’un UC
Précondition :
Le distributeur contient des billets, il est en attente d ’une
opération, il n’est ni en panne, ni en maintenance
Début : lorsqu ’un client introduit sa carte bancaire dans le
Retirer
DeLArgent distributeur.
AuDistributeur
Fin : lorsque la carte bancaire et les billets sont sortis.
Postcondition :
Si de l ’argent a pu être retiré la somme d’argent sur le
compte est égale à la somme d ’argent qu’il y avait avant,
moins le montant du retrait. Sinon la somme d ’argent sur le
compte est la même qu’avant.
Jean-Marie Favre 71 /95

86. Dict. U.C. ✓Système Process. ✓4.détailler Compléments.
Description détaillée d’un UC
■ Description des scénarios:
■ Préconditions
■ Scénario Nominal
■ Flots alternatifs
■ Flots d'erreur
■ Postconditions
■ Exigences non fonctionnelles
■ Besoins d'IHM
72 /95

87. Dict. U.C. Process. ✓4.détailler Compléments.
Exemple de description détaillée d’un UC
Contraintes non fonctionnelles :
(A) Performance : le système doit réagir dans un délai
inférieur à 4 secondes, quelque soit l ’action de l ’utilisateur.
Retirer
DeLArgent
AuDistributeur (B) Résistance aux pannes : si une coupure de courant ou
une autre défaillance survient au cours du cas d ’utilisation,
la transaction sera annulée, l ’argent ne sera pas distribué.
Le système doit pouvoir redémarrer automatiquement
dans un état cohérent et sans intervention humaine.
(C) Résistance à la charge : le système doit pouvoir gérer
plus de 1000 retraits d ’argent simultanément
...
Jean-Marie Favre 73 /95

88. Description textuelle du cas d'utilisation:
« RETIRER DE L’ARGENT »
informations optionnelles
Exigences non fonctionnelles
Contraintes Descriptif
Temps de réponse L’interface du GAB doit réagir en l’espace de 2
secondes au maximum. Une transaction nominale
de retrait doit durer moins de 2 minutes
Concurrence Non applicable (mono-utilisateur)
Disponibilité Le GAB est accessible 7j/7, 24h/24 . L’absence de
papier pour les tickets ne doit pas empêcher les
retraits.
Intégrité Les interface du GAB doivent être très robustes
pour prévenir le vandalisme
Confidentialité La vérification du code saisi doit être fiable à 10-6

89. Dict. U.C. ✓Système Process. ✓4.détailler Compléments.
Description détaillée d’un UC
■ Description des scénarios:
■ Préconditions
■ Scénario Nominal
■ Flots alternatifs
■ Flots d'erreur
■ Postconditions
■ Exigences non fonctionnelles
■ Besoins d'IHM
75 /95

90. Description textuelle du cas d'utilisation:
« RETIRER DE L’ARGENT »
informations optionnelles
Besoins d’IHM
Les dispositifs d'entrée/sortie à la disposition du porteur
de carte doivent être :
• Un lecteur de carte bancaire.
• Un clavier numérique (pour saisir son code), avec des
touches «validation », « correction » et « annulation ».
• Un écran pour l'affichage des messages du GAB.
• Des touches autour de l'écran pour sélectionner un
montant de retrait parmi ceux qui sont proposés.
• Un distributeur de billets.
• Un distributeur de tickets.

91. Dict. U.C. Process. ✓4.détailler Compléments.
Faire le point sur les UC
Les interactions entre le système et les acteurs
sont claires
Les séquence de communication sont conformes
aux attentes de l'utilisateur
Quand/comment les UC commencent/se
terminent est clair
Le flot de base de base donne un résultat
observable pour un ou plusieurs acteurs
77 /95

92. Dict. U.C. Process. ✓4.détailler Compléments.
Quel niveau de détail?
✓ Saisir toutes les X Pas de détail des
exigences pour tous les interfaces utilisateurs
demandeurs
X Pas de détail des
processus internes non
liés à une exigence
✓ Informations et
événements X Pas les formats de
données, ni les contrôles
How much detail in a use case?
Enough to satisfy all stakeholders that their interests
(requirements) will be satisfied in the delivered system.
78 /95

93. Dict. U.C. Process. Compléments.
Ecrire des UC : Défis
1. Comment garder les UC précis et concis?
2. Comment traiter les interfaces utilisateur?
3. Comment traiter un flux quand
a. Un acteur doit choisir parmi différentes options?
b. Un acteur peut répéter des actions avant de passer à
la suite?
c. Les étapes ne sont pas nécessairement séquentielles?
4. Comment gérer le comportement conditionnelle dans les
cas d'utilisation?
79 /95

94. Dict. U.C. Process. Compléments.
1.Comment garder les UC précis et concis?(1)
✓ Capturer le vocabulaire commun dans un
glossaire
➡ Définir les termes utilisés dans le projet dans le glossaire,
pas dans les flux
➡ Aide à éviter les malentendus
Use Case Glossary
5. Enter Customer Information Customer Details Information
that uniquely identifies and
The system prompts the Customer to provides contact information
enter their Customer Details. for a customer located in the
The Customer enters the Customer U.S.A. The information
consists of Name, two address
Details. lines, city, state, ZIP code, and
The Customer creates the account. daytime phone number.
Implementation
80 /95

95. Dict. U.C. Process. Compléments.
1.Comment garder les UC précis et concis? (2)
✓ Visualiser le glossaire par un modèle du
domaine
Student 1 0..* Schedule 0..* 0..4 Course Offering
0..* 0..*
0..1 1
Part-time Student Full-time Student Professor Course
81/95

96. Dict. U.C. Process. Compléments.
Relations entre UC :
Include, Extend, Specialize
82 /95

97. Dict. U.C. Process. Compléments.
Relations entre UC :
Include, Extend, Specialize
Au fur et à mesure que les cas d’utilisation sont documentés,
des relations peuvent apparaître
‣ Une relation include : utilisation systématique
‣ Une relation extend dénote un comportement optionnel
82 /95

98. Dict. U.C. Process. Compléments.
Extends
Les deux UC sont
indépendants.
Permettre au client de
consulter son solde avant
de saisir le montant :
extension optionnelle.
Flot enrichi
8. Le GAB demande au client de saisir le montant
Point d’extension : Vérification du solde
9. Le client saisit le montant désiré de retrait
83 /95

99. Dict. U.C. Process. Compléments.
Ludothèque
/82

100. Dict. U.C. Process. Compléments.
La relation <<include>>
/95

101. Dict. U.C. Process. Compléments.
La relation <<include>>
La relation d’include a pour seul objectif de factoriser
une partie de la description d’un cas d’utilisation qui
est commune à d’autres cas d’utilisation.
/95

102. Dict. U.C. Process. Compléments.
La relation <<include>>
La relation d’include a pour seul objectif de factoriser
une partie de la description d’un cas d’utilisation qui
est commune à d’autres cas d’utilisation.
Le cas d’utilisation inclus dans les autres cas
d’utilisation n’est pas à proprement parler un vrai
cas d’utilisation car il n’a pas d’acteur déclencheur
ou receveur d’évènement.
/95

103. Dict. U.C. Process. Compléments.
La relation <<include>>
La relation d’include a pour seul objectif de factoriser
une partie de la description d’un cas d’utilisation qui
est commune à d’autres cas d’utilisation.
Le cas d’utilisation inclus dans les autres cas
d’utilisation n’est pas à proprement parler 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.
/95

104. Généralisation
 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
86

105. Dict. U.C. Process. Compléments.
Ludothèque
/82

106. Dict. U.C. Process. Compléments.
Ludothèque
/82

107. Dict. U.C. Process. Compléments.
Ludothèque
/82

108. Dict. U.C. Process. Compléments.
Structuration des UC en packages
Scanner p 43 et 44 de UML par la pratique
On peut alors, si nécessaire,
détailler certains de cas
d’utilisation. /95

109. Dict. U.C. Process. Compléments.
2. Comment traiter les interfaces utilisateur?
✓Laissez l'interface utilisateur hors des UC
➡ Les UC sont indépendants de l'interface utilisateur
➡ Décrire les interfaces utilisateur avec des modèles dédiés
ou des prototypes
Words to Avoid Words to Use
Click Drag Form Prompts Chooses
Open Close Drop Initiates
Button Field Drop-down Specifies
Pop-up Scroll Browse Submits Selects
Record Window Starts Displays
Informs
“Le système fait sonner le téléphone.”
91 /95

110. Dict. U.C. Process. Compléments.
2. Comment traiter les interfaces utilisateur?
✓Laissez l'interface utilisateur hors des UC
➡ Les UC sont indépendants de l'interface utilisateur
➡ Décrire les interfaces utilisateur avec des modèles dédiés
ou des prototypes
Words to Avoid Words to Use
Click Drag Form Prompts Chooses
Open Close Drop Initiates
Button Field Drop-down Specifies
Pop-up Scroll Browse Submits Selects
Record Window Starts Displays
Informs
“Le système fait sonner le téléphone.”
91 /95

111. Dict. U.C. Process. Compléments.
2. Comment traiter les interfaces utilisateur?
✓Laissez l'interface utilisateur hors des UC
➡ Les UC sont indépendants de l'interface utilisateur
➡ Décrire les interfaces utilisateur avec des modèles dédiés
ou des prototypes
Words to Avoid Words to Use
Click Drag Form Prompts Chooses
Open Close Drop Initiates
Button Field Drop-down Specifies
Pop-up Scroll Browse Submits Selects
Record Window Starts Displays
Informs
“Le système fait sonner le téléphone.”
91 /95

112. Dict. U.C. Process. Compléments.
2. Comment traiter les interfaces utilisateur?
✓Laissez l'interface utilisateur hors des UC
➡ Les UC sont indépendants de l'interface utilisateur
➡ Décrire les interfaces utilisateur avec des modèles dédiés
ou des prototypes
Words to Avoid Words to Use
Click Drag Form Prompts Chooses
Open Close Drop Initiates
Button Field Drop-down Specifies
Pop-up Scroll Browse Submits Selects
Record Window Starts Displays
Informs
“Le système fait sonner le téléphone.”
notifie 91 /95

113. Si c’est nécessaire...Après...
• avec l’addon Firefox :
• http://pencil.evolus.vn/en-US/Downloads/Application.aspx
92

114. Résumé
et
conseils
méthodologiques
93

115. Dict. U.C. Process. Compléments.
Cas d’utilisation : résumé
 Se servir des Cas d’Utilisation UML pour identifier les
exigences fonctionnelles.
94 /95

116. Dict. U.C. Process. Compléments.
Cas d’utilisation : résumé
95 /95