Interaction Diagrams
Steven Zeil
UML Interaction diagrams describe how groups of objects collaborate in some behavior.
- Important: these diagrams are about objects. The UML class diagrams that we looked at earlier are about (surprise!) classes.
UML: Objects vs. Classes
Remember that, in UML, these represent classes:
But now we want objects:
-
Note the underlining and non-bold face.
-
The syntax for the text describing the object is similar to the attributes in the class diagrams.
Two Kinds of Interaction Diagrams
We’ll use these objects in two different kinds of interaction diagrams:
-
Sequence diagrams
-
Collaboration 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
-
The main components of a collaboration diagram are objects
-
Objects that exchange messages are joined by links, shown as solid lines running from one object to another.
-
If one object passes a message to (calls a member function of) another, we write the message name alongside the link, with an arrow showing the direction of the message.
1.1 Control Flow
1.1.1 Guards
There is a limited capacity for indicating control flow.
-
A guard indicates that a call is conditional. Guards are written as boolean expressions inside square brackets.
-
An
*
in front of a call indicates that the call can be performed multiple times. -
This is often followed by a guard representing the loop condition.
1.2 Sequencing
- But if the order of the messages is important to understanding the collaboration, then something like this
might not suffice.
Simple Sequencing
We can try to make things clearer by adding sequence numbers.
- The easiest way to do this is to simply order the calls in time.
This can help a lot.
- Note, however, that it’s far from clear just which of these calls are in response to which other calls.
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:
-
what objects are involved
-
what operations are involved, and on which objects
-
what the sequence of operations is
2.1 Sequence Diagram Components
Sequence Diagram Components
Our domain or analysis models view the world as objects that interact by exchanging messages.
- Sequence diagrams allow us to demonstrate that our model suffices to represent a use case by mapping the steps of the use-case into specific messages (function calls) from one object to another.
-
we most often draw one sequence diagram for each use case.
-
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
-
A sequence diagram is composed of a number of columns, each headed by an object.
- Human objects are often indicated by a stick figure. In general, objects are shown as rectangles.
-
Note that, unlike in the class relationship diagrams, the rectangles here denote individual objects, not classes.
objectName : className
objectName : className
The colon (:) in front to the remaining name is our cue that
-
This is still a representation of an object, not of a class, and
-
The name that follows is a class name.
2.1.2 Time Lines
The dashed lines are called time lines.
-
As we move from the top of the diagram towards the bottom, we are moving forward in time.
-
Something that is drawn below a particular event actually occurs after it in our scenario.
-
If an object is created/destroyed as part of a scenario, it will be shown as a shorter time line.
2.1.3 Messages
- Each solid arrow denotes the passing of a message from one object to another.
Or alternatively, a function call made by some code associated with the first object, calling a member function of the second object.
Parameters and Return Values
As with any function calls, these can include parameters.
- Functions can also have return values, shown as an arrow with a dashed line.
-
Normally, show these only when they are important to the understanding of a diagram (e.g., they match one of the named objects)
-
Sanity Check 1
Important Sanity Check: If you draw an arrow from one object of type
C
to an object of typeT
, and you label that arrowfoo
, then the classT
must have a function namedfoo
listed as one of its member functions.
- If your CRC cards are still valid
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.
- If a function is recursive (calls itself or calls other functions that eventually call it), it can have multiple activations in memory at any given time.
Activation Boxes
Sequence diagrams are all about time, so we sometimes need to indicate just how long a function call is active
- An activation box marks off the time from the start of execution of a function body to when we return from that body to its caller.
When to Show Activation Boxes
- You must show activation boxes if a the body of a called function makes other calls of its own, or if a function has a return arrow.
-
Activation boxes are essential to demonstrating cause-and-effect within the model
-
More Sanity Checks
Sanity check 2: An incoming arrow to an activation box must connect to the very top of that box.
- We do not have psychic functions that suddenly start executing themselves in anticipation of being called at some time in the future.
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 functionbar
, the activation box ofbar
must end above the end of the activation box offoo
.
That’s just the way functions work.
- If
foo
callsbar
, thenfoo
can’t actually do anything (including returning to its own caller) until afterbar
returns.
Sanity check 5: If an activation box has an outgoing “return value” arrow, that arrow must emerge from the very bottom of the box.
- Function bodies do not hang around chatting after they return control to their caller.
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.
- That’s just the way functions work!
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:
-
The call to partialEvaluate() is a call from one member function of an object to another member function of the same object.
-
We often choose not to show these because they really have little to do with the idea of whther the public interface fo a class is OK.
-
Instead, usually concentrate on inter-object messages.
-
-
We have “unrolled” the loop in this diagram because I wanted to show the specific cells being manipulated each time around the loop.
-
We’ll see other approaches to handling loops shortly.
-
-
Note the stacking of the activation boxes on the SpreadSheet timeline to illustrate nested periods of time.
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.
-
Guards are OK if only one call is repeated/conditional
-
They become confusing when a sequence of messages are affected.
2.2.2 Frames
UML 2.0 introduced frames to group messages
Most common varieties (identified by label):
-
diagram label
-
loop: repeated messages
-
opt: conditional messages
-
alt: if-then-else like construct
-
ref: reference to another diagram, becomes a “black box” in this diagram
Options and Loops
-
Grouping is indicated very naturally by the area of the enclosing rectangle. We can nest frames if we need to.
-
We use guard expressions (in the
[ ]
) to indicate loop and option conditions.
Reference Frames
We use an outer frame to name our diagram
Referring to Other Frames
And then can reference it in other diagrams
- These allow you to break up sequence diagrams into pieces and have some diagrams “include” or refer to other diagrams.