Archive

Articles taggués ‘use case’

Use Cases versus User Stories (2 sur 2)

La semaine dernière, Henri Darmet nous rappelait ce qu’étaient un Use Case et une User Story (et aussi ce qu’ils n’étaient pas). Il nous propose maintenant de voir ce qui lie ces deux notions… Hé bien, pas grand chose. L’une est « l’anglais » du besoin utilisateur, l’autre le « chinois ». On peut traduire de l’anglais en chinois (et vice versa), mais pas plus.

OK, mais que faut-il mieux faire, des Uses Cases ou des User Stories ? Eh bien là aussi, la comparaison avec l’anglais et le chinois est pertinente : vaut-il mieux parler anglais ou chinois ? Ça dépend… généralement, c’est l’anglais, mais en Chine, le chinois est plus efficace et plus convivial.

Essayons quand même de voir ce qui rassemble les Use Cases et les User Stories, ce qui les sépare, et les contextes dans lesquels ces  approches sont les plus adaptées.

Lire la suite…

Use Cases versus User Stories (1 sur 2)

Que de choses ont été dites, pour les définir, les comparer, les opposer, les réunifier ! Alors, afin d’entretenir la confusion ambiante, Henri Darmet y va de son petit avis.

Commençons d’abord par examiner les deux bestioles.

 

Les Use Cases

 

D’abord un peu d’histoire : les Use Cases ont été définis par un des pères d’UP (Unified Process), donc d’UML (Unified Modeling Language) : monsieur Ivar Jacobson. Il l’a fait de manière formelle et précise :

« Un Use Case est une activité ou une série d’activités, initiées par un acteur, et qui apportent une valeur du point de vue de l’acteur. »

Première remarque : un Use Case n’est donc pas une « chose » que je détourne à ma guise et que je vais représenter par une « patate » liée à un bonhomme « fil de fer ». Pour prendre un exemple, « se connecter au système » ne peut pas être un Use Case, car il n’apporte pas de valeur du point de vue de l’acteur (vous arrive-t-il de vous connecter au système et de vous dire juste après : « Ah ! super ! Ma tâche est terminée ! »). 95% des Uses Cases que j’ai rencontrés dans les projets sur lesquels je suis intervenu… n’en étaient pas. Le Use Case est une notion aussi connue que mal comprise.

Lire la suite…

Séminaires techniques – L’agilité : innovation utile au business !

3 nouveaux séminaires techniques organisés et animés par Objet Direct, en mai et juin : « L’agilité : innovation utile au business ! » avec le retour d’expérience d’une grande banque d’investissement.

Ce séminaire se propose de vous faire découvrir concrètement le quotidien d’une équipe agile, à travers l’illustration par des projets réels réalisés pour une grande banque d’investissement. Nous aborderons dans ce séminaire les difficultés rencontrées et des solutions pour les surmonter.

=> le 31 mai à Grenoble, le 31 mai à Lyon, le 19 juin à Toulouse, 8h30-12h (accueil petit déjeuner) Evénements gratuits, sur réservation ferme. En savoir plus et s’inscrire en ligne sur le site d’Objet Direct.

Quel acteur pour un cas d’utilisation déclenché périodiquement?

Cet article traite d’une question récurrente lorsque l’on modélise un cas d’utilisation dont la particularité est son lancement automatique et périodique. En support des explications apportées, j’ai utilisé comme exemple la mise à jour quotidienne des données clients en prenant en compte les transactions effectuées depuis la dernière mise à jour, objectif du cas d’utilisation Mettre à jour les encours clients.

Pour modéliser ce cas de figure, il est courant d’utiliser l’horloge du système (timer) comme acteur primaire, celui-ci représentant le déclencheur du cas d’utilisation. Est-ce la meilleure méthode pour modéliser un cas d’utilisation déclenché périodiquement? C’est ce que cet article va tenter de clarifier par la présentation de trois approches différentes :

Approche 1 : le cadenceur est un acteur primaire

Une tache périodique étant effectuée en interne par le système, elle ne porte pas de comportement visible d’un point de vue analyse boite noire. Comme cette tache porte une fonctionnalité du système, elle fait partie du périmètre étudié.

Dans cette approche de modélisation, le cadenceur est une fonction interne que l’on sort du système (d’un point vue boite noire), et que l’on identifie comme acteur primaire basé sur le raisonnement suivant : le cadenceur déclenche le cas d’utilisation de façon périodique. Le cadenceur ne porte pas la définition d’un acteur primaire car il n’a pas d’objectif dans l’exécution du cas d’utilisation. En effet, d’un point de vue UML, un acteur primaire est un utilisateur du cas d’utilisation ayant un but visible dans son exécution. Néanmoins dans le cas où aucun évènement déclencheur (trigger) n’est défini, la première action de l’acteur primaire peut être vue comme l’évènement déclencheur (ou trigger) du cas d’utilisation, d’où la modélisation du cadenceur comme acteur primaire.

Cette approche, couramment pratiquée en UML, permet d’indiquer sans équivoque que chacun des cas d’utilisations associés à un Cadenceur décrivent une fonctionnalité déclenchée de façon cyclique par le système. Le choix du terme « cadenceur » permet de rester au niveau de l’analyse n’indiquant pas la solution pour le réaliser. Lors de la conception, il sera alors possible de répondre à la spécification fonctionnelle par exemple en utilisant une horloge système.

Approche 2 : l’acteur primaire doit avoir un objectif dans l’exécution du cas d’utilisation

Cette approche alternative consiste à utiliser un acteur primaire ayant un but visible dans l’exécution du cas d’utilisation.

Dans l’exemple de mise à jour des encours clients, l’acteur primaire est le Comptable car celui-ci a un objectif dans l’exécution du cas d’utilisation ‘Mettre à jour les encours clients’ : obtenir un état à jour des encours de chacun des comptes clients.

La particularité porte sur le fait qu’il n’y a pas d’interaction entre l’acteur primaire et le système étudié. L’évènement déclencheur (trigger) du cas d’utilisation est représenté par l’acteur secondaire « Cadenceur  » dans le souci de présenter visuellement le fonctionnement cyclique de ce cas d’utilisation – cela est optionnel mais il est recommandé de conserver le Cadenceur sur ce diagramme permettant d’indiquer cette particularité au lecteur.

Si l’on ne souhaite pas représenter l’acteur secondaire Cadenceur, il est également possible de définir un évènement déclencheur (trigger) dans le cas d’utilisation, par ex : « Le cadenceur du système déclenche ce cas d’utilisation ».

Approche 3 : aucun acteur

La dernière approche proposée consiste à n’associer aucun acteur à ce cas d’utilisation. D’un point de vue UML, cela est tout à fait correct car l’on représente un cas d’utilisation ne comportant pas d’interaction avec un acteur externe. Il est alors possible de spécifier comment le cas d’utilisation est déclenché par son trigger.

Un cas d’utilisation sans acteur risque de susciter des difficultés de compréhension et des questions.

Conclusion

J’ai personnellement toujours appliqué la première approche pour différents projets en modélisant le Cadenceur (ou utilisant une variante de ce terme selon le contexte) comme acteur primaire. J’ai trouvé l’exercice d’identification et d’évaluation des approches alternatives utile pour mieux comprendre comment l’approche retenue parait la plus appropriée.