Sequence diagram
Messages between user, interface, server and database, in time order.
What it explains and when it is useful
A sequence diagram shows one scenario as messages passed between participants over time, read from top to bottom. Combined fragments (alt, opt, loop) show alternatives and repetition.
When to use it: When the interaction between parts matters: a web request reaching a database, an app calling an API, objects co-operating in OOP, a client and server in a game.
Worked example
Illustrative: PracticePal is a fictional project used throughout this guide.
Scroll sideways to see the whole diagram.
Notation and legend
| Symbol or part | Meaning |
|---|---|
| Box or figure at the top | Participant (user, component or object) |
| Dashed vertical line | Lifeline: time runs downwards |
| Shaded bar | Activation: the participant is busy |
| Solid arrow | Request or call |
| Dashed arrow | Reply |
| alt frame | Alternatives; the condition is in brackets |
Design decisions it communicates
A diagram earns marks when you explain the decisions it shows. In PracticePal's documentation these would each be one sentence:
- Three rule checks run before the transaction, so most refusals never take the write lock.
- The browser receives a reason (409) rather than an error page, which becomes the message the user sees.
- Numbered messages match the SQL query design table (Q1–Q3).
Common mistakes
- Too many participants or messages: one scenario per diagram.
- No return messages.
- Using it instead of algorithms: it shows who talks to whom, not the logic inside.
Checklist for your own version
Ticks are saved in this browser only, so you can use the list while you draft.