软件需求分析英文课件：Chap 7-GRASP

1、Elaboration Iteration 1- GRASPCh17. GRASP: Designing Objects with ResponsibilitiesCh18. Object Design Examples with GRASP1Chapter 17. GRASP: Designing Objects with ResponsibilitiesObjectivesLearn to apply five of the GRASP principles or patterns for OOD2Vague advice on OOD“After identifying your req

2、uirements and creating a domain model, then add methods to the software classes, and define the messaging between the objects to fulfill the requirements” Not really answer the following questions:What methods belong to where? How the objects should interact? GARSP as a Methodical Approach to Learni

3、ng Basic Object Design3UML versus Design PrinciplesUML is simply a standard visual modeling language, knowing its details doesnt teach you how to think in objects-thats a theme of this course.The critical design tool for software development is a mind well educated in design principles. It is not th

4、e UML or any other technology.4Object Design: Example Inputs, Activities, and OutputsWhat are the inputs to object design? Use case model Domain Model System Sequence Diagrams Operation Contracts Supplementary SpecificationGlossary5What Are Activities of Object Design?Dynamic and static modeling (dr

5、aw both interaction and complementary class diagrams) Applying various OO design principles GRASP GoF design patterns Responsibility-Driven Design (RDD)6What Are the Outputs?Modeling for the difficult parts of the design that we wished to explore before codingspecifically for object design, UML inte

6、raction, class, and package diagramsUI sketches and prototypesdatabase modelsreport sketches and prototypes78OOD-Input & OutputResponsibility-Driven DesignRDD Responsibility-Driven Design responsibilities, roles, and collaborations A general metaphor for thinking about OO software design-viewing an

7、OO analysis & design as a community of collaborating responsible objects.The UML defines a responsibility as a contract or obligation of a classifierIn RDD, Responsibilities are related to the obligations or behavior of an object in terms of its roleRDD also includes the idea of collaboration. Respo

8、nsibilities are implemented by means of methods that either act alone or collaborate with other methods and objects.9ResponsibilityResponsibilities are related to the obligation of an object in terms of its behavior Doing responsibilities of an object include:doing something itself, such as creating

9、 an object or doing a calculationinitiating action in other objects controlling and coordinating activities in other objects Knowing responsibilities of an object include:knowing about private encapsulated dataknowing about related objectsknowing about things it can derive or calculate For example a

10、 Sale is responsible for creating SalesLineItems (a doing) a Sale is responsible for knowing its total (a knowing)10Responsibilities and Interaction DiagramsInteraction diagrams show choices in assigning responsibilities to objects. When created, decisions in responsibility assignment are made, whic

11、h are reflected in what messages are sent to different classes of objects11Where are we now?The background for OOD The iterative process background Prior artifacts? How do they relate to OOD models? How much time should we spend design modeling? RDD as a metaphor for object design a community of col

12、laborating responsible objects Patterns as a way to name and explain OOD ideasGRASP for basic patterns of assigning responsibilities GoF for more advanced design idea. UML for OOD visual modeling during which time both GRASP and GoF patterns can be applied12GRASP: A Methodical Approach to Basic OO D

13、esignA 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.GRASP pattern: General Responsibilities Assignment Software Pattern They describe fundamental principles of object design and respon

14、sibility assignment, expressed as patterns.Understanding how to apply GRASP for object design is a key goal of the course.GRASP is a learning aid to structure and name the principles once you “grasp” the fundamentals, the specific GRASP terms (Information Expert, Creator, ) arent important13GRASPGen

15、eral Responsibilities Assignment Software Pattern Understanding and being able to apply the ideas behind GRASP forms the foundation for designing OO systems. There are nine GRASP patterns: Information Expert Creator Low Coupling Controller High Cohesion Polymorphism Pure Fabrication Indirection Prot

16、ected Variables14GRASP Patterns Information ExpertName: Information Expert (or Expert)Problem: What is a general principle of assigning responsibility to objects? Solution: Assign a responsibility to the class that has the information needed to fulfill it Example In the NextGen application, some cla

17、ss needs to know the grand total of a sale15Example ExpertWho should be responsible for knowing the grand total of a sale?Look in Design Model firstOtherwise, look in the Domain Model and create design class.16Partial Domain ModelExample ExpertWhat information do we need to determine the grand total

