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

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

8. Depicting a Fragment Graphically
sd 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)
Opt
[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_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

11. Depicting an Break Fragment
sd sample
client
order
inventory
Interaction
Fragment
Operation
Name:
(Break)
break
[ ! 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.

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

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 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.
SD polling
SD notification
clock
waterHeatercntrl
waterHeatercntrl
clock
loop
notify
loop
time=getTime
time=getTime
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
Central contrl

18. Heuristics to Avoid Centralized Control
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 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 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
Notify_date( )
Set_temp( )
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