Feb 4, 200291.3913 Ron McFadyen1 founded on principles of good OO design idea was first put forth by Christopher Alexander (1977) in their work concerning.

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 Design Examples with GRASP
Object-Oriented Analysis and Design CHAPTER 17, 25: GRASP PATTERNS 1.
GRASP Patterns M Taimoor Khan
Oct 3, R. McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
Oct 2, Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
March R McFadyen1 Architecture Architecture involves the set of significant decisions about the organization of a software system, decisions.
March Ron McFadyen1 Ch 17: Use Case Realizations with GRASP Patterns Assigning responsibilities to objects to achieve user goals Section 17.4.
Feb R. McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m Function:
Oct Ron McFadyen1 Ch 17: Use Case Realizations with GRASP Patterns P. 248: “The assignment of responsibilities and design of collaborations.
Fall 2009ACS-3913 Ron McFadyen1 idea was first put forth by Christopher Alexander (1977) in his work on architectural design principles a pattern is a.
February Ron McFadyen1 From the Merriam-Webster’s online dictionary ( Main Entry: an·thro·po·mor·phism Pronunciation: -"fi-z&m.
Feb Ron McFadyen1 Use Case Realizations with GRASP Patterns “The assignment of responsibilities and design of collaborations are very important.
Low Coupling High Cohesion
NJIT 1 GRASP: Designing Objects with Responsibilities Chapter 17 Applying UML and Patterns Craig Larman.
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.
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.
GRASP PATTERNS Information Expert (Expert) Creator Controller © Lethbridge/Laganière 2001 Chapter 6: Using design patterns1.
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 )
1 Ch 18. Object Design Examples With Grasp Objectives Design use case realizations. Apply GRASP to assign responsibilities to classes. Apply UML to illustrate.
BTS430 Systems Analysis and Design using UML Design Patterns.
GRASP: Designing Objects With Responsibilities Chapter 17 Applying UML and Patterns -Craig Larman.
GRASP: Designing Objects With Responsibilities
Object Design Examples with GRASP (Ch. 18)
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.
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.
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 -
Fall 2009ACS-3913 Ron McFadyen1 Use Case Realizations with GRASP Patterns “The assignment of responsibilities and design of collaborations are very important.
OO Design Roshan Chitrakar. Analysis to Design Do the RIGHT thing Do the RIGHT thing Requirement Analysis Requirement Analysis Domain Modeling with addition.
TK2023 Object-Oriented Software Engineering CHAPTER 8 LOGICAL ARCHITECTURE.
Copyright © Craig Larman All Rights Reserved COMP-350 Object-Oriented Analysis and Design GRASP: Designing Objects with Responsibilities Reference:
GRASP: Designing Objects With Responsibilities
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.
1 Design Model Use-Case realizations with GRASP Larman chapter 17.
Oct 3, Ron McFadyen1 GRASP Patterns 1.Expert 2.Creator 3.Controller 4.Low Coupling 5.High Cohesion.
OO Methodology Elaboration Phase Iteration 1- Part 2.
TK2023 Object-Oriented Software Engineering CHAPTER 13d GRASP Patterns: High Cohesion.
Ch 17: Use Case Realizations with GRASP Patterns
TK2023 Object-Oriented Software Engineering
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
BTS530: Major Project Planning and Design
GRASP : Designing Objects with Responsibilities
GRASP Design Patterns: Designing Objects with Responsibilities
Presentation transcript:

Feb 4, Ron McFadyen1 founded on principles of good OO design idea was first put forth by Christopher Alexander (1977) in their work concerning architectural design principles rules of thumb not new ideas notion of pattern is vague: “one person’s pattern is another person’s primitive building block” a pattern is a named problem/solution pair that can be applied in new contexts Patterns

Feb 4, Ron McFadyen2 Guiding principles to help us assign responsibilities GRASP: –General Responsibility Assignment Software Patterns –Very very fundamental, simple, basic principles of object design. Fundamental Principles of Object Design GRASP Patterns