18、? We need to know about all the SalesLineItem instances of a sale and the sum of their subtotals. A Sale instance contains theseBy Expert, Sale is a suitable class of object for this responsibility.17Example ExpertWhat information do we need to determine the line item subtotal?SalesLineItem.quantity

19、 and ProductDescription.price. The SalesLineItem knows its quantity and its associated ProductDescriptionBy Expert, SalesLineItem should determine the subtotal18Example ExpertTo knowing its subtotal, a SalesLineItem has to know the product price.By expert, ProductDescription should answering its pri

20、ce.19Discussion Information Expert is frequently used in the assignment of responsibilities; it is a basic guiding principles used continuously in object design. The fulfillment of a responsibility often requires information spread across different classes of objects. Expert usually leads to designs

21、 where a software object does those operations that are normally done to the inanimate real-world thing it represents. The Information Expert pattern like many things in OO has a real-world analogy. Contraindications There are situations where a solution suggested by Expert is undesirable, usually b

22、ecause of problems in coupling and cohesion Ex. who should be responsible for saving a Sale in a database?20GRASP Patterns CreatorName: CreatorProblem: Who should be responsible for creating a new instances of some class? Solution: Assign class B the responsibility to create an instance of class A i

23、f one of these is true (the more the better) B “contains” or compositely aggregate 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 B is a creator of A objects If more than one option applies,

24、 usually prefer a class B which aggregates or contains class A21Example CreatorIn the NextGen POS application, who should be responsible for creating a SalesLineItem instance?22Partial Domain ModelExample CreatorSale is a good candidateSale contains (in fact, aggregates) many SalesLineItem objects23

25、Creating a SalesLineItemDiscussion Creator guides the assigning of responsibilities related to the 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. Choosing it as the creator supports

26、low coupling Contradictions If creation requires significant complexity, such as using recycled instances, conditionally creating an instance from one of a family of similar classes based upon some external property value, it is advisable to delegate creation to a helper class called Factory. Benefi

27、ts Low coupling is supported, which implies lower maintenance dependencies and higher opportunities for reuse. 24GRASP Patterns Low Coupling Name: Low Coupling Coupling is a measure of how strongly one element is connected to, has knowledge of, or relies on other elements.Problem: How to support low

28、 dependency, low change impact, and increased reuse? Solution: Assign a responsibility so that coupling remains low Example Assume need to create a Payment instance and associate it with the Sale, who should be responsible for this? 25Design 1: Register creates Payment26Design 2: Sale creates Paymen

29、tDiscussion Low Coupling is a principle to keep in mind during all design decisions; it is an underlying goal to continually consider. Although, in general, a low coupling is preferred, it shouldnt be taken to excess. Some moderate degree of coupling between classes is normal and necessary to create

30、 an OO system in which tasks are fulfilled by a collaboration between connected objects Contradictions High coupling to stable elements and to pervasive elements is seldom a problem. Ex. a Java application can safely couple itself to the Java libraries (java.util, and so on) because they are stable

31、and widespread Benefits not affected by changes in other components simple to understand in isolation convenient to reuse27GRASP Patterns Controller Name: Controller Problem: What first object beyond the UI layer receives and coordinates (“controls”) a system operation? Solution: Assign the responsi

