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.
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.
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
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.
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 CERTAIN to 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.
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 are needed.) 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.
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.
Use Case Realizations
Static 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.!)
Use Case Realizations
Dynamic 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.