Activity Diagrams

Introduction

Activity diagrams model workflows with decisions, forks, and parallel steps — useful when business logic branches heavily: ATM menu, order fulfillment, game turn sequence.

They resemble flowcharts but align with UML and object-oriented actions. In interviews, a quick activity diagram for 'withdraw cash' clarifies validation order before you assign methods to classes.

Use them when control flow is harder to explain than object ownership.

Understanding the topic

Key concepts

• Rounded rectangles for actions; diamonds for decisions.
• Initial and final nodes mark start/end.
• Fork/join bars for parallel activities.
• Swimlanes assign actions to actors or classes.
• Object nodes show artifacts produced (Ticket, Receipt).
• Can map each action to a method or service step.

flowchart TD
  Start --> CheckBalance
  CheckBalance -->|sufficient| DispenseCash
  CheckBalance -->|insufficient| Reject
  DispenseCash --> End

Step-by-step explanation

1. Identify start trigger (user inserts card).
2. Chain actions until first decision point.
3. Branch with labeled guards (valid PIN?).
4. Merge paths before end or next decision.
5. Optional swimlanes: User, ATM, BankHost.
6. Translate actions to sequence or class methods.

Syntax reference

Activity diagram elements:

• Map swimlanes to ATM, Bank, User.
• Parallel fork for dispense + log if independent.

(*) --> "Insert card"
"Insert card" --> "Validate PIN"
if "PIN ok?" then
  -->[yes] "Check balance"
  if "Sufficient?" then
    -->[yes] "Dispense cash"
    --> "Print receipt"
  else
    -->[no] "Show error"
  endif
else
  -->[no] "Retain card"
endif
--> (*)

Informative example

Withdraw workflow implemented as structured service method:

public final class WithdrawWorkflow {
    private final PinValidator pins;
    private final AtmService atm;

    public WithdrawWorkflow(PinValidator pins, AtmService atm) {
        this.pins = pins;
        this.atm = atm;
    }

    public Result execute(CardSession session, Money amount) {
        if (!pins.verify(session)) {
            return Result.failed("invalid pin");
        }
        if (amount.isZero()) {
            return Result.failed("invalid amount");
        }
        return atm.withdraw(session.account(), amount);
    }
}

Each activity node becomes a step or delegated call — keeps workflow readable without giant switch.

Real-world use

Real-world applications

• ATM and vending machine menu flows.
• Order pipeline with validation gates.
• Game loop and turn processing (Snake and Ladder).

Best practices

• Label decision guards clearly.
• Use swimlanes when multiple actors involved.
• Keep one level of abstraction per diagram.
• Link terminal actions to domain outcomes.
• Do not duplicate entire class diagram inside activities.

Common mistakes

• Activity diagram instead of class diagram for structure.
• Unlabeled decision branches.
• Missing merge after parallel fork.
• Too low-level — every getter as separate action.

Advanced interview questions

Summary

Activity diagrams model branching workflows. Decisions, forks, and swimlanes clarify complex logic. Map actions to service methods after diagramming. Complement class and sequence diagrams. Ideal for ATM menus and game flows.