UML Activity Diagrams

1. Overview

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:

Model sequential and concurrent workflows
Document business processes and use case realizations
Represent algorithms and control logic
Show interactions between multiple actors/systems
Visualize exception handling and interrupts

2. Core Elements

Activity diagrams consist of the following fundamental components:

Initial Node

A filled circle (●) representing the start of the diagram flow.

Final Node

A bullseye or target symbol (⊙) representing the end of the diagram. Multiple final nodes indicate alternative outcomes.

Action/Activity Node

A rounded rectangle containing the name of an action or activity. Represents a unit of work or computation.

Decision Node

A diamond (◇) with incoming flow and multiple outgoing flows, each guarded by a condition. Only one guard evaluates true.

Merge Node

A diamond combining multiple incoming flows into a single outgoing flow (no synchronization of timing).

Fork Node

A thick horizontal or vertical bar (━) splitting one flow into multiple concurrent flows. Represents the start of parallel execution.

Join Node

A thick bar (━) synchronizing multiple incoming flows into one. Waits for all incoming flows to complete.

Swimlanes/Partitions

Vertical or horizontal sections that assign activities to specific actors, departments, or systems. Activities stay within their respective swimlane.

Object Node

A rectangle representing input/output objects (parameters, data). Can be typed (e.g., <<Order>>).

Signal Send/Receive

Send: triangle pointing right (▶). Receive: triangle pointing left (◀). Used for asynchronous communication.

3. Control Flow

Sequential Flow

Activities execute one after another, connected by solid arrows (→).

         ●
         │
         ▼
    ┌─────────────┐
    │ Start Task  │
    └─────────────┘
         │
         ▼
    ┌─────────────┐
    │ Process     │
    └─────────────┘
         │
         ▼
    ┌─────────────┐
    │ End Task    │
    └─────────────┘
         │
         ▼
         ⊙

Branching (Decision/Merge)

Multiple paths based on conditions; only one executes. Paths rejoin at a merge node.

         ●
         │
         ▼
    ┌─────────────┐
    │  Check Age  │
    └─────────────┘
         │
         ▼
        ◇ [age >= 18]
       / \
      /   \
    [T]   [F]
    /       \
   ▼         ▼
┌──────┐  ┌──────┐
│Grant │  │ Deny │
└──────┘  └──────┘
   │       │
    \     /
     ▼   ▼
      ◇ (merge)
      │
      ▼
     ⊙

Parallel Execution (Fork/Join)

Multiple activities execute concurrently. A join synchronizes before continuing.

         ●
         │
         ▼
    ┌─────────────┐
    │ Order Ready │
    └─────────────┘
         │
         ▼
    ━━━━━━━━━━━━━ (fork)
    ║   │   │
    │   │   │
    ▼   ▼   ▼
  ┌──┐┌──┐┌──┐
  │Sq││Pm││Ci│
  └──┘└──┘└──┘
    │   │   │
    ━━━━━━━━━━━━━ (join)
         │
         ▼
    ┌─────────────┐
    │  Finalize   │
    └─────────────┘
         │
         ▼
        ⊙

Interruptible Regions

A dashed boundary indicating activities that can be interrupted by an external event. Often used with exception handlers.

Exception Handlers

Arrows emanating from an interruptible region indicate exception flows with guard conditions.

4. Swimlanes

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.

Order Fulfillment Across Departments

┌──────────┬──────────┬─────────┬──────────┐
│ Customer │  Sales   │Warehouse│ Shipping │
├──────────┼──────────┼─────────┼──────────┤
│    ●     │          │         │          │
│    │     │          │         │          │
│    ▼     │          │         │          │
│┌────────┐│          │         │          │
││Place   ││          │         │          │
││Order   ││          │         │          │
│└────────┘│          │         │          │
│    │     │          │         │          │
│    ├────▶│◇ Valid? │         │          │
│    │     │  F      │         │          │
│    │   ┌─┴─────┐   │         │          │
│    │   │Decline│   │         │          │
│    │   └───────┘   │         │          │
│    │   T           │         │          │
│    │     │         │         │          │
│    │     ├────────▶│Check Inv│         │
│    │     │         │   │     │         │
│    │     │         │   ◇[Out]│         │
│    │     │         │  /  \   │         │
│    │     │         │/      \ │         │
│    │     │         │  Pick  │         │
│    │     │         │ &Pack   │         │
│    │     │         │   │     │         │
│    │     │         │   ├────────────▶│Ship  │
│    │     │         │         │   │   │
│    │     │         │         │   ├──▶│Deliver
│    │     │         │         │   │   │
│    ◀─────┴─────────┴─────────┴───┘   │
│ 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.

