Complete guide to UML Sequence Diagrams: learn how to model object interactions over time. Master lifelines, messages, activation boxes, and how to document system behavior effectively.
Table of Contents
1. What are Sequence Diagrams?
Sequence diagrams model the interactions between objects over time. They show how objects collaborate to accomplish a task, displaying the order in which messages are sent and received.
Sequence diagrams are particularly useful for:
- Modeling object interactions in a use case
- Designing method calls and object collaborations
- Documenting system behavior
- Understanding the flow of control in a system
- Identifying design issues and optimization opportunities
Unlike class diagrams that show static structure, sequence diagrams show dynamic behavior—how objects interact over time.
2. Lifelines
2.1 What are Lifelines?
A lifeline represents an object or actor participating in an interaction. It's shown as a vertical dashed line with a box at the top containing the object name.
2.2 Lifeline Notation
2.3 Lifeline Naming
Lifelines can be named in several ways:
- Object name:
order1 : Order - Class only:
: Order - Actor:
Customer - Role:
: PaymentProcessor
2.4 Lifeline Duration
The vertical line represents the object's lifetime:
- Top of line: Object creation or start of interaction
- Bottom of line: Object destruction or end of interaction
- Dashed line: Object exists but is inactive
3. Messages
3.1 What are Messages?
Messages represent communication between lifelines. They show method calls, signals, or other interactions. Messages are shown as arrows between lifelines, with time flowing from top to bottom.
3.2 Synchronous Messages
Synchronous messages represent method calls where the caller waits for a response. Shown as a solid arrow with a filled arrowhead.
3.3 Asynchronous Messages
Asynchronous messages represent calls where the caller doesn't wait. Shown as a solid arrow with an open arrowhead.
3.4 Return Messages
Return messages show the response to a synchronous call. Shown as a dashed arrow. Often omitted if the return value is obvious.
3.5 Self Messages
Self messages represent an object calling its own method. Shown as an arrow that loops back to the same lifeline.
3.6 Message Types Summary
| Type | Notation | Description |
|---|---|---|
| Synchronous | ───▶ | Method call, caller waits |
| Asynchronous | ───▷ | Signal, caller doesn't wait |
| Return | ◀─── (dashed) | Return value or control |
| Self | Loop back | Object calls itself |
4. Activation Boxes
4.1 What are Activation Boxes?
Activation boxes (also called focus of control) show when an object is active—when it's executing a method or processing a message. They're shown as thin rectangles on the lifeline.
4.2 Activation Box Notation
4.3 Nested Activations
When an object calls another method while already active, nested activation boxes show this:
4.4 When to Show Activations
- Show activations for clarity in complex interactions
- Use them to show when objects are actively processing
- Nested activations show method call chains
- Can be omitted in simple diagrams
5. Interaction Fragments
5.1 What are Interaction Fragments?
Interaction fragments (UML 2.0+) allow you to model complex control flow, including alternatives, loops, and parallel execution. They're shown as frames with operators.
5.2 Alternative Fragment (alt)
Shows alternative paths based on conditions:
5.3 Loop Fragment (loop)
Shows repeated execution:
5.4 Optional Fragment (opt)
Shows optional behavior:
5.5 Parallel Fragment (par)
Shows parallel execution:
5.6 Other Fragments
- ref: References another sequence diagram
- break: Exceptional exit from interaction
- critical: Critical section that must complete
- neg: Invalid interaction
6. Best Practices
6.1 Keep Diagrams Focused
- Focus on one use case or scenario per diagram
- Don't try to show everything in one diagram
- Create multiple diagrams for different scenarios
- Keep diagrams readable and uncluttered
6.2 Use Appropriate Detail Level
- Show important interactions, not every method call
- Include return messages only when they add value
- Use activation boxes for clarity, not always
- Balance detail with readability
6.3 Organize Lifelines
- Place important actors/objects on the left
- Group related objects together
- Minimize message crossing
- Use consistent naming conventions
6.4 Use Fragments Wisely
- Use fragments to show complex control flow
- Keep conditions clear and understandable
- Don't overuse fragments in simple scenarios
- Use ref fragments to reuse common interactions
6.5 Consistency
- Ensure consistency with class diagrams
- Verify messages match class methods
- Keep naming consistent across diagrams
- Update diagrams when code changes
0 Comments