Deliverable #8: Detailed Design - Overview due: Wednesday, 7 March 2012

1. Deliverable #8: Detailed Design - Overview due: Wednesday, 7 March 2012 • 1. All Deliverable materials are to be posted into Team Concert. Your email to me, when posted, must contain the path to your materials within Team Concert. • 2. This deliverable will be presented in class on a date TBD. • 3. Don’t forget to email Peer Reviews. You may omit Self-Reviews, if you wish.

2. Deliverables 1. Executive Summary, as usual. This is a one-pager outlining what is in the deliverable. Bullets may be included 2. Statement of Work – who did what; estimated time expended per individual on the deliverable. This SOW should include your preliminary assessment of the technologies that you plan to use in addition to Team Concert, what features you plan to use them, sources of knowledge of these technologies and overall assessment of your team’s familiarities with these technologies.

3. Deliverables (continued) • 3. Traceability and Major Verification • A. Verify that all necessary behaviors cited in the use case narratives have been distributed along the participating classes • See use case narratives and interaction diagrams • B. Verify that all associations between design elements (classes and subsystems in layers and other components) needed for the use case realizations have been defined, • See layer architecture and components therein. • C. Verify that all of the attributes needed for the use cases have been defined and found in domain models, glossary, etc.. • See class diagrams

4. Deliverables (continued) • D. Refine the Use-Case Realizations (boundary, control, entity classes and subsystems interfaces) from Use-Case Analysis into design model elements • E. Ensure application architectural mechanisms (persistence, security, etc.) are incorporated into the use case realizations. • Use Case Realizations are captured via software class diagrams and interaction diagrams for various scenarios. • A comprehensive statement attesting to the verification / traceability exercises undertaken must be included in this deliverable. (a paragraph or two) I may ask about your procedure during your presentation. • Because analysis entities do not necessarily morph cleanly to design components, this may be tough. But try to bridge this chasm between the analysis model and the design realization.

5. Deliverables 4. Iteration Plan. Carefully constructed. This is an essential part of your deliverable, because it really contains your schedule and your development ‘plan.’ Ensure you have time boxes and equally shared responsibilities for contributions. • Be CERTAINto check each other’s work. Do not just parcel tasks out and batch them up for delivery. Verify!!! 5. Design Sequence diagram (Use Case Design) and (optionally a communications diagram) for the basic course of events of each use case and at least one alternative or exception scenario for each use cases. • Do yourselves a favor. Don’t select the easiest alternative path. Also for alternative paths for CRUD considerations, these may not need full expansion. Simple notes may be sufficient. Address those issues that require a good number of object collaborations so that you are certain responsibilities will be met.

6. Notes on Interaction Diagrams • The sequence diagram is to be fully annotated, as shown in lecture slides. You ‘may’ include the communications diagram too • This is a design-level sequence diagram, so it should include the entire flow. Where there is a reference to a subsystem, that subsystem represented by its interface will suffice. (lectures upcoming) For packages, however, the public interfaces for each of the key classes in the package must be shown. (No implementation, but clear responsibilities via anticipated signatures areneeded.) Don’t forget to include any persistency, security, etc. packages in their appropriate layers. • Note that the subsystem interfaces do not require showing the ‘insides’ of the subsystem. The detailed responsibilities will be presented in Deliverable #9. But the responsibilities of the classes within packages (via their individual interfaces) must be shown.

7. Notes on Iteration Plan • Sketch out what you feel will be the number of iterations that will be needed and the features (scenarios) that you will implement in each iteration. • Remember! Jump on the scenarios / features that you feel present to your team the MOST RISK! • Architecturally-significant use case scenarios have the most risk. Also high risk ones are those that address high-priority non-functional requirements, such as security, persistence, distribution, etc. Then, your most important core functionalities should be second. Map out a plan. • Map these to a number of iterations with short duration and stick to the plan. Explicitly task individuals with, perhaps, intermediate review (howgoesit) dates. Include dates, scenarios, and responsible developers, expected outcomes, and room for your iteration assessment - shortcomings (a post mortem). Include span time dates of iteration! • Your first iteration (and each subsequent iteration) must be totally understood before you start it and you should have a ‘pretty good idea’ of the specifics of the next one. As you finish the first, roll into the second one (or subsequent iteration) anything ‘not quite right.’ Finalize the next iteration (or any other one impacted by assessment of the first one) it before you continue. Iterate.

8. Use Case RealizationsStatic Component (Structural) • Class Diagram • For each sequence diagram you develop, you are to produce the VOPC (View of Participating Classes) for that sequence diagram. • Be certain to include all the associations, dependencies, multiplicities, aggregations, etc. • Some of the details of Deliverable #7 that might not have gotten ‘finalized’ (Try to include any clear attributes). Identification of methods that realize responsibilities will be very helpful indeed.) (No algorithms, etc.!)

9. Use Case RealizationsDynamic Component (Behavioral) • Interaction Diagrams (Sequence and Communications). • Sequence diagrams are to be fully annotated and should include subsystem interfaces, persistency references, etc. as appropriate. (See previous slides) • These should be consistent with your subsystems / packages in your layered architectural design. • Be certain to look at past examples of sequence diagrams in the lecture slides.