Comment représenter des actions imbriquées dans un diagramme d'activité UML?

16

Cette question est très similaire à celle-ci , mais la réponse ne correspond pas à mes besoins. Il se concentre sur un outil UML spécifique (Papyrus) alors que ma question est plus générale sur UML.

Je voudrais représenter une action imbriquée dans un diagramme d'activité , mais je ne sais pas quelle est la manière la plus courante de le faire. L'idée est qu'il existe une action de même envergure que les autres actions, mais plus complexe dans son exécution. Je voudrais montrer plus de détails sur son exécution tout en étant capable de montrer cette action au même niveau que les autres.

Dans l'exemple ci-dessous, qui est un diagramme d'activité montrant une sorte d'activité " à la maison ", les actions imbriquées sont dans l' Pet the cataction. Notez qu'il y a une autre erreur potentielle dans ce diagramme, voir les errata à la fin de la question.

Enfin de retour à la maison

J'ai utilisé le nœud structuré, mais je ne suis pas sûr que ce soit la bonne façon, d'où la question. Dans un organigramme, l'équivalent serait un état composite, mais je ne trouve rien sur une action composite. Concernant le nœud structuré, après avoir lu quelques documents à ce sujet, je ne comprends toujours pas vraiment comment il est censé être utilisé, donc je peux me tromper totalement avec ce diagramme.

Je sais également qu'il y a la possibilité de se référer à une autre sous-activité avec le symbole trident, comme dans l'image ci-dessous, mais cela ne correspond pas à mes besoins car je voudrais toutes les informations sur le même diagramme (donc je peux imprimer sans aucune perte d'information):

Sous-activité Trident

Alors, quelle est la manière standard de représenter une telle action imbriquée? Par standard, je veux dire UML valide, communément vu et si possible réalisable sur la plupart des outils de conception UML.

Errata sans rapport: une autre chose ne va pas dans mes diagrammes, les flèches qui viennent à la même action ( Scratch behind the ears) doivent aller à un nœud fusionnant avant d'entrer dans l'action. Voir les commentaires ci-dessous, y compris cette citation de JOT .

Tim
la source
Vous n'avez pas posé de question à ce sujet, mais je tiens à souligner que l'action "Grattez derrière les oreilles" ne peut jamais s'exécuter. Est-ce que quelqu'un sait pourquoi c'est vrai?
Jim L.
Bon je ne sais pas mais j'espère que c'est juste le tempérament du chat, car le schéma que j'ai finalement donné à mon patron ressemble à celui-ci: /
Tim
La raison en est qu'un jeton des deux chemins doit être offert à l'action pour qu'elle démarre, ce qui est impossible, car on vient d'un autre qui n'arrivera jamais.
Jim L.
@ JimL. Voulez-vous dire que les deux conditions doivent être remplies pour entrer dans cet état? Quelle serait alors la manière d'exprimer ce que j'ai l'intention d'exprimer? Un nœud de diamant fusionné avant l'entrée de l'État?
Tim
Nous parlons d'une action, pas d'un État; mais oui, une fusion est nécessaire pour résoudre ce problème.
Jim L.

Réponses:

23

Les deux sont "standard". La première image selon les spécifications UML est

Nœuds d'activité structurés

Un StructuredActivityNode est une Action qui est également un ActivityGroup (voir le paragraphe 15.6) et dont le comportement est spécifié par les ActivityNodes et ActivityEdges qu'il contient. Contrairement à d'autres types d'ActivityGroup, un StructuredActivityNode possède les ActivityNodes et ActivityEdges qu'il contient, de sorte qu'un nœud ou un bord ne peut être directement contenu que dans un StructuredActivityNode. Les StructuredActivityNodes peuvent être imbriqués (comme un StructuredActivityNode, comme une Action, est également un ActivityNode), donc un bord ou un nœud peut être indirectement contenu dans un certain nombre de StructuredActivityNodes imbriqués.

Groupes d'activités

ActivityGoups sont des constructions de regroupement pour ActivityNodes et ActivityEdges. Les nœuds et les arêtes peuvent appartenir à plusieurs groupes. Cette sous-clause décrit deux types concrets de ActivityGroups, ActivityPartitions et InterruptibleActivityRegions. Les StructuredActivityNodes sont un troisième type de ActivityGroup, mais ils sont également des Actions et sont discutés dans le paragraphe 16.11 de l'Article 16 sur les Actions.

La 2ème photo est

Actions d'invocation

Une InvocationAction est une Action qui entraîne, directement ou indirectement, l'invocation d'un Comportement (voir le sous-paragraphe 13.2). Les InvocationActions incluent les CallActions pour appeler des opérations ou des comportements et pour démarrer des comportements qui ont été précédemment instanciés. Des types supplémentaires d'actions d'invocation permettent l'envoi ciblé de signaux et d'autres objets et la possibilité de diffuser des signaux aux récepteurs disponibles.

La principale différence entre les deux cas est la réutilisation. Alors qu'en premier lieu, vous avez juste une certaine complexité à un seul endroit (votre Pet the cat) le second est lorsque vous (ré) utilisez une certaine action à plusieurs endroits. Cependant, j'ai tendance à utiliser la variante d'invocation même si ce n'est que pour une seule utilisation. Ici, j'ajoute un diagramme composite (qui dans EA s'ouvre sur dbl-click) pour montrer les détails de l'action correspondante. Le flux principal montre simplement l'aperçu et si des détails sont nécessaires, ils ne sont qu'à un clic.

Maintenant, la création d'un diagramme composite dans EA est (encore) différente. Vous devez créer un AD au niveau du package, puis le faire glisser dans l'élément d'invocation. Maintenant, lorsque vous cliquez deux fois dessus, le diagramme incorporé s'ouvre.

qwerty_so
la source
Merci pour votre réponse. Pourriez-vous donner plus de détails sur le moment où vous utilisez quelle possibilité? Je trouve la spécification UML assez difficile à lire, côté utilisateur.
Tim
Ce n'est pas une conférence au coucher :-) Je vais essayer d'ajouter quelques explications.
qwerty_so
J'ai fait une mise à jour avec une remarque sur un autre EAUI.
qwerty_so