1. Chapter 12: Collaboration Diagram - PART2
Chapter 16 in Applying UML and Patterns Book.

2. Overview How to build Collaboration Diagram?
Responsibilities and Methods.
The five GRASP patterns.

3. Building Collaboration Diagrams
System Design: how the system will do what we decided to do.
We must identify software classes and assign responsibilities.
For each operation contract we build a collaboration diagram.
We work through the post condition state changes and design message interactions to satisfy the requirements.
In doing so, we assign responsibilities to objects.
Poor choices lead to hard to implement, maintain, reuse, or extend system design.

4. Building Collaboration Diagrams
Interaction diagrams are one of the most important artifacts created in OOAD.
The skillful assignment of responsibilities that occurs while creating collaboration diagrams is very important.
The amount of time and effort spent on their generation, and the careful consideration of responsibility assignment, should absorb a significant percentage of the design phase.
Codified patterns, principles and idioms can be applied to improve the quality of their design.

5. Responsibilities and Methods
Responsibilities are related to the obligations of an object in terms of its behavior.
Two types of responsibilities:
1. Doing responsibilities:
Doing something itself (create objects, change its attributes).
Initiating actions in other objects (by calling functions in other objects).
Controlling and coordinating activities in other objects (receiving data from one object an send them to another object).
2. Knowing responsibilities:
Private encapsulated data.
Related objects.
Things it can derive or calculate.

6. Responsibilities and Methods
Responsibilities are assigned to objects during design.
Example: Sale responsibilities;
1. Printing itself (doing).
2. Knowing its date.
Responsibilities related to knowing (who know who) are often detected from conceptual model (from the attributes and associations).

7. Responsibilities and Methods
Responsibility ≠ Method.
A responsibility is not the same thing as a method, but methods are implemented to fulfill responsibilities.
For example, “provide access to a relational database” may involve dozens of classes and hundreds of methods, whereas “create a Book Entry” may involve only one or few methods.
Methods either act alone or collaborate with other methods and objects to fulfill responsibilities.
For example, Sale has a responsibility named print. To fulfill this responsibility, the Sale may collaborate with other objects, such as sending a message to SaleLineItem objects asking them to print themselves.

8. Responsibilities and Collaboration Diagrams

9. GRASP
Describe fundamental principles of object design and responsibility.
Acronym for General Responsibility Assignment Software Patterns.
GRASP is expressed as patterns.
Patterns are problem/solution pairs that guide in assigning responsibilities by giving advice in how to apply it in varying circumstances.

10. GRASP There are 5 basic GRASP patterns: 1. Expert. 2. Creator.
3. Low Coupling.
4. High Cohesion.
5. Controller.

11. 1. The Expert Pattern
Problem: What is the most basic principle of assigning responsibilities to objects?
Solution:
– Assign a responsibility to the information expert class – i.e. the class that has the information necessary to fulfill the responsibility is given the responsibility.
– Start by clearly stating the responsibility.
Example:
– In POST, who should be responsible for knowing the grand total of the sale?
– By expert pattern, we should look for that class that has the information needed to determine the total.

12. 1. The Expert Pattern: Example

13. 1. The Expert Pattern: Example
Step 1: What information is needed to determine the grand total?
It is necessary to know about all the SaleLineItems instances composing the Sale and their subtotals.
Only Sale object knows the information about SaleLineItems it contains. So by Expert pattern, the Sale object is the information expert and should be one of its responsibilities to compute the sale total.
Collaboration diagram so far:

14. 1. The Expert Pattern: Example
Step 2: To determine the SaleLineItem subtotals, what information is needed?
We need SaleLineItem.Quantity and Productspecfication.Price.
The SaleLineItem object knows its quantity and its associated Productspecfication (which contains the price).
Thereby by Expert pattern, SaleLineItem object should determine the subtotal as it is the information expert.
Collaboration diagram so far:

15. 1. The Expert Pattern: Example
Step 3: Finally, how the SaleLineItem will compute its subtotal?
It should know its item price through ProductSpecfication.
Thus, the ProductSpecfication object is the information expert of the item price; therefore a message must be sent to it from SaleLineItem object asking for the price.
Thus, ProductSpecfication must have a method called price() that returns the item price.

16. 1. The Expert Pattern: Example
From Step1
From Step2
From Step3

17. 1. The Expert Pattern: Example
Class Responsibilities:
Class
Responsibility
Sale
Knows sale total.
SaleLineItem
Knows line item subtotal.
ProductSpecification
Knows product price.

18. 2. The Creator Pattern
Problem: Who should be responsible for creating a new instance of some class?
The creation of objects is one of the most common activities in OO system. If assigned well, the design can support low coupling, encapsulation and reusability.
Solution:
– Assign class B the responsibility to create an instance of class A if one or more of the following is true:
B aggregates A objects.
B contains A objects.
B records instances of A objects.
B has the initializing data that will be passed to A when it is created (thus B is an Expert with respect to creating A).
– Thus B is called a creator of A objects.
– If more than option applies, prefer a class B which aggregates or contains class A.

19. 2. The Creator Pattern Example:
– In POST, who should be responsible for creating a SaleLineItem instance?
– By Creator, we should look for the class that aggregates, contains, records, closely uses, or has initializing data for SaleLineItem instances.

