In a UML sequence diagram, what does a lifeline represent and what does its activation bar show?
answer
- One participant, one vertical line
- Down the page means later
- The bar means actively executing
- Instance, not class
- Stacked bars mean nested behaviour
basics
~20 sA lifeline is one participant in the interaction — an object, component or actor — drawn as a labelled box above a dashed vertical line down which time runs. The activation bar marks the stretch where that participant is actively executing.
solid answer
~50 sA **lifeline** names one participant and gives it a vertical dashed line. The whole diagram reads top to bottom as elapsed time, so the vertical axis is **ordering, not duration**, and horizontal position means nothing. The **activation bar** — formally an *execution occurrence* — is the narrow rectangle drawn on top of that dashed line while the participant is doing something. It starts when a message arrives that begins the behaviour and ends when the behaviour finishes, which for a synchronous call is the point the participant replies. Bars stack: if a participant starts a second behaviour while the first is still running, a second bar is drawn offset on top of the first, so nesting depth is visible without reading a label. A lifeline is a participating **instance**, not a class — two instances of one class get two lifelines.
code
pseudocode · 8 linesvisitor kiosk dispenser
| | |
|--buy(2)------>|[bar starts] |
| |--validate()------->|[bar starts]
| |<- - - ok - - - - - |[bar ends]
| |--audit() --. |
| |<-----------' [nested bar]
|<- - ticket - -|[bar ends] |go deeper
Be ready to point at a lifeline, an activation bar and the time axis on a printed diagram and say what each one means in a sentence. Recall that time runs downward and that each participating instance gets its own line.
Explain the mechanics: when a bar starts, when it ends, why bars stack when a participant calls itself, and why the vertical axis orders events without measuring them. Expect to draw a small interaction on a whiteboard while you talk.
Show judgement about what the bars reveal in a real design review — who blocks whom, who is idle, which participant has become the orchestrator — and be ready to say when omitting bars costs the reader nothing.
Own the convention itself: decide what your teams' diagrams must always show and what they may leave out, so that a diagram passed between groups is read the same way by everyone rather than argued over.
## What a lifeline actually represents A **lifeline** stands for one participant in one interaction. It is drawn as a rectangle — the **head** — with a dashed vertical line falling from its bottom edge. The head is labelled `role : Type`, and either half may be dropped: `kiosk : TicketDispenser`, `: TicketDispenser` for an anonymous participant of that type, or plain `kiosk` when the type adds nothing to the story. Two consequences of that definition trip candidates up: - A lifeline is an **instance-level** element, not a type. If three ticket kiosks take part in the interaction, you draw three lifelines, each with its own dashed line, even though all three are the same kind of thing. - A lifeline is scoped to **this** interaction. It asserts "this participant plays a part in the story below". It says nothing about the participant's fields, its relationships to other participants, or its behaviour outside this one scenario. ## The vertical axis is order, not duration Time runs **downward**. A message drawn lower than another happened after it, for the lifelines the two messages touch. Horizontal position carries no meaning beyond readability, which is exactly why teams shuffle lifelines left and right freely to reduce crossing arrows — the semantics do not change. The axis is **ordinal, not metric**. A message drawn a long way below another does not take longer than one drawn just beneath it. If you need to assert real elapsed time, that is what explicit duration and timing constraints exist for; drawing distance is never a substitute. Two messages at the same height on unrelated lifelines are also not simultaneous: the notation only orders events that share a lifeline or are joined by a message. ## The activation bar, formally an execution occurrence The narrow rectangle drawn on top of the dashed line is the **activation bar**, whose formal name is an **execution occurrence** (also seen as execution specification). It marks the stretch during which the participant is actively executing a behaviour. It begins when the participant receives a message that starts that behaviour, and ends when the behaviour completes — for a synchronous call, at the moment the participant replies. | Notation | Formal name | What it asserts | | --- | --- | --- | | Labelled box at the top | Lifeline head | Which participant this is, as `role : Type` | | Dashed vertical line | Lifeline | This participant takes part; time runs downward | | Narrow rectangle on the line | Execution occurrence | The participant is executing during this stretch | | Rectangle offset on another | Nested execution | A behaviour began while one was already running | | Large cross ending the line | Destruction occurrence | The participant ceases to exist at this point | ## Nested bars and self-messages Bars stack whenever a participant starts a behaviour while another is still running on it. The commonest case is a **self-message**: an arrow that leaves a lifeline and hooks straight back into it. What you draw is: 1. The outer bar, started by whatever message arrived from another participant. 2. An arrow from that outer bar back to the same lifeline, drawn as a short hook to the right. 3. A second bar, offset slightly and overlapping the first, for the inner behaviour. 4. The inner bar ending first, then the outer bar ending when the whole behaviour finishes. The offset is the entire point. The visible stacking depth is the depth of nested behaviour at that instant, and a reader can count it without reading a single label. ## Why the bar is worth drawing Activation bars are optional in the notation, and plenty of correct diagrams leave them off. They carry information nothing else in the diagram does: - Where a caller is **blocked**. With synchronous calls, an outer bar spanning six inner exchanges says the first participant waits through all six. - Where a participant is **idle**. Gaps between bars on one lifeline show it takes no part in that stretch. - Which participant is the **orchestrator**: one long bar running most of the height with everything else in short bursts is a centralised design, readable at a glance. - Where a lifeline **starts late or dies**: a head drawn part-way down means the participant is created during the interaction, and a large cross ends it. ## The mistakes that show up in interviews - Treating a lifeline as a class rather than as a participating instance. - Reading vertical distance as elapsed time. - Drawing a bar that never ends, so the diagram never says the behaviour finished. - Drawing a self-message without the nested bar, which throws away the only visual signal that the behaviour is nested. - Assuming activation bars are mandatory, and rejecting a valid diagram that omits them.
- A participant calls one of its own behaviours part-way through handling a request. What changes on its lifeline?The message is drawn as a short arrow leaving the lifeline and hooking back into it, and a second execution bar appears offset on top of the one already running. The inner bar ends when the inner behaviour returns; the outer bar continues until the original behaviour finishes. Without that offset second bar the diagram loses the only visible evidence that the behaviour is nested.
- The same class takes part twice in one interaction. How is that drawn?As two separate lifelines, each with its own head and its own dashed line, because a lifeline represents a participating instance rather than a type. Label them by role so a reader can tell them apart — for example two kiosks distinguished by role name rather than by type alone. Collapsing them into one lifeline would falsely claim a single participant handled both parts.
- Can a lifeline begin below the top of the diagram, and what does that mean?Yes. A lifeline head drawn part-way down means the participant is created during the interaction, and the message that creates it points at the head rather than at the dashed line. Symmetrically, a large cross ending the line marks a destruction occurrence: the participant does not exist after that point, and no later message may touch it.
The dashed line is a participant's whole appearance in the story; the solid bar is the stretch of that appearance where it is holding the microphone.
saying these in an interview costs you the question
- Says a lifeline represents a class rather than a participating instance
- Reads vertical distance as elapsed seconds
- Thinks horizontal position of lifelines carries meaning
- Cannot say when an activation bar starts or ends
- Draws a self-message with no nested bar
- Believes activation bars are mandatory in the notation