Brève introduction aux cas d'utilisation en UML
Cible juste une sensibilisation et la donnée de quelques outils pour mieux identifier les grandes utiisations d'un système.
A destination d'étudiants en IUT
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.
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
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
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
Notes de l'éditeur
\n
\n
\n
\n
s&#xE9;curi&#xE9;s&#xE9; par qui ?\n\nComment cela se passe pour les cliensts qui ne sont pas de la banque a ton pens&#xE9; au S de consultation des cartes bleues?\n\n
\n
Le dictionnaire est un outil m&#xE9;thodologique important. Il permet de r&#xE9;unir utilisateurs et informaticiens autour d'un objectif commun. La communication et donc la qualit&#xE9; de l'expression des besoins s'en trouvent am&#xE9;lior&#xE9;es.\nLa terminologie issue du cahier des charges doit &#xEA;tre reprise et pr&#xE9;cis&#xE9;e, afin d'en extraire le dictionnaire. \nLes concepts de ce dictionnaire (noms communs) sont candidats &#xE0; &#xEA;tre des classes, relations ou attributs, alors que les actions (verbes) sont candidats &#xE0; &#xEA;tre des op&#xE9;rations.\nLe cahier des charges peut comporter des manques et des incoh&#xE9;rences. Un premier objectif du dictionnaire est de clarifier ces aspects.\nLe dictionnaire est un document de r&#xE9;f&#xE9;rence, qui fait foi au cours du projet.\nLes d&#xE9;finitions pr&#xE9;cises des termes du dictionnaire doivent permettre de r&#xE9;gler les cas des synonymes (plusieurs termes ont la m&#xEA;me d&#xE9;finition) et des polys&#xE9;mies (un m&#xEA;me terme &#xE0; plusieurs s&#xE9;mantiques).\n\n\n\nLa polys&#xE9;mie est la qualit&#xE9; d'un mot ou d'une expression qui a deux voire plusieurs sens diff&#xE9;rents (on le qualifie de polys&#xE9;mique).\nIl ne faut pas confondre polys&#xE9;mie et homonymie. Deux mots homonymes ont la m&#xEA;me forme (phonique ou graphique) mais sont des mots totalement diff&#xE9;rents. Ils ont deux entr&#xE9;es distinctes dans le dictionnaire. Polys&#xE9;mie et homonymie sont des cas particulier d'ambigu&#xEF;t&#xE9;.\nSommaire\n[masquer]\n1 Exemples\n2 Cha&#xEE;nes s&#xE9;mantiques\n3 Cas particulier des math&#xE9;matiques\n4 Voir aussi\n 4.1 Articles connexes\n 4.2 Liens externes\nExemples [modifier]\nBlanc, la couleur, l'espace, le vin, la viande, la couleur de peau\nRouge, la couleur, le vin, la race, la col&#xE8;re, le communiste\nVivre, exister, subsister, habiter, exp&#xE9;rimenter, traverser\nIndien, habitant de l'Inde, autochtones des Am&#xE9;riques\nam&#xE9;ricain, qui vient de l'Am&#xE9;rique, qui vient des &#xC9;tats-Unis\nClart&#xE9;, lumi&#xE8;re, transparence, intelligibilit&#xE9;, blancheur\nSouris&#xA0;: tipex, souris d'ordinateur, l'animal, la viande d'agneau, sourire.\n\n\n
Another important part of beginning a project is to start identifying the common vocabulary. Look at the Glossary for a sample.\nThere should be one Glossary for a system. This document is important to all stakeholders, especially when they need to understand and use terms that are specific to the project. There is a sample glossary RUCS2 section of the Student Workbook.\nAll textual descriptions of the system, especially use-case descriptions should use and refer to the terms defined in the glossary. \nIn some cases, you may build a domain model to further visualize the terms in the glossary.\n\n\n \nA partir des documents r&#xE9;cup&#xE9;r&#xE9;s en \nr&#xE9;alisant le sch&#xE9;ma des acteurs et des \nflux. \n&#xF06E;Recenser et analyser l&#x2019;ensemble des \ndonn&#xE9;es pr&#xE9;sentes sur les documents. \n&#xF06E;Avoir un support &#xE9;crit d&#xE9;crivant \nclairement les donn&#xE9;es manipul&#xE9;es par \nl&#x2019;entreprise.\n \n&#xF06E;Une donn&#xE9;e est la repr&#xE9;sentation \nd&#x2019;une information sous une forme \npermettant d&#x2019;en faire le traitement \nautomatique. \n&#xF06E;Une donn&#xE9;e &#xE9;l&#xE9;mentaire doit &#xEA;tre \ninitialis&#xE9;e pour pouvoir &#xEA;tre utilis&#xE9;e. \n&#xF06E;Une donn&#xE9;e calculable peut &#xEA;tre \nd&#xE9;duite d&#x2019;autres donn&#xE9;es. \n&#xF06E;L&#x2019;analyse des donn&#xE9;es se fait &#xE0; travers \ndes rubriques pr&#xE9;sentes dans le \ndictionnaire des donn&#xE9;es.\n \n&#xF06E;Le nom de la donn&#xE9;e : le plus proche \nde celui utilis&#xE9; dans l&#x2019;entreprise. \n&#xF06E;La d&#xE9;finition : celle-ci doit &#xEA;tre libell&#xE9;e \nde fa&#xE7;on compr&#xE9;hensible pour tout le \nmonde. \n&#xF06E;La structure : c&#x2019;est le &#xAB;&#xA0;type&#xA0;&#xBB; de la \ndonn&#xE9;e alphab&#xE9;tique, num&#xE9;rique, date, \n&#x2026; On compl&#xE9;tera si possible par le \nnombre de caract&#xE8;res n&#xE9;cessaire. \n&#xF06E;Le type : &#xE9;l&#xE9;mentaire ou calculable\n&#xF06E;La quantification : une estimation si \npossible du nombre de valeurs \ndiff&#xE9;rentes que peut prendre la donn&#xE9;e. \n&#xF06E;Des exemples : de valeurs que peut \nprendre la donn&#xE9;e. \n&#xF06E;Les commentaires : tout ce qui est \nint&#xE9;ressant de savoir sur la donn&#xE9;e et \nque l&#x2019;on n&#x2019;a pas mis dans une autre \nrubrique.\n \n
En tant que r&#xE9;f&#xE9;rentiel, le dictionnaire doit &#xEA;tre mis &#xE0; jour, afin de garantir la tra&#xE7;abilit&#xE9; entre les besoins exprim&#xE9;s et le syst&#xE8;me d&#xE9;velopp&#xE9;.\n
Au d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
\n
\n
\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is to write the textual description of what happens in each use case, the non-functional requirements, and rules. The description of what happens is called the flow of events.\nActivity diagrams (previously known as flow charts) are another useful tool you can use to describe a use case. It is quite common to use an activity diagram to describe complex flows of events. When using activity diagrams, it is advisable to use swimlanes to represent each actor and the system. Without swimlanes, the activities float in a &#x201C;semantic emptiness&#x201D; and quickly become meaningless.\nThe following diagram is an example from a Withdraw Cash use case for an ATM.\n
Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks, or activities. Functional requirements may include feature sets, capabilities, and security.\nUsability is the ease with which software can be learned and operated by the intended users. Usability requirements may include such subcategories as human factors, aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, and training materials.\nReliability is the ability for the software to behave consistently in a user-acceptable manner. Reliability requirements to be considered are frequency and severity of failure, recoverability, predictability, accuracy, and mean time between failure (MTBF). \nPerformance is a measure of speed or efficiency of the running system. It imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for speed, efficiency, availability, accuracy, throughput, response time, recovery time, and resource usage.\nSupportability is the ability of the software to be easily modified to accommodate enhancements and repairs. Supportability requirements may include testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, and localizability (internationalization).\nUse cases mainly capture the functional requirements of the system.\n\nA design requirement, often called a design constraint, specifies or constrains the design of a system. \n\n\n\n\n\n
Use cases defined for a system are the basis for the entire development process. They provide the unifying thread through the system and define the behavior performed by a system. Use cases play a role in each of the core process disciplines:\nThe use-case model is a result of the requirements workflow. It models what the system should do from the user's perspective. \nIn analysis and design, use cases are realized in a design model. You create use-case realizations, which describe how the use case is performed in terms of interacting objects in the design model. This model describes, in terms of design objects, the different parts of the implemented system and how the parts should interact to perform the use cases. \nDuring implementation, the design model is the implementation specification. Because use cases are the basis for the design model, they are implemented in terms of design classes. \nDuring testing, the use cases constitute a basis for identifying test cases and test procedures. The system is verified by performing each use case.\nUse cases have other roles as well: \nBasis for planning iterative development.\nFoundation for what is described in user manuals.\nDefinition of ordering units. For example, a customer can get a system configured with a particular set of use cases.\n
To write use cases, you must find actors and use cases, outline the use cases, and then detail the use cases.\nYou must go through these activities, but the process is rarely as linear as the graphic suggests. Use-case writing is an iterative process.\n
In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully detailed description of how your system behaves.\n1. First, you find the actors of the system.\n2. Next, you find and briefly describe the use case. A brief description describes the goal in two or three sentences. When finding use cases, you may find additional actors that require you to refine the list of actors.\n3. The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify (not outline) possible alternate flows. This enables you to gain an understanding of the potential size and complexity of the use case. When outlining the use case, you may end up merging or splitting use cases.\n4. Finally, you fully detail the use case, but iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully detail and implement those during that iteration. At the end of the project, you have all of your use cases fully detailed.\nRemember, the use case writing process is an iterative process. You will likely go through many cycles of refinement before you complete your use case.\n
In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully detailed description of how your system behaves.\n1. First, you find the actors of the system.\n2. Next, you find and briefly describe the use case. A brief description describes the goal in two or three sentences. When finding use cases, you may find additional actors that require you to refine the list of actors.\n3. The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify (not outline) possible alternate flows. This enables you to gain an understanding of the potential size and complexity of the use case. When outlining the use case, you may end up merging or splitting use cases.\n4. Finally, you fully detail the use case, but iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully detail and implement those during that iteration. At the end of the project, you have all of your use cases fully detailed.\nRemember, the use case writing process is an iterative process. You will likely go through many cycles of refinement before you complete your use case.\n
Un acteur se repr&#xE9;sente soit sous la forme d&#x2019;une classe avec le st&#xE9;r&#xE9;otype &#xAB;Actor&#xBB; o&#xF9; le nom de l&#x2019;acteur appara&#xEE;t &#xE0; la place du nom de la classe, soit sous la forme d&#x2019;une figure stylis&#xE9;e d&#x2019;un homme avec le nom de l&#x2019;acteur en dessous, soit encore comme un combin&#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&#xE8;me se repr&#xE9;sente par un rectangle vide incluant son nom (nom de l&#x2019;application ou du syst&#xE8;me). Les acteurs sont ext&#xE9;rieurs au syst&#xE8;me, ils ne font qu&#x2019;interargir avec.\n
Un acteur se repr&#xE9;sente soit sous la forme d&#x2019;une classe avec le st&#xE9;r&#xE9;otype &#xAB;Actor&#xBB; o&#xF9; le nom de l&#x2019;acteur appara&#xEE;t &#xE0; la place du nom de la classe, soit sous la forme d&#x2019;une figure stylis&#xE9;e d&#x2019;un homme avec le nom de l&#x2019;acteur en dessous, soit encore comme un combin&#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&#xE8;me se repr&#xE9;sente par un rectangle vide incluant son nom (nom de l&#x2019;application ou du syst&#xE8;me). Les acteurs sont ext&#xE9;rieurs au syst&#xE8;me, ils ne font qu&#x2019;interargir avec.\n
Un acteur se repr&#xE9;sente soit sous la forme d&#x2019;une classe avec le st&#xE9;r&#xE9;otype &#xAB;Actor&#xBB; o&#xF9; le nom de l&#x2019;acteur appara&#xEE;t &#xE0; la place du nom de la classe, soit sous la forme d&#x2019;une figure stylis&#xE9;e d&#x2019;un homme avec le nom de l&#x2019;acteur en dessous, soit encore comme un combin&#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&#xE8;me se repr&#xE9;sente par un rectangle vide incluant son nom (nom de l&#x2019;application ou du syst&#xE8;me). Les acteurs sont ext&#xE9;rieurs au syst&#xE8;me, ils ne font qu&#x2019;interargir avec.\n
Un acteur se repr&#xE9;sente soit sous la forme d&#x2019;une classe avec le st&#xE9;r&#xE9;otype &#xAB;Actor&#xBB; o&#xF9; le nom de l&#x2019;acteur appara&#xEE;t &#xE0; la place du nom de la classe, soit sous la forme d&#x2019;une figure stylis&#xE9;e d&#x2019;un homme avec le nom de l&#x2019;acteur en dessous, soit encore comme un combin&#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&#xE8;me se repr&#xE9;sente par un rectangle vide incluant son nom (nom de l&#x2019;application ou du syst&#xE8;me). Les acteurs sont ext&#xE9;rieurs au syst&#xE8;me, ils ne font qu&#x2019;interargir avec.\n
Un acteur se repr&#xE9;sente soit sous la forme d&#x2019;une classe avec le st&#xE9;r&#xE9;otype &#xAB;Actor&#xBB; o&#xF9; le nom de l&#x2019;acteur appara&#xEE;t &#xE0; la place du nom de la classe, soit sous la forme d&#x2019;une figure stylis&#xE9;e d&#x2019;un homme avec le nom de l&#x2019;acteur en dessous, soit encore comme un combin&#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&#xE8;me se repr&#xE9;sente par un rectangle vide incluant son nom (nom de l&#x2019;application ou du syst&#xE8;me). Les acteurs sont ext&#xE9;rieurs au syst&#xE8;me, ils ne font qu&#x2019;interargir avec.\n
Un acteur se repr&#xE9;sente soit sous la forme d&#x2019;une classe avec le st&#xE9;r&#xE9;otype &#xAB;Actor&#xBB; o&#xF9; le nom de l&#x2019;acteur appara&#xEE;t &#xE0; la place du nom de la classe, soit sous la forme d&#x2019;une figure stylis&#xE9;e d&#x2019;un homme avec le nom de l&#x2019;acteur en dessous, soit encore comme un combin&#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&#xE8;me se repr&#xE9;sente par un rectangle vide incluant son nom (nom de l&#x2019;application ou du syst&#xE8;me). Les acteurs sont ext&#xE9;rieurs au syst&#xE8;me, ils ne font qu&#x2019;interargir avec.\n
Un acteur se repr&#xE9;sente soit sous la forme d&#x2019;une classe avec le st&#xE9;r&#xE9;otype &#xAB;Actor&#xBB; o&#xF9; le nom de l&#x2019;acteur appara&#xEE;t &#xE0; la place du nom de la classe, soit sous la forme d&#x2019;une figure stylis&#xE9;e d&#x2019;un homme avec le nom de l&#x2019;acteur en dessous, soit encore comme un combin&#xE9; des deux.\nLe conducteur est un acteur primaire\nLe garagiste est un acteur secondaire\nLa notion de syst&#xE8;me se repr&#xE9;sente par un rectangle vide incluant son nom (nom de l&#x2019;application ou du syst&#xE8;me). Les acteurs sont ext&#xE9;rieurs au syst&#xE8;me, ils ne font qu&#x2019;interargir avec.\n
\n
Actor is a role, not a particular person or thing. The name of the actor should represent, as clearly as possible, the actor&#x2019;s role.\nMake sure that there is little risk of confusing one actor&#x2019;s name with another at a future stage of the work. Also, try to avoid an actor called &#x201C;User&#x201D;, rather, try to figure out the role of that particular user.\nIn most instances, some person or some other system does something to trigger the start of the use case. If a use case in your system is initiated at a certain time, for example, at the end of the day or the end of the month, this can be modeled with a special actor, such as the &#x201C;scheduler&#x201D; or &#x201C;time.&#x201D; &#x201C;Scheduler&#x201D;, as opposed to &#x201C;time&#x201D;, is a useful name for such an actor because scheduler may be human or non-human. \n
\n
Attention jefais le choix de transforemer le catalogue comme qq d&#x2019;existant d&#x2019;ou l&#x2019;acteur.\n\nAu d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n\n\n\nAu d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
Au d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
to describe each actor in detail . \nInclude this information in each brief description for each actor:\nWhat or whom the actor represents\nWhy the actor is needed\nWhat the actor&#x2019;s area of responsibility is \nWhat interests the actor has in the system\nSome information about the actors is also shown on use-case diagrams, which show the name of the actor and the actor&#x2019;s relationships with use cases.\n
actuers externes : porteurs de carte \nDistribut et lecteur sont interne pas des acteurs : sauf si nous ne gerons que la partie interne.\ncarte : oui et non. C&#x2019;est un acteur physique que l&#x2019;on garde ou non...\nmais aussi des clients...\nSyst&#xE8;me d&#x2019;autorisation\nSysteme d&#x2019;information de la banque\n\n\n\n\n\n\n
\n
\n
Attention jefais le choix de transforemer le catalogue comme qq d&#x2019;existant d&#x2019;ou l&#x2019;acteur.\n\nAu d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
Attention jefais le choix de transforemer le catalogue comme qq d&#x2019;existant d&#x2019;ou l&#x2019;acteur.\n\nAu d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n\n\n\nAu d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
\n
\n
\n
\n
\n
\n
\n
actuers externes : porteurs de carte \nDistribut et lecteur sont interne pas des acteurs : sauf si nous ne gerons que la partie interne.\ncarte : oui et non. C&#x2019;est un acteur physique que l&#x2019;on garde ou non...\nmais aussi des clients...\nSyst&#xE8;me d&#x2019;autorisation\nSysteme d&#x2019;information de la banque\n\n\n\n\n\n\n
In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully detailed description of how your system behaves.\n1. First, you find the actors of the system.\n2. Next, you find and briefly describe the use case. A brief description describes the goal in two or three sentences. When finding use cases, you may find additional actors that require you to refine the list of actors.\n3. The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify (not outline) possible alternate flows. This enables you to gain an understanding of the potential size and complexity of the use case. When outlining the use case, you may end up merging or splitting use cases.\n4. Finally, you fully detail the use case, but iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully detail and implement those during that iteration. At the end of the project, you have all of your use cases fully detailed.\nRemember, the use case writing process is an iterative process. You will likely go through many cycles of refinement before you complete your use case.\n
This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system's functional requirements in terms of use cases. \nIt is a model of the system's intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, "models" the restaurant's behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system's functional requirements in terms of use cases. \nIt is a model of the system's intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, "models" the restaurant's behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system's functional requirements in terms of use cases. \nIt is a model of the system's intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, "models" the restaurant's behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
This slide lists several questions that can help you find the use cases in your system. The best way to find use cases is to consider what each actor requires of the system. Go through all of the actors and identify the particular needs of each actor.\nWhen you have made your first list of use cases, verify that all required functionality has been addressed. Include special use cases for system startup, termination, or maintenance. Also, include use cases for automatically scheduled events. For example, a time-initiated job may run the payroll at midnight on the last day of each month. Use cases that concern automatically scheduled events are usually initiated by a special actor: the Scheduler.\nTry to keep all use cases at approximately the same level of importance. The notion of use-case levels as popularized by some authors is not recommended, because it can lead to a functionally decomposed system. \nThese questions can help you get to the appropriate level of granularity (also see the definition of a use case). Ask yourself:\nWould you ever want to perform a particular activity as an end result in itself?\nAre there any activities that should be kept together, so you can review, modify, test, and document them together?\nIs the use case too complex? If it is, you may want to split it (a use-case report significantly longer than 10 pages may be a candidate).\nDoes it deliver something of value to multiple actors? If so, it may be too large.\n\nAfter you have identified the actors, finding the use cases is the next step in developing your use-case model. Use cases describe what an actor wants a system to do that provides some value to the actor. \nUse this process to identify the use cases for each actor.\nStart with the highest-priority actor. For all actors, but individually, ask:\nWhat goals are they trying to achieve with the system?\nHow will the solution help them do their jobs?\nHow will the solution change their jobs?\n
\n
Au d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
Au d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &#x201C;The student registers for a course?&#x201D; Does it make sense to say, &#x201C;The student takes a course?&#x201D; \nAnother approach is to ask, &#x201C;Why does the actor want to use the system?&#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &#x201C;The student registers for a course?&#x201D; Does it make sense to say, &#x201C;The student takes a course?&#x201D; \nAnother approach is to ask, &#x201C;Why does the actor want to use the system?&#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &#x201C;The student registers for a course?&#x201D; Does it make sense to say, &#x201C;The student takes a course?&#x201D; \nAnother approach is to ask, &#x201C;Why does the actor want to use the system?&#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &#x201C;The student registers for a course?&#x201D; Does it make sense to say, &#x201C;The student takes a course?&#x201D; \nAnother approach is to ask, &#x201C;Why does the actor want to use the system?&#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n\nEach use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &#x201C;The student registers for a course?&#x201D; Does it make sense to say, &#x201C;The student takes a course?&#x201D; \nAnother approach is to ask, &#x201C;Why does the actor want to use the system?&#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
Relationships between actors and use cases are called communicates-associations. A communicates-association between an actor and a use case indicates that they interact: The actor participates in and communicates with the system containing the use case. A communicates-association is represented on UML diagrams as a solid line.\n
Relationships between actors and use cases are called communicates-associations. A communicates-association between an actor and a use case indicates that they interact: The actor participates in and communicates with the system containing the use case. A communicates-association is represented on UML diagrams as a solid line.\n
\n
\n
\n
On ne sait pas distinguerle SI Automatique et de la nanque en fonction de qui fait le retrait, cela pose un prbem, du coup on passe &#xE0; la mod&#xE9;lisation suivante\n
distingue bien les acteurs secondaires\n
Each use case should have a name that indicates what is achieved by its interactions with the actor(s).\nA good rule of thumb (but not dictated by any standard) is to attach the actor&#x2019;s name (of the primary actor) at the beginning of the use-case name to see if it makes a meaningful sentence. For example, does it make sense to say &#x201C;The student registers for a course?&#x201D; Does it make sense to say, &#x201C;The student takes a course?&#x201D; \nAnother approach is to ask, &#x201C;Why does the actor want to use the system?&#x201D;\nBe focused on identifying the goal that is trying to be attained by using the system.\n
Au d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
The above is an example use case in a fire alarm monitoring system. The Supervisor is the person who administers the system and starts the monitoring. \nA passive sensor is a smoke detector that requires the system to ask for its status. An active sensor is a smoke detector that automatically sends its status to the system every 60 seconds. A hybrid sensor is a smoke detector that sends its status every 60 seconds, but it can also receive status requests from the system. In this system, if the system does not hear from it in 75 seconds then the system asks the sensor for its status.\nObserve how the top example conveys important characteristics of the actors surrounding the system. The information describing who starts the use case would be contained in the use-case description. For example: &#x201C;This use case starts when the Supervisor activates the alarm monitoring.&#x201D;\nThe bottom example only shows the actor that starts the use case. This means the way the actors communicate with the system is relegated to the description of the actor. But this form is usually more palatable for non-UML savvy stakeholders.\nArrowheads are optional in UML, only use them if they help to clarify the diagrams. Whatever standard you adopt, it should be clearly specified in Use-Case-Modeling Guidelines for the project. The Golden Rule for use-case-model guidelines: to effectively communicate the requirements to ALL stakeholders.\nNote: It is the exception to see two navigation arrows pointing towards a use case. Most of the time you have one arrow pointing in and the rest pointing out. The top example is present to reinforce that the navigation arrow is about indicating who initiates each interaction, not who obtains the goal or who initiates the use case.\n
Attention jefais le choix de transforemer le catalogue comme qq d&#x2019;existant d&#x2019;ou l&#x2019;acteur.\n\nAu d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n\n\n\nAu d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
\n
\n
Here is an example that raises questions that need to be answered by the customer or user:\nAre the use cases too small?\nDoes the diagram cover all activities? \nHow do you know what is done in each use case?\nYou might notice that the Student and the Professor interact with the system during Close Registration. Does this mean that they have to be present when registration closes? No, it doesn&#x2019;t. They are informed of the outcome through e-mail or postal mail. Another technique is to make the e-mail server or the postal service an actor. There is no right or wrong answer; both are correct. Use whichever method more clearly conveys your requirements.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
\n
\n
actuers externes : porteurs de carte \nDistribut et lecteur sont interne pas des acteurs : sauf si nous ne gerons que la partie interne.\ncarte : oui et non. C&#x2019;est un acteur physique que l&#x2019;on garde ou non...\nmais aussi des clients...\nSyst&#xE8;me d&#x2019;autorisation\nSysteme d&#x2019;information de la banque\n\n\n\n\n\n\n
\n
\n
\n
\n
\n
This list of actor checkpoints is a summary of the list in the IBM&#xAE; Rational Unified Process&#xAE; (RUP &#xAE;&#xF87F;). \n\n
This list of actor checkpoints is a summary of the list in the IBM&#xAE; Rational Unified Process&#xAE; (RUP &#xAE;&#xF87F;). \n\n
This list of actor checkpoints is a summary of the list in the IBM&#xAE; Rational Unified Process&#xAE; (RUP &#xAE;&#xF87F;). \n\n\n Tous les CRUD use cases ont &#xE9;t&#xE9; &#xE9;limin&#xE9;s.\n Create, Retrieve, Update, Delete\n
This list of actor checkpoints is a summary of the list in the IBM&#xAE; Rational Unified Process&#xAE; (RUP &#xAE;&#xF87F;). \n\n\nUn diagramme de cas d'utilisation doit toujours rester simple\n Donner un nom parlant (verbe) &#xE0; chaque cas d'utilisation\n Compl&#xE9;ter la sp&#xE9;cification du cas d'utilisation\n Par une description textuelle\n Eventuellement &#xE0; l'aide du diagramme d'activit&#xE9;\n\n Ne pas mod&#xE9;liser &#xE0; un niveau de d&#xE9;tail trop pr&#xE9;cis\n\n\n\n\n Ne pas mod&#xE9;liser en dehors de l'application\n
This list of actor checkpoints is a summary of the list in the IBM&#xAE; Rational Unified Process&#xAE; (RUP &#xAE;&#xF87F;). \n\n\nUn diagramme de cas d'utilisation doit toujours rester simple\n Donner un nom parlant (verbe) &#xE0; chaque cas d'utilisation\n Compl&#xE9;ter la sp&#xE9;cification du cas d'utilisation\n Par une description textuelle\n Eventuellement &#xE0; l'aide du diagramme d'activit&#xE9;\n\n Ne pas mod&#xE9;liser &#xE0; un niveau de d&#xE9;tail trop pr&#xE9;cis\n\n\n\n\n Ne pas mod&#xE9;liser en dehors de l'application\n
Business value is based on increased revenues, decreased expenses, or intangible benefits. Where disagreements occur, quantify and compare dollar values.\nRisk is based on the known architectural risks associated with implementing the functionality in the use case, the degree of complexity of development, or the amount of uncertainty about the solution. For packaged or commercial off-the-shelf (COTS) solutions, consider integration risks as primary.\nTime-limit the sessions for assessing business values and technical risks.\nAssign a value of high, medium, or low to the business value or risk.\nAs a result of assessing business value and technical risk, you will know which use cases to outline and define in detail first. \n
This list of actor checkpoints is a summary of the list in the IBM&#xAE; Rational Unified Process&#xAE; (RUP &#xAE;&#xF87F;). \n\n\nUn diagramme de cas d'utilisation doit toujours rester simple\n Donner un nom parlant (verbe) &#xE0; chaque cas d'utilisation\n Compl&#xE9;ter la sp&#xE9;cification du cas d'utilisation\n Par une description textuelle\n Eventuellement &#xE0; l'aide du diagramme d'activit&#xE9;\n\n Ne pas mod&#xE9;liser &#xE0; un niveau de d&#xE9;tail trop pr&#xE9;cis\n\n\n\n\n Ne pas mod&#xE9;liser en dehors de l'application\n
This list of actor checkpoints is a summary of the list in the IBM&#xAE; Rational Unified Process&#xAE; (RUP &#xAE;&#xF87F;). \n\n\nUn diagramme de cas d'utilisation doit toujours rester simple\n Donner un nom parlant (verbe) &#xE0; chaque cas d'utilisation\n Compl&#xE9;ter la sp&#xE9;cification du cas d'utilisation\n Par une description textuelle\n Eventuellement &#xE0; l'aide du diagramme d'activit&#xE9;\n\n Ne pas mod&#xE9;liser &#xE0; un niveau de d&#xE9;tail trop pr&#xE9;cis\n\n\n\n\n Ne pas mod&#xE9;liser en dehors de l'application\n
Here is an example that raises questions that need to be answered by the customer or user:\nAre the use cases too small?\nDoes the diagram cover all activities? \nHow do you know what is done in each use case?\nYou might notice that the Student and the Professor interact with the system during Close Registration. Does this mean that they have to be present when registration closes? No, it doesn&#x2019;t. They are informed of the outcome through e-mail or postal mail. Another technique is to make the e-mail server or the postal service an actor. There is no right or wrong answer; both are correct. Use whichever method more clearly conveys your requirements.\n
In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully detailed description of how your system behaves.\n1. First, you find the actors of the system.\n2. Next, you find and briefly describe the use case. A brief description describes the goal in two or three sentences. When finding use cases, you may find additional actors that require you to refine the list of actors.\n3. The next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify (not outline) possible alternate flows. This enables you to gain an understanding of the potential size and complexity of the use case. When outlining the use case, you may end up merging or splitting use cases.\n4. Finally, you fully detail the use case, but iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully detail and implement those during that iteration. At the end of the project, you have all of your use cases fully detailed.\nRemember, the use case writing process is an iterative process. You will likely go through many cycles of refinement before you complete your use case.\n
Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &#x201C;detours&#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &#x201C;detours&#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &#x201C;detours&#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &#x201C;detours&#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &#x201C;detours&#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &#x201C;detours&#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
Developing a use-case sequence of actions is an iterative process. Start by developing an outline or draft, such as the one on this page. Later, add the descriptions. The outlines are not official documents, but merely a start toward developing a document. \nThe basic flow shows the major steps in accomplishing the goal of the use case.\n The alternative flows show alternatives behavior (what may go wrong and optional behavior). At this point in the process, it is enough to identify the most significant alternatives without describing them in detail.\n\nThe outline of the flow of events for a use case has two main sections:\nBasic Flow of Events\nAlternative Flow of Events\nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up and finish.\nThe basic flow of events should be relatively short and easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &#x201C;detours&#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for more than 25 credit hours differently.\nExceptional (error) flows: Invalid student ID number.\nNote: The diagram on the slide is informational only and is not a valid UML diagram.\n
This is an example of a step-by-step outline for the Register for Courses use case. The basic flow shows the major steps. The alternative flows show optional or conditional behavior.\nNotice the level of detail in this example. Remember, this is just a brief step-by-step outline to help you understand what functions are contained in the use case. These steps are described further in a later module.\n\nThis is an example of a step-by-step outline for the Register for Courses use case. The basic flow shows the major steps. The alternative flows show optional or conditional behavior.\nNotice the level of detail in this example. Remember, this is just a brief step-by-step outline to help you understand what functions are contained in the use case. These steps are described further in a later module.\n
Reasons to outline your use cases:\nIterative development reduces risk. For the same reason that you do not implement the whole system at once, you do not develop the detailed requirements all at once.\nAvoid writing too much detail too early.\nYou do not know everything at first. Outlining helps you discover what you don&#x2019;t know.\nOutlining use cases creates a rough draft to use as a starting point for fully specifying your use cases.\nOutlining helps determine whether the use case is too small on its own or too big to be just one use case. It might also help you decide whether the use case is actually more than just one use case. \nAfter you outline your steps, you might find that they really belong in another use case. Also, if the outline shows that the use case does not have much to it, it may not be a use case at all. \nOutlining adds value to finding all possible alternate flows.\n
This is an example of a step-by-step outline for the Register for Courses use case. The basic flow shows the major steps. The alternative flows show optional or conditional behavior.\nNotice the level of detail in this example. Remember, this is just a brief step-by-step outline to help you understand what functions are contained in the use case. These steps are described further in a later module.\n
A use-case scenario describes an instance of using the system (an instance of a use case). It is one path through a use case that flows from its beginning to one of its end points.\nEach use case has a web of flows of events, with a scenario as just one description of a particular path through the web. The scenario might involve the basic flow and any number of alternative flows in any number of combinations.\nQuestion: How many scenarios do you need? \nSimple answer: As many as you need to understand the system that you are developing. \n
Note: The RUP use-case specification template contains a section for listing key scenarios. \nDocumenting scenarios is useful because, although you write flows (basic, alternative, subflows) in a use case, you implement and test scenarios.\nEach scenario captures a family of test cases. Each test case in the family follows the same path through the use case, but uses different data values to ensure that all of the boundary conditions are tested.\nIn iterative development, when software architects propose the technical contents and the order of successive iterations, they select a certain number of architecturally significant scenarios and use cases to analyze and design first.\nAccording to Use Case Modeling, a book by Kurt Bittner and Ian Spence, capturing scenarios is useful for these reasons:\nThe scenarios will match your test cases.\nScenarios are what actually gets performed, so they are useful for discussing what the system will do in practice.\nScenarios are useful for analysis and design, because they help the developers think about how the system will be used.\n
Capture scenarios in a separate section of your use-case specification or as part of your test cases. The benefit of capturing the scenarios in the use-case specification is that all of the information required for analysis, design, and testing is then included with the use-case specification.\nGive the scenario a descriptive name and list the flows (in order) that make up the scenario.\nIt&#x2019;s a good practice to elaborate the scenarios of the interesting and high-risk use cases. You can use scenarios to understand, as well as to validate, the use-case flows of events. \nSome people write scenarios first and then extract use cases, but others find use cases first and validate those use cases by writing scenarios. Scenarios make excellent test cases.\nScenarios do not contain details of the system input or output data. That information forms part of your test cases.\n
This is an example of a step-by-step outline with some key scenarios identified for the Register for Courses use case. \n
In the process of writing use cases, functional and non-functional requirements specific to a use case will be captured in the use-case specification. For those that cannot be applied to specific use cases, you can put them in a document such as the Supplementary Specifications.\nAlthough many of the functional requirements will be documented in use cases, there are some functional requirements that cannot be applied to specific use cases. \n\nAmong those are reporting, auditing, printing, security, licensing support or enforcement, and authentication requirements. Document these functional requirements in the Supplementary Specification. \n
In the process of writing use cases, functional and non-functional requirements specific to a use case will be captured in the use-case specification. For those that cannot be applied to specific use cases, you can put them in a document such as the Supplementary Specifications.\nAlthough many of the functional requirements will be documented in use cases, there are some functional requirements that cannot be applied to specific use cases. Among those are reporting, auditing, printing, security, licensing support or enforcement, and authentication requirements. Document these functional requirements in the Supplementary Specification. \n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Detailing the use-case description is where the &#x201C;real work&#x201D; in use-case modeling occurs. The outline of the flow of events in each use case that you developed earlier lacks important details. The main purpose of detailing a use case is to elaborate the step-by-step outline of the flow of events. \nWithout a detailed description of the flows of events, it is nearly impossible to implement a solution. The reason is that the use-case outline does not contain any real software requirements. Instead, the outline just contains a high-level description of the flows.\nThe detailed flow of events includes what the actor does and what the system does in response. \n
\n
A precondition for a use case is a condition in the system that must be true before the use case can begin. For example, the list of course offerings must be available before a student can register for courses. Otherwise, the student could not select from the course list.\nA precondition is not the event that starts the use case. For example, if a use case is written in such a way that logging on to the system is the first event in the use case, then logging on is not a precondition. But if a use case is written so that logging on must happen before the use case begins, then &#x201C;The user has logged on to the system&#x201D; would be a precondition.\nPreconditions reduce the need for validation inside the use-case flows. In this example, you do not need to test whether the course offerings are available anywhere in the use-case flows of events, because, by definition, they must have been available or the use case could not execute.\nPreconditions do not describe things outside of the system. For example, &#x201C;The customer has a valid PIN&#x201D; would be an invalid precondition. Validating the PIN is something that the system does in the use case.\nPreconditions are optional. They are used only if they are needed for clarification.\nNote: Preconditions can also be used at the beginning of an alternative flow or subflow. More commonly, they are used only on the basic flow. An example of using a precondition on an alternative flow is to describe security. If only certain actors can perform a given flow, you could attach a precondition to that flow to ensure that the user has the appropriate authentication to perform the flow.\n
\n
This is a template for a Use-Case Specification.\nFor each use case, start with the step-by-step outline and gradually add detail to each step. You want to understand what really happens so you do not miss anything. Typically, you begin with refining the basic flow, and then refine the alternative flows. \nWork with system users to revise and detail the outline. Expect to revise the outline and the details many times.\nThere is no minimum or maximum size for a Use-Case Specification. It needs to be big enough to contain an unambiguous description of how the system behaves, yet short enough to be as concise as you can . Be sure that your description is complete and that you have answered all of the questions that people may have about the events in the use case. \nThe Use-Case Specification describes the details of a particular use case. In addition to the Flow of Events, there are other properties that detail a use case. It is best to use a standard template for your use cases, such as the one shown here (from the IBM&#xAE; Rational Unified Process&#xAE;). Regardless of whether you have any properties within the section, use the standard outline.\n
When you detail each step in the outline, be sure to describe the flow of events, not only what the system is doing. A suggestion for how to enforce this is to start every step with &#x201C;When the [actor] ....&#x201D; \nWhen possible, make each step in the flow of events show a roundtrip of events, usually in the form of messages: \nWhat the actor does: <Actor> sends a message to <System>, and....\nWhat the system does in response: <System> sends a message to <An Actor>....\nMaking each step a roundtrip ensures testability, ensures adherence to the purpose of a use case, and makes sequence diagrams easier to develop and read. \nSome interactions are system-controlled. That is, after the user&#x2019;s request that begins the use case, the system controls the interaction: The system asks for information and the user supplies information, and so on. In these cases, a roundtrip within a step would begin with system actions and then have the user respond.\n
The distinction between chooses and decides: \nDecides can be totally unrelated to the system. For example, the Professor can decide to submit grades while eating breakfast or while driving to campus. \nChooses, on the other hand, implies an interaction with the system.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Here is a list of questions to help you make decisions about the details in the flow of events.\nAlternative flows describe how the system should behave when things go wrong or when unusual things happen. \nWhen working on the alternative flows, questions regarding the behavior of the system are bound to surface. List these questions and have the system users answer what the system is supposed to do, and how they expect to interact with the system in each scenario. Understanding the alternatives is an important step in clarifying the requirements. \nAt this point in the process, however, it is enough to identify the alternatives without describing them in detail.\n
\n
A postcondition defines the state that the system is in at the end of a use case. In many cases, you can omit the postcondition entirely when the result of the use case is obvious or when there is no significant state change in the system. \nWhen you need to call attention to the different conditions that may exist when a use case completes, you can enumerate all the postconditions. \nPostconditions can be a powerful tool for developing use cases. You must first define what the use case is supposed to achieve (the postcondition). Then describe the different ways to reach this condition (the flow of events needed).\n
\n
\n
\n
\n
\n
\n
A use-case scenario describes an instance of using the system (an instance of a use case). It is one path through a use case that flows from its beginning to one of its end points.\nEach use case has a web of flows of events, with a scenario as just one description of a particular path through the web. The scenario might involve the basic flow and any number of alternative flows in any number of combinations.\nQuestion: How many scenarios do you need? \nSimple answer: As many as you need to understand the system that you are developing. \n\nNote: The RUP use-case specification template contains a section for listing key scenarios. \nDocumenting scenarios is useful because, although you write flows (basic, alternative, subflows) in a use case, you implement and test scenarios.\nEach scenario captures a family of test cases. Each test case in the family follows the same path through the use case, but uses different data values to ensure that all of the boundary conditions are tested.\nIn iterative development, when software architects propose the technical contents and the order of successive iterations, they select a certain number of architecturally significant scenarios and use cases to analyze and design first.\nAccording to Use Case Modeling, a book by Kurt Bittner and Ian Spence, capturing scenarios is useful for these reasons:\nThe scenarios will match your test cases.\nScenarios are what actually gets performed, so they are useful for discussing what the system will do in practice.\nScenarios are useful for analysis and design, because they help the developers think about how the system will be used.\n
A use-case instance describes one particular path through the flows of events described in a use case. It is a specific sequence of actions that illustrates the behavior of the system. This is also called a scenario. In the example here, the sketch of Scenario 1 for the Register for Courses use case shows a Student interacting with the Course Registration System and successfully enrolling in a course the first time. Scenario 2 shows a Student interacting with the Course Registration System and entering an invalid subject; that student must re-enter the subject before successfully getting the course list.\nA use case defines a set of related scenarios. A use case represents all the possible sequences that might happen until the resulting value is achieved or until the system terminates the attempt. The Register for Courses use case represents both of these sequences, and all the other possible sequences of interactions that may occur when a Student tries to enroll in a course.\nUsers and stakeholders can often identify the sequence of actions they want to perform to obtain a result. Asking stakeholders for the sequence of actions they perform is a good way to start identifying the steps in a use case.\n
Use cases typically have a great deal of cross-referenced information within them. The overhead of maintaining this cross-referencing is what typically causes use cases to become out of date. To make maintenance easier, refer to a use case step by its label rather than by number. If you change the text of the label, then the location that references the label also needs to be updated.\nWord processors and page layout software , such as Microsoft&#xAE; Word and Adobe&#xAE; FrameMaker&#xAE;, have book-marking and cross-referencing capabilities that can make the maintenance of cross-references easier. \n\nThis is an example of how to write a subflow. Notice that subflows are in a separate section in the Use-Case Specification. In this style, the subflow names have an identifier in front of them (S1, S2 , and so on) to help identify them as subflows.\nUnlike alternative flows, subflows do not need a line that says where they return to, because they always return to the line after the line from which they were called. \nIn this example, when the subflow S1: Obtain Course Information completes, the flow will resume at 4. Select Courses.\n\n\nA complex flow of events should be further structured into subflows. The main goal should be to improve the readability of the text. Subflows can be invoked many times from many places. Remember that the use case can perform subflows in optional sequences, in loops, or even several at the same time.\nThe difference between an alternative flow and a subflow is that alternative flows are insert themselves into another flow. The flow it inserts itself into has no knowledge of the alternative flow. An alternative flow may also resume at any place within the use case.\nA subflow is explicitly called from a flow. When a subflow completes, it always returns to the line after the line that it was called from. It is similar in concept to a subroutine call in some programming languages.\nSubflows are not listed as part of a scenario. By definition, if the calling flow is in the scenario, the subflow is also in the scenario.\nAs with any other flow, a subflow may have alternative flows.\n\n
\n
\n
\n
A postcondition defines the state that the system is in at the end of a use case. In many cases, you can omit the postcondition entirely when the result of the use case is obvious or when there is no significant state change in the system. \nWhen you need to call attention to the different conditions that may exist when a use case completes, you can enumerate all the postconditions. \nPostconditions can be a powerful tool for developing use cases. You must first define what the use case is supposed to achieve (the postcondition). Then describe the different ways to reach this condition (the flow of events needed).\n
One of the most difficult aspects of writing good use cases is capturing the correct level of detail.\nIt is important to capture all of the requirements but not stray into designing the system or the user interface.\nBoth end users and subject-matter experts are stakeholders of the system, thus they can drive requirements from different perspectives. When using an ATM to withdraw cash, end users may be interested only that the machine dispenses the right amount of money and prints a receipt. But a subject-matter expert is interested in far more. For instance, the banking subject-matter expert is interested in what the ATM does to ensure that the transaction is recorded correctly and that the transaction is communicated to the bank for processing. Therefore, a use case should capture requirements from different stakeholders. (Bittner and Spence, 2002)\n
There are many reasons why a project may be pushed or pulled toward a specific level of detail with use cases.\nDevelopers&#x2019; demands &#x2013; Developers rely on use cases as their only user interface or business rule definition, thus they demand more and more detail in them so they can develop effectively.\nTransition from old requirements process &#x2013; Most older styles of gathering requirements for software projects involve substantial hierarchies of more and more decomposed requirements. \nWaterfall approaches &#x2013; In waterfall methods, analysts are pressured early in the project lifecycle to capture all of the requirements to 100% completeness that anyone might need downstream. This leads to large, very detailed requirement sets.\nLow modeling sophistication of the team &#x2013; Object-Oriented Analysis and Design (OOAD) associates responsibilities with components in the design processes through use case realizations in sequence diagrams and class models. User interface design can be similarly broken down using more systematic approaches. Use cases often include information that should be in the intermediate design artifacts.\nExperienced analysts &#x2013; The more experienced the analysts are in multiple aspects of software development, the better they understand the implications of inappropriate level of detail.\nExperienced architects &#x2013;Software architects who understand the appropriate level of detail for use cases as input to their fundamental work will be the most powerful force for better practices.\nBetter techniques and methods &#x2013; If the method calls for useful intermediate work products and artifacts and provides guidance on how and when to create them, that&#x2019;s a powerful force for appropriate level of detail.\n
User Story vs Use Case\n\nOn m&#x2019;a souvent pos&#xE9; la question :C&#x2019;est quoi la diff&#xE9;rence entre un use case et une user story? La r&#xE9;ponse n&#x2019;est pas simple pour moi. Bien que la diff&#xE9;rence de concept semble claire, dans les faits, c&#x2019;est plus complexe.On r&#xE9;vise:Definition wikipedia:User Story&#xAB; Une user story (histoire utilisateur) est une exigence logicielle formul&#xE9;e en une ou plusieurs phrases dans le langage de tous les jours ou celui li&#xE9; au m&#xE9;tier l&#x2019;utilisateur. Les user stories sont utilis&#xE9;es dans le d&#xE9;veloppement logiciel dit Agile comme sp&#xE9;cifications (en m&#xEA;me temps que les tests d&#x2019;acceptance). Le formalisme est limit&#xE9; &#xE0; un carte de type post-it. &#xBB;Use Case&#xAB; Un use case (cas d&#x2019;utilisation) dans l&#x2019;ing&#xE9;nierie logicielle et syst&#xE8;me est une description du comportement d&#x2019;un syst&#xE8;me en r&#xE9;ponse &#xE0; une requ&#xEA;te externe au syst&#xE8;me lui-m&#xEA;me. En d&#x2019;autres termes, le use case d&#xE9;crit &#xAB; qui &#xBB; fait &#xAB; quoi &#xBB; avec le syst&#xE8;me en question. La technique des use case est utilis&#xE9;e pour d&#xE9;finir les exigences de comportement d&#x2019;un syst&#xE8;me en d&#xE9;taillant les exigences fonctionnelles avec un approche sc&#xE9;narios. &#xBB;Wikipedia en propose m&#xEA;me la comparaison:&#xAB; Bien que les use cases et user stories proposent tous les deux une solution de d&#xE9;finition des exigences utilisateur en terme d&#x2019;interactions entre celui-ci et le syst&#xE8;me, il y a des diff&#xE9;rences majeures entre eux.Les user stories proposent un format l&#xE9;ger et facile &#xE0; comprendre de l&#x2019;information. Elles sont la plus part du temps formul&#xE9;es dans le langage de tous les jours de l&#x2019;utilisateur et contiennent peu de d&#xE9;tail. Elles doivent aider le lecteur &#xE0; comprendre ce que le logiciel doit faire.Les use cases, eux, d&#xE9;crivent un process et le d&#xE9;taillent pas &#xE0; pas, ils sont plus formels. Un use case doit fournir le niveau d&#xE9;tail suffisant pour &#xEA;tre compris seul. Un use case est d&#xE9;crit comme &#xAB; une description g&#xE9;n&#xE9;rale des interactions entre le syst&#xE8;me et un ou plusieurs acteurs, les acteurs pouvant &#xEA;tre des personnes ou d&#x2019;autres syst&#xE8;mes. &#xBB;&#xBB;(Traduction par mes soins, donc soyez indulgents et surtout vigilants.)Bon, avec tout &#xE7;a, on est bien avanc&#xE9; !\nUse case, forte connotation proc&#xE9;durale, merci UML\nUser story, pas assez formel, mais bien test&#xE9;.\n\n\n\nDans son livre d&#xE9;di&#xE9; &#xE0; Scrum[1], Claude Aubry propose (en &#xA7;13.5.5) une facette int&#xE9;ressante sur ce d&#xE9;bat :\n&#xAB; La technique des user stories n&#x2019;est pas une technique de sp&#xE9;cification &#xBB;, ce en quoi il a tout &#xE0; fait raison, puisque les exigences dans scrum sont d&#xE9;finies et d&#xE9;taill&#xE9;es lors de la r&#xE9;union de planification du sprint et non pas avant: cqfd.\nEt &#xAB; il est pr&#xE9;f&#xE9;rable de dialoguer&#x2026; &#xBB; combin&#xE9; avec &#xAB; r&#xE9;diger des tests fonctionnels et les passer&#x2026; &#xBB;\nOn voit l&#xE0; bien l&#x2019;approche radicalement diff&#xE9;rente, qui est plus dans le processus global de construction du projet que dans l&#x2019;&#xE9;l&#xE9;ment m&#xEA;me du use case ou de la user story.\n\nUn autre point indiqu&#xE9; par Claude est le fait que par d&#xE9;finition un use case ne peut &#xEA;tre utilis&#xE9; dans un backlog, puisqu&#x2019;il ne rempli pas les conditions d&#x2019;entr&#xE9;e dans un sprint. Encore une fois, je suis enti&#xE8;rement d&#x2019;accord, mais c&#x2019;est plus discutable, en tout cas, il faut un peu plus d&#x2019;exp&#xE9;rience &#xAB; agile &#xBB; pour comprendre ce point. Je vais essayer d&#x2019;expliquer plus clairement ce point l&#xE0; : Ne peuvent entrer dans un sprint que des &#xE9;l&#xE9;ments suffisamment fins au regard de la v&#xE9;locit&#xE9; de l&#x2019;&#xE9;quipe (A&#xEF;, a&#xEF;, j&#x2019;en ai perdu en route). Comme nous l&#x2019;avons vu pr&#xE9;c&#xE9;demment, une user story est par d&#xE9;finition succincte et utilise un format l&#xE9;ger, cela entraine une granularit&#xE9; assez fine et donc une complexit&#xE9;/charge relativement petite la plus part du temps. Dans le cas o&#xF9; une user story ne serait pas assez &#xAB; fine &#xBB;, alors elle ne pourrait &#xEA;tre &#xE0; consid&#xE9;rer dans le prochain sprint.\nPour les use cases, la notion de complexit&#xE9;/charge n&#x2019;intervient jamais dans leur cr&#xE9;ation. En cons&#xE9;quence leur niveau de granularit&#xE9; n&#x2019;est pas adapt&#xE9; aux sprints. Bien sur, il est possible de d&#xE9;couper les use cases en scenarios, puis en diagrammes d&#x2019;&#xE9;tats et ainsi avoir une granularit&#xE9; suffisante pour &#xEA;tre utilis&#xE9; dans un backlog. Mais on perd la vision utilisateur dans ce cas.\n\n\n\nJe rajouterai pour ma part et pour vous aidez &#xE0; faire le choix, les quelques id&#xE9;es et conseils suivants :\n\nPour moi, la vraie diff&#xE9;rence est dans la construction du logiciel lui-m&#xEA;me.\nLes use cases d&#xE9;crivent un syst&#xE8;me entier et d&#xE9;j&#xE0; pre-pens&#xE9; (cahier des charges, appel d&#x2019;offres,&#x2026;).\n\nLes use cases ne supportent pas tr&#xE8;s bien le mode it&#xE9;ratif, ou alors comme l&#x2019;avait &#xE9;voqu&#xE9; Pascal Roques lors de sa pr&#xE9;sentation sur la mod&#xE9;lisation Agile (SigmaT 8), il ne faut pas avoir peur de jeter son mod&#xE8;le &#xE0; la poubelle et ne pas chercher d&#xE9;sesp&#xE9;r&#xE9;ment &#xE0; le maintenir.\nLes use cases &#xE0; eux seuls ne servent &#xE0; rien, il faut toute la suite des 13 sch&#xE9;mas UML et outils associ&#xE9;s.\nC&#x2019;est trop orient&#xE9; architecture, et moi je m&#x2019;en fiche de savoir si mon logiciel est en java ou en C# avec un poisson givr&#xE9;, un patron-java ou un flexible dans&#x2026;, Je veux qu&#x2019;il marche !\n\nLes user stories sont faites pour d&#xE9;crire simplement la mani&#xE8;re dont l&#x2019;utilisateur pourra utiliser son logiciel. On pourra lui ajouter pleins de nouvelles fonctions super utiles, les user stories se compl&#xE8;tent les unes aux autres, pas besoin d&#x2019;un processus lourd, d&#x2019;un outil de mod&#xE9;lisation, le backlog est l&#xE0; (je parle de post-it, au mieux un fichier, pas d&#x2019;outils de gestion de projet). Les user stories ont par d&#xE9;finition aussi cette notion d&#x2019;utilit&#xE9; et/ou de priorit&#xE9; que n&#x2019;ont pas les use cases.\n\nJe pr&#xE9;f&#xE8;re l&#x2019;utilisation des user stories dans le contexte de d&#xE9;marrage de nouveaux projets. L&#x2019;aspect &#xAB; quelle solution me propose mon logiciel pour faire &#xE7;a &#xBB; me plait pas mal, le logiciel orient&#xE9; service &#xE0; son utilisateur ! Plus facile pour discuter avec le client du client (SSII et sous traitance obligent) lors d&#x2019;un atelier sans qu&#x2019;il ait eu besoin d&#x2019;apprendre UML.\n\nEncore un point, on ne peut pas tous d&#xE9;finir en use case :\n&#xAB; En tant qu&#x2019;utilisateur, je veux que l&#x2019;icone clignote quand je re&#xE7;ois un mail &#xBB;, vous traduisez &#xE7;a comment en use case ? C&#x2019;est, &#xE0; la limite, une des 2000 exigences du use case &#xAB; Recevoir un message &#xBB;\n\nEt puis si vous ne savez toujours pas quoi prendre, reste la solutio Mac ou Windows ?\no &#xAB; Je veux acheter un nouvel ordinateur, c&#x2019;est bien Max ? &#xBB;\no &#xAB; bein, t&#x2019;as quoi pour l&#x2019;instant ?\no &#xAB; un pc ! &#xBB;\no &#xAB; Ah, et t&#x2019;as du temps &#xE0; perdre &#xBB;\no &#xAB; non ! &#xBB;\no &#xAB; alors reste sur pc &#xBB;\nSi vous avez l&#x2019;habitude des use cases, gardez les, sinon \nOsez le changement.\n\n
Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
Review the example on the slide:\nWhat is good about the way the use case is written?\nWhat is not good about the way the use case is written?\nIs this the right level of detail? \nHow would you write it differently?\n
Au d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
Start identifying the common vocabulary at the beginning of a project. \nThere should be one glossary for a system. This document is important to all stakeholders, especially when they need to understand and use terms that are specific to the project. \nAll text descriptions of the system, especially Use-Case Specifications, should use and refer to the terms defined in the glossary. \nIn some cases, you may build a domain model to further visualize the terms in the glossary.\n\n=======\nDescribing how actors interact with forms is common in use cases. There are many techniques that writers use, such as placing them in the flow or in the Special Requirements.\nFor example \n5. Enter Customer Information\nThe system prompts the Customer to enter name, address (two lines), city, state, zip code, and phone number.\nThe Customer enters the information.\nThe Customer creates the account.\nThis style has a tendency to distract the reader from the flows of events and is harder to maintain. \nThe safest method is to use the glossary. This ensures that there is only a single place to maintain the information. It ensures consistency if the same data is used in multiple use cases. It also makes the use-case description cleaner and easier to read. The glossary can be used by your database and user interface designers more effectively.\nWhile you should always strive to use the glossary, an alternative approach is to specify the detailed data requirements in the Special Requirements section of a Use-Case Specification or place them in the Supplementary Specification. \n
A domain model provides a visual model of key business objects that are captured in the glossary. The benefit of a domain model is that the relationships between the glossary terms can be represented visually, thereby improving the stakeholders&#x2019; understanding of the domain .\nThis is an example of part of a domain model for a course registration system. It shows that there are student, schedule, course offering, course, and professor. There are two types of students: full-time students and part-time students.\nThe numbers on associations between objects indicate how many objects that a particular object can be related to. This diagram shows\nA student can have zero-to-many schedules. A schedule must be associated with a student. \nA schedule is associated with zero-to-four course offerings. A course offering can exist in zero-to-many schedules.\nA course offering is associated with zero-to-one professor. A professor can teach zero-to-many course offerings. \nA course offering is associated with a course. A course can have zero-to-many course offerings. \n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
On peut regrouper sur les acteurs, par domaine, ...\n\nScanner p 43 et 44 de UML par la pratique\n\nOn peut alors, si n&#xE9;cessaire, d&#xE9;tailler certains de cas d&#x2019;utilisation.\n
On peut regrouper sur les acteurs, par domaine, ...\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Use cases were never intended to describe a user interface. Describing a visual thing with words is always open to interpretation and very hard to review. For example, picture a bucket. You may imagine that it is a plastic container with an open top and a handle. But someone else may imagine it as being made of metal, with a handle, painted red, and with the word &#x201C;Fire&#x201D; written on it. Everyone interprets descriptions differently. For the same reason, user interfaces are best described visually.\nAnother reason to keep a user interface out of a Use-Case Specification is that the requirements of the system may be the same regardless of the technology used.\nConsider the Use-Case Specification for a mobile phone. One of the use cases may be Receive Call. In this use case, the system needs to notify the user that there is an incoming call. Typically, use-case authors would write &#x201C;The system rings the phone.&#x201D; But with modern phones, the ring tone could be turned off. In fact, the phone could ring, vibrate, display a message on the screen, or any combination of the three, depending on which features have been enabled. In this case, the use-case description should be &#x201C;The system notifies the user of an incoming call. Refer to the special requirements for a description of how the system can notify the user.&#x201D; In the Special Requirements, there would be a matrix of how the system can notify the user, depending on the features that have been enabled in the system. This tells the implementer and tester that this is configurable and that the notification method is based on the system&#x2019;s configuration.\nEven if you know what your system&#x2019;s interface is going to be, your use cases should still be as interface-independent as possible. Put interface specific information in the user-interface specifications or user experience models. \n
Use cases were never intended to describe a user interface. Describing a visual thing with words is always open to interpretation and very hard to review. For example, picture a bucket. You may imagine that it is a plastic container with an open top and a handle. But someone else may imagine it as being made of metal, with a handle, painted red, and with the word &#x201C;Fire&#x201D; written on it. Everyone interprets descriptions differently. For the same reason, user interfaces are best described visually.\nAnother reason to keep a user interface out of a Use-Case Specification is that the requirements of the system may be the same regardless of the technology used.\nConsider the Use-Case Specification for a mobile phone. One of the use cases may be Receive Call. In this use case, the system needs to notify the user that there is an incoming call. Typically, use-case authors would write &#x201C;The system rings the phone.&#x201D; But with modern phones, the ring tone could be turned off. In fact, the phone could ring, vibrate, display a message on the screen, or any combination of the three, depending on which features have been enabled. In this case, the use-case description should be &#x201C;The system notifies the user of an incoming call. Refer to the special requirements for a description of how the system can notify the user.&#x201D; In the Special Requirements, there would be a matrix of how the system can notify the user, depending on the features that have been enabled in the system. This tells the implementer and tester that this is configurable and that the notification method is based on the system&#x2019;s configuration.\nEven if you know what your system&#x2019;s interface is going to be, your use cases should still be as interface-independent as possible. Put interface specific information in the user-interface specifications or user experience models. \n
Use cases were never intended to describe a user interface. Describing a visual thing with words is always open to interpretation and very hard to review. For example, picture a bucket. You may imagine that it is a plastic container with an open top and a handle. But someone else may imagine it as being made of metal, with a handle, painted red, and with the word &#x201C;Fire&#x201D; written on it. Everyone interprets descriptions differently. For the same reason, user interfaces are best described visually.\nAnother reason to keep a user interface out of a Use-Case Specification is that the requirements of the system may be the same regardless of the technology used.\nConsider the Use-Case Specification for a mobile phone. One of the use cases may be Receive Call. In this use case, the system needs to notify the user that there is an incoming call. Typically, use-case authors would write &#x201C;The system rings the phone.&#x201D; But with modern phones, the ring tone could be turned off. In fact, the phone could ring, vibrate, display a message on the screen, or any combination of the three, depending on which features have been enabled. In this case, the use-case description should be &#x201C;The system notifies the user of an incoming call. Refer to the special requirements for a description of how the system can notify the user.&#x201D; In the Special Requirements, there would be a matrix of how the system can notify the user, depending on the features that have been enabled in the system. This tells the implementer and tester that this is configurable and that the notification method is based on the system&#x2019;s configuration.\nEven if you know what your system&#x2019;s interface is going to be, your use cases should still be as interface-independent as possible. Put interface specific information in the user-interface specifications or user experience models. \n
\n
\n
\n
\n
People differ on how to deal with choices in use cases alternative flows or separate use cases?\nIf the choices are reasonably simple, keep them in the same use case. Include one choice in the basic flow, and put other choices in the alternative flows. If they have their own very different flows, you may want to consider putting them in separate use cases. However, avoid having too many fragmented use cases, because this makes it very difficult to understand the key functionality of the system. Also, avoid creating CRUD use cases. \n
\n
\n
If steps can occur in parallel, state this in the use case. Avoid inadvertently placing additional constraints on the design by ignoring optional ordering of steps. \n
It is common to see conditional statements such as IF-THEN-ELSE-ENDIF in Use-Case Specifications. The primary reason for including conditional statements in a use case flow is that they are very natural and convenient to write. However, every time you include a conditional statement, you add a level of complexity to the use case. The readers need to keep in mind the condition that got them to the subflow. With one level of condition, this is easy. But as you add more conditions, the level of complexity goes up an order of magnitude.\nFor example\nIF a THEN\n do something\n IF b THEN\n do something else\n When ELSE\n do something else again\n ENDIF\nENDIF\nImplementing and writing test scripts for use cases that make excessive use of conditional statements is difficult and prone to error. A far better approach is to use alternative flows.\nThere are tradeoffs. A use case with many alternative flows becomes difficult to read because the flows are fragmented throughout the document. The side effects of overuse of conditional statements far outweigh this problem.\n
It is common to see conditional statements such as IF-THEN-ELSE-ENDIF in Use-Case Specifications. The primary reason for including conditional statements in a use case flow is that they are very natural and convenient to write. However, every time you include a conditional statement, you add a level of complexity to the use case. The readers need to keep in mind the condition that got them to the subflow. With one level of condition, this is easy. But as you add more conditions, the level of complexity goes up an order of magnitude.\nFor example\nIF a THEN\n do something\n IF b THEN\n do something else\n When ELSE\n do something else again\n ENDIF\nENDIF\nImplementing and writing test scripts for use cases that make excessive use of conditional statements is difficult and prone to error. A far better approach is to use alternative flows.\nThere are tradeoffs. A use case with many alternative flows becomes difficult to read because the flows are fragmented throughout the document. The side effects of overuse of conditional statements far outweigh this problem.\n
\n
Functional decomposition is breaking down a problem into small, isolated parts. The parts work together to provide the functionality of the system. Often, the parts do not make sense in isolation because they lose their context.\nUse cases allow you to capture requirements at the same level of detail as functional decomposition, but the requirements are put into context with one another. Use cases enable you to develop requirements that are more likely to be understood by your stakeholders, and that deliver end-to-end functionality of the system.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
Au d&#xE9;but d&#x2019;un semestre les &#xE9;tudiants consultent un catalogue des cours propos&#xE9;s. Le catalogue contient des informations sur le cours tels que le professeur responsable, les intervenants ainsi que les pr&#xE9;-requis pour aider les &#xE9;tudiants dans leur choix.\n\nLe syst&#xE8;me doit permettre aux &#xE9;tudiants de choisir quatre cours. De plus, les &#xE9;tudiants doivent donner deux autres choix au cas o&#xF9; un cours est complet ou est supprim&#xE9;. Il ne peut y avoir plus de 15 &#xE9;l&#xE8;ves inscrits dans chaque cours mais un cours ne peut ouvrir s&#x2019;il n&#x2019;a pas au moins 6 inscrits.\n\nQuand l&#x2019;inscription d&#x2019;un &#xE9;tudiant est termin&#xE9;e, le syst&#xE8;me des inscriptions envoie des informations au service comptable pour &#xE9;mettre une facture.\n\nLes professeurs doivent pouvoir acc&#xE9;der au syst&#xE8;me pour indiquer les cours qu&#x2019;ils sont en mesure d&#x2019;assurer et pour conna&#xEE;tre les &#xE9;tudiants qui se sont inscrits &#xE0; leur cours.\n\nLes &#xE9;tudiants disposent d&#x2019;une p&#xE9;riode pendant laquelle ils peuvent changer leur choix, ils peuvent en outre ajouter ou abandonner certains cours.\n
This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system's functional requirements in terms of use cases. \nIt is a model of the system's intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, "models" the restaurant's behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
This definition of a use case comes from the Object Management Group (OMG), which is a non-profit computer industry specifications consortium.\nThe Unified Modeling Language is a standard visual modeling language managed and maintained by members of the OMG.\nTo learn more about UML and to access UML resources, go to www.ulm.org or to the IBM Rational software UML Resource Center www.ibm.com/sofware/rational/uml/.\nFor example, in a university-based course registration system, use cases might include: Register for Courses, Request Course Catalog, and Get Class List for a Course.\n\nA use-case model describes a system's functional requirements in terms of use cases. \nIt is a model of the system's intended functionality (use cases) and its environment (actors). \nThink of a use-case model as a menu, much like the menu you would find in a restaurant. By looking at the menu, you know what is available to you, the individual dishes as well as their prices. You also know what kind of cuisine the restaurant serves: Italian, Mexican, Chinese, and so on. By looking at the menu, you get an overall impression of the dining experience that awaits you in that restaurant. The menu, in effect, "models" the restaurant's behavior. \nBecause it is a very powerful planning instrument, the use-case model is generally used in all phases of the development lifecycle by all team members.\n
Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
Relationships between actors and use cases are called communicates-associations. A communicates-association between an actor and a use case indicates that they interact: The actor participates in and communicates with the system containing the use case. A communicates-association is represented on UML diagrams as a solid line.\n
\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
The use-case model consists of both diagrams and text. The diagrams give a visual overview of the system. The text gives descriptions of the actors and the use cases.\nThe majority of the work in writing use cases is spent writing the textual portion of the use case. \nUse cases involve writing text. Drawing the pictures is only a small part of the effort. Typically, more than 80 percent of all effort during requirements capture is writing the textual description of what happens in each use case, the non-functional requirements, and rules. \nUML does NOT specify how the text of a use case should be structured, organized, or written.\nHow you write use cases will have a large impact on how easy they are to read, use, and test.\n
\n
\n
Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
Use cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The benefits of use cases include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. They express requirements from a user perspective and in the user&#x2019;s own vocabulary. Traditional forms of requirements capture need some translation to make them accessibly by different stakeholders. When you translate something, information is often lost or misinterpreted. Use cases require no such translation. Therefore, they provide a more consistent and reliable form of requirement capture. \nUse cases are a means to communicate requirements between customers and developers to ensure that the system that is built is what the customer wants.\n
Functional requirements describe the behaviors (functions or services) of the system that support user goals, tasks, or activities. Functional requirements may include feature sets, capabilities, and security.\nUsability is the ease with which software can be learned and operated by the intended users. Usability requirements may include such subcategories as human factors, aesthetics, consistency in the user interface, online and context-sensitive help, wizards and agents, user documentation, and training materials.\nReliability is the ability for the software to behave consistently in a user-acceptable manner. Reliability requirements to be considered are frequency and severity of failure, recoverability, predictability, accuracy, and mean time between failure (MTBF). \nPerformance is a measure of speed or efficiency of the running system. It imposes conditions on functional requirements. For example, for a given action, it may specify performance parameters for speed, efficiency, availability, accuracy, throughput, response time, recovery time, and resource usage.\nSupportability is the ability of the software to be easily modified to accommodate enhancements and repairs. Supportability requirements may include testability, extensibility, adaptability, maintainability, compatibility, configurability, serviceability, installability, and localizability (internationalization).\nUse cases mainly capture the functional requirements of the system.\n\nA design requirement, often called a design constraint, specifies or constrains the design of a system. \n\n\n\n\n\n
Use cases defined for a system are the basis for the entire development process. They provide the unifying thread through the system and define the behavior performed by a system. Use cases play a role in each of the core process disciplines:\nThe use-case model is a result of the requirements workflow. It models what the system should do from the user's perspective. \nIn analysis and design, use cases are realized in a design model. You create use-case realizations, which describe how the use case is performed in terms of interacting objects in the design model. This model describes, in terms of design objects, the different parts of the implemented system and how the parts should interact to perform the use cases. \nDuring implementation, the design model is the implementation specification. Because use cases are the basis for the design model, they are implemented in terms of design classes. \nDuring testing, the use cases constitute a basis for identifying test cases and test procedures. The system is verified by performing each use case.\nUse cases have other roles as well: \nBasis for planning iterative development.\nFoundation for what is described in user manuals.\nDefinition of ordering units. For example, a customer can get a system configured with a particular set of use cases.\n
\n
\n
Un (ou un ensemble) de diagramme de plus haut niveau\n Placement des acteurs\n Pas de raffinements des cas d'utilisation\n G&#xE9;n&#xE9;ralement pas de d&#xE9;pendances entre cas d'utilisation (sauf cas d'utilisation de plus haut niveau)\n\n\n Pour chaque cas d'utilisation du diagramme de plus haut niveau, si n&#xE9;cessaire, d&#xE9;composition dans un diagramme de plus bas niveau\n Inutile de r&#xE9;p&#xE9;ter les acteurs\n R&#xE9;p&#xE9;ter le cas d'utilisation &#xE0; raffiner\n Relations de d&#xE9;pendance entre cas d'utilisation obligatoires\n\n Plusieurs niveaux de diagramme possibles\n\n
\n
Sommaire d&#xA0;&#x2019;identification\nDescription des encha&#xEE;nements\npr&#xE9;conditions\npostconditions\nBesoins d&#xA0;&#x2019;IHM\nContraintes non fonctionnelles\nservira &#xE0; &#xE9;valuer les contraintes techniques\nCompl&#xE9;ter avec des diagrammes dynamiques simples (vus plus loin)\ndiagrammes d&#xA0;&#x2019;activit&#xE9; global et sc&#xE9;narios \n(Comment le cas d&#x2019;utilisation commence et comment il finit) \n
n Actors: traveler, client account db, airline reservation system\nn Preconditions:\n&#x2022; Traveler has logged on to the system and selected &#x2018;change flight itinerary&#x2019; option\nn Basic course\n&#x2022; System retrieves traveler&#x2019;s account and flight itinerary from client account database\n&#x2022; System asks traveler to select itinerary segment she wants to change;traveler selects itinerary segment.\n&#x2022; System asks traveler for new departure and destination information;traveler provides information.\n&#x2022; If flights are available then\n&#x2022; &#x2026;\n&#x2022; System displays transaction summary.\nn Alternative courses\n&#x2022; If no flights are available then &#x2026;\n
\n
An actor represents a role that interacts with the system.\nA use case describes a sequence of interactions between actors and the system that occur when an actor uses the system to achieve a certain business goal.\nA use case describes: \nThe system, its environment, and the relationship between them. \nHow things outside the system interact with the system.\nThe desired behavior for the system.\nUse cases are containers for contextually related requirements of the system under development. They are containers because they group all requirements related to achieving a particular goal into a single story of how that is achieved.\nA use case is shown as an ellipse containing the name of the use case. An optional presentation is to place the use case name under the ellipse.\n
A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&#x201C;Sequence of actions&#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&#x201C;Performed by a system&#x201D;: The actions performed by the system are the functional requirements.\n&#x201C;Observable result of value&#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&#x201C;To an actor&#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &#x201C;Operate the Registration System.&#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&#x201C;Sequence of actions&#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&#x201C;Performed by a system&#x201D;: The actions performed by the system are the functional requirements.\n&#x201C;Observable result of value&#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&#x201C;To an actor&#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &#x201C;Operate the Registration System.&#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&#x201C;Sequence of actions&#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&#x201C;Performed by a system&#x201D;: The actions performed by the system are the functional requirements.\n&#x201C;Observable result of value&#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&#x201C;To an actor&#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &#x201C;Operate the Registration System.&#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&#x201C;Sequence of actions&#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&#x201C;Performed by a system&#x201D;: The actions performed by the system are the functional requirements.\n&#x201C;Observable result of value&#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&#x201C;To an actor&#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &#x201C;Operate the Registration System.&#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&#x201C;Sequence of actions&#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&#x201C;Performed by a system&#x201D;: The actions performed by the system are the functional requirements.\n&#x201C;Observable result of value&#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&#x201C;To an actor&#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &#x201C;Operate the Registration System.&#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
A use case describes a set of possible executions of the system. It describes a complete flow through the system until the resulting value is achieved for some actor. \n&#x201C;Sequence of actions&#x201D;: Atomic activities, decisions, and requests. Each action is performed fully or not at all.\n&#x201C;Performed by a system&#x201D;: The actions performed by the system are the functional requirements.\n&#x201C;Observable result of value&#x201D;: Make sure that the use case results in an observable value. Why would anybody use the system if it does not achieve a result of value? If nobody receives value from the use case, then the use case is probably too small. It needs to be combined with other use cases to provide a complete set of steps for achieving some goal for an actor.\n&#x201C;To an actor&#x201D;: Decide which particular actor receives the value and helps avoid use cases that are too large. If more than one actor receives value from a use case, it might indicate that the use case is too big; it tries to do too much for too many actors. For example, in the Course Registration System, there could be just one use case, called &#x201C;Operate the Registration System.&#x201D; It would achieve a variety of results for a variety of actors. It would be so big that it is hard to understand. It needs to be broken into smaller use cases. Use cases that do not deliver something of value are too small and usually describe individual functions of the system. These use cases do not make sense on their own and must be avoided.\nOften the sequence of interactions in a use case involves several actors. But one actor receives the result of value. The actor receiving the value is sometimes called the primary actor. The actor receiving the value is usually, but not necessarily, the one who initiated the use case. \n
Use cases contain the detailed functional software requirements. Every time a use case says, &#x201C;The system &#x2026;,&#x201D; is a detailed requirement of what the system must do.\nAlso, remember the definition: &#x201C;A sequence of actions performed by a system that yields a measurable result of value for a particular actor.&#x201D;\n
Do you have any problems in these areas with your current requirement process?\nUse cases are a way to organize requirements from a user perspective. All the requirements for a user to accomplish a particular task are gathered together in a single use case. The use-case model is the collection of all the individual use cases.\nAdvantages of use-case modeling include:\nUse cases show why the system is needed. Use cases show what goals the users can accomplish by using the system.\nSystem requirements are placed in context. Each requirement is part of a logical sequence of actions to accomplish a goal of a user. \nUse cases are easy to understand. The model expresses requirements from a user perspective and in the user&#x2019;s own vocabulary. The model shows how users think of the system and what the system should do. Traditional forms of requirements capture need some translation to make them useable to different stakeholder types. When you translate something, information is often lost or misinterpreted. Use cases require no such translation and therefore provide a more consistent and reliable form of requirement capture. \nThe model is a means to communicate requirements between customers and developers to make sure that the system we build is what the customer wants.\nUse-case modeling is the best tool (so far) to capture requirements and put them in context. \n
In all but the most trivial of systems, use cases are not written in one sitting. As with any iterative process, a use case evolves from the spark of an idea to a fully described description of how your system behaves.\nInitially you &#x201C;discover&#x201D; a use case. This is done when you identify and name the goal that the actor is trying to achieve. A use case is discovered once you have named it.\nImmediately after discovering a use case (usually while you are discussing the name), you create a brief description of the use case. A brief description describes the goal in two or three sentences. For example, the Close Registration Use Case&#x2019;s brief description is: This use case allows a Registrar to close the registration process. Course offerings that do not have enough students are cancelled. The Billing System is notified for each student in each course offering that is not cancelled, so the student can be billed for the course offering.\nThe next stage of evolution is to outline the use case. This can be a bulleted list of just the basic flow. You may also choose to identify identify (not outline) possible alternate flows. This enables you to identify scenarios and also gain an understanding of the possible size and complexity of the use case.\nFinally, you fully describe the use case. This is done iteratively. You identify particular flows for development in an iteration and then fully describe and implement just those flows. You then identify flows for subsequent iterations and fully describe and implement those during that iteration. At the end of the project, you have all of your use cases fully described.\nPrioritization of flows is done during the Manage the Scope of the System workflow detail.\n
The difference between an actor and an individual system user is that an actor represents a particular class of user rather than an actual user. Several users can play the same role, meaning they can be the same actor. In that case, each user constitutes an instance of the actor. \nHowever, in some situations, only one person plays the role modeled by an actor. For example, there may be only one individual playing the role of system administrator for a rather small system.\n
A use-case model shows what the system is supposed to do (use cases), the system's surroundings (actors), and the relationship between actors and use cases.\nThe use-case diagram is a graphical description of the use-case model. Can you tell at a glance what users can do with an ATM? \nWhat do you think the priorities for the use cases above would be? The diagram already helps to determine these priorities; without the first one we do not have an ATM, so we better get it right, (e.g. during elaboration); other use cases like deposit funds are nice to have, but would also have quite an architectural impact.\nIt is also useful to distinguish between primary use case and secondary use cases: Primary use cases support the customers/actors and business. Secondary use cases we get, because we decided on a particular technical solution and thus have to specify "extra" functionality to run this technical solution; thus, Maintain ATM, Print logs, Start, Stop, Backup the System, etc are required. These could be also be organized in a separate diagram.\n
The use-case diagram shown here is a graphic description of the use-case model for an online Course Registration System. It shows two of the actors (Student and Course Catalog System) and one use case (Register for Courses) that they participate in. \nThe diagram is incomplete. You use the online course registration system as a case study in this module. You develop the use-case model for this example as we go through the module. \nTake some time to look at the use-case model for an online Course Registration System in the Student Workbook. This example gives you an idea of what a use-case model looks like before you begin to develop one.\nThe use-case model for an online Course Registration System in the Student Workbook is incomplete. It contains only enough artifacts for the purpose of this module: Introduction to Use-Case Modeling. A larger, much more fully developed case study is presented later in the course.\n
Creating a use-case model involves putting the pieces you have learned together. First, the actors and the use cases are found by using the requirements of customers and potential users as vital information. As they are discovered, the use cases and the actors are identified and illustrated in a use-case diagram. Next, the steps in a use case are outlined to get a sketch of the flow. \nThe actor's name must clearly denote the actor's role. Make sure there is little risk at a future stage of confusing one actor's name with another.\nDefine each actor by writing a brief description that includes the actor's area of responsibility and what the actor needs the system for. Because actors represent things outside the system, you need not describe them in detail. \nEach use case should have a name that indicates what is achieved by its interactions with the actor(s). The name may have to be several words to be understood. No two use cases can have the same name. \nDefine each use case by writing a brief description of it. As you write the description, refer to the glossary and, if you need to, define new terms. \nWhen the actors and use cases have been found, each use case is described in detail. These descriptions show how the system interacts with the actors and what the system does in each individual case. In an iterative development environment, you select a set of use case flows to be detailed in each iteration. These are prioritized in such a way that technical risk is mitigated early and the customer gets important functionality before less important functionality.\n
Your use cases will go through brief iterations during development. At this point in development, you are concerned with identifying and briefly describing your use cases. Later, when you refine the system definition, you will detail and structure the use cases&#x2019; flows of events.\nWhen writing the brief description for a use case you should strive to capture the purpose of the use case and the value it provides to its actors or stakeholders. A brief description should really be no longer than two paragraphs. If it is longer, you may have invested too much time in it.\nFor each brief description, ensure that it captures:\nBusiness justification for its existence &#x2013; the value it provides to the actors and stakeholders.\nAn overview of a couple of the key scenarios.\nAfter reading a brief description a reviewer should be able to describe the business reason for its existence as well as a brief overview of some of the key scenarios.\nAn example for the Register for Courses use case is:\nThis use case enables the Student to register for courses at the beginning of a semester.\nThe system allows students to select from a variety of courses that the student has prerequisites for. During the registration process the student can browse current course listings, and add and remove courses from their enrolment list. Once the student has submitted their selections the student cannot make any more changes.\n
Here is a sample (not necessarily optimal) solution, which brings up a lot of questions that need to be answered by the customer or user:\nAre the use cases too small? For example, should you combine the Manage Portfolio Use Case and Review Account Use Case?\nDoes the diagram cover all activities? For example, in which use case do you think notifying the IRS of sale of stock is done?\nHow do you know what is done in each use case?\n\nNote It is not a complete solution; it covers only the goals mentioned in the initial requests. The complete sample solution can be found in the Student Workbook, RUCS4: Use-Case Model Survey.\n
There are a number of iterations that your use cases go through during development. At this point, you are concerned with outlining the use cases. Later, when you refine the system definition, you detail and structure the use case flows of events.\nA useful first step when outlining use cases is to capture the &#x201C;Essential Use Case&#x201D; as described by Larry Constantine and Lucy A.D. Lockwood 1999. Software for Use. Reading, MA: Addison Wesley Longman.\nThe idea behind the essential use case is to capture the essence of the intention of using the system for the intended purpose. An example for the ubiquitous ATM Withdraw Cash use case would be:\n
Some of the reasons to outline your use cases are:\nIterative development reduces risk. For the same reason we do not implement the whole system in one hit, we do not develop the detailed requirements all at once.\nAvoid getting bogged down in too much detail too early.\nYou do not know everything at once. Outlining helps you discover what you don&#x2019;t know.\nOutlining use cases creates a rough draft for fully specifying your use cases.\nOutlining helps determine whether the use case is too small on its own or too big to be just one use case. It might also help decide whether the use case is actually more than just one use case. \nOnce you write out your steps, you might find that they really belong in another use case. If the outline shows that the use case does not have much to it, it may not be a use case at all. \nOutlining adds value to finding all possible alternate flows.\n
The outline of the flow of events for a use case has two main sections:\nBasic Flow of Events.\nAlternative Flow of Events. \nThe outline is used as a base when you start to write the full use-case specification.\nStructure the flows in such a way that it is easy to follow the different scenarios and to be able to understand what happens when alternatives occur and where they pick up or finish.\nThe basic flow of events should be relatively short and very easy to read, like a single story line. The basic flow should show the steps needed to achieve the main goal of the use case. \nMost of the other details go into alternative flows. You can think of the alternative flows as &#x201C;detours&#x201D; from the basic flow of events, some that return to the basic flow of events and some that end the execution of the use case. In the diagram on the slide, the straight arrow represents the basic flow and the curves represent alternative paths in relation to the basic flow. Examples of different kinds of alternative flows for the Register for Courses use case are:\nRegular variants: Handle freshman enrollments differently.\nOdd cases: Handle registering for over 25 credit-hours differently.\nExceptional (error) flows: Invalid student ID Number.\nYou develop both the basic and alternative flows in the outline you make in the Find Actors and Use Cases activity.\nNote, the diagram above is informational only and is not a valid UML diagram.\n
Here is a list of questions to help you make decisions about the details in the flow of events.\nAlternative flows describe how the system should behave when things go wrong or when unusual things happen. \nWhen working on the alternative flows, questions regarding the behavior of the system are bound to surface. List these questions and have the users answer what the system is supposed to do, and how they expect to interact with the system in each scenario. Understanding the alternatives is an important step in clarifying the requirements. \nAt this point in the process, however, it is enough to identify the alternatives without describing them in detail.\n
This is an example of a step-by-step outline for a use case. It shows a step-by-step outline for the Get Quote use case from the RU e-st system. The basic flow shows the major steps. The alternative flows show optional behavior.\nNotice the level of detail in this example. Remember, this is just a brief step-by-step outline to help understand what functions are contained in the use case. Further describe these steps in Module 8, Refine the System Definition.\n
A package is a general-purpose grouping mechanism in UML.\nIf your model is too large to view as a single unit, you can break your model into packages. A package in a use-case model may contain use cases, actors and relationships; and perhaps other, smaller packages. \nThere are many ways to organize your packages. For example, one package might contain a particular actor and all the use cases that the particular actor can perform. Another popular grouping is to have each package contain all the use cases related to a particular feature.\nIf you are using packages, the Use-Case-Model Survey has a separate subsection in Section 3 for each package. Each subsection contains an overview of the package and the lists of Actors and Use Cases in the package.\nIn the book Use Case Modeling, a suggested guideline for organizing your model is:\nEach use-case package should contain 3 to 10 smaller units (use cases, actors, or other packages).\n0-15 units: No use-case packages needed.\n10-50 units: Use one level of use-case packages.\n>25 units: Use two levels of use-case packages.\nNote: The quantities overlap because it is impossible to give exact guidelines.\n
The approach to business modeling presented in the Rational Unified Process&#xAE;&#xF87F; includes a concise and straightforward way to generate requirements on supporting information systems. A good understanding of business processes helps you to build the right systems. \nA business model consists primarily of two parts. Each part plays an important role in understanding stakeholder needs.\nA Business use-case model shows the business intended functions. The business use-case model is used as an essential input to identify roles and deliverables in the organization. In requirements elicitation, the business use-case model helps develop the system use-case model of a particular system being developed.\nA Business object model describes things handled by the business, workers, and responsibilities; and the relationships between them. The business object model captures the vocabulary of objects in the business. The business object model is also used in the Design Workflow to help develop class diagrams and other parts of the system design.\nHaving a business model as input into the requirements management workflow is particularly useful if you intend to build one of the following systems: \nCustomized systems for one or more companies in a particular type of industry (banks, insurance companies)\nA family of applications for the open market (order handling systems, billing systems, air-traffic control systems)\n
This example is from the RUP Business Modeling Guidelines: Going from Business Models to Systems. \nThe diagram above shows how there is a clear mapping between things found in a business model and the things in your system model. In this particular example, it is showing how a system can automate the responsibilities of a business worker. It is also showing how key business entities are candidates for automation.\nA business use case describes how the business delivers something of value to an actor of the business. The Business Object Model describes how the things inside the business collaborate to deliver the value described in the business use-case model. There are two important concepts in a business object model &#x2013; the business worker and the business entity. A business worker represents a person or computer system that does work in the business. A business entity represents the information that the workers use in performing the business process.\nUse-Case Model Step 1 shows how a system can help with the business process. The workers in the business are the actors for the system.\nUse-Case Model Step 2 shows an example of replacing a customer-facing worker with a system. The customer is now the actor for the system.\nThe Analysis Model shows how the business entities map to classes in the system analysis model. These classes represent the &#x201C;data&#x201D; that the system will work with.\n
The above list of use-case checkpoints is a summary of the list in the Rational Unified Process&#xAE;&#xF87F;.\n