NJIT 1 GRASP: Designing Objects with Responsibilities Chapter 17 Applying UML and Patterns Craig Larman.

Slides:



Advertisements
Similar presentations
GRASP: Designing Objects with Responsibilities
Advertisements

Object-Oriented Analysis and Design
Object Design Examples with GRASP
Chapter 22 Object-Oriented Systems Analysis and Design and UML Systems Analysis and Design Kendall and Kendall Fifth Edition.
Chapter 1 Object Oriented Analysis and Design. UML, Patterns, and Object-Oriented Analysis and Design  The essential skills for the creation of well-designed,
Object-Oriented Analysis and Design CHAPTERS 12-14: INTRODUCTION TO DESIGN 1.
OOAD Using the UML - Use-Case Analysis, v 4.2 Copyright  Rational Software, all rights reserved 1/18 Use Case Analysis – continued Control Classes.
GRASP Patterns M Taimoor Khan
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:
Copyright W. Howden1 Lecture 6: Design Evaluation and Intro to OO Design Patterns.
© 2005 Prentice Hall8-1 Stumpf and Teague Object-Oriented Systems Analysis and Design with UML.
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.
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.
The chapter will address the following questions:
Object-Oriented Design. From Analysis to Design Analysis Artifacts –Essential use cases What are the problem domain processes? –Conceptual Model What.
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 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.
Requirements To Design--Iteratively Chapter 12 Applying UML and Patterns Craig Larman.
1 On to Object Design Chapter 14 Applying UML and Patterns.
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
Object-Oriented Analysis and Design Mar 11, 2008.
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
Systems Analysis and Design in a Changing World, 3rd Edition
Requirements as Usecases Capturing the REQUIREMENT ANALYSIS DESIGN IMPLEMENTATION TEST.
GRASP: Designing Objects with Responsibilities
1 COMP 350: Object Oriented Analysis and Design Lecture 1Introduction References: Craig Larman Chapter 1.
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)
Introduction to Design Patterns Part 1. © Lethbridge/Laganière 2001 Chapter 6: Using design patterns2 Patterns - Architectural Architectural Patterns:
Object-Oriented Analysis and Design Mar 9, 2008.
Patterns Roberto Damiani Mendes. Roteiro Definition; Definition; Architecture Patterns; Architecture Patterns; Design Patterns; Design Patterns; GRASP.
TK2023 Object-Oriented Software Engineering CHAPTER 12 Introduction to Responsibility-Driven Design.
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
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.
General Principles in Assigning Responsibilities Responsibilities Responsibility-Driven Design CRC Cards GRASP.
OO Methodology Elaboration Phase Iteration 1- Part 2.
TK2023 Object-Oriented Software Engineering CHAPTER 13d GRASP Patterns: High Cohesion.
TK2023 Object-Oriented Software Engineering
Object Design Examples with GRASP
GRASP – Designing Objects with Responsibilities
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
Object Oriented System Design Responsibilities
Presentation transcript:

NJIT 1 GRASP: Designing Objects with Responsibilities Chapter 17 Applying UML and Patterns Craig Larman

2 GRASP : Designing Objects With Responsibilities GRASP patterns are a learning aid to help one understand essential object design, and apply design reasoning in a methodical, rational,explainable way.

3 Do we learn UML or RUP? The critical design tool for software development is a mind well educated in design principles. It is not the Unified Modeling Language, the Rational Unified Process, or any methodology.

4 Text Case Study (POS) What has been done so far? A two Day Requirements Workshop Agree to implement and test certain particular scenarios in the first three-week timeboxed iteration. These other artifacts have been started: Supplementary Specification, Glossary, and Domain Model.

5 POS continued Three out of twenty Use Cases (with high business value) have been analyzed in detail. Package Diagrams have detailed the large-scale architecture. Use case text has been expanded to support the software objects (use case realization.)

6 POS continued Supplementary Specification define non- functional goals. System Sequence Diagrams identify system operation messages, the starting messages on interaction diagrams. Glossary clarifies details of parameters and data.

7 POS continued Operation Contracts may complement use cases to clarify the behavior of system objects. Domain Model suggests some names and attributes of software objects. Remember that in the Unified Process all of these elements are optional. Select what is needed for the project!

8 What activities are design? As we switch from being analysts to designers, there are several different ways we can continue. Start developing, probably with test-first development (or) Start UML modeling for object design (or) Use another method, such as CRC cards.

9 Design activities During design and coding we apply various OO design principles, among them software design patterns such as the GRASP and GoF (Gang of Four) patterns. Our metaphor is Responsibility Driven Design (RDD), because our chief design emphasis is on assigning responsibilities to objects.

10 Design Model Relationships Domain Model Use Case Model Interaction Diagrams Glossary Design Requirements Business Model Some object names and attributes Events and functional requirements Item details Supplementary Specification Domain rules Non-func reqs System Sequence Diagram

