What do the alt, opt and loop combined fragments express in a UML sequence diagram?

middleshould knowfreq 46%

answer

A box with a tag in the corner
The tag names the operator
Dashed lines separate the operands
Guards live in square brackets
One operand versus several alternatives

basics

~20 s

A combined fragment is a labelled box drawn over part of a sequence diagram, with an operator in its top-left pentagon. alt holds several guarded, mutually exclusive operands; opt holds one that runs only if its guard holds; loop repeats its operand.

solid answer

~40 s

A combined fragment is a rectangle drawn over the region of the interaction it governs, with the interaction operator in a small pentagon at its top-left corner. Inside it are one or more interaction operands, separated by dashed horizontal lines, and each operand may carry a guard written in square brackets at its top-left.

alt — two or more operands, mutually exclusive; exactly one runs, chosen by the guards, with [else] as the fallback operand.
opt — a single operand that runs when its guard holds and is skipped otherwise; equivalent to an alt with one guarded operand and an empty alternative.
loop — one operand repeated, written loop(min, max) with an optional guard tested before each pass.

par completes the set for concurrency: its operands may interleave in any order.

A **combined fragment** is a rectangle drawn over the region of the interaction it governs, with the **interaction operator** in a small pentagon at its top-left corner. Inside it are one or more **interaction operands**, separated by dashed horizontal lines, and each operand may carry a **guard** written in square brackets at its top-left. - **alt** — two or more operands, mutually exclusive; exactly one runs, chosen by the guards, with `[else]` as the fallback operand. - **opt** — a single operand that runs when its guard holds and is skipped otherwise; equivalent to an `alt` with one guarded operand and an empty alternative. - **loop** — one operand repeated, written `loop(min, max)` with an optional guard tested before each pass. **par** completes the set for concurrency: its operands may interleave in any order.

code

pseudocode · 12 lines

pseudocode

+-- alt ------------------------------------------+
| [payment approved]                              |
|    kiosk  -> printer : printTicket(2)           |
|    printer - -> kiosk : ticketReady             |
|- - - - - - - - - - - - - - - - - - - - - - - - -|
| [else]                                          |
|    kiosk  -> screen  : showDeclineReason()      |
+-------------------------------------------------+

+-- loop(1, 4) [seats remaining] ------------------+
|    kiosk  -> dispenser : reserveNextSeat()       |
+-------------------------------------------------+

go deeper

for a junior

Recognise the shape: a box over part of the diagram with a small tag in its top-left corner naming the operator. Recall that alt means alternatives, opt means maybe, and loop means repeat.

for a middle

Explain the mechanics — operands, dashed separators, guards in square brackets, loop bounds — and say precisely why opt is not just an alt with one branch. Expect to add a condition to a diagram on the spot.

for a senior

Show judgement about how much control flow belongs in one diagram: which branches earn a fragment, which belong in a referenced interaction, and when the scenario has stopped being a conversation worth drawing this way.

for a principal

Own the convention across teams: decide how exhaustive your diagrams try to be, since a group that fragments every error path produces diagrams nobody reads and a group that never fragments hides every failure case.

Anatomy of a combined fragment

A straight sequence diagram shows one path. Combined fragments are how the notation adds control flow without turning into a second diagram type. Every combined fragment has the same three parts:

A rectangle drawn over exactly the region — lifelines and messages — that it governs. Messages outside the box are unaffected.
An interaction operator in a small pentagon tag in the top-left corner: alt, opt, loop, par and the rest.
One or more interaction operands, separated by dashed horizontal lines, each of which may carry a guard in square brackets at its own top-left corner.

The guard is a boolean condition evaluated when the fragment is entered — [balance >= total], [else]. It is written in brackets on the operand it governs, not on any message inside it and not beside the operator tag.

The four operators worth knowing cold

Operator	Operands	What it asserts
`alt`	Two or more, guarded	Exactly one operand runs; guards select it; `[else]` is the fallback
`opt`	Exactly one, guarded	The operand runs if the guard holds, and is skipped otherwise
`loop`	Exactly one	The operand repeats, bounded by `loop(min, max)` and any guard
`par`	Two or more	The operands' messages may interleave in any order

