Un planificateur doit-il être un acteur dans un diagramme de cas d'utilisation

Question

Supposons qu'un planificateur qui fait partie du système soit responsable de l'envoi de courriels hebdomadaires aux utilisateurs. Le «planificateur» devrait-il être traité comme un acteur ou devrait-il être modélisé comme un cas d'utilisation?

Lignes directrices pour choisir les acteurs disent: Si: c'est une personne réelle interagissant avec votre système. Si "Oui" est un acteur Sinon: Est-ce quelque chose que vous pouvez changer dans le système? Si "Non" est un acteur

Le planificateur n'est pas une personne. Et vous pouvez changer comment cela fonctionne. Mais mon instinct dit que cela peut être un acteur. Un peu d'aide serait génial.

Answer 1

La directive de niveau supérieur dit: Si cela vous aide à comprendre la conception, incluez-la dans le diagramme. Si cela n'introduit que du bruit inutile, laissez-le.

Également, une ligne directrice de niveau supérieur: Utilisez le sens commun.

Answer 2

Je modélise souvent des planificateurs et d'autres agents externes liés au temps en tant qu'acteurs. C'est logique, c'est compréhensible, cela ne contredit rien au sein d'UML ou de la pratique courante de la modélisation OO, et cela correspond bien à la plupart des stratégies de mise en œuvre.

Answer 3

@CesarGon Il se peut que vous utilisiez un cas d'utilisation (diagrammes) comme technique de conception plutôt que comme technique. Au fur et à mesure que la technique des exigences se concentrerait sur les objectifs de l'utilisateur, le système et les acteurs interagiraient avec le système. TIME L'acteur n'a pas de but utilisateur contre le système donc j'essaye de trouver l'acteur qui a un but ou un intérêt contre le système. Qui se soucie quand l'email hebdomadaire n'est pas envoyé? TIME acteur que j'ajoute comme acteur secondaire. TIME acteur aide un acteur «réel» à atteindre l'objectif de l'utilisateur.