Other UML Diagrams

Learning Objectives

Know the purpose of each UML diagram type and when to use it.

Draw sequence, activity, state-machine and component diagrams.

Prerequisites: Module 23.

Intuition and Definition

actors and the goals they achieve with the system a snapshot of objects and links at one moment explaining a tricky structure (cycles, sharing) messages between participants over time designing an interaction or protocol the same messages, arranged by links rarely — sequence is usually clearer workflow with decisions, forks and joins business processes, algorithms State machine states and transitions of one object lifecycle (order, connection, vehicle mode) deployable/replaceable parts and their interfaces nodes (servers, ECUs) and what runs where infrastructure, embedded topologies grouping and dependencies of packages state changes along a time axis real-time and hardware interactions activity diagram whose nodes are interactions very large scenarios

Why It Matters

Different questions need different views: "what talks to what, in what order?" (sequence), "what states can this be in?" (state machine), "where does it run?" (deployment).

Syntax and Language Notes

Mermaid supports sequence diagrams and flowcharts directly; state machines can be drawn as flowcharts with states as nodes.

Complete Example

A sequence diagram for a diagnostic request through a gateway:

A state machine for an order, and code that enforces exactly those transitions:

An activity diagram for checkout (drawn as a flowchart):

A deployment view of a vehicle (drawn as a flowchart with clusters):

sequenceDiagram
  participant T as Tester
  participant G as Gateway
  participant E as EngineECU
  T->>G: ReadDTC request
  G->>E: forward request
  E-->>G: 2 DTCs
  G-->>T: response
  Note over T,E: timeout 50 ms per hop

flowchart LR
  New -->|pay| Paid
  New -->|cancel| Cancelled
  Paid -->|ship| Shipped
  Paid -->|cancel| Refunded
  Shipped -->|deliver| Delivered

#include <iostream>
#include <map>
#include <string>
#include <utility>

enum class S { New, Paid, Shipped, Delivered, Cancelled, Refunded };
const char* name(S s) {
    switch (s) {
        case S::New: return "New"; case S::Paid: return "Paid"; case S::Shipped: return "Shipped";
        case S::Delivered: return "Delivered"; case S::Cancelled: return "Cancelled"; case S::Refunded: return "Refunded";
    }
    return "?";
}

class Order {
    S state_ = S::New;
    static const std::map<std::pair<S, std::string>, S>& table() {
        static const std::map<std::pair<S, std::string>, S> t{
            {{S::New, "pay"}, S::Paid},        {{S::New, "cancel"}, S::Cancelled},
            {{S::Paid, "ship"}, S::Shipped},   {{S::Paid, "cancel"}, S::Refunded},
            {{S::Shipped, "deliver"}, S::Delivered}};
        return t;
    }
public:
    bool fire(const std::string& event) {
        auto it = table().find({state_, event});
        if (it == table().end()) { std::cout << "  '" << event << "' not allowed in " << name(state_) << "\n"; return false; }
        std::cout << "  " << name(state_) << " --" << event << "--> " << name(it->second) << "\n";
        state_ = it->second;
     
…

'ship' not allowed in New
  New --pay--> Paid
  Paid --ship--> Shipped
  'cancel' not allowed in Shipped
  Shipped --deliver--> Delivered

flowchart TD
  A[Cart submitted] --> B{Items in stock?}
  B -->|no| C[Show out-of-stock]
  B -->|yes| D[Reserve stock]
  D --> E[Charge payment]
  E --> F{Payment ok?}
  F -->|no| G[Release stock]
  F -->|yes| H[Create order]

flowchart LR
  subgraph Cluster[Instrument cluster ECU]
    UI[Display software]
  end
  subgraph Gateway[Central gateway]
    R[Routing + diagnostics]
  end
  subgraph Engine[Engine ECU]
    M[Engine control]
  end
  M -->|CAN 500 kbit/s| R
  R -->|CAN FD| UI

Step-by-Step Walkthrough

The sequence diagram reads top to bottom: solid arrows are requests, dashed arrows responses.

The state diagram is the single source of truth for allowed transitions; the code's table mirrors it, so "ship" before "pay" and "cancel" after shipping are rejected, while the legal sequence pay → ship → deliver goes through.

The activity diagram captures decisions and compensating actions (release stock when payment fails).

Common Mistakes

Sequence diagrams with every getter call — show the meaningful messages.

State machines with implicit transitions in code (status = "shipped" anywhere) — enforce transitions in one place.

Mixing levels of abstraction in one diagram (servers and individual functions).

Trade-offs and Alternatives

UML is a vocabulary, not a process. Many teams use C4 diagrams (context, container, component, code) for architecture and only sequence/state diagrams from UML.

Real-World Use

Protocols (diagnostics, payment flows), device lifecycles (ignition states, connection managers), and workflow engines are specified with sequence and state diagrams; deployment diagrams document which software runs on which ECU or server.

Practice

Q1. (Easy) Which diagram shows the order of messages between objects?

Answer: Sequence diagram.

Q2. (Medium) Which diagram would you draw for the lifecycle of a TCP-like connection?

Answer: A state-machine diagram (Closed → Connecting → Open → Closing → Closed, with error transitions).

Q3. (Advanced) Add a "return" event that moves a Delivered order to Refunded within the code above, and show it being accepted only from Delivered.

Answer: Add {{S::Delivered, "return"}, S::Refunded} to the table. fire("return") then succeeds only when the state is Delivered; from any other state the lookup fails and the event is rejected — the table remains the single source of truth.

Interview Question

Q1. "Which UML diagrams do you actually use, and why?" Answer: A good answer is pragmatic: sequence diagrams to design and review interactions (APIs, retries, timeouts), state machines for anything with a lifecycle, class diagrams for module-level structure during design discussions, and deployment/component (or C4) views for architecture documentation — all as diagrams-as-code next to the source. Use-case and communication diagrams are rarely worth the effort.

Quick Quiz

Q1. Which diagram shows where software runs?

Answer: Deployment diagram.

Q2. Which diagram is best for a business workflow with decisions?

Answer: Activity diagram.

Q3. What does a dashed arrow usually mean in a sequence diagram?

Answer: A return/response message.

Summary

Each UML diagram answers one kind of question; sequence and state diagrams are the most used.

Keep diagrams focused and consistent with code (enforce state machines in one table).

Related: Modules 23, 25, 43 (State pattern).