17

This question is very similar to this one, but the answer doesn't match my needs. It's focused on a specific UML tool (Papyrus) whereas my question is more general about UML.

I would like to represent a nested action in an activity diagram, but I don't know what is the common way to do it. The idea is that there is an action of the same scope than the other actions, but more complex in its execution. I would like to show more details about its execution while still being able to show this action at the same level than the others.

On the example below, which is an activity diagram showing some kind of "back home" activity, the nested actions are in the Pet the cat action. Note that there's another potential error in this diagram, see the errata at the end of the question.

Finally back home

I have used the structured node, but I'm not sure it's the correct way, hence the question. In a statechart the equivalent would be a composite state, but I just can't find anything about a composite action. Concerning the structured node, after reading a few documents about it I still don't really get how it's supposed to be used, so I might be totally wrong with this diagram.

I also know that there is the possibility to refer to another sub-activity with the trident symbol, as in the image below, but it doesn't match my needs since I would like the whole information on the same diagram (so I can print it without any loss of information):

Trident sub-activity

So what is the standard way to represent such a nested action? By standard, I mean valid UML, commonly seen and if possible doable on most of the UML design tools.

Unrelated errata : Another thing is wrong in my diagrams, the arrows that come to the same action (Scratch behind the ears) should go to a merging node before to enter the action. See the comments below, including this quote of JOT.

Community
  • 1
Tim
  • 433
  • 6
  • 14
  • You didn't ask about this, but I want to point out that the action "Scratch behind the ears" can never execute. Does anyone know why this is true? – Jim L. Sep 19 '16 at 15:19
  • @TimF, that is not the one I meant. There is a 5-part series that any user of activity diagrams really should read before starting: https://www.google.com/search?q=conrad+bock+JOT+activity&ie=utf-8&oe=utf-8#q=conrad+bock+JOT+UML+2+Activity+and+Action+Models – Jim L. Sep 20 '16 at 14:23
  • We are talking about an action, not a state; but yes, a merge is required to fix this problem. – Jim L. Sep 19 '16 at 19:02
  • The reason is that a token from both paths must be offered to the action for it to start, which is impossible, as one comes from an else that will never happen. – Jim L. Sep 19 '16 at 16:16
  • @PeterMortensen when referring other sites, it is often helpful to point that [cross-posting is frowned upon](http://meta.stackexchange.com/tags/cross-posting/info) – gnat Sep 19 '16 at 19:12
  • @PeterMortensen: the difference between analysts, architects, designers, software engineers, and programmers is a touchy subject. If one is asking a UML question that is particular to OO programming (e.g., what is called "round tripping"), the site for programmers may indeed be more appropriate. The question here is seems more relevant to analysis, though. – Jim L. Sep 19 '16 at 22:13
  • @PeterMortensen To be honest I wasn't aware of the distinction between SO and *Programmers* until now, when I've looked for it. You're right, it would've been more appropriate, JimL, thanks, I'll fix that then. It's impressive the number of things one can learn here on SE. – Tim Sep 19 '16 at 19:06
  • I guess what @JimL. is talking about is in [JOT Vol 13, no 2. 2014, page 12](http://www.jot.fm/issues/issue_2014_06/article1.pdf) : `Multiple control flows into the same UML action cause the action to be executed once, after all actions on the other ends of the control flows are finished, as if a join were used.` – Tim Sep 20 '16 at 07:06
  • Well I don't know but I hope it's just the cat's temper, because the diagram I finally gave to my boss looks like this one :/ – Tim Sep 19 '16 at 15:24
  • @JimL.Do you mean that both conditions must be true to enter this state ? Then what would be the way to express what I intend to express ? A merging diamond node before the state entrance ? – Tim Sep 19 '16 at 18:50
  • @JimL. Probably you are right with the merge, but "human logic" solves this in almost all cases. Only if a machine is going to read that flow it might get hick-ups. Do you by any chance have a reference where the need for a merge is stated? I could not find one except for what Merge does. What you impose is that an Action behaves like a Fork/Join. –  Sep 19 '16 at 22:03
  • @JimL. I was not promoting sloppiness. I have opened a follow-up question here: http://stackoverflow.com/questions/39592326/sloppiness-in-activity-diagrams Tim: you are probably right. However, that paper is about BPMN which is based on UML, but a different dialect. –  Sep 20 '16 at 11:01
  • @ThomasKilian Yes it seems so and I don't know BPML, but this quote is cleary for UML. This part of the document compares BPML and UML. – Tim Sep 20 '16 at 11:04
  • @ThomasKilian: ignoring the UML token semantics doesn't do anyone any favors. UML diagrams are meant to communicate clearly. Relying on "human logic" (or what I would call "human intuition") creates a situation where someone who understands the UML token semantics cannot tell if a diagram is sloppy or modeled as intended. That does not foster clear communication, it leads to confusion. The token semantics are defined in UML 2.5, but are most plainly described by Conrad Bock in his series in the Journal of Object Technology, and most precisely defined in fUML. – Jim L. Sep 19 '16 at 22:20

1 Answers1

24

Both are "standard". The first picture as per UML specs is

Structured Activity Nodes

A StructuredActivityNode is an Action that is also an ActivityGroup (see sub clause 15.6) and whose behavior is specified by the ActivityNodes and ActivityEdges it so contains. Unlike other kinds of ActivityGroup, a StructuredActivityNode owns the ActivityNodes and ActivityEdges it contains, and so a node or edge can only be directly contained in one StructuredActivityNode. StructuredActivityNodes may be nested (as a StructuredActivityNode, as an Action, is also an ActivityNode), however, so an edge or node may be indirectly contained in a number of nested StructuredActivityNodes.

Activity Groups

ActivityGoups are a grouping constructs for ActivityNodes and ActivityEdges. Nodes and edges can belong to more than one group. This sub clause describes two concrete kinds of ActivityGroups, ActivityPartitions and InterruptibleActivityRegions. StructuredActivityNodes are a third kind of ActivityGroup, but they are also Actions and are discussed in sub clause 16.11 of Clause 16 on Actions.

The 2nd picture is

Invocation Actions

An InvocationAction is an Action that results, directly or indirectly, in the invocation of a Behavior (see sub clause 13.2). InvocationActions include the CallActions for calling Operations or Behaviors and for starting Behaviors that have been previously instantiated. Additional kinds of InvocationActions allow for the targeted sending of signals and other objects and the ability for broadcasting signals to available receivers.

The main difference between both cases is re-use. While in the first place you just have some complexity at a single place (your Pet the cat) the second one is when you (re-)use a certain action at multiple places. However, I tend to use the invocation variant even if it's only for a single use. Here I add a composite diagram (which in EA opens on dbl-click) to show details of the according action. The main flow just shows the overview and if details are needed, they are just a dbl-click away.

Now, creating a composite diagram in EA is (again) different. You need to create an AD on package level and then drag this into the invocation element. Now, when you dbl-click that, the embedded diagram will open.

Community
  • 1
  • 1
    Thank you for your answer. Could you give more details on when you use which possibility ? I find the UML spec quite hard to read, user-side. – Tim Sep 19 '16 at 12:08
  • I made an update with a remark on another EAUI. –  Sep 19 '16 at 12:40
  • It's no bed-time lecture :-) I'll try to add some more explanation. –  Sep 19 '16 at 12:24