Ce document traite de l'analyse et de la conception de systèmes à l'aide de diagrammes UML, mettant particulièrement l'accent sur les cas d'utilisation. Il illustre des exemples pratiques comme le système d'inscription universitaire et le guichet automatique de banque, en soulignant l'importance de ces cas d'utilisation pour définir les exigences systèmes et améliorer la communication entre les différents acteurs. La méthodologie abordée aide à structurer les exigences et à faciliter le développement logiciel orienté utilisateur.

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 /98

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 /98

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.
UML au travail : Une galerie d’art
(1) Nous voulons informatiser une galerie d'art, par laquelle nous
souhaitons vendre des oeuvres d'arts à des clients. Les paiements
doivent être sécurisés en utilisant le système de paiement externe
“chaimoinscheir”.
(2) Les oeuvres et les artistes sont gérés par les administrateurs via des
interfaces adaptées.
(3) Un internaute doit pouvoir s'inscrire sur le site pour devenir client.
(4) Un internaute peut naviguer sur le site, retrouver un artiste par
son nom, visualiser les oeuvres par catégorie.
(5) Les clients peuvent voter pour les oeuvres ou les artistes qu'ils
préfèrent.
(6) Une fois par jour, un super-administrateur déclenche une
opération de sauvegarde de la galerie.
(7) L'identification des clients fait partie du système de la galerie.
6 /82

7. 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 7 /98

8. 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
8 /98

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 /98

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 /98

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 /98

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 /98

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

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 /98

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 /98

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 /98

17. Dict. U.C. ✓acteurs Process. 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 /98

18. Dict. U.C. ✓acteurs Process. 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 /98

19. Dict. U.C. ✓acteurs Process. 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 /98

20. Dict. U.C. ✓acteurs Process. 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 /98

21. Dict. U.C. ✓acteurs Process. 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 /98

22. Dict. U.C. ✓acteurs Process. 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 /98

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 /98

24. 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
21 /98

25. 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
22 /98

26. 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
23 /98

27. 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
23 /98

28. 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, .
24 /98 Voir UML2 par la pratique

29. 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

30. Dict. U.C. Process. ✓1. acteurs Compléments.
UML au travail : Une galerie d’art
(1) Nous voulons informatiser une galerie d'art, par laquelle nous
souhaitons vendre des oeuvres d'arts à des clients. Les paiements
doivent être sécurisés en utilisant le système de paiement externe
“chaimoinscheir”.
(2) Les oeuvres et les artistes sont gérés par les administrateurs via des
interfaces adaptées.
(3) Un internaute doit pouvoir s'inscrire sur le site pour devenir client.
(4) Un internaute peut naviguer sur le site, retrouver un artiste par
son nom, visualiser les oeuvres par catégorie.
(5) Les clients peuvent voter pour les oeuvres ou les artistes qu'ils
préfèrent.
(6) Une fois par jour, un super-administrateur déclenche une
opération de sauvegarde de la galerie.
(7) L'identification des clients fait partie du système de la galerie.
26 /82

31. Dict. U.C. Process. ✓1. acteurs Compléments.
Diagramme de contexte
27 /98

32. 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.

33. Diagramme de contexte statique

34. 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)

35. 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)

36. Dict. U.C. Process. ✓1. acteurs Compléments.
UML au travail : Une galerie d’art
(1) Nous voulons informatiser une galerie d'art, par laquelle nous
souhaitons vendre des oeuvres d'arts à des clients. Les paiements
doivent être sécurisés en utilisant le système de paiement externe
“chaimoinscheir”.
(2) Les oeuvres et les artistes sont gérés par les administrateurs via des
interfaces adaptées.
(3) Un internaute doit pouvoir s'inscrire sur le site pour devenir client.
(4) Un internaute peut naviguer sur le site, retrouver un artiste par
son nom, visualiser les oeuvres par catégorie.
(5) Les clients peuvent voter pour les oeuvres ou les artistes qu'ils
préfèrent.
(6) Une fois par jour, un super-administrateur déclenche une
opération de sauvegarde de la galerie.
(7) L'identification des clients fait partie du système de la galerie.
32 /82

37. 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
33 /98

38. Dict. U.C. ✓cas d’utilisat. Process. Compléments.
Cas d’utilisation (UC)
34 /98

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

40. Dict. U.C. ✓cas d’utilisat. Process. 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.
34 /98

41. Dict. U.C. ✓cas d’utilisat. Process. 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.
34 /98

42. 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
35 /98

43. 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
36 /98

44. Dict. U.C. ✓cas d’utilisat. 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
37 /98

45. Dict. U.C. ✓cas d’utilisat. Process. Compléments.
Nommer un use-case
 Enregistrer des Cours
?
 Enregistrement de cours
 Cours
 Utiliser le système d’enregistrement
 Accuser réception des cours
38 /98

46. Dict. U.C. ✓cas d’utilisat. Process. 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
38 /98

47. Dict. U.C. ✓cas d’utilisat. Process. 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
38 /98

48. Dict. U.C. ✓cas d’utilisat. Process. 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
38 /98

49. Dict. U.C. ✓cas d’utilisat. Process. 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
38 /98

50. Dict. U.C. ✓cas d’utilisat. Process. 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
38 /98

51. Dict. U.C. ✓cas d’utilisat. Process. 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
39 /98

