Je dois inclure la piste d'audit et la journalisation des erreurs dans mon diagramme de cas d'utilisation.

Question

Notre équipe de soutien aux applications suggère de mettre en place une piste d'audit, une journalisation étendue des erreurs et un nouveau travail par lot pour traiter certaines données en interne. Avant de mettre en œuvre cette solution, je souhaite apporter des modifications à mon diagramme de cas d'utilisation. Je pense que l'audit trail doit être un cas d'utilisation mais je ne suis pas sûr de la journalisation des erreurs. Doit-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 n'avoir AUCUN acteur. Peut-on considérer l'enregistrement des erreurs comme un cas d'utilisation sans acteur ? Puis-je considérer un travail par lot comme un cas d'utilisation où le planificateur de lot 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 à travers un cas d'utilisation) comme un acteur ?

Answer 1

Un cas d'utilisation doit ont un acteur, puisque fondamentalement, il ne fait que décrire la valeur ajoutée pour son acteur. L'auteur de l'article référencé a tout simplement tort ici.

P. 637 des spécifications UML 2.5 :

Chaque UseCase spécifie un comportement qu'un sujet peut exécuter en collaboration avec un ou plusieurs Acteurs.

...

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

N.B. : Bien que l'UML soit la "vraie source", ce n'est pas une bonne lecture pour les cas d'utilisation. Je recommande plutôt vivement Bittner/Spence.

Il existe plusieurs façons d'aborder la Log error "cas d'utilisation". L'un d'eux serait de <extend> cas d'utilisation avec Log error . Mais en fait, il y a quelques inconvénients à cela. Log error peut apporter une valeur ajoutée à long terme (améliorations du système et corrections de bogues), mais il ne s'agit pas d'une valeur ajoutée a-priori. De plus, vous ne feriez qu'encombrer vos diagrammes de cas d'utilisation.

Une deuxième solution consiste à changer de perspective et à inclure le "système" lui-même en tant qu'acteur. Mais c'est un anti-modèle. Il n'est donc pas non plus recommandé.

Enfin, vous pouvez simplement ajouter une exigence non fonctionnelle à votre système et remonter jusqu'aux cas d'utilisation qui sont pertinents. C'est ce que je vous recommande de faire.

Vos questions supplémentaires :

• Un travail par lot n'est pas un cas d'utilisation, mais un cas d'utilisation peut être mis en œuvre comme un travail par lot 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.