Use Case, Sequence, Activity: Which Diagram Answers Which Question

Eleven questions asked of one published case, routed to the UML diagram that can answer each. Seven go to no diagram at all.

Numbers in this note carry source tags ([POLICY], [THREADS n=10], [MINE]). What the tags mean.

This piece stands on the returns case published on this site: damaged-delivery refunds at a mid-size online retailer, built only from public sources - a published returns policy, help centre articles, ten public complaint threads I selected myself, consumer law and a walk through the published customer journey. No client, no interviews, no internal document. I start from the questions, not the notation: the case records five review objections and six open questions, and I route each to the diagram that could answer it. The routing and the counts are mine [MINE], and you can redo them from the published case.

Choosing a UML diagram means naming what the question is about. Who wants what from the system is a use case diagram. Which steps happen in which order, who does each one and where the path splits is an activity diagram. Who sends what to whom, and in what order over time, is a sequence diagram. Which condition one record can be in, and what event moves it, is a state machine.

In short

• Pick the diagram from the question, not from the notation. Four behaviour diagrams carry the questions in this case: use case, activity, sequence and state machine.
• Of the eleven questions asked of the returns case, one goes to a use case diagram, one to an activity diagram, two to a sequence diagram, none to a state machine, and seven to no diagram at all [MINE].
• The seven are about owners, values and measurement. A diagram can show where such a question sits, not answer it.
• The state machine is the one diagram no question asked for, and drawn from the register it finds two gaps.

What does each diagram actually answer?

The definitions are short, and each one already names the question. Wikipedia describes a use case diagram as "a graphical depiction of a user's possible interactions with a system". An activity diagram is a graphical representation "of workflows of stepwise activities and actions with support for choice, iteration, and concurrency". A sequence diagram "shows process interactions arranged in time sequence", with messages drawn "in the order in which they occur". And in a UML state machine, "the response to an event generally depends on both the type of the event and on the internal state of the system".

The notation itself is defined by the Object Management Group in UML 2.5.1, published December 2017. This piece uses four of its diagram types, and the question is which one to open.

The last column matters as much as the second. A question asked of the wrong diagram does not fail loudly. It gets a picture that looks like an answer.

The eleven questions, routed

The questions are not mine: five logged objections from the review sessions on 2 and 6 April 2026 (RL-01 to RL-05), and six open questions from the register (OQ-01 to OQ-06). For each I asked: is it about goals, steps, messages, states, or something no drawing holds?

One use case, one activity, two sequence, zero state machine, seven no diagram [MINE]. That is a count of these eleven, not a rule about projects.

Two routings are arguable. OQ-02 could go to a state machine, because the case says "a target with no breach state is a wish with a number in it", and a state diagram shows whether a "breached" state exists. But it can only draw both versions; which one is true belongs to the Head of Customer Care. OQ-04 could go to an activity diagram with a timer. I put it in sequence because the problem is a message arriving at a participant who may not exist on a Sunday.

Three diagrams, each drawn for its question

Each is drawn only from named lines in the case.

Use case diagram, for RL-04

Actors outside the box, goals inside it, and the goals the case decided to leave out drawn outside on purpose.

The fifth row is the objection: before review, that goal had no line anywhere in the case. The case fixed it in the scope section, and a use case diagram shows the gap at a glance: one actor, two goals, one with a place to go. A diagram that draws only the ovals inside the box hides it again.

Activity diagram, for RL-01

The case's as-is model in section 3.1 is drawn as a flow. The objection was that the first version had one ending. The fix is what an activity diagram is built to show: a decision with two outgoing paths, and an end nobody wants.

Customer calls                     [WALKTHROUGH]
  -> Agent asks for photos by email  [HELP]
  -> < Evidence enough? >            no written test [WALKTHROUGH]
       YES -> Refund issued
       NO  -> CASE PARKED: no owner, no clock
              -> Customer chases, thread restarts  [THREADS n=10]
              (parked branch, frequency unknown, flagged for measurement)

Template 2 in the pack gives the conversion rules: every actor becomes a lane, every exception a gateway, and every ending an end event, "including the ones nobody wants". RL-01 is a question about the shape of the path, so an activity diagram answers it. It does not answer RL-03, even with the frequency label sitting on it: the label says where the count came from, and the drawing has no opinion about it.

Sequence diagram, for RL-02 and OQ-04

The to-be, as messages between participants, in the order they happen.

Participants: Customer, Form, Pre-check, Agent, Duty owner

1. Customer -> Form:        submit with photos     (t0 = form timestamp)
2. Form -> Pre-check:       case with evidence
3a. Pre-check -> Customer:  approved under BR-04 and BR-11
3b. Pre-check -> Agent:     passed on, with the reason it stopped
4. Agent:                   opens the case
5. at t0 + 48 h, no decision -> Duty owner:  assigned, due date written
6. -> Customer:             one message naming who holds it, and by when

RL-02 asked which of two moments starts the clock. On a sequence diagram they are two different arrows: the customer's submit, and the agent opening the case. REQ-014/2 now names the first, "the timestamp on the submitted form, not the moment an agent opens it". The diagram does not choose; it shows that there are two.

OQ-04 is the same diagram read for one scenario from section 3.5: submitted at 23:50 on a Friday, due at 23:50 on Sunday. Message 5 points at a duty owner, and whether that participant exists at the weekend is the open question, now a missing lifeline rather than a footnote. The answer belongs to the Head of Customer Care. The 48 hours are [MINE], as everywhere in the case.

Why did no question ask for a state machine?

One likely reason [MINE]: the process models and the register are written as steps, so they prompt step questions. Yet the register describes one thing, the case, moving through conditions, and five of its lines describe a transition:

A state machine drawn from these five lines has a state with no way in (closed) and a transition with no trigger (customer reopen). The data model piece found the same two gaps from the database side, as U5 and U6. The state diagram finds them from the behaviour side, as a box with no incoming arrow.

That is the lesson of the zero in the routing table: nothing in the case was drawn as states, so nobody asked a state question. The diagram for the question nobody asks has to be drawn on purpose.

What about the seven questions no diagram answers?

They are where the case's decisions live: the reason behind a threshold (RL-05), the owner of two rules (OQ-03), a legal retention period (OQ-01), a release decision (OQ-05), a measurement nobody can take from outside (OQ-06). Each open question has an owner slot, a due date and a fallback in the register; for OQ-03 the slot reads "Unknown", because the owner is the question. None gets easier with a drawing.

The failure to watch for is the diagram as a holding pattern. A meeting that cannot answer "who owns BR-11?" can always produce another swimlane, and it will look like progress. A question about a value, a person or a number goes to the open questions register with an owner, which is scorecard check 05. The diagram can mark where the answer will land, not stand in for it.

The diagram routing sheet, filled in

One sheet per question. This is RL-02, filled from the case.

The "cannot settle" row pays for the sheet: it lists what the diagram leaves behind.

The diagram routing sheet, blank

Where does this method stop?

It routes questions. It does not tell you whether the drawing is right; only someone who does the work can. It is also biased towards the questions you already have, which is why the state machine gap showed up only when I went looking for the diagram nobody asked for. Do that pass on purpose, once for each of the four.

The scope question comes before any of these, and the context diagram answers it. The exceptions a use case has to carry are in writing a use case. The full process models, the register and the review log the eleven questions come from are at /case, the tags are explained on the method page, and checks 03, 05, 09 and 12 of the scorecard are the ones a diagram in a work sample has to pass.

All field notes · The portfolio guide · More in The Case File