Object-Oriented Analysis and Design CHAPTER 17, 25: GRASP PATTERNS 1.

Slides:



Advertisements
Similar presentations
Object-Oriented Analysis and Design
Advertisements

Object Design Examples with GRASP
GRASP The other four What are the first five? What is the goal/purpose of using patterns?
Object-Oriented Analysis and Design CHAPTERS 12-14: INTRODUCTION TO DESIGN 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:
Object-Oriented Software Engineering Practical Software Development using UML and Java Design Patterns – Part 2 Sources: Chapter 6: Using Design Patterns,
Chapter 25 GRASP: More Objects with Responsibilities 1CS6359 Fall 2011 John Cole.
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.
Chapter 25 More Design Patterns. Polymorphism Issue: Conditional variation –If-then-else or switch statements –New variation or case: Conditional statements.
Object-Oriented Analysis and Design
GRASP : Designing Objects with Responsibilities
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 26 Applying Gang of Four Design Patterns 1CS6359 Fall 2012 John Cole.
Chapter 25 More Design Patterns.
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.
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 Chapter 17 GRASP Design Patterns: Designing Objects with Responsibilities.
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 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
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
GoF Design Patterns (Ch. 26). GoF Design Patterns Adapter Factory Singleton Strategy Composite Façade Observer (Publish-Subscribe)
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.
Next Gen POS Example GRASP again. Same Patterns Different Example!
CSSE 374: More GRASP’ing for Object Responsibilities
GRASP: Designing Objects with Responsibilities
IntellAgile Copyright © 2002 Craig Larman. All rights reserved. Object Design and Use- Case Realizations with GRASP Patterns.
Object-Oriented Analysis and Design CHAPTERS 9, 31: DOMAIN MODELS 1.
Object-Oriented Analysis and Design Mar 9, 2008.
OO Methodology Elaboration Iteration 2 - Design Patterns -
Behavioral Patterns CSE301 University of Sunderland Harry R Erwin, PhD.
Patterns Roberto Damiani Mendes. Roteiro Definition; Definition; Architecture Patterns; Architecture Patterns; Design Patterns; Design Patterns; GRASP.
OO Design Roshan Chitrakar. Analysis to Design Do the RIGHT thing Do the RIGHT thing Requirement Analysis Requirement Analysis Domain Modeling with addition.
SOEN 343 Software Design Section H Fall 2006 Dr Greg Butler
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
Chapter 17 Designing with Responsibilities. Fig
References: Applying UML and patterns Craig Larman
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.
GRASP: More Patterns for Assigning Responsibilities Presented By Dr. Shazzad Hosain.
Oct 3, Ron McFadyen1 GRASP Patterns 1.Expert 2.Creator 3.Controller 4.Low Coupling 5.High Cohesion.
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
BTS530: Major Project Planning and Design
GoF Patterns (GoF) popo.
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
Apply Expert, Creator, Controller, Low Coupling, High Cohesion
GRASP : Designing Objects with Responsibilities
GRASP Design Patterns: Designing Objects with Responsibilities
Chapter 25 GRASP The other four.
Chapter 25 GRASP The other four.
Presentation transcript:

Object-Oriented Analysis and Design CHAPTER 17, 25: GRASP PATTERNS 1

What will we learn? GRASP – More patterns 2

GRASP Patterns Recall that these are general principles for software design Patterns of design that have been successfully applied We have explored 3: Creator (who creates a new instance) Expert (general principle for assigning responsibilities to objects) Low Coupling (how best to support low dependency, low change impact, high reuse) Now we will explore the remaining six patterns 3

GRASP Patterns: Controller Problem: What first object beyond the User Interface layer receives and coordinates (“controls”) a system operation? Solution: Assign responsibility to a class representing one of the following choices: Represents the overall “system”, a “root object”, a device that the software is running in, or a major subsystem (these are façade controllers) Represents a use case scenario within which the system event occurs, often called a “Handler”, “Coordinator”, or “Session”. Use the same controller class for all system events in the same use case scenario. Note a “session” is a conversation between the system and an actor, and is often organized in terms of use cases System operations are operations that are performed as the result of a major system (input) event, like hitting “Submit” on a form or pressing the “End Sale” button in the POS A Controller is the first object (beyond any User Interface object) that is responsible for receiving or handling the event and generating the operation 4

GRASP Patterns: Controller Example During Analysis, could have a conceptual class called “System” that owns system operations – but this may not directly translate to a similar class in design … 5

6

