subroute.
Beginner13 min readUML & Diagramminglive prototype

Activity Diagrams

An activity diagram is a flowchart for a workflow: it shows the steps, the decisions, and the parallel paths from start to finish — so you can read the whole logic of a process at a glance.

The idea

What it is

An activity diagram is a flowchart for a process. You draw the steps of some workflow, the decisions that send it down one path or another, and the points where work happens in parallel — all the way from a clear start to a clear finish. If a class diagram answers “what are the pieces?”, an activity diagram answers “what happens, in what order, and when do things branch or run at the same time?”

Think of a recipe. Preheat the oven. Mix the batter. Is the oven hot yet? If yes, bake; if no, wait. While it bakes, wash up. That's an activity diagram in words: a sequence of steps, a yes/no decision, and two things happening at once. Or picture the flowchart of “what happens when you place an order online” — that is exactly the kind of thing this diagram draws.

The one sentence to remember

An activity diagram = the flow of a workflow: a start, a chain of actions (rounded boxes), decision diamonds that branch, and fork/join bars for things that run in parallel — ending at a final node. Read it top to bottom like a flowchart and you've read the whole process.

Mechanics

How it works

The shapes, one at a time

An activity diagram is built from a small, fixed set of shapes. Each shape has one meaning. Learn these six and you can read any activity diagram — the workflow just connects them with arrows.

  • Start (initial node) — a filled black circle ●. Every diagram begins here. There's exactly one.
  • Action — a rounded rectangle. One step of work, e.g. Charge payment. Most boxes in the diagram are actions.
  • Control flow — an arrow from one node to the next. It shows the order: do this, then that.
  • Decision — a diamond ◇ with one arrow in and two (or more) arrows out. Each outgoing arrow has a guard in square brackets like [in stock] or [out of stock]. The flow takes the branch whose guard is true.
  • Merge — a diamond that does the opposite: several arrows come in, one goes out. It rejoins branches that split earlier. (Same diamond shape, used to gather paths back together.)
  • Fork / Join — a thick black bar. A fork has one arrow in and several out: the flows after it all happen in parallel. A join has several arrows in and one out: it waits for all parallel flows to finish before moving on.
  • End (final node) — a filled circle with a ring ◉. The workflow stops here. You can have more than one (e.g. one for success, one for the out-of-stock path).

How they fit together

Here is the online-order workflow from the prototype, drawn in text. Read it top to bottom, following the arrows:

Add item to cart Checkout [in stock?] [in stock] [out of stock] Notify out of stock Charge payment fork Send confirmation email Reserve inventory join Ship order
Read it top to bottom: ● start, each rounded box is an action, the ◇ diamond is a decision with guards [in stock] / [out of stock], the thick bar is a fork/join for parallel work (Send confirmation email and Reserve inventory run at once), and ◉ is an end.

Decision vs fork — don't mix them up

A decision (diamond) chooses one path — either this branch or that one, based on a guard. A fork (bar) takes all paths at once — both this and that, in parallel. Diamond = a question with an or answer. Bar = an and: everything after it runs together.

Guards: the labels on a decision's branches

The little labels in square brackets — [in stock], [out of stock], [amount > 0] — are guards. A guard is the condition that must be true to take that branch. Guards on a single decision should cover every case and not overlap, so the flow always has exactly one way to go. They map straight to the conditions in an if/else in code.

Optional: swimlanes (who does what)

Sometimes you split the diagram into vertical columns called swimlanes (or partitions), one per actor — Customer, Payment Service, Warehouse. Each action sits in the lane of whoever performs it. The arrows still flow the same way; the lanes just add the who. Use them when the workflow crosses several people or systems and that ownership matters.

Activity diagram vs sequence diagram

These two get confused. An activity diagram shows the whole workflow's logic — its steps, branches, and parallel paths — without caring much which object does each step. A sequence diagram shows messages between specific objects over time (object A calls object B, which calls C). Use an activity diagram for “what is the flow of this process?” and a sequence diagram for “who calls whom, in what order?”

Interactive prototype

See it. Build it. Break it.

A sandboxed, hands-on simulation — no setup, no install. Play with it as you read.

