軟件需求分析英文課件：Chap 9-Iteration 2--More GRASP

1、Elaboration Iteration 2- More PatternspCh24. Iteration 2More PatternspCh23. Quick Analysis Update pCh25. GRASP: More Objects with Responsibilities1Chapter 24. Iteration 2-More Patternso Objectiveso Define the requirements for iteration-2.2Introductiono Object Design and Patterns o In this iteration,

2、 the case study just emphasizes nessential object design nuse of patterns to create a solid design nApplying the UML to visualize the models o The discussion of requirements and domain modeling will be minimal o The explanation of the design will be succinct 3From Iteration 1 to 2o Achievements at t

3、he end of iteration 1 nAll the software has been vigorously tested; unit, acceptance, usability, nCustomers have been regularly engaged in evaluating the partial system, to obtain feedback for adaptation and clarification of requirements nThe system, across all subsystems, has been completely integr

4、ated and stabilized as a baselined internal release4Iteration 2 Requirements & Emphasiso NextGen POS nSupport for variations in third-party external services. oDifferent tax calculators oDifferent accounting systemsnComplex pricing rules nA design to refresh a GUI when the sale total changes 5o

5、Monopoly nImplement a basic, key scenario of the Play Monopoly Game moving around the squares of the board nSome of the special square rules apply oEach player receives $1500 at the beginning of the gameoGo square oGo-To-Jail square oIncome-Tax square 6Chapter 24. Quick Analysis Updateo Objectiveso

6、Quickly highlight some analysis artifact changes, especially in the Monopoly domain model7Case Study: NextGen POS -SSD89Case Study: Monopoly-Domain ModelChapter 25. GRASP: More Objects with Responsibilitieso The five GRASP patterns explored nCreator nInformation Expert nLow Coupling nController nHig

7、h Cohesion o Learn to apply the remaining GRASP patternsnPolymorphism nIndirection nPure Fabrication nProtected Variations10Polymorphism oName: Polymorphism oProblem: nHow to handle alternatives based on type? How to create pluggable software components? oSolution: nWhen alternate behaviours are sel

8、ected based on the type of an object, use polymorphic method call to select the behaviour, rather than using if statement to test the type.oassign responsibility to the types for which the behaviors vary.oExamples: nIn the NextGen POS application, there are multiple external third-party tax calculat

9、ors that must be supported; the system needs to be able to integrate with different ones nWhat objects should be responsible for handling these varying external tax calculator interfaces?11NextGen Problem: Example 1How Support Third-Party Tax Calculators?1213NextGen Problem: Example2CreditPaymentaut

10、horize() CheckPaymentauthorize() By Polymorphism, each payment should authorize itselfCashPaymentauthorize()PaymentamountoWho should be responsible for authorising different kinds of payments?authorize()Monopoly Problem: Example 3How to Design for Different Square Actions?14Applying Polymorphism to

11、the Monopoly problem15Applying Polymorphism16The GoSquare case17The RegularSquare case18The IncomeTaxSquare case19The GoToJailSquare case20Improving the Coupling21Iteration-2: Improved DCD22Iteration-2: Improved Interaction Diagram23DiscussionoPolymorphism is a fundamental principles in designing ho

12、w a system is organized to handle similar variations. oA design based on assigning responsibilities by Polymorphism can be easily extended to handle new variations. oContradications nSometimes, developers design systems with interfaces and polymorphism for speculative future-proofing against an unkn

13、own possible variation. oBenefits nExtensions required for new variations are easy to add nNew implementations can be introduced without affecting clients2425Pure FabricationoProblem:What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other

14、goals, but solutions offered by Expert (for example) are not appropriate?oSolution: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:nHigh cohesion is su

15、pported because responsibilities are factored into a class that only focuses on a very specific set of related tasks.nReuse potential may be increased because of the presence of fine grained Pure Fabrication classes.26Example :oSuppose, in the POS example, that support is needed to save Sale instanc

16、es in a relational database. By Expert, there is some justification to assign this responsibility to Sale class. However.nThe task requires a relatively large number of supporting database-oriented operations and the Sale class becomes incohesive.nThe sale class has to be coupled to the relational d

17、atabase increasing its coupling.nSaving objects in a relational database is a very general 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 Fabric

18、ation : Example 1PersistentStoragesave()By Pure FabricationoThe Sale remains well design, with high cohesion and low couplingoThe PersistentStorage class is itself relatively cohesiveoThe PersistentStorage class is a very generic and reusable objectPure Fabrication:Example 2 o Monopoly Problem: Hand

19、ling the Dice282930Pure Fabricationo Preserves low coupling and high cohesion of classeso Improve reusability of classesNote: All the GoF patterns involve fabricating new classes-e.g. observer, adapter, abstract factory, etc.31IndirectionoProblem:Where to assign a responsibility, to avoid direct cou

20、pling between two (or more) things? How to de-couple objects so that low coupling is supported and reuse potential remains higher?oSolution:Assign the responsibility to an intermediate object to mediate between other components or services, so that they are not directly coupled. 32Example1 : Persist

21、entStorageoThe Pure fabrication example of de-coupling the Sale from the relational database services through the introduction of a PersistentStorage is also an example of assigning responsibilities to support Indirection. oThe PersistentStorage acts as a intermediary between the Sale and databaseEx

22、ample2: TaxCalculatorAdapter33Indirection : Example3oConsider a CreditAuthorizationService class that needs to use a ModemnBad approach: Put low-level calls to the Modem API directly in the methods of the CreditAuthorizationClassnBetter approach: Add an intermediate Modem class that insulates Credit

23、AuthorizationClass from the Modem API3435Indirection : Example3Modemdial( )receive( )send( )By IndirectionModem:dial(phoneNum):OS_OpenPort(1);:OS_Dial(phoneNUM)CreditAuthorizationServiceModem1:dial(phoneNum)authorize(payment)36Indirectiono Low couplingo Promotes reusabilityProtected VariationoProble

24、m: How do we design objects and systems so that instability in them does not have undesirable effects on other elements?oInstability here doesnt mean “crashy”. It means prone to change or evolve.oSolution: Identify points of predicted instability (variation) and assign responsibilities to create a s

25、table interface around them37Key ConceptExample: ITaxCalculatorAdapter oInstability or variation ndifferent interfaces or APIs of external tax calculators.nintegrate with many existing tax calculator systems, and also with future third-party calculators not yet in existence.oBy adding a level of ind

26、irection, an interface, and using polymorphism with various ITaxCalculatorAdapter implementations, protection within the system from variations in external APIs is achieved. nInternal objects collaborate with a stable interface; the various adapter implementations hide the variations to the external

27、 systems.38Protected Variation is Pervasive in ComputingoVirtual machines and operating systemsoData-driven designs (e.g., configuration files)oLiskov Substitution PrincipleoLSP Liskov88 formalizes the principle of protection against variations in different implementations of an interface, or subcla

28、ss extensions of a superclass.nTo quote:nIf 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 o2 then S is a subtype of T Liskov88.npublic void getTaxes( ITaxCalculatorAdapter cal

29、culator, Sale sale ) List taxLineItems = calculator.getTaxes( sale ); / . 3940Law of Demeter“Dont Talk to Strangers”oProblem:To avoid knowing about the structure of indirect objects?oSolution:If two classes have no other reason to be directly aware of each other or otherwise coupled, then the two cl

30、asses should not directly interact.Special Case of PV41Law of DemeterIt states that within a method, messages should only be sent to the following objects:nThe this object (or self)nA parameter of the methodnAn attribute of selfnAn element of a collection which is an attribute of selfnAn object crea

31、ted within the methodBetter: Dont talk to strangers who seem unstableThis guideline warns against code like:osale.getPayment().getAccount().getAccountHolder()42Law of Demeter : ExampleRegisterpaymentAmount () : FloatendSale ()enteritem ()makePayment ()11Saledate : DateisComplete : Booleantime : Time

32、becomeComplete ()makeLineitem ()makepayment ()payment () : Paymenttotal () : Float11PaymentamountTenderedamountTendered () : Float11 11CapturesPaid-by43Violates Law of Demeter : Example:Sale1:prnt:=payment() : payment:Registerprnt:Payment1.1:amt:=amountTendered():Floatamt:=paymentAmount():Float Regi

33、ster :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

34、egister : PaymentAmount()return m_sale - PaymentAmount();Saledate : DateisComplete : Booleantime : TimebecomeComplete( )makeLineitem( )makePayment( )payment( )paymentAmount( )total( )45Law of Demetero a mechanism to achieve protection from structure changeso Keeps coupling between classes low and makes a design more robusto Adds a small amount of overhead in the form of indirect method callsNotes on Protected Variationso Benefits (if we guessed variation points correctly):nExtensions easy to add and plug in new implementationsnLower couplin