Handling Alternatives and Loops in Sequences

“I just want to show what happens when the user logs in” — that’s a phrase I hear weekly from beginners. It often means they’re about to draw a single path with no consideration for failure, timeout, or retry. That’s fine for a first sketch — but in real systems, things don’t always go smoothly. The real power of sequence diagrams comes not just from showing one flow, but from modeling the full picture: what happens when things go wrong, when choices are made, when actions repeat. That’s where UML sequence fragments come in.

These aren’t extra bells and whistles — they’re the tools that turn a simple interaction diagram into a reliable blueprint for behavior. You’ll learn how to use alt, option, loop, and par fragments to model conditional logic, repetition, and parallelism — all while keeping your diagrams clean and readable.

By the end of this chapter, you’ll be able to model a login process that handles both valid and invalid credentials, a checkout system that repeats attempts on timeout, and a task that runs in parallel with confirmation. You’ll understand not just how to draw them, but when to use each one — and when to avoid overcomplicating.

Why Sequence Fragments Are Essential for Realistic Behavior

Sequence diagrams aren’t just about time order. They’re about control flow. Without fragments, you’re limited to a single path, which doesn’t reflect real-world software behavior.

Consider a login system. A user enters a username and password. The system might respond in multiple ways: success, invalid password, locked account, or network failure.

To represent these possibilities, you need to move beyond a single linear flow. That’s what sequence fragments are for.

They let you define alternative branches, repeat actions, and run processes in parallel — all within the same diagram. This makes your models more accurate, more useful for testing, and more valuable when discussing design with teammates.

Modeling Alternatives with alt and option Fragments

The alt fragment is your go-to for modeling mutually exclusive alternatives — like success vs. error.

When to Use alt

• When only one branch should execute (e.g., login succeeds or fails).
• When modeling valid and invalid outcomes.
• When you want to highlight a primary path and its exceptions.

Here’s how to use it:

1. Draw a rectangle around the messages that represent the main flow.
2. Label the top of the rectangle alt.
3. Inside, add a condition in brackets (e.g., [success]).
4. Draw the alternative branch below, starting with [else].

Example: A login that either succeeds or returns an error.

alt [success]
  User --> System: Enter credentials
  System --> User: Welcome!
else [failure]
  User --> System: Enter credentials
  System --> User: Invalid password

This is a clean way to show conditional flows in sequence UML. It’s easy to read, and it emphasizes the most common path first.

When to Use option

The option fragment is similar but less strict. It allows multiple branches, but the rules are looser — it’s useful when you want to show optional paths.

• Use option when you’re listing possibilities, not enforcing exclusivity.
• Good for showing actions that might happen under certain conditions (e.g., “send email” or “notify admin”).
• Doesn’t require a then or else — so it’s more flexible.

Example: A user can log in with password, biometrics, or magic link.

option [password]
  User --> System: Enter password
  System --> User: Login success
option [biometrics]
  User --> System: Scan fingerprint
  System --> User: Login success
option [magic link]
  User --> System: Click link
  System --> User: Login success

Use option when you’re not enforcing mutual exclusivity — for example, when showing possible login methods, not the actual one used.

Modeling Repetition with the loop Fragment

Some actions repeat. A system might retry a failed connection, or a user might confirm an action multiple times.

The loop fragment models repetition clearly and efficiently.

How to Use loop

1. Enclose the repeated messages in a rectangle.
2. Label it loop.
3. Add a condition in brackets: [while retries < 3].

Example: A system retries a network call up to 3 times.

loop [while retries < 3]
  System --> Network: Send request
  Network --> System: Timeout
  System --> User: Retry attempt {retries + 1}

This is a powerful way to model sequence diagram alternatives loops. It’s concise, readable, and avoids the need to draw the same messages three times.

Don’t overuse loop fragments. If you’re repeating more than 2–3 times, consider whether a loop is appropriate — or if it should be modeled in a different diagram (like an activity diagram) for clarity.

Running Tasks in Parallel with par

Some tasks happen at the same time. For example, a user logs in, and the system simultaneously starts a session, sends a welcome email, and logs the event.

The par fragment (short for “parallel”) lets you show these concurrent actions.

How to Use par

1. Draw a rectangle around the parallel actions.
2. Label it par.
3. Each branch inside should be a separate sequence of messages.

Example: After login, the system starts multiple processes.

par
  System --> Session: Create session
  System --> Email: Send welcome email
  System --> Logger: Log login event

Use par when actions are independent and don’t depend on each other’s completion. If you need them to finish before continuing, use opt or alt with synchronization points.

When to Avoid par

• When actions depend on each other (e.g., you can’t send an email until the session is created).
• When the number of parallel actions exceeds 3 — the diagram becomes cluttered.
• When you’re modeling execution order that isn’t truly concurrent.

For complex parallel flows, consider breaking them into smaller diagrams or using activity diagrams instead.

Best Practices and Common Pitfalls

Keep Fragments Simple

Don’t nest fragments too deeply. One level of alt or loop is usually sufficient. If you need more, consider splitting the diagram.

Label Conditions Clearly

Use natural language in brackets: [user exists], [password matches]. Avoid complex expressions unless necessary.

Use Consistent Layout

Align fragments vertically. Start each branch on the same timeline. Avoid diagonal or overlapping flows.

Don’t Overuse Fragments

Not every decision needs a fragment. If a path is straightforward and unlikely to fail, just draw it. Use fragments only when you need to capture alternative outcomes.

Decision Checklist: Which Fragment to Use

Scenario	Fragment	Why?
Only one outcome happens: success vs. failure	alt	Enforces mutual exclusivity
Multiple possible paths (e.g., login methods)	option	Flexible, no need for exclusivity
Repeating an action (e.g., retrying)	loop	Clear and concise repetition
Independent actions at the same time	par	Models concurrency effectively

Frequently Asked Questions

Can I use multiple fragments in one diagram?

Yes — but be careful. You can combine alt and loop by placing a loop inside an alt branch. However, avoid deep nesting. If you find yourself with three layers, consider splitting the diagram.

How do I know if I should use a fragment or create a new diagram?

Use fragments when the alternative or loop is part of the same interaction. If the logic is complex — like a multi-step decision tree or a stateful process — consider using an activity diagram instead. Fragments are for behavior within a single interaction flow.

Do fragments affect the activation bar?

Yes — the activation bar should span the entire fragment. If you’re inside a loop, the activation should last for the duration of the loop. For par, each path gets its own activation bar that runs in parallel.

Can I use fragments in communication diagrams?

No — fragments are specific to sequence diagrams. Communication diagrams use numbered messages and focus on object collaboration, not control flow. Use UML sequence fragments only where timing and conditional logic matter.

How do I model a loop that stops on success?

Use loop with a condition like [until success]. This makes it clear the loop continues until a condition is met. Example:

loop [until success]
  System --> Network: Send request
  Network --> System: Failed
  System --> User: Try again

Are fragments mandatory in every sequence diagram?

No. Use them only when you need to show alternatives, repetition, or parallelism. A simple login flow with no error cases doesn’t need fragments. But if you’re modeling real-world behavior, they’re essential.