UML Activity Diagram
The UML activity diagram models how a piece of work unfolds inside a single system: the sequence of actions, the decisions that route them, the branches that run in parallel and the objects that move through. It belongs to the UML model, where it realises a use case, and it rests on token semantics: each node offers then accepts a token along the edges. Three traits separate it from a flowchart it resembles: guards are written in square brackets on the edges, fork and join bars express genuine concurrency and an object flow follows the control flow. It is read at three levels of abstraction, from the enterprise view down to the system view, and its value concentrates in the lower levels, where a model becomes precise enough to be simulated or executed.
Goal
The diagram specifies, formally, how a use case is carried out inside a system: the order of the actions, the conditions that route the flow, the simultaneous pieces of work that must re-synchronise and the objects that pass from one action to the next. It is a model artefact, attached to a use case in the UML model. Its token semantics make it workable down to executable detail, and they are also what sets it apart from a flowchart of the same appearance.
Usage
When to use it
- Realising a use case: show the internal behaviour that delivers what the use case promises.
- Genuine concurrency in the logic: two simultaneous pieces of work that must re-synchronise, carried by a fork bar.
- Routing on guarded conditions: the condition, decided upstream, is written in square brackets on the edge.
- Artefact embedded in the UML model: the logic traces to the use case and the surrounding class model.
When not to use it
- A non-technical audience to align on the process: the formality buys nothing in this case, reach for the flowchart.
- Independent participants exchange messages across an organisational boundary: this is a collaboration, use BPMN.
- The question is what governs and performs a function: use IDEF / IGOE.
Description
A control and object flow inside a single system
The diagram is a graph of nodes joined by edges, driven by token semantics: one node offers a token, the next accepts it, and it is this circulation that carries the meaning. The flow starts at an initial node, passes through actions and ends at an activity final node; decisions are hollow diamonds, the fork and join bars are thick lines and an object node shows an object passing from one action to the next. It is one of the process modelling notations, the one that lives inside the model of a system.
Two properties separate it from a flowchart it imitates. The guard decides, the diamond only routes: the condition, written in square brackets on the edge, directs the flow along the branch on which it holds. And the fork bar expresses genuine concurrency, two branches that run at the same time and meet again at the join, where a flowchart can only place two sequences side by side. Added to this are the object flow and the membership of the UML model, where the diagram realises a use case. Partitions, or swimlanes, name who performs an action but do not distinguish the notation: the flowchart, BPMN and the activity diagram all accept them.
The three levels
A process model is built at three levels of abstraction, and its worth differs from one to the next. At the high, enterprise or context level, the model gives a general understanding of the process and its relationships to neighbouring processes; formal semantics serve nothing there, and a process landscape or a flowchart fit better. At the operational level, the model details the activities and names every outcome, exceptions and alternative paths included: this is where the diagram earns its place, guarded decisions routing the exceptions and a fork bar showing the branches that genuinely run in parallel. At the system level, the lowest, the model becomes precise enough to be simulated or executed, and the token semantics make that level reachable.
The activity diagram is therefore an artefact of the operational and system levels: it elaborates a chosen design and drives it down to executable detail, without framing the enterprise context.
AI considerations
Two uses hold. The first draft: from the written description of a use case, a language model proposes a graph of actions, decisions and endings that the analyst corrects. And the form check, mechanical, delegates well: does every fork have its join, does every decision carry guards on its exits, is any action left without an incoming edge?
What does not delegate belongs to meaning. Deciding that two branches are genuinely concurrent engages a knowledge of how the work is performed. And the question that precedes everything, a single system or participants exchanging messages, settles the choice between this diagram and BPMN: it is answered in the field.
You'll find more detail in our BPMN tutorial.
Examples
Order validation at a Swiss online retailer, inside its own systems. The concept the drawing makes visible is genuine concurrency: on an order that is in stock, two pieces of work start at the same time and must meet again before confirmation.
The order, an object node carrying a total of CHF 1'250, moves from one action to the next. Reserving the stock and taking the payment need not wait for each other, where a flowchart could only place them in sequence.
One point alone decides that this drawing is an activity diagram: the payment is handled inside the retailer's system. Were the payment provider exchanging messages across an organisational boundary, it would have to become BPMN, with two pools and a message flow.
Visualizations
The geometry is the content. An edge's role is read in its shape: a guard in square brackets states the condition that routes, a thick bar asserts a concurrency a plain line could not carry, a bullseye marks the activity final and an open arrowhead signs the control flow.
Cost
| Phase | Level | Justification |
|---|---|---|
| Preparation | Medium | The use case and the chosen design must exist before drawing: that is the substance of the drawing. |
| Execution | Low | A use case fits in one diagram, drawn in a single session. The cost rises with the number of guarded branches and concurrent pieces of work; the size of the system makes no difference. |
| Documentation | Medium | The diagram lives in the UML model and is updated when the use case or the class model changes. Its value rests on that maintained consistency. |
Tooling
A whiteboard is enough for a first sketch: a flow of actions and two guarded branches fit on a single sheet. General-purpose drawing tools, diagrams.net, Lucidchart or Visio, carry correct stencils, but their contribution stops at the drawing, and the link to the use case then survives only in the author's head. UML modelling workbenches, Enterprise Architect, Visual Paradigm or Modelio, hold the diagram as an object of the model: it traces to the use case it realises and to the classes it manipulates, and the tool flags a fork without a join or a decision without a guard.
Sources
- OMG, Unified Modeling Language (UML), Version 2.5.1, the Activities clause: the token semantics, the control nodes (initial node, decision and merge, fork and join, activity final), the guards, the object flow and the partitions.
- IIBA, A Guide to the Business Analysis Body of Knowledge (BABOK Guide) v3, §10.35 Process Modelling: the activity diagram among the process modelling notations and the three levels of a process model.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.5 UML: the activity diagram as a secondary use for business process modelling, in the information technology domain.
- ABPMP, Guide to the Business Process Management Common Body of Knowledge (BPM CBOK), §3.3.2 Swim Lanes: lanes are a notational addition.