1 / 22

Elaboration

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.

Télécharger la présentation

Elaboration

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

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

More Related