1 Chapter 17 GRASP Design Patterns: Designing Objects with Responsibilities.

Slides:



Advertisements
Similar presentations
GRASP: Designing Objects with Responsibilities
Advertisements

Software Engineering 1 Object-oriented Analysis and Design Applying UML and Patterns An Introduction to Object-oriented Analysis and Design and Iterative.
Object-Oriented Analysis and Design
Object Design Examples with GRASP
Object-Oriented Analysis and Design CHAPTER 17, 25: GRASP PATTERNS 1.
Oct 2, Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
Feb R. McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
NJIT More GRASP Patterns Chapter 22 Applying UML and Patterns Craig Larman Prepared By: Krishnendu Banerjee.
February Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m.
Object-Oriented Software Engineering Practical Software Development using UML and Java Design Patterns Sources: Chapter 6: Using Design Patterns, and Chapter.
Object-Oriented Analysis and Design
GRASP : Designing Objects with Responsibilities
October 20, 2005Architectural Design, ECEN Architectural Design Architecture Business Cycle Design for Maintainability ECEN 5543 / CSCI 5548 SW Eng.
Fall 2009ACS-3913 Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Date: 1753 an interpretation.
Feb 4, Ron McFadyen1 founded on principles of good OO design idea was first put forth by Christopher Alexander (1977) in their work concerning.
Chapter 25 More Design Patterns.
CSSE 374: More GRASP’ing and Use Case Realization Steve Chenoweth Office: Moench Room F220 Phone: (812) These.
GRASP Design Patterns: Designing Objects with Responsibilities
GRASP Pattern Zhen Jiang West Chester University
GRASP Principles. How to Design Objects The hard step: moving from analysis to design How to do it? –Design principles (Larman: “patterns”) – an attempt.
GRASP Patterns Presented By Dr. Shazzad Hosain. Patterns A pattern describes a problem and solution, and given a name. Examples are Singleton, Adapter,
Chapter 18 Object Design Examples with GRASP. Objectives Design use case realizations –A use-case realization describes how a particular use case is realized.
Chapter 17. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after identifying requirements, create domain model, define responsiblities.
1 SAD2 - UML 4 th Lecture Class Diagram in Construction Phase Patterns Case Study Lecturer: Dr Dimitrios Makris
SOEN 6011 Software Engineering Processes Section SS Fall 2007 Dr Greg Butler
Architecture GRASP Realization of use cases in interaction diagrams Design class diagram Design ( how )
Chapter 7: Object Design Examples with GRASP. Objective Design use case realizations. Apply GRASP to assign responsibilities to classes. Apply UML to.
Chapter 26 GoF Design Patterns. The Adapter Design Pattern.
BTS430 Systems Analysis and Design using UML Design Patterns.
Chapter 17. Initial Object Design Inputs: requirements meetings various Use Cases – 10% complete Key risks addressed with preliminary programming System.
GRASP: Designing Objects With Responsibilities Chapter 17 Applying UML and Patterns -Craig Larman.
GRASP: Designing Objects With Responsibilities
Object-Oriented Analysis and Design Mar 11, 2008.
17. GRASP—Designing Objects with Responsibilities III CSE5324 Lecture Quiz 17 due at 5 PM Thursday, 8 October 2015.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Chapter 17 GRASP: Designing Objects with Responsibilities. 1CS6359 Fall 2011 John Cole.
Design Patterns. Patterns “Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution.
COMP 6471 Software Design Methodologies Winter 2006 Dr Greg Butler
Copyright © Craig Larman All Rights Reserved Responsibility-Driven Design with the GRASP Patterns.
Object-Oriented Design Part 2
Next Gen POS Example GRASP again. Same Patterns Different Example!
GRASP: Designing Objects with Responsibilities
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Object Design and Use- Case Realizations with GRASP Patterns.
What to remember from Chap 13 (Logical architecture)
Object-Oriented Analysis and Design Mar 9, 2008.
OO Methodology Elaboration Iteration 2 - Design Patterns -
OO Design Roshan Chitrakar. Analysis to Design Do the RIGHT thing Do the RIGHT thing Requirement Analysis Requirement Analysis Domain Modeling with addition.
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
GRASP: Designing Objects With Responsibilities
Chapter 17 Designing with Responsibilities. Fig
References: Applying UML and patterns Craig Larman
OO Methodology Elaboration Phase Iteration 1- Part 3.
Design. 2 The Need for Software Blueprints Knowing an object-oriented language and having access to a library is necessary but not sufficient in order.
Oct 3, Ron McFadyen1 GRASP Patterns 1.Expert 2.Creator 3.Controller 4.Low Coupling 5.High Cohesion.
General Principles in Assigning Responsibilities Responsibilities Responsibility-Driven Design CRC Cards GRASP.
OO Methodology Elaboration Phase Iteration 1- Part 2.
Elaboration: Iteration 2. Elaboration: Iteration 2 Basics Iteration 1 ends with : All the software has been tested: The idea in the UP is to do early,
Object Design Examples with GRASP
GRASP – Designing Objects with Responsibilities
TK2023 Object-Oriented Software Engineering
Chapter 12: Collaboration Diagram - PART2
Conception OBJET GRASP Patterns
DESIGN MODEL: USE-CASE REALIZATIONS WITH GRASP PATTERNS
TK2023 Object-Oriented Software Engineering
Presentation on GRASP Patterns Submitted by
Apply Expert, Creator, Controller, Low Coupling, High Cohesion
GRASP : Designing Objects with Responsibilities
GRASP Design Patterns: Designing Objects with Responsibilities
Next Gen POS Example GRASP again.
Object Oriented System Design Responsibilities
Presentation transcript:

