UMLBehaviour diagrams

Activity diagram examples

Three activity diagrams of processes you have met - a CI pipeline, support triage, and a fragment that ends two tokens differently - each drawn out with the reasoning behind every node.

August 6, 20268 min readUML 2.5.114 of 35

The short answer

A CI pipeline is the clearest example: build, then three checks in parallel behind a fork, a join that waits for all three, and a branch on the result.
Edges leaving a fork never carry guards, because every one of them is taken. Guards belong on the edges leaving a decision.
A flow final ends one token; an activity final ends everything. Using the ringed disc on a side branch silently kills the main flow.
Give the last edge out of a decision the guard [else]. Without it a token can arrive where no guard holds, and the activity stalls.

A UML activity diagram of a CI pipeline. From the initial node, build artifact. A fork bar splits into three parallel actions: run unit tests, run linters and scan dependencies. A join bar waits for all three, then a decision branches on the result: all green goes to deploy to staging and the activity final node, any failed goes right to notify author and its own final node. — A CI pipeline: one fork, three concurrent actions, a join that waits for all of them, and a decision on the result.

01Example 1: parallel work behind a fork#

A build pipeline is the clearest first example because the concurrency is real rather than notional. Unit tests, linting and a dependency scan genuinely run at once, nothing downstream can start until all three have finished, and everybody has watched it happen.

The two solid bars are doing the work. The upper one is a fork: one token arrives and three leave, so all three branches run. The lower one is a join: it waits until a token has arrived on every incoming edge before letting one continue. Swap either for a diamond and the diagram now claims something false - a diamond fires on the first token through and never waits.

Note the two separate final nodes. A failed build and a deployed build are different endings, and drawing them as two ringed discs is both legal and clearer than routing both back into one. UML puts no limit on how many activity final nodes an activity has.

02Example 2: a three-way branch with exhaustive guards#

Most business processes are not concurrent. They are a decision with several outcomes that later come back together, which is the shape below.

Three things in this diagram are deliberate. The guards are exhaustive: [sev 1], [sev 2 or 3] and [else] between them cover every ticket, so no token can arrive at the diamond and find nowhere to go. A token with no enabled outgoing edge is a stalled process, and it is a defect worth catching on paper.

The lower diamond is a merge, not a join, and the difference matters: only one of the three paths ever carries a token, so waiting for all three would deadlock immediately. The rule is easy to hold - a diamond opens what a diamond closes, and a bar closes what a bar opened.

Finally, every action is a verb phrase in the imperative: “Page on-call”, not “On-call paging”. Nouns creep in when somebody is describing a system rather than a process, and a diagram of nouns is a class diagram that has taken the wrong shape.

03Example 3: the two ways a flow can end#

The pair of ending nodes is the detail most first diagrams get wrong, and the mistake is invisible: the diagram still looks right.

A UML activity diagram fragment contrasting the two ending nodes. A fork splits into two branches: write audit entry ends at a flow final node drawn as a crossed circle, and confirm to customer ends at an activity final node drawn as a ringed disc. A note explains that the crossed circle ends only its own token while the ringed disc ends the whole activity.

After the fork, two tokens are in flight. The audit branch reaches a flow final - the circle with a cross - which consumes that token and nothing else. The customer branch reaches an activity final, the ringed disc, which ends the whole activity and abandons every other token in it.

Put the ringed disc on the audit branch instead, and the diagram now says the order is abandoned as soon as the log line is written. Nothing about it looks wrong, which is exactly why the distinction is worth learning once: use a flow final for a side branch that simply finishes, and an activity final only where you mean “we are done”.

04Turning these into your own#

These three cover the shapes almost every activity diagram is made of. What changes between them and yours is the labels; what should not change is the discipline about scope.

Reach for it when

One process per diagram, with a name you could put in an email subject line.
Verb-phrase actions, so each box is something somebody or something does.
Swimlanes when the handoffs between roles are the point - lane crossings are where processes fail.
A guard of [else] on the last edge out of every decision, so the set is exhaustive.

Reach for something else when

More than about fifteen actions. Extract a subtree as its own activity instead.
A bar where alternatives rejoin, or a diamond where concurrent work does.
Error handling for every step. Draw the happy path, then one diagram for the failure that matters.
Modelling a single object's lifecycle - that is a state machine, not an activity.

If the audience is business analysts rather than engineers, the same process is usually better drawn in BPMN, which has richer event semantics and is what a process engine will execute. The two notations answer the same question for different rooms.

05What to remember#

In one line each

01A bar forks and joins; a diamond branches and merges. A diamond never waits, and a bar always does.
02Guards belong on edges out of a decision and never on edges out of a fork.
03Make the guard set exhaustive - [else] on the last edge - or the process can stall.
04A flow final ends one token; an activity final ends everything. The wrong one looks identical.
05Actions are verb phrases. If the boxes are nouns, you are drawing the wrong diagram.

06Common questions#

What is a good example of an activity diagram?

A CI pipeline is the clearest one: build the artifact, then run tests, linters and a dependency scan in parallel behind a fork, wait for all three at a join, and branch on the result. It uses every node kind that matters in about ten boxes.

How do you draw parallel steps in an activity diagram?

Put a solid bar - a fork - across the flow and take one edge from it into each concurrent action. Close the group with a second bar, the join, which waits for a token on every incoming edge before the flow continues. Guards never appear on the edges leaving a fork, because every one of them is taken.

What is the difference between a flow final and an activity final node?

A flow final, a circle with a cross, ends the token that reaches it and leaves the rest of the activity running. An activity final, a ringed disc, ends the entire activity and abandons every other token. Using the ringed disc for a side branch silently kills the main flow.

Do the guards leaving a decision have to cover every case?

Yes. If no guard holds, the token has nowhere to go and the activity stalls, which is a real defect rather than a drawing nicety. The safe habit is to give the last edge the guard [else], which makes the set exhaustive by construction.

How many actions should one activity diagram have?

Roughly fifteen before it stops being readable. Past that, take a subtree out as its own activity and reference it as a single call action. A diagram that needs to be zoomed is a diagram nobody checks against reality.

ShareX LinkedIn

↑ Back to top All UML articles →

In this series