1 / 8

Homework #8 - Deliverable 5 due: 2 December

Homework #8 - Deliverable 5 due: 2 December. 1. Exec Summary 2. Revisit Use Cases 3. The Analysis Model Class Diagrams Interaction Diagrams 4. Non-Functional Specifications. Deliverable #5 Analysis Model - Static.

lockman
Télécharger la présentation

Homework #8 - Deliverable 5 due: 2 December

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. Homework #8 - Deliverable 5due: 2 December • 1. Exec Summary • 2. Revisit Use Cases • 3. The Analysis Model • Class Diagrams • Interaction Diagrams • 4. Non-Functional Specifications

  2. Deliverable #5 Analysis Model - Static • VOPC. Include boundary classes together, control classes together, and entity classes together all without associations to other classes. (a one-page drawing) Merely separate the classes from each other. This should partition all the classes by type. Include all attributes / methods with each class, but no connectivity. This is the View of Participating Classes. Example is found in my slides. • Follow this with a fully ‘connected’ model– foreachusecase. Use those analysis classes appropriate to the use case and associate the classes. • Class structure may be realized with the standard stereotyped classes or the RUP icons • These should be modeled in RTC

  3. Deliverable #5 Analysis Model – Traceability • Remember, the validity of the model is simply determined: can one look at any path through a use case (scenario) and see where/which objects will accommodate all the functionality captured in this scenario? • Can the functionality be traced (with your finger...) through the objects as you read through the path description? • Each developer should be responsible for his/her own traceability. This will be demonstrated in class. • This is the check to make! VerifyTraceability!!!

  4. More on Deliverable #5 Analysis Model • For boundary to control classes, a simple association line is sufficient, because it cannot be determined what method in control class will be invoked from the boundary class unless we consider a specific scenario. Better, though, is a series of boundary classes constituting the interface. See lecture slides for example. • Associations among entity classes should have the multiplicities, aggregations, dependencies, etc. cited. • They are appropriate here and may come from your domain model, which will VERY likely need upgrading after/during your exercise.

  5. Deliverable 5 - Interaction Diagrams • For each use case, you are to develop a sequence diagram for the basic course of events only. (You need NOT develop sequence diagrams for the other scenarios (alternative and exception scenarios). Only one interaction diagram per use-case (at this point). • These will show boundary, control, and entity classes along with appropriate actors needed to analyze a specific scenario. • You may use SmartDraw, if you wish. (Freeware) • Recommend that the static classes (boundary, control, and entity classes) be developed first so that the methods these classes include are available to the dynamic model (sequence diagram), which sequences the issuing of method calls.

  6. Deliverable 5: Non-Functional Requirements • See Use Case Textbook for ‘tables’ • Thoughts: • Small systems: • functionality; performance • Large systems: • Portability; Maintainability; Scalability; Reliability; Security • How about: Persistence? • Will discuss more in class; Remember the Supplementary Specifications for Non-Functional Requirements. • The Supplementary Specifications Document should be a Word document containing the non-functional ‘tables.’

  7. Second Semester Deliverables(anticipated) • Deliverable #6 – User Interface Design • Deliverable #7 – Layered Architectural Design • Deliverable #8 – Detailed Design - Iteration Planning and Use Case Realizations – Context Diagrams only. • Deliverable #9 – Subsystem Design – Interaction Diagrams (both) and VOPC diagrams. • Deliverable #10 –Class Design and Implementation #1; First Functional Demonstration • Deliverable #11 – Final Deliverable: Complete Implementation Model and Demonstration including client testing. Clients will be simulated – other teams.

  8. Last Slide! • This is it for this semester. • Hope you feel that you have learned a great deal. • As I have mentioned, this is very marketable knowledge. • Have a great Christmas!!!!

More Related