A UML activity diagram models a process as a set of actions connected by flows. The process does not have to be software. An expense approval that crosses three departments fits the notation as well as a CI pipeline does. Among the UML behavior diagrams, this is the one about steps and their order, not about objects and the messages between them.
What is a UML Activity Diagram?
An activity diagram describes the behavior of a system or an organization as steps in the order they run. You read it from the initial node, along the arrows, to a final node. It shows:
- Actions: the individual steps
- Control flows: arrows giving the order between steps
- Decisions and merges: where the process takes one of several paths, and where those paths come back together
- Forks and joins: where the process splits into parallel paths, and where it waits for all of them
- Object flows: data or documents moving between steps
- Partitions: lanes naming who performs which steps
Why Use Activity Diagrams?
- Working out a process before automating it: draw the manual process as it runs today, then mark the actions the new system takes over.
- Filling in a use case: a use case diagram names the goal, Place Order, and stops there. The steps go in an activity diagram.
- Finding parallelism: some steps can start together and some cannot. The diagram states which, and where the process has to wait.
- Recording responsibility: when a process crosses a team or service boundary, lanes show where work passes from one side to the other.
Core Components and Notation
Action and Control Flow
An action is a single step in the process. It is drawn as a rounded rectangle with the step's name inside. A control flow is the solid arrow between two actions, and it means the first action must finish before the second starts. In a hiring process, Screen application and Schedule interview are actions joined by a control flow. A condition in square brackets on an arrow is a guard; the flow is taken only when the condition is true.
Initial and Final Nodes
An initial node is a solid black circle. It marks where the process starts. There are two ending nodes. The activity final node is a solid circle inside a hollow ring; it ends the whole process, including parallel paths that are still running. The flow final node is a circle with an X in it; it ends only the path that reaches it, and the rest of the process continues. The receipt email path of an order process ends at a flow final while the packing path continues.
Decision and Merge Nodes
A decision node is a diamond with one arrow in and several out. Each outgoing arrow has a guard, and the process follows the arrow whose guard is true. One arrow may use the predefined guard [else], taken when no other arrow accepts the flow. A loan application takes the [approved] arrow or the [rejected] arrow, never both. A merge node is the same diamond with several arrows in and one out. It does not wait; each arriving flow continues straight out.
Fork and Join Nodes
A fork is a thick bar with one arrow in and several out. When the flow reaches it, every outgoing path starts at once; where a decision picks one path, a fork starts them all. A join is a thick bar with several arrows in and one out. It waits for every incoming path to arrive, then the process continues as a single flow. An airline check-in forks into Check passport and Weigh baggage, and boarding waits at the join for both.
Object Nodes and Data Stores
An object node is a rectangle between two actions naming the data that moves from one to the other, an Invoice for example. Arrows entering or leaving it are object flows; they carry data, not just order. The same information can be drawn as pins, small squares on the edge of an action, one per input or output. An object node with the keyword «datastore» is a data store: it holds its contents for the whole run of the process, and an action reading from it gets a copy while the original stays in place. A customer register read by both the billing step and the shipping step is a data store.
Partitions
A partition, usually called a swimlane, divides the diagram into rows or columns, one per performer. The performer's name goes in a box at one end of the lane, at the top when lanes run vertically, and every action inside the lane belongs to that performer. An insurance claim diagram gets one lane for the customer, one for the claims handler, and one for accounting. When lanes would make the diagram too wide, write the partition name in parentheses above the action name instead.
Send Signal and Accept Event Actions
Send signal and accept event actions communicate with something outside the process. A send signal action is a box with one pointed end. The process sends the named signal and continues without waiting for a reply. An accept event action is a box with one end notched inward. The flow stops there until the named event arrives. In an order process, Request payment is a send signal. Payment confirmed is the event the process waits for before shipping. An accept event action with no incoming arrow waits the whole time the process runs. Its outgoing flow starts each time the event occurs. A wait for a specific time such as the end of the month is drawn as an hourglass.
Practical Example: Pull Request CI Pipeline
The diagram models what happens after a developer pushes a branch. Two lanes split the work between the developer and the CI server.
- The initial node is in the Developer lane. Push branch is the only action the developer performs.
- The flow crosses into the CI Server lane and reaches a fork. Run linter and Run unit tests start at the same time.
- The join under them waits for both to finish.
- The decision routes on the result.
[all checks passed]continues to Build container image.[else]goes to Post failure comment. - A Container image object node is between Build container image and Deploy to staging. The image itself is the input of the deploy step.
- The two branches meet at a merge node, and the flow ends with the send signal action Notify developer and an activity final node. The pipeline stops as soon as the notification is sent.
Best Practices
- Use a flow final to end one path, an activity final to end the whole process: the first flow to reach an activity final also cancels every other path still running.
-
Write guards that cannot both be true:
[total >= 100]beside[total <= 100]can both be true at 100, and the tool then picks the edge. - Do not guard the edges out of a fork when a join collects them: a flow stopped by a failed guard never reaches the join, and the process stops there.
- Omit pins when they make the diagram hard to read: an action name like Build container image already names its output.
- Break an arrow that would cross the whole diagram with a pair of connectors: the arrow ends at a small labeled circle and continues from the circle with the same label elsewhere on the page.
Conclusion
An activity diagram records how one process runs from start to finish, including any parallel paths. It does not record which objects carry out a step or what messages pass between them. That is what sequence diagrams show. A state machine diagram covers the states one object passes through over its lifetime.
