1. GRASP: Designing Objects With Responsibilities
Chapter 17
Applying UML and Patterns
-Craig Larman

2. Agenda Information Expert Creator Low Coupling High Cohesion
Introduction to object design
GRASP:
Information Expert
Creator
Low Coupling
High Cohesion
Controller

3. Introduction to Object Design
Inputs :
use case text : objects are designed to realise the use cases
System sequence diagrams : identify the system operation messages
Operation contracts : complement the use case.
Supplementary Specification : non functional requirements
Glossary
Domain Model : help name and attributes of software object.

4. Object Design UML interaction diagram Class diagram Package diagrams
Outputs :
UML interaction diagram
Class diagram
Package diagrams
UI sketches and prototypes;
database models.
Remember : not all of the input artifacts are necessary.

5. Fig. 17.1 UP artifacts influencing OO design

6. Responsibility-Driven Design (RDD)
Design of behavior implies assigning responsibilities to software classes.
Responsibilities: contract or obligation of a classifier”

7. What’s responsibility
Doing:
Doing something itself, such as creating an object or doing a calculation
Initiating action in other objects
Controlling and coordinating activities in other objects.
Knowing:
Knowing about private encapsulated data
Knowing about related objects
Knowing about things it can derive or calculate

8. Fig. 17.2 Responsibilities and methods

9. Responsibility Assignment is the Key
Appropriate assignment of responsibilities to classes is the key to successful design.
There are fundamental principles in assigning responsibilities that experienced designers apply.
These principles are summarized in the GRASP patterns.

10. General Responsibility Assignment Software Patterns
GRASP: nine basic OO design principles. memorization and application of these patterns are critical for successful object-oriented designs.
1. Creator..
2. Information Expert.
3. Controller.
4. Low Coupling.
5. High Cohesion.
6. Polymorphism.
7. Pure Fabrication.
8. Indirection.
9. Don’t Talk to Strangers.
Memorizing and applying these nine principles during every design exercise is the primary course objective.

11. GRASP Patterns Which class, in the general case is responsible?
You want to assign a responsibility to a class
You want to avoid or minimize additional dependencies
You want to maximise cohesion and minimise coupling
You want to increase reuse and decrease maintenance
You want to maximise understandability
…..etc.

12. Creator

13. Creator Who should create an instance of a particular class?
Consider assigning Class B the responsibility to create an instance of class A if one of the following is true:
B contains A.
B aggregates A.
B records A.
B closely uses A.

14. Fig. 17.3 Monopoly iteration-1 domain model

15. Fig. 17.4 Applying the Creator pattern (dynamic model)

16. Fig. 17.5 Applying Creator in a static model
Board has a composite aggregation association with Square.

17. Fig. 17.12 Partial POS domain model

18. Fig. 17.13 Creating a SalesLineItem
Sale objects are given a responsibility to create Payments. The responsibility is invoked with a makePayment message

19. Creating a Book

20. Information Expert

21. Information Expert
What is a basic principle by which to assign responsibilities to objects?
Assign a responsibility to the information expert — the class with the information necessary to fulfill the responsibility.

22. Applying Expert in POS Application
Start assigning responsibilities by clearly stating the responsibility.
Who should be responsible for knowing the grand total of a sale?
Where do we look for the classes that have the information needed?
First, in the Design Model.
If no relevant classes there, look in the Domain Model, and add a corresponding software class to the Design Model.

23. Fig. 17.14 Associations of Sale in Domain Model

24. Fig. 17.15 Partial interaction and class diagrams
Adding a Sale class to the Design Model supports low representational gap.
Express responsibility of knowing the total of a sale with the method named getTotal.
What information do we need to know to determine the line item subtotal?

25. Fig. 17.16 SalesLineItem is Expert for Subtotal
How does the SalesLineItem find out the product price?
“Partial” information experts collaborate to fulfill the responsibility.

26. Fig. 17.17 ProductDescription is Expert for Price

27. Example : Fig In Monopoly, which class should be responsible for knowing a Square, given a key (e.g., its name)?

28. Example : Fig In Monopoly, which class should be responsible for knowing a Square, given a key (e.g., its name)?

29. Another Example

30. Low Coupling Principle

31. The Low Coupling Principle
Problem : Reduce the impact of change.
Solution: Assign responsibilities so that coupling remains low.
Use this principle to evaluate alternatives.
Coupling: how strongly one element is connected to, has knowledge of, or relies on other elements.
Low coupling tends to reduce the time, effort, and defects in modifying software.
Coupling per se is not a problem, only coupling to elements that are unstable (likely to change).

33. Fig. 17.7 Don’t assign getSquare to an arbitrary class

34. Low Coupling in POS Case Study
What class should be responsible for creating a Payment instance and associating it with the Sale?
Register?
Sale?
Creator pattern suggests Register should create the Payment.
A register records a payment in the real world.

