Nécessité d'inclure la trace d'audit et la consignation des erreurs dans mon diagramme de cas d'utilisation

Question

Notre équipe de support d'application suggère d'implémenter une piste d'audit, une journalisation des erreurs étendue et un nouveau traitement par lots pour traiter certaines données en interne. Avant d'implémenter ceci, je veux faire des changements dans mon diagramme de cas d'utilisation. Je pense que piste d'audit doit être un cas d'utilisation, mais pas sûr de la journalisation des erreurs. Devrait-il être considéré comme un cas d'utilisation. Ce lien http://www.umlchannel.com/en/uml/item/24-use-case-actor-system-timer dit qu'un cas d'utilisation peut parfois avoir aucun acteur. Pouvons-nous considérer la journalisation des erreurs comme un cas d'utilisation sans acteur? Puis-je considérer un travail par lots comme un cas d'utilisation où le planificateur de lots est un acteur?

Une autre clarification dont j'ai besoin est: Je sais que l'acteur peut être une personne ou un autre système. Peut-on considérer un événement (qui interagit avec une solution par le biais d'un cas d'utilisation) comme un acteur?

Answer 1

Un cas d'utilisation doit avoir un acteur, car fondamentalement, il décrit juste la valeur ajoutée pour son acteur. L'auteur de l'article référencé est simplement faux ici.

P. 637 des UML 2.5 caractéristiques:

Chaque UseCase spécifie un comportement qu'un sujet peut effectuer en collaboration avec un ou plusieurs acteurs.

...

Un sujet d'un UseCase pourrait être un système ou tout autre élément qui peut avoir un comportement, comme un composant ou une classe. Chaque UseCase spécifie une unité de fonctionnalité utile que le sujet fournit à ses utilisateurs

NB: Bien que l'UML soit la "vraie source", ce n'est pas une bonne lecture sur les cas d'utilisation. Au lieu de cela, je recommande fortement Bittner/Spence.

Il existe plusieurs façons d'utiliser le "cas d'utilisation" Log error. On serait à <extend> des cas d'utilisation avec Log error. Mais en fait, il y a quelques inconvénients avec cela. Log error peut donner une valeur supplémentaire à long terme (améliorations du système et corrections de bogues), mais ce n'est pas une valeur ajoutée a priori. En outre, vous feriez juste encombrer vos diagrammes de cas d'utilisation.

Une deuxième façon est de changer la perspective et d'inclure le "système" lui-même en tant qu'acteur. Mais c'est un anti-pattern. Donc non recommandé aussi bien. Enfin, vous pouvez simplement ajouter une exigence non-fonctionnelle à votre système et suivre simplement les cas d'utilisation pertinents. C'est ce que je recommanderais de faire.

Vos questions supplémentaires:

• Un traitement par lots est pas cas d'utilisation, mais un cas d'utilisation peut être mis en œuvre en tant que traitement par lots et le planificateur peut être l'acteur.
• Non, un événement est un événement et non un acteur. Un événement peut déclencher une chaîne d'actions faisant partie d'un cas d'utilisation.