alt versus opt — the distinction interviewers probe

Both are conditional, and candidates often use alt for everything. The difference is about alternatives, not about conditions:

alt says these are the possibilities and one of them happens. Its operands are mutually exclusive and, taken with [else], they are meant to be exhaustive. An alt with a single operand and no [else] is a smell: you meant opt.
opt says this may or may not happen and nothing else takes its place. It is exactly an alt with one guarded operand and an empty alternative, and using it makes the "or nothing" case explicit rather than leaving the reader to infer it.

If no guard on an alt holds and there is no [else] operand, nothing inside the fragment runs — which is a legal but usually unintended reading, and is why an explicit [else] is a good habit.

loop and its bounds

loop repeats its single operand. The bounds are written on the tag:

loop alone — unbounded repetition.
loop(3) — exactly three iterations.
loop(0, 8) — between none and eight.
loop(1, *) — at least one, no upper bound.

A guard may be combined with the bounds and is evaluated before each pass: the operand repeats while the guard holds, up to the maximum. Two errors are common. The first is expecting loop(0, 4) to run at least once — the minimum is zero, so it may be skipped entirely. The second is expecting the diagram to show the iteration count at runtime; the bounds constrain the possible traces, they do not record what actually happened on any one run.

par, and what it does not promise

par says the messages in its operands may interleave in any order, subject only to the ordering that each individual lifeline already imposes. That is weaker than most people read it as:

It does not assert threads, processors or a scheduler. It asserts that the diagram does not constrain the relative order across operands.
It does not mean the operands finish together, and it does not mean they start together.
Ordering within a single operand still holds, and ordering along a single lifeline still holds.

Beyond these four, break abandons the rest of the enclosing interaction after its operand runs, critical marks a region that must not be interleaved, and ref (an interaction use) pulls in a whole interaction defined elsewhere — the main tool for keeping a diagram small.

When nesting stops paying

Fragments nest, and that is where readable diagrams go to die. Each nesting level roughly multiplies the traces a reader has to hold in their head, and three levels deep the box borders alone consume the space the messages need. Practical discipline:

Keep the happy path as the diagram's spine, and push rare branches into a separate diagram referenced by ref.
Prefer several small diagrams named after their scenario over one fragment-laden diagram trying to be exhaustive.
If you find yourself drawing an alt with five operands, the interaction is probably a decision procedure rather than a conversation, and the diagram is the wrong shape for it.