GRASP Patterns: Controller For the POS example, we could assign the operations of enterItem and endsale to the Register object, or we could create a POSSystem object, or create ProcessSaleHandler, ProcessSaleSession classes and assign the task of handling the system operations to them The Controller is a delegation principle; since we don’t want the objects in the UI layer to do application logic, the Controller principle helps to summarize the choices the developer has to decide which Domain object will receive the work requests Choosing a handler for system events May have different controller classes for different use cases Make sure the controller you specify delegates the work, and does not do it itself. It coordinates work, controls activity 7

GRASP Patterns: Controller Façade controllers (one class to represent all system operations) are useful when there are not too many system events, or if the UI classes cannot redirect system event messages to specific controllers (message-processing). Individual use case controllers are good if the façade controller is becoming “bloated” with responsibilities, implying high coupling Controllers are often seen in web UI, but the principle of Model-View Separation does still apply This is the Model-View-Controller Note that even if you decide that individual handlers will be responsible for particular use cases, you still need an overall “main” function to initialize everything Book shows an example of Java code where the Register handles the enterItem system operation; the Register and client UI still need to be instantiated by something 8

GRASP Patterns: Bloated Controller A controller is “bloated” if it is doing too much: A single controller receiving too many system events, the controller itself is performing the logic to process the system event (acting like an Expert), the controller has many attributes and maintains significant amounts of information Think of the controller as being the “team manager” – delegates work to the experts Again, the UI layer does not handle system events! It delegates responsibility for handling events to the Application or Domain Layer, where a controller takes over (and probably delegates the work to other Domain Objects) Not a good idea to have the UI object directly delegate the work to the Domain Object – this would lead to business logic being used in the UI Layer. See following slides. 9

10

11

GRASP Patterns: High Cohesion Problem: How to keep objects focused, understandable, and manageable, and as a result support Low Coupling? Solution: Assign a responsibility so that cohesion remains high. In other words, only assign strongly related responsibilities to an object. An element with highly related responsibilities that does not do a tremendous amount of work has high cohesion. Low cohesion classes: Complicated, hard to understand Hard to reuse Hard to maintain Brittle; easily affected by change 12

High Cohesion: POS Example The POS system needs to handle a makePayment system event; if we are using the Register as the controller, it may make sense to have the Register create the Payment object and then send an addPayment() message to the Sale object, and include the new Payment object as a parameter. 13

High Cohesion: POS Example Note this is OK for this simple scenario, but using this approach we may end up adding more and more responsibilities to the Register. We may have selected the Register object as our controller (since in the real world domain the register is probably the device the software is running on), but remember controllers should delegate Adding too much functionality to the Register object can lead to low cohesion – a complicated object that does too many different things Better approach may be to have the Register pass the makePayment() message to the Sale, and have the Sale object instantiate the Payment (next slide) 14

15

High Cohesion: Observations High cohesion objects are useful when dealing with relational databases – design separate classes to deal with different parts of the RDB In general, high cohesion classes usually have few methods with highly related functionality Collaborate with other objects to accomplish tasks Analogy: Avoid “overloading” one member of your team with too many responsibilities – distribute the workload among experts, don’t assign them unrelated activities This is similar to “modular design” High cohesion is related to low coupling – bad cohesion leads to bad coupling, and viceversa 16

Polymorphism Problem: How to handle alternatives based on type? How to create pluggable software components? Solution: When related alternatives or behaviors vary by type (or class), assign responsibilities for the behavior (using polymorphic operations) to the types for which the behavior varies. Polymorphism: Here it means “giving the same name to services in different objects” when services are similar or related. So for example, the different objects may implement a common interface or be members of the same super-class. Example: Consider the NextGen POS system. Suppose we are designing the system, and we are assigning the responsibility for a getTaxes() system operation. The system needs to support various different tax calculators. They may each have a different interface – how to do this efficiently? 17

Polymorphism: NextGen Example This is a good candidate for polymorphism – we have many different objects (the tax calculators) that each do the same work, but in related (different) ways The solution would be to create an interface that defines a getTaxes() method, and then define adaptor classes for each calculator that support the interface and implement the getTaxes() method in a way that is consistent with that calculator Notice we have used the Polymorphism principle to assign the responsibility of handling the getTaxes() system operation to the entities for which the behavior varies. In other words, rather than try to harmonize all of the different calculators in our system, we simply created adaptor classes and let each adaptor class handle the responsibility. Much more maintainable, flexible, robust – can plug in new calculators, remove calculators, etc. without changing the base system 18

