1.5.10 Representing Nested Decisions in Activity Diagrams

Activity Diagrams Can Show a Decision Inside a Decision Path

Consider:

if (player1.isAvailable)
{
    if (player1.position == "Goalkeeper")
    {
        System.Console.WriteLine("Goalkeeper is available.");
    }
}

The second decision exists only inside the true path of the first decision.

An activity diagram should preserve that relationship.

Begin with the Outer Decision

The first decision can be stated as:

Is the player available?

Its true path leads toward the inner decision.

Its false path bypasses the inner decision.

Place the Inner Decision on the Correct Path

The inner decision can be stated as:

Is the player's position "Goalkeeper"?

Conceptually:

Start
  ↓
Is the player available?
     ◇
   /   \
[true] [false]
  |       |
  v       |
Is the player a goalkeeper?
     ◇    |
   /   \  |
[true] [false]
  |       |
  v       |
Display   |
message   |
   \      /
    \    /
   Continue
      ↓
     End

The exact layout can vary, but the meaning should not.

The False Outer Path Must Bypass the Inner Decision

If:

player1.isAvailable = false

the program does not evaluate the goalkeeper condition.

The activity diagram should show that the false path skips the inner decision entirely.

Do Not Draw the Decisions as Independent

This is misleading:

        Start
       /     \
available?  goalkeeper?

That suggests both questions can be reached independently.

The source does not behave that way.

The second decision is conditional on the first path.

Do Not Model the Structure as an else if Chain

For an else if chain, the next decision is reached from the false path of the earlier decision.

For this nested example, the next decision is reached from the true path.

That difference is the central visual feature.

Use Plain-Language Decision Questions

A readable activity diagram can use:

Is the player available?

and:

Is the player a goalkeeper?

The diagram should communicate the behavioral question rather than reproduce every C# symbol.

Label Each Branch Clearly

Use true/false labels so the reader can tell which path belongs to which decision.

With multiple decision nodes, branch labels must be interpreted relative to the decision they leave.

Trace Several Runtime States

Available goalkeeper

outer true
inner true
message runs

Available forward

outer true
inner false
message skipped

Unavailable goalkeeper

outer false
inner decision not reached
message skipped

If the diagram supports all three traces correctly, it represents the nested behavior.

Rejoin the Common Flow

If execution continues after the nested structure, the diagram should show the relevant paths reconnecting to that shared continuation.