skip to content

How do you choose which UML diagram to draw for a given modelling question?

level: middleimportance: must knowfreq 56%

answer

  1. Begin with the question, not the notation
  2. Name the unknown before choosing
  3. Arrangement, ordering, or lifecycle?
  4. One diagram answers one question
  5. No question means no diagram

basics

~20 s

Start from the question, not the notation. Say in one sentence what you need to know — what the parts are, in what order they interact, or what one object's lifecycle permits — then draw the family that answers it.

solid answer

~50 s

I phrase the unknown as one sentence with a verb in it, then classify it. If the answer is an arrangement — what parts exist, what binds them, what runs where — it lives in the **structural** half, so a class, object or deployment diagram. If the answer is an ordering or a triggering — who sends what to whom in what order, which steps a process runs through, what may happen to one object across its life, who wants what from the system — it lives in the **behavioural** half, so an interaction, activity, state machine or use-case diagram. Then I draw the narrowest diagram that answers the sentence and nothing else. If I cannot phrase the question, that is the signal not to draw at all: a diagram with no question behind it has no reader either.

go deeper

for a junior

Learn the mapping in the everyday direction: what the parts are is a class diagram, who talks to whom in what order is a sequence diagram, what one object may go through is a state machine diagram.

for a middle

Be ready to walk the method aloud — phrase the question, pick the half, pick the narrowest diagram — and to justify a choice when two candidates from the same half both look plausible.

for a senior

Demonstrate the discipline of refusing to draw. An interviewer at this level wants to hear when you decided a sentence, a measurement or a short read of the code answered the question better than any diagram would.

for a principal

Be able to argue for the choosing rule as a team habit rather than a personal one, including what it saves: fewer diagrams, drawn deliberately, that a reviewer can check against the question they were drawn to settle.

## Start from the unknown, not from the notation The reliable method has one step before any drawing: **say out loud, in one sentence, the question the diagram has to answer.** If that sentence will not come, no diagram will help, because a diagram is an answer and you have not yet got a question. Only once the sentence exists do you ask which half of UML answers questions of that shape — arrangement, which is structural, or ordering and triggering, which is behavioural — and inside the chosen half there are only a handful of candidates, each obviously about something different. Three question shapes cover most real design conversations, and they map cleanly: | The question actually being asked | Half | Diagram to draw | What it will not tell you | | --- | --- | --- | --- | | What parts are there, and what rules bind them? | Structural | Class diagram | Nothing about ordering or timing | | For this one confusing case, which instances exist and how are they linked? | Structural | Object diagram | Nothing that generalises beyond that snapshot | | Who runs where, and what is co-located? | Structural | Deployment diagram | Nothing about the logic inside anything | | Who talks to whom, in what order, for this scenario? | Behavioural | Sequence or other interaction diagram | Nothing about what other scenarios may do | | Through which steps and decisions does one process run? | Behavioural | Activity diagram | Nothing about which object owns each step | | What can happen to one object across its whole life? | Behavioural | State machine diagram | Nothing about who triggers a transition from outside | | Who wants what from the system at all? | Behavioural | Use-case diagram | Nothing about how any of it is done | ## Applying the method under pressure 1. **Write the question as a sentence with a verb.** *In what order do these three parts settle a payment* is answerable; *document the payment subsystem* is not a question and produces a diagram no one reads. 2. **Classify the sentence.** Does the answer take the shape of a noun-like arrangement, or of an ordering over time? That picks the half and eliminates most of the taxonomy in one move. 3. **Pick the narrowest diagram in that half that answers it.** Narrow beats complete: a diagram covering one scenario with five participants is read; one covering everything is skimmed. 4. **Draw only what the question needs.** Every element that is not part of the answer is noise the reader must decide about. 5. **Check the answer is legible in the drawing.** Read the diagram back as a sentence. If the sentence you get is not the question you wrote in step one, the notation choice was wrong, not the drawing. ## Two diagrams, or one? A single question needs a single diagram. Two genuinely different questions need two, and they will often fall in different halves — what participates, and what happens between the participants. The failure mode is not drawing two diagrams; it is drawing one diagram that tries to answer both, which usually means a structural picture with arrows annotated in a numbered order. That hybrid answers the ordering question badly and hides the structural rules, and reviewers argue about the notation instead of the design. The opposite failure is fan-out: a request for one clarification turns into a set of diagrams because the taxonomy has that many entries. The taxonomy is a menu of answers, not a checklist to complete. ## When the honest answer is no diagram - **The answer fits in a sentence.** If *the scheduler calls the notifier once per day, after the roll-up completes* settles it, write that sentence and move on. - **The question is about a value, not a shape.** How long something takes, or how often it fails, is measured rather than drawn. - **The question is already answered by one small unit of code that both people can read** in less time than the drawing would take. - **Nobody in the room disagrees.** Diagrams earn their keep where there is ambiguity or disagreement. Drawing what everyone already agrees on is documentation theatre. ## Why this beats picking a favourite notation Most weak modelling comes from the reverse order: someone reaches for the diagram type they are most fluent in and fits the question to it. That is how a class diagram ends up being offered as the answer to an ordering question, with the ordering smuggled into method names, and how a scenario diagram ends up being offered as proof that a lifecycle rule holds. Choosing from the question keeps the notation subordinate to the design conversation, and it makes the diagram disposable in a healthy way: when the question is settled, the diagram has done its job, and whether it survives is a separate decision.

  • A stakeholder on a language-learning app asks what happens when a learner's daily streak resets at midnight. Which diagram do you draw?
    It depends on which answer they want, and I would ask. If the answer names participants and an order — the scheduler, the streak record, the notifier — it is an interaction diagram. If the answer is about what a streak may legally be and which transitions between those lifecycle states are allowed, including whether a reset streak can be restored, it is a state machine diagram over the streak itself.
  • When is the honest answer no diagram at all?
    When nobody disagrees, when a sentence settles it, when the question is about a measured value rather than a shape, or when both people can read the relevant unit of code faster than the drawing would take. Diagrams pay for themselves where there is ambiguity; drawing what the room already agrees on is documentation theatre.
  • What goes wrong when someone answers an ordering question with a structural diagram?
    The ordering gets smuggled in as numbered arrows or suggestive method names, so the diagram makes a claim its notation cannot support and readers argue about interpretation. It is also unfalsifiable: nothing in a structural diagram can be wrong about sequence, so a genuine ordering defect passes review unnoticed.

saying these in an interview costs you the question

  • Picks the diagram they know best, then fits the question to it
  • Draws a class diagram for every question asked
  • Thinks more diagram types means a better design document
  • Cannot say what question their own diagram answers
  • Models the whole system when one interaction was asked about
  • Numbers the arrows on a structural diagram to imply ordering