Class diagrams reveal what objects exist in a system—their attributes, methods, and relationships. But software is not static. Objects come to life, collaborate with each other, exchange messages, and orchestrate complex workflows. To understand how a system behaves over time, we need a fundamentally different perspective.

This is where sequence diagrams enter the picture. They model the dynamic side of object-oriented design: the temporal flow of interactions between objects as they fulfill a use case or execute a feature.

Consider a simple e-commerce checkout. A class diagram might show Customer, Cart, PaymentProcessor, Inventory, and OrderConfirmation classes. But that diagram doesn't answer critical questions:

• In what order do these objects interact during checkout?
• Which object initiates the process, and which ones respond?
• How does PaymentProcessor signal success or failure?
• What happens if inventory is insufficient?

These are behavioral questions—questions about how objects collaborate, not what they are. Answering them requires modeling interactions across time.

The fundamental building block of a sequence diagram is the lifeline. A lifeline represents a single participant in an interaction—an object, actor, or system component—and its existence over the duration of the scenario.

Visual Representation:

A lifeline consists of two parts:

1. Head (Header Box) — A rectangle at the top containing the participant's name and, optionally, its type. The standard UML notation is objectName:ClassName (e.g., cart:ShoppingCart).

2. Tail (Dashed Line) — A vertical dashed line extending downward from the header, representing the passage of time. This line is the participant's "life" during the interaction.

Reading the Diagram:

In the diagram above, we have four lifelines:

• customer:Customer — An instance of the Customer class
• cart:ShoppingCart — An instance of the ShoppingCart class
• paymentSvc:PaymentService — An instance of the PaymentService class
• inventory:InventorySystem — An instance of the InventorySystem class

Time flows downward. Events higher in the diagram occur before events lower down. This vertical axis is the temporal dimension that distinguishes sequence diagrams from static structural views.

Let's examine each component of a lifeline in detail.

Naming Conventions:

The header box follows the pattern objectName:ClassName. Both parts are optional, but at least one must be present:

Anonymous instances (using just :ClassName) are common when the scenario involves a single instance of that type, and the specific name doesn't add clarity.

While we often think of lifelines as representing objects (instances of classes), the concept is more general. A lifeline can represent any participant in an interaction:

Types of Participants:

Actors in Sequence Diagrams:

Actors represent entities outside the system boundary that initiate or participate in interactions. In a checkout scenario, the "Customer" actor triggers the process. The system's objects then collaborate to fulfill the customer's request.

Actors are typically positioned on the left edge of the diagram, as they usually initiate the interaction sequence.

The horizontal arrangement of lifelines affects readability and clarity. While UML doesn't mandate a specific order, professional practice follows conventions that enhance comprehension:

Conventional Ordering (Left to Right):

Why Ordering Matters:

Proper ordering creates a natural left-to-right flow that mirrors the message sequence. Messages travel predominantly from left to right, with responses returning right to left. This visual pattern—resembling reading order in Western languages—makes the diagram intuitive.

When lifelines are poorly ordered, message arrows crisscross chaotically, obscuring the interaction's logic. A well-ordered diagram tells a visual story: "The customer initiates, the controller delegates, the domain objects work, the services assist, and external systems persist."

Not all objects exist for the entire duration of an interaction. Some are created during the scenario, and some are destroyed. Sequence diagrams have specific notation for these lifecycle events.

Object Creation:

When an object is created during the interaction (rather than existing before it starts), its lifeline begins at the point of creation, not at the top of the diagram. A creation message (often labeled with a <<create>> stereotype or constructor name) points to the header box.

Object Destruction:

When an object is destroyed (its lifecycle ends), a large X marks the end of its dashed line. This indicates the object is no longer available for subsequent interactions.

Design Implications:

Modeling creation and destruction explicitly reveals important design decisions:

1. Who is responsible for creating objects? — Factory patterns, dependency injection containers, or direct instantiation.
2. What is the object's scope? — Is it created per-request and discarded, or does it persist across interactions?
3. Are resources properly cleaned up? — Destruction markers remind us to consider cleanup logic.

This explicit lifecycle modeling helps prevent resource leaks at the design level—long before they become runtime bugs.

An activation bar (or execution occurrence) is a thin rectangle overlaid on a lifeline's dashed line. It represents a period during which the object is actively executing—processing a method call, performing computation, or waiting for a response it initiated.

When Activation Bars Appear:

An activation bar begins when an object receives a message (method call) and ends when it returns control to the caller. The bar's height corresponds to the duration of that execution.

Visual Representation:

Reading Activation Bars:

In the diagram above:

1. Client calls processRequest() on Server → Server's activation begins
2. While active, Server calls query() on Database → Database's activation begins
3. Database returns results → Database's activation ends
4. Server returns response → Server's activation ends

Activation bars show the call stack visually. Nested activations (like Server being active while it waits for Database) represent the call hierarchy.

Stacked Activations:

If an object calls itself (a self-call), it creates a stacked activation—a narrower bar nested inside the outer activation. This visualizes recursive calls or internal method decomposition.

Let's apply our understanding of lifelines to model a realistic scenario: an e-commerce checkout process.

The Scenario:

A customer clicks "Checkout" on a shopping cart. The system must validate the cart, check inventory, process payment, and create an order confirmation.

Identified Participants (Lifelines):

Analysis:

This diagram reveals the checkout's structure:

• Initiator: The Customer actor starts the flow
• Orchestrator: CheckoutController manages the sequence, delegating to specialists
• Validation: InventoryService confirms availability before payment
• Transaction: PaymentGateway handles financial processing
• Creation: A new Order object is created upon success
• Notification: EmailService handles communication

The lifeline ordering creates a readable left-to-right flow, with the customer on the far left and external systems (PaymentGateway) and side-effects (EmailService) toward the right.

We've established the foundation for understanding sequence diagrams by focusing on their primary building block: the lifeline. Here's what we've covered:

What's Next:

With lifelines established, we need to understand what connects them: messages. The next page explores how objects communicate through synchronous and asynchronous messages, including the crucial concepts of calls, returns, and signals.