## Anatomy of a combined fragment A straight sequence diagram shows one path. **Combined fragments** are how the notation adds control flow without turning into a second diagram type. Every combined fragment has the same three parts: 1. A **rectangle** drawn over exactly the region — lifelines and messages — that it governs. Messages outside the box are unaffected. 2. An **interaction operator** in a small pentagon tag in the top-left corner: `alt`, `opt`, `loop`, `par` and the rest. 3. One or more **interaction operands**, separated by **dashed horizontal lines**, each of which may carry a **guard** in square brackets at its own top-left corner. The guard is a boolean condition evaluated when the fragment is entered — `[balance >= total]`, `[else]`. It is written in brackets on the operand it governs, not on any message inside it and not beside the operator tag. ## The four operators worth knowing cold | Operator | Operands | What it asserts | | --- | --- | --- | | `alt` | Two or more, guarded | Exactly one operand runs; guards select it; `[else]` is the fallback | | `opt` | Exactly one, guarded | The operand runs if the guard holds, and is skipped otherwise | | `loop` | Exactly one | The operand repeats, bounded by `loop(min, max)` and any guard | | `par` | Two or more | The operands' messages may interleave in any order | ## alt versus opt — the distinction interviewers probe Both are conditional, and candidates often use `alt` for everything. The difference is about **alternatives**, not about conditions: - `alt` says *these are the possibilities and one of them happens*. Its operands are mutually exclusive and, taken with `[else]`, they are meant to be exhaustive. An `alt` with a single operand and no `[else]` is a smell: you meant `opt`. - `opt` says *this may or may not happen and nothing else takes its place*. It is exactly an `alt` with one guarded operand and an empty alternative, and using it makes the "or nothing" case explicit rather than leaving the reader to infer it. If no guard on an `alt` holds and there is no `[else]` operand, nothing inside the fragment runs — which is a legal but usually unintended reading, and is why an explicit `[else]` is a good habit. ## loop and its bounds `loop` repeats its single operand. The bounds are written on the tag: - `loop` alone — unbounded repetition. - `loop(3)` — exactly three iterations. - `loop(0, 8)` — between none and eight. - `loop(1, *)` — at least one, no upper bound. A guard may be combined with the bounds and is evaluated **before each pass**: the operand repeats while the guard holds, up to the maximum. Two errors are common. The first is expecting `loop(0, 4)` to run at least once — the minimum is zero, so it may be skipped entirely. The second is expecting the diagram to show the iteration *count* at runtime; the bounds constrain the possible traces, they do not record what actually happened on any one run. ## par, and what it does not promise `par` says the messages in its operands may **interleave in any order**, subject only to the ordering that each individual lifeline already imposes. That is weaker than most people read it as: - It does not assert threads, processors or a scheduler. It asserts that the diagram does not constrain the relative order across operands. - It does not mean the operands finish together, and it does not mean they start together. - Ordering *within* a single operand still holds, and ordering along a single lifeline still holds. Beyond these four, `break` abandons the rest of the enclosing interaction after its operand runs, `critical` marks a region that must not be interleaved, and `ref` (an interaction use) pulls in a whole interaction defined elsewhere — the main tool for keeping a diagram small. ## When nesting stops paying Fragments nest, and that is where readable diagrams go to die. Each nesting level roughly multiplies the traces a reader has to hold in their head, and three levels deep the box borders alone consume the space the messages need. Practical discipline: - Keep the happy path as the diagram's spine, and push rare branches into a separate diagram referenced by `ref`. - Prefer several small diagrams named after their scenario over one fragment-laden diagram trying to be exhaustive. - If you find yourself drawing an `alt` with five operands, the interaction is probably a decision procedure rather than a conversation, and the diagram is the wrong shape for it.

When would you reach for opt rather than an alt with one operand?
Whenever the alternative to the guarded behaviour is nothing at all. `opt` states "this may happen, or the interaction simply continues" in one operand, which is exactly an `alt` with a single guarded operand and an empty alternative. Writing it as a one-operand `alt` with no `[else]` leaves a reader wondering whether an alternative was forgotten, and an `alt` is meant to enumerate exhaustive, mutually exclusive possibilities.
What does a par combined fragment actually guarantee about ordering?
Only that the diagram does not constrain the order of messages across its operands: they may interleave in any way. Ordering inside one operand still holds, and ordering along any single lifeline still holds. It asserts nothing about threads, processors or scheduling, and it does not require the operands to start or finish together. Reading it as a promise of true simultaneity is the usual mistake.
None of the guards on an alt fragment hold and there is no else operand. What happens?
Nothing inside the fragment runs and the interaction continues after it. That is legal, but it is rarely what the author meant, which is why an explicit `[else]` operand is a good habit — it forces you to say what the fallback is instead of leaving a silent, empty path that a reader has to deduce from the absence of a guard that matches.

saying these in an interview costs you the question

Writes the guard beside the operator tag instead of on the operand
Uses alt for a condition with no alternative branch
Thinks par asserts separate threads or true simultaneity
Assumes a loop with minimum zero always runs once
Cannot name the dashed lines as operand separators
Nests fragments four deep and calls the result readable

What do the alt, opt and loop combined fragments express in a UML sequence diagram?

§ answer

basics

solid answer

code

§ go deeper

▾level notes4 levels

▾deep dive~4 min

Anatomy of a combined fragment

The four operators worth knowing cold

alt versus opt — the distinction interviewers probe

loop and its bounds

par, and what it does not promise

When nesting stops paying

▾common follow-ups3 questions

▾red flags6 flags

Anatomy of a combined fragment

The four operators worth knowing cold

alt versus opt — the distinction interviewers probe

loop and its bounds

par, and what it does not promise

When nesting stops paying

answer

go deeper