From the static structure to the system in motion: who sends which message to whom, and in what order, for one scenario of one use case.
Move with the arrow keys or the buttons below.
The class diagram told us what exists: the cast of objects, their data and operations. A sequence diagram shows what happens: those objects exchanging messages, in time order, to carry out one scenario.
Class and sequence are two views of the same objects. The class diagram is the system at rest; the sequence diagram is the same cast in motion for a single run. The lifelines you draw here are instances of the classes you drew there, and the messages are their operations.
Before the details, a complete sequence diagram for one scenario: a doctor viewing a patient record, where access depends on authorisation. Do not decode every mark yet, the rest of the deck explains each labelled part.
Four participants across the top, each with a dashed lifeline and a grey activation bar when busy; messages as arrows (solid = a call, dashed = a return); time running top to bottom; and an alt fragment splitting the flow on a guard, [authorised] versus [else]. Each part gets its own slide next.
A sequence diagram models the interactions between the actors and objects of a system as a time-oriented view: it shows the order of messages exchanged during one particular use case, or one instance of it. Participants are listed across the top with a dashed line dropping from each; interactions are annotated arrows; the diagram is read left to right and top to bottom.
Draw a sequence diagram for a scenario whose call order is not obvious, or where the collaboration between several objects needs pinning down: a checkout, an authorisation, a booking. It is how you catch a forgotten return, a missing error path, or a message sent to an object that has no such operation, before any code exists.
A sequence diagram does not invent anything. It realises one scenario of a use case, using the classes from the class diagram, calling their operations.
| In the sequence diagram | Comes from |
|---|---|
| The scenario being drawn | one path through a use case (its normal flow, or one alternative) |
| The participants (lifelines) | actors and objects , the objects are instances of classes from the class diagram |
| The messages | the operations declared on those classes |
| The fragments (alt, loop) | the decisions and loops of the activity diagram for that use case |
If a lifeline receives a message fetchRecord(), the class it instantiates must declare fetchRecord(). The sequence diagram is therefore a powerful check on the class diagram: a message with no matching operation means the class model is incomplete.
The box names the participant (: Class for an anonymous object, name : Class for a named one). The dashed lifeline drops from it; the thin activation bar marks the stretch of time it is busy handling a message. An actor (an external participant such as the Customer or Librarian) gets no activation bar; we do not model its internal execution. Only the system objects that execute a message are barred.
Synchronous (filled head): the caller waits for the reply. Reply / return (dashed, open head): the answer coming back. Asynchronous (open head, solid line): fire and continue, no waiting. A message back to the same lifeline is a self-message.
Adel draws the distinction clearly. A plain sequence diagram is an instance: one possible run, with no branching, the “happy path”. But a use case has many scenarios, so we often need to show conditional behaviour and iteration too.
One concrete sequence of messages, start to finish, no choices. Quick to draw, easy to read, ideal for explaining the normal flow (like the ATM deposit on the next slide).
Shows the family of runs that can occur, using combined fragments (alt, opt, loop) to fold the alternatives and repetitions into one picture, like the authorisation alt in the opening diagram.
Draw the instance first to nail the normal flow, then promote it to a generic diagram only where real branching or looping matters. Do not cram every error path into one diagram, that is what fragments, or separate diagrams, are for.
A combined fragment is a boxed region of the diagram with an operator label in the top-left corner. It is how a generic diagram expresses choice and repetition.
| Operator | Meaning |
|---|---|
opt | Optional. The fragment runs only if its guard is true. Equivalent to an alt with a single branch. |
alt | Alternatives. Two or more branches separated by dashed lines, each with a guard; exactly one runs per pass. |
loop | Loop. The fragment may run zero or more times; the guard is the iteration condition. loop(n) for exactly n times. |
par | Parallel. Two or more branches run concurrently; the order between them is unspecified. |
ref | Reference. Stands for another sequence diagram, so a shared sub-interaction is not redrawn each time. |
The “at a glance” diagram uses an alt: the guard [authorised] runs the fetch-and-display branch, and [else] runs the error branch. Exactly one of the two executes. An opt would be the same box with a single guarded branch and no [else].
Adel's self-service-machine example, the normal scenario. Three internal objects do the work: the front (the customer interface), the register (where money is counted and the cash reserve kept), and the dispenser (which delivers the receipt).
The normal deposit scenario. On screen, use Next and Prev to step through it message by message; watch each activation bar appear as its participant becomes busy.
The same Library we modelled with a use case, an activity diagram and a class diagram, now in motion for one scenario. The lifelines are objects of the classes LibraryMember, BookCopy and Loan; the messages are their operations; the alt is the activity's “limit reached?” decision.
borrow(c) on the member object m (the borrow() operation from the class diagram).m runs a self-message checkAllowance() to see whether the member is under the six-item limit.m calls issue() on the copy c, which sets its status and returns onLoan; m then creates a new Loan object (the «create» message, whose lifeline begins where it is created); finally m returns “loan recorded” to the Librarian.m returns “loan refused” and nothing is issued or created.Loan object's dates are set at creation, exactly the association class from the class diagram.alt, opt, loop).alt / opt / loop (a generic diagram) or separate diagrams for the rest.fetchRecord() to a lifeline whose class has no such operation, fix the class diagram or the message.loop fragment.Use case (who and what) , activity (how one task flows) , class (what exists) , sequence (what happens between objects, over time). Each answers a different question about the same system; together they are the working core of UML for analysis and design.
Sources: A. Taweel, COMP433 Chapter 4 (UML) lecture notes (ATM “Deposit Cash” and MHC-PMS examples); Sommerville, Software Engineering 10th ed.; UML 2.x specification (combined fragments). Companion: COMP433_Ch4_UML_System_Modelling_Companion.html, section 11.