About this simulation

One clean stage holds a real workflow — placing an online order — drawn top to bottom: a start circle, a few action boxes, a decision diamond, and a fork that splits into two parallel actions. Press Next to walk a glowing token along the flow one node at a time; at the decision you pick in stock or out of stock to see the two different paths. A single fixed note panel is rewritten each step to explain that node's shape and meaning, so nothing scrolls away or grows the page.

Hands-on

Try these yourself

Open the prototype above, predict what happens, then verify.

try 01

Walk the happy path

Open the prototype and press Next repeatedly. Watch the glowing token move ● → Add item to cart → Checkout → the decision diamond. When you reach the decision, click in stock, then keep pressing Next. Notice the token reach the fork bar and light up both Send confirmation email and Reserve inventory at once — that's parallelism — before joining and ending at Ship order → ◉.

try 02

Take the other branch

Restart and step to the decision again, but this time click out of stock. Follow the token down the short branch to Notify out of stock → ◉. You just traced both guarded paths of the same diamond. Say out loud: one diamond, two guards, the flow takes whichever guard is true.

try 03

Name every shape

Step through once more and, at each node, read the note panel and name the shape before it tells you: filled circle = start, rounded box = action, diamond = decision with guards, thick bar = fork/join = parallel, ringed circle = end. If you can name all six without help, you can read any activity diagram.

In practice

When to use it — and what trips people up

When to reach for an activity diagram

Draw one whenever the interesting thing is the flow, not the structure: a business process (signing up, checking out, approving a refund), a complex method whose branches are hard to follow in prose, or any algorithm where work splits into parallel steps and joins back. It's also the friendliest UML diagram for non-coders — a product manager or analyst can read a flowchart of branches and arrows without knowing any code.

Great for parallel work and business logic

Use an activity diagram to model a business process, to untangle a tricky method's branching logic, or to show where work happens concurrently (the fork/join bars make parallelism obvious). When you need to explain an algorithm's branching to people who don't read code, this is the diagram to draw.

What it gives you

  • Reads like a flowchart — almost anyone, technical or not, can follow it.
  • Shows branching and parallelism clearly, which plain text and class diagrams cannot.
  • Maps cleanly to code: decisions become if/else, forks become parallel tasks.
  • Great for modelling whole business processes end to end, not just one class.

Common mistakes

  • Shows the flow of a process, but not which objects exchange which messages (that's a sequence diagram).
  • Gets messy fast for big workflows — too many branches and forks turn into spaghetti.
  • Easy to drift from the code: a detailed diagram goes stale as the logic changes.
  • It models control flow, not data structure — you still need class/object diagrams for the shape of the data.

Reference

Code & further reading

A minimal reference implementation and pointers worth bookmarking.

// The activity diagram becomes this function.
// Each action box → a statement; the decision diamond → an if/else;
// the fork → two tasks started together (await Promise.all = the join).

async function processOrder(order: Order): Promise<void> {
  addItemToCart(order);   // action: Add item to cart
  checkout(order);        // action: Checkout

  // ◇ decision diamond — guards [in stock] / [out of stock]
  if (inStock(order)) {
    chargePayment(order); // action: Charge payment

    // ━━ FORK ━━ : these two run in PARALLEL
    await Promise.all([
      sendConfirmationEmail(order), // parallel action
      reserveInventory(order),      // parallel action
    ]); // ━━ JOIN ━━ : wait for BOTH before continuing

    shipOrder(order);     // action: Ship order
  } else {
    notifyOutOfStock(order); // action on the [out of stock] branch
  }
  // ◉ final node — the function returns
}

References & further reading

5 sources

Knowledge check

Did it land?

Quick questions, answers revealed on submit. Sign in to save your best score.

question 01 / 05

In an activity diagram, what does a thick black bar (a fork) mean?

question 02 / 05

What is the [in stock] label on an arrow coming out of a decision diamond called?

question 03 / 05

What is the difference between a decision diamond and a fork bar?

question 04 / 05

How is the start (initial node) of an activity diagram drawn?

question 05 / 05

Which question is best answered by a sequence diagram rather than an activity diagram?

0/5 answered