1 Chapter 17 GRASP Design Patterns: Designing Objects with Responsibilities

2

3 Responsibility-Driven Design (RDD) A way of thinking about OOD: –In terms of Responsibilities Roles Collaborations Common responsibility categories: –Doing: Doing something itself: –Creating and object or doing a calculation Initiating action in other objects Controlling and coordinating activities in other objects –Knowing: Knowing about private data Knowing about related objects Knowing about things it can derive or calculate Bigger responsibilities may take several classes Guideline: –Domain model helps with “knowing” –Interaction diagrams help with “doing”

4 RDD and Collaboration Responsibilities implemented by methods Some methods act alone and do a job Some collaborate with other objects and methods –Example: Sale class has getTotal() method –Sale and getTotal() collaborate with other objects to fulfill a responsibility SalesLineItem objects and getSubtotal() methods RDD: Community of collaborating objects

5 RDD and Interaction Diagrams We decide on responsibility assignment when drawing interaction diagrams

6 Patterns Patterns: A repertoire of –general principles –idiomatic solutions to guide us in the creation of software A pattern: A named and well-known problem/solution pair that –Can be applied in new contexts –With advice on how to apply it in novel situations –With a discussion of its trade-offs, implementations, variations, … Names facilitate communication about software solutions Some patterns may seem obvious: That’s a good thing!

7 Pattern Example Pattern name Problem: Solution Information Expert What is a basic principle by which to assign responsibilities to objects? Assign a responsibility to (one of?) the class that has the information needed to fulfill it

8 Well-known Pattern Families GRASP: –General Responsibility Assignment Software Patterns (or Principles) –9 Patterns GoF: Design Patterns: Elements of Reusable Object-Oriented Software –GoF: Erich Gamma Richard Helm Ralph Johnson John Vlissides –23 patterns –Some of these will be covered

9 GRASP Patterns Creator –Who creates? Information Expert –Who, in the general case, is responsible? Low Coupling –Support low dependency and increased reuse Controller –Who handles a system event? High Cohesion –How to keep complexity manageable? Polymorphism –Who, when behavior varies by type? Pure Fabrication –Who, when you are desperate, and do not want to violate High Cohesion and Low Coupling? Indirection –Who, to avoid direct coupling? Law of Demeter (Don’t talk to strangers) –Who, to avoid knowing about the structure of indirect objects?

10 The “Creator” Pattern Example: Monopoly game –See domain model example Problem: Who creates the Square object in a Monopoly game? –Java answer: Any object could –Common answer: Make Board create Square objects Is this good design? –Intuition: Containers should create the things contained in them –Issue: No classes yet, only have the domain model –Look at the domain model for inspiration to pick the first important software classes

11 The Creator Pattern

12 Monopoly Iteration-1 Domain Model (Again)

