Le document présente les cas d'utilisation et les diagrammes associés selon la norme UML, en se basant sur les principes d'Alistair Cockburn. Il explique comment les cas d'utilisation servent à capturer les exigences fonctionnelles d'un système et à définir les interactions entre les acteurs et le système. Enfin, il argumente en faveur de l'utilisation de descriptions textuelles plutôt que de diagrammes pour mieux communiquer les besoins fonctionnels.

1. Cas d’utilisation et expression de besoinsYannick PriéDépartement Informatique – Faculté de Sciences et TechnologiesUniversité Claude Bernard Lyon 12011-2012

2. Objectifs de ce coursPrésenter les cas d’utilisation et les diagrammes de cas d’utilisation de façon « standard » ce qu’on trouve en général dans la norme UMLPrésenter de façon précise une façon particulière de penser les cas d’utilisationd’après le livre de Alistair Cockburn qui fait référence, au delà de la normeà utiliser dans cette UE2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 2

3. Plan Présentation standard des CURédaction de cas d’utilisation2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 3

4. Cas d’utilisationTechnique pour capturer les exigences fonctionnelles d’un système

5. déterminer ses limites

6. déterminer ce qu’il devra faire, quels services il rendra

7. mais pas comment il devra le faire

8. point de vue de l’utilisateur

9. Pour cela

10. déterminer les acteurs qui interagissent avec le système

11. rôles

12. déterminer les grandes catégories d’utilisation

13. cas d’utilisation

14. décrire textuellement des interactions

15. scénarios2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 4

16. Acteur2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 5Client : 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.<<Acteur>>ImprimanteclientEntité (humain ou machine) située hors du système

17. permet de déterminer les limites du système

18. Un acteur joue un rôle par rapport au système

19. soit déclenche un stimulus entraînant une réaction du système

20. soit est sollicité par le système au cours d’un scénario

21. Un acteur est décrit précisément en quelques lignes

22. Catégories d’acteurs

23. acteurs principaux (fonctions principales du système)

24. acteurs secondaires (administration / maintenance)

25. matériel externe

26. autres systèmesCas d’utilisationEnsemble de séquences d’actions réalisées par le système, produisant un résultat observable pour un acteur particulier

27. ex. s’identifier, retirer du liquide, répondre à un mail

28. Un cas d’utilisation

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. 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 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 6

31. ScénarioSéquence particulière d’étape dans la réalisation d’un CU

32. Séquence particulière de messages dans le CU pendant une interaction particulière

33. « chemin » dans le cas d’utilisation

34. Tous les scénarios d’un CU sont issus du même acteur et ont le même objectif

35. Description du CU

36. ensemble de scénarios couvrant le CU

37. documents avec flot d’événements

38. détaille ce qui se passe entre utilisateur et le système quand le CU est exécuté

39. flot nominal des événements (80 %)

40. flots d’événements alternatifs

41. flots d’exceptions (terminaison incorrecte)

42. serviront de base pour les jeux d’essais2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 7scénario 1scénario 2CUscénario 3

43. Documentation des CU (1/4)Diagramme général des cas d’utilisation2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 8AssociationS’identifierActeur humainActeur non humainCas d’utilisationLimite du système

44. Faire un virementFaire un virementpar Minitel« extend »montant > 80 €Client local« include »Client distantVérifiersolde compteS’identifierDocumentation des CU (2/4)Diagramme avec relation entre CU« include » la réalisation d’un CU nécessite la réalisation d’un autre, sans condition, à un point d’extension (le seul important)« extend » 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)conseil : ne pas utiliser, ou seulement si on ne peut toucher à CU1« generalize » héritage. (conseil : ne pas utiliser)2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 9

45. Documentation des CU (3/4)Fiche textuelleEnsemble de champs de description

46. nom, préconditions…

47. Lisible et informelle

48. français simple, phrases descriptives

49. pas trop long (personne ne lit 10 pages)

50. Décrivant

51. un scénario nominal

52. suite d’étapes avec objectifs de l’acteur bien identifiés et menés à bien

53. des points d’extension et étapes d’extensions

54. des points d’échec

55. des liens vers d’autres scénarios s’il y a trop d’étapes2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 10

56. Documentation des CU (4/4)Complément de descriptionTout ce qui permet de mieux expliquer modèle du domainediagrammes de séquence systèmediagramme d’activité, de machines d’étatsdessin ou maquette d’interfacedocuments quelconques…2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 11

57. CU : texte vs diagramme (1/4)Bonnes propriétés des diagrammes généraux2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction Simple à comprendre, notamment pour des décideursles différents acteurs leurs interactions avec le systèmeles limites du systèmexxxActeur 1xxxxxxActeur 2Acteur 312

58. CU : texte vs diagramme (2/4)Problèmes des diagrammes précisExprimer des besoins avec un diagramme de CU tend naturellement à produire une décomposition fonctionnelle hiérarchique de l’application

59. exactement ce qu’on veut éviter avec la conception objet !2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx13

60. CU : texte vs diagramme (2/4)Problèmes des diagrammes précisLes diagrammes de CU ne sont pas précis et génèrent des erreurs d’interprétation

61. Le nom d’un CU n’est pas un indicateur précis de ce qu’il s’y passe

62. La forme en graphe du CU n’est pas lisible par tout le monde2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx14

63. CU : texte vs diagramme (2/4)Problèmes des diagrammes précisUn diagramme de CU peut devenir très compliqué (spaghettis illisibles)

64. Le concepteur ne maîtrise plus sa conception

65. L’utilisateur ne comprend pas : comment pourrait-il valider ? 2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx15

66. CU : texte vs diagramme (3/4)Dialoguer avec un utilisateurLes CU sont issus du dialogue entre concepteurs (informaticiens) et futurs utilisateurs (non informaticiens) pour

67. passer du flou du cahier des charges à des fonctionnalités exprimées dans le langage du domaine, donc celui des utilisateurs

68. exprimer complètement les besoins, tout au long du processus de conception de système d’information

69. Les CU doivent être validés par les futur utilisateurs : lisibilité impérative

70. l’utilisateur ne doit pas faire confiance à l’informaticien, il doit comprendre et réagir s’il n’est pas d’accord

71. Un CU textuel raconte l’histoire du futur utilisateur avec le futur système2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 16

72. CU : texte vs diagramme (4/4)ConclusionPrivilégier les description textuelles, les seules qui décrivent réellement les besoins fonctionnels de façon partageableN’utiliser les diagrammes de CU que comme tables des matières donnant accès aux différentes descriptions textuelles2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 17

73. Petit exercice à faire en classeQuels sont les acteurs et les cas d’utilisation d’un système d’information pour l’Université ?182010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction

74. Plan Présentation standard des CURédaction de cas d’utilisationd’après Alistair Cockburn (2001) Rédiger des cas d’utilisation efficaces, Eyrolles, Paris. 290 pp.2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 19

75. Plan Présentation standard des CU

76. Rédaction de cas d’utilisationGénéralitésIntérêts et intervenants Portée de conceptionActeurs et objectifsPréconditions, garanties et déclencheursScénariosExtensionsVariantes de technologies et de donnéesFormats de CUDivers2010-2011 / Yannick Prié - Université Claude Bernard Lyon 1 | UML : Diagrammes dynamiques et d'interaction 20

77. A quoi servent les CU ? Clarifier les processus métier

78. bien comprendre le domaine, l’organisation pour laquelle on va concevoir et fabriquer le SI

79. complète la modélisation du domaine

80. Fixer les limites du système

81. bien comprendre ce qui relève du système à concevoir et à construire

82. … et ce qui n’en relève pas