Sequence Diagrams

Order of Elements

The order of elements within a sequence diagram is pre-defined and must be kept. At first the involved participants are defined, followed by the messages in chronological order.

Participants

Participants are defined with the keyword act, followed by a unique ID, a colon and the type.

act Name:Participant

The ID cannot include empty spaces, except if it is placed in quotation marks. It is recommended to use the CamelCase convention. In terms of long names, an alias can be put right after the id - introduced with as.

act "Long Name":participant as lang

An alias has to be given if anonymus participants are defined.

act:Participant as participant

Participants can be further defined by stereotypes. This form of specification is marked by the keyword role and the relevant attribute in square brackets.

act Giraffe role[animal]
act Visitor role[human]

Further stereotypes are controls, entities and databases.

Instantiating a participant only when a message is sent to it can also be defined. In this case the keyword def (for defer) is given when defining the participant.

def act : Participant as deferedParticipant

Messages

Synchronous messages are defined with the keyword sync, asynchronous messages with async and reply messages with reply. The keyword is followed by the id of the message and then the included participants in round brackets.

sync "synchronous message from Bob to Alice" (Bob,Alice)
async "asynchronous message from Bob to Alice" (Bob,Alice)
reply "dashed line as reply message" (Bob,Alice)

Reflexive messages are presented analogous, only the operands are identical.

sync "synchronous messages from Alice to Alice" (Alice,Alice)

There are further lost and found messages. These are introduced by the keywords lost and found respectively. The anonymos participant is indicated by an underscore character.

found sync "message without a sender for Alice, found message" (_,Alice)
lost sync "message from Alice without reciever, lost message" (Alice,_)

Message Time Constraints

Different time constraints can be specified for messages. These are introduced by the keyword time followed by the condition in square brackets.

sync "Duration of the message 2 min" (Alice,Bob) time[d=2min]
sync "Maximal duration of the message 1 sec" (Alice,Bob) time[max=1sec]
async "Send, Recieve stated explicitly" (Alice, Bob) time[t=now, t+1sec]

The actual time constraint is written behind the actual message as an attribute. The only exception is the "call/invoke condition", in which the time constraint indicates how much time can pass between two messages. Here, the time constraint is put in a block which contains the relevant messages.

time[max=5min] {
sync call (Alice,Bob)
sync invoke (Alice,Bob)
}

Message Arguments

Messages can have arguments additionally to their id. This equals the function parameters in programming. In UML4ALL these arguments are declared as a string behind the id.

sync "no arguments" (Alice, Bob)
sync "simple values(10,8)" (Alice, Bob)
sync "variable declaration(var1=10,var22=8)" (Alice, Bob)
sync "values not specified(age=-)" (Alice, Bob)
sync "arguments not specified(-)" (Alice, Bob)

The declaration of return values is analogous to the declaration of function parameters. There is no compulsory structure but it is recommended to use the following notation:

reply "Concrete values(10,8):18" (Alice, Bob)
reply "Variable assignment(10,8):sum" (Alice, Bob)
reply "Value and variable assignment(10,8,out sum:18)" (Alice,Bob)
reply "value assignment(-,-):18" (Alice,Bob)

Lifelines

Participants are typically only activated when they are actually needed. For this reason the activation boxes of the livelines are not explicitly modelled in UML4ALL.

The only exception is the keyword dest (for destroy), with which a liveline can be destructed. The destruction is indicated with an "X" at the end of the liveline in the diagram.

act Alice:Visito
dest Alice

Combined Fragments

A fragment is introduced with a keyword. This is followed by a block in curly brackets which groups the corresponding messages together. Depending on the type of the fragment, further descriptors or attributes can be given.

Fragments can be defined individually, as well as through predefined fragments. Below, the notation for some of the predefined fragments will be introduced.

Alternative Execution - alt/else

For alternative executions the keywords alt and else are used to model the alternate messages. After the keyword alt the condition is stated in square brackets.

@start-seqd"Example ALT"
rootPackage RootElement

act visitor:visitor
act zookeeper:zookeeper

sync "hello" (visitor,zookeeper)

alt[zoo==open]{
    sync "Welcome!" (visitor,zookeeper)
}else{
    sync "Closed" (visitor,zookeeper)
}
@end-seqd

Optional Execution - opt

For optional executions the keyword opt is used, followed by the condition in square braces. An alternate execution with else is not allowed.