elaboration l.
Skip this Video
Loading SlideShow in 5 Seconds..
Elaboration PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 22

Elaboration - PowerPoint PPT Presentation

  • Uploaded on

Elaboration. Lecture OO09 Gymnastics System Example Cont’d. References. The Booch Method Guide, for Rose 2.0. Teaching Points. Validation Architectural Design Planning. Review. What are the products of architectural design? How would you validate you domain analysis?. Validation.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation


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
    1. Elaboration Lecture OO09 Gymnastics System Example Cont’d

    2. References • The Booch Method Guide, for Rose 2.0

    3. Teaching Points • Validation • Architectural Design • Planning

    4. Review • What are the products of architectural design? • How would you validate you domain analysis?

    5. Validation • Are we building the right product? • Use the requirement

    6. Gymnastics System Example • The “scoring” use case

    7. When to Stop Domain Analysis • You have identified all domain entities that play a role and defined their classes • You have specified the relationships between each of these classes

    8. When to Stop Domain Analysis • You have associated with each class all operations performed on it (from uses cases) • You have analyzed each operation to the point where you understand what it needs to do and what other classes are involved

    9. Packages are organized in a hierarchy of layers where each layer has a well-defined interface e.g. The OSI model for network services is a layered architecture Classic three-tier architecture Presentation (windows, reports, etc.) Application Logic (tasks and rules that govern the process) Storage (persistent storage mechanism) Layered Architecture

    10. Three-tier Architecture

    11. Identified by the separation of the application logic into a distinct middle layer Presentation layer is free of application logic and just forwards requests to middle tier Middle tier communicates with a back end storage layer Three-tier Architecture (cont’d)

    12. Advantages the opportunity for reuse the possibility of distributing application logic on a network allocation of developers to construct specific tier (based on interface specs, that is good OO decomposition) Three-tier Architecture (cont’d)

    13. The logical extension of three-tier architecture You can decompose a three-tier into multiple services Multi-tiered Architectures

    14. Multi-tiered Architectures

    15. The Gymnastics System

    16. What if we change user interfaces? What if we change DBMS? (how can we make the architecture less vulnerable to change) The Gymnastics System

    17. The essence of a plan is to set up a series of iterations (executable releases) for construction and to assign use cases to iterations A plan allocates each use case to an iteration (executable release) and identifies a start date for each iteration Planning

    18. Allocate Use Cases: By level of user priority By architectural Risk address risk early By level of effort uses cases with schedule risk early roughly equal releases you may split large use cases Executable Release Plan

    19. Classes to be implemented Inputs you may have to provide drivers Output you may have to provide stubs ASIDE: A good rule of thumb is that you will produce as much test harness as production code Other planning data

    20. Executable release: Scoring Report Goal: Verification and successful use of navigational paths and score derivation logic for the scores of a competition. Start Date: 26 Aug 98 Effort: 12 developer-weeks Classes to be implemented: Competition, Event, Trial, RawScore, Team Use Cases to be Implemented: Scoring Inputs: Dummy database (validated in advance) with a meet, a competition, all events for that competition, all competing teams and gymnasts for the competition, and all trials and raw scores. Outputs: The data needed to build the report on Figure 4-3, “Output of the Gymnastics System,” on page 25 of requirement spec. A DB utility dump of the raw input for comparison.

    21. Teaching Points • Validation • Architectural Design • Planning