软件需求分析英文课件：Chap 9-Iteration 2--More GRASP

1、Elaboration Iteration 2- More PatternsCh24. Iteration 2More PatternsCh23. Quick Analysis Update Ch25. GRASP: More Objects with Responsibilities1Chapter 24. Iteration 2-More PatternsObjectivesDefine the requirements for iteration-2.2IntroductionObject Design and Patterns In this iteration, the case s

2、tudy just emphasizes essential object design use of patterns to create a solid design Applying the UML to visualize the models The discussion of requirements and domain modeling will be minimal The explanation of the design will be succinct 3From Iteration 1 to 2Achievements at the end of iteration

3、1 All the software has been vigorously tested; unit, acceptance, usability, Customers have been regularly engaged in evaluating the partial system, to obtain feedback for adaptation and clarification of requirements The system, across all subsystems, has been completely integrated and stabilized as

4、a baselined internal release4Iteration 2 Requirements & EmphasisNextGen POS Support for variations in third-party external services. Different tax calculators Different accounting systemsComplex pricing rules A design to refresh a GUI when the sale total changes 5Monopoly Implement a basic, key scen

5、ario of the Play Monopoly Game moving around the squares of the board Some of the special square rules apply Each player receives $1500 at the beginning of the gameGo square Go-To-Jail square Income-Tax square 6Chapter 24. Quick Analysis UpdateObjectivesQuickly highlight some analysis artifact chang

6、es, especially in the Monopoly domain model7Case Study: NextGen POS -SSD89Case Study: Monopoly-Domain ModelChapter 25. GRASP: More Objects with ResponsibilitiesThe five GRASP patterns explored Creator Information Expert Low Coupling Controller High Cohesion Learn to apply the remaining GRASP pattern

7、sPolymorphism Indirection Pure Fabrication Protected Variations10Polymorphism Name: Polymorphism Problem: How to handle alternatives based on type? How to create pluggable software components? Solution: When alternate behaviours are selected based on the type of an object, use polymorphic method cal

8、l to select the behaviour, rather than using if statement to test the type.assign responsibility to the types for which the behaviors vary.Examples: In the NextGen POS application, there are multiple external third-party tax calculators that must be supported; the system needs to be able to integrat

9、e with different ones What objects should be responsible for handling these varying external tax calculator interfaces?11NextGen Problem: Example 1How Support Third-Party Tax Calculators?1213NextGen Problem: Example2CreditPaymentauthorize() CheckPaymentauthorize() By Polymorphism, each payment shoul

10、d authorize itselfCashPaymentauthorize()PaymentamountWho should be responsible for authorising different kinds of payments?authorize()Monopoly Problem: Example 3How to Design for Different Square Actions?14Applying Polymorphism to the Monopoly problem15Applying Polymorphism16The GoSquare case17The R

11、egularSquare case18The IncomeTaxSquare case19The GoToJailSquare case20Improving the Coupling21Iteration-2: Improved DCD22Iteration-2: Improved Interaction Diagram23DiscussionPolymorphism is a fundamental principles in designing how a system is organized to handle similar variations. A design based o

12、n assigning responsibilities by Polymorphism can be easily extended to handle new variations. Contradications Sometimes, developers design systems with interfaces and polymorphism for speculative future-proofing against an unknown possible variation. Benefits Extensions required for new variations a

13、re easy to add New implementations can be introduced without affecting clients2425Pure FabricationProblem:What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Expert (for example) are not appropriate?Solu

14、tion:Assign a highly cohesive set of responsibilities to an artificial class that does not represent anything in the problem domain, in order to support high cohesion, low coupling, and reuse. Benefits:High cohesion is supported because responsibilities are factored into a class that only focuses on

15、 a very specific set of related tasks.Reuse potential may be increased because of the presence of fine grained Pure Fabrication classes.26Example :Suppose, in the POS example, that support is needed to save Sale instances in a relational database. By Expert, there is some justification to assign thi

16、s responsibility to Sale class. However.The task requires a relatively large number of supporting database-oriented operations and the Sale class becomes incohesive.The sale class has to be coupled to the relational database increasing its coupling.Saving objects in a relational database is a very g