11 Responsibilities and Methods Responsibilities are realized as methods Approach to understanding and using design principles is based on patterns of assigning responsibilities. Definition of Responsibility: “A contract or obligation of a classifier” Responsibilities are of the following types: Knowing Doing

12 Doing responsibilities of an object include : Doing something itself, such as creating an object or doing a calculation Initialing action in other objects Controlling and coordinating activities in other objects Doing

13 Knowing responsibilities of object include : Knowing about private encapsulated data Knowing about related objects Knowing about things it can derive or calculate Knowing

14 Responsibilities and interaction diagrams Interaction diagrams show choices in assigning responsibilities to objects. When these diagrams are created, decisions in responsibility assignment are reflected in the messages sent to different classes of objects.

15 Patterns Principles and idioms codified in a structured format describing the problem, solution, and given a name are called patterns. A “New Pattern” is an oxymoron. Patterns are tried and true, established ways of doing things. They are not new things or new ways of doing things.

16 Definition of Pattern Pattern is a named problem/solution pair that can be applied in new contexts,with advice on how to apply it in novel situations and discussion of its trade-offs.

17 All Patterns have suggestive names. Naming a pattern, technique, or a principle has the following advantages : It supports chunking and incorporating that concept into our understanding and memory It facilitates communication. Naming Patterns

18 Changing Emphasis Throughout analysis, we have referred to analyzing the problem domain, and postponing consideration of the solution domain. We emphasized domain objects over software objects. That changes in design. We are now concerned with software objects and the solution domain.

19 GRASP The GRASP name was chosen to suggest the importance of grasping these principles to successfully design object-oriented software. It is an acronym for General Responsibility Assignment Software Patterns. They describe the fundamental principles of object design and responsibility assignment, expressed as patterns.

20 Five GRASP patterns : Information Expert Creator High Cohesion Low Coupling Controller

21 UML Class diagram notation Three sections: Class Name attributes methods Third section is for methods

22 Creator Problem: Who should be responsible for creating a new instance of some class ? The creation of objects is one of the most common activities in an object-oriented system. Consequently, it is useful to have a general principle for assignment of creation responsibilities. Assigned well, the design can support low coupling increased clarity, encapsulation, and reusability.

23 Solution Assign class B the responsibility to create an instance of class A if one or more of the following is true : B aggregates A objects. B contains A objects. B records instances of A objects. B closely uses A objects. B has the initializing data that will be passed to A when it is created B is a creator of A objects.

24 Discussion Creator guides assigning responsibilities related to creation of objects, a very common task. The basic intent of the Creator pattern is to find a creator that needs to be connected to the created object in any event. Aggregator aggregates Part Container contains Content Recorder records. Sometimes a creator is found by looking for the class that has the initializing data that will be passed in during creation.

25 Contraindications Often creation requires significant complexity, such as: using recycled instances for performance reasons, conditionally creating an instance from one of a family of similar classes based upon some external property value In these instances, another pattern principle might be preferred.

26 Monopoly Example Larman suggests in his example of a Monopoly Game, that since the game board contains the squares where activities take place, a Board software object is a logical place to create Square software objects.

27 Information Expert By Information expert we should look for the class of objects that has the information needed to determine the total. Problem : What is a general principle of assigning responsibilities to objects? Solution: Assign a responsibility to the information expert – a class that has the information necessary to fulfill the responsibility.

28 Discussion Information Expert is a basic guiding principle used continuously in object design. Expert is not meant to be obscure or fancy idea; it expresses the common “intuition” that objects do things related to information they have. Fulfillment of a responsibility often requires information that is spread across different classes of objects. Whenever information is spread across different objects, they will need to interact via messages to share the work.

29 Contraindications There are situations where the solution suggested by expert is undesirable, usually because of problems in coupling and cohesion. Keep the application logic in one place, database in another place and so forth, rather than intermingling different system concerns in the same component.

30 Information encapsulation is maintained, since objects use their own information to fulfill tasks.This usually supports low coupling, which leads to more robust and maintainable systems. Behavior is distributed across the classes that have the required information, encouraging more cohesive “lightweight” class definitions that are easier to understand and maintain. High cohesion is usually supported. Benefits

31 Monopoly Example If you want to retrieve information about the squares on the board, you should assign that responsibility to a software object that knows how to access those squares. In this case, the Board software object is also a good choice, as it was for creating the Square objects. Note that the information is retrieved from the Squares.

32 Low Coupling Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other element.

33 Problem: How to support a low dependency,low change impact,and increased reuse? Solution: Assign a responsibility so that coupling remains low. Low Coupling Pattern

34 Discussion Low Coupling is a principle to keep in mind during all design decisions; it is an underlying goal to continually consider. It is evaluative principle that a designer applies while evaluating all design decisions.

