A sequence diagram is an interaction diagram that shows how processes operate with one another and in what order.

Most developers would find the syntax fairly familiar. The following example demonstrates some basic syntaxes.

The above diagram is generated from the follow text:

// Optionally declare a participant (see Participant)
@Lambda BookLibService
// Sync message; <br>
// Use `A->B: message` for async messages
BookLibService.Borrow(id) {
  // Nested message
  User = Session.GetUser() {
    // Self message
    loadUserProfile()
  }
  // Alt fragment; also try `while`, `par` (see Fragments)
  if(User.isActive) {
    // Try/Catch/Finally fragment
    try {
      BookRepository.Update(id, onLoan, User)
      // Creation message with return message
      receipt = new Receipt(id, dueDate)
    } catch (BookNotFoundException) {
      ErrorService.onException(BookNotFoundException)
    } finally {
      Connection.close()
    }
  }
  // separte return message
  return receipt
}

Participants

The participants can be defined implicitly as in the first example on this page. The participants are rendered in order of appearance in the diagram source text. Sometimes you might want to show the participants in a different order than how they appear in the first message. It is possible to specify the participant’s order of appearance by doing the following:

B
A
A.method()
A->B: Event

Participant group

We can group the participants with group keyword.

group GroupName {
  A
  B
}
C

Participant type (Annotation)

We can change the shape of the participant representation with annotations.

Stereotype

It is possible to add stereotypes to participants using << and >>.

Starter

advanced

By default, the “client” of the interaction is not shown in the diagram. However, you can specify a “client” with the @Starter keyword. Specifically, if the starter’s name is “User” or “Actor”, we will use a Stickman icon. @Starter must be put after you have declared all participants and before any messages.

Messages

A message is shown as a line from the sender MessageEnd to the receiver MessageEnd.

See Unified Modeling Language v2.5.1, section 17.4.4.1.

Message type	DSL	Line and arrowhead (Spec)

Message type	DSL	Line and arrowhead (Spec)
Async	A->B: Async message	solid line with open arrowhead
Sync	A.method()	filled arrowhead
Reply	`ret = A.method` `return ret` `@return A->B: message`	dashed line with either an open or filled arrowhead * ZenUML renderer use open arrowhead.
Object creation	new ClassName()	dashed line with an open arrowhead
Object deletion	NOT SUPPORTED YET	Must end in a DestructionOccurrenceSpecification
Lost	NOT SUPPORTED YET	A small black circle at the arrow end of the message
Found	NOT SUPPORTED YET	A small black cirle at the starting end of the message

Loops

The loop operand will be repeated a number of times. This is expressed by the notation:

See the example below:

Alt

The alt operand represents a choice of behavior. At most one of the operands will be chosen. This is expressed by the notions:

ZenUML Docs

Sequence diagram syntax