Interaction Design &
UML Sequence Diagram
• Once we have decomposed the system and
designed the individual components (or classes), we
need to depict how these pieces “collaborate” to
deliver the services. (of course, you may go back and redesign the components after looking at the collaboration)
• The interactions among the individual participants
(classes) can be captured with different UML
notations, but mainly through Sequence Diagrams
• Sequence diagram depicts the “message flow”
among the participants and thus depicts the
collaboration among the participants.
General Sequence Diagram
• It is composed of a
diagram frame:
1) with an identifier
name
2) the individual
participants (classes)
in the form of
“lifeline” composed
of:
• A rectangle
depicting the
participating object
• A dotted line that
extends for the time
period of the
interaction
3) messages to
communicate among
the participants
order process
client
order
inventory
create
locate item
Message Arrows for Communications
• The message arrows represent the communications
between two objects in a sequence diagram. It goes
from the lifeline of one object to that of another object
– Synchronous message where the sending object suspends
action and waits for the response to the message
(filled head)
– Asynchronous message where the sending object continues
with its operations without waiting for the response
(open head)
– A return of control from the synchronous message
– A creation of a new entity
Message Specification
• Every synchronous and asynchronous arrow must
be labeled with a message specification on top of the
message arrow.
See page 364 for details
• The message format :
of param list
return_variable_name = message_name (param_list)
–
Both the i) return_variable_name and ii) the “=“ sign are
suppressed if there is no return value
– message_name is never suppressed (required field)
– param_list is a list of arguments separated by commas and
is suppressed when there is no argument
Examples of Sequence Diagram’s message specification
•
age = getAge
–
•
or
age = getAge( )
message specifies that the return value from getAge
operation is assigned to the variable age. Note that age is
a variable accessible by the object that sent the message
checkStatus (flag = status, machine)
–
message specifies that checkStatus operation passes a
parameter and gets back the status information which
assigned to a “local” variable, flag. (local meaning the
object that sent the message)
Execution Occurrence in Sequence Diagram
•
•
•
•
An operation is executing
when a process is running
An operation is suspended
when it sends a
synchronous message and
waiting for a return
message.
An operation is considered
active when it is either
executing or suspended
An object is active if one or
more of its operation is
active. While an object is
active it is shown with an
execution occurrence (a
thin rectangle covering the
dashed line).
– A synchronous message
always initiates a new
execution occurrence
(e.g. order in the diagram)
sample
client
order
inventory
create(ord#)
locate_item(i)
Interaction Fragments
• Sequence diagram depicts the interactions among the entities.
The natural flow of “control” in the diagram is sequential from
top to bottom and follows the direction of the message arrows.
The natural sequential control can be “broadened” with
“Interaction Fragments”:
–
–
–
–
Optional Fragment
Alternative Fragment
Break Fragment
Loop Fragment
( “if –then” )
( “if-then-else-if - - -” or “case” )
( “break” )
( iterations or “loop” )
Note that these fragments are like the control structures that exist in
a high level programming language.
Depicting a Fragment Graphically
seq-dia sample
client
order
inventory
Interaction
Fragment
create
operator
Interaction
Fragment
Operation
Name:
(e.g. loop)
op1
Interaction Fragment
Operand
Locate item
Depicting an “Optional” Fragment
sd sample
client
Interaction
Fragment
Operation
Name:
(optional)
order
inventory
Interaction
Fragment
optional
[new_cust]
cr_custinfo()
Interaction
Fragment
guard
create_order
locate_item
Interaction Fragment
Operand
This Optional Fragment has only 1 operand and guard in brackets. A guard
is a Boolean expression. The Optional Fragment is performed if the guard is true at
that point of the interaction. It is like the “if” structure of programming language
Depicting an “Alternative” Fragment
sd sample
client
Interaction
Fragment
Operation
Name:
(Alternative)
order
inventory
Interaction
Fragment
alt
[new_cust=yes]
cr_custinfo()
Interaction
Fragment
guard
[new_cust= no]
get_custinfo()
Cr_order( )
Interaction Fragment
Operands
The Alternative Fragment has multiple mutually exclusive guards in brackets. The
operand associated with the true guard is executed. This structure is like the “CASE”
or “if-then-else-if” constructs of the programming language
Depicting an Break Fragment
sd sample
client
Interaction
Fragment
Operation
Name:
(Break)
break
order
inventory
[ ! good_status]
error_msg( )
alt
[new_cust=yes]
cr_custinfo()
The guard
expression of
NOT good_status
[new_cust= no]
get_custinfo()
Cr_order( )
The Break Fragment has a single operand which is processed if the guard is “true,”
and the rest of the processing in the diagram is not performed. It is like the “break”
construct in programming language.
Depicting an Loop Fragment
sd sample
order
inventory
n_it = check_items()
Interaction
Fragment
Operation
Name:
Loop (min,max)
iterator
create
checking for
more items
more = has_item (n_it)
Loop
[more]
Process_item()
The guard
expression of
[ more]
more = has_item(n_it)
** The Loop Fragment is expressed as Loop(min,max). The loop is performed at
least min times and at most max times. If neither min or max is specified, then min=0
and max is unlimited. If the loop is performed min times but less than max, then it is
performed again as long as the guard is true. The default value of guard is true.
Some Sequence Diagram Guidelines
• Pick a design level (based on the classes in the static model)
and “be consistent” at that level through out the interaction
diagram.
•
•
•
•
Put the sender of the first message leftmost
Put pairs of entities that interact heavily next to each other
Position the entities to shorten the message arrows
Position the entities to make the message arrows go from let to
right
• Suppress return arrows as much as possible when using
execution occurrences
Some Thoughts on Designing
1. Design is not a sequential process but much
more iterative: (“Component/Interaction” CoDesign)
–
–
Design (generate) the components in terms of
entities (with class model and express in class
diagram)
Design the interactions among the classes
(express in sequence diagram)
Iterate the above as we evaluate, alter, and improve the model
(See pages 376 -380 example in your book)
2. Design is not a single level process, but more
top-down: (Outside-In Design)
•
•
Top may be viewed as external (requirement level)
Down may be viewed class model and interactions
representing deeper levels of solutions
•And we progressively move into more details (inwards)
Some details on evaluating interaction alternatives
(Example)
waterHeatercntrl is constantly
polling the clock with a fixed
rate. - - - efficient for waterHeatercntrl?
Seq-D polling
Seq-D notification
waterHeatercntrl
loop
clock is constantly checking time and notifies
waterHeatercntrl when the time arrives, then
waterHeatercntrl takes action.
clock
clock
loop
waterHeatercntrl
notify
time=getTime
time=getTime
opt
[time = right]
takeAction
opt [time = right]
takeAction
Which one would you pick and why ?
Also, note the synchronous message creates an execution occurrence
On Control Mechanism
• In designing, one of the issue is on “point of control,”
or the controller, which makes decisions and directs
other components.
• There are three major ways to establish control:
– Centralized control where all decisions are made by one or two
entities and the rest of the entities receives directions from
them
– Delegated control where only the main decisions are made by
one or two “main” entities, other decisions are delegated to
lower level entities and coordinated among the entities.
– Dispersed control where decision making is spread out widely,
with no easily identifiable coordinating entity or entities.
Centralized Control
• Should be used only when the solution is small and
only a few decisions are involved. (easy to find control
point)
• Lots of drawbacks:
– Centralized control can be “bloated” and too big to manage
– May be less cohesion when too many varieties of decisions are
being made
– May increase coupling between the controller and other entities
which merely act as data store or simple functions
– Information hiding can NOT be easily achieved due to coupling
Central contrl
Heuristics to Avoid Centralized Control
1.
2.
3.
4.
Avoid interaction design where most messages originate from
single component
Keep components small so that there can not be a “bloated”
controller. (This is not very different from the traditional advise
on keeping modules small - - - how small is small? --cohesion?)
Make sure that operational responsibilities are not assigned to
just a few components.
Make sure operational responsibilities are consistent with data
responsibilities. (what happens if they are not? - - - you may
have less cohesion among methods in a class )
Look at diagram 12-3-3 on page 386: it is an over-centralized control design:
- AutoCycle delegates nothing and is coupled with all other objects
- it lacks cohesion in that it is doing all types of details
- it is too big in size because it contains all the low level activities
Delegated Control
• Control is in more entities – smaller in size
• Information hiding is easier with different control
points
• Increased cohesion with delegated points of control
• Each controller is coupled to less entities. (but overall # of couplings may not decrease)
(Note: the 1st to 4th object interaction is asynchronous)
Delegated contrl
Heuristics for Delegated Control
•
Delegated control is the ideal case we are
after.
1. Ensure that each component is responsible for
“high level” tasks and as much of the lower
( more detailed, less functional, just different
functional areas, etc.) level tasks are delegated
as possible.
2. The lower level tasks may be performed in a
more collaborative manner among several other
components.
Look at diagram 12-3-4 on page 387, where AutoCycle delegates some
responsibilities to Zone. This is a much less coupled and a more cohesive
design along with a certain amount of encapsulation of information.
Dispersed Control
• Too many controls and hard to figure out the
interactions:
– Too much interactions among the entities – high
coupling among the parts and possibly very low
cohesion within each entity.
Heuristics for avoiding Dispersed control
• Basically, avoid situations where every
component is sending a lot of messages to
other components.
• Ensure that there is not an over-delegation,
where each component is responsible for too
a small portion of the whole and there are a
lot of components involved in accomplishing
anything.
Control and Communications
delegated &
hierarchical
centralized &
wheel
(n-1) potential coupling
but deceiving because - -?
(n-1) potential coupling
but deceiving because - -?
dispersed &
all-member
[(n x (n-1))/ 2]
potential coupling
Law of Demeter for OO Interaction Design
• An operation (method M) of an object, Obj,
should send messages only to the following:
– Within the object, Obj, itself
• Methods within Obj
• Attributes of Obj (its instance variables)
– Argument of the operation (parameters of method M, which
may be some object)
– Elements of a collection that is an argument of the
operation or an attribute of the object, Obj.
– Objects created within the operation (objects instantiated
within the method M)
– Global Classes or objects
Note that objects that are returned by messages sent to other object is not included.
“ Talk only to your immediate neighbors”
The Law of Demeter is meant to help in : (1) information hiding;
(2) lessening centralized control
Example from page 375 of text
• Design a water heater controller based on:
• Caldera is a smart water heater controller that attaches to the
thermostat of a water heater and provides more efficient control
of water temperature to save money and protects the
environment.
• Caldera sets the water heater thermostat high when hot water is
much in demand and sets it low when there is no much demand.
For example:
– Caldera can be told to set the thermostat high on weekday mornings
and evenings and all day on weekends.
– And low during the middle of the week days and nights.
– Caldera can be told to set the thermostat high all the time in case of
illness or other needs.
– Caldera can be told to set the thermostat low all the time in case of
vacation or some other prolonged absence from house.
Your Caldera Design may progress as follows:
1. Class Model
heaterController
set_temp
thermostat
sd Caldera
heaterController
2. Class
Interactions
set_temp( )
thermostat
Your Caldera Class Design (further
Refinement) ?
heaterController
set_temp
thermostat
clock
manual
calendar
3. Further “Refined” Class Model
Your Caldera Interaction Design (further
Refinement) ?
sd Caldera
heaterController
Calendar
Clock
thermostat
manual
Set_temp( )
Notify_date( )
Notify_time( )
Special_set( )
Set_temp( )
4. Refined Class Interactions in Sequence Diagram
Further Evaluate and Improve the Caldera
Design
1.
Consider the notion of adding another entity to
represent the notion of “load scaling” or “temp
scaling” which traps the inputs from clock and
calendar and sends the controller a binary high or
low signal.
1.
Consider the manual override to go directly to
thermostat and be equal to the controller.
Draw the Class diagram and the Sequence diagram for these concepts,
evaluate and see if they are indeed improvements:
- cohesion
- coupling
- size