60 322 object oriented analysis and design
This presentation is the property of its rightful owner.
Sponsored Links
1 / 49

60-322 Object-Oriented Analysis and Design PowerPoint PPT Presentation


  • 40 Views
  • Uploaded on
  • Presentation posted in: General

60-322 Object-Oriented Analysis and Design. Week 12, 2009. 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.

Download Presentation

60-322 Object-Oriented Analysis and Design

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


60 322 object oriented analysis and design

60-322 Object-Oriented Analysis and Design

Week 12, 2009


Ch 20 mapping designs to code

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.


Creating classes from dcds

  • 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


Creating classes from dcds1

Creating Classes from DCDs


Creating methods from interaction diagrams

  • 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


Creating methods from interaction diagrams1

Creating Methods from Interaction Diagrams


Creating methods from interaction diagrams2

Creating Methods from Interaction Diagrams


Creating methods from interaction diagrams3

Creating Methods from Interaction Diagrams


Order of implementation

Order of Implementation

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


Summary

  • 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


Order of implementation1

Order of Implementation


Order of implementation2

Order of Implementation


Order of implementation3

Order of Implementation


Order of implementation4

Order of Implementation


Order of implementation5

Order of Implementation


Order of implementation6

Order of Implementation


Order of implementation7

Order of Implementation


60 322 object oriented analysis and design

  • Done Ch. 20

  • Study Ch 21, and 22 yourself.


Part 4 elaboration iteration 2 more patterns

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? ……


Ch 23 iteration 2 more patterns

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.


Ch 23 iteration 2 more patterns1

Ch 23. Iteration 2 – More Patterns

  • Case study strategy:

    • Iterative development+ Iterative learning.


Ch 23 iteration 2 more patterns2

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.


  • Ch 23 iteration 2 more patterns3

    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.


    From iteration 1 to iteration 2

    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.


    From iteration 1 to iteration 21

    • 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


    From iteration 1 to iteration 22

    • 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


    From iteration 1 to iteration 23

    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.


    Iteration 2 requirements and emphasis

    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:


    Iteration 2 requirements and emphasis1

    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


    Iteration 2 requirements and emphasis2

    • 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


    Ch 24 quick analysis update

    • 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


    Ch 24 quick analysis update1

    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


    Ch 24 quick analysis update2

    • 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


    Ch 24 quick analysis update3

    • 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


    Ch 25 grasps more objects with responsibities

    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


    Polymorphism

    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.


    Polymorphism1

    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.


  • Polymorphism2

    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


    Polymorphism3

    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.`


    Polymorphism4

    «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


    Polymorphism5

    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.


    Polymorphism6

    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?


  • Login