Sequence Diagrams

Sequence diagrams visualize how objects interact over time. They show the order of messages exchanged between participants to accomplish a specific task or scenario.

Core Concepts

Participants

Participants represent the objects or actors involved in the interaction. Each participant has a lifeline - a vertical dashed line extending downward that represents time.

Messages

Messages are the communications between participants, shown as horizontal arrows between lifelines. Time flows from top to bottom.

Activation Boxes

Activation boxes (also called execution specifications) are thin rectangles on a lifeline that show when a participant is actively processing.

Creating Participants

Using the Participant Tool

On a UML Sequence Diagram page, press P or choose Participant from the toolbar's UML menu, then click on the canvas to place participants. New participants line up with the existing ones. Press Return with a participant selected to rename it.

Participant Types

Participants can represent different types of entities:

  • Participant - A generic object or system part (rectangle)
  • Actor - A user or external system (stick figure)
  • Boundary - UI or system boundary
  • Control - Process or controller logic
  • Entity - Data or domain object
  • Database - A data store

Set the Role Type in the Inspector's Arrange tab → UML section.

Creating Messages

Using the Message Tool

Press M to activate the Message tool, then:

  1. Click on the source participant's lifeline
  2. Drag to the target participant's lifeline
  3. Release to create the message

Message Types

TypeArrow StyleDescription
SynchronousSolid line, filled arrowSender waits for response
AsynchronousSolid line, open arrowSender continues without waiting
ReturnDashed line, open arrowResponse to a synchronous call
CreateDashed line, open arrow to boxCreates a new participant
DestroyLine ending with XTerminates a participant
Self CallArrow looping back to the same lifelineA participant calls itself

Set the Message Type of the selected message in the Inspector's UML section.

Message Labels

Select a message and edit its Label in the Inspector's UML section. Common formats:

  • methodName() - Simple method call
  • methodName(param1, param2) - Call with parameters
  • result := methodName() - Call with return assignment
  • [condition] methodName() - Conditional message (guard)

Activation Boxes

Activation boxes show the period during which a participant is executing or waiting for a response.

Adding Activation Boxes

  1. Choose Activation from the toolbar's UML menu
  2. Drag along a participant's lifeline over the span where it is active
  3. The activation box is placed on that lifeline

Nested Activations

When a participant calls itself (recursive call) or handles multiple nested calls, activation boxes can be stacked.

Fragments

Fragments group messages to show conditional logic, loops, or other control flow.

Fragment Types

TypeKeywordPurpose
AlternativealtIf-else branching
OptionoptOptional execution (if without else)
LooploopRepeated execution
BreakbreakExit from enclosing loop
ParallelparConcurrent execution
CriticalcriticalAtomic/critical section
NegativenegInvalid interaction
AssertionassertRequired interaction
IgnoreignoreMessages that may be ignored
ConsiderconsiderMessages that must be considered
ReferencerefReference to another interaction

Creating Fragments

  1. Choose Fragment from the toolbar's UML menu
  2. Drag a rectangle over the participants and messages you want to group
  3. Select the fragment and set its Fragment Type in the Inspector's UML section
  4. Enter a Guard Condition as needed

Fragment Guards

Guards are conditions shown in square brackets:

  • [x > 0] - Numeric condition
  • [user.isAdmin] - Property check
  • [else] - Default/else branch in alt fragments

Reordering Elements

Moving Participants

Drag participants horizontally to reorder them. Connected messages will follow.

Moving Messages

Select a message and press Cmd+↑ or Cmd+↓ to move it earlier or later in the sequence.

Best Practices

  1. Start with the main flow - Model the happy path first, then add alternatives
  2. Keep it readable - Limit to 5-7 participants per diagram
  3. Use meaningful names - Label messages with actual method names or descriptions
  4. Show return messages - Especially for synchronous calls where the return value matters
  5. Use fragments sparingly - Too many nested fragments reduce readability
  6. Add notes - Use sticky notes to explain complex logic

Example: User Login Flow

A typical login sequence might include:

  1. User enters credentials
  2. Client sends login request to Server
  3. Server validates with Database
  4. Database returns user record
  5. Server creates session
  6. Server returns success/failure to Client
  7. Client updates UI

This flow demonstrates synchronous calls, return messages, and potential alt fragments for success/failure paths.