Week 6. Objects interaction - Sequence Diagram
A special kind of the diagrams exists in UML in order to refine objects responsibilities and communication interfaces – Interaction diagrams. There are two of them – Sequence Diagram and Collaboration Diagram. We start with Sequence Diagram.
Sequence Diagram is designed to show:
The objects or classes participating in a workflow through a use case.
The messages (methods calls) that are sent between the objects. Through a message, one object or class can request another one to perform some activity. Message is an instruction to do something. Messages are ordered by time. Activities are implemented as the methods; therefore a caller should invoke a method in order to initiate some activity in a receiver object.
Sequence Diagram is the cornerstone upon which the rest of the design is built. When we create the diagram we are assigning responsibility to objects. Each message sent to some particular class assumes that the receiver class contains the method to capture the message and process it.
The fact of sending messages means that the association relationship exists between the classes.
So, doing with the sequence diagram we refine classes, assign the responsibility to classes and identify the class relationships. Altogether it leads to a Class Diagram and then to source code.
Tentatively you may assume that for each use case we need a sequence diagram. Sequence
Diagram incorporates 3 things – Actors, Objects (or Classes) and Messages.
Actors are known from the use case diagrams. It could be just one or a few actors for each diagram.
Finding objects
Both use case and activity diagrams should be used to determine the objects. Examine the nouns in use case and the activity diagram. Another good place to look is the functional scenarios in the
Functional Requirements document. As you look at the nouns, some of them will be Actors, some of them will be objects, and some of them will be attributes of an object. When you build a sequence diagram it becomes clear what is what.
Model – View – Controller objects responsibility
Model – View – Controller (MVC) concept considers the following categories of objects:
 Model. These are objects that hold information. Most of them eventually map to the tables or fields in the database. As well they carry on core business functionality.
 View. These are objects that lie between the system and end users. They represent GUI.
 Controller. These are objects that intercept end user’s events and transfer the signal to model or other control object. They are attached to views, one controller to one view.
Apart those designated controller objects there can be other control objects that control the flow through the use case. Control objects do not carry any business functionality themselves. Instead they coordinate other objects and control the overall work flow.
1

Messages
Through a message one object or class can request that another object performs some specific function. When you add the message you assign a responsibility to the object receiving the message. Be sure the message is assigned to the appropriate object. Consider the object categories to test yourself. Entity objects (Model) should hold information and conduct business functionality. View objects (form and windows) should display and receive information.
Controllers should take care about events intercepting and directing.
Sequence Diagram Development Technique
First Stage. Actors, Objects and messages.

Take one particular Use Case.

Consider Actors you identified in Use Case, objects you have identified from Use Case and Activity Diagram or other sources of information.

In Logical View create classes

In Logical View create Sequence Diagram, name it and open

To begin with, consider Controller and View as black boxes. Concentrate on Model.
Assume that all Views are represented by View, and all the controllers are represented by a single Controller object. Also assume that all operations with relational database are implemented by DAO component.

Place Actor, View, Controller and entity classes one by one on the top of the diagram window.

Vertical line of the diagram represents sequence of messages along the time. Think about functional scenario implementation in the terms of messages (instructions) your objects are sending each other. Start from your Primary Actor – End User.

Draw the lines to show messages. When you see the message from the end user, draw the line from your Primary Actor to View. Next steps may be one of the following: o View to Controller o Controller to Model o Model to other Model, or to View (the same or different), or to DAO

Name your messages.

Store the diagram.
Second Stage. Mapping the Sequence Diagram Messages to Classes Operations
Each message is to be assigned to the method of the receiver class. You have classes in the logical view. At this early stage the first thing is to define attributes and methods for each class.
In a message specification window there will be all methods available at the moment, shown to you. You can select existing one or to create a new one, which immediately will be included into the class structure.
It is helpful to remember the basic approach of object-oriented programming – that this is
“event-driven programming”. Simply speaking objects provide their functionality in response to some events occurrence. Messages are supposed to convey information about events and to invoke the class operations. Define classes and operations with the encapsulation in mind. It means that the class methods can operate with a given class native attributes or with the other class reference attributes visible from a given class.
When mapping messages to the operations we switch our attention from the message sender to the message receiver – classes where the operations must be located. You may want to correct your sequence diagram.
2

Collaboration Diagram
Collaboration diagram gives another view to the objects interaction that is useful to test the sequence diagram. It can be created automatically. Having the sequence diagram open go to
Browse and select the appropriate function.
Reminder:
Association relationship assumes that reference attributes (pointers) are created accordingly to the association definition. It allows the following communication mechanisms:
Class A ---------

Class B
Method()
B.Method()
3