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.
  • Although sequence diagrams can be used to illustrate any interesting collaborations (sequences of related messages) among our objects, 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.

Seq Diagrams: 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.

  If it seems confusing to use rectangles for both, there is a consistent way to tell them apart. In UML, the general form for an object declaration is

  objectName : className

  For example, chkTrans:Transaction indicates that we have an object named “chkTrans” of type “Transaction”.

  Quite often, we know we want to discuss an object, but don’t really care to give it a name. For example, in all of our use-cases so far, there has been only a single checkbook. We know that it will be a member of the Checkbook class, but if we actually give it a name, the reader will think that’s something they are supposed to remember. Then, if we never actually use that name, we’ve distracted the reader for no good reason.

  So UML allows to drop the object name:

  objectName : className

  as we have done for several of the objects in the diagram above, including the checkbook.

  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.

  In essence, we have an anonymous object of a known class.

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. We’ll see examples of this later.

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 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.

• If your CRC cards are still valid (eventually we abandon them as we move along in the analysis process) then foo should be a responsibility of T and T should be a collaborator of C.

Activations   

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 (i.e., how long we are executing its body or executing other function bodies called from it).

• 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

Now, a sequence diagram indicates the flow of time, but it’s not a strict graph. We can’t say that one inch of vertical space equals some number of seconds. All that we can say is that if A is drawn below B, than A occurs after B.

Look, then at the applyTo call from the scorer to the rubric. You can see an activation box starting there, indicating the start of the function body of EssayRubric::applyTo. A little time after that, you see an arrow emerging from that box. That arrow indicates that this function body of applyTo eventually calls comcept.match(essayresponse). There you see another function body (of match) start to execute.

The particular drawing tool that I use insists on putting short activation boxes at the end of every call. If there are no further outgoing calls (e.g., getNormalMinimum()), these boxes are optional. A message arrow with no activation box on the end simply indicates that the function call issues no interesting messages of its own.

A function body that does issue a message must show an activation box so that we can see whence that message comes.

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 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.

• If foo calls bar, then foo can’t actually do anything (including returning to its own caller) until after bar 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 Overlap (nest) in Time   

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

// 
Re
-
evaluate 
all 
cells 
in 
the 
spreadsheet





int 
evaluateAll
() 
{




 
while
(
moreToEvaluate
())




 
partialEvaluate
();




 
return 
evaluationCounter
;





}
  

Example   

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.
• 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.