UML Mise en œuvre du postcondition du diagramme de cas d'utilisation (avec diagramme)

Question

J'apprends le langage UML en essayant de simuler le fonctionnement d'un garage de service automobile avec des diagrammes et de la documentation. Un de mes problèmes concerne les instructions postconditionnées (ou plutôt GOTO).

Est-ce que la ligne en pointillés < < inclut >> relation uniquement pour les conditions préalables? Les bulles de cas d'utilisation peuvent-elles se connecter entre elles et suivre un chemin logique?

Donc, c'est ce que j'ai jusqu'ici .. 1) Le «paiement de règlement» est-il au mauvais endroit? Devrait-il être inclus dans les autres bulles? 2) Dois-je associer les bulles de «demande de service» au technicien, car c'est lui qui va réparer la voiture?

image

Answer 1

cas d'utilisation sont comme des classes. Ils ont l'héritage (étend) et les relations comme inclus et utilisations.

Les conditions préalables sont des contraintes de relation communes. Certains d'entre nous écrivent les conditions préalables et postconditions dans le texte du cas d'utilisation. Vous pouvez le dessiner, mais ce n'est pas obligatoire. N'essayez pas de séquencer les bulles du cas d'utilisation. C'est ce que sont les diagrammes d'activité et les diagrammes de séquence. C'est à ça que sert le texte narratif. C'est quelque chose que les utilisateurs connaissent déjà. En outre, ne perdez pas beaucoup de temps à traiter les cas d'utilisation comme un langage de programmation de très haut niveau. Rappelez-vous, les acteurs savent déjà ce qu'ils font; ils n'ont pas besoin d'aide pour séquencer les choses.

Vous devez vous concentrer sur la capture des acteurs, les cas d'utilisation, et de base "étend", "utilise", "inclut" parmi les cas d'utilisation. Les modèles de cas d'utilisation ne sont pas programmés. Le diagramme de cas d'utilisation est la capture des connaissances de "qui" et de "quoi". Pensez-y plutôt comme un modèle de sécurité qui définit ce que les acteurs peuvent faire. L'ordre, la séquence et d'autres détails importent moins que ce que font les acteurs.

Lorsque vous avez associé un acteur à un acteur (comme Technicien et Réception), vous dites que les acteurs interagissent en dehors du système. Vous dites que la technologie ne se connecte jamais au système pour obtenir leur travail ou enregistrer leur temps.

Si le technicien se connecte réellement pour obtenir du travail et enregistrer le temps, le technicien participe à certains cas d'utilisation.

Les cas d'utilisation ne sont pas programmés. Ce sont des choses que les acteurs font. Les cas d'utilisation sont liés en raison de la construction d'un grand logiciel commun. Vous n'avez pas besoin de dessiner un flot de données ou des flèches logiques parmi les cas d'utilisation. Ils peuvent tous être largement indépendants. Lorsque vous concevez le système, vous implémentez des fonctionnalités de l'interface utilisateur et des fonctionnalités de base de données qui connectent les cas d'utilisation dans un ordre donné.