UML activity diagrams

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.

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.

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.

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.

This is also the point where the notation runs out. A UML partition says who performs a step; it does not distinguish a colleague in the next team from a different company with its own process. BPMN splits those into lanes and pools and gives the boundary between pools real semantics - only messages cross it. If the handoffs you care about leave the organisation, that distinction is worth the second notation, and BPMN is where to start.

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.