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.

3 réflexions au sujet de « Quel acteur pour un cas d’utilisation déclenché périodiquement? »

  • 8 juin 2011 à 6 h 39 min
    Permalink

    Merci Guillaume pour cette analyse très intéressante.

    Pour ma part, j’aime bien l’option 2 qui met en avant le besoin (le but de l’acteur).

    • Je trouve qu’elle facilite le dialogue avec les utilisateurs qui peuvent s’identifier, se projeter comme un comptable, rôle concret de l’entreprise.
    • Il me semble que c’est d’autant plus important si l’on doit définir des priorités avec les utilisateurs. obtenir un état à jour des encours de chacun des comptes clients me semble plus accessible à l’utilisateur que Mettre à jour les encours clients

    En poussant mon raisonnement à l’extrême, je me pose plusieurs questions : est-ce que le cadenceur doit apparaitre au niveau du use case ou est-ce un choix de conception ? Apparaitrait-il si la consolidation était instantanée ?

    A mon sens, le cadenceur permet d’identifier les traitements a priori longs, qui vont probablement avoir des conséquences sur l’architecture. Cette identification dans les phases amont du projet est très importante. Est-ce qu’un stéréotype « traitement long » pourrait suffire ?

  • 8 juin 2011 à 8 h 20 min
    Permalink

    @Jean-Francois SUBLET
    Les 3 approches proposées dans l’article sont valables, aussi il est tout à fait possible d’appliquer la 2ème approche s’il est important pour client de voir l’objectif pour un rôle (ex comptable) tenu par un utilisateur.
    Pour répondre à tes questions :
    – est-ce que le cadenceur doit apparaitre au niveau du use case ou est-ce un choix de conception ?
    le cadenceur est un choix d’analyse et non de conception : il est utilisé afin d’indiquer que la fonctionnalité décrite pas ce use case est déclenchée automatiquement par le système (et il est éventuellement possible d’indiquer la périodicité demandée selon les exigences du client, par ex tous le jours à 23h, afin d’alimenter les décisions de conception).
    – Apparaitrait-il si la consolidation était instantanée ?
    Oui, le cadenceur indique juste le déclenchement du use case, il ne dépend par de la durée d’exécution du use case (traitement instantané ou long)

  • 21 juin 2011 à 10 h 21 min
    Permalink

    Merci Guillaume d’avoir bien posé le problème.

    Pour ma part, j’utilise plutôt la deuxième approche qui permet de satisfaire un des objectifs principaux de la modélisation avec les cas d’utilisations : « identifier la valeur ajoutée métier (mesurable) du système pour un Acteur ».

    Comme je ne pense pas que le système modélisé apporte de la valeur à l’acteur « Cadenceur » 😉 je m’astreint à trouver l’acteur à qui le système apporte de la valeur même si ça nest pas lui qui produit l’événement déclencheur du cas d’utilisation.

    Et le caractère périodique àapparaît dans la description textuelle du use case : « Ce cas d’utilisation commence tous les lundi matin à 7h… » ou « Ce cas d’utilisation démarre tous les premiers lundi du mois… ».

    MTC

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *