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

2. Designing Objects With Responsibilities
“Identify requirements, create a domain model and define dynamic behaviour , define messages to meet requirements , add methods to the software classes …”
Too Simple!
How do we assign responsibilities to classes?
What methods belong where?

3. Object Design : Input Use case text System sequence diagram
Defining the behavior
System sequence diagram
Identifying the system operation messages
Supplementary specification
Defines non-functional goals
Glossary
Data format, data related with UI and database
Domain model
initial attempt of software object in the domain layer of software architecture
The operation contract
Stating events to design for, and detailed post-condition to satisfy

4. Fig. 17.1 UP artifacts influencing OO design

5. Responsability Driven Design-RDD
Design of behavior implies assigning responsibilities to software classes.
Responsibilities are assigned to classes of objects during object design.
Responsibility is a contract or obligation of a class
What must a class “know”? [knowing responsibility]
What must a class “do”? [doing responsibility]
Obligation : Duty , Responsibility

6. Doing Responsability What must a class “do”? [doing responsibility]
Take action (create an object, do a calculation)
Initiate action in other objects
Control/coordinate actions in other objects
Doing responsibilities are implemented by means of methods
Methods fulfill responsibilities alone or through collaboration with other objects and methods.
Ex: A Sale is responsible for creating SalesLineItems” (doing)

7. Responsibilities and methods : create
Sale objects are given a responsibility to create Payments.
The responsibility is invoked with a makePayment message

8. knowing responsibility
What must a class “know”? [knowing responsibility]
Private encapsulated data
Related objects
Things it can derive or calculate
Knowing responsibilities are related to attributes, associations in the domain model.
Domain model illustrates attributes and associations => inspires the “knowing” responsibilities.
Ex : a Sale is responsible for knowing its total” (knowing)

9. Responsibilities and attribute

10. RDD and Collaboration Responsibilities are implemented by methods
Some methods act alone and do a task
Some collaborate with other objects to fulfill their responsibility.
Example:
Sale class has getTotal() method, the getTotal() collaborates with SalesLineItem objects to get the subtotal through getSubtotal() methods

11. Software pattern What is a software pattern?
A design pattern is a general reusable and proven solution to a commonly occurring problem in software design.
Craig Larman: “ a pattern is a named problem/solution pair that can be applied in new contexts, with advice on how to apply it in the situations”

12. Well‐known Pattern Families
GRASP = General Responsibility Assignment Software Patterns
Describe fundamental principles for assigning
responsibilities to classes and for designing
interactions between classes
GoF: Gang of Four Design Patterns : 23 pattrens
We’ll cover with GRASP

13. GRASP Patterns 9 GRASP patterns , but we start with the first five
Information Expert
Creator
Controller
Low Coupling
High Cohesion
Polymorphism
Pure Fabrication.
Indirection.

14. Creator

15. Creator principle B “records” A B “closely uses” A
Problem: Who creates an A object
Solution: Assign class B the responsibility to create an instance of class A if one of these is true
B “contains or aggregate ” A
B “records” A
B “closely uses” A
B “ has the Initializing data for ” A

16. Creator principle
B “has the Initializing data for ” A that will be passed to A when it is created.
Often initiation is done using a constructor with parameters.
e.g. a Payment instance, when created
needs to be initialized with the Sale total.
Sale class knows Sale total. Good candidate for creating Payment is Sale.
If more than one of the above applies, prefer a class B which aggregates or contains A.

17. Problem Who should create a SalesLineItem?

19. Creating a SalesLineItem
Sale objects are given a responsibility to create SaleLineItem.
The responsibility is invoked with a makeLineItem message

20. Creating a SalesLineItem

21. Information Expert

22. Information Expert
Problem : What is a basic principle by which to assign responsibilities to objects?
Solution (advice ) : Assign a responsibility to the information expert , that is the class with the information necessary to fulfill the responsibility.
“Objects do things related to the information they have.”
Customer
Shopping cart
items

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

24. Who should be responsible for knowing/getting the grand total of a sale?

25. Who responsible for knowing the grand total of a sale?

26. Partial interaction and class diagrams
Add a Sale class to the Design Model.
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?
Sale knows about neighbours (associations), SaleLineitems who is responsible for knowing its subtotal