32、bility to a class representing one of the following choices: Represents the overall “system”, a device, or a subsystem (faade controller) Represents a use case scenario ( use case controller） 28A Controller is a non-user interface object responsible for receiving or handling a system event. A contro

33、ller defines the method for the system operations 29Controller for enterItem30Controller choices31Allocations of system operations 32Discussion Systems receive externally input events, typically involving a GUI operated by a person. In all cases, some handler for these events must be chosen The Cont

34、roller pattern provides guidance for generally accepted, suitable choices. Normally, a controller should delegate to other objects the work that needs to be done; it coordinates or controls the activity. It doesnt do much work itself.33Benefits Increased potential for reuse and pluggable interfaces

35、Opportunity to reason about the state of the use case Implementation Implementation Java Swing: Rich Client UI Implementation with Java Struts: Client Browser and Web UI Issues and Solutions: Bloated Controllers Poorly designed, a controller will have low cohesion unfocused and handling too many are

36、as of responsibility Signs of bloating34Desirable Coupling of UI Layer to Domain Lyaer 35Less Desirable Coupling of UI Layer to Domain Lyaer 36GRASP Patterns High CohesionName: High Cohesion Problem: How to keep objects focused, understandable, and manageable, and as a side effect support of Low Cou

37、pling? Solution: Assign a responsibility so that cohesion remains high. Use this to evaluate alternatives37Example High Cohesion38Example High Cohesion39Discussion High Cohesion is a principle to keep in mind during all design decisions; it is an underlying goal to continually consider. A rule of th

38、umb, a class with high cohesion has 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 Some scenarios that illustrate varying degrees of functional cohesion: Very low cohesi

39、on a class is solely responsible for many things in very different functional areas (RDB-RPC-Interface)Low cohesion a class has sole responsibility for a complex task in one functional area (RDBInterface)High cohesion a class has moderate responsibilities in one functional area and collaborates with

40、 other classes to fulfill tasks (RDBExecutor,RDBException)40Chapter 18. Object Design Examples with GRASPObjectivesDesign use case realizations.Apply GRASP to assign responsibilities to classes.Apply UML to illustrate and think through the design of objects.41What is a Use Case Realization? A use-ca

41、se realization describes how a particular use case is realized within the Design Model, in terms of collaborating objects the design of one or more scenarios of a use case; each of these is called a use case realization(scenario realizaiton)Use case realization is a UP tem used to remind us the conn

42、ection between the requirements expressed as use cases and the object design that satisfies the requirements UML diagrams are a common language to illustrate use case realizations We can apply principles and patterns of object design, during this use case realization design work4243Artifact relation

43、ships, emphasizing use case realizationCommunication Diagrams and System Operation Handling44Sequence Diagram And System Operation Handling 45Operation Contracts and Use Case Realization Use case realizations could be designed directly from the use case text or from ones domain knowledge. For some m

44、ore complex system operations, contracts may have been written that add more analysis detail .46Partial Interaction Diagram Satisfies a Contract Postcondition47Use Case Realization for the NextGen IterationProcess Sale Happy Path, Cash Payment OnlymakeNewSaleenterItemendSalemakePaymentInitialization

45、 and the Start Up Use Case4849How to Design makeNewSale?Choosing the Controller Class Faade controller Register, POSSystem Use-case controller ProcessSalehandler, ProcessSaleSession50Applying the GRASP Controller Pattern51Creating a New Sale 52How to Design enterItem? Choosing the Controller Class :

46、 Register 53Display Item Description and Price Model-View Separation principle GUI design is not considered here Only the information for display needs to be known Finding a ProductDescription Who should be responsible for knowing a ProductDescription, based on an itemID match? Information Expert pa

47、ttern Taking inspiration from the domain: a software ProductCatalog will contain software ProductDescription, with a method of getProductDescriptoinCreating a New SalesLineItem Taking inspiration from the domain, a software Sale may similarly contain software SalesLineItemBy Creator, a software Sale

48、 is an appropriate candidate to create a SalesLineItem 54The enterItem Interaction Diagram 55The enterItem Design Class Diagram 56How to Design endSale?Choosing the Controller Class: Register 57Setting the Sale.isComplete Attribute Who should be responsible for setting the isComplete attribute of th

49、e Sale to true? By Expert, it should be the Sale itself. 58Calculating the Sale Total 59The Sale-getTotal Design 60Showing a Method in a Note Symbol61How to Design makePayment? 62Choosing the Controller Class: Register Creating a Payment Alternative design choices ( Register or Sale )good cohesion,

50、couplingstability in the presence of likely future changes 63Logging a SaleResponsibility: who is responsible for knowing all the logged sales, and doing the logging? 64Logging a complete sale 65Calculating the Balance Who is responsible for knowing the balance? Sale and Payment are partial Experts

51、on solving this problem 66A More Completed DCD Reflecting Most Design Decisions 67How to Connect the UI Layer to the Domain Layer? 68Interface and Domain Layer ResponsibilitiesThe UI layer should not have any domain logic responsibilities. It should only be responsible for user interface tasks, such as updating widgets The UI layer should forward requests for all domain-oriented tasks on to the domain layer, which is responsible for handling them 69Initialization and the Start UP Use CaseWhen to Create the sta