CRUD dans un diagramme de cas d'utilisation?
Ma question est assez simple. Quelle est la meilleure façon d'introduire CRUD dans un diagramme de cas d'utilisation? Il devrait être sec . Je sais, UML est parfois discrétionnaire, mais qu'en pensez-vous?
Quelques idées:
1 diagramme de cas d'utilisation
- Pas vraiment sec, s'il y a quelques objets CRUD.
2 diagramme de cas d'utilisation
- Pas vraiment sec, s'il y a quelques objets CRUD.
3 cas d'utilisation diagramme
- , je préfère cela.
Mettre à jour
4 diagramme de cas d'utilisation (@Uffe)
- notez peut-être inutile, quand il est décrit dans la documentation?
5 diagramme de cas d'Utilisation (@home @ Uffe)
3 réponses
Parmi ceux-ci, je dirais que #3 est en fait le pire, parce que "CRUD" en soi n'est pas un cas d'utilisation du tout; vous CRUD toujours quelque chose. Ne confondez pas le cas d'utilisation <<extend>> avec l'héritage de classe.
L'Option # 2 n'est pas très bonne non plus, car parcourir un cas d'utilisation "gérer l'utilisateur" ne signifie pas que vous effectuez les quatre actions CRUD.
Si vous voulez vraiment être explicite dans vos cas d'utilisation, #1 A mon argent. Mais si c'était moi, je mettrais juste une seule utilisation "Gérer les utilisateurs" cas là.
Puisque la gestion des utilisateurs (ou autre chose) est un concept bien compris, un cas d'utilisation" Gérer les utilisateurs " est en fait assez explicite et n'a pas besoin de détailler plusieurs cas d'utilisation à moins qu'il y ait des raisons spécifiques de le faire (par exemple, si le système pour lequel vous analysez les exigences est un mécanisme Si c'est le cas, utilisez le #1.
Selon le livre "Applying UML and Patterns-Craig Larman", nous pouvons utiliser "Manage User" pour le nom du cas d'utilisation pour afficher L'opération CRUD dans le cas d'utilisation. No 4 est un bon choix et dans ce cas, nous devrions décrire les opérations CRUD dans le scénario. Créer l'utilisateur dans le flux principal des événements et les autres dans le flux alternatif des événements.
Id vote pour trois tant qu'il y a une compréhension implicite ou explicite en compagnie de ce que vous entendez exactement par CRUD (c'est-à-dire que tout le monde devrait convenir que cela signifie simplement des formulaires de base pour entrer toutes les données, si une classe a besoin d'un processus d'entrée plus complexe, elle devrait être modélisée