Activity Diagram

An activity diagram models the flow of activities in a process—showing the sequence of actions, decision points, parallel execution, and synchronization. Think of it as a sophisticated flowchart enhanced with UML notation for concurrency, partitioning, and object flow. Activity diagrams are versatile: they model business workflows (order fulfillment process), algorithmic logic (sorting algorithm steps), use case scenarios (detailed steps in making a purchase), and system processes (batch data processing pipelines). They answer the question: "What happens step by step, and in what order?"

Core Notation

Activity/Action Node (rounded rectangle): A single step or task in the process. Each node represents work being done: "Verify Credit Card," "Ship Package," "Send Confirmation Email."

Initial Node (filled circle ●): The starting point of the activity flow.

Final Node (circle with filled center ◉): The ending point—the process terminates here.

Decision Node (diamond ◇): A branching point where flow takes one path based on a condition. Guard conditions on outgoing edges specify which path is taken.

Merge Node (diamond ◇): Combines multiple alternative paths back into one. Visually identical to decision nodes but has multiple incoming edges and one outgoing edge.

Fork (thick bar ═): Splits a single flow into multiple concurrent (parallel) flows. All outgoing paths execute simultaneously.

Join (thick bar ═): Synchronizes multiple concurrent flows—the process waits until ALL incoming flows complete before proceeding.

Swimlanes: Vertical or horizontal partitions showing which actor or system component is responsible for each activity.

Real-World Example: Online Order Fulfillment

This diagram shows: after receiving an order, inventory is checked. If in stock, payment processing and picking/packing happen in parallel (fork). Both must complete (join) before shipping. If out of stock, the customer is notified and the system waits for restocking before proceeding.

Swimlane Example: Loan Application Process

Swimlanes make responsibility clear—you can immediately see which actor performs each step and where handoffs occur between actors.

When to Use Activity Diagrams

Business process modeling: Documenting how work flows through an organization (insurance claim processing, employee onboarding, procurement).

Use case elaboration: Detailing the step-by-step flow of a use case, including alternative and exception paths.

Algorithm design: Modeling complex algorithmic logic with decision points and parallel processing.

Workflow automation: Specifying workflows for automation engines (BPMN tools, workflow platforms).

Testing: Deriving test scenarios from activity paths—each path through the diagram suggests a test case.

Activity Diagram vs. Flowchart

Activity diagrams extend traditional flowcharts with: parallel execution (fork/join), swimlanes for responsibility assignment, object flow (showing data objects passed between activities), signal sending and receiving (inter-process communication), and exception handling. For simple sequential processes, a flowchart suffices; for processes with concurrency, multiple actors, or complex data flow, activity diagrams provide the necessary expressiveness.

Best Practices

Start with the main success path before adding alternatives and exceptions. Use swimlanes whenever multiple actors or systems participate. Keep each activity node at a consistent level of abstraction—do not mix "Click Submit Button" with "Process Annual Financial Reconciliation" in the same diagram. Label all decision branches with guard conditions. Use fork/join only for genuinely concurrent activities—sequential activities connected by fork/join mislead readers. Include exception flows for important error scenarios rather than modeling only the happy path.