60-322 Object-Oriented Analysis and Design

1. 60-322 Object-Oriented Analysis and Design Week 12, 2009

2. Ch 20 Mapping Designs to Code • With the completion of interaction diagrams and DCDs for the current iteration of the case studies, there's more than enough thought and detail to cut some code for the domain layer of objects. • The UML artifacts created during the design work - the interaction diagrams and DCDs - will be used as input to the code generation process. • In UP terms, there exists an Implementation Model. • This is all the implementation artifacts, such as the source code, database definitions, JSP/XML/HTML pages, and so forth. Thus, the code being created in this chapter can be considered part of the UP Implementation Model.

3. DCDs depict the class or interface name, superclasses, operation signatures, and attributes of a class. • This is sufficient to create a basic class definition in an OO language. • If the DCD was drawn in a UML tool, it can generate the basic class definition from the diagrams. Creating Classes from DCDs

4. Creating Classes from DCDs

5. The sequence of the messages in an interaction diagram translates to a series of statements in the method definitions. • The enterItem interaction diagram illustrates the Java definition of the enterItem method. • For this example, we will explore the implementation of the Register and its enterItem method. • A Java definition of the Register class is shown below. Creating Methods from Interaction Diagrams

6. Creating Methods from Interaction Diagrams

7. Creating Methods from Interaction Diagrams

8. Creating Methods from Interaction Diagrams

9. Order of Implementation Classes need to be implemented (and ideally, fully unit tested) from least-coupled to most-coupled.

10. As demonstrated, there is a translation process • from UML class diagrams to class definitions, and • from interaction diagrams to method bodies. • There is still lots of room for creativity, evolution, and exploration during programming work. • The code example for the NextGen POS case study… • The main point of this listing is to show that there is a translation from design artifacts to a foundation of code. • This code defines a simple case; it is not meant to illustrate a robust, fully developed Java program with synchronization, exception handling, and so on. Summary

11. Order of Implementation

13. Order of Implementation

15. Order of Implementation

17. Order of Implementation

19. Order of Implementation

21. Order of Implementation

23. Order of Implementation

25. Done Ch. 20 • Study Ch 21, and 22 yourself.

26. Part 4 Elaboration Iteration 2 – More Patterns Chapter 23. • Objectives • Define the requirements for iteration-2. • Do you remember What we have done before Part 4? ……

27. Ch 23. Iteration 2 – More Patterns • Remember we are discussing elaboration phase • Iteration 2 of Elaboration. • In this iteration, the case study just emphasizes: • essential object design • the use of patterns to create a solid design • applying the UML to visualize the models • Tell me (yourself) something that should happen in iteration 2.

28. Ch 23. Iteration 2 – More Patterns • Case study strategy: • Iterative development+ Iterative learning.

29. Ch 23. Iteration 2 – More Patterns • This book is organized to show an iterative development strategy. • OOA/D is applied to the case studies in multiple iterations; the first iteration is for some core functions. Later iterations expand the functionality • In conjunction with iterative development, the presentation of analysis and design topics, UML notation, and patterns is introduced iteratively and incrementally. • In the first iteration, a core set of analysis and design topics and notation is presented. The second iteration expands into new ideas, UML notation, and patterns. And likewise in the third iteration.

30. Ch 23. Iteration 2 – More Patterns • Based on this iterative learning strategy, there is minimal discussion of requirements analysis or domain modeling, and the explanation of the design is more succinct, now that (in iteration-1) a detailed explanation of the basics of how to think in objects has been presented. • Many other analysis, design, and implementation activities would of course occur in this iteration, but these are de-emphasized in favor of sharing information about how to do object design.

31. From Iteration 1 to Iteration 2 • When iteration-1 ends, the following should be accomplished: • All the software has been vigorously tested: unit, acceptance, load, usability, and so on. • The idea in the UP is to do early, realistic, and continuous verification of quality and correctness, so that early feedback guides the developers to adapt and improve the system, finding its "true path." • Customers have been regularly engaged in evaluating the partial system, • to obtain feedback for adaptation and clarification of requirements. And the customers get to see early visible progress with the system. • The system, across all subsystems, has been completely integrated and stabilized as a baselined internal release.

32. This part 4 focus on object design with more patterns. • Many activities concluding iteration-1 and initiating iteration-2 are skipped, since the emphasis of this presentation is an introduction to OOA/D. • Skipped activities that are skipped include: • An iteration planning meeting to decide what to work on in the next iteration, resolve questions, and identify major tasks. From Iteration 1 to Iteration 2

33. At the start of the new iteration, use a UML tool to reverse engineer diagrams from the source code of the last iteration (the results are part of the UP Design Model) , as a communication aid to illustrate the starting point of the logical design for the next iteration. • Usability analysis and engineering for the UI is underway. • This is an extraordinarily important skill and activity for the success of many systems. However, the subject is detailed and non-trivial, and outside the scope of this book. • Database modeling and implementation is underway. From Iteration 1 to Iteration 2

34. From Iteration 1 to Iteration 2 • Another two-day (for example) requirements workshop occurs, in which more use cases are written in their fully dressed format. • During elaboration, while perhaps 10% of the most risky requirements are being designed and implemented, there is a parallel activity to deeply explore and define perhaps 80% of the use cases for the system, even though most of these requirements won't be implemented until later iterations. • There's nothing like building software to discover what we really don't know about the requirements - this is a key idea in the UP and iterative, evolutionary methods.

