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 / planifié. 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.