35. Fig. 17.18 Register creates Payment
Register is coupled to both Sale and Payment.

36. Fig. 17.19 Sale creates Payment
Assuming that the Sale must eventually be coupled to knowledge of a Payment, having Sale create the Payment does not increase coupling.
Low Coupling and Creator suggest different solutions.

37. Common Forms of Coupling in OO Languages
Type X has an attribute (data member, instance variable) that refers to type Y or an instance of Y.
An object of type X calls on services of a type Y object.
Type X has a method that references an instance of type Y (e.g., parameter, local variable, object returned from a method).
Type X is a subclass of type Y.
Type X implements the interface Y.

38. Controller Pattern

39. Fig. 17.8 System Sequence Diagram for Monopoly
Actors generates UI events by clicking on a buttons. UI software objects(Jframe window and Jbutton button) reacts to the mouse click and cause the game to play. UI objects pick up the mouse events and should delegate the request to domain objects in the domain layer.

40. Controller Pattern
What first object beyond the UI layer receives and coordinates (“controls”) a system operation message?
Solution: Assign the responsibility to a class that represents one of the following options:

41. Options for Control Responsibility
Option 1a: Represents the overall system or a root object.
E.g., an object called MonopolyGame.
Option 1b: Represents the device the software is running within.
E.g., Phone or BankCashMachine.
Not applicable in the Monopoly case.
Option 2: Represents the use case or session.
E.g., PlayMonopolyGameHandler.

42. Who is Controller for playGame or How to connect the UI layer to the application logic?

43. Fig. 17.10 Using MonopolyGame as Controller
Option 1 is reasonable if there are only a few system operations.

44. Remind from analysis: System Operations of POS Application

45. Fig. 17.20 System Operations of POS Application
During analysis, system operations may be assigned to a System class.
Does not mean a software class named System fulfills the system operations during design.
During design, a controller class is assigned the responsibility for system operations.

46. Fig. 17.21 What should be Controller for enterItem?

47. Fig. 17.22 Controller choices ?
In the POS domain, Register (POS Terminal) is a specialized device with software running on it.
ProcessSaleHandler represents a receiver of all system events of a use case scenario.

48. Fig. 17.23 Allocation of system operations
During design, system operations identified during system behaviour analysis are assigned to one or more controller classes.

49. Delegation UI layer objects delegate system events to another layer.
UI layer shouldn’t contain application logic.
Increases potential for reuse.
Can “unplug” UI layer – use a different framework or run in offline “batch” mode.
Controller should delegate the work that needs to be done to other objects.
It controls or coordinates the activity.

50. Fig. 17.24 Desirable coupling of UI and domain layers

51. Fig. 17.25 Undesirable coupling of UI to domain layer

52. Façade Controller
Façade controller represents the overall system, device, or subsystem.
A façade or cover over other layers.
Abstraction of overall physical unit
e.g., Register, TelecommSwitch, Robot, or
class representing entire system or concept
e.g., POSSystem, ChessGame.
Suitable when there are not too many system events or when UI cannot choose between multiple controllers.

53. Use Case Controller
A use case controller handles system events for a single use case.
Can maintain information about the state of the use case.
E.g., detect out-of-sequence system events.
Different controller for each use case.
Not a domain object, but artificial construct (“pure fabrication”) to support the system.
Use when there are many system events.
Factors handling into separate classes.

54. Controller - Facades Facades are “covers.”
Intent - A class that (in some way) represents an overall cover.
Many possibilities.
Example: The entire organization.

55. Controller - Facades
Other facades? A class representing the “system.” Examples:
The software information system.
The device that includes a computer and software such as an ATM.
Others.

56. Controller

57. High Cohesion

58. High Cohesion Solution
Assign a responsibility so that cohesion remains high
Problem
How to keep complexity manageable?
Cohesion is a measure of how strongly related and focused the responsibilities of an element (classes, subsystems) are
A class with low cohesion does many unrelated things, or does too much work
They suffer from the following problems:
hard to understand
hard to reuse
hard to maintain
delicate; constantly effected by change

59. Benefits of High Cohesion
Clarity and ease of comprehension of the design is increased.
Maintenance and enhancements are simplified.
Low coupling is often supported.
The fine grain of highly related functionality supports increased reuse because a cohesive class can be used for a very specific purpose.

60. Fig. 17.26 Reduced cohesion of Register(creator pattern)
Low cohesion:
Register is taking part of the responsibility for fulfilling “makePayment” operation and many other unrelated responsibility ( 50 system operations all received by Register).then it will become burden with tasks and become incohesive

61. Fig. 17.27 Higher Cohesion and Lower Coupling
Solution:
Delegate the payment creation responsibility to “Sale” to support high cohesion