Copyright W.
Howden 1
Lecture 6: Collaboration
Diagrams
Context - 1
Interaction sequence diagrams show:
interactions of actors with the whole system
(via the GUI/View layer/subsystem)
interactions between subsystems
illustrates how the GUI/View sends messages to
other subsystems, and how they cooperate to
perform some responsibility
Copyright W. Howden 2
Context - 2
Messages received by subsystems
in our design, messages received by the
interface class for a subsystem
corresponds to a method in the interface class
(i.e. an instance of it) being executed
corresponds to a task/request/event to which the
subsystem must respond
Copyright W. Howden 3
Context - 3
Subsystem responses
for each request, we have to design how the
subsystem will respond
creation of new subsystem classes to fulfill
those responsibilities
design for change
design for intellectual manageability
use design patterns and basic design patterns
Copyright W. Howden 4
Copyright W. Howden 5
Collaboration Diagrams
Use for subsystem and class design
Will use to show event responses
Event receiving a message
how should the entity (e.g. subsystem/subsystem-
interface) react to this?
Diagrams will show auxiliary objects that
we will create as part of the design
leads to definition of new subsystem classes
Copyright W. Howden 6
Collaboration Diagram
Components
Objects
Messages
One object sends a message to another message
Sequencing of messages
various notations can be used here
Copyright W. Howden 7
2b: [userName=/ name] result :="Not logged on"
3b: [2a & memberData == null] result = "NotAMember"
5: [2a & 3a] result = "UpdateMade"
2a: [userName==name] memberData
= getMemberData(userName)
4: [2a & 3a] updateMemberData(memberData)
1: userName = getUserName()
result = setMemberData
(name, dateeData) :String
dL : DomainLogic
dB : DataBase
logOn : LogOn
memberData : MemberData
3a: [2a & memberData/= null]
setDateeData(dateeData)
Domain (Business) Logic subsystem updates a member's data
Copyright W. Howden 8
Message Sequence Notation
Dont number first message, we are showing how
the object responds to this initial event
Complicated situations:
Conditional branching
Nesting of (sub) operations
Compound conditionals
Copyright W. Howden 9
Notation: Conditionals
Alternative choices of message flows
1. Precede messages with constraints/guards
E.g. [userName == name] .
2. Use lettered notation to indicate alternative
message flows
E.g. 2a, 2b; 3a, 3b in the example
Copyright W. Howden 10
Conditionals Example
Used to indicate choices based on specified
conditions. Either 1a or 1b is done, then 2 is
done
Object1
Object2
Object3
1
a
:
[
c
o
n
d
]
m
1
(
)
1b:[not cond] m2()
Object4
2
:
m
3
(
)
Object5
Copyright W. Howden 11
Nesting and Sub-Operations
Nested inside the response to message m1,
is the sending of messages m2 then m3,
done before returning from m1
Object1 Object2
Object3
Object4
1: m1() 1.1: m2()
1
.
2
:
m
3
(
)
Object5
Copyright W. Howden 12
Compound Conditions
How to number structures such as?
if a then
if b then {c, d}
else e
else g
Nested numbering already used up for sub-
operation nesting so just repeat the
condition
Copyright W. Howden 13
2b: [userName=/ name] result :="Not logged on"
3b: [2a & memberData == null] result = "NotAMember"
5: [2a & 3a] result = "UpdateMade"
2a: [userName==name] memberData
= getMemberData(userName)
4: [2a & 3a] updateMemberData(memberData)
1: userName = getUserName()
result = setMemberData
(name, dateeData) :String
dL : DomainLogic
dB : DataBase
logOn : LogOn
memberData : MemberData
3a: [2a & memberData/= null]
setDateeData(dateeData)
Domain (Business) Logic subsystem updates a member's data
Copyright W. Howden 14
Notation - Names
Lower case
Specific: objects, messages, instances instances,
instance variables
Upper Case
General: Classes, Types, Associations in
Domain Models
Copyright W. Howden 15
2b: [userName=/ name] result :="Not logged on"
3b: [2a & memberData == null] result = "NotAMember"
5: [2a & 3a] result = "UpdateMade"
2a: [userName==name] memberData
= getMemberData(userName)
4: [2a & 3a] updateMemberData(memberData)
1: userName = getUserName()
result = setMemberData
(name, dateeData) :String
dL : DomainLogic
dB : DataBase
logOn : LogOn
memberData : MemberData
3a: [2a & memberData/= null]
setDateeData(dateeData)
Domain (Business) Logic subsystem updates a member's data
Copyright W. Howden 16
Notation - Iteration
Use star notation to indicate repetition of a
message
Iterated sequence of messages: match iterated
conditions, possible ambiguity
Stacked icons indicate object collections
Additional notation: anonymous objects
Copyright W. Howden 17
memberData = execute(): MemberData
2*: [until result = true or memberData = nil] result =
match(dR.daterPreferences, memberData.dateeData)
1*: [until result = true or memberData=nil] memberData = getnext()
dR : DateRequest : DateMatchExpert
:MemberData
Copyright W. Howden 18
Notation: Object Creation
Diagrams show messages from one object
to another
How to show creation of an object?
Notational convention: send it a create
message
: LogOn
create(name)
1: userName = name
Copyright W. Howden 19
Discovery of Classes and
Methods
Collaboration Diagrams show objects for
which we will develop classes
Messages that are sent to Classes/Objects
will be methods in the classes
Copyright W. Howden 20
Collaboration Diagrams for DS
Assume three level design: GUI, DL
(Business or Domain Logic) and DB (Data
Base)
Assume a single interface class for each
subsystem: GUI, DL, DB
Start with DL
Domain Logic Classes
Start with interface class DomainLogic
During construction of collaboration
diagrams
Discover new, needed methods for the class
Create new classes/objects needed to help fulfill
some responsibility
Copyright W. Howden 21
Domain Logic Event Responses
Events/messages to be handled by dL
(Domain Logic Interface)
logOn()
getUserType()
getCurrentUName()
Design choices shown on following
collaboration diagram
Copyright W. Howden 22
Copyright W. Howden 23
1: Un = getUserName() uN = getCurrentUName(): String
1: uT = getUserType() uT = getUserType():int
logOn(name)
1: create(name)
2: initialize()
dL : DomainLogic : LogOn
dL : DomainLogic
dL : DomainLogic
: LogOn
: LogOn
Copyright W. Howden 24
Expert & Creator Pattern Uses
DL creates LogOn because it has the
initialization data, and records instances of
LogOn event
LogOn will have the information necessary to
determine user type, so it will be given this
expert responsibility
It has the information necessary to determine
the name of the logged on user so will have this
responsibility also
7/21/2014
More DL Event Responses
dL will have to deal with the following
event/messages
getDate()
isMemberber()
getMemberData()
Design Choices shown on following
diagram
Copyright W. Howden 25
Copyright W. Howden 26
1: isMember(name): Boolean
mD = getDate(userName, daterPrefs)
: MemberData
2: [userName = name]
mD = getMemberData(userName)
mD = getMemberData(name)
: MemberData
isMember(name): Boolean
1: create(userName, daterPrefs)
2: memberData = execute()
: DataBase
dateRequest : DateRequest dL : DomainLogic
dL : DomainLogic
dL : DomainLogic : DataBase
1: UserName = getUserName()
: LogOn
Copyright W. Howden 27
Expert and Creator Pattern Uses
DL creates LogOn because it has the
initialization data and records instances of
LogOn event
LogOn will have the information necessary to
determine user type, so it will be given this
expert responsibility
It has the information necessary to determine
the name of the logged on user so will have this
responsibility also
7/21/2014
More Complex Diagrams
Following slide shows dL response to
setMemberData() event/message
Interfaces with both its own subsystem
classes and other subsystem interface
Copyright W. Howden 28
Copyright W. Howden 29
2b: [userName=/ name] result :="Not logged on"
3b: [2a & memberData == null] result = "NotAMember"
5: [2a & 3a] result = "UpdateMade"
2a: [userName==name] memberData
= getMemberData(userName)
4: [2a & 3a] updateMemberData(memberData)
1: userName = getUserName()
result = setMemberData
(name, dateeData) :String
dL : DomainLogic
dB : DataBase
logOn : LogOn
memberData : MemberData
3a: [2a & memberData/= null]
setDateeData(dateeData)
Domain (Business) Logic subsystem updates a member's data
Design Decisions for
DomainLogic
Necessary DomainLogic methods
logOn, getCurrentUName, getUserType
getDate, isMember, getMemberData
setMemberData
New objects/classes created
LogOn, DateRequest, MemberData
Copyright W. Howden 30
Designing Subsystem Classes
LogOn is one of the classes we decided to
create inside the DomainLogic subsystem
The dL interface class for DL sends
messages to this class
How will it respond to the event/messages it
must take the responsibility for?
Shown in following Collaboration diagrams
Copyright W. Howden 31
LogOn Class
Copyright W. Howden 32
1: userName = name
create(name)
1: userName = name
name = getUserName()
: LogOn
: LogOn
Copyright W. Howden 33
1: userType = userType
userType = getUserType()
initialize()
1: memberData = getMemberData(name)
eB : DataBase
: LogOn
: LogOn
If name is in DB set user type to Member
else set to Unauthorized
Design Decisions for LogOn
LogOn methods
create(name)
getUserName()
initialize()
getUserType()
Copyright W. Howden 34
Copyright W. Howden 35
DL Design Motivation
Where did these objects and these ideas for the
design come from?
1. Messages sent from GUI
GUI collaboration diagrams show GUI will respond to
user initiated events identified in sequence diagrams
2. Principles of good design
2.1 Design evaluation
2.2 Design patterns
GUI Classes
Start with GUI interface class
Collaboration Diagrams
Discover needed methods for the class
Create new classes/objects needed to help fulfill
some responsibility
Copyright W. Howden 36
Copyright W. Howden 37
Collaboration Diagrams
and User Interface Design
Messages are a little different
Come from
actor actions such as pressing a button
other GUI objects which may create them and send
a message to become visible
Following (partial) set of diagrams does not
deal with case where user is ADMIN
Copyright W. Howden 38
1b: [Button = Start] show()
dL : DomainLogic
: LogOnDialog : GUIFrame
System
GUI Frame Presentation Logic
3a: [1b & userType == MEMBER] show()
2: [1b] userType = getUserType()
3b: [1b & userType = UNAUTH]
create(gUI, "Unauthorized")
4: [1b & userType = UNAUTH] show()
1a: [Button == End] Exit
Start/End Button
: DaterOptionSelectionDialog
: MessageDialog
Copyright W. Howden 39
Design Decisions for GUI
New Classes
Objects appearing in GUI collaboration model
MessageDialog, LogOnDialog,
DaterOptionSelectionDialog
When made visible (with show()) a GUI object
can respond to events
Additional collaboration diagrams will show their
responses, and additional classes
More GUI Collaboration
Diagrams 1
Diagrams for Classes that receive
messages/events from :GUIFrame
Shows their responses to events
from actors
from other GUI objects
Copyright W. Howden 40
Copyright W. Howden 41
: MessageDialog
OKButton
1: setVisible(false)
Copyright W. Howden 42
: LogOnDialog : DomainLogic
: TextField
OKButton
3: setVisible(false)
2: logOn(name)
1: name = getText
Copyright W. Howden 43
setMemberDataButton
1: create()
2: show()
: DaterOptionSelectionDialog
: SetMemberDataDialog
3: setVisible(false)
Copyright W. Howden 44
6b: [mD == null] create(gUI, "No Date")
7b: [mD == null] show()
6a: [mD /= null]
create (gUI, mD.name, mD.dateeData)
7a: [ mD /= null] show()
: DaterOptionSelectionDialog : SelectDateePropsDialog
daterPrefs : DaterPreferences
: SelectDaterPrefsDialog
dL : DomainLogic
: MessageDialog
GetADateButton
4: userName = getUserName()
5: mD = getDate(userName, daterPrefs)
2: create()
3: show()
1: create()
8: setVisible(false)
Copyright W. Howden 45
Design Decisions for
DaterOptionSelectionDialog
New Classes for setMemberData message
SetMemberDataDialog
New Classes for getADateButton message
SelectDaterPrefsDialog, MessageDialog,
SelectDateePropsDialog, DaterPreferences
More GUI
Collaboration Diagrams 2
Collaboration diagrams for classes
receiving messages/events from classes that
receive messages/events from GUIFrame
From DaterOptionSelectionDialog
setMemberDataButton alternative
SetMemberDataDialog
getADateButton alternative (only first is shown)
SelectDaterPrefsDialog, MessageDialog,
SelectDateePropsDialog, DaterPreferences
Copyright W. Howden 46
Copyright W. Howden 47
2: create()
3: setGender(genderField.getText())
4: setReligion(religionField.getText)
5: setOccupation(occupationField.getText())
6: setEmail(emailField.getText())
7: result = setMemberData
(name, dateeData)
1:name = nameField.getText()
10: setVisible(false)
acceptButton
: setMemberDataDialog
dateeData : DateeData
nameField : TextField
dl : DomainLogic
: MessageDialog
8: create(gUI, result)
9: show()
Copyright W. Howden 48
EnterButton
: SelectDaterPrefsDialog
: DaterPreferences
2: setReligion(religionChoice)
4: setGender(genderChoice)
1: religionChoice = ListBox.Religion
3: genderChoice = ListBox.Gender
Design Decisions
SetMemberDataDialog
New Classes
DateeData
necessary methods
SelectDaterPrefsDialog
additional methods for daterPreferences
setReligion, setGender
Copyright W. Howden 49
Copyright W. Howden 50
Additional GUI Diagrams
GUIFrame, for full set of functionality, will
need a branch for UserType = ADMIN
This will send a show() message to an
object called
AdminOptionSelectionDialog
leading to new classes and additional
collaboration diagrams
Copyright W. Howden 51
Collaboration vs Sequence
Diagrams
Equivalent: it is possible to transform one kind of
diagram into the other
Rational Rose: automated tool
Sequence diagrams: clearly show
ordering of messages in time
linear interaction structure
Collaboration
good for free form create of new messages and classes
during design process
Assignment 5
Construct collaboration diagrams for your
subsystem interface classes (Phase 1)
Construct collaboration diagrams for the
more complex classes that are created by
the subsystem interface classes (and more
complex ones created by them, ....)
Copyright W. Howden 52
