Uml Cas Utilisation introduction

5 877 vues

Publié le

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

Publié dans : Formation
  • Soyez le premier à commenter

Uml Cas Utilisation introduction

  1. 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. 2. BibliographiePrincipalement : • 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éeobjet, M.Grimaldi – janvier 2010 2
  3. 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. 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. 5. Dict. U.C. Process. Compléments.UML au travail : Guichet automatique de banqueLe guichet automatique d’une banque (GAB) offre lesservices 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. 6. Dict. U.C. Process. Compléments. UML au travail : Une galerie d’art(1) Nous voulons informatiser une galerie dart, par laquelle noussouhaitons vendre des oeuvres darts à des clients. Les paiementsdoivent ê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 desinterfaces adaptées.(3) Un internaute doit pouvoir sinscrire sur le site pour devenir client.(4) Un internaute peut naviguer sur le site, retrouver un artiste parson nom, visualiser les oeuvres par catégorie.(5) Les clients peuvent voter pour les oeuvres ou les artistes quilspréfèrent.(6) Une fois par jour, un super-administrateur déclenche uneopération de sauvegarde de la galerie.(7) Lidentification des clients fait partie du système de la galerie. 6 /82
  7. 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 dapplication. – Constitue le point dentrée et le référentiel initial de lapplication ou du système. Homonymie Synonymie Polysémie 7 /98
  8. 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. 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 dutilisation sont nommés en utilisant la terminologie décrite dans le dictionnaire Jean-Marie Favre 9 /98
  10. 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. 11. Dict. U.C. ✓Conclusion Process. Compléments. Bénéfices des use-casesOrganisent les exigences d’un point de vue utilisateurDéfinissent les exigences du système comme desséquences logiques,Permettent de vérifier que toutes les exigences sontcapturées et qu’elles correspondent à ce qu’attend ledemandeur.Facilitent l’adéquation des demandeurs‣ mais aussi des cas de tests, la documentation et la réutilisation des exigences. 11 /98
  12. 12. Dict. U.C. ✓Conclusion Process. Compléments.Des use-cases, pour qui?Demandeurs (décrire et approuver)Utilisateurs (comprendre)Architectes logiciels (identificationdes fonctions)Concepteurs et développeursTesteurs (identifier les tests)Managers (Planifier)Rédacteurs de documentation(prendre un point de vue utilisateur) 12 /98
  13. 13. Dict. U.C. ✓Conclusion Process. Compléments.Dev. logiciel dirigé par les use-cases 13 /98
  14. 14. Dict. U.C. Process. Compléments.Processus d’écriture des UCTrouver les acteurs Etudiant Catalogue des cours Enregistrer des cours Brève description: Ce UC permet à un étudiantTrouver 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. 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. 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. 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. 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. 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. 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. 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. 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. 23. Dict. U.C. Process. ✓1. acteurs Compléments. Trouver les acteursQui ou quoi utilise le système?Qui ou quoi obtient de linformation 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. 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. 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 secondairesdans le catalogue des cours proposésDès qu’un étudiant s’est inscrit pour un semestre, le système de facturationest 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. 26. Dict. U.C. Process. ✓1. acteurs Compléments. Décrire les acteursStudent : A person who signs up for a course Student- Quest-ce ou que lacteur représente- Pourquoi lacteur est nécessaire- Quel est l’intérêt de l’acteur dans le UC ? Professor Registrar 23 /98
  27. 27. Dict. U.C. Process. ✓1. acteurs Compléments. Décrire les acteursStudent : A person who signs up for a course Student- Quest-ce ou que lacteur représente- Pourquoi lacteur est nécessaire- Quel est l’intérêt de l’acteur dans le UC ? Professor Registrar Course Catalog System 23 /98
  28. 28. Dict. U.C. Process. Compléments.UML au travail : Guichet automatique de banqueLe guichet automatique d’une banque (GAB) offre lesservices 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. 29. Identification des acteursQuelles sont les entités externes qui interagissent avec le GAB ? • Porteur de cartePhrase 1 • Carte de crédit • Lecteur de carte • Distributeur de billetsPhrase 2 • Porteur de carte client de la banquePhrase 3 Le système est sécurisé (par quoi?) 1. Le système d’autorisation 2. Le système d’information de la banquePhrase 4 • Opérateur de maintenance
  30. 30. Dict. U.C. Process. ✓1. acteurs Compléments. UML au travail : Une galerie d’art(1) Nous voulons informatiser une galerie dart, par laquelle noussouhaitons vendre des oeuvres darts à des clients. Les paiementsdoivent ê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 desinterfaces adaptées.(3) Un internaute doit pouvoir sinscrire sur le site pour devenir client.(4) Un internaute peut naviguer sur le site, retrouver un artiste parson nom, visualiser les oeuvres par catégorie.(5) Les clients peuvent voter pour les oeuvres ou les artistes quilspréfèrent.(6) Une fois par jour, un super-administrateur déclenche uneopération de sauvegarde de la galerie.(7) Lidentification des clients fait partie du système de la galerie. 26 /82
  31. 31. Dict. U.C. Process. ✓1. acteurs Compléments.Diagramme de contexte 27 /98
  32. 32. Le GAB est un système fondamentalementmono-utilisateur: à tout instant, il n’y a qu’uneinstance de chaque acteur (au maximum)connecté au système!Pour simplifier, nous utiliserons le terme Client banque pourl’acteur Porteur de carte client de la banque.
  33. 33. Diagramme de contexte statique
  34. 34. Les acteurs humains Client banque et Porteur de carte sontmutuellement exclusifs, ce qui n’est pas implicite d’après lesmultiplicités des associations. On peut ajouter une contrainte{XOR} (ou exclusif)
  35. 35. Une autre solution, un peu plus élaborée, consiste àconsidérer que Client banque est une spécialisation dePorteur de carte (héritage entre acteurs)
  36. 36. Dict. U.C. Process. ✓1. acteurs Compléments. UML au travail : Une galerie d’art(1) Nous voulons informatiser une galerie dart, par laquelle noussouhaitons vendre des oeuvres darts à des clients. Les paiementsdoivent ê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 desinterfaces adaptées.(3) Un internaute doit pouvoir sinscrire sur le site pour devenir client.(4) Un internaute peut naviguer sur le site, retrouver un artiste parson nom, visualiser les oeuvres par catégorie.(5) Les clients peuvent voter pour les oeuvres ou les artistes quilspréfèrent.(6) Une fois par jour, un super-administrateur déclenche uneopération de sauvegarde de la galerie.(7) Lidentification des clients fait partie du système de la galerie. 32 /82
  37. 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. 38. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Cas d’utilisation (UC) 34 /98
  39. 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. 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’actionsconnectées, effectuées par un dialogue entre des acteurs et lesystè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. 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’actionsconnectées, effectuées par un dialogue entre des acteurs et lesystè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. 42. Dict. U.C. Process. ✓2. U.C. Compléments. Trouver les use-casesQuels sont les objectifs de chaque acteur?‣ Pourquoi lacteur utiliserait-il le système?‣ Est-ce que lacteur créera, stockera, modifiera, supprimera ou lira des données dans le système? Si oui, pourquoi?‣ Est-ce que lacteur nécessite dinformer le système sur des événements externes ou des changements?‣ Est-ce que lacteur 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. 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 secondairesdans le catalogue des cours proposésDès qu’un étudiant s’est inscrit pour un semestre, le système de facturationest 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. 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 secondairesdans le catalogue des cours proposésDès qu’un étudiant s’est inscrit pour un semestre, le système de facturationest notifiéLes étudiants peuvent utiliser le système pour modifier leurs choix pendantune certaine période de temps après leur inscriptionLes 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. 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. 46. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-caseLe 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. 47. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-caseLe nom doit être unique, intuitif et auto-explicatifIl doit commencer par un verbe et utiliser une simplecombinaison verbe-nom  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  48. 48. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-caseLe nom doit être unique, intuitif et auto-explicatifIl doit commencer par un verbe et utiliser une simplecombinaison verbe-nomDéfinir clairement et sans ambiguïté le gain des résultatsobservables  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  49. 49. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-caseLe nom doit être unique, intuitif et auto-explicatifIl doit commencer par un verbe et utiliser une simplecombinaison verbe-nomDéfinir clairement et sans ambiguïté le gain des résultatsobservablesPlacez vous du point de vue de lacteur qui déclenche lecas dutilisation  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  50. 50. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Nommer un use-caseLe nom doit être unique, intuitif et auto-explicatifIl doit commencer par un verbe et utiliser une simplecombinaison verbe-nomDéfinir clairement et sans ambiguïté le gain des résultatsobservablesPlacez vous du point de vue de lacteur qui déclenche lecas dutilisationDécrire le comportement fournit par le cas dutilisation  Enregistrer des Cours ?  Enregistrement de cours  Cours  Utiliser le système d’enregistrement  Accuser réception des cours 38 /98
  51. 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 serviceEtudiant Enseignant S’inscrireSystème de Etablir lefacturation Programme Scolaire Chef du Service Des Inscriptions 39 /98
  52. 52. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Communication : un dialogueL’étudiant se connecte au systèmeLe 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. 53. Dict. U.C. ✓cas d’utilisat. Process. Compléments. Diagramme des cas d’utilisationPorteur de carte: Retirer de l’argentClient 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érationnelSystème d’autorisation (Sys.Auto) Acteurs Néant secondairesSystème d’information de la banque (SI banque) Néant /82
  54. 54. Dict. U.C. ✓cas d’utilisat. Process. Compléments.Diagramme des cas d’utilisation /82
  55. 55. Dict. U.C. ✓cas d’utilisat. Process. Compléments.Diagramme des cas d’utilisation amélioration /82
  56. 56. Dict. U.C. ✓cas d’utilisat. Process. Compléments. UML au travail : Une galerie d’art(1) Nous voulons informatiser une galerie dart, par laquelle noussouhaitons vendre des oeuvres darts à des clients. Les paiementsdoivent ê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 desinterfaces adaptées.(3) Un internaute doit pouvoir sinscrire sur le site pour devenir client.(4) Un internaute peut naviguer sur le site, retrouver un artiste parson nom, visualiser les oeuvres par catégorie.(5) Les clients peuvent voter pour les oeuvres ou les artistes quilspréfèrent.(6) Une fois par jour, un super-administrateur déclenche uneopération de sauvegarde de la galerie.(7) Lidentification des clients fait partie du système de la galerie. 44 /82
  57. 57. Dict. U.C. ✓Système Process. Compléments. Le systèmeLe système est un ensemble de cas d’utilisationLe 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. 58. Dict. U.C. ✓Système Process. Compléments. System Frontière du système Etablir un emploi du tempsEtudiant Enregistrer ses cours Catalogue S’inscrire des cours Demander Système de un tableau de facturation serviceSystème de Enseignantfacturation Maintenir le Programme Chef du Service 46 /98 Des Inscriptions
  59. 59. Dict. U.C. ✓Desc. Process. Compléments.Description succincte d’un UC Sommaire didentification : ■ Titre ■ Résumé ■ Acteurs ■ Date de création ■ Date de mise à jour ■ Version ■ Responsable 47 /98
  60. 60. Dict. U.C. ✓Desc. Process. Compléments. Description textuelle du cas dutilisation: « RETIRER DE L’ARGENT »   Sommaire didentificationTitre : Retirer de largentRésumé : ce cas dutilisation permet à un porteur de carte, qui nest pasclient de la banque, de retirer de largent, si son crédit hebdomadaire lepermet.Acteurs : Porteur de carte non client (principal), Sys. Auto. (secondaire).Date de création : 03/01/07 Date de mise à jour : 09/02/07Version : 1.0 Responsable : Pierre DUMONT /82
  61. 61. Dict. U.C. Process. ✓2. U.C. Compléments. Bilan sur les UC 49 /98
  62. 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 dutilisation? Est-ce que des acteurs jouent des rôles similaires du point de vue du système? Dans laffirmative, 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 lenvironnement du système?» 50 /98
  63. 63. Dict. U.C. Process. ✓2. U.C. Compléments.Faire le point sur les Use-cases(1) Le modèle de cas dutilisation 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 dutilisation ont été identifiés; les cas dutilisation représentent l’ensemble des comportements requis. Le modèle de cas dutilisation ne contient pas de comportement superflu; A chaque cas dutilisation correspond une exigence fonctionnelle. 51 /98
  64. 64. Dict. U.C. Process. ✓2. U.C. Compléments.Faire le point sur les Use-cases(2) Le cas dutilisation ont des noms uniques, intuitifs, et des noms explicites de sorte quils 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 dutilisation. La brève description donne une image fidèle du cas dutilisation. Chaque cas dutilisation implique au moins un acteur. Les cas dutilisation n’ont pas de comportements ou des flux dévénements très similaires. 52 /98
  65. 65. Dict. U.C. Process. ✓2. U.C. Compléments.Évaluer la valeur commerciale et les risques Pour chaque cas dutilisation 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. 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. 67. Dict. U.C. Process. ✓3.décrire. Compléments. Décrire une UCDécrire chaque étape du UC par des phrasescourtes, 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. 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 deNuméroter base en 1. First stepet nommer 2. Second step étapesles é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. 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. 70. Dict. U.C. Process. ✓3.décrire. Compléments. Décrire les UCUn processus itératif : ne pas tout détailler, pastrop tôtUn processus de découverte : Décrire vous aideà découvrir ce que vous ne connaissez pas. Unebrève description sert de point de départ.Un processus d’évaluation : UC trop petit outrop gros ? partagé? 57 /98
  71. 71. Dict. U.C. Process. ✓3.décrire. Compléments.Exigences additionnellesCollecter les exigences système qui nepeuvent pas être allouées à des UCspécifiques dans des documentsadditionnels. 58 /98
  72. 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. 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 derreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins dIHM 60 /98
  74. 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 à dautres 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. 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 derreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins dIHM 62 /98
  76. 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 theDé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. 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 dacteur)  Dire: “Létudiant choisit ... …”  Au lieu de: "Lutilisateur choisit ...…"  Dire: “Le Système valide …”  Au lieu de: "Le choix est validé …" 64 /98
  78. 78. Description textuelle du cas dutilisation: « RETIRER DE L’ARGENT »   Description des scénariosPré 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 nominal1. 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. 79. 3. Le GAB demande au porteur de carte de saisir son code didentification.4. Le porteur de carte saisit son code didentification.5. Le GAB compare le code didentification avec celui qui est codé sur la puce de la carte.6. Le GAB demande une autorisation au système dautorisation.7. Le système dautorisation 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 sil 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. 80. Description textuelle du cas dutilisation: RETIRER DE L’ARGENT  (Représentation de C.Larman)Une autre présentation dite de Larman consiste à séparer lesactions des acteurs et du système en deux colonnes: Action d’acteur Action Système1. 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 didentification.4. Le porteur de carte saisit son 5. Le GAB compare le code code didentification. d’identification avec celui qui est codé sur la puce de la carte. 6. Le GAB demande une autorisation au système dautorisation global.
  81. 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 ticket12. 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. 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 derreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins dIHM 69 /98
  83. 83. Enchaînements alternatifs*Al : code didentification provisoirement erronéLenchaî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 hebdomadaireLenchaî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 derreur (Ey) qui terminentbrutalement le cas dutilisation en échec. Lobjectif de lacteur principal est doncatteint par les scénarios nominaux et alternatifs mais pas par ceux derreur.
  84. 84. A3 : ticket refuséLenchaî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’erreurEl : carte non-valideLenchaînement El démarre au point 2 du scénario nominal.3. Le GAB indique au porteur que la carte nest pas valide (illisible, périmée, etc.), la confisque ; le cas dutilisation se termine en échec.
  85. 85. E2 : code didentification définitivement erronéLenchaî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 dautorisation est informé ; le cas dutilisation se termine en échec.E3 : retrait non autoriséLenchaînement E3 démarre au point 6 du scénario nominal.7. Le système dautorisation interdit tout retrait.8. Le GAB éjecte la carte ; le cas dutilisation se termine en échec.E4 : carte non repriseLenchaî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 dautorisation est informé ; le cas dutilisation se termine en échec.
  86. 86. E5 : billets non prisLenchaî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 dautorisation est informé ; le cas dutilisation se termine en échec.E6 : annulation de la transactionLenchaînement E6 peut démarrer entre les points 4 et 12 du scénario nominal.4 à 12. Le porteur de carte demande lannulation de la transaction en cours.Le GAB éjecte la carte ; le cas dutilisation se termine en échec.E4 : carte non repriseLenchaî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 dautorisation est informé ; le cas dutilisation se termine en échec.
  87. 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 dutilisation?‣ Comment le cas dutilisation se termine-t-il?‣ Comment le cas dutilisation répète-t-il certains comportements? Flots d’exceptions‣ Y-a-t-il des situations facultatives dans le cas dutilisation?‣ 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. 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 derreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins dIHM 75 /98
  89. 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 à dautres 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 dutilisation, soit létudiant a été inscrit à des cours, soit l’inscription a échoué et aucune modification na été apportée à aux cours... 76 /98
  90. 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. 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 derreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins dIHM 78 /98
  92. 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 DeLArgentAuDistributeur (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. 93. Description textuelle du cas dutilisation: « RETIRER DE L’ARGENT »  informations optionnellesExigences non fonctionnelles Contraintes DescriptifTemps 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 minutesConcurrence 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 vandalismeConfidentialité La vérification du code saisi doit être fiable à 10-6
  94. 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 derreur ■ Postconditions ■ Exigences non fonctionnelles ■ Besoins dIHM 81 /98
  95. 95. Description textuelle du cas dutilisation: « RETIRER DE L’ARGENT »  informations optionnellesBesoins d’IHMLes dispositifs dentré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 laffichage 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. 96. Dict. U.C. Process. ✓4.détailler Compléments.Faire le point sur les UCLes interactions entre le système et les acteurssont clairesLes séquence de communication sont conformesaux attentes de lutilisateurQuand/comment les UC commencent/seterminent est clairLe flot de base de base donne un résultatobservable pour un ou plusieurs acteurs 83 /98
  97. 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. 98. Dict. U.C. Process. Compléments. Ecrire des UC : Défis1. 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 dutilisation? 85 /98
  99. 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. 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. 101. Dict. U.C. Process. Compléments. Relations entre UC : Include, Extend, Specialize 88 /98
  102. 102. Dict. U.C. Process. Compléments. Relations entre UC : Include, Extend, SpecializeAu 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. 103. Dict. U.C. Process. Compléments. Extends Les deux UC sont indépendants. Permettre au client de consulter son solde avant de saisir le montant : extension optionnelle.Flot enrichi 8. Le GAB demande au client de saisir le montant Point d’extension : Vérification du solde 9. Le client saisit le montant désiré de retrait 89 /98
  104. 104. La relation <<include>> ou <<uses>>
  105. 105. La relation <<include>> ou <<uses>>La relation d’include a pour seul objectif de factoriser unepartie de la description d’un cas d’utilisation qui estcommune à d’autres cas d’utilisation.
  106. 106. La relation <<include>> ou <<uses>>La relation d’include a pour seul objectif de factoriser unepartie de la description d’un cas d’utilisation qui estcommune à d’autres cas d’utilisation.Le cas d’utilisation inclus dans les autres cas d’utilisationn’est pas à proprement parler un vrai cas d’utilisation car iln’a pas d’acteur déclencheur ou receveur d’évènement.
  107. 107. La relation <<include>> ou <<uses>>La relation d’include a pour seul objectif de factoriser unepartie de la description d’un cas d’utilisation qui estcommune à d’autres cas d’utilisation.Le cas d’utilisation inclus dans les autres cas d’utilisationn’est pas à proprement parler un vrai cas d’utilisation car iln’a pas d’acteur déclencheur ou receveur d’évènement.Il est juste un artifice pour faire de la réutilisation d’uneportion de texte.
  108. 108. Généralisation Lassociation de généralisation entre cas dutilisation a la même sémantique que pour les classes Valider usager Vérifier Scanner mot de passe rétine 91
  109. 109. Dict. U.C. Process. Compléments.La galerie /98
  110. 110. Dict. U.C. Process. Compléments.Structuration des UC en packages Scanner p 43 et 44 de UML par la pratiqueOn peut alors, si nécessaire, détailler certains de cas d’utilisation. /98
  111. 111. Dict. U.C. Process. Compléments. 2. Comment traiter les interfaces utilisateur?✓Laissez linterface utilisateur hors des UC ➡ Les UC sont indépendants de linterface 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. 112. Dict. U.C. Process. Compléments. 2. Comment traiter les interfaces utilisateur?✓Laissez linterface utilisateur hors des UC ➡ Les UC sont indépendants de linterface 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. 113. Dict. U.C. Process. Compléments. 2. Comment traiter les interfaces utilisateur?✓Laissez linterface utilisateur hors des UC ➡ Les UC sont indépendants de linterface 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. 114. Dict. U.C. Process. Compléments. 2. Comment traiter les interfaces utilisateur?✓Laissez linterface utilisateur hors des UC ➡ Les UC sont indépendants de linterface utilisateur ➡ Décrire les interfaces utilisateur avec des modèles dédiés ou des prototypes Words to Avoid Words to Use Click Drag Form Prompts Chooses Open Close Drop Initiates Button Field Drop-down Specifies Pop-up Scroll Browse Submits Selects Record Window Starts Displays Informs “Le système fait sonner le téléphone.” notifie 94 /98
  115. 115. Si c’est nécessaire...Après...• avec l’addon Firefox :• http://pencil.evolus.vn/en-US/Downloads/Application.aspx 95
  116. 116. Résumé et conseilsméthodologiques 96
  117. 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. 118. Dict. U.C. Process. Compléments.Cas d’utilisation : résumé 98 /98

×