13 The “Information Expert” of “Expert” Pattern Problem: Given the name of a Monopoly square, we want to get a reference to the Square object with that name –Most developers would choose the Board object to do this job –Intuition: A responsibility needs information for its fulfillment –Info about other objects, –an object’s own state –The world around an object –information an object can derive –The object that will do the job must know all Squares –Board has the information necessary to fulfill the responsibility

14 The “Information Expert” Pattern Name Problem: Solution (advice): Information Expert or Expert What is a basic principle by which to assign responsibilities to objects? Assign a responsibility to the class that has the information needed to fulfill it

15 The “Low Coupling” Principle Name Problem: Solution (advice): Low Coupling How to reduce the impact of change on software? Assign responsibilities so that (unnecessary) coupling remains low. Use this principle to evaluate alternatives.

16 Evaluating the Effect of Coupling Coupling: A measure of how strongly one element is connected to, has knowledge of, or depends on other elements The greater the coupling, the greater the dependence between objects –Coupling is avoided because it goes against OO principles Why is low coupling good? It reduces time, effort and defects involved in modifying software The “Expert” pattern supports low coupling

17 The “Controller Pattern” Question: What first object after or beyond the UI layer should receive the message from the UI layer? –Assign the responsibility for handling a system event message to a class representing one of these choices: 1.The business or overall organization (a façade controller). 2.The overall "system" (a façade controller). 3.An animate thing in the domain that would perform the work (a role controller). 4.An artificial class (Pure Fabrication) representing the use (a use case controller).

18 The “Controller” Pattern

19 Monopoly Controller Alternatives Option 1: Represents the overall “system” or a “root object” –An object called MonopolyGame Option 2: Represents a device that the software is running within –It doesn’t really apply here. –It applies to designs with specialized hardware devices: Phone, BankCashMachine, … Option 3: Represents the use case or session. –The use case that the playGame system operation occurs in is called Play Monopoly Game –A class such as PlayMonopolyGameHandler (or...Session) might be used The very first option looks good if there are only a few system operations

20 High Cohesion Cohesion: –How are the operations of a software element functionally related? –How much work is a software element doing? Example: –The “Big” class: 100 methods, 2000 lines of code –The “Small” class 10 methods, 200 lines of code. –“Big” is probably covering many different areas of responsibility Examples: database access AND random number generation –Big has less focus or functional cohesion than small An object that has too many different kinds of responsibilities probably has to collaborate with many other objects –Low cohesion  High coupling, Both bad.

21 The “High Cohesion” Principle Name: Problem: Solution (advice): High Cohesion How to keep objects focused, understandable, and manageable, and as as side effect, support low coupling? Assign responsibilities so that cohesion remains high. Use this to evaluate alternatives.

22 A more detailed look at “Creator” Problem: Who should be responsible for creating a new instance of some class. Solution: B should create an instance of A if –B “contains” or compositely aggregates A –B records A –B closely uses A –B has the initializing data for A that will be passed to A when it is created. Thus, B is an Expert with respect to creating A. If more than one of the above applies, prefer a class B which aggregates or contains A.

23 Partial Domain Model Basic intent of the “Creator” pattern: Find a creator that needs to be connected to (dependent on or associated with) the created object anyway. Supports low coupling.

24 Creating a SalesLineItem object

25 The “Creator” pattern Another use: Identify a creator by looking for a class that has the initialization data that will be passed in during creation. –Actually an example of the “Expert” pattern Initialization data passed in to an “initialization method” –Often a constructor with parameters –Or a factory method Example: –A Payment instance, when created needs to be initialized with the Sale total. –Sale knows Sale total. Good candidate for creating Payment.

26 Information Expert Problem: What is a general principle of assigning responsibilities to objects? Solution: Assign a responsibility to the information expert –The information expert: The class that has the information to fulfill the responsibility Guideline: Start by clearly stating the responsibility –Example: Who should be responsible for finding out what checker is located at a given coordinate on the board?

27 Information Expert Question: Where do we look to analyze the classes that have the info needed? –The Domain Model? Or, –The Design Model (class and interaction diagrams)

28 Information Expert Question: Where do we look to analyze the classes that have the info needed? –The Domain Model? –The Design Model (class and interaction diagrams)? Answer: –If there are relevant classes in the Design Model, look there first –Otherwise, look in the domain model. Use it to inspire the definition of new Design classes.

