Activity Diagrams: Actions & Flows

Activity Diagrams: Actions & Flows

In the previous lessons you modeled who says what to whom using sequence diagrams. Now we shift to a different behavioral question: what happens, step by step, when the system runs? That is the domain of the Activity Diagram — the UML diagram that shows workflows, decisions, and the paths a process can take from beginning to end.

Activity diagrams are arguably the most broadly used behavioral diagram in practice. Business analysts use them to document business processes. Developers use them to design algorithms. Testers use them to identify paths that need test cases. By the end of this lesson you will be able to draw a correct, readable activity diagram for a real business scenario using the four core elements: start nodes, end nodes, actions, and decisions with merges.

The Four Core Elements

Every activity diagram is built from a small set of precisely defined shapes. Learn these shapes by heart — using the wrong shape breaks the standard notation and confuses your readers.

• Initial Node (Start): A solid filled circle (●). Every activity diagram has exactly one initial node. It marks where the flow begins and has no incoming edges — only an outgoing one.
• Activity Final Node (End): A bullseye — a filled circle inside a larger unfilled circle (⊙). The flow reaches here when the entire activity is complete. A diagram may have more than one activity final node if multiple paths can finish the activity.
• Action: A rounded rectangle containing a short verb phrase. Each action represents one discrete step that the system or a person performs — "Validate Credentials", "Send Confirmation Email", "Check Availability". Actions are the workhorses of the diagram.
• Decision Node: A diamond. It has exactly one incoming edge and two or more outgoing edges. Each outgoing edge carries a guard condition in square brackets — for example [available] and [not available]. The guards must be mutually exclusive and collectively exhaustive (every possible outcome is covered).
• Merge Node: Also a diamond, but used in the reverse direction: it has two or more incoming edges and exactly one outgoing edge. The merge node reunites paths that were split by a decision. In practice many tools and authors draw merges and decisions with the same diamond; you distinguish them by counting their edges.
• Control Flow (Edge): A solid arrow connecting two nodes. The flow follows the arrow. No label is needed on most edges; labels appear only on decision outgoing edges (the guard conditions).

Reading an Activity Diagram: Clinic Appointment Booking

Before drawing, practice reading. The diagram below models the process a clinic receptionist and its booking system follow when a patient requests an appointment.

Walk through this diagram step by step:

1. The flow starts at the filled black circle.
2. "Receive Appointment Request" and "Search Doctor Availability" are sequential actions — connected by plain arrows.
3. The first diamond is a decision: one edge comes in, two go out, labelled [yes] and [no].
4. The [yes] path immediately confirms the booking. The [no] path offers the next available date, then asks the patient again.
5. The second diamond (inner [no]) routes to "Cancel Request" and a separate end node — the activity can terminate here without sending any email.
6. The purple diamond labelled "merge" reunites the two successful paths (confirmed immediately, or confirmed after rescheduling) back into a single flow.
7. "Send Confirmation Email" executes, and the bullseye marks the successful end.

The Notation Reference: All Core Shapes

The diagram below is a compact notation legend — not a business scenario, but a visual reference showing each shape in isolation with its name and the rules that govern it.

Drawing a Decision-Rich Example: Online Store Order

The best way to solidify notation knowledge is to draw a second example from scratch. Consider an online store's order validation process. The system receives an order, checks payment authorisation, and checks stock — two sequential decisions before confirming or rejecting the order.

Follow this procedure every time you draw an activity diagram:

1. Identify the trigger. What starts the flow? Here: "Customer submits order."
2. List the actions. Receive Order → Validate Payment → Check Stock → Confirm Order (or Reject Order).
3. Identify decisions. Payment authorised? Stock available? Each becomes a diamond with labelled guards.
4. Identify merge points. Where do alternative paths rejoin? Both rejection paths might merge into a "Notify Customer" action.
5. Draw start and end nodes. One filled circle at the top; one or more bullseyes at the bottom.

Decisions vs. Merges: Getting the Count Right

A decision diamond introduces branching: the token of control travels down exactly one of the outgoing paths based on the guard condition that evaluates to true. A merge diamond ends branching: it passes through whichever incoming token arrives — it does not wait for all paths, and it does not synchronise them (that would be a join bar, which you will study in the next lesson on swimlanes and parallel activities).

In the clinic diagram above, the merge node correctly reunites "Confirm Booking" (reached immediately) and the re-routed "Confirm Booking" (reached after the patient accepted an alternative date). Either path, but not both, will arrive at the merge. The merge simply passes it on to "Send Confirmation Email." If this were a join bar instead, the diagram would incorrectly imply that both paths must complete before sending the email — a logical impossibility for a single booking.

When to Use an Activity Diagram

Activity diagrams are the right choice when you need to model:

• A business process with multiple steps, actors, and decision points (use-case realisation).
• An algorithm or complex operation inside a system component.
• A process that involves parallel paths (covered in the next lesson when we add fork/join bars and swimlanes).
• A workflow you are redesigning — you draw the "as-is" diagram, then the "to-be" diagram and compare them.

Activity diagrams complement, rather than replace, sequence diagrams. A sequence diagram answers "in what order do objects exchange messages?" An activity diagram answers "what steps does the system take and what decisions does it make along the way?" For a library reservation system, you might draw a sequence diagram to show how the ReservationService calls the CatalogueRepository, and a separate activity diagram to show the full reservation workflow from patron request to shelf pick.

Summary

An activity diagram documents the flow of control through a process using four core building blocks: the initial node (filled circle) to start, actions (rounded rectangles) for work, decision nodes (diamonds with labelled guards) for branching, merge nodes (diamonds with multiple incoming edges) to rejoin branches, and the activity final node (bullseye) to end. Drawing correct guards on every decision edge, and choosing merge rather than join for exclusive branches, are the two habits that separate a readable, technically correct diagram from a confusing one. In the next lesson you will add swimlane partitions and fork/join bars to handle concurrent, multi-actor workflows.