20. 2. The Creator Pattern: Example
From the conceptual model, a Sale contains (aggregates) many SaleLineItem objects.
By creator, Sale is a good candidate to have the responsibility of creating SaleLineItem instances.
A method called makeLineItem is defined in Sale class to create the SaleLineItem objects (1….*).

21. 3. Low Coupling Pattern
Coupling: it is a measure of how strongly one element is connected to, has knowledge of, or relies upon other elements.
A class with high coupling depends on many other classes (libraries, tools).
Problems because of a design with high coupling:
– Changes in related classes force local changes.
– Harder to understand in isolation; need to understand other classes.
– Harder to reuse because it requires additional presence of other classes.

22. 3. Low Coupling Pattern
Problem: How to support low dependency, low change impact and increased reuse?
Solution:
– Assign a responsibility so that coupling remains low.
Example:
– In POST, we need to create a Payment instance and associate it with the Sale.
– Which class should be responsible for this? (creator).

23. 3. Low Coupling Pattern: Example
Since a POST records a Payment, by Creator, a POST should be responsible for creating a Payment instance p.
The POST instance then sends an addPayment message to the Sale, passing the new Payment instance as parameter.
This solution couples POST with the knowledge of Payment class.

24. 3. Low Coupling Pattern: Example
Another alternative is to make Sale class responsible for creating a Payment and associate it with the Sale.
In both cases, eventually, Sale has to be coupled with the knowledge of Payment.
 first design has an extra coupling.
 second design does not increase coupling.
We may face Low coupling vs. Creator tradeoff.

25. 3. Low Coupling Pattern
There is no specific measurement for coupling, but in general, classes that are generic and simple to reuse have low coupling.
Coupling will lead to highly interacting classes.
There will always be some coupling among objects, otherwise, there would be no collaboration.
A subclass is strongly coupled to its superclass. The decision to derive a subclass from superclass must be carefully considered as it produces a strong form of coupling.

26. 3. Low Coupling Pattern Benefits:
Understandability: Classes are easier to understand in isolation.
Maintainability: Classes aren’t affected by changes in other components.
Reusability: easier to grab hold of classes.

27. 4. High Cohesion Pattern
Cohesion: (functional cohesion) it is a measure of how strongly related and focused the responsibilities of a class are.
A class with low cohesion does many unrelated activities or does too much work.
A class with high cohesion has highly related responsibilities, and does not do a large amount of work by itself.
Problems because of a design with low cohesion:
– Hard to understand.
– Hard to reuse.
– Hard to maintain.

28. 4. High Cohesion Pattern Problem: How to keep complexity manageable?
Solution:
– Assign a responsibility so that cohesion remains high.
Example:
– In POST, we need to create a Payment instance and associate it with the Sale. Which class should be responsible for this?

29. 4. High Cohesion Pattern: Example
Since a POST records a payment, by Creator, a POST should be responsible for creating a payment instance.
This solution gives the responsibility of creating payment with POST who records it (creator).
We add more unrelated responsibilities to POST, thus it became incohesive.
We cannot let POST instance do all the work related to it.

30. 4. High Cohesion Pattern: Example
Another alternative is to make Sale responsible for (take the job from POST) creating a Payment and associate it with it.
This solution supports high cohesion and low coupling  more desirable than Creator.

31. 4. High Cohesion Pattern Benefits:
Understandability: Clarity & ease of comprehension.
Maintainability: Maintenance and enhancement is easier.
Complements Low Coupling.

32. 5. The Controller Pattern
Problem: Who should be responsible for handling an input system event?
A system event is a high level system generated by an external actor; it is an external input event (which is found in the SSD).
They are associated with system operations.
For a cashier (external actor) using an a POST presses the EndSale button, he is generating a system event indicating “the sale has ended”.
A controller is a non-user interface object responsible for handling a system event.
A controller defines the method for the system operation.

33. 5. The Controller Pattern
Solution:
– Assign the responsibility for receiving or handling a system event message to a class representing one of the four following choices:
Represents the overall system. (façade controller).
Represents the overall organization. (façade controller).
Represents something in the real world that is active (the role of a person).
Represents an artificial handler of all system events of a use case. (use case controller) use the name <Use case name>Handler.
Each use case has one controller for its operations (1 use case = 1 controller for all system events in the same use case).
Note that windows, applets, etc. typically receive events and delegate them to a controller. They are NOT controllers.

34. 5. The Controller Pattern: Example
– In POST system, there are several system operations.
– Who should be the controller for the system events such as enterItem? There are many choices:
Overall system (façade controller).
Overall organization (façade controller).
Active real world something (role controller).
Artificial handler of all use case operations (use-case controller).

35. 5. The Controller Pattern

36. POST if chosen to be the controller class.
5. The Controller Pattern
Many different controller can be used for different use cases.
A common problem with the controller class is that it has much responsibilities (bloated controller), thus it should give some of the other work to other classes.
Whichever you pick:
Never implement system operations in UI classes.
Only coordinate other objects’ responsibilities in the controller.
POST if chosen to be the controller class.

37. Summary
Skillful assignment of responsibilities is extremely important in object-oriented design.
Patterns are named problem/solution pairs that codify good advice and principles related to assignment of responsibilities.
GRASP identifies five patterns or principles:
Creator, Information Expert, Controller, Low Coupling and High Cohesion.