29 Applying the “Information Expert” Pattern What information do we need to determine the grand total of a Sale? –All the SalesLineItem instances –Sum of their subtotals A Sale instance contains these –By “Information Expert”, it is a suitable class for computing the grand total

30 Applying Information Expert

31 Applying Information Expert (cont’d) Next question: What information do we need to know to determine the line item subtotal? –Answer: SalesLineItem.quantity and SalesLineItem.price Question: Who knows these? –Answer: SalesLineItem –By “information expert”, SalesLineItem should compute the subtotal

32 Applying Information Expert (cont’d)

33 Applying Information Expert (cont’d) Next issue: Who should return the price of an item? –Who knows the price of an item? ProductDescription –By “information expert”, SalesLineItem asks ProductDescription to return the price.

34 Applying Information Expert (cont’d) Lesson learned: Many partial information experts collaborate in a task

35 Warning: Don’t blindly apply “Information Expert” Example: –Who should be responsible for saving a Sale in a database? Sale has all the information that needs to be saved –But acting on this alone leads to problems in cohesion, coupling, and duplication –Sale class must now contain logic related to database handling SQL, JDBC,... –Many other objects that need to be stored will duplicate the “saving” code

36 Low Coupling Problem: How to support low dependency, low change impact, and increased re-use? Why is a class with high (or strong) coupling bad? –Forced local changes because of changes in related classes –Harder to understand in isolation –Harder to re-use Because it requires the presence of classes that it depends on Solution: Assign responsibilities so that coupling remains low. Important: Use this principle to evaluate alternatives

37 Two alternative responses to “Who creates Payment?”

38 Two alternative responses to “Who creates Payment?” The second alternative leads to less coupling –Avoids an association between Register and Payment –Sale and Payment already related

39 Common Forms of Coupling from Type X to Type Y TypeX has an attribute 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 –TypeY itself (static method call, etc.) Typically occurs when an argument, return value or a local variable of TypeX is type TypeY TypeX is a direct or indirect subclass of TypeY TypeY is an interface, and TypeX implements that interface

40 Guidelines A subclass is VERY strongly coupled to its superclass –Think carefully before using inheritance Some moderate degree of coupling between classes is normal and necessary for collaboration High coupling to stable or pervasive elements is NOT a problem –Examples: Java libraries High coupling is a problem only in areas where change is likely –Example: Your design, as it evolves

41 Controller pattern “System” class: Represents system-level operations No class called system really The controller class is assigned responsibility for system-level operations

42 What object should be the Controller for enterItem?

43 Two controller alternatives

44 Allocation of system operations to two kinds of controllers

45 The controller pattern A delegation pattern Use same controller class for all system events of one use case –Controller maintains information about the state of the use case –Helps identify out-of-sequence operations Example: makePayment before endSale Common defect in design of controllers: Overassignment of responsibility –Controller may suffer from low cohesion Benefits of controller pattern: –Increased potential for reuse and pluggable interfaces –Opportunity to reason about the state of the use case

46 Bloated controllers Signs of a bloated controller –There is a single controller receiving many system events –Controller itself performs the tasks instead of delegating them –Controller has many attributes, maintains a lot of info about the system or domain Better to distribute these to other objects Cures –Add more controllers –Design the controller to delegate the work

47 Domain Layer Controller

48 Undesirable: UI Layer object is controller

49 Swing Example Code where controller is called.... public void actionPerformed(ActionEvent e) { // read itemID and quantity from Swing // GUI components... register.enterItem(itemID, quantity); }

50 High Cohesion Problems with a class with low cohesion: –Hard to comprehend –Hard to reuse –Hard to maintain –Constantly affected by change

51 Danger: Register has potential to do too much work

52 Better design: Register delegates, has high cohesion

53 Modular Design Modularity: The property of a system that has been decomposed into a set of cohesive and loosely coupled modules Exceptions to high cohesion and modularity –Example: To simplify maintenance by one SQL expert, group all SQL-related functionality of all classes into one separate class –Distributed server objects: Because of cost of communication, might make sense to have few, large server objects Example: Instead of three fine-grained operations, setName, setSalary, setHireDate, have one coarse-grained operation, setData