35 Contraindications & Benefits (High coupling to stable elements and to pervasive elements is seldom a problem.) Benefits: Objects are not affected by changes in other components Objects are simple to understand in isolation Objects are convenient to reuse

36 Monopoly Example If we created an arbitrary other class to retrieve information from the Squares instead of assigning the responsibility to the Board object, then our other class would have to retrieve information from both Board and Square, increasing the number of connections (and thus the coupling.)

37 Connections between Patterns You should note that in the example given, Information Expert supports Low Coupling. This is a natural result of identifying patterns from practices that have developed over years of experience. You often get the same result by starting with a different idea, because the ideas (patterns) support each other.

38 Controller A Controller is a non–user interface object responsible for receiving or handling a system event. It defines methods for system operation.

39 Problem : Who should be responsible for handling an input system event? Note that this assumes the Model-View- Controller architectural (not software) pattern that separates the user interface (Views) from the functionality of the rest of the system and uses controllers to access other functionality (Models).

40 Solution Assign the responsibility for receiving or handling a system event message to a class representing one of the following choices: Represent the overall system, device, or subsystem Represents a use case scenario within which the system event occurs

41 Discussion Controller pattern provides guidance for generally accepted, suitable choices. It is often desirable to use the same controller class for all the system events of one use case so that it is possible to maintain information about the state of the use case in the controller.

42 Monopoly Example The first system message is “Play Game.” What object should receive this message? The author suggests that :MonopolyGame might be a suitable object if there are a limited number of system operations. Otherwise, we would have to consider High Cohesion if there are many operations.

43 Facade Controller 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 message processing system.

44 Use–Case controller When placing the responsibilities in a façade controller leads to design with low cohesion or high coupling, Use Case Controller is preferred as an alternative. When there are many system events across different processes;it factors their handling into manageable separate classes.

45 High Cohesion Cohesion is a measure of how strongly related and focused are the responsibilities of an element. High Cohesion: An element with highly related responsibilities, and which does not do a tremendous amount of work, has high cohesion.

46 Problem: How can complexity be kept manageable? Solution: Assign responsibility so that cohesion remains high. High Cohesion Pattern

47 Discussion Like Low Coupling, High Cohesion is a principle to keep in mind during all design decisions; it is an underlying goal to consider contantly.

48 Monopoly Example Assuming, from the previous Monopoly slide, that :MonopolyGame is the controller: If :MonopolyGame performs most of the game functions within the software object, you have low cohesion. If the functions are delegated to other software objects, you have high cohesion.

49 Back to relationships Low Coupling and High Cohesion go together naturally. One usually leads to the other. Both are outcomes of the OO principle of “chunking,” breaking up a large problem into manageable pieces. If the pieces are too simple there will be too many of them. If the pieces are too complex, each will not be understandable.

50 Some scenarios illustrating varying degrees of varying degrees of functional cohesion: Very Low Cohesion – A class is solely responsible for many different functional areas. Low Cohesion – A class has sole responsibility for a complex task in one functional area. Cohesion examples

51 Moderate Cohesion – A class has light weight and sole responsibilities in a few different areas that are logically related to the class concept, but not to each other. High Cohesion – A class has moderate responsibilities in one functional area and collaborates with other classes to fulfill tasks.

52 Contraindications Grouping of responsibilities or code into one class or component to simplify maintenance by one person. (Such grouping may also make maintenance much more difficult.) Distributed server objects. It is sometimes desirable to create fewer and larger, less cohesive server objects that provide an interface for many operations, due to overhead and performance needs associated with remote objects and remote communication.

53 Benefits Clarity and ease of comprehension of design is increased. Maintenance and enhancements are simplified Low coupling is often supported.

54 Important This lecture has not gone over Larman’s examples in the text of using the GRASP patterns for the POS case study. You need to read that material and understand it thoroughly if you hope to become proficient in applying patterns. It will also take years of using the patterns to become expert with them.

55 An object classification schema The following analysis class types are used by Ivar Jacobsen in Objectory: Boundary objects are abstractions of interfaces Entity objects are application-independent domain software objects Control objects are use case handlers Jacobsen was a contributor to UML, and the controller pattern reflects his approach.

56 Benefits Increased potential for reuse,and pluggable interfaces. Provides information about the state of a use case.

57 Object Design and CRC Cards Another tool used to help assign responsibilities are CRC cards. CRC stands for Class-Responsibility- Collaborator They are index cards, one of each class,upon which the responsibilities of the class are briefly written,and a list of collaborator objects to fulfill these responsibilities.

58 Summary The skillful assignment of responsibilities is extremely important in object design. Determining the assignment of responsibilities often occurs during the creation of interaction diagrams, and certainly during programming. Patterns are named problem/solution pairs that codify good advice and principles often related to assignment of responsibilities.