Deal with Sequence Diagram - UML 2.0?

Sequence diagram is the most common kind of interaction diagram, which focuses on the message interchange between a number of lifelines.

Sequence diagram describes an interaction by focusing on the sequence of messages that are exchanged, along with their corresponding occurrence specifications on the lifelines.

The following nodes and edges are typically drawn in a UML sequence diagram: lifeline, execution specification, message, combined fragment,interaction use, state invariant, continuation, destruction occurrence.

Major elements of the sequence diagram are shown on the picture below.

Major elements of UML sequence diagram.

You can find some sequence diagram examples here:

• Online Bookshop
• Submit Comments to Pluck using DWR, AJAX, JSON
• Facebook User Authentication in a Web Application
• Spring and Hibernate transaction management

Lifeline

Lifeline is a named element which represents an individual participant in the interaction. While parts and structural features may have multiplicity greater than 1, lifelines represent only one interacting entity.

If the referenced connectable element is multivalued (i.e, has a multiplicity > 1), then the lifeline may have an expression (selector) that specifies which particular part is represented by this lifeline. If the selector is omitted, this means that an arbitrary representative of the multivalued connectable element is chosen.

A lifeline is shown using a symbol that consists of a rectangle forming its "head" followed by a vertical line (which may be dashed) that represents the lifetime of the participant.

