Design Model - GRASP: Designing Objects With Responsibilities

1. Design Model - GRASP: Designing ObjectsWith Responsibilities

2. Objectives • Define patterns • Learn to apply five of the GRASP patterns

3. Patterns and Frameworks • Pattern • Provides a common solution to a common problem in a context • Analysis/Design Pattern • Provides a solution to a narrowly scoped technical problem • Provides a fragment of a solution, or a piece of the puzzle • Framework • Defines the general approach to solving the problem • Provides a skeletal solution, whose details may be analysis/design patterns

4. TemplateParameters Pattern Name What Is a Design Pattern? • A design pattern provides a scheme for refining the subsystems or components of a software system, or the relationships between them. It describes a commonly-recurring structure of communicating components that solves a general design problem within a particular context. Erich Gamma et al. 1994. Design Patterns—Elements of Reusable Object-Oriented Software

5. Patterns • A pattern is a named problem/solution pair that can be applied in new context, with advice on how to apply it in novel situations and discussion of its trade-offs • Patterns are general principles and idiomatic solutions which are summarized from those experienced object-oriented developers during work, and they are used to guide others in the creation of software. • Primitive examples from OOP: • Model - View - Controller (MVC) • Object - Attribute - Value (OAV) • GRASP (Larman) • Gang of Four (GoF; Gamma, et. al.)

6. Examples of Pattern Usage

7. Application Detailing the Command Pattern +menu 1 1 MenuItem 1 1 Command 0..* 0..* Menu - label : String + Process() +cmd +items + Clicked() cmd.Process();

8. OpenCommand Application AskUser(); + Process() DoOpen(); +cmd 1 1 Command + Process() Detailing the Command Pattern (continued) +menu 1 1 MenuItem 0..* 0..* Menu - label : String +items + Clicked() cmd.Process();

9. myapp ocmd : OpenCommand menu aNewItem : MenuItem Detailing the Command Pattern (continued) 1. OpenCommand( ) Initialization 2. AddItem("Open...",ocmd) 3. MenuItem("Open...", ocmd) 3. AskUser( ) 4. DoOpen( ) The user selects the Open… menu item 1. Clicked( ) 2. Process( ) theMenuItem cmd : Command A user

10. AskUser(); DoOpen(); OpenCommand Application + Process() + OpenCommand() - AskUser() - DoOpen() Clicked(): MenuItem(): cmd.Process(); cmd = c; label = s; Detailing the Command Pattern (continued) +menu 1 1 MenuItem Menu 0..* 0..* - label : String +items + AddItem(s : String, c : Command) + Clicked() + MenuItem(s : String, c : Command) +cmd 1 Command + Process()

11. app Application CloseCommand OpenCommand Detailing the Command Pattern (continued) gui Menu MenuItem com Command

12. ClientInvokerConcreteCommand Command Representing Design Patterns in UML • A design pattern is a parameterized collaboration: The parameters (stereotype <<role>>) of the collaboration <<role>> Client <<role>> ConcreteCommand + Process() <<role>> Invoker Command + Process()

13. Introduction to Object Design Process • Object design • After identifying your requirements and creating a domain model, then add methods to the software classes, and define the messaging between the objects to fulfill the requirements. • The heart of developing an object-oriented system is to decide • what methods belong where, and • how the objects should interact is terribly important and anything but trivial

14. What’s GRASP pattern • GRASP - General Responsibility Assignment Software Patterns • This approach to understanding and using design principles is based on patterns of assigning responsibilities • The GRASP patterns are a learning aid to help one understand essential object design, and apply design reasoning in a methodical, rational, explainable way

15. What’s responsibility • Responsibility A contract or obligation of a class • Type of 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

16. Responsibilities, Methods and Interaction Diagrams • Methods implements responsibilities • Responsibilities are implemented using methods that either act alone or collaborate with other methods and objects • Responsibilities and methods are related and shown in interaction diagram

17. Basic GRASP Patterns • Expert • Creator • Controller • High Cohesion • Low Coupling

