1. 2.3 Collaboration Contracts

2. Motivation Collaboration Contracts
Single classes with inheritance are insufficient to adequately model framework behaviour
Sets of collaborating classes are needed to express connections between classes that are not related by means of inheritance
Behaviour should be divided into manageable chunks.
Separation of concerns
Chunks represent identifiable pieces of behaviour
Collaboration Contracts

3. Recap: Class Collaboration
Packet Forwarding
Contract

4. Elements of a Collaboration
Participants: who is participating in the collaboration?
Acquaintance relations: who collaborates with who?
Interaction: how does the collaboration proceed?
Intent: why are the participants collaborating?

5. Definition
A collaboration contract is a contract that describes the collaboration between classes. It consists of a name, a static structure and an interaction part.
The name describes the purpose of the collaboration.
The static structure describes the acquaintance relationships between the participants in the collaboration. It describes which participant can send messages to which other participant.
The interaction describes the method invocation structure (method dependencies).

6. Graphical Notation: Static Structure
Use Class Diagrams in UML
participants
(= classes or interfaces in UML)
acquaintance relations
(= associations in UML)
AddressableNode
ActivePacket
accept(p:Packet)
aNode
isDestinationFor (p :Packet)
visit (n : Node)
send(p: Packet)
action (n : Node)
thePacket
handle (p : Packet)
nextNode
Packet Forwarding Contract

7. Graphical Notation: Interaction
Use Interaction Diagrams in UML
packet:Active
Packet
aNode:Addressabl
eNode
nextNode:
AddressableNode
2a.1: action( )
1: visit
2b.1: send
2: isDestinationFor
2a.2: handle
2b.2: accept
accept
Packet Forwarding Contract

8. Graphical Notation: Interaction
Extension of UML Interaction Diagrams
{send invokes} accept
aNode:AddressableNode
nextNode:AddressableNode
{action invokes} handle
{visit invokes} isDestinationFor
{accept invokes} visit
start (underlined)
= convention !
{visit invokes} send
packet:ActivePacket
method dependency
{visit invokes} action
Packet Forwarding Contract

9. Putting it Together Use UML Packages Contract Name Static Structure
identifies the ‘concern’ that is addressed by the contract
Use UML Packages
Packet Forwarding
Static Structure
AddressableNode
ActivePacket
accept(p:Packet)
thePacket
isDestinationFor(p:Packet)
visit(n:Node)
send(p:Packet)
aNode
action(n:Node)
handle(p:Packet)
nextNode
{send invokes} accept
aNode:AddressableNode
nextNode:AddressableNode
{action invokes} handle
{visit invokes} isDestinationFor
{accept invokes} visit
{visit invokes} send
packet:ActivePacket
Interaction
{visit invokes} action

10. Well-formedness
A collaboration contract is well-formed if all messages to a target participant are in the interface of that participant and originate from a method that is in the interface of the source participant
ill-formed
ill-formed X Y X Y q q a b a b
{a invokes} p
{p invokes} b
x:X
y:Y
x:X
y:Y

11. Other Example
Destination Checking
Contract

12. Destination Checking Contract
NodeAddress
AddressableNode
addressee
isDestinationFor (p:Packet)
isDestinationFor (p:Packet)
node:AddressableNode
address:Address
{isDestinationFor invokes} isDestinationFor

13. Designing Collaborations
Partition the behaviour in manageable chunks
contracts correspond to an identifiable piece of behaviour (e.g. correspond to a feature)
contracts have a name!
classes can play a role in different contracts
Where to stop?
collaborations that have too many participants (e.g. more than 7 participants)
collaborations that address different concerns (e.g. user interfacing and storage)
collaborations that cannot be given a clear name

14. Classes can Participate in Different Collaboration Contracts
Participants are Class Roles instead of actual classes!
Packet forwarding
AddressableNode
aNode
ActivePacket
accept(p:Packet)
isDestinationFor(p:Packet)
thePacket
visit(n:Node)
send(p:Packet)
action(n:Node)
handle(p:Packet)
two roles of the same class
nextNode
Destination checking
AbstractAddress
AddressableNode
addressee
isDestinationFor (p :Packet)
isDestinationFor (p :Packet)

15. Classes are the Sum of Roles (1)
Packet Forwarding
AddressableNode
thePacket
ActivePacket
accept(p:Packet)
isDestinationFor(p:Packet)
aNode
visit(n:Node)
send(p:Packet)
action(n:Node)
handle(p:Packet)
nextNode
AbstractAddress
addressee
isDestinationFor(p:Packet)
Destination Checking

16. Assoc. Roles must be Independent
AddressableNode
thePacket
ActivePacket
accept(p:Packet)
isDestinationFor(p:Packet)
aNode
visit(n:Node)
send(p:Packet)
action(n:Node)
handle(p:Packet)
nextNode
Overlap in acquaintance names !
AddressableNode
accept(p:Packet)
thePacket
BroadcastPacket
isDestinationFor (p :Packet)
send(p: Packet)
handle (p : Packet)

17. Classes are the Sum of Roles (2)
{isDestinationFor invokes} isDestinationFor
Destination Checking
address:Address
{send invokes} accept
aNode:AddressableNode
nextNode:AddressableNode
{action invokes} handle
{accept invokes} visit
{visit invokes} isDestinationFor
{visit invokes} send
Packet Forwarding
packet:ActivePacket
{visit invokes} action

18. Class Roles must be Independent
Different roles of a class should not lead to conflicting behaviour.
Try to separate concerns as much as possible.

