# How do I represent nested actions in a UML activity diagram?

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.

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):

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.

## migrated from stackoverflow.comSep 21 '16 at 19:44

This question came from our site for professional and enthusiast programmers.

• 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
• 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
• 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
• @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
• 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

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.

• 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
• It's no bed-time lecture :-) I'll try to add some more explanation. – qwerty_so Sep 19 '16 at 12:24
• I made an update with a remark on another EAUI. – qwerty_so Sep 19 '16 at 12:40