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 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 – for each use case. 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

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! Verify Traceability!!!

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.

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.

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

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.

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!!!!