Feb 4, Ron McFadyen3 Expert Creator Controller Low Coupling High Cohesion CH 16 GRASP Patterns

Feb 4, Ron McFadyen4 (Information) Expert What is the most basic, general principle of responsibility assignment? Assign a responsibility to the object that has the information necessary to fulfill it. –“That which has the information, does the work.” –E.g., What software object calculates sales tax? What information is needed to do this? What object or objects has the majority of this information.

Feb 4, Ron McFadyen5 Creator What object creates an X? –Ignores special-case patterns such as Factory. Choose an object C, such that: –C contains or aggregates X –C closely uses X –C has the initializing data for X

Feb 4, Ron McFadyen6 Controller What object in the domain (or application layer) receives requests for work from the UI layer?

Feb 4, Ron McFadyen7 Basic Principle: Interface objects should not have responsibility for handling system events Assign responsibility to a Controller, an object in the application/domain layer. Choose, or invent, an object in the application layer for this. Controller: a non-user interface object responsible for receiving or handling a system event. In the Process Sale Use Case, there are several system evetns: makeNewSale, enterItem, endSale, makePayment

Feb 4, Ron McFadyen8 makeNewSale enterItem endSale makePayment Part of Figure 9.1 System Operations

Feb 4, Ron McFadyen9 Candidates: –An object whose name reflects the use case. e.g. ProcessSaleHandler –An object whose name reflects the overall server, business, or large-scale entity. A kind of “façade” object e.g. Register Basic Principle: Interface objects should not have responsibility for handling system events Assign responsibility to the application/domain layer. Choose, or invent, an object in the application layer for this.

Feb 4, Ron McFadyen10 Figure Allocating System Operations Register has been chosen to handle all system operations Ch 20 shows the code for this Use Case handlers are chosen

Feb 4, Ron McFadyen11 public void endSale ( ) { sale.becomeComplete(); } public void enterItem ( String id, int quantity ) { ProductSpecification spec = catalog.getSpecification( id ); sale.makeLineItem( spec, quantity ); } public void makeNewSale ( ) { sale = new Sale(); } public void makePayment (Money cashTendered ) { sale.makePayment( cashTendered ); } System event handling in Register The Controller doesn’t do much … delegates work to other objects … it receives the request and coordinates fulfillment

Feb 4, Ron McFadyen12 The Controller pattern promotes reuse UI code is not intertwined with system event code UI can be replaced Multiple UIs could be utilized When a legal sequence of operations must occur, state information must be kept … the Controller object is an excellent choice for this information

Feb 4, Ron McFadyen13 Low Coupling When we need to assign a responsibility to a class, we should do so such that coupling remains low. What does low coupling mean? … a class with high coupling has knowledge of, or is connected to, or relies on many other classes Example Assume we need to create a Payment instance … what class should do this?

Feb 4, Ron McFadyen14 Creator pattern suggests Register Figure 16.9 Register creates Payment (Collaboration diagram)

Feb 4, Ron McFadyen15 An alternative design is given in Figure Which of the two designs, figures 16.9 and 16.10, supports lower coupling?

Feb 4, Ron McFadyen16 High Cohesion When we need to assign a responsibility to a class, we should do so such that cohesion remains high cohesion: a measure of how strongly related and focussed the responsibilities of an object are Rule of Thumb (ROT): A class with high cohesion has a relatively small number of methods, with highly related functionality, and does not do too much work … it collaborates with others to get work done Example Assume we need to create a Payment instance … what class should do this?

Feb 4, Ron McFadyen17 First solution given in Figure (note this Sequence Diagram represents the same logic as the Collaboration diagram in Figure 16.9)

Feb 4, Ron McFadyen18 Figure gives a second solution (note this Sequence Diagram represents the same logic as the Collaboration diagram in Figure 16.10) Which solution supports higher cohesion for Register?

Feb 4, Ron McFadyen19 Note, when considering which class to assign the responsibility of creating a payment, the text arrives at the same solution when applying both principles