18. Pattern 1: Information Expert • Solution • Assign a responsibility to the information expert - the class that has the informationnecessary to fulfill the responsibility. • Problem • What is a general principle of assigning responsibilities to objects? • The most commonly used pattern

19. Case Study: Apply Expert Pattern in the design of POS • What do we have to start the design

20. Continue • Next, we need to design: how to get the grand total of a sale • Question: • Who (which class) should handle this? • Answer: • the one who knows about all the SalesLineltem instances of a sale and the sum of their subtotals. So, the Sale instance is the answer

21. Continue • Q: What information is needed to determine the line item subtotal? • A: SalesLineltem.quantity and ProductSpecification.price are needed. • The SalesLineltem knows its quantity and its associated ProductSpecification; therefore, by Expert, SalesLineltem should determine the subtotal; it is the information expert

22. Continue • In the last step, to fulfill the responsibility of getting its subtotal, a Sales- Lineltem needs to know the product price. • Q: Who should handle this? • A: The ProductSpecification is an information expert on answering its price; therefore, a message must be sent to it asking for its price.

23. Discuss Expert Pattern • The main idea - give responsibility to individuals who have the information necessary to fulfill a task • Do It Myself • The fulfillment of a responsibility often requires information that is spread across different classes of objects. This implies that there are many "partial“ information experts who will collaborate in the task Contraindications • There are situations where a solution suggested by Expert is undesirable, usually because of problems in coupling and cohesion Benefits • Information encapsulation is maintained • Class definitions are easier to understand and maintain

24. Pattern 2: Creator Solution Assign class B the responsibility to create an instance of class A if one or more of the following is true: • B aggregatesA objects • B containsA objects • B recordsinstances of A objects • B closelyusesA objects • B hasthe initializing datathat will be passed to A when it is created Problem Who should be responsible for creating a new instance of some class?

25. Case Study: Apply Create Pattern in POS

26. Continue Q: Who should be responsible for creating a SalesLineltem instance? A: Sale- since it aggregates many SalesLineItem instances It requires a makeLineItem method be defined in Sale

27. Discussion of Creator • Creator pattern is used to find a creator that needs to be connected to the created object in any event • Creator suggests that the enclosing container or recorder class is a good candidate for the responsibility of creating the thing contained or recorded • Sometimes a creator is found by looking for the class that has the initializing data that will be passed in during creation For example, Sale  Payment • Low coupling (described next) is supported, which implies lower maintenance dependencies and higher opportunities for reuse Contraindications If creation requires significant complexity, We should delegate creation to a helper class called a Factory

28. Pattern 3: Low Coupling • Solution • Assign a responsibility so that coupling remains low. • Problem • How to support low dependency, low change impact, and increased reuse? • Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements. • A class with high (or strong) coupling relies on many other classes will cause the following problems: • Changes in related classes force local changes. • Harder to understand in isolation. • Harder to reuse because its use requires the additional presence of the classes on which it is dependent

29. Case Study: Apply Low Coupling in POS • Design 1: The Register class couples the Payment class. The Sale class couples the payment class • Design 2: The Sale class couples the payment class • Which one is better? Purely from the point of view of coupling, Design 2 is preferable because overall lower coupling is maintained.

30. Discussion of Low Coupling • Low Coupling is a principle to keep in mind during all design decisions; it is an underlying goal to continually consider • In object-oriented languages such as C++, Java, and C#, common forms of coupling from TypeX to TypeY include: • TypeX has an attribute (data member or instance variable) that refers to a TypeY instance, or TypeY itself • A TypeX object calls on services of a TypeY object • TypeX has a method that references an instance of TypeY, or TypeY itself, by any means. These typically include a parameter or local variable of type • TypeY, or the object returned from a message being an instance of TypeY • TypeX is a direct or indirect subclass of TypeY • TypeY is an interface, and TypeX implements that interface

31. Continue • Benefits: • not affected by changes in other components • simple to understand in isolation • convenient to reuse

32. Be careful of Inheritance • A subclass is strongly coupled to its superclass. Be careful since it is such a strong form of coupling • For example, suppose that objects need to be stored persistently in a relational or object database. In this case it is a relatively common design to create an abstract superclass called PersistentObjectfrom which other classes derive • Disadvantage • It highly couples domain objects to a particular technical service and mixes different architectural concerns • Advantage • Automatic inheritance of persistence behavior