52. Dict. U.C. ✓cas d’utilisat. Process. 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é
40 /98

53. Dict. U.C. ✓cas d’utilisat. Process. 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

54. Dict. U.C. ✓cas d’utilisat. Process. Compléments.
Diagramme des cas d’utilisation
/82

55. Dict. U.C. ✓cas d’utilisat. Process. Compléments.
Diagramme des cas d’utilisation
amélioration
/82

56. Dict. U.C. ✓cas d’utilisat. Process. Compléments.
UML au travail : Une galerie d’art
(1) Nous voulons informatiser une galerie d'art, par laquelle nous
souhaitons vendre des oeuvres d'arts à des clients. Les paiements
doivent être sécurisés en utilisant le système de paiement externe
“chaimoinscheir”.
(2) Les oeuvres et les artistes sont gérés par les administrateurs via des
interfaces adaptées.
(3) Un internaute doit pouvoir s'inscrire sur le site pour devenir client.
(4) Un internaute peut naviguer sur le site, retrouver un artiste par
son nom, visualiser les oeuvres par catégorie.
(5) Les clients peuvent voter pour les oeuvres ou les artistes qu'ils
préfèrent.
(6) Une fois par jour, un super-administrateur déclenche une
opération de sauvegarde de la galerie.
(7) L'identification des clients fait partie du système de la galerie.
44 /82

57. Dict. U.C. ✓Système Process. 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.
45 /98

58. Dict. U.C. ✓Système Process. 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
46 /98 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
47 /98

60. Dict. U.C. ✓Desc. Process. 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. ✓2. U.C. Compléments.
Bilan sur les UC
49 /98

62. Dict. U.C. Process. ✓2. U.C. Compléments.
Faire le point sur les acteurs
Est-ce chacun des acteurs est impliqué dans au
moins un cas d'utilisation?
Est-ce que des acteurs jouent des rôles similaires
du point de vue du système? Dans l'affirmative, les
fusionner en un seul acteur.
«Avez-vous trouvé tous les acteurs?»
«Avez-vous pris en compte et modélisé tous les
rôles dans l'environnement du système?»
50 /98

63. Dict. U.C. Process. ✓2. U.C. Compléments.
Faire le point sur les Use-cases(1)
Le modèle de cas d'utilisation présente le
comportement du système, il est facile de comprendre
ce que le système fait en passant en revue le modèle.
Tous les cas d'utilisation ont été identifiés; les cas
d'utilisation représentent l’ensemble des
comportements requis.
Le modèle de cas d'utilisation ne contient pas de
comportement superflu; A chaque cas d'utilisation
correspond une exigence fonctionnelle.
51 /98

64. Dict. U.C. Process. ✓2. U.C. Compléments.
Faire le point sur les Use-cases(2)
Le cas d'utilisation ont des noms uniques, intuitifs, et
des noms explicites de sorte qu'ils ne peuvent pas être
confondus à un stade ultérieur. Sinon, changer leurs
noms.
Les demandeurs et les utilisateurs comprennent les
noms et les descriptions des cas d'utilisation.
La brève description donne une image fidèle du cas
d'utilisation.
Chaque cas d'utilisation implique au moins un acteur.
Les cas d'utilisation n’ont pas de comportements ou
des flux d'événements très similaires.
52 /98

65. Dict. U.C. Process. ✓2. U.C. Compléments.
Évaluer la valeur commerciale et les risques
Pour chaque cas d'utilisation identifié, obtenir
un consensus avec les parties prenantes quant à
sa valeur commerciale et les risques techniques
‣ L’équipe métier décide ce qui a de l’importance
et ce qui n’en a pas.
‣ L'équipe technique décide de ce qui est risqué
- Degré de complexité de dev. pressentie,
intégration, indéterminisme.
Utilisez : haute, moyen, faible
En déduire les use cases
à détailler en premier
53 /98

66. 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
54 /98

67. 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
55 /98

68. 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.
55 /98

69. 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.
56 /98

70. 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é?
57 /98

71. 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.
58 /98

72. 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
59 /98

73. 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
60 /98

74. 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
61 /98

75. 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
62 /98

76. 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.
63 /98

77. 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é …"
64 /98

78. 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.

79. 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.

80. 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.

81. 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.

82. 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 /98

83. 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.

84. 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.

85. 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.

86. 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.

87. 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
74 /98

88. 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 /98

89. 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...
76 /98

90. 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 77 /98

91. 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
78 /98

92. 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 79 /98

93. 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

94. 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
81 /98

95. 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.

96. 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
83 /98

97. 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.
84 /98

98. 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?
85 /98

99. 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
86 /98

100. 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
87/98

101. Dict. U.C. Process. Compléments.
Relations entre UC :
Include, Extend, Specialize
88 /98

102. 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
88 /98

103. 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
89 /98

104. La relation <<include>> ou <<uses>>

105. La relation <<include>> ou <<uses>>
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.

106. La relation <<include>> ou <<uses>>
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.

107. La relation <<include>> ou <<uses>>
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.

108. 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
91

109. Dict. U.C. Process. Compléments.
La galerie
/98

110. 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. /98

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.”
94 /98

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.”
94 /98

113. 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.”
94 /98

114. 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 94 /98

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

116. Résumé
et
conseils
méthodologiques
96

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

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