5. Example: Order Processing Workflow

A complete activity diagram from order placement through delivery, including payment verification and inventory checks.

                           ●
                           │
                    ┌──────▼──────┐
                    │Place Order  │
                    └──────┬──────┘
                           │
                    ┌──────▼──────┐
                    │Process Pay. │
                    └──────┬──────┘
                           │
                          ◇ [Success?]
                         / \
                        /   \
                      [Y]    [N]
                      /       \
                     ▼         ▼
              ┌──────────┐  ┌──────────┐
              │Check Inv.│  │Reject    │
              └────┬─────┘  │Order     │
                   │        └──────────┘
                  ◇ [In Stock?]
                 / \
               /     \
             [Y]     [N]
             /         \
            ▼           ▼
        ┌────────┐  ┌──────────┐
        │Reserve │  │Backorder │
        │Inventory   │ or 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.

6. Example: CI/CD Pipeline

A typical continuous integration and deployment pipeline with sequential build steps, parallel testing, and gated promotion to production.

              ●
              │
       ┌──────▼──────┐
       │Developer    │
       │Commits Code │
       └──────┬──────┘
              │
       ┌──────▼──────┐
       │Build (Compile
       │+ Package)   │
       └──────┬──────┘
              │
       ┌──────▼──────┐
       │Run Unit     │
       │Tests        │
       └──────┬──────┘
              │
       ┌──────▼──────┐
       │Integration  │
       │Tests        │
       └──────┬──────┘
              │
         ━━━━┴━━━━━━━━━━ (fork)
         │          │
         ▼          ▼
    ┌────────┐  ┌─────────┐
    │Security│  │Performance
    │Scan    │  │Test
    └────────┘  └─────────┘
         │          │
         ━━━━┬━━━━━━━━ (join)
             │
       ┌─────▼──────┐
       │Deploy to   │
       │Staging     │
       └─────┬──────┘
             │
            ◇ [Manual Approval?]
           / \
         /     \
       [Y]     [N]
       /         \
      ▼           ▼
 ┌──────────┐  ┌──────┐
 │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.

7. Example: User Registration

User registration workflow with email verification, duplicate account detection, and parallel notification to admin and user.

              ●
              │
       ┌──────▼──────┐
       │Submit        │
       │Registration  │
       └──────┬──────┘
              │
       ┌──────▼──────┐
       │Validate      │
       │Email Format  │
       └──────┬──────┘
              │
             ◇ [Email Exists?]
            / \
          /     \
        [Y]     [N]
        /         \
       ▼           ▼
  ┌────────┐  ┌────────────┐
  │Notify  │  │Create User │
  │Existing│  │Account     │
  └────────┘  └────┬───────┘
       │            │
       │    ┌───────▼────────┐
       │    │Send Verification
       │    │Email            │
       │    └───────┬────────┘
       │            │
       │       ━━━━┴━━━━━━ (fork)
       │       │        │
       │       ▼        ▼
       │   ┌────┐  ┌──────────┐
       │   │Verify│ │ Notify  │
       │   │Email │ │ 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.

8. Activity Diagrams vs. Flowcharts

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

9. Mermaid.js Code

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.

10. Best Practices

Single Entry and Exit: Every diagram should have one initial node and one or more final nodes. Avoid dangling flows.
Label Decision Guards: Always annotate decision paths with conditions (e.g., [Success], [age >= 18]). This clarifies the logic.
Use Swimlanes for Cross-Functional Processes: If multiple actors/systems are involved, swimlanes make responsibilities clear and improve readability.
Name Actions as Verb Phrases: Use imperative verbs: "Process Payment," "Check Inventory," "Send Notification" instead of nouns.
Keep Diagrams to One Page: Large diagrams become difficult to understand. Break complex workflows into sub-activities referenced in separate diagrams.
Distinguish Fork/Join from Decision/Merge: Forks split into parallel paths (all execute); decisions split into exclusive paths (one executes).
Use Object Nodes for Data Flow: When data or parameters are passed between activities, show them explicitly with object nodes.
Group Related Activities: Use composite activities or sub-flows to abstract low-level details and improve clarity.
Test for Syntax and Semantics: Verify that all paths from initial to final node are possible and that fork/join pairs are balanced.
Document Exception Handlers: Clearly mark interruptible regions and the exceptions they handle with guard conditions.

Summary

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.