27. SalesLineItem is Expert for Subtotal
How does the SalesLineItem find out the product price?
SaleLineItem knows about neighbours ( ProductDescription) to get the price.

28. Product Description is Expert for Price
“Partial” information experts collaborate to fulfill the responsibility.

29. Low Coupling Principle

30. “Low Coupling” Principle
Problem:
How to support low dependency, Low change impact, and increased reuse?
Solution: Assign responsibilities so that coupling remains low. Use this principle to evaluate alternatives.
Coupling is a measure of how strongly one class is
connected to,
has knowledge of, or
relies upon other classes.

31. What is a coupling ?
Coupling between classes is dependency of one class on another class
Common form of coupling from Class A to Class B are:
Class A has an attribute (data member or instance variable) that refers to a Class B instance, or Class B itself.

32. What is a coupling ?
Class A has a method which references an instance of Class B, or Class B itself, by any means. These typically include a parameter or local variable of type Class B, or the object returned from a message being an instance of Class B.
Class A is a direct or indirect subclass of Class B.
Class B is an interface, and Class A implements that interface.

33. Low Coupling - 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.

34. What if Register creates Payment
Register is coupled to both Sale and Payment.

35. What if 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.

36. Controller Pattern

37. Controller Pattern UI layer does not contain any business logic
Problem:
How to connect UI layer to the business logic layer?
Solution:
If a program receive events from external sources
other than its graphical interface, add an event class
to decouple the event source(s) from the objects
that actually handle the events.

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

39. Options for Control Responsibility
Represents the overall system or a root object.
e.g., an object called System or Register
Suitable when there are not too many system events or when UI cannot choose between multiple controllers.
A controller for each use case
e.g. processSaleHandler

40. What should be Controller for enterItem?

41. Bad Design

42. Good Design
Controller should representative for the work that needs to be done to other objects.

43. A use case controller handles system events for a single use case.
Can maintain information about the state of the use case.
Different controller for each use case.
Not a domain object, but artificial construct to support the system.
Use when there are many system events.
Factors handling into separate classes.

44. Controller

45. Controller: Benefits Increased potential for reuse
Ensures that the application logic is not handled in the interface layer. Thus, the external event raisers are independent of internal event handlers
Plug & Play interfaces
Since the interface is not bound to the controllers, it can be replaced or updated without much impact
Verifying the reasoning of the use case
Allows us to verify that the system operations occur in a logical sequence. For example: makePayment() is not called before endSale()

46. High Cohesion

47. High Cohesion
A class with low cohesion does too much unrelated work and are:
Hard to comprehend
Hard to reuse.
Hard to maintain.
Delicate and constantly affected by change
Cohesion is a measure of how strongly related the responsibilities of an element (classes, subsystems) are.

48. High Cohesion Problem How to keep complexity manageable? Solution
Assign a responsibility so that cohesion remains high

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

50. Better solution Higher Cohesion and Lower Coupling
Delegate the payment creation responsibility to “Sale” to support high cohesion

51. Conclusion
Like Low Coupling, High Cohesion is a principle to keep in mind during all design decisions
It is important to evaluate design constantly with respect to GRASP principles.

52. Object Design Examples with GRASP
Chapter 17
Applying UML and Patterns
Craig Larman

53. Use-Case Realizations
UML interaction diagrams are used to illustrate use-case realizations.
Design operations of the SSD
Principles and Patterns can be applied during this design work.
Which object has which responsibility?

54. Domain Model and Use-Case Realization
Some of the software objects that interact via messages in the interaction diagrams are inspired from the Domain Model.
The existing domain model is not likely to be perfect. Errors and omissions are to be expected.
You will discover new conceptual classes that were previously missed, ignore conceptual classes that were previously identified, and do likewise with associations and attributes.

55. Interaction Diagrams
Your System Sequence Diagram list the system events.
Create a separate diagram for each system operation(all events of the use case) under development in the current iterative step.
If the diagram gets complex, split it into smaller diagrams.