Information identifying the lifeline is displayed inside the rectangle in the following format (slightly modified from what's in UML 2.4 standard):

lifeline-ident ::= [ connectable-element-name [ '[' selector ']' ]]   [ ':' class-name ] [ decomposition ] | 'self'
selector ::= expression
decomposition ::= 'ref' interaction-ident [ 'strict' ]

where class-name is the type referenced by the represented connectable element. Note that although the syntax allows it, lifeline-ident cannot be empty.

The lifeline head has a shape that is based on the classifier for the part that this lifeline represents. Usually the head is a white rectangle containing name of class.

Lifeline "data" of class Stock

Anonymous lifeline of class User

Lifeline "x" of class X is selected with selector [k]

If the name is the keyword self, then the lifeline represents the object of the classifier that encloses the Interaction that owns the Lifeline. Ports of the encloser may be shown separately even when self is included.

Message

Message is a named element that defines one specific kind of communication between lifelines of an interaction. The message specifies not only the kind of communication, but also the sender and the receiver. Sender and receiver are normally two occurrence specifications (points at the ends of messages).

Syntax for the message is:

message ::= [ attribute '=' ] signal-or-operation-name [ arguments ] [ ':' return-value ]  | '*'
arguments ::= '(' [argument  [ ',' argument]* ')'
argument ::= [ parameter-name '='] argument-value | attribute '=' out-parameter-name [ ':' argument-value ]  | ' -'

Arguments of a message could only be:

• attributes of the sending lifeline,
• constants,
• symbolic values (which are wildcard values representing any legal value),
• explicit parameters of the enclosing interaction,
• attributes of the class owning the interaction.

A message is shown as a line from the sender message end to the receiver message end. The line must be such that every line fragment is either horizontal or downwards when traversed from send event to receive event. The send and receive events may both be on the same lifeline. The form of the line or arrowhead reflects properties of the message.

Messages by Action Type

A message reflects either an operation call and start of execution or a sending and reception of a signal.

When a message represents an operation call, the arguments of the message are the arguments of the operation. When a message represents a signal, the arguments of the message are the attributes of the signal.

Depending on the type of action that was used to generate the message, message could be one of:

• synchronous call
• asynchronous call
• asynchronous signal
• create
• delete
• reply

Synchronous Call

Synchronous call typically represents operation call - send message and suspend execution while waiting for response. Synchronous call messages are shown with filled arrow head.

Web Client searches Online Bookshop and waits for results.

Asynchronous Call

Asynchronous call - send message and proceed immediately without waiting for return value. Asynchronous messages have an open arrow head.

Service starts Task and proceeds in parallel without waiting.

Asynchronous Signal

Asynchronous signal message corresponds to asynchronous send signal action.

Create Message

Create message is sent to a lifeline to create itself. It is shown as a dashed line with open arrowhead (looks the same as reply message), and pointing to the created lifeline's head.

Online Bookshop creates Account.

Note, that this weird convention to send a message to a nonexisting object to create itself is used both in UML 1.x and 2.x. In OOAD practice create message should probably be sent to the class, see Message in OOAD discussion for the backgound information. In Smalltalk-80 new objects are created by sending messages to classes, with an instance of the class created and returned back. So one way to interpret UML create message notation is probably as a shortcut for these actions.

Delete Message

Delete message (called stop in previous versions of UML) is sent to terminate another lifeline. The lifeline usually ends with a cross in the form of an X at the bottom denoting destruction occurrence.

UML 2.4 specification provides neither specific notation for delete message nor a stereotype. Until they provide some notation, we can use custom «destroy» stereotype.

Online Bookshop terminates Account.

Reply Message

Reply message to an operation call is shown as a dashed line with open arrow head (looks similar to creation message).

Web Client searches Online Bookshop and waits for results to be returned.

Messages by Presence of Events

Depending on whether message send event and receive events are present, message could be one of:

• complete message
• lost message
• found message
• unknown message (default)

The semantics of a complete message is the trace <sendEvent, receiveEvent>. Both sendEvent and receiveEvent are present.

Unknown message - both sendEvent and receiveEvent are absent (should not appear).

Lost Message

Lost Message is a message where the sending event is known, but there is no receiving event. It is interpreted as if the message never reached its destination. The semantics is the trace <sendEvent>, receiveEvent is absent. Lost messages are denoted with as a small black circle at the arrow end of the message.

Web Client sent search message which was lost.

Found Message

Found Message is a message where the receiving event is known, but there is no (known) sending event. It is interpreted as if the origin of the message is outside the scope of the description. This may for example be noise or other activity that we do not want to describe in detail. The semantics is simply the trace: <receiveEvent>, while send event is absent.

Found Messages are denoted with a small black circle at the starting end of the message.

Online Bookshop gets search message of unknown origin.

Conditional interaction

A message can include a guard, which signifies that the message is only sent if a certain condition is met. The guard is simply that condition between brackets.

If you want to show that several messages are conditionally sent under the same guard, you'll have to use an 'opt' combined fragment. The combined fragment is shown as a large rectangle with an 'opt' operator plus a guard, and contains all the conditional messages under that guard.

A guarded message or 'opt' combined fragment is somewhat similar to the if-construct in a programming language.

If you want to show several alternative interactions, use an 'alt' combined fragment. The combined fragment contains an operand for each alternative. Each alternative has a guard and contains the interaction that occurs when the condition for that guard is met.

At most one of the operands can occur. An 'alt' combined fragment is similar to nested if-then-else and switch/case constructs in programming languages.

Repeated interaction

When a message is prefixed with an asterisk (the '*'-symbol), it means that the message is sent repeatedly. A guard indicates the condition that determines whether or not the message should be sent (again). As long as the condition holds, the message is repeated.

The above interaction of repeatedly sending the same message to the same object is not very useful, unless you need to document some kind of polling scenario.

A more common use of repetition is sending the same message to different elements in a collection. In such a scenario, the receiver of the repeated message is a multiobject and the guard indicates the condition that controls the repetition.

This corresponds to an iteration over the elements in the collection, where each element receives the message. For each element, the condition is evaluated before the message is sent. Usually though, the condition is used as a filter that selects elements from the collection (e.g. 'all', 'adults', 'new customers' as filters for a collection of Person objects). Only elements selected by the filter will receive the message.

If you want to show that multiple messages are sent in the same iteration, a 'loop' combined fragment can be used. The operator of the combined fragment is 'loop' and the guard represents the condition to control the repetition.

Again, if the receiver of a repeated message is a collection, the condition is generally used to specify a filter for the elements.

For example, to show that the bounds of a drawing are based on those of its visible figures we could draw the following sequence diagram :

Several things are worth noting in this example

• a local variable 'r' was introduced to clarify that it is the result of getBounds that is added.
• naming the resulting Rectangle 'bounds' avoids the introduction of an extra local variable.
• the loop condition is used as a filter on the elements of the figures collection.

Ref:
http://www.uml-diagrams.org/sequence-diagrams.html

 http://www.tracemodeler.com/articles/a_quick_introduction_to_uml_sequence_diagrams/