Learning Objectives

  • Model a workflow using activity diagram notation including decisions and parallel flows
  • Explain the purpose of fork and join nodes
  • Compare activity and sequence diagrams and choose the appropriate type for a given scenario
1

Core Input

Read through each tab before working through the key concepts.

An activity diagram models a workflow or process as a flow of actions. Core elements:

  • Initial node — a filled black circle. The single starting point of the activity. Every activity diagram has exactly one.
  • Action node — a rounded rectangle containing the action name. Represents a discrete step in the process: Validate Payment, Send Confirmation Email, Update Inventory.
  • Decision node — a diamond shape. A single incoming flow splits into two or more outgoing flows based on conditions. Each outgoing flow is labelled with a guard condition in square brackets: [payment valid], [payment failed].
  • Merge node — also a diamond shape, but multiple incoming flows converge into one outgoing flow. Unlike a join node, a merge does not wait for all paths — it passes through whichever flow arrives.
  • Activity final node — a bullseye (filled circle inside a ring). Marks the end of the entire activity. All flows terminate here.
  • Flow final node — a circle with an X inside. Terminates one branch of the flow only — the rest of the activity continues.

Activity diagrams can model concurrent (parallel) processes using two specialised nodes:

  • Fork node — a thick horizontal (or vertical) bar with one incoming flow and multiple outgoing flows. The incoming flow splits into parallel branches that execute simultaneously.
  • Join node — a thick bar with multiple incoming flows and one outgoing flow. Waits until all parallel branches have completed before continuing.

Fork and join nodes always appear in pairs — every fork must eventually be joined.

Example: When an order is confirmed, three things happen in parallel: the payment is charged, the warehouse is notified, and the confirmation email is sent. Only when all three are complete does the flow continue to "Order Complete".

This parallel modelling capability is one of the main reasons to prefer an activity diagram over a sequence diagram for workflow scenarios.

Both sequence and activity diagrams model behaviour, but they answer different questions:

Sequence Diagram Activity Diagram
FocusWhich objects interact and in what orderThe steps and flow of a process
Central elementMessages between objectsActions and control flow
Parallel flowsLimited (par fragment)First-class (fork/join nodes)
Object focusYes — shows which class does whatNo — objects are optional (swimlanes)
Best forDetailed object interactions, API callsBusiness processes, workflows, algorithms
AudienceDevelopersBusiness analysts, managers, developers
2

Key Concepts: Activity Diagram Elements

Work through each item carefully — several elements look similar but have distinct meanings.

The initial node is a filled black circle. It marks where the activity starts.

  • Every activity diagram has exactly one initial node.
  • It has no incoming flows — only outgoing.
  • It does not represent an action — it is a control node that starts the flow.

If you find yourself drawing multiple starting points, you should ask whether you are modelling one activity or two separate activities that should be diagrammed independently.

Both are drawn as a diamond, but they serve opposite purposes:

  • Decision nodeone input, multiple outputs. The flow arrives and one of the outgoing paths is taken, based on guard conditions. Like an if/else or switch statement.
  • Merge nodemultiple inputs, one output. Different paths that were split by a decision node reconnect here. The merge does not wait for all inputs — it passes through whichever arrives.

A common modelling error is using a fork/join where a decision/merge is intended (or vice versa). The difference is critical: a fork starts parallel execution; a decision makes a choice.

Activity final node (bullseye — filled circle inside a ring): terminates the entire activity. All currently active flows stop when this node is reached. Use this to end the whole process.

Flow final node (circle with X inside): terminates one branch only. Other parallel branches continue unaffected. Use this when one parallel path ends early (e.g. an error in one thread) but the rest of the process should continue.

Example: In a parallel order process, if email delivery fails, a flow final node ends the email branch — but the payment and warehouse branches continue. An activity final node here would be wrong: it would terminate the entire order process.

Swimlanes (also called partitions) divide the activity diagram into vertical or horizontal lanes, each representing a different actor or system component. Each action is placed in the lane of the actor responsible for performing it.

Use swimlanes when:

  • Responsibility for different steps is shared across multiple people or systems
  • You want to show clearly who does what, without drawing a full sequence diagram
  • The audience includes business stakeholders who need to see their role

Swimlane activity diagrams bridge the gap between business process analysis and system design — they are readable by non-technical stakeholders while still being precise enough for developers.

3

Key Concepts: Parallel Flows and Diagram Choice

Parallel flows and the choice between diagram types are among the most important practical judgements in UML modelling.

