Unit 6: Sequence Diagrams

Both appear as boxes at the top of the diagram, but they represent different things:

• Actor — the external user or system that initiates the interaction. The same actor from your use case diagram. Often drawn as a stick figure rather than a box to distinguish it visually.
• Object — an instance of a class in your class diagram. Named as name : ClassName. This is the software object receiving and sending messages.

A key consistency check: every class name appearing in a sequence diagram should exist in your class diagram. If it does not, your class diagram is incomplete.

A lifeline is the dashed vertical line below each participant's box. It represents that object's existence over time during the interaction.

Time flows downward. Messages higher on the diagram happen earlier than messages lower down. This makes the sequence diagram a readable narrative: read it top to bottom to follow the flow of the interaction.

An object can be created during an interaction — shown by the message arrow pointing to the object box itself, rather than to the lifeline below it. An object can also be destroyed — shown by a large X at the end of its lifeline.

An activation bar (also called an execution specification) is a narrow rectangle drawn on a lifeline. It shows the period during which an object is actively executing.

The bar starts when the object receives a call and ends when:

• It returns a response to the caller (end of synchronous call)
• It finishes processing an asynchronous message

Activation bars can be nested — a bar within a bar shows that an object calls itself (recursion) or that a new call arrives while it is still processing a previous one.

In simple diagrams, activation bars are sometimes omitted. Include them when the timing and duration of processing is important to communicate.

Time flows strictly top to bottom. A message drawn higher on the diagram occurs before one drawn lower. This imposes a clear ordering on the interaction.

However, sequence diagrams do not specify exact timings or durations — only ordering. They show what happens before what, not how long each step takes.

This is an important limitation: if you need to model timing constraints (e.g. a response must arrive within 500ms), a timing diagram is the appropriate UML diagram, not a sequence diagram.

A synchronous message is drawn as a solid arrow with a filled arrowhead. It means: the sending object calls the receiving object and waits for the response before doing anything else.

This is the standard model for most software interactions — a method call where the caller blocks until the method returns. The sender's activation bar extends downward until the return message arrives.

Example: LoginController calls UserDatabase.findUser(userId) and waits for the User object to be returned before proceeding.

An asynchronous message is drawn as a solid arrow with an open (stick) arrowhead. The sender does not wait for a response — it continues processing immediately.

Use this for:

• Sending events or notifications (fire and forget)
• Interactions with message queues or event buses
• Background thread processing
• User interface interactions (button press triggers event, UI does not block)

Asynchronous messages do not have a corresponding return arrow — there is no response the sender is waiting for.

A return message is drawn as a dashed arrow pointing back to the original caller. It represents the response from a synchronous call.

When to include it:

• When the return value is important to the logic of the diagram
• When the interaction would be ambiguous without it
• In detailed, precise diagrams where completeness matters

When it is acceptable to omit it:

• When the return is obvious and labelling it adds no information
• In overview diagrams where clarity of the high-level flow matters more than completeness

An alt fragment (alternative) is drawn as a rectangular frame around part of the interaction, with the label alt in the top-left corner. Inside, two or more regions are separated by dashed lines. Each region has a guard condition in square brackets: [condition].

Only the region whose guard condition is true will execute — exactly like an if/else statement.

Example:

• Region 1: [password matches] → create session, return success
• Region 2: [password does not match] → return failure message

The opt fragment is similar but has only one region — the enclosed messages occur only if the guard is true (no else branch).

A loop fragment is drawn as a rectangular frame labelled loop. The guard condition specifies the condition under which the loop continues.

Often written as loop(minOccurrences, maxOccurrences) or with a condition: loop [more items in cart].

Use loop fragments when the same sub-interaction repeats — for example, processing each item in a shopping cart, or retrying a failed connection up to three times.

Caution: Heavy use of combined fragments can make a sequence diagram hard to read. If the logic becomes complex, consider whether an activity diagram would communicate the same information more clearly.