17、eneral task for which many classes need support. Placing these responsibilities in the Sale class suggests there is going to be poor reuse or lots of duplication in other classes that do the same thing. 27Pure Fabrication : Example 1PersistentStoragesave()By Pure FabricationThe Sale remains well des

18、ign, with high cohesion and low couplingThe PersistentStorage class is itself relatively cohesiveThe PersistentStorage class is a very generic and reusable objectPure Fabrication:Example 2 Monopoly Problem: Handling the Dice282930Pure FabricationPreserves low coupling and high cohesion of classesImp

19、rove reusability of classesNote: All the GoF patterns involve fabricating new classes-e.g. observer, adapter, abstract factory, etc.31IndirectionProblem:Where to assign a responsibility, to avoid direct coupling between two (or more) things? How to de-couple objects so that low coupling is supported

20、 and reuse potential remains higher?Solution:Assign the responsibility to an intermediate object to mediate between other components or services, so that they are not directly coupled. 32Example1 : PersistentStorageThe Pure fabrication example of de-coupling the Sale from the relational database ser

21、vices through the introduction of a PersistentStorage is also an example of assigning responsibilities to support Indirection. The PersistentStorage acts as a intermediary between the Sale and databaseExample2: TaxCalculatorAdapter33Indirection : Example3Consider a CreditAuthorizationService class t

22、hat needs to use a ModemBad approach: Put low-level calls to the Modem API directly in the methods of the CreditAuthorizationClassBetter approach: Add an intermediate Modem class that insulates CreditAuthorizationClass from the Modem API3435Indirection : Example3CreditAuthorizationServiceModem1:dial

23、(phoneNum)authorize(payment)36IndirectionLow couplingPromotes reusabilityProtected VariationProblem: How do we design objects and systems so that instability in them does not have undesirable effects on other elements?Instability here doesnt mean “crashy”. It means prone to change or evolve.Solution

24、: Identify points of predicted instability (variation) and assign responsibilities to create a stable interface around them37Key ConceptExample: ITaxCalculatorAdapter Instability or variation different interfaces or APIs of external tax egrate with many existing tax calculator systems

25、, and also with future third-party calculators not yet in existence.By adding a level of indirection, an interface, and using polymorphism with various ITaxCalculatorAdapter implementations, protection within the system from variations in external APIs is achieved. Internal objects collaborate with

26、a stable interface; the various adapter implementations hide the variations to the external systems.38Protected Variation is Pervasive in ComputingVirtual machines and operating systemsData-driven designs (e.g., configuration files)Liskov Substitution PrincipleLSP Liskov88 formalizes the principle o

27、f protection against variations in different implementations of an interface, or subclass extensions of a superclass.To quote:If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for

28、o2 then S is a subtype of T Liskov88.public void getTaxes( ITaxCalculatorAdapter calculator, Sale sale ) List taxLineItems = calculator.getTaxes( sale ); / . 3940Law of Demeter“Dont Talk to Strangers”Problem:To avoid knowing about the structure of indirect objects?Solution:If two classes have no oth

29、er reason to be directly aware of each other or otherwise coupled, then the two classes should not directly interact.Special Case of PV41Law of DemeterIt states that within a method, messages should only be sent to the following objects:The this object (or self)A parameter of the methodAn attribute

30、of selfAn element of a collection which is an attribute of selfAn object created within the methodBetter: Dont talk to strangers who seem unstableThis guideline warns against code like:sale.getPayment().getAccount().getAccountHolder()42Law of Demeter : ExampleRegisterpaymentAmount () : FloatendSale

31、()enteritem ()makePayment ()11Saledate : DateisComplete : Booleantime : TimebecomeComplete ()makeLineitem ()makepayment ()payment () : Paymenttotal () : Float11PaymentamountTenderedamountTendered () : Float1111CapturesPaid-by43Violates Law of Demeter : Example:Sale1:prnt:=payment() : payment:Registe

32、rprnt:Payment1.1:amt:=amountTendered():Floatamt:=paymentAmount():Float Register :PaymentAmount()prnt:= m_sale-Payment()/Violates Law of DMreturn prnt-amountTendered();Violates Law of DMprnt is a Stranger to POST44Support Law of demeter1:prnt:=payment() : payment1.1:amt:=amountTendered():Floatamt:=paymentAmount():Float Supports the Law of Demeter: Registerprnt:Payment:SaleR