CM CU-cockburn

2 144 vues

Publié le

Publié dans : Formation
0 commentaire
2 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
2 144
Sur SlideShare
0
Issues des intégrations
0
Intégrations
806
Actions
Partages
0
Téléchargements
102
Commentaires
0
J’aime
2
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

CM CU-cockburn

  1. 1. Cas d’utilisation et expression de besoins<br />Yannick Prié<br />Département Informatique – Faculté de Sciences et Technologies<br />Université Claude Bernard Lyon 1<br />2011-2012<br />
  2. 2. Objectifs de ce cours<br />Présenter les cas d’utilisation et les diagrammes de cas d’utilisation de façon « standard » <br />ce qu’on trouve en général dans la norme UML<br />Présenter de façon précise une façon particulière de penser les cas d’utilisation<br />d’après le livre de Alistair Cockburn qui fait référence, au delà de la norme<br />à utiliser dans cette UE<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />2<br />
  3. 3. Plan <br />Présentation standard des CU<br />Rédaction de cas d’utilisation<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />3<br />
  4. 4. Cas d’utilisation<br /><ul><li>Technique pour capturer les exigences fonctionnelles d’un système
  5. 5. déterminer ses limites
  6. 6. déterminer ce qu’il devra faire, quels services il rendra
  7. 7. mais pas comment il devra le faire
  8. 8. point de vue de l’utilisateur
  9. 9. Pour cela
  10. 10. déterminer les acteurs qui interagissent avec le système
  11. 11. rôles
  12. 12. déterminer les grandes catégories d’utilisation
  13. 13. cas d’utilisation
  14. 14. décrire textuellement des interactions
  15. 15. scénarios</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />4<br />
  16. 16. Acteur<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />5<br />Client : personne qui se connecte au distributeur bancaire à l’aide de sa carte. Peut avoir ou non un compte dans la banque qui possède le distributeur.<br /><<Acteur>><br />Imprimante<br />client<br /><ul><li>Entité (humain ou machine) située hors du système
  17. 17. permet de déterminer les limites du système
  18. 18. Un acteur joue un rôle par rapport au système
  19. 19. soit déclenche un stimulus entraînant une réaction du système
  20. 20. soit est sollicité par le système au cours d’un scénario
  21. 21. Un acteur est décrit précisément en quelques lignes
  22. 22. Catégories d’acteurs
  23. 23. acteurs principaux (fonctions principales du système)
  24. 24. acteurs secondaires (administration / maintenance)
  25. 25. matériel externe
  26. 26. autres systèmes</li></li></ul><li>Cas d’utilisation<br /><ul><li>Ensemble de séquences d’actions réalisées par le système, produisant un résultat observable pour un acteur particulier
  27. 27. ex. s’identifier, retirer du liquide, répondre à un mail
  28. 28. Un cas d’utilisation
  29. 29. définit un ensemble de scénarios d’exécution impliquant le même acteur (déclencheur) avec le même objectif utilisateur
  30. 30. recense les informations échangées et les étapes dans la manière d’utiliser le système, les différentes points d’extension et tous les cas d’erreur </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />6<br />
  31. 31. Scénario<br /><ul><li>Séquence particulière d’étape dans la réalisation d’un CU
  32. 32. Séquence particulière de messages dans le CU pendant une interaction particulière
  33. 33. « chemin » dans le cas d’utilisation
  34. 34. Tous les scénarios d’un CU sont issus du même acteur et ont le même objectif
  35. 35. Description du CU
  36. 36. ensemble de scénarios couvrant le CU
  37. 37. documents avec flot d’événements
  38. 38. détaille ce qui se passe entre utilisateur et le système quand le CU est exécuté
  39. 39. flot nominal des événements (80 %)
  40. 40. flots d’événements alternatifs
  41. 41. flots d’exceptions (terminaison incorrecte)
  42. 42. serviront de base pour les jeux d’essais</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />7<br />scénario 1<br />scénario 2<br />CU<br />scénario 3<br />
  43. 43. Documentation des CU (1/4)Diagramme général des cas d’utilisation<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />8<br />Association<br />S’identifier<br />Acteur humain<br />Acteur non humain<br />Cas d’utilisation<br />Limite du système<br />
  44. 44. Faire un virement<br />Faire un virement<br />par Minitel<br />« extend »<br />montant > 80 €<br />Client local<br />« include »<br />Client distant<br />Vérifier<br />solde compte<br />S’identifier<br />Documentation des CU (2/4)Diagramme avec relation entre CU<br />« include » <br />la réalisation d’un CU nécessite la réalisation d’un autre, sans condition, à un point d’extension (le seul important)<br />« extend » <br />entre deux instances de CU : le comportement de CU1 peut être complété par le comportement de CU2 (option avec condition et point d’extension)<br />conseil : ne pas utiliser, ou seulement si on ne peut toucher à CU1<br />« generalize » <br />héritage. (conseil : ne pas utiliser)<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />9<br />
  45. 45. Documentation des CU (3/4)Fiche textuelle<br /><ul><li>Ensemble de champs de description
  46. 46. nom, préconditions…
  47. 47. Lisible et informelle
  48. 48. français simple, phrases descriptives
  49. 49. pas trop long (personne ne lit 10 pages)
  50. 50. Décrivant
  51. 51. un scénario nominal
  52. 52. suite d’étapes avec objectifs de l’acteur bien identifiés et menés à bien
  53. 53. des points d’extension et étapes d’extensions
  54. 54. des points d’échec
  55. 55. des liens vers d’autres scénarios s’il y a trop d’étapes</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />10<br />
  56. 56. Documentation des CU (4/4)Complément de description<br />Tout ce qui permet de mieux expliquer <br />modèle du domaine<br />diagrammes de séquence système<br />diagramme d’activité, de machines d’états<br />dessin ou maquette d’interface<br />documents quelconques<br />…<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />11<br />
  57. 57. CU : texte vs diagramme (1/4)Bonnes propriétés des diagrammes généraux<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />Simple à comprendre, notamment pour des décideurs<br />les différents acteurs <br />leurs interactions avec le système<br />les limites du système<br />xxx<br />Acteur 1<br />xxx<br />xxx<br />Acteur 2<br />Acteur 3<br />12<br />
  58. 58. CU : texte vs diagramme (2/4)Problèmes des diagrammes précis<br /><ul><li>Exprimer des besoins avec un diagramme de CU tend naturellement à produire une décomposition fonctionnelle hiérarchique de l’application
  59. 59. exactement ce qu’on veut éviter avec la conception objet !</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />13<br />
  60. 60. CU : texte vs diagramme (2/4)Problèmes des diagrammes précis<br /><ul><li>Les diagrammes de CU ne sont pas précis et génèrent des erreurs d’interprétation
  61. 61. Le nom d’un CU n’est pas un indicateur précis de ce qu’il s’y passe
  62. 62. La forme en graphe du CU n’est pas lisible par tout le monde</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />14<br />
  63. 63. CU : texte vs diagramme (2/4)Problèmes des diagrammes précis<br /><ul><li>Un diagramme de CU peut devenir très compliqué (spaghettis illisibles)
  64. 64. Le concepteur ne maîtrise plus sa conception
  65. 65. L’utilisateur ne comprend pas : comment pourrait-il valider ? </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />xxx<br />15<br />
  66. 66. CU : texte vs diagramme (3/4)Dialoguer avec un utilisateur<br /><ul><li>Les CU sont issus du dialogue entre concepteurs (informaticiens) et futurs utilisateurs (non informaticiens) pour
  67. 67. passer du flou du cahier des charges à des fonctionnalités exprimées dans le langage du domaine, donc celui des utilisateurs
  68. 68. exprimer complètement les besoins, tout au long du processus de conception de système d’information
  69. 69. Les CU doivent être validés par les futur utilisateurs : lisibilité impérative
  70. 70. l’utilisateur ne doit pas faire confiance à l’informaticien, il doit comprendre et réagir s’il n’est pas d’accord
  71. 71. Un CU textuel raconte l’histoire du futur utilisateur avec le futur système</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />16<br />
  72. 72. CU : texte vs diagramme (4/4)Conclusion<br />Privilégier les description textuelles, les seules qui décrivent réellement les besoins fonctionnels de façon partageable<br />N’utiliser les diagrammes de CU que comme tables des matières donnant accès aux différentes descriptions textuelles<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />17<br />
  73. 73. Petit exercice à faire en classe<br />Quels sont les acteurs et les cas d’utilisation d’un système d’information pour l’Université ?<br />18<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />
  74. 74. Plan <br />Présentation standard des CU<br />Rédaction de cas d’utilisation<br />d’après Alistair Cockburn (2001) Rédiger des cas d’utilisation efficaces, Eyrolles, Paris. 290 pp.<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />19<br />
  75. 75. Plan <br /><ul><li>Présentation standard des CU
  76. 76. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />20<br />
  77. 77. A quoi servent les CU ? <br /><ul><li>Clarifier les processus métier
  78. 78. bien comprendre le domaine, l’organisation pour laquelle on va concevoir et fabriquer le SI
  79. 79. complète la modélisation du domaine
  80. 80. Fixer les limites du système
  81. 81. bien comprendre ce qui relève du système à concevoir et à construire
  82. 82. … et ce qui n’en relève pas
  83. 83. Orienter la discussion
  84. 84. entre les concepteurs, le client, les futurs utilisateurs </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />21<br />
  85. 85. A quoi servent les CU ? (suite)<br />Découvrir / fixer les besoins fonctionnels<br />fixer des exigences (contrat), mais pas toutes les exigences<br />importance des conditions d’échec pour ne rien laisser dans l’ombre<br />le plus important pour toute conception : décrire ce que le système permet de faire<br />Remarque <br />Les cas d’utilisation seront réalisés avec des interactions d’objets : base de l’analyse et de la conception proprement dites<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />22<br />
  86. 86. A quoi servent les CU ? (suite)<br /><ul><li>Préparer les tests
  87. 87. CU = description du fonctionnement du futur système
  88. 88. Unir tous les modèles d’un projet
  89. 89. tout choix de conception vient d’un cas d’utilisation
  90. 90. les CU sont un des points d’entréevers la documentation de la conception(avec la description de l’architecture)</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />23<br />perf<br />IHM<br />…<br />CU<br />Protocoles<br />…<br />data<br />
  91. 91. Définition générale (Cockburn)<br /> « Un cas d’utilisation établit entre les différents intervenants un contrat régissant le comportement d’un système. Il décrit ce comportement sous diverses conditions, lorsque le système répond à une requête émanant de l’un des intervenants, appelé acteurprincipal. L’acteur principal amorce une interaction avec le système en vue d’atteindre un objectif particulier. Le système répond, en veillant à protégerlesintérêts de tous les intervenants. Diverses séquences de comportement, ou scénarios, peuvent se déployer en fonction des requêtes effectuées et des conditions de leur réalisation. Le cas d’utilisation regroupe ces différents scénarios. »<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />24<br />
  92. 92. Forme des cas d’utilisation<br /><ul><li>Essentiellement textuelle
  93. 93. le diagramme des CU UML n’est là que comme table des matières
  94. 94. Description des CU
  95. 95. ensemble de rubriques
  96. 96. différents niveaux de détail suivant les besoins
  97. 97. simplifiés : petite équipe soudée
  98. 98. détaillés : gros projets…
  99. 99. Faciles à lire
  100. 100. mais difficiles à écrire…
  101. 101. risques : ne pas être au bon niveau d’abstraction, ne pas savoir quel système on modélise exactement</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />25<br />CU<br />Acteur<br />CU<br />Nom : <le nom doit indiquer l’objectif sous la forme d’une courte expression verbale infinitive exprimant une action><br />Contexte d’utilisation : <formulation plus longue de l’objectif, si nécessaire, dans ses conditions de déroulement normal><br />Portée : <portée de conception : quel système est considéré comme boîte noire en cours de conception><br />Niveau :<stratégique, objectif utilisateur, sous-fonction><br />Acteur principal :<nom de rôle de l’acteur principal ou description><br />Intervenants et intérêt :<liste d’intervenants et d’intérêts essentiels dans le CU><br />Pré-condition :<ce que doit être l’état du monde avant le début du CU><br />
  102. 102. Rubriques d’un cas d’utilisation<br />Nom / objectif<br />Contexte d’utilisation<br />Portée <br />Niveau <br />Acteur principal<br />Intervenants et intérêt <br />Garanties minimales<br />Garanties en cas de succès<br />Déclencheur<br />Scénario nominal<br />étapes<br />Extensions <br />étapes<br />Listes de variantes de technologies et de données : <br />Informations connexes<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />26<br />
  103. 103. Plan <br /><ul><li>Présentation standard des CU
  104. 104. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />27<br />
  105. 105. Intervenant et intérêts <br /><ul><li>Intervenant
  106. 106. personne ou élément ayant un intérêt matériel dans le comportement du Système A l’Etude (SAE)
  107. 107. Acteur
  108. 108. Intervenant particulier ayant un comportement digne d’intérêt pour décrire les cas d’utilisation
  109. 109. remarque
  110. 110. dans cette définition, le système est un acteur, qui pourra intervenir dans certains types de CU (portée organisation)
  111. 111. Acteur principal
  112. 112. intervenant déclenchant une interaction avec le SAE dans le but d’atteindre un objectif
  113. 113. objectif = nom du cas d’utilisation</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />28<br />
  114. 114. Un CU est un contrat entre intervenants ayant des intérêts<br /><ul><li>Le contrat porte sur le comportement du Système à l’Etude
  115. 115. Certains intervenants sont présents, d’autre sont hors champ
  116. 116. Le système sert l’acteur principal tout en protégeant les intervenants hors champ
  117. 117. Ex. conserver une trace des transactions en cas de litige
  118. 118. Pour chaque CU
  119. 119. recenser tous les intervenants
  120. 120. nommer leur intérêt par rapport à la réalisation du CU
  121. 121. Que signifie le succès ? Quelles sont les garanties à maintenir ?</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />29<br />
  122. 122. Le CU-contrat porte sur le comportement du système<br /><ul><li>Le CU décrit
  123. 123. tous les comportements pour satisfaire les intérêts des intervenants,
  124. 124. et uniquement ces comportements-là
  125. 125. Chaque étape d’un CU n’a de justification que si elle décrit une action
  126. 126. protégeant les intérêts d’un intervenant
  127. 127. accroissant les intérêts d’un intervenant
  128. 128. Trois sortes d’actions du système
  129. 129. une interaction entre deux acteurs (pour faire avancer un objectif)
  130. 130. une validation (pour protéger un intervenant)
  131. 131. un changement d’état interne (pour satisfaire les intérêt d’un intervenant)</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />30<br />
  132. 132. Plan <br /><ul><li>Présentation standard des CU
  133. 133. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />31<br />
  134. 134. Portée de conception : système à l’étude<br /><ul><li>Système à l’étude
  135. 135. ce dont on est en train de décrire / modéliser le comportement
  136. 136. Différents systèmes « emboîtés » à considérer
  137. 137. entreprise – organisation (pour fixer le contexte)
  138. 138. intervenants : actionnaires, fournisseurs, administration, clients
  139. 139. acteurs principaux : clients, fournisseurs
  140. 140. système logiciel (le plus souvent)
  141. 141. intervenants : utilisateurs, société, administration, autres programmes
  142. 142. acteurs principaux : utilisateurs, autres programmes
  143. 143. sous-partie logicielle (si besoin)</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />32<br />
  144. 144. Trois portées de conception :1. entreprise / organisation<br /><ul><li>On décrit le comportement de l’entreprise dans son ensemble dans la réalisation de l’objectif que poursuit l’acteur principal
  145. 145. « métier » de l’entreprise
  146. 146. Possibilité de considérer l’entreprise comme
  147. 147. boîte noire
  148. 148. vue uniquement de l’extérieur
  149. 149. boîte blanche
  150. 150. fonctionnement interne explicite
  151. 151. Exemple
  152. 152. fonctionnement de l’organisation Université au sein de l’Education Nationale
  153. 153. fonctionnement interne de l’organisation Université </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />33<br />
  154. 154. Trois portées de conception :2. système à construire<br /><ul><li>On décrit le comportement du système à construire
  155. 155. caractérisation du futur système
  156. 156. Possibilité de considérer le système comme
  157. 157. boîte noire
  158. 158. pour définir ses interaction avec l’extérieur (acteurs)
  159. 159. de loin le plus important pour l’expression des besoins
  160. 160. boîte blanche
  161. 161. pour révéler le fonctionnement des composants
  162. 162. Ex.
  163. 163. système de gestion des emplois du temps de l’Université
  164. 164. vu du point de vue de ses interaction avec les utilisateurs et les autres systèmes de l’Université
  165. 165. vu du point de vue interne</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />34<br />
  166. 166. Trois portées de conception :3. sous-système<br />On décrit une sous-partie du systèmes à construire<br />fonctionnement d’une des parties du système<br />Exemple<br />sous-système de description des caractéristiques des salles dans le système de gestion des emplois du temps <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />35<br />
  167. 167. Organisation<br />Système<br />SS1<br />SS2<br />SS3<br />En résumé<br />
  168. 168. Plan <br /><ul><li>Présentation standard des CU
  169. 169. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />37<br />
  170. 170. Acteurs<br /><ul><li>Un acteur a des objectifs (et des sous-objectifs)
  171. 171. les objectifs peuvent échouer
  172. 172. Un cas d’utilisation
  173. 173. a un nom qui est l’objectif de l’acteur principal
  174. 174. regroupe des scénarios
  175. 175. qui se terminent par des succès ou des échecs
  176. 176. qui décrivent comment on arrive à ce terme
  177. 177. décomposés en séquences d’étapes
  178. 178. avec des objectifs de plus bas niveau, pouvant donner lieu à des sous-cas d’utilisation</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />38<br />
  179. 179. Acteurs et intervenants liés à un CU<br /><ul><li>Les intervenants
  180. 180. ont un intérêt matériel dans la bonne réalisation du CU
  181. 181. prennent part au contrat que représente le CU
  182. 182. Les acteurs
  183. 183. ont un comportement pendant la réalisation du CU : ils agissent directement
  184. 184. Exemple distributeur bancaire
  185. 185. L’Etat, les banques sont des intervenants
  186. 186. Le client, le réparateur, le système CB sont des acteurs</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />39<br />
  187. 187. Différents types d’acteurs<br /><ul><li>Acteur principal
  188. 188. demande au système de faire quelque chose pour lui (de lui fournir un service), poursuit un objectif
  189. 189. en général le déclencheur du CU
  190. 190. utilisation d’un bouton, choix d’un menu, etc.
  191. 191. possibilité de déclencheurs non acteurs principaux
  192. 192. employé, « relais » pour le compte d’une client
  193. 193. temps (lancement automatique régulier)
  194. 194. importance par rapport à la conception
  195. 195. début : bien identifier besoins et utilisateurs
  196. 196. en cours : fragmentation des rôles (de multiples acteurs peuvent jouer le même rôle)
  197. 197. fin : important pour préparer la livraison
  198. 198. caractérisation
  199. 199. tableau nom / profil (description succincte)</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />40<br />
  200. 200. Différents types d’acteurs (suite)<br /><ul><li>Acteurs de second plan
  201. 201. acteur fournissant un service au système en cours de conception
  202. 202. ex. serveur d’impression
  203. 203. Acteur système à l’étude
  204. 204. également un acteur dans les CU de portée organisation boîte blanche
  205. 205. Acteurs internes
  206. 206. composants
  207. 207. nécessite une portée du CU au niveau système en boîte blanche</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />41<br />
  208. 208. Trois niveaux d’objectifs :1. objectifs utilisateur<br /><ul><li>Objectifs utilisateur
  209. 209. niveau de la mer
  210. 210. test : l’acteur principal est-il satisfait après avoir terminé le CU ?
  211. 211. notion de session / test de la pause café
  212. 212. ex. « acheter un livre », « enregistrer un client »
  213. 213. mauvais : « ouvrir une session » (trop bas), « réaliser un achat par enchère en ligne » (trop haut)
  214. 214. composé de sous-objectifs sous le niveau de la mer</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />42<br />
  215. 215. Trois niveaux d’objectifs :2. objectifs stratégiques<br /><ul><li>Objectifs stratégiques
  216. 216. impliquent plusieurs objectifs utilisateurs
  217. 217. servent à
  218. 218. montrer le contexte pour l’utilisateur
  219. 219. montrer le séquencement des objectifs liés
  220. 220. fournir une table des matières
  221. 221. au dessus du niveau de la mer
  222. 222. plus haut encore
  223. 223. jouent sur plusieurs mois, années
  224. 224. ex. « traiter une demande d’indemnisation », « gérer une formation »
  225. 225. les CU aux limites sont stratégiques</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />43<br />
  226. 226. Trois niveaux d’objectifs :3. objectifs sous-fonctions<br /><ul><li>Objectifs sous-fonctions
  227. 227. permettent la réalisation des objectifs utilisateurs
  228. 228. ex. « trouver un produit », « enregistrer un fichier », « s’identifier »
  229. 229. sous l’eau
  230. 230. voire au fond
  231. 231. trop loin pour les détailler
  232. 232. à utiliser avec parcimonie
  233. 233. pour clarifier des CU utilisateur
  234. 234. parce que beaucoup d’objectifs en font usage
  235. 235. remarque
  236. 236. possèdent bien un acteur principal</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />44<br />
  237. 237. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />45<br />Trois niveaux d’objectifs : récapitulatif<br />Objectifs stratégiques<br />Gérer les EdT<br />Gérer les salles<br />Gérer les UE <br />Gérer les affectations <br />Objectifs utilisateurs<br />Ajouter une formation<br />Ajouter une salle<br />Signaler une salle en travaux<br />Ajouter une UE <br />Affecter une salle à une UE<br />Diffuser vers le site web<br />S’identifier<br />Identifier une salle<br />Choisir une date<br />Identifier une UE<br />Objectifs sous-fonctions<br />
  238. 238. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />46<br />Passer d’un niveau d’objectif à l’autre : pourquoi / comment<br />Objectif du CU<br />Objectif des étapes<br />Pourquoi?<br />Objectif du CU<br />Comment?<br />Objectif des étapes<br />
  239. 239. Résumé niveaux d’objectif / portées<br />Plusieurs niveaux d’objectif <br />objectif stratégique<br />fonction du SI dans organisation<br />on se rapproche des processus métier<br />objectif utilisateur<br />fonction du SI pour l’utilisateur<br />objectif sous-fonction<br />fonction interne au système, utile pour l’informaticien<br />Plusieurs portées de conception<br />organisation (boîte blanche ou noire)<br />système (boîte blanche ou noire)<br />composant<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />47<br />
  240. 240. Résumé<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />48<br />
  241. 241. Un façon de penser générique<br /><ul><li>Acteurs / objectifs / étapes
  242. 242. Utilisable à différents niveaux, avec différents types d’acteurs
  243. 243. organisation, individu, système informatique
  244. 244. Permet de modéliser différents systèmes à différents niveaux
  245. 245. de l’organisation interne d’une entreprise au fonctionnement d’un sous-système informatique
  246. 246. Tout la difficulté est de se trouver au bon niveau pour les besoins du moment</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />49<br />
  247. 247. Conseil / méthode<br /><ul><li>Mettre beaucoup d’énergie pour détecter les CU au niveau de la mer
  248. 248. question à se poser
  249. 249. « est-ce là ce que l’acteur principal attend du système maintenant ? »
  250. 250. si la réponse est non et qu’on est trop bas
  251. 251. « que veut réellement l’acteur principal ? », « pourquoi agit-il ainsi ? »
  252. 252. pour monter de niveau d’objectif
  253. 253. question « pourquoi ? »
  254. 254. Remarque
  255. 255. pour réorganiser les CU, il est facile de couper/coller du texte d’un CU à l’autre</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />50<br />
  256. 256. Conseil / méthode (suite)<br />Rédiger quelques CU aux limites pour créer un contexte pour les autres<br />CU aux limites : niveau stratégique, portée maximale<br />atteinte quand l’acteur principal rentre dans la portée<br />exemples de portées : entreprise, service (commercial, informatique), client, etc.<br />entre 2 et 5 CU aux limites par conception<br />montrent comment le système finit par bénéficier aux utilisateurs les plus éloignés<br />serviront de tables des matières pour les autres CU<br />Ex. diagramme UML de CU cliquable<br />51<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />
  257. 257. Plan <br /><ul><li>Présentation standard des CU
  258. 258. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />52<br />
  259. 259. Préconditions, garanties et déclencheurs<br /><ul><li>Précondition
  260. 260. ce que le système garantit avant le début du CU
  261. 261. ex. « l’utilisateur a ouvert une session », « le client a été validé »
  262. 262. Garanties minimales
  263. 263. promesses du système aux intervenants
  264. 264. intéressant quand le CU échoue
  265. 265. ex. « un journal est tenu » (très courant), « la commande n’est lancée qu’une fois le règlement reçu »
  266. 266. Garantie en cas de succès
  267. 267. intérêts des intervenants satisfaits si le CU réussit
  268. 268. ex. « le fichier sera sauvegardé », « le système lancera une commande pour le client »
  269. 269. Déclencheur
  270. 270. événement qui lance le CU
  271. 271. ex. « le client insère sa carte », « le client appelle pour se plaindre »</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />53<br />
  272. 272. Plan <br /><ul><li>Présentation standard des CU
  273. 273. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />54<br />
  274. 274. Scénarios : définitions<br /><ul><li>Scénario
  275. 275. ligne narrative qui débute avec le déclencheur, se poursuit jusqu’à la réalisation complète ou l’abandon
  276. 276. Cas d’utilisation
  277. 277. ensemble de scénarios couvrant le CU, décrit minimalement
  278. 278. scénario nominal + ses extensions
  279. 279. Cadre général pour les scénarios
  280. 280. condition sous laquelle s'exécute le scénario (précondition + déclencheur, condition d’extension)
  281. 281. objectif à atteindre
  282. 282. ensemble d’étapes d’actions
  283. 283. condition de fin
  284. 284. ensemble d’extension (fragments de scénario)
  285. 285. Même modèle rédactionnel pour les scénarios quelque soit le niveau d’objectif</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />55<br />
  286. 286. Un scénario est composé d’étapes<br /><ul><li>Étape : séquence d’actions formulant un objectif
  287. 287. peut se détailler en sous-étapes
  288. 288. remarque :
  289. 289. possibilité d’indiquer textuellement un ordre indifférent, une répétition
  290. 290. un objectif d’étape est un sous-objectif de l’objectif du CU
  291. 291. Actions possibles
  292. 292. interaction entre deux acteurs
  293. 293. « le client saisit une adresse »
  294. 294. validation pour protéger les intérêts d’un intervenant
  295. 295. « le système valide le code secret »
  296. 296. changement interne pour satisfaire les intérêts d’un intervenant
  297. 297. « le système déduit le montant du solde »</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />56<br />Exercice<br />
  298. 298. Directives pour les étapes<br /><ul><li>Utiliser une forme grammaticale simple
  299. 299. sujet … verbe … COD … autre complément
  300. 300. Montrer clairement « qui a le ballon »
  301. 301. qui a la main à la fin de l’étape ?
  302. 302. Le système ? L'utilisateur ? Un autre système ?
  303. 303. Adopter le « point de vue d’un oiseau »
  304. 304. pas celui du système
  305. 305. Montrer le processus en train d’avancer
  306. 306. pas plus de 9 étapes pour un scénario nominal
  307. 307. chaque étape rapproche de l’objectif qui est toujours le même pour le même acteur principal
  308. 308. Montrer l’intention de l’acteur, pas ses gestes
  309. 309. ne pas spécifier l’interface</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />57<br />
  310. 310. Directives pour les étapes (suite)<br /><ul><li>Inclure un ensemble « raisonnable » d’actions
  311. 311. regrouper ou dissocier en fonction des points d’extensions
  312. 312. Utiliser « valider » et lieu de « vérifier si »
  313. 313. « valider » est bien orienté vers la satisfaction d’un objectif
  314. 314. Mentionner éventuellement le déroulement temporel
  315. 315. « à tout moment », « dès que »
  316. 316. Utiliser la locution « l’utilisateur amène le système A à solliciter le système B »
  317. 317. pour éviter de parler de l’interface
  318. 318. Utiliser la locution « effectuer les étapes x-y jusqu’à la condition z »
  319. 319. pour les répétitions</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />58<br />
  320. 320. Plan <br /><ul><li>Présentation standard des CU
  321. 321. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />59<br />
  322. 322. Extensions : définitions<br /><ul><li>Pour éviter d’utiliser des « si » dans les scénarios
  323. 323. rapidement incompréhensibles s’il y a plusieurs niveaux
  324. 324. Extension = fragment de scénario
  325. 325. présente souvent les exigences système les plus intéressantes
  326. 326. fait souvent intervenir des règles métiers non explicitées jusque là
  327. 327. A prendre en compte systématiquement :
  328. 328. chemin alternatif de succès,
  329. 329. acteur principal avec comportement incorrect,
  330. 330. inaction du fait de l’acteur principal,
  331. 331. échec pour chaque étape de validation,
  332. 332. réponse inappropriée ou absence de réponse d’un acteur secondaire,
  333. 333. échec interne « normal » au système (ex. bourrage papier),
  334. 334. échec interne « anormal » ou inattendu (fichier journal endommagé),
  335. 335. échec de performance critique à détecter (ex. calcul trop long)…</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />60<br />
  336. 336. Conditions d’extension<br /><ul><li>Condition pour laquelle le système adoptera un comportement différent
  337. 337. ex. « l’enregistrement échoue : », « le système détecte lui-même la nécessité d’une sauvegarde intermédiaire : »
  338. 338. bien réfléchir à tout ce qui peut mal se passer, aux voies alternatives de succès
  339. 339. Directive pour les conditions d’extension
  340. 340. faire dire à la condition ce qui a été détecté
  341. 341. Une fois la liste faite, la rationaliser
  342. 342. le moins possible d’extensions : validation, regroupement
  343. 343. vérification :  le système doit être en mesure de détecter la condition, le système doit prendre en charge sa détection</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />61<br />
  344. 344. Ecriture des extensions<br /><ul><li>Extension = fragment de scénario = séquence d’étapes
  345. 345. jusqu’au retour au scénario nominal
  346. 346. retour comme si l’étape avait réussi
  347. 347. ex. rechercher une URL à la main après l’échec d’une URL pré-enregistrée : on a fait « autrement »
  348. 348. deuxième chance à l’utilisateur
  349. 349. ex. mot de passe à retaper
  350. 350. jusqu’à la fin du CU par succès alternatif
  351. 351. autre manière de réussir
  352. 352. jusqu’à la fin du CU par échec
  353. 353. impossible à récupérer
  354. 354. ex. 3 mots de passe faux de suite</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />62<br />
  355. 355. Extensions des extensions<br />En cas d’échec dans un échec<br />continuer à rédiger en utilisant des retraits et une numérotation adéquate tant que c’est compréhensible<br />en général pas au delà de 2-3 niveaux<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />63<br />
  356. 356. CU d’extension<br /><ul><li>Sous-cas d’utilisation qui décrit l’extension
  357. 357. appelé dans une étape
  358. 358. Ex. L’utilisateur enregistre le rapport
  359. 359. A créer dans les cas suivants
  360. 360. si l’extension revient à plusieurs endroits
  361. 361. peut être « factorisée »
  362. 362. si l’extension est trop compliquée et nuit à la lisibilité du CU
  363. 363. si le CU étendu ne peut pas être modifié
  364. 364. service asynchrone qui ne doit pas déranger le CU de base
  365. 365. complément à un CU de base verrouillé
  366. 366. Attention :
  367. 367. complique la maintenance de la base des CU</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />64<br />
  368. 368. Plan <br /><ul><li>Présentation standard des CU
  369. 369. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />65<br />
  370. 370. Variantes de technologies et de données<br /><ul><li>Point de variation du CU servant à décrire les autres possibilités
  371. 371. technologies qui pourraient être utilisées, autres types de données
  372. 372. Exemple
  373. 373. Dans le scénario nominal
  374. 374. 2. L’utilisateur s’identifie, ainsi que sa banque et son numéro de compte
  375. 375. Dans les variantes
  376. 376. 2a. Utiliser une carte bancaire, une empreinte optique, ou une empreinte digitale</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />66<br />
  377. 377. Plan <br /><ul><li>Présentation standard des CU
  378. 378. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />67<br />
  379. 379. Quatre niveaux de précision<br /><ul><li>Les niveaux donnent des indications sur
  380. 380. l’énergie à mettre dans la rédaction des CU
  381. 381. ne pas aller aux détails trop tôt
  382. 382. les étapes de validation
  383. 383. vérification régulière de la cohérence globale
  384. 384. Niveau 1 : Acteurs et objectifs
  385. 385. exigences fonctionnelles de premier niveau de précision
  386. 386. Niveau 2 : Résumé des CU (scénarios nominaux)
  387. 387. vérifier que le système répond aux intérêts des intervenants
  388. 388. Niveau 3 : Conditions d’extension
  389. 389. liste exhaustive des conditions d’extension (souvent échecs)
  390. 390. Niveau 4 : Prise en compte des extensions
  391. 391. comment le système prend en compte ces extension</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />68<br />
  392. 392. Format simplifié<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />69<br />Nom : <br />Acteur principal :<br />Portée :<br />Niveau :<br />Quelques paragraphes de description<br />
  393. 393. Format étoffé<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />70<br />Nom : <le nom doit indiquer l’objectif sous la forme d’une courte expression verbale infinitive exprimant une action><br />Contexte d’utilisation : <formulation plus longue de l’objectif, si nécessaire, dans ses conditions de déroulement normal><br />Portée : <portée de conception : quel système est considéré comme boîte noire en cours de conception><br />Niveau :<stratégique, objectif utilisateur, sous-fonction><br />Acteur principal :<nom de rôle de l’acteur principal ou description><br />Intervenants et intérêt :<liste d’intervenants et d’intérêts essentiels dans le CU><br />Pré-condition :<ce que doit être l’état du monde avant le début du CU><br />Garanties minimales : <mode de protection des intérêts quelle que soit l’issue><br />Garanties en cas de succès : <état du monde si l’objectif est rempli><br />Déclencheur : <ce qui démarre le CU ; peut être un événement temporel><br />Scénario nominal : <étapes du scénario du déclenchement à lal réalisation de l’objectif><br /><numéro d’étape><description de l’action><br />Extensions : <extensions, une par une, chacune faisant référence à l’étape concernée du scénario nominal><br /><numéro d’étape modifiée><condition> : <action ou sous-cas d’utilisation<br />Listes de variantes de technologies et de données : <><br />Informations connexes : <tout type d’information dont peut avoir besoin votre projet><br />
  394. 394. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />71<br />Exempledecription longue<br />Retirer de l’argent<br />Client <br />CU : Retirer de l’argent<br />Portée : système DAB <br />Niveau : objectif utilisateur<br />Acteur principal : Client<br />Intervenants et intérêts : Banque, Client<br />Préconditions : compte approvisionné<br />Garanties minimales : rien ne se passe<br />Garanties en cas de succès : de l’argent est retiré, le compte est débité de la même somme<br />…<br />
  395. 395. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />72<br />Exempledecription longue<br />Retirer de l’argent<br />Client <br />…<br />Scénario nominal :<br />Le Client introduit sa carte dans le lecteur.<br />Le DAB décrypte l’identifiant de la banque, le numéro de compte et le code secret de la carte, valide de la banque et le numéro de compte auprès du système principal.<br />Le client saisit son code secret. Le DAB valide par rapport au code secret crypté lu sur la carte.<br />Le client sélectionne retrait, et un montant multiple de 10 € (min 20 €)<br />Le DAB soumet au principal système de la banque le compte client et le montant demandé, et reçoit en retour une confirmation et le nouveau solde du compte<br />Le DAB délivre la carte, l’argent et un reçu montrant le nouveau solde<br />Le DAB consigne la transaction<br />…<br />
  396. 396. 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />73<br />Exempledecription longue<br />Retirer de l’argent<br />Client <br />…<br />Extensions :<br />*a. Panne générale. <br /> *a1. Le DAB annule la transaction, signale l’annulation, et rend la carte.<br />2a. Carte volée.<br /> 2a1. Le DAB confisque la carte volée<br />4a. Plus de billets de 10 €<br /> 4a1. Le DAB arrondit la somme demandée à un multiple de 20 €.<br /> 4a2. Le Client valide la nouvelle somme demandée.<br />5a. Solde insuffisant.<br /> 5a1. Le DAB signale que la somme demandée est trop élevée et rend la carte.<br />Inclusion autre scénario<br />
  397. 397. Autres formats<br />RUP<br />Tableau à une colonne<br />Tableau à deux colonnes<br />À base de diagrammes<br />etc. <br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />74<br />
  398. 398. Plan <br /><ul><li>Présentation standard des CU
  399. 399. Rédaction de cas d’utilisation</li></ul>Généralités<br />Intérêts et intervenants <br />Portée de conception<br />Acteurs et objectifs<br />Préconditions, garanties et déclencheurs<br />Scénarios<br />Extensions<br />Variantes de technologies et de données<br />Formats de CU<br />Divers<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />75<br />
  400. 400. Quand avons-nous fini de rédiger des cas d’utilisation ? <br /><ul><li>Tous les acteurs principaux et les objectifs utilisateurs sont identifiés
  401. 401. Toutes les conditions de déclenchement ou d’extension sont identifiées
  402. 402. Tous les CU d’objectif utilisateur sont rédigés ainsi que les CU stratégiques et sous-fonctions nécessaires à leur réalisation
  403. 403. Chaque CU est rédigé avec assez de clarté pour que
  404. 404. les représentant des client puisse convenir à la livraison que oui ou non le CU a bien été réalisé
  405. 405. les utilisateurs conviennent que le comportement du système tel qu’il est décrit répond pleinement, ou du moins de façon acceptable à leurs souhaits
  406. 406. les développeurs conviennent qu’ils peuvent effectivement développer cette fonction
  407. 407. Les clients conviennent que l’ensemble des CU couvrent tous leurs souhaits (pour l’instant) </li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />76<br />
  408. 408. Notion de récit d’utilisation<br /><ul><li>Histoire d’un acteur utilisant le système de façon spécifique
  409. 409. situation extérieure, état mental, actions, motivations, etc.
  410. 410. un ou deux paragraphes
  411. 411. A utiliser avant de commencer à rédiger les cas d’utilisation pour
  412. 412. donner un début de vision commune du système à concevoir
  413. 413. planter le décor pour les cas d’utilisation</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />77<br />
  414. 414. Ecrire les CU en équipe<br /><ul><li>D’abord : produire une vue de bas niveau de précision de la fonction du système : récits d’utilisation
  415. 415. s’accorder sur un récit d'utilisation (en groupe)
  416. 416. s’accorder sur la portée et réfléchir aux acteurs et objectifs (en groupe)
  417. 417. écrire les récit (séparément)
  418. 418. recueillir et valider/réviser les récits (en groupe)
  419. 419. Puis : produire une vue de niveau élevé de précision : cas d’utilisation
  420. 420. réfléchir sur les CU à rédiger (en groupe)
  421. 421. s'accorder sur un format de CU (en groupe)
  422. 422. écrire et réviser les CU (séparément)
  423. 423. réviser les CU (en groupe)
  424. 424. Durée
  425. 425. plusieurs semaines</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />78<br />
  426. 426. Erreurs fréquentes de rédaction<br /><ul><li>Oublier le système ou l’acteur principal
  427. 427. les introduire dans la description
  428. 428. Trop de détails d’IHM
  429. 429. décrire les intentions de l’utilisateur sans prendre de décision d’interface
  430. 430. Objectifs de niveau trop bas
  431. 431. fusionner, remonter le niveau (question « pourquoi ? »)
  432. 432. Intention et contenu ne coïncident pas
  433. 433. adéquation non du nom / contenu des étapes</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />79<br />
  434. 434. CU : aide-mémoire<br /><ul><li>Un CU est un essai en prose
  435. 435. Veillez à la lisibilité des CU
  436. 436. Veillez à la qualité des phrases utilisées pour décrire les étapes
  437. 437. Utilisez l’inclusion de sous-cas d’utilisation si besoin
  438. 438. Qui a le ballon ?
  439. 439. Identifiez les bons niveaux d’objectifs
  440. 440. Laissez de côté l’IHM
  441. 441. Seules deux fins possibles : succès ou échec
  442. 442. Les intervenants ont besoin de garanties
  443. 443. Préconditions et CU de niveau supérieur
  444. 444. Travaillez en largeur sur l’ensemble des CU</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />80<br />
  445. 445. CU : processus d’écriture<br /><ul><li>Réfléchissez ensemble et désignez la portée et les frontières du système
  446. 446. Réfléchissez ensemble et recensez les acteurs principaux
  447. 447. Réfléchissez ensemble et dressez la liste exhaustive des objectifs utilisateur pour le système
  448. 448. Identifiez les CU stratégiques aux limites pour voir qui se soucie réellement du comportement
  449. 449. Reconsidérez et révisez les CU stratégiques. Ajoutez, retirez ou fusionnez des objectifs.</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />81<br />
  450. 450. CU : processus d’écriture (suite)<br /><ul><li>Sélectionnez un CU à développer
  451. 451. Identifier les intervenants et intérêts, les pré-conditions et les garanties
  452. 452. Ecrivez les scénarios nominaux
  453. 453. Réfléchissez ensemble et dressez la liste exhaustive des conditions d’extension
  454. 454. Rédigez les étapes de prise en charge des extensions
  455. 455. Extrayez les flots complexes pour en faire des sous-cas d’utilisation
  456. 456. Fusionnez les sous-cas d’utilisation simples
  457. 457. Réajustez l’ensemble : ajoutez, retirez, fusionnez en fonction des besoins</li></ul>2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />82<br />
  458. 458. Conclusion<br />TD conception liés à la rédaction de cas d’utilisation<br />D’autres informations sur <br />http://alistair.cockburn.us/usecases/usecases.html<br />2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction <br />83<br />

×