Download Visual Case Free for 30 Days

Visual Case Tool - UML Tutorial

4. Interaction Diagrams - Sequence and Collaboration

Once the use cases are specified, and some of the core objects in the system are prototyped on class diagrams, we can start designing the dynamic behaviour of the system.

Recall from the Use Case page of this tutorial, that a use case encompasses an interaction between a user and a system.  Typically, an interaction diagram captures the behaviour of a single case by showing the collaboration of the objects in the system to accomplish the task.  These diagrams show objects in the system and the messages that are passed between them.

Let's start with the simple example above: a user logging onto the system.  The Logon use case can be specified by the following step:

1. Logon dialog is shown

2. User enters user name and password

3. User clicks on OK or presses the enter key

4. The user name and password are checked and approved

5. The user is allowed into the system

Alternative: Logon Failed - if at step 4 the user name and password are not approved, allow the user to try again

Now that we have a simple Use Case to work with, we can specify some of the classes involved in the interaction.

The LogonDialog has public methods to show and hide the window, and a private method that is called when the user presses the ok button or clicks enter.  For our example (and indeed most cases) you need not specify the interface elements of the dialog. 

Our design also includes a LogonManager class that will include one method that returns true if the logon is successful, false if it is not.

A DatabaseAccess class will allow us to run queries against our database.  We can pass a query string and a ResultSet of data will be returned.

Now that we have prototyped the classes involved in our interaction, we can begin to make our interaction diagrams.

Instances and Messages

Interaction diagrams are composed mainly of instances and messages.  An instance is said to be the realization of a class, that is if we have a class Doctor, than the instances are Dr. Jones, Dr. Smith, etc..  In an object oriented application, instances are what exist when you instantiate a class (create a new variable with the class as its datatype).

In the UML, instances are represented as rectangles with a single label formatted as:

instanceName: datatype

You can choose to name the instance or not, but the datatype should always be specified.

Below the name, you can also list the attributes and their values.  In Visual Case, you can map attributes from your class and enter new values specific to that instance.  Attributes need only be shown when they are important and you don't have to specify and show all of the attributes of a class.

Messages represent operation calls.  That is, if an instance calls an operation in itself or another class, a message is passed.  Also, upon the completion of the operation a return message is sent back to the instance that initiated the call.

The format for message labels is:

Sequence Iteration [Guard] : name (parameters)

Sequence: represents the order in which the message is called.  The sequence is redundant on sequence diagrams, but required on collaboration diagrams

Sequence Diagrams

There are two types of Interaction Diagrams - Sequence and Collaboration.  Sequence diagrams emphasize the order in which things happen, while collaboration diagrams give more flexibility in their layout.  You can use whichever you prefer when drawing interactions, as both show the same information.

An example sequence diagram for our logon collaboration is shown:

Things to Note:

• The flow of time is shown from top to bottom, that is messages higher on the diagram happen before those lower down

• The blue boxes are instances of the represented classes, and the vertical bars below are timelines

• The arrows (links) are messages - operation calls and returns from operations

• The hide and show messages use guards to determine which to call.  Guards are always shown in square braces [ ] and represent constraints on the message (the message is sent only if the constraint is satisfied)

• The messages are labelled with the operation being called and parameters are shown.  You can choose to enter the parameters or not - this is dependent upon their importance to the collaboration being shown

• The sequence numbers are not shown on the messages as the sequence is intrinsic to the diagram

Asynchronous Messages

You can specify a message as asynchronous if processing can continue while the message is being executed.  In the example below, the asynchronous call does not block processing for the regular call right below.  This is useful if the operation being called is run remotely, or in another thread.

Collaboration Diagrams

Collaborations are more complex to follow than sequence diagrams, but they do provide the added benefit of more flexibility in terms of spatial layout.

Above is our logon interaction shown as a collaboration diagram.  Notice that each message is numbered in sequence, because it is not obvious from the diagram, the order of the messages.

Lollipop Interfaces

Another advantage over the sequence diagram is that collaboration diagrams allow you to show lollipop interfaces.

Suppose that our DatabaseAccess class implemented an interface called Queryable.  If the logon manager only has access to the interface, we can show that the message is called through the interface by including a lollipop interface on the diagram.  The stick of the lollipop indicates that the class DatabaseAccess realizes Queryable.

Putting it all Together

Using interaction diagrams, we can clarify the sequence of operation calls among objects used to complete a single use case.  When drawing these diagrams, try to keep them as clear and simple as possible.  Sequence diagrams are easy to read and follow, as they enforce a standard layout on the diagram.  Collaborations have the added advantage of interfaces and freedom of layout, but can be difficult to follow, understand and create.

It's also important not to confuse interaction diagrams with state and activity diagrams.  Interaction diagrams are used to diagram a single use case.  When you want to examine the behaviour of a single instance over time use a state diagram, and if you want to look at the behaviour of the system over time use an activity diagram.

Visual Case^TM  is a trademark or registered trademark of Artiso Corp. Canada.

Microsoft, Windows, SQL Server, VB, Visual Basic and Access are registered trademarks of Microsoft Corporation.
Oracle is a registered trademark of Oracle Corporation.
Unified Modeling Language and UML are trademarks of Object Management Group Inc. in the U.S. and other countries.
Other brands and their products are trademarks or registered trademarks of their respective holders and should be noted as such.