Loading learning content...
Real software doesn't execute in a single straight line. It branches based on conditions, repeats operations in loops, handles exceptions, and executes tasks in parallel. Basic message arrows can't express this conditional and iterative logic—we need something more powerful.
Combined fragments are the UML mechanism for adding control flow to sequence diagrams. They define regions of a diagram where special rules apply: execute this part only if a condition is true, repeat until complete, run these operations in parallel, or take one of several alternative paths.
By the end of this page, you will master the primary combined fragments: alt (alternatives), opt (optional), loop (iteration), par (parallel), and break (early exit). You'll know when to use each and how to compose them for complex behavioral models.
A combined fragment is a rectangular region in a sequence diagram that groups messages and applies special semantics to them. Each fragment has:
Visual Structure:
┌─────────────────────────────────┐
│ operator [guard] │
├─────────────────────────────────┤
│ │
│ Messages in this operand │
│ │
├─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ─ ┤
│ [alternative guard] │
│ │
│ Messages in alternative │
│ │
└─────────────────────────────────┘
| Operator | Name | Purpose |
|---|---|---|
alt | Alternatives | If-else branching; exactly one operand executes |
opt | Optional | Execute if condition is true; like if without else |
loop | Loop | Repeat while condition is true or for n iterations |
par | Parallel | All operands execute concurrently |
break | Break | Early exit from enclosing fragment |
critical | Critical Region | Must execute atomically without interleaving |
neg | Negative | Shows invalid/prohibited interactions |
ref | Reference | Refers to another sequence diagram |
The alt (alternatives) fragment models if-else logic. It contains multiple operands, each with a guard condition. Exactly one operand executes—the first whose guard evaluates to true.
Structure:
[condition][else] can be used for the default caseExample: Payment Processing
Reading the Diagram:
processPayment is calledalt fragment ensures mutual exclusivityDesign Insight:
The alt fragment reveals decision points in your design. Each operand represents a distinct code path. This is valuable for:
Guards should be written in terms the reader understands—not code snippets. Use [payment successful] rather than [result.status == SUCCESS]. The diagram communicates intent; implementation details go in code.
The opt (optional) fragment models conditional execution without an alternative. If the guard is true, the operand executes; if false, it's skipped. This is the UML equivalent of an if statement without else.
Structure:
Example: Optional Logging
When to Use opt vs alt:
Use opt | Use alt |
|---|---|
| There's only one conditional behavior | There are multiple mutually exclusive behaviors |
| No alternative action (silent skip) | Each branch has different actions |
| Feature flags, debug modes | Error handling, status-based branching |
if (condition) { ... } | if (...) { } else if (...) { } else { } |
Note: An opt is semantically equivalent to an alt with one operand and an empty [else] case.
If you find many opt fragments in your diagram, consider whether the optional behavior should be a separate diagram or abstracted. Too many conditional paths make diagrams hard to follow.
The loop fragment models repeated execution. It continues until a condition becomes false or a specified number of iterations completes.
Syntax Variations:
| Format | Meaning |
|---|---|
loop [condition] | While condition is true |
loop (min, max) | Execute between min and max times |
loop (n) | Execute exactly n times |
loop * | Unlimited/while true |
loop (1, *) | At least once (like do-while) |
Example: Processing Items in a Collection
Reading the Diagram:
Bounded Loops:
When iteration count matters, use bounds:
Avoid drawing each iteration separately unless the specific iterations matter. The loop fragment abstracts repetition, keeping diagrams concise. Use notes to indicate what varies between iterations.
The par (parallel) fragment models concurrent execution. All operands within the fragment execute simultaneously—their relative ordering is undefined.
Structure:
Example: Parallel Notifications
Key Points:
par fragment completes when all three finishreserveInventory happens after all notifications (it's outside the par)When to Use par:
The par fragment asserts that operations CAN run concurrently. This implies no ordering dependencies and no shared mutable state conflicts. If operations must be ordered, don't use par—you'll be asserting something false about your design.
The break fragment models early termination of an enclosing fragment (like break in loops). When a break's guard is true, its operand executes and then control exits the enclosing fragment.
Semantics:
Example: Validation with Early Exit
Reading the Diagram:
Break vs. Alt:
break | alt |
|---|---|
| Exits enclosing fragment | Stays within fragment |
| Represents early return/exception | Represents conditional branches |
| One path ends processing | All paths continue after |
Use break for: Input validation failures, error conditions, search-found-early scenarios.
Break is particularly useful inside loop fragments. When a condition is met (item found, error occurred), break allows immediate exit without processing remaining iterations.
Fragments can be nested to model complex control flow. A loop can contain an alt; an alt can contain a par; any combination is valid.
Example: Loop with Conditional Processing
Nested Structure:
loop ─────────────────────────────────┐
│ validate(record) │
│ │
│ alt ────────────────────────┐ │
│ │ [valid] │ │
│ │ process(record) │ │
│ ├───────────────────────────┤ │
│ │ [invalid] │ │
│ │ logError(...) │ │
│ └───────────────────────────┘ │
│ │
└─────────────────────────────────────┘
Nesting Guidelines:
Deeply nested fragments (4+ levels) become impossible to read. If your diagram needs that much control flow, it's a sign to decompose into multiple diagrams or rethink the design's complexity.
The ref (reference) fragment allows you to reference another sequence diagram, enabling modular design. Instead of duplicating complex interactions, you define them once and reference them from multiple places.
Syntax:
┌─────────────────────────────────┐
│ ref │
│ InteractionName │
└─────────────────────────────────┘
Example: Referencing Authentication
Benefits of refs:
Common ref Candidates:
Use refs to create layered diagrams: high-level overviews reference detailed sub-diagrams. Readers start with the overview and dive into refs only when needed. This manages complexity effectively.
Fragments add expressive power but also complexity. Use them judiciously:
| Guideline | Rationale | Example |
|---|---|---|
| Use guards that read naturally | Diagrams communicate intent, not code | [order is valid] not [isValid == true] |
| Limit nesting to 2-3 levels | Deeper nesting destroys readability | Extract to ref if deeper |
| Prefer alt over nested opts | Single fragment is cleaner than multiple | alt [A][B][else] vs. opt [A] + opt [B] |
| Use ref for reused sequences | Don't duplicate; reference | Auth, logging, error handling |
| Show break for early exits | Makes exit conditions explicit | Validation failures, found-in-search |
| Use par only for true parallelism | Don't imply concurrency that doesn't exist | Independent async calls, not sequential steps |
alt operands truly mutually exclusive?par represent genuinely parallel operations?We've covered the combined fragments that bring control flow to sequence diagrams:
Module Complete:
You've now mastered the core concepts of sequence diagrams:
With these tools, you can model virtually any dynamic behavior in your system, communicating designs precisely and enabling productive design discussions.
You now have comprehensive knowledge of sequence diagrams for modeling behavior over time. You can represent object interactions, message flows, conditional logic, loops, parallel execution, and modular decomposition—the full toolkit for dynamic behavioral modeling in UML.