35. Iteration 2 Requirements and Emphasis • For these case studies, iteration-2 largely ignores requirements analysis and domain analysis, and focuses on object design with responsibilities and GRASP, and applying some GoF design patterns. NextGen POS • Iteration-2 of the NextGen POS application handles several interesting requirements:

36. 1. Support for variations in third-party external services. • For example, different tax calculators must be connectable to the system, and each has a unique interface. Likewise with different accounting systems and so forth. Each will offer a different API and protocol for a core of common functions. 2. Complex pricing rules. 3. A design to refresh a GUI window when the sale total changes. • These requirements will only be considered (for this iteration) in the context of scenarios of the Process Sale use case. • These are not newly discovered requirements; they were identified during inception. (see use case, supplementary spec. ) Iteration 2 Requirements and Emphasis

37. Because of these requirements, we are revisiting the Process Sale use case in iteration-2, but implementing more scenarios, so that the system incrementally grows. • It is common to work on varying scenarios or features of the same use case over several iterations and gradually extend the system to ultimately handle all the functionality required. • On the other hand, short, simple use cases may be completely implemented within one iteration. Iteration 2 Requirements and Emphasis

38. This chapter briefly points out some changes in the requirements and domain analysis. • NEXTGEN POS • use cases • No refinement is needed for the use cases this iteration. • SSDs • This iteration includes adding support for third-party external systems with varying interfaces, such as a tax calculator. • The NextGen POS system will be remotely communicating with external systems. • Consequently, the SSDs should be updated to reflect at least some of the inter-system collaborations, in order to clarify what the new system-level events are. Ch 24. Quick Analysis Update

39. Process Sale Pay by Credit Scenario «actor» «actor» «actor» : NextGenPOS : CreditAuthorization : Accounts : TaxCalculator System Service : Cashier makeNewSale enterItem ( itemID , quantity ) description , total endSale taxLineItems = getTaxes ( sale ) total with taxes makeCreditPayment ( credNum , expiryDate ) reply = requestApproval ( request ) postReceivable ( receivable ) postSale ( sale ) Ch 24. Quick Analysis Update

40. This chapter briefly points out some changes in the requirements and domain analysis. • NEXTGEN POS • use cases • SSDs • Domain Model • A set of new requirements may have a minor or major impact on the Domain Model in terms of many new concepts, associations, and attributes. • The requirements being tackled this time do not involve many new domain concepts. • A brief survey of the new requirements suggests something like PriceRule as a domain concept, but there are probably not dozens of new things. Ch 24. Quick Analysis Update

41. Domain Model • Note that the discovery of new domain concepts occur during object design in the Design Model, when the developers are thinking through a solution, or indeed even while coding. Ch 24. Quick Analysis Update

42. Ch 25. Grasps: More Objects With Responsibities • Previously, we applied five GRASP patterns: • Information Expert, Creator, High Cohesion, Low Coupling, and Controller • The final four GRASP patterns are covered in this chapter. They are: • Polymorphism • Indirection • Pure Fabrication • Protected Variations

43. Polymorphism Problem • How to handle alternatives based on type? How to create pluggable software components? • Alternatives based on type • Conditional variation is a fundamental theme in programs. If a program is designed using if-then-else or case statement conditional logic, then if a new variation arises, it requires modification of the case logic - often in many places. This approach makes it difficult to easily extend a program with new variations because changes tend to be required in several places - wherever the conditional logic exists.

44. Polymorphism pluggable software components • Viewing components in client-server relationships, how can you replace one server component with another, without affecting the client? Solution • When related alternatives or behaviors vary by type (class), assign responsibility for the behavior -using polymorphic operations - to the types for which the behavior varies.

45. Example NextGen Problem: How Support Third-Party Tax Calculators? • In the NextGen POS application, there are multiple external third-party tax calculators that must be supported (such as Tax-Master and Good-As-Gold TaxPro). • The system needs to be able to integrate with different ones. • Each tax calculator has a different interface, so there is similar but varying behavior to adapt to each of these external fixed interfaces or APIs. Polymorphism

46. Polymorphism What objects should be responsible for handling these varying external tax calculator interfaces? Since the behavior of calculator adaptation varies by the type of calculator, by Polymorphism we should assign the responsibility for adaptation to different calculator (or calculator adapter) objects themselves, implemented with a polymorphic getTaxes operation.`

47. «interface» ITaxCalculatorAdapter getTaxes ( Sale ) : List < TaxLineItems > <???> Adapter TaxMasterAdapter GoodAsGoldTaxPro Adapter ... ... getTaxes ( Sale ) : List < TaxLineItems > getTaxes ( Sale ) : List < TaxLineItems > By Polymorphism , multiple tax calculator adapters have their own similar , but varying behavior for adapting to different external tax calculators . Polymorphism

48. Polymorphism • These calculator adapter objects are not the external calculators, but rather, local software objects that represent the external calculators, or the adapter for the calculator. • By sending a message to the local object, a call will ultimately be made on the external calculator in its native API. • Each getTaxes method takes the Sale object as a parameter, so that the calculator can analyze the sale. • The implementation of each getTaxes method will be different: TaxMasterAdapter will adapt the request to the API of Tax-Master, and so on.

49. Polymorphism Discussion • Polymorphism is a fundamental principle in designing how a system is organized to handle similar variations. • A design based on assigning responsibilities by Polymorphism can be easily extended to handle new variations. • For example, adding a new calculator adapter class with its own polymorphic getTaxes method will have minor impact on the existing design. • Guideline: When to Design with Interfaces?