19. UML Pattern Notation
UML pattern notation hides details about the collaboration contract.
Only acquaintance role names and contract name are mentioned.
Packet Forwarding
pattern notation
ActivePacket
dependency notation
AddressableNode
Destination Checking
AbstractAddress

20. At the Implementation Level
Ideally, a set of collaboration contracts is implemented as:
a set of abstract classes that implement the collaboration
a factory to implement the name-space for participants (see design patterns)
Filling in contract participants at the implementation level is typically a combination of:
inheritance from the base (abstract) classes to create a sub-class with new behavior, and
filling in this sub-class in a factory

21. From Collaboration to Implementation
View
Implementation
View
Model View
Packet Forwarding
<<implements>>
AddressableNode
Node
<<implements>>
Packet
ActivePacket
Destination Checking
<<implements>>
Address
AbstractAddress
implementation classes are associated to class descriptions in the design model instead of being used as participants in the collaboration contracts directly.
an implementation class must ‘conform’ to all collaboration contracts in which the design class to which it is associated participates.

22. Relating Participants to Classes
Directly relating a participant to the implementation using the name of a class.
Indirectly relating to the implementation using a dependency relation.
AddressableNode
accept(p:Packet)
isDestinationFor(p:Packet)
send(p:Packet)
handle(p:Packet)
AbstractAddress
isDestinationFor(p:Packet)
<<implements>>
Node

23. Interpreting Acquaintances ?
AddressableNode
accept(p:Packet)
isDestinationFor(p:Packet)
implementation must have a ‘nextNode’ acquaintance
send(p:Packet)
handle(p:Packet)
nextNode
acquaintance relation
Object subclass: #Node
instanceVariableNames: ‘name nextNode’

24. Kinds of Acquaintances
Objects known to everybody (or large groups)
global variables, class variables, pool variables, classes
Immediate subparts of the current object
instance variables, attributes
Argument objects of the executing method
formal arguments, ‘self’ pseudo variable
Objects created by the executing method
possibly stored in temporary variables
Objects that are the result of sending a message

25. Acquaintances: Globals
Node
Transcript
Logger
{global}
accept(p:Packet)
isDestinationFor(p:Packet)
log(s:String)
send(p:Packet)
handle(p:Packet)
Object subclass: #Node
instanceVariableNames: ‘name nextNode’
classVariableNames: ‘Logger’

26. Acquaintances: Subparts
AddressableNode
accept(p:Packet)
isDestinationFor(p:Packet)
send(p:Packet)
handle(p:Packet)
nextNode
Object subclass: #Node
instanceVariableNames: ‘name nextNode’

27. Acquaintances: Arguments
AddressableNode
accept(p:Packet)
isDestinationFor(p:Packet)
send(p:Packet)
handle(p:Packet)
ActivePacket
visit(n:Node)
action(n:Node)
thePacket
{arg=p}
aNode
{arg=n}

28. Acquaintances: Self
‘self’ is an implicit acquaintance, and is always present
Shortcut notation
ActivePacket
ActivePacket
visit(n:Node)
visit(n:Node) {action}
action(n:Node)
action(n:Node)
packet : ActivePacket
invocation on self
This slide shows the link between
collaboration contracts and specialisation interfaces
{visit invokes} action

29. Reverse Engineering Collaboration Contracts
Identifying key classes
abstract classes
classes with many variations
classes that seem to be mapped directly from the problem domain
classes that play a role in design patterns (see earlier)
Identifying key collaborations
calls from template methods to abstract methods
methods that are frequently overridden
method calls between key classes
messages that pass self as parameters
design patterns (see earlier)

30. Acquaintances: Results
reverse engineering
AddressableNode
thePacket.addressee
NodeAddress

31. Formalising Result Acquaintances
AddressableNode
thePacket.addressee
NodeAddress
must be an acquaintance
thePacket
must be a method (or public attribute) in the interface of the receiving participant
ActivePacket
originator
addressee
contents
Must be added to make the contract consistent.

32. However !!!!!
Law of Demeter
An operation O of a class C should only invoke operations of the classes (called preferred supplier classes) of the following objects:
immediate subparts of the current object (stored or computed)
argument objects of O (including self)
objects created by O
Should be avoided ! (see also part 2.2)
AddressableNode
NodeAddress
thePacket.addressee
thePacket

33. Solution AddressableNode NodeAddress thePacket ActivePacket originator
addresee
{path = thePacket.addressee}
AddressableNode
NodeAddress
name of acquaintance
thePacket
access path to acquaintance
ActivePacket
originator
addressee
contents

34. Formalising the Interaction
implementation must invoke isDestinationFor()
{isDestinationFor() invokes} isDestinationFor()
node:AddressableNode
address:Address
Again different interpretations are possible
source level: invocation occurs somewhere in method body
run time: invocation must occur in any possible method execution
Again we will take the simpler source level interpretation

35. Reusing Class Collaborations: Subclassing Abstract Classes
collaboration instance:
printing
collaboration instance:
broadcasting

36. Reusing Collaborations: Filling in Contract Participants
framework instance:
counting hops
Packet Forwarding
Contract

37. Recap: three different layers
collaboration view
model view
implementation view
Packet Forwarding
<<participates>>
<<implements>>
ActivePacket
CountingPacket
must strictly conform to the contracts in which ActivePacket participates!
can have more than one participant.
can participate in more than one collaboration.

38. Summary Collaboration contracts designing collaborations
documenting collaborations
reuse of collaborations