J'ai actuellement un Use Case Diagram qui est similaire à la précédente :
Dans ma candidature finale, je partagerai probablement les mêmes Login pour les deux Employees y Employers . Dois-je en tenir compte dans cette Use Case Diagram ayant à la fois Actors en utilisant le même Login Use Case ? Si oui, comment puis-je représenter ce que chacun d'entre eux peut faire après avoir effectué les tâches suivantes ? Login ?
Il est très probable qu'il y ait d'autres cas d'utilisation partagée ? L'utilisateur "abstrait" est donc logique, bien que je ne pense pas qu'il doive être "abstrait", il peut être un acteur à part entière ?
Quel que soit le style que vous préférez, l'objectif de la modélisation est d'abstraire l'information. Si le cas d'utilisation de la connexion est très important au point de devoir figurer dans le diagramme, ce diagramme ne me dit rien de spécial à ce sujet. Ce diagramme me dit que, dans ce système, le cas d'utilisation de la connexion précède tous les autres cas d'utilisation ? Duh ? Tout système aura un cas d'utilisation de connexion, donc pour la plupart des systèmes, il ne sera pas (architecturalement/très) significatif. Si le cas d'utilisation est spécial pour une raison quelconque, je mettrais le diagramme sans relations, cela suffit je pense. Le diagramme communiquera : nous avons un cas d'utilisation de connexion spécial, nous voulons que vous en preniez note. Le système a-t-il des cas d'utilisation anonymes ? Des cas d'utilisation qui peuvent être exécutés sans le cas d'utilisation de connexion ? C'est important et cela mérite des éléments de modèle. Dans le cas contraire, il s'agit d'un élément implicite, selon l'IMHO.
Si votre modélisation doit faire plus que permettre la compréhension et la communication, par exemple si elle doit conduire à la génération de code, c'est bien sûr différent. Mais vous pouvez alors, en fonction de votre environnement de modélisation, l'intégrer au modèle mais pas au diagramme. De cette façon, il peut faire les deux : piloter la génération de code et permettre la compréhension et la communication.
La proposition de @CesarGon est une bonne solution. Une autre alternative - pas nécessairement meilleure, juste différente - est d'avoir les deux Employee & Employer Cas d'utilisation <<include>> el login UC.
Le choix dépend du style et des préférences de chacun. L'approche de l'utilisateur abstrait est plus propre et plus déclarative (vous devez spécifier la connexion comme condition préalable à d'autres UC). L'approche <<includes>> correspond peut-être mieux à un état d'esprit de modélisation impérative/processus puisque chaque UC montrera explicitement l'appel à la connexion en tant que première étape.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
