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

3. Designing Objects With Responsibilities 2 “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?

4. Object Design : Input Use case text Defining the behavior System sequence diagram Identifying the system operation messages The operation contract Stating events to design for, and detailed post-condition to satisfy 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 3

5. Fig. 17.1 UP artifacts influencing OO design

6. 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 ] 5

7. 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) 6

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

9. 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) 8

10. Responsibilities and attribute 9

11. RDD and Collaboration 10 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

12. 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 novel situations” 11

13. Well ‐ known Pattern Families 12 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

14. GRASP Patterns 9 GRASP patterns, but we start with the first five Information Expert Creator Controller Low Coupling High Cohesion Polymorphism Pure Fabrication. Indirection. Don’t Talk to Strangers 13

15. Creator

16. Creator principle 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 15

17. 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. 16

18. Creator Pattern in Monoply 17

19. Problem Who should create a SalesLineItem?

20. 19

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

22. Creating a SalesLineItem 21

23. Why Catalog is reating a Book ?

24. Information Expert

25. 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.”

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

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

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

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

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

31. ProductDescription is Expert for Price “Partial” information experts collaborate to fulfill the responsibility.

32. 31 Another Example

33. Low Coupling Principle

34. “Low Coupling” Principle 33 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.

35. What is a coupling ? 34 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.

36. What is a coupling ? 35 Common form of coupling from Class A to Class B are:  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.

37. What is a coupling (continued) ? 36 Common form of coupling from Class A to Class B are:  Class A is a direct or indirect subclass of Class B.  Class B is an interface, and Class A implements that interface.

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

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

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

41. 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. NB : Low Coupling and Creator may suggest different solutions.

42. Controller Pattern

43. 42 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.

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

45. Options for Control Responsibility 1. 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. 2. A controller for each use case e.g. processSaleHandler

46. Controller choices ? 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. Controllers

47. What should be Controller for enterItem?

48. Bad Design

49. Good Design Controller should delegate the work that needs to be done to other objects.

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

51. Controller

52. Controller: Benefits 51 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()

53. High Cohesion

54. 53 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.

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

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

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

58. 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, regardless of the design result. 57

59. Object Design: startUp  Initial system operation  Delay until all other system operations have been considered  What objects need to be there through out the use case  What associations need to be there through out the use case  Create a set of domain objects that need to be there to support the use  case execution  Find a suitable initial object and request that object to create a set of other objects  Do the initialization design last 58

60. Object Design Examples with GRASP Chapter 18 Applying UML and Patterns Craig Larman

61. 60

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

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

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

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

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

67. 66 System Operations of POS Application

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

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

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

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

72. Creating a New Sale

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

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

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

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

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

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

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

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

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

83. Constraints and Notes

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

85. Creating the Payment Register – makePayment Communication diagram

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

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

88. Logging a Completed Sale

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

90. Calculating the Balance

92. Questions ? 91