Archyno
UMLBehaviour diagrams

UML activity diagrams

A process drawn precisely: the steps, the branches, and the parts that genuinely happen at the same time. The closest thing UML has to a flowchart, with the ambiguity taken out.

9 min readUML 2.5.15 of 15

[over limit][else]Receive refund requestEscalate to managerforkCredit customerNotify merchantjoinClose request
A refund process. The diamond chooses one path; the solid bars split into two paths that run at the same time and then wait for each other.

01What it shows

An activity diagram describes a process as a flow of work. It looks like a flowchart, and for the simple cases it is one. What it adds - and the reason it is worth using instead of a shape library - is precision about two things flowcharts are vague about: concurrency and synchronisation.

The model underneath is token flow. A token starts at the initial node and moves along the arrows. An action runs when a token arrives; when it finishes, the token moves on. A fork turns one token into several. A join waits until it has one on every incoming edge. That single mental model explains every symbol on the diagram, and it is worth holding onto because it makes the awkward cases obvious.

02The nodes

ElementNotationWhat it means
Initial nodefilled discWhere the flow starts. One per activity, normally.
Actionrounded rectangleA step of work, named verb-first. It runs to completion once a token arrives.
Decisiondiamond, one edge inChooses one outgoing edge by its guard. Guards go in square brackets; [else] catches the rest.
Mergediamond, one edge outBrings alternative paths back together. It does not wait - the first token through carries on.
Forksolid bar, one edge inSplits into paths that all run concurrently.
Joinsolid bar, one edge outWaits for every incoming path, then continues. This is the synchronisation point.
Activity finalring around a discEnds the whole activity, killing any tokens still in flight.
Flow finalcircle with a crossEnds this one path only. The rest of the activity carries on.

03Decision is not fork

This is the distinction the notation exists for, and the one that gets muddled. A decision is a choice: one token in, one token out, along whichever branch the guard selects. A fork is a split: one token in, several tokens out, all of them live at once.

Decision: exactly one branch runs.Guards must be exhaustive.Fork: both branches run.A join downstream waits for both.[ok][else]ApproveDeclineCredit customerNotify merchant
Left: a diamond, and exactly one branch runs. Right: a bar, and both branches run. Swapping them changes the meaning of the process entirely.

Their partners follow the same rule. A merge (diamond) does not wait - it is just where alternative paths rejoin. A join (bar) does wait, for all of them. Using a merge where you meant a join is how a diagram ends up claiming a process continues before its parallel work has finished.

04Swimlanes

An activity partition - almost always called a swimlane - divides the canvas into bands and puts each action in the band of whoever performs it. Lanes can be vertical or horizontal, and they can nest.

Swimlanes are the single most valuable addition to a business-process diagram, because the interesting problems in a process are usually the handoffs. When an arrow crosses a lane boundary, work has changed hands, and that is where things get lost, delayed, or done twice. A diagram with four lane crossings in six steps has just told you something important.

They also cost nothing in expressiveness: a partition changes no semantics, it only says who is responsible. If the performer does not matter for your question, leave them out.

05When to draw one

Reach for it when

  • A business process with real branching that people need to agree on
  • Anything with genuine parallelism - the fork/join notation has no good substitute
  • Documenting the main flow and alternatives behind a use case
  • Showing handoffs between teams or systems, with swimlanes

Reach for something else when

  • The process is linear - a numbered list is shorter and just as clear
  • You are describing one object's lifecycle - use a state machine diagram
  • It is really about message order between services - use a sequence diagram
  • You would be transcribing an existing function statement by statement

06Common mistakes

  1. Fork used where a decision was meant. A bar says both paths run. If only one should, it is a diamond.
  2. A fork with no join. Legal, but usually a mistake: it says nothing ever waits for those parallel paths to finish.
  3. Guards that do not cover everything. Add [else].
  4. Actions named as nouns. Refund is ambiguous; Credit customer is a step. Name actions verb-first.
  5. Activity final where flow final was meant. The ring-and-disc kills the entire activity, including branches still running. If you only meant to end one path, use the crossed circle.

In one line each

  1. 01Think in tokens: an action runs when a token arrives, and passes it on when it finishes.
  2. 02Diamond chooses one path; solid bar runs all of them.
  3. 03Merge does not wait. Join does. This is the pair to get right.
  4. 04Guards go in square brackets and must be exhaustive - always add [else].
  5. 05Swimlanes show who performs each step; lane crossings are where processes fail.
  6. 06Activity final ends everything; flow final ends only its own path.
All articles