An activity diagram is a flowchart with superpowers: it shows the steps of a process, the decisions along the way, and which steps can run at the same time. Swimlanes show which person, team or system is responsible for each step. It is used for business processes, workflows such as CI/CD pipelines, and algorithms.
Activity diagrams are UML behavioral diagrams used to model workflows, business processes, algorithms, and system interactions. They extend flowcharts by introducing concurrency support, swimlanes, and object flow semantics. Unlike flowcharts, activity diagrams are part of the formal UML standard and excel at representing parallel execution, synchronization points, and cross-functional processes.
Key purposes:
A filled dot starts the activity, a bullseye ends the whole activity, and a circled X ends just one flow. Rounded rectangles are actions; diamonds are decisions (with [guard] labels on outgoing arrows) or merges. A thick bar is a fork (one flow becomes several parallel flows) or a join (wait until all arrive). Swimlanes divide actions by role.
Activity diagrams consist of the following fundamental components:
A filled circle (●) representing the start of the diagram flow.
A bullseye or target symbol (⊙) representing the end of the diagram. Multiple final nodes indicate alternative outcomes.
A rounded rectangle containing the name of an action or activity. Represents a unit of work or computation.
A diamond (◇) with incoming flow and multiple outgoing flows, each guarded by a condition. Only one guard evaluates true.
A diamond combining multiple incoming flows into a single outgoing flow (no synchronization of timing).
A thick horizontal or vertical bar (━) splitting one flow into multiple concurrent flows. Represents the start of parallel execution.
A thick bar (━) synchronizing multiple incoming flows into one. Waits for all incoming flows to complete.
Vertical or horizontal sections that assign activities to specific actors, departments, or systems. Activities stay within their respective swimlane.
A rectangle representing input/output objects (parameters, data). Can be typed (e.g., <<Order>>).
Send: triangle pointing right (▶). Receive: triangle pointing left (◀). Used for asynchronous communication.
Activities execute one after another, connected by solid arrows (→).
Multiple paths based on conditions; only one executes. Paths rejoin at a merge node.
Multiple activities execute concurrently. A join synchronizes before continuing.
A dashed boundary indicating activities that can be interrupted by an external event. Often used with exception handlers.
Arrows emanating from an interruptible region indicate exception flows with guard conditions.
Swimlanes partition activities by actor, role, department, or system. Each swimlane is a vertical (or horizontal) section, and activities must remain in their assigned lane. Flows cross lane boundaries when interaction occurs.
In this example, the Customer initiates the order, Sales validates, Warehouse checks inventory and picks/packs, and Shipping delivers. Flows cross swimlane boundaries to show handoffs.
A complete activity diagram from order placement through delivery, including payment verification and inventory checks.
Flow: Order placed → Payment processed → If payment fails, reject and exit. If successful, check inventory → If in stock, reserve; else backorder. Generate shipping labels, ship, and deliver.
A typical continuous integration and deployment pipeline with sequential build steps, parallel testing, and gated promotion to production.
Flow: Code commit → Build → Unit tests → Integration tests → (fork) Security and Performance tests run in parallel → (join) Deploy to staging → Manual approval gate → Deploy to production or reject.
User registration workflow with email verification, duplicate account detection, and parallel notification to admin and user.
Flow: Registration submitted → Validate email → If email exists, notify user. If new, create account, send verification email → (fork) Verify and notify admin concurrently → (join) Activate account.
| Aspect | Activity Diagram | Flowchart |
|---|---|---|
| Concurrency | Native support via fork/join | No built-in concurrency |
| Swimlanes | Supported for cross-functional flows | Not standard |
| Standard | UML formal standard | Informal; various conventions |
| Object Flow | Explicit object nodes and pins | No formal object representation |
| Signals | Send/receive signals for async | Not supported |
| Use Case | Complex workflows, algorithms | Simple sequential logic |
| Complexity | Steeper learning curve | Simpler, more intuitive |
Mermaid does not natively support UML activity diagrams, but you can approximate them using flowchart syntax with concurrency comments. Below is a Mermaid flowchart approximating the CI/CD pipeline:
graph TD
A([Developer Commits Code])
B[Build - Compile & Package]
C[Run Unit Tests]
D[Integration Tests]
E[Security Scan]
F[Performance Test]
G[Deploy to Staging]
H{Manual Approval?}
I[Deploy to Production]
J[Reject]
K([End])
A --> B
B --> C
C --> D
D --> E
D --> F
E --> G
F --> G
G --> H
H -->|Yes| I
H -->|No| J
I --> K
J --> K
style A fill:#0066cc
style K fill:#ff9900
style H fill:#ffcc00,color:#000
Limitation: This syntax does not explicitly show fork/join semantics. For true UML activity diagrams with concurrency, use dedicated tools like Lucidchart, Draw.io, or PlantUML.
Activity diagrams are powerful tools for modeling workflows and processes that involve sequential steps, parallel execution, and cross-functional interactions. Their support for swimlanes, concurrency, and UML standardization makes them ideal for documenting complex business processes, algorithms, and system interactions. Use them in tandem with other UML diagrams (sequence diagrams for temporal ordering, state diagrams for object states) to create comprehensive system models.
Rendered by PlantUML activity syntax ("new" beta syntax), rendered by the PlantUML server, IDE plugins or plantuml.jar. Swimlanes use |Lane|. The order processing workflow:
@startuml
|Customer|
start
:Place order;
|Sales|
:Validate order;
if (In stock?) then (yes)
fork
:Charge payment;
fork again
|Warehouse|
:Pick and pack items;
end fork
|Shipping|
:Ship order;
:Send tracking email;
else (no)
|Sales|
:Notify customer of backorder;
endif
|Customer|
:Receive confirmation;
stop
@enduml