33. Pattern 4: 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

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

35. Low Cohesion (Register has payment responsibility, and many other unrelated responsibility) The second design supports both high cohesion and low coupling, it is desirable. Case Study: Apply High Cohesion in POS

36. Discussion of High Cohesion • In practice, consideration of cohesion should not isolate from other responsibilities and other principles such as Expert and Low Coupling • Like Low Coupling, High Cohesion is a principle to keep in mind during all design decisions • How we design a class with high cohesion? • Assign a class with a relatively small number of methods, with highly related functionality, and does not do too much work. It collaborates with other objects to share the effort if the task is large • Contraindications • Grouping responsibilities or code into one class or component to simplify maintenance and development • Distributed server objects

37. Pattern 5: Controller • Solution • Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices: • Represents the overall system, device, or subsystem (facade controller). • Represents a use case scenario within which the system event occurs • Problem • Who should be responsible for handling an input system event?

38. Benefits of using controller • A controller supports the reuse of the logic and pluggable interfaces • It ensures that application logic is not handled in the interface layer. Because an interface-as-controller design (it is bound to a particular interface) reduces the opportunity to reuse logic in future applications • Reason about the state of the use case - It is sometimes necessary to ensure that system operations occur in a legal sequence

39. Case Study: Apply Controller in POS • There are several system operations (triggered by system events): • endSale() • enterItem() • makeNewSale() • makePayment()

40. Continue • Design Question: Who should handle incoming system events? • Answer: By Controller pattern, we use a controller class to handle all system events

41. Continue – Type of Controllers • The controller is a kind of facade into the domain layer from the interface layer • Two Types of Controller • Facade Controller - Represents the overall "system," device, or subsystem Register, POSSystem • Use-Case Controller - Represents a receiver or handler of all system events of a use case scenario ProcessSaleHandler

42. Choice of Controller Type • Facade controllers are suitable when • there are not "too many" system events, or • it is not possible for the user interface (UI) to redirect system event messages to alternating controllers, such as in a message processing system • Choose Use-Case controller if a facade controller leads to designs with low cohesion or high coupling, typically when the facade controller has excessive responsibilities. • A use-case controller is a good choice when there are many system events across different processes

43. Avoid Bloated Controllers • Poorly designed, a controller class will have low cohesion - unfocused and handling too many areas of responsibility • this is called a bloated controller • Signs of bloating include: • There is only a single controller (facade controller) class receiving all system events in the system, and there are many of them • The controller itself performs many of the tasks to fulfill the system event. This usually involves a violation of Information Expert and High Cohesion. • A controller has many attributes, and maintains significant information about the system or domain, which should have been distributed to other objects, or duplicates information found elsewhere • In this case, we can • Add more controllers (use-case controllers) • Design the controller so that it delegates the fulfillment of each system operation responsibility on to other objects

44. Interface Layer Should not Handle System Events • Assigning the responsibility for system operations to objects in the application or domain layer—using the Controller pattern rather than the interface layer supports increased reuse potential

45. Controller Class(es) in POS

46. Middle-Term Exam – Produce Analysis Model for the Payroll Application

47. Mid-term Exam: Analysis Model • Given the following: • Use-Case Model, especially the use-case flows of events • Payroll Requirements, Use-Case Model section • Key abstractions/classes • Architectural Analysis section • The Supplementary Specification • Payroll Requirements, Supplementary Specification section

48. Mid-term Exam: Analysis Model • Identify the following for a particular use case: • The analysis classes, along with their: • Brief descriptions • Stereotypes • Responsibilities • Produce the following for all the use cases: • The collaborations needed to implement the use case • Use-Case Realization - Interaction diagram for the use-case flows of events

49. Mid-term Exam: Analysis Model • Analysis class attributes and relationships • VOPC class diagram, containing the analysis classes, their stereotypes, responsibilities, attributes, and relationships • Due Date: 14th May 8:00 am