This is one of the most commonly confused distinctions in activity diagrams:

  • Decision node (diamond) — the flow takes one of multiple paths. The paths are alternatives. Guard conditions make clear which path is taken. Think: if/else.
  • Fork node (thick bar) — the flow splits into all outgoing paths simultaneously. All branches execute in parallel. Think: thread.start().

A decision is exclusive: one path is taken, the others are not. A fork is inclusive: all paths are taken at the same time.

A join node (thick bar with multiple incoming flows) waits for all incoming parallel branches to complete before allowing the outgoing flow to continue.

This models synchronisation: the process cannot continue until every parallel activity is finished. In implementation terms, this corresponds to a barrier, a join() call on multiple threads, or a Promise.all() in JavaScript.

If some branches can finish early and the process should continue as soon as any branch finishes, that is a different pattern — not directly supported by standard activity diagram notation without additional annotations.

Choose an activity diagram when:

  • You are modelling a business process or workflow (not a technical interaction)
  • The process involves parallel or concurrent activities
  • The audience includes non-technical stakeholders
  • The process has complex branching logic (multiple decisions)
  • Object-level detail is not needed — you care about steps, not which class executes them

Choose a sequence diagram when:

  • You need to show which specific objects interact and in what order
  • You are specifying an API or interface between components
  • Message parameters and return values are important
  • The audience is developers implementing the interaction

Often, yes — the same use case can be modelled by both. They highlight different aspects:

  • A sequence diagram for a login process shows the exact messages between User, LoginController, and UserDatabase — useful for a developer writing those classes.
  • An activity diagram for the same login process shows the steps from a user perspective: enter credentials → validate → check account status → grant or deny access — useful for a business analyst or for specifying test cases.

In a well-designed model, both diagrams exist and are consistent with each other. Unit 8 explores how to check and maintain that consistency.

4

Watch

Video coming soon

5

Check Your Understanding

Select the best answer for each question.

In an activity diagram, which symbol splits a single flow into two or more parallel branches?

Correct! A thick horizontal bar is the fork node — it splits one incoming flow into multiple concurrent outgoing flows that execute simultaneously. A diamond shape is a decision node, which splits into alternative (not parallel) paths.
Not quite — review the material and try again. A thick horizontal bar is the fork node — it splits one incoming flow into multiple concurrent outgoing flows that execute simultaneously. A diamond shape is a decision node, which splits into alternative (not parallel) paths.

You need to model a checkout process where 'Charge Payment', 'Notify Warehouse', and 'Send Confirmation' happen simultaneously. Which diagram type is most appropriate?

Correct! Activity diagrams model parallel flows naturally using fork and join nodes. Sequence diagrams focus on ordered message exchanges between specific objects and are less suited to showing genuinely parallel processes. A use case diagram shows goals, not processes.
Not quite — review the material and try again. Activity diagrams model parallel flows naturally using fork and join nodes. Sequence diagrams focus on ordered message exchanges between specific objects and are less suited to showing genuinely parallel processes. A use case diagram shows goals, not processes.
6

Activities

Individual task

Choose a process from your group's system — something with clear steps and at least one decision point. Good candidates: placing an order, registering a new account, handling a support request.

Create an activity diagram that includes:

  • An initial node and an activity final node
  • At least four action nodes
  • At least one decision/merge pair
  • At least one fork/join pair showing parallel activities

Pair task

One partner takes the activity diagram from the individual task. The other partner models the same process as a sequence diagram (using the classes from Units 4–5).

Compare the two representations:

  • What information is clearly shown in the activity diagram that is hard to show in the sequence diagram?
  • What information is clearly shown in the sequence diagram that is absent from the activity diagram?
  • Is there any information that is inconsistent between the two?

Group task

Discuss: for your group's system, which process would you present using an activity diagram if talking to a business analyst, and which would you present using a sequence diagram if talking to a developer implementing a feature?

  • Choose one process for each scenario and justify the diagram choice.
  • If time allows, produce both representations for one process and compare them side by side.

Review

  • Initial node — filled circle (start)
  • Action node — rounded rectangle (a step)
  • Decision node — diamond with guard conditions (choice)
  • Merge node — diamond joining alternative paths
  • Fork node — thick bar splitting into parallel branches
  • Join node — thick bar synchronising parallel branches
  • Activity final node — bullseye (end of whole activity)
  • Flow final node — circle with X (end of one branch)

Activity diagrams show what happens in a process — the steps, decisions, and flows. Sequence diagrams show how objects implement those steps — the messages that flow between specific classes.

Together, they give a complete behavioural picture: the activity diagram provides the process overview; the sequence diagram provides the technical detail. In Unit 8, you will check that these two types of diagram — along with the structural diagrams — are consistent with each other.

Proceed to Unit 8: Integrating UML when ready.