Sequence Diagrams

Collaborations and Components

A collaboration is a group of classes that work together to implement a component.

A collaboration instance is a group of objects that work together to implement a component instance.

A collaboration instance is just the runtime instantiation of a collaboration.

Components can be software components, hardware components, or business components.

The structure of a collaboration is given by a class diagram. The structure of a collaboration instance is given by an object diagram.

The interaction between the members of a collaboration can be given by a sequence role diagram or by a collaboration role diagram.

The interaction between the members of a collaboration instance can be given by a sequence diagram or a collaboration diagram.

I find Sequence/Sequence Role diagrams easier to understand than Collaboration/Collaboration Role diagrams and more fun to draw. Therefore I will only cover the former.

Sequence Diagram Elements

Objects, Roles, and Lifelines

Sequence diagrams and sequence role diagrams are identical except that in a sequence diagram collaborators are objects while in a sequence role diagram collaborators are roles.

A role is sort of like an abstract or generic object. Different concrete objects can be plugged into a role.

A lifeline dangles under a role or object. This represents the lifetime of the role or object. Time is assumed to flow downward.

Here are some examples of roles:

Here are examples of objects:

Use roles when modeling a collaboration. Use objects when modeling a collaboration instance.

Stimulus/Message

Objects send stimuli to one another, while roles send messages. Other than that, the distinction seems unimportant.

There are five types of messages/stimuli: Call, Send, Return, Create, and Destroy. Objects/Roles can also send messages/stimuli to themselves. The following diagram shows all five types:

The sender begins by calling its own demo method. The yellow bar indicates the period of time that this method is running. The demo method creates a new instance of the ReceiverClass called receiver. At the end of the demo method the receiver will be destroyed.

Next, the sender calls the receiver's m1 method with inputs a1 and a2. This is a conditional call. It only is made if guard is true. The return value is stored in a variable called result. Alternatively, the returned result can be shown by the return message sent from the receiver back to the sender. Calling a method is an example of a synchronous message. The sender blocks until the receiver is finished processing the message and has returned a value or sent some sort of acknowledgement.

Next, the sender sends the message m2 with inputs a3 and a4 to the receiver. This message is sent again and again until the guard condition becomes false. Sent messages are asynchronous. The sender does not need to wait for a reply. Sending messages requires that the receiver has some sort of message queue where the messages can be stored until the receiver has time to process them. Once a message has been stored in a queue, the sender can go on to do other things.

Here is how this sequence diagram might be expressed in C++:

class SenderClass {
public:
   void demo() {
      ReceiverClass* receiver = new ReceiverClass();
      if (guard) result = receiver->m1(a1, a2);
      while(guard) receiver->msgQueue << m2(a3, a4);
      delete receiver;
   }
   // etc.
};
     

Example

The scenario:

A client selects a menu item on a control panel. In response, the control panel creates a command and asks a command processor to execute it. The command processor asks the command to execute itself, stores the result, deletes the command, then returns the result to the control panel to be displayed.

The sequence diagram:

 

Combined Fragments and Interaction Operands

Fragments of sequence diagrams can be identified and qualified.

Options (One-Way Conditionals)

An optional fragment is only executed if some guard condition is true:

Alternatives (Multi-Way Conditionals)

An alternative fragment provides several guarded alternative fragments (separated by interaction operands):

Loops

A loop allows a fragment to be repeated until some guard condition becomes false:

Break

A break allows an enclosing loop to be escaped when some guard becomes true:

Parallel

A parallel fragment allows multiple interactions to run in parallel:

Other Fragment Types

Strict

Assert

Consider

Ignore

Region

Neg

Frames

A frame provides a way to encapsulate a sequence diagram.

A frame can be referenced in another sequence diagram:

Examples

Protocols

Collaborations

Scenarios

Signals and Receptions

An auctioneer broadcasts a proposed price for an item to a crowded room of anxious bidders. When a bidder hears the proposal he decides to accept the price or not.

In an automated auction, how will the auctioneer broadcast the proposal? An object may have designated operations that should automatically be called if certain types of broadcast signals are received. These methods are called receptions. Signals are a special kind of class. The name of the reception usually matches the name of the signal. Receptions are shown in a separate compartment:

 

In a sequence diagram we can represent a signal as an asynchronous signal, and the reception as a reception invocation: