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:
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 (→).
┌──────────────────────────────────────────────────────────────────────────────────────────┐ │ Sequential Flow │ │ │ │ ● │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Start Task │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Process │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ End Task │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ⊙ │ └──────────────────────────────────────────────────────────────────────────────────────────┘
Multiple paths based on conditions; only one executes. Paths rejoin at a merge node.
┌──────────────────────────────────────────────────────────────────────────────────────────┐ │ Branching: Decision and Merge │ │ │ │ ● │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Check Age │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ age >= 18 ? │ │ │ └──┬────────────┬──┘ │ │ Yes No │ │ │ │ │ │ ▼ ▼ │ │ ┌────────────────┐ ┌────────────────┐ │ │ │ Grant Access │ │ Deny Access │ │ │ └────────┬───────┘ └────────┬───────┘ │ │ │ │ │ │ └────────┬─────────┘ │ │ │ │ │ ▼ │ │ ⊙ │ └──────────────────────────────────────────────────────────────────────────────────────────┘
Multiple activities execute concurrently. A join synchronizes before continuing.
┌──────────────────────────────────────────────────────────────────────────────────────────┐ │ Parallel Execution: Fork and Join │ │ │ │ ● │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Order Ready │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ (FORK) │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │ │ │ Send Email │ │ Pack Items │ │ Charge Card │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ ▼ ▼ ▼ │ │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ (JOIN) │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Finalize │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ⊙ │ └──────────────────────────────────────────────────────────────────────────────────────────┘
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.
┌─────────────────────┬──────────────────────┬──────────────────────┬──────────────────────┐ │ CUSTOMER │ SALES │ WAREHOUSE │ SHIPPING │ ├─────────────────────┼──────────────────────┼──────────────────────┼──────────────────────┤ │ ● │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ ┌───────────────┐ │ │ │ │ │ │ Place Order │ │ │ │ │ │ └───────┬───────┘ │ │ │ │ │ │ │ │ │ │ │ └──────────│─▶ ┌──────────────┐ │ │ │ │ │ │ Validate │ │ │ │ │ │ │ Order │ │ │ │ │ │ └──────┬───────┘ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ [ Valid ? ] │ │ │ │ │ ╱ ╲ │ │ │ │ │ No Yes │ │ │ │ │ │ │ │ │ │ │ │ ▼ └───────│─▶ ┌──────────────┐ │ │ │ │ ┌────────┐ │ │ Check Stock │ │ │ │ │ │Decline │ │ └──────┬───────┘ │ │ │ │ └────────┘ │ │ │ │ │ │ │ ▼ │ │ │ │ │ ┌──────────────┐ │ │ │ │ │ │ Pick & Pack │ │ │ │ │ │ └──────┬───────┘ │ │ │ │ │ │ │ │ │ │ │ └───────────│─▶ ┌──────────────┐ │ │ │ │ │ │ Ship │ │ │ │ │ │ └──────┬───────┘ │ │ │ │ │ │ │ │ ◀──────────│──────────────────────│──────────────────────│──────────┘ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ ┌───────────────┐ │ │ │ │ │ │ Receive │ │ │ │ │ │ └───────┬───────┘ │ │ │ │ │ │ │ │ │ │ │ ▼ │ │ │ │ │ ⊙ │ │ │ │ └─────────────────────┴──────────────────────┴──────────────────────┴──────────────────────┘
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.
┌──────────────────────────────────────────────────────────────────────────────────────────┐ │ Order Processing Workflow │ │ │ │ ● │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Place Order │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Process Payment │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────┐ │ │ │ Successful ? │ │ │ └──┬───────────┬──┘ │ │ Yes No │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────┐ ┌────────────────┐ │ │ │ Check Inventory│ │ Reject Order │ │ │ └────────┬────────┘ └────────┬───────┘ │ │ │ │ │ │ ▼ │ │ │ ┌────────────┐ │ │ │ │ In Stock ? │ │ │ │ └─┬────────┬─┘ │ │ │ Yes No │ │ │ │ │ │ │ │ ▼ ▼ │ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │Reserve Inventory│ │Backorder/Cancel │ │ │ └────────┬────────┘ └────────┬────────┘ │ │ │ │ │ │ └─────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Generate Labels │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Ship │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Deliver │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ⊙ │ └──────────────────────────────────────────────────────────────────────────────────────────┘
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.
┌──────────────────────────────────────────────────────────────────────────────────────────┐ │ CI/CD Pipeline │ │ │ │ ● │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Developer Commits │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Build (Compile + │ │ │ │ Package) │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Run Unit Tests │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Integration Tests │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ (FORK) │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Security Scan │ │Performance Test │ │ │ └────────┬────────┘ └────────┬────────┘ │ │ │ │ │ │ ▼ ▼ │ │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ (JOIN) │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Deploy to Staging │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Manual Approval ?│ │ │ └──┬────────────┬──┘ │ │ Yes No │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────┐ ┌────────────┐ │ │ │ Deploy to │ │ Reject │ │ │ │ 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.
┌──────────────────────────────────────────────────────────────────────────────────────────┐ │ User Registration │ │ │ │ ● │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Submit Registration │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Validate Email │ │ │ │ Format │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ┌──────────────────┐ │ │ │ Email Exists ? │ │ │ └──┬────────────┬──┘ │ │ Yes No │ │ │ │ │ │ ▼ ▼ │ │ ┌─────────────────┐ ┌─────────────────┐ │ │ │ Notify Existing │ │ Create Account │ │ │ │ User │ │ │ │ │ └────────┬────────┘ └────────┬────────┘ │ │ │ │ │ │ │ ▼ │ │ │ ┌─────────────────────┐ │ │ │ │ Send Verification │ │ │ │ │ Email │ │ │ │ └──────────┬──────────┘ │ │ │ │ │ │ │ ▼ │ │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ (FORK) │ │ │ │ │ │ │ │ ▼ ▼ │ │ │ ┌─────────────┐ ┌─────────────┐ │ │ │ │Verify Email │ │Notify Admin │ │ │ │ └──────┬──────┘ └──────┬──────┘ │ │ │ │ │ │ │ │ ▼ ▼ │ │ ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ (JOIN) │ │ │ │ │ │ └─────────┬─────────┘ │ │ │ │ │ ▼ │ │ ┌─────────────────────┐ │ │ │ Activate Account │ │ │ └──────────┬──────────┘ │ │ │ │ │ ▼ │ │ ⊙ │ └──────────────────────────────────────────────────────────────────────────────────────────┘
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.