19

Polymorphism: Monopoly Example In Monopoly, there are different kinds of squares that require different behavior when landed on: Go square – player receives $200 Income Tax square – player must pay tax amount Go to Jail square – player goes to the Jail Regular square – nothing new happens right now, in more detailed use case player can buy or pay rent When designing the simulation application system, we must decide how to assign the responsibility of handling the system operation that occurs when a Player rolls the dice and lands on a square Note that although the Player always lands on a square, there are different behaviors depending upon Square type Avoid doing this as a “Switch” statement in the system – too rigid. Use Polymorphism. 20

21

Polymorphism: Monopoly Example Here we have defined an abstract Square class with an abstract method called landedOn(). We can then define subclasses for the types of Squares, and each can (using Polymorphism) define their own behaviors for the landedOn() method. Note the Player only needs to be aware of the landedOn() method name The Player knows the current location (Square) he/she is on, and the Player rolls the dice and gets the value The Player can then check with the Board to get the next square, and then use the landedOn() method to initiate the behavior associated with that square. This is better than having the Player maintain a list of behaviors for each type of square and then having the Player implement the behavior See next slide for examples 22

23

24

Polymorphism: Observations Polymorphism is fundamental when designing a system for which a system operation may generate multiple variations of behavior (landedOn(), getTaxes()) Usually, this will result in the definition of interfaces or abstract classes Use interfaces to support polymorphism without creating a new class hierarchy In general, creating interfaces is more flexible, since you do not need to be a sub-class of the super-class to implement the interface 25

Pure Fabrication Problem: If you do not want to violate High Cohesion and Low Coupling, what object should be assigned responsibility if the solutions offered by the Expert principle are not valid? Solution: Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a domain conceptual class – i.e., create a new object that does not correspond to a domain object, but has high cohesion, low coupling, and is reusable. This allows us to make up new classes that are not implied by (or directly associated with) the Domain Model Often useful to collect responsibilities which simply cannot be assigned to existing objects in a good (high cohesion, low coupling) way 26

Pure Fabrication: NextGen POS Example Suppose that in the NextGen system there is a system operation that requires instances of Sale to be saved to a relational database for logging. Using the Expert principle, we could include the responsibility of handling this operation in the Sale object, but that would require adding a (possibly complicated) set of database interaction code into the Sale object Sale class becomes less cohesive – DB activity not really related to the purpose of the class Couples the Sale class to the DB interface We may want to save instances of other classes into the DB, not just Sale. We need to generalize this action Better solution is to create a new class that is solely responsible for saving instances of objects into the database Note this design has better cohesion, coupling, reuse potential 27

Pure Fabrication: Monopoly Example Currently, the Player rolls the dice (once for each die), gets the face value as a result of each roll, and computes the total Somewhat complicates the Player object, and the Dice object is not very reusable Can use Pure Fabrication to create a new class, Cup The Cup will be associated with the Dice object, and the Player will request that the Cup roll the dice and return the total The class Cup can be designed so that on instantiation the total number of die is set This class may then be used by other game systems, as is. See the next slide for Design Model diagrams 28

29

Indirection Problem: Where to assign a responsibility to avoid a direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains high? Solution: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled. This is very related to Polymorphism and Pure Fabrication Essentially, create a “go between” or mediator class to insulate (protect) the “inner” design from external elements which may change The same database example we used for Pure Fabrication would also be an example of Indirection (see next slide) 30

31

Protected Variations Problem: How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements? Solution: Identify points of predicted variation or instability, assign responsibilities to create a stable interface around them One example: The “Don’t talk to strangers” principle, which states that an object’s methods should only send messages (i.e. use methods) of objects that it is directly familiar with Avoid a “chain” of method calls (foo.getA().getB().getC().getD()), because this traverses along the path of object connections to send a message to a distant object. Dangerous because of the possibility of change along the chain, which could easily break this design (further along you go, more likely something will change and so break) Related to Indirection, Polymorphism (the Tax Calculator example shows Indirection) 32

GRASP: Final Thoughts Note that these are principles of OOD – they are not templates or recipes Sometimes, the principles contradict each other – as a designer, you need to discover the best approach Reuse is always a strong motivator, but there are exceptions There are times when these principles can be ignored or directly violated – see the sections of the text for contradiction examples 33

Takeaways from Chapter 17, 25 Know the nine GRASP principles, and how to apply them 34

Next … We apply GRASP and begin the design of the POS system – read Chapter 18 35