Interaction Design

1
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 re-design 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.

2
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
3
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
• Asynchronous message where the sending object
  continues with its operations without waiting for
  the response
• A return of control from the synchronous message
• A creation of a new entity

(filled head)
(open head)
4
Message Specification

• Every synchronous and asynchronous arrow must be
  labeled with a message specification on top of
  the message arrow.
• The message format
• 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

See page 364 for details of param list
5
Examples of Sequence Diagrams 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)

6
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)
7
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 ( if then )
• Alternative Fragment ( if-then-else-if
  - - - or case )
• Break Fragment ( break )
• Loop Fragment ( iterations or
  loop )

Note that these fragments are like the control
structures that exist in a high level programming
language.
8
Depicting a Fragment Graphically
seq-dia sample
client
order
inventory
Interaction Fragment
create
operator
op1
Interaction Fragment Operation Name (e.g. loop)
Interaction Fragment Operand
Locate item
9
Depicting an Optional Fragment
sd sample
client
order
inventory
Interaction Fragment
Interaction Fragment Operation Name (optional)
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
10
Depicting an Alternative Fragment
sd sample
client
order
inventory
Interaction Fragment
Interaction Fragment Operation Name (Alternative)
alt
new_custyes
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
11
Depicting an Break Fragment
sd sample
client
order
inventory
Interaction Fragment Operation Name (Break)
break
! good_status
error_msg( )
alt
new_custyes
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.
12
Depicting an Loop Fragment
sd sample
order
inventory
n_it check_items()
checking for more items
Interaction Fragment Operation Name Loop
(min,max)
create
iterator
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 min0 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.
13
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

14
Some Thoughts on Designing

• Design is not a sequential process but much more
  iterative (Component/Interaction Co-Design)
• 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)
• 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

Iterate the above as we evaluate, alter, and
improve the model (See pages 376 -380 example in
your book)

• And we progressively move into more details
  (inwards)

15
Some details on evaluating interaction
alternatives(Example)
waterHeatercntrl is constantly polling the clock
with a fixed rate. - - - efficient for
waterHeatercntrl?
clock is constantly checking time and notifies
waterHeatercntrl when the time arrives, then
waterHeatercntrl takes action.
Seq-D polling
Seq-D notification
waterHeatercntrl
clock
waterHeatercntrl
clock
loop
notify
loop
timegetTime
timegetTime
opt
opt
time right
time right
takeAction
takeAction
Which one would you pick and
why ? Also, note the synchronous message creates
an execution occurrence
16
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.

17
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
18
Heuristics to Avoid Centralized Control

1. Avoid interaction design where most messages
   originate from single component
2. 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?)
3. Make sure that operational responsibilities are
   not assigned to just a few components.
4. 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
19
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
  over-all of couplings may not decrease)

(Note the 1st to 4th object interaction is
asynchronous)
Delegated contrl
20
Heuristics for Delegated Control

• Delegated control is the ideal case we are after.
  
• 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.
• 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.
21
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.

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

23
Control and Communications
centralized wheel
dispersed all-member
delegated hierarchical
(n x (n-1))/ 2 potential coupling
(n-1) potential coupling but deceiving because -
-?
(n-1) potential coupling but deceiving because -
-?
24
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
25
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.

26
Your Caldera Design may progress as follows
heaterController
thermostat
set_temp
1. Class Model
sd Caldera
heaterController
thermostat
2. Class Interactions
set_temp( )
27
Your Caldera Class Design (further Refinement) ?
heaterController
thermostat
set_temp
notify_time
special_set
notify_date
clock
manual
calendar
3. Further Refined Class Model
28
Your Caldera Interaction Design (further
Refinement) ?
sd Caldera
heaterController
thermostat
Calendar
Clock
manual
Set_temp( )
Notify_date( )
Notify_time( )
Special_set( )
Set_temp( )
4. Refined Class Interactions in Sequence Diagram
29
Further Evaluate and Improve the Caldera Design

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