Interaction Diagrams

Steven Zeil

Last modified: Jun 29, 2015
Contents:

UML Interaction diagrams describe how groups of objects collaborate in some behavior.


UML: Objects vs. Classes

Remember that, in UML, these represent classes:

 

But now we want objects:

 


Two Kinds of Interaction Diagrams

We’ll use these objects in two different kinds of interaction diagrams:

1 Collaboration Diagrams

An older technique for diagramming collaborations. These are easier to read for small, simple cases, but less useful for complicated sequences of messages.


Components of a Collaboration Diagram

 

1.1 Control Flow

1.1.1 Guards

There is a limited capacity for indicating control flow.

 

1.2 Sequencing

 
Collaboration diagrams work well in situations like this where the focus is on what the relevant messages are.

 

might not suffice.


Simple Sequencing

We can try to make things clearer by adding sequence numbers.

 

This can help a lot.


Nested Sequencing

Another possibility is to use nested sequencing calls, in which “x.y” indicates the y$^{\text{th}}$ step from within call# x.

 

This gets messy very quickly, however.


Collaboration Diagrams do not Scale Up

If we really want to get a handle on both the order and the cause of messages, we are better off using sequence diagrams.

2 Sequence Diagrams


Sequence Diagrams

These diagrams attempt to show, for some specific use-case or some common interaction:

2.1 Sequence Diagram Components


Sequence Diagram Components

Our domain or analysis models view the world as objects that interact by exchanging messages.


The Score Essay Use Case

Here is a sequence diagram for our “Score Essay” use-case. To help understand this, we’ll take this apart, one element at a time, looking at what each one shows us.

 

2.1.1 Objects

 

objectName : className

objectName : className

The colon (:) in front to the remaining name is our cue that

  1. This is still a representation of an object, not of a class, and

  2. The name that follows is a class name.

2.1.2 Time Lines

 

The dashed lines are called time lines.

2.1.3 Messages

 


Parameters and Return Values

As with any function calls, these can include parameters.


Sanity Check 1

Important Sanity Check: If you draw an arrow from one object of type C to an object of type T, and you label that arrow foo, then the class T must have a function named foo listed as one of its member functions.

then foo should be a responsibility of T and T should be a collaborator of C.

2.1.4 Activation Boxes

An activation of a function is the information associated with a particular call to that function, including all parameters, local variables, etc.


Activation Boxes

 

Sequence diagrams are all about time, so we sometimes need to indicate just how long a function call is active


When to Show Activation Boxes


More Sanity Checks

Sanity check 2: An incoming arrow to an activation box must connect to the very top of that box.

Sanity check 3: Every activation box must either

  • have exactly one incoming arrow, or

  • have no incoming arrows but belong to an autonomous object (e.g., a human) that initiates a task spontaneously (e.g., the scorer in this scenario).


More Sanity Checks

Sanity check 4: If a function body of foo calls a function bar, the activation box of bar must end above the end of the activation box of foo.

That’s just the way functions work.

Sanity check 5: If an activation box has an outgoing “return value” arrow, that arrow must emerge from the very bottom of the box.


More Sanity Checks

Sanity check 6: If an activation box has an outgoing “return value” arrow, that arrow must point back to the caller of that function activation.


Activations Can Overlap (nest) in Time

The call/activation box symbols can easily accommodate simultaneous activations of different functions on the same object.

Example

Suppose we have a spreadsheet in which cell B3 contains the fomula “A1+1” and that a new formula has recently been placed in A1. A spreadsheet is in the midst of a call to

// Re-evaluate all cells in the spreadsheet
int evaluateAll()   { 
  while(moreToEvaluate()) 
     partialEvaluate();
  return evaluationCounter;
} 

  • Each call to partialEvaluate causes one cell (e.g., A1) to be removed from a queue moreToEvaluate and then told to evaluate its formula.

    • If that evaluation changes the value in A1, it notifies any cells that are observing it (e.g., B3).
    • Those cells tell the spreadsheet that they require evaluation, and the spreadsheet adds them to the queue.
  • On a subsequent pass around the loop, the spreadsheet makes another call to partialEvaluate that results in B3 being pulled from the queue and evaluated.


Example: Seq Diagram

 

Observations:


Returns

If you have trouble following the sequence of calls and returns, you can add in the return arrows from the bottom of each activation box:

 

Personally, I find the extra arrows distracting and don’t recommend them for general use. Save them for circumstances where the data being returned in important to the understanding of the diagram (e.g., where you give a name to the returned value so that you can use that name later in the diagram).

2.2 Control Flow

2.2.1 Guards

Guards are conditions attached to messages to indicate conditional execution or loops.

 

2.2.2 Frames

UML 2.0 introduced frames to group messages

Most common varieties (identified by label):


Options and Loops

 


Reference Frames

We use an outer frame to name our diagram

 


Referring to Other Frames

And then can reference it in other diagrams