56. Multiple Sequence Diagrams (
Multiple sequence diagrams and system event message handling.

57. Use-case Realizations for NextGen Iteration
Explore the choices and decisions made while designing a use-case realization, with objects based on the GRASP patterns.
No magic in the creation of well designed ID’s.
Construction of ID’s is made on justifiable principles.

58. System Operations of POS Application

59. Interaction Diagrams and System Events
In the current iteration of PoS application, we are considering two use-cases and their associated system events:
Process Sale
makeNewSale
enterItem
endSale
makePayment
Start Up !!!!!!!
startUp

60. Object Design : Contract
Name : makeNewSale()
Responsibilities : Make a new sale for a cashier to request to start a new sale, after a customer has arrived with things to buy.
Cross-References: Use Cases : Process Sale
Pre-Conditions : None
Post-Conditions : A sale instance was created.
The sale instance was associated with the register . Attributes of the sale instance were initialized.

61. Choosing the Controller Class
Our design choice involves choosing the controller for the system operation message
Here are some choices:
Represents the overall system, device, or subsystem: Register,
Represents a handler of all system events of a use-case scenario : ProcessSaleHandler.
From those choices, we choose the register as our controller

62. Creating a New Sale
A software sale object must be created, and the GRASP creator pattern suggests assigning the responsibility for creation to a class that aggregates, contains, or records the object to be created.
The register is a good choice to create the sale object by the creator pattern.

63. Creating a New Sale

64. Object Design : enterItem
Name: enterItem(itemID : itemID,quantity : integer)
Responsibilities : Enter sale of an item and add it to the sale. Display the item description and price.
Cross References : Use-Cases : ProcessSale.
Pre-Conditions : There is an underway sale.

65. Object Design : enterItem
Post-Conditions
sli was associated with current sale.(association formed)
sli.quantity became quantity.(attribute modification)
sli was associated with a ProductSpecification, based on itemID match.(association formed), that is also should find its ProductSpecification

66. Creating a new SalesLineItem
The contract post condition indicate a responsibility to create a SalesLineItem instance.
A Sale contains SalesLineItem objects.
By creator pattern, the sale is an appropriate candidate for creating Lineitems.
GRASP creator pattern
Assign the responsibility for creation to a class that aggregates, contains or records.

67. Finding a product specification
The SalesLineItem needs to be associated with the ProductSpecification that matches the incoming itemID.
Who should be responsible for looking up the ProductSpecification based on the itemID match?
By the Expert pattern, ProductCatalog is a good candidate for the responsibility, since it logically contains all the ProductSpecifications.

68. Visibility to a product catalog
Who should send the Specification message to the ProductCatalog to ask for a ProductSpecification?
Assumption: A Register and a ProductCatalog instances were created during the initial Start Up use-case, and there is a permanent connection between them.
Based on this assumption, then it is possible to the Register to send the specification message (using reference to productCatalog) to the ProductCatalog.

70. Object Design : endSale Contract
Name : endSale()
Responsibilities : Record that it is the end of entry of sale items, and display sale total.
Cross References : Use Cases : Process Sale
Exceptions : If a sale is not underway, indicate that it was an error.
Pre-Conditions : There is an underway sale.
Post-Conditions : sale.isComplete became true.

71. Choosing the Controller Class
Based on the Controller Pattern, as for enterItem, we will continue to use register as a controller.

72. Setting the Sale.isComplete attribute
We will continue to use register as a controller
The contract post-condition state:
Sale.isComplete became true.
As always, Expert should be the first pattern considered unless it is a controller or creation problem (which is not).
Who should be responsible for setting the Sale.isComplete attribute of the Sale to true.
By Expert, it should be the Sale itself.

73. Communication Diagram : endSale
Setting the Sale.isComplete attribute (2)

74. Constraints and Notes

75. Object Design:makePayment
Choosing the Controller Class
Based on the Controller GRASP pattern, as for enterItem, we will continue to use Register as a controller.
It is common to use the same controller throughout a use case.

76. Creating the Payment
Register – makePayment Communication diagram

77. Logging the Sale
Who should be responsible for knowing the complete sale.

78. Logging a completed sale
Perhaps we did not think of a sale ledger early, but now we have.
If it is not chosen, it would be ideally added to the domain model as well.
Fortunately, iterative development provides a life-cycle for continual change.
This kind of discovery and change during design work is to be expected.

79. Logging a Completed Sale

80. Calculating the Balance
Who is responsible for knowing the balance?
To calculate the balance, the Sale and Payment cash tendered are required.
Therefore, Sale and Payment are partial experts for solving the problem.

81. Calculating the Balance