Transcript Document 7288323

Project Deliverables
Version 9: 04/03/06
Note: This document contains the deliverables for a two semester
course.
It is a living document and changes every now and then. Stay tuned!
For CEN 6017: Go to Slide 53
Overview of Guidance



I shall try to upgrade / refine guidance for
each deliverable as we progress.
Please view this file often as it will change.
Suggestions for clarity and/or consistency
are always welcome.
Format of Deliverables



All Deliverables will be via CD.
Outside: Surface of CD is to clearly indicate
your course number and the team number, as
CEN 6016 - Team 1. Also include the project
title.
Inside: Each deliverable will be in a separate
folder on the same CD, so when I access the
CD, all I should see are individual folders with
labels such as Deliverable n, as in Deliverable 4.
Contents of Folder
 Each
Folder (i.e., Deliverable) is to
contain
 Management

a number of Word files discussed ahead
 Artifacts

Folder:
Folder
Contents discussed ahead.
Management Folder
Documents

Team Num file, with file name as follows (for example):
Team1.Deliverablen.Date.mm.dd.yy
 In this file, you are to simply (may be a single Word
file):





List the names of the team members
Indicate who is team leader with phone number.
Indicate who is the software quality analyst and phone
List individual email accounts.
Iteration Plan (Include for second semester deliverables)
 Note that the Iteration Plan will change for each
deliverable, that is, it will be refined and ‘extended.’
Each successive deliverable will contain a ‘revised’
Iteration Plan.
Management Folder
Documents

Executive Summary
 Single page document; Summarizes the contents of this
folder.
 What ‘activities’ were undertaken
 What ‘artifacts’ were changed and rationale
 Note: revising artifacts is the norm in an iterative
approach to software development.
 What new ‘artifacts’ were produced
  Must include signatures of EACH team member that
he/she has reviewed and has ‘bought off’ on the contents
of this deliverable.
 If you have not read and personally reviewed the
contents of the deliverable, do not sign this form!
Management Folder
Documents

Team Activities:



Team Software Process (TSP), and
Personal Software Process (PSP) Forms
Software Quality Analyst Report

This will address in narrative or graphic form (your choice) the
status of the project with respect to identifying and tracing
requirements to date as well as efforts undertaken by you
regarding testing.
Artifacts Folder

All developed artifacts will be found here.
Sometimes the artifacts will be models; other
times, they will be documents. Artifacts are items
produced by team members as a result of
undertaking specific activities.


Sample artifacts – likely Word documents: A project
Vision Document; the Risks List; the Business Rules
document, etc.
Sample artifact likely developed in Rose: Your Use
Case Folders within your Rose Model.
Artifacts Folder (continued)

Sample artifacts developed in Rose (continued):


In general, specific components of deliverables should
be found here, and a number of these should be in
their own subfolders, such as the user interface
prototype (linked to via Rose / Requisite Pro), Use
Case diagrams, Use Case Narratives, Analysis Model,
Sequence Diagrams, architectural models, etc.
We will discuss in class for each deliverable.
Guidance on the Rose Browser

Use Case Diagrams in Use Case Folder
within Use Case Model in Rose

Capture Use Cases in separate subfolders in
the Use Case folder within Use Case Model in
Rose (see the Rose Browser).


But Use Case Narratives are in Requisite Pro
Capture all Actors in folder within Use Case
Model in Rose
Grammar and Wording





Under NO circumstances will poor grammar or ill-conceived
sentences be considered acceptable work.
EACH portion of EACH deliverable should be reviewed and
‘signed off’ by EACH team member. (as stated)
Poor adherence to this ‘standard’ will impact EACH team
member. So, check out your text BEFORE you submit it to me.
This is a TEAM responsibility!!
On the provided templates, there is room for signoff by the
team / team members. Use this for verification…
Deliverable #1
Business Modeling
(Domain Analysis)
Deliverable #1 Business Modeling
Business Domain Analysis
Due: Monday 10/3

Purpose:

To understand the structure and dynamics of the
organization within which the application will
operate;

To ensure customers, end-users, and developers
understand the organization;

To derive requirements on systems to support the
organization;
Deliverable 1 – Business Model
Domain Analysis
Deliverable Artifacts






Business Vision Document - a text document.
Business Use Case Model – captured in a Rational
Rose model
Business Glossary - text
Business Rules – text
Business Risk List - text
Domain Model - model in Rational Rose – will
accommodate in Deliverable #2.
Deliverable #1:
Business Vision Document






This captures (Word document) the purpose of
the business enterprise.
What services are they providing?
What are they all about?
Who are the customers?
What are the goals of the business?
Primary stakeholders??
Business Vision Document (more)

You may use the Vision Template (see web
page) but you must MODIFY it so that it does
NOT address a project; rather, it will capture the
vision of the enterprise itself.

eliminate section 2. Elaborate on section 1. In
Stakeholders, address those interests NOT from a
project perspective but from an organization’s
perspective: customers, users, etc. There is no
Product Overview But your business vision document
should address what the business is all about. Add
major sections that you deem appropriate.
The Business Use Case Model


When logging onto Rose, be sure to select RUP icon from
the initial window.
Be also certain to notice the tool mentors – when you
select a folder in the Rose Browser, a description often
appears with invaluable information.

The Business Use Case Model must be developed in the
Use Case View (see last slide)

This is a single model of the key business processes of the
organization.
Deliverable #1: Business Glossary


Definitions of important terms used in the
business. (alphabetical)
Key words: (sometimes these are called
‘core abstractions.’ ) These are often the ‘things’
the business deals with. Business Entities.
A Student Registration system might have key words
like Course, Schedule, Payment, Registration, Student,
Professor, ….
Deliverable #1: The Business Rules

Use the appropriate forms available at:





RUP document templates are located at the site
http://jdbv.sourceforge.net/RUP.html. See also my web page.
The link for the Business Rules template is incorrect (points
to the Business Modeling Guidelines template), so there is
another link to point to the Business Rules format.
There are also two former student examples on my web page
to guide you. (Note: I am not disclosing their grades, or
how I graded them.) These are merely samples.
Be careful: The samples on my web page are Rules for an
application that will be developed. Your Rules are simply for
the organization itself - the way it does business; guiding
principles. It has no relationship (at this time) to an
application to be developed.
Business Rules are policy declarations or conditions or
guidelines that must be satisfied in running the business.
Deliverable #1:
The Business Risks List


Very general at this stage.
What are some of the risks that the
organization must be constantly assessing:


e.g. market share, technology awareness, new
statutes from Washington D.C., trends in the
industry; demographics; environmental
considerations, maintaining top notch software
developers, keeping developers current; training;
give this some thought….
Again, this is at the organizational level.
Deliverable #2
Domain Model
The Product Vision Document
Statement of Work
Deliverable #2 – Artifacts
Due: Monday, Oct 17th

1. Build a Domain Model (precursor activity to Use
Case development)


Is an essential activity to facilitate good use case development that
contains glossary items and objects from the problem space (domain).
2. Build a Product Vision Document
Will include User Needs and Features



3. Develop a Statement of Work – assigning responsibilities to
different roles to be accommodated on the team.
Traceability Matrix
Review / upgrade previous artifacts.
4.
Business Use Case Model, Use Cases and Actors - Modeled
Business Vision document – text, Business Glossary - text
Business Rules - text
Deliverable #2: Domain Model
1. Domain Model – The Domain Model should be captured
as a separate folder under the Logical View in your
Rose Browser.
 This is a major effort that takes into consideration
attributes, multiplicities, associations, etc.
 Be careful. the Domain Model may look like a Database
Schema. It isn’t. It is similar – to a degree – to a Fully
Attributed List in the Logical Model – but there are
differences.


Notice also – a good domain model does not have methods –
only attributes and connections (associations/ dependencies)
There is a decent link to a student example on my web
page. Notice it is found in the Logical View (as it should).
Domain Model - continued





A continuation of Domain Analysis…
The Domain Model is an extension of
Deliverable 1. It deals with the
organization.
Domain Model is essential to understanding
the environment within which the
application to be developed will function.
It is sometimes the only item from the
Business Case. But it is an essential artifact.
 See Lecture 8 on the Domain Model.
Deliverable #2: Product Vision Document


This represents the vision for the application you will be
developing. This essential artifact is called the Product
Vision Document.
Use the template provided.


You may transfer much of the information from the
Business Vision Document to this Product Vision
Document.




You must take the link to the RUP documents and access the
Project Management Templates : Product Vision Document.
You are to add the Problem Statements (section 2.2) and all the
other items dealing with the Stakeholder and User Profiles and
Stakeholder and User Needs.
You need not include the Product Overview section.
Product Features Section (section 5) is essential and is to include
identification of stakeholder needs and their mapping to features
via the traceability matrix shown in lecture materials.
(Software Quality Analyst on your team will learn/use
Requisite Pro. Take the Requisite Pro Quick Tour…) One
other team members should be conversant.
More on Needs and Features




When we are dealing with ‘needs’ and ‘features’ we are
dealing with reasonably high levels of abstraction.
But it is critical to capture the features in the Vision
Document for a new application, because it is these
features that must be accommodated in the delivered
system.
The Features drive the development of the use cases –
our functional requirements, and the development of our
supplementary specifications – our non-functional
requirements.
Your deliverable must contain a Traceability Matrix.
More on Sample Features



Features are not behavioral (like the Use Cases). These are typically
text descriptions.
Example of features: (We will discuss)
ClassicsCD.com Web Shop
Need a Secure payment method.
There must be easy browsing for available titles.
Users need the ability to check the status of an order.
Application must provide Customer e-mail notification.
The catalog shall be highly scaleable to include many
titles and effective searching through those titles.
The Customer shall be able to customize the Web site.
The Customer shall be able to register as a user for future
purchases without needing to re-enter personal
information.
Deliverable #2: Statement of Work

3. Statement of Work


May take on this is a bit different than the Use Case Book. It
should be a Word document. See textbook and/or templates for
format
What is your team plan?





Meetings/ (see forms on web page)
Who does what (that is assign roles)?
What are the responsibilities that must be
fulfilled by each role?
What is your plan? (See textbook)
This short document should appear in the
Artifacts Folder
Deliverable #2 – Traceability Matrix


A traceability matrix associating needs to
features is to be captured in the Product Vision
Document.
This is essentially a 1:n mapping of Needs (from
the Users/ Stakeholders) to Features that the
application will accommodate.



Needs are very high level and may contain items that
will not be (can not be) accommodated by the
application.
Features are to be accommodated by the application.
Additional guidance will be presented to support
your traceability efforts.
Deliverable #3
Develop Use Case Index
Develop Façade Use Case Specification
Develop Initial User Interface (UI) Prototype
Extend Requirements Traceability (RT) Matrix
Deliverable #3 - Use Case - Façade Iteration
Initial User Interface Prototype, Traceability
due: Wednesday 10/26


Executive Summary (overviews new artifacts and
ALL changes/revisions to existing artifacts, such as
the revised Iteration Plan, etc. as required.
Specific Rework:


Revisit the Business Case (Deliverables 1 and 2)
including artifacts listed below and update them. (Risks
Lists – deliverable 1; Business Rules.
Revisit Artifacts from Deliverable 2 especially the
Domain Model and the Product Vision Document
(deliverable #2) and the Statement of Work, etc.)
Deliverable #3: New Artifacts

1. Develop Use Case Index


Single page: Essentially this is a table of contents of
Use Cases
Include an index for Use Cases that follow. Use
designators, UC1, UC2, etc. (to facilitate traceability)


Use Case Index is to contain an entry to support traceability, Use
Case name (verb…object), short description (no more than a
single sentence), and other high level items you consider
important.
Construct this in tabular form using a table in Word. See power
point slides for detailed attributes needed
Deliverable #3: New Artifacts

2. Develop Façade Use Case Specification.

Develop an overall Use Case Diagram (all application Use
Cases and Actors). Similar to Business Use Case Model
but icons are a little different.




This is sometimes called the system level use case model.
This should be a single page of actors and use cases.
Examples of all these can be found in Use Case book and Visual
Modeling book.
Develop Façade Use Case Specifications and associated
Use Case Diagrams for each Use Case. (See examples)


Use Requisite Pro and Rational Rose (Use Case View) for your
models. Link the Use Case Specifications captured in Requisite
Pro and onto Rational Rose.
Use the Façade Use Cases templates from the Kulak and Guiney
book. Again, see power point lectures for required attributes.
(See examples of ‘reasonable’ student Use Cases posted on my
web page.)
Deliverable #3: New Artifacts

3. Develop User Interface Prototype


…needed to familiarize the end user with the beginnings
of the User Interface. Additional functional
requirements will likely be discovered. Iterate this a as
needed. (Can be done in conjunction with the Façade
Use Case and will (together with Domain Model) greatly
assist you for Deliverable #4, your full-blown Use Case
Descriptions with alternate and exception paths.
You may use any prototyping tool you wish: VB,
JavaScript, dynamic HTML, etc. Your prototype should
include storyboarding.



Most teams use static html; some use Front Page; some contain
Javascript, etc. It doesn’t really matter to me.
Validate the functionality represented on the user interface with
VIM.
Alternatively, validate with members of other team.
Deliverable #3: New Artifacts


To accompany the Façade Use Cases, user interface
prototype needs to represent the functionality that will
ultimately be implemented and accessible from the UI
later.
See examples of initial user interface prototypes on my
web page. See also (ahead) lecture slides on User
Interface Design
Deliverable #3: New Artifacts

4. Extend a Traceability Matrix

Traceability Matrix is to extend the traceability
matrix developed in Deliverable #2.
Traceability so far includes tracking indicators (U1,
S03, etc.) from previous work that mapped Needs
to Features. There were a couple of effective ways
we discussed.
 In this deliverable, you are to extend the
traceability from Features (captured in the Product
Vision Document and documented in matrices)
from Features to specific Use Cases that tell the
stories of the Features. Thus your Matrix will have
a 1:n mapping of Features to Use Cases.

Deliverable #4




Develop Full/Mature Use Case Specifications
Develop Activity Diagram for each Use Case
Extend Requirements Traceability (RT) Matrix
Revisit and Revise:




Domain Model,
Façade Use Case Specifications and Diagrams
User Interface;
All Management Docs
Deliverable #4 Overview
due: Monday, 11/14






Executive Summary; Cite all revisions and overview
activities.
Develop Mature Use Case Specifications and associated Use
Case Diagrams for each Use Case.
Each Use Case is to be accompanied by an Activity Diagram
that should indicate flow for all paths in the Use Case
Extend the Traceability Matrix by tracing all use cases
backward to specific features and forward from features to
use cases.
Revisit the Domain Model for added / altered business
entities; revisit your Risks document, Business Rules, and
Product Vision statement.
Upon ‘completion’ of Use Case specifications, revisit the UI.
Use Case Specifications


Complete Use Case Specification and Use Case
Diagrams for each Use Case – This is a major
assignment.
Complete your model by including alternative,
exception flows, and ‘sub-flows’, using extension
points or other tags as appropriate.



Include all subflows with your use case narratives.
Modify any use cases you feel are associated with any
‘included’ or ‘extending’ use cases and change use case
diagrams to reflect these use cases. (There definitely should
be some.)
Develop a single Use Case Diagram for the entire Application
too. This will be a single diagram containing all actors and all
use cases and connections.
Use Case Specifications - More

Allocate functional requirements / features to use cases via
the stories of interactions. This is a painstaking and long
task! It will underpin your entire design. Spend time
here!!!! Recognize that Use Cases are NOT functional
requirements; rather, they are stories of actor-application
interactions which contain the required functionality.


All customer functionality should be accounted for here.



Try to get the proper level of granularity. (Discussed in class).
Be certain to use your Domain Model and italicize or bold all
references to entities in the domain model and/or Glossary.
Ensure everything the customer desires is accounted for!
 Iterate on the Use Case Model. Review, Review, Review!
Rational Rose and Requisite Pro

In Rose, put Use Cases into packages appropriate to the
major feature(s) and groupings of features they address.



(These may assist in our software architecture later – as these may
become likely subsystems).
Use Rose (Use Case View) and Requisite Pro to link all these
into a single browser (SQA team members).
 Kulak and Guiney book (Use Cases); Visual Modeling
book and Rose Basics (see power point lecture slides for
examples.)
Recognize that Use Cases are really never ‘finished.’
They become more ‘mature’ as we learn more.
Activity Diagrams

Develop one activity diagram per Use Case.

Activity Diagram is to should include all alternate
paths.


You may view an Activity Diagram as a visual model of
the Use Case, since it will contain all scenarios.
Include Activity Diagrams in a package in Rose
Browser in the Use Case View under Use Case
Models in a folder entitled Activity Diagrams.

See Visual Modeling text for examples and use Rose.
Traceability Matrix




Extend your traceability by tracing all features forward to
individual or groups of Use Cases required to capture
these features.
Similarly, trace Use Cases back to features that the Use
Cases address.
You must ensure that every feature is accommodated in
the collection of Use Cases and that there are no
superfluous paths in use cases that do not trace back to
specific features.
You will need to address the scenarios in each use case
to do an adequate trace. This is a lot of work. If you
find a scenario that does not relate back to a feature,
check the feature; if necessary check the Need.
Something needs to be resolved… Report on this activity.
Revisiting / Iterating Previous Deliverables
Special emphasis: UI and Domain Model


Be absolutely certain to revisit / modify your
User Interface Prototype in light of the
development of the collection of Use Cases.
Recognizing that this collection represents the
functionality of the application, does the Use
Case support these major functions at a
sufficiently high level.
The most major options presented on the UI
must reflect the most major features to be
implemented – up front…
This will be a major milestone in our development efforts.
Once we can ‘baseline’ these artifacts with user concurrence,
we will then embark upon Analysis Modeling
Deliverable 5
due: 11/30



1. Analysis Model
2. Non-Functional Requirements:
Supplementary Specification Document
3. Traceability Matrix
Analysis Model


1. Analysis Model (Preliminary Design)
Part 1: Static Model – VOPC




Your analysis model must include boundary classes, a
control classes, and entity classes required for each Use
Case.
Model is to be fully connected - show labeled associations,
multiplicities (for entity classes – may come from Domain
Model)…
Should be a one-page drawing per Use Case
Class structure may be realized with the standard
stereotyped classes or the RUP icons
Analysis Model – Sources; Guidance



Use your initial user prototype (boundary),
Domain model (entities), and
Use Case Specifications (control as well as the others)




See also your Features to ensure all features are captured.
See Visual Modeling Book; RUP; Logical View on Rose
Allocate as many attributes and methods
(responsibilities) as possible to each of the analysis
classes.
Can one inspect any path through a use case and see
where/which objects will accommodate the
functionality?

(Can it be traced (with your finger...) through the objects
as you read through the path description?
Analysis Model


1. Analysis Model (Preliminary Design)
Part 2: Dynamic Model – Interaction Diagram




Your analysis model must include an Interaction
Diagram (Sequence Diagram and Communications
Diagram) for the basic course of events for each
Use Case.
Use your analysis classes in this modeling.
There are a host of examples in my notes and in
the books for this course.
Object structure may be realized with the standard
stereotyped classes or the RUP icons
Non-Functional Requirements



2. Supplementary Specifications Document
See Use Case Textbook for examples of ‘tables’
System Size:




Small systems:
 functionality; performance
Large systems:
 Portability; Maintainability; Scalability; Reliability; Security
How about:
 Persistence? Will discuss more in class.
The Supplementary Specifications for Non-Functional
Requirements should be a Word document containing the nonfunctional ‘tables.’

Link this in to Req Pro.
Traceability Matrix and Associated Documentation





1. Map each Use Case (such as UC1, …, UCn) to the
analysis classes that will accommodate the Use Case
functionality. (Recognize that there may be many
scenarios in each use case. But they must be
traceable to analysis classes and hence the matrix.
You may have to be somewhat creative to show this
kind of trace to specific analysis classes.
Again, you might include a VERY short description of
the Use Case (its name and short description) and
then the analysis classes that realize the
specification. Link this in to Requisite Pro.
Ensure ALL traceability is VERIFIED to date!
“Let no function be left behind!” (Ha)
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.
Deliverable #6 - User Interface Design
due: Wednesday, 25 January 2005

Purpose: To design a user interface that reflects application
functionality.
 This should be a significant refinement of your initial user
interface prototype based on your increased knowledge and
understanding of the requirements.
 This user interface should demonstrate the vast majority of
key items of functionality as found in the use cases.
 In your classroom and field presentation, you are to
demonstrate how your UI satisfies required functionality.
 Utility and Usability Principles as cited in the lecture slides
and your text will be emphasized in evaluation.
 Verify your UI by running it against your use cases to ensure
all functionality is captured.
Deliverable #6 - User Interface Design

I should be able to access the Deliverable #6 folder on your CD
and bring up the UI and execute it successfully.






I should be able to navigate from screen to screen to pursue some
scenario from a use case.
I should NOT have to hunt and peck and wonder…
Recognize that some (a few) of the windows / displays will be /
may be hard coded and that demonstrated functionality may
not be totally backed up with implemented code or efficient
algorithms. But the implied functionality must be clear.
Text caveats in the UI are appropriate.
ALL new team members must be on board and conversant with
the project
This will be field tested for the Medical Project.
Deliverable #6 - User Interface Design






Your User Interface will be demonstrated in class
and will be openly discussed.
This version of your UI should address ALL the
anticipated functionality for the VIM project.
Ensure the UI incorporates all the myriad changes
emailed by the users that you will include in the
application.
Features to ‘not be included’ will be separated
discussed during your presentation.
Team 2 will present first.
Ensure Self and Peer Evaluations are emailed to
me.
Deliverable #7 – Layered Architecture
due: Wed, February 15, 2006

Layers:




You are to design a layered architectural prototype to
accommodate your application requirements.
The named layers are to consist of major subsystems and
packages, their contents (other subsystems, packages, etc.). All
component dependencies (coupling) are to be indicated via
appropriate UML connectors.
The main purpose and suggested contents of each of your layers
must be spelled out in a text-accompanying document. (see
lecture slides for examples)
Your choice (decision) of architectural pattern should be fully
discussed using the eleven design principles; that is, how does
your choice support the design principles enumerated upon in
the lecture slides and your textbook. (Word document, please)
Deliverable #7 – Layered Architecture

Subsystems / Packages.





For each subsystem, you should provide a single sentence citing
the purpose of the subsystem (that is, how it ‘coheres’).
You should provide a rationale explaining exactly why specific
subsystems / packages were placed in their respective layers;
that is, a record of your design decisions. (Cohesion)
The detailed contents of the subsystems / packages
(subsystems, packages, classes and their associations /
dependencies) of each design element should be supplied at this
time (cohesion). This means that classes, for example,
constituting a subsystem or package, must have their properties
named and methods (responsibilities) cited – as much as
possible.
You should NOT INCLUDE the detailed description of properties
(that is, float, char, integer, String, etc.) nor the number and
types of parameters for the methods nor the algorithms, etc.
used by the methods. Only named methods / return items.
These models should be realized in Rose. Supplement
this layered model separately as needed in Word.
Deliverable #7 – Layered Architecture




Please note that your architectural modeling
(layers and their components, etc.) should be
captured in Rose: Logical View, Design Model,
<Layer-Name> Layer.
The <Layer-Name> Layer has subfolders for
packages, subsystems, etc., which you will like (I
hope).
There are mechanisms for, say, a subsystem, to
name the subsystem and site the dependencies
and interfaces related to this subsystem.
Approximately what I’d like your deliverable to
look like:
Architectural Layers – the basic idea
Presentation Layer
Subsystem name
Subsystem name
Subsystem name
Package name
Subsystem name
…However many
Application Layer
Subsystem name
… However many
Middleware Layer
Subsystem name
Subsystem name
… additional layers as you decide.
Name each of your layers (probably four…), subsubsystems, packages,
classes, etc. etc.
Package name
…
However many
Components and Their Interfaces
You will communicate the interface of each component by taking each component (subsystem) and showing
the responsibilities of the subsystem by showing the interface class. (Note the stereotype below)
You will need to show the arguments that are part of the signature.
Please note that a package has no specific interface and thus the classes in a package needs to
explicitly show its public interface.
Maintain Database
(name interface)
<<interface>>
Addrec(xxxx, xx) bool
UpdateRec(xx, xx) int
DeleteREc(xxxxxx)
etc……
Design Elements in Each Component
You may combine this drawing with the previous drawing; otherwise, make this separate.
For each component, you should also – as much as possible - include the classes and their properties/method
that are needed to ‘realize’ the interface. Recognize those signatures in the interface must be accommodated
by the classes or other components (along with other dependencies ‘they’ might have) in the subsystem.
You may also show any dependencies these objects will experience with realizing the interface…
Maintain Database
(name interface)
<<interface>>
…
Addrec(xxxx, xx) bool
UpdateRec(xx, xx) int
DeleteREc(xxxxxx)
etc……
1..2
Add properties, methods,
and anything else that
will assist in realizing
the interface.
*
…
…
XXXX Package
Showing a dependency
between this object (in sub)
and an object in
another design
element (package,
here)
We are saying that the
interface is realized by
this combination of
objects and dependencies.
Deliverable #8: Detailed Design - Overview
due: Monday, 6 March 2006


0. Folder with Deliverable #8 on CD. Executive
Summary, as usual. (Also, send Self and Peer Reviews)
1. Iteration Plan. Carefully constructed. This continues
to be 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. (SQA person primarily
with team leader inputs and team buy-in!!)


Be CERTAIN to check each other’s work. Do not just parcel
tasks out and batch them up for delivery. Verify!!!
2. Sequence diagram and a communications diagram for
the basic course of events and at least one alternative or
exception scenario for each of your use cases is required.


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.
Deliverable #8: Detailed Design - Overview
due: Monday, 6 March 2006

3. Traceability Update – Trace your design model
entities to layers and subsystems / packages if
possible. (accommodated by SQA guru)




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.
4. Prepare to Present – Nothing formal. Perhaps two
team members should present. Date: to be decided.
Should be able to cover easily within our 75 minutes.
5. Technology assessment. See slide ahead. Should be
accommodated by team leader.
5. No need to interface with VIM people for this.
More Notes on Interaction Diagrams


The sequence diagram is to be fully annotated, as shown in
lecture slides. Include the communications diagram too (use
the F5 toggle) Clearly use Rose.
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 is 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.
Deliverable #8: Detail Design – 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! Secondly, your
most important core functionalities should be second.
Map these to a number of iterations with short duration
and stick to the plan. 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 must be totally understood before you
start it and you should have a ‘pretty good idea’ of the
specifics of your second. 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.
Deliverable #8: Detail Design – Iteration Plan




Technology Assessment.
Your iteration plan should include your
preliminary assessment of the technologies that
you plan to use, where (for what features) you
plan to use them, sources of knowledge of these
technologies and overall assessment of your
team’s familiarities with these technologies.
Tell me who knows what and the extent of that
knowledge.
See examples on my web page .
Deliverable #8: Detail Design – Use Case Realizations
Static Component (Structural)




Class Diagram
For each sequence diagram you develop, you
are to produce in Rose 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.!)
Deliverable #8: Detail Design – Use Case Realizations
Dynamic Component (Behavioral)





Interaction Diagrams (Sequence and Communications).
These should be captured in Rose These should be
located in the Logical View, Design Package, etc.
Check out Use Case Realizations.
Sequence diagrams are to be fully annotated and
should include subsystem interfaces, persistency
references, etc. as appropriate. (See previous slides)
Be certain to look at past examples of sequence
diagrams in the lecture slides.
Use the toggle (F5) to generate the Communications
Diagram.

Note: Professional Rose users almost all seem to imply that
developing the communications diagram first results in a
cleaner, less cluttered sequence diagram via the toggle rather
than vice versa. What do you think?
Deliverable #9 – Detail Design, Traceability, and
Iteration Plan
Subsystem Design and Realization – due: 20 March 2006

For each subsystem, you are to provide an interaction diagram of
at least two responsibilities accommodated by the subsystem
from its interface. (lecture 32) and Deliverable #8.





No more than one interaction diagram for one subsystem should
address accommodating persistency. You should, however, include
one that does this. This means that of all your subsystem
realizations, you may only show one interaction diagram that
addresses persistency.
I am thus after you to show a number of realizations that your
subsystems must accommodate.
You should also present the corresponding communications
(collaboration) diagram. Note the differences.
For each subsystem, you are also to provide the internal structure
of your subsystems, like appropriate slides in lecture 33. This is
your VOPC. These are to be fully annotated (dependencies,
communications, multiplicities, etc.)
You are to annotate via stereotyping which objects are persistent
in your modified VOPC as well as any other stereotyping you feel
is necessary. (See lectures on class design and persistency)
Deliverable #9 – Detail Design
Subsystem Design and Realization





All messages in your sequence diagrams need to be
numbered as shown in lecture 32 (numbers and their
sub-parts).
ALL of your design class model elements must have the
package or subsystem they are associated with in with
the class header as shown in lecture 33 (think:
University Artifacts).
Packages and Subsystems should have a stereotype
indicating the layer in which they reside.
Sequence Diagrams may require UML Notes to clarify
interactions. Use them as necessary.
Extra credit and VERY NICE Touch: Try to list the text of
the Use Case Specification in the left margin (column?)
of each sequence diagram.
Deliverable #9 - Traceability



The second major part of this deliverable is to
realize traceability of each function captured in
Use Cases and in the Analysis Model here in the
Design Model.
Frankly, you are breaking new ground here. It
one thing to have traceability from Use Cases to
analysis classes. It is quite another thing to
trace analysis class traceability into the Design
Model, as realized in subsystems, packages,
classes, and in layers.
Please note that this is a major undertaking for
this deliverable and will take time!
Deliverable #9 – Iteration Plan





This is to be a comprehensive treatment of
iterations particularly starting with the Construction
Phase.
This should be based on scenarios in Use Cases. It
should not be supporting activities such as refining
the database, developing stored procedures, etc.
It is used to track the development of the
application and is an essential tool used to
determine if we are on schedule.
You may use any reasonable format, but remember,
each iteration has most of the core disciplines as
activities! (requirements, analysis and design,
testing, implementation, configuration, environment,
program management, etc.)
Again, lots of work…
Deliverable #9 - Questions



These are questions whose answers are to accompany this
deliverable. You may answer these in the Management Folder.
STUDY these questions and answers. Ensure that they are complete,
as you will see them again!
What is a proxy class and what is its purpose?
What do we mean by a dependency?





What are the pros and cons of dependencies?
Under what circumstances is the modeling of only a subsystem
interface sufficient in a sequence diagram?
In behavioral modeling, when must the interface be realized? How is
it done? What kind of model(s) is/are used to capture the details of
the inner workings of a subsystem?
Why should dependencies on a subsystem be on the subsystem
interface?
Turn these in via a separate Word document.
Deliverable #10
Class Design and Implementation #1 due
3 April



In addition to Executive Summary,
 Update your Iteration Plan for remaining iterations based on your
assessment of the previous iterations.
 Document that assessment as part of the Iteration Plan (may use
Word)





This may likely be a few paragraphs. Don’t wimp out on this!
 Ensure all methods in your Use Case Realizations have full
signatures in their calling sequences.
 Extend your Traceability to cover your current detail design
 Testing: Document your test suites: catalog these via number,
purpose, scope, results, and assessment of each test.
 Using Rose, ensure your classes and attributes are all correct by
revising your VOPCs ensuring that all connections are either
associations or dependencies.
This can be shown by clicking on objects across the top of sequence
diagrams and filling in the window specifications.
Deliverable #10
Class Design and Implementation #1



Demonstrate and Discuss your (first and)
second Iteration in class (possibly)
Talk about the ‘good, bad, and ugly’ of your
development, tests, etc.
(not formal; 15 minutes per team)
Deliverable #10
Class Design and Implementation #1

Source Code: Your deliverable is to include your sourcelevel components.




organized ‘by design unit’ (that is, package, subsystem), ‘by
component’ (within these higher level components).
Read documentation section of Component View in Rose.
 Please note: Your source code absolutely must be
internally documented with meaningful, guiding
comments. These will be reviewed very carefully!!!
So, your organization should be Component View,
Implementation Model, Package or Subsystem, and
specific component within the owning package or
subsystem.
Deliverable #11
Implementation #2 and Demo due 17 April




This is a continuation / extension of Deliverable #10:
In addition to Executive Summary and the accustomed documents,
 Update your Iteration Plan for remaining iterations based on
your assessment of the previous iterations.
 Document your assessment as part of the Iteration Plan





This may likely be a few paragraphs. Don’t wimp out on this!
 Ensure all methods in your Use Case Realizations have full
signatures in their calling sequences.
 Extend your Traceability to cover your current detail design
 Testing: Document your test suites: catalog these via number,
purpose, scope, results, and assessment of each test.
 Using Rose, ensure your classes and attributes are all correct by
revising your VOPCs ensuring that all connections are either
associations or dependencies.
This can be shown by clicking on objects across the top of
sequence diagrams and filling in the window specifications.
Deliverable #11
Implementation #2 and Demonstration

Source Code: Your deliverable is to include your
source-level components.




organized ‘by design unit’ (that is, package, subsystem), ‘by
component’ (within these higher level components).
Read documentation section of Component View in Rose.
 Please note: Your source code absolutely must be
internally documented with meaningful, guiding
comments. These will be reviewed very carefully!!!
So, your organization should be Component View,
Implementation Model, Package or Subsystem, and
specific component within the owning package or
subsystem.
Deliverable #11
Implementation #2; Demonstration


This deliverable is a chance to finalize any
shortcomings in your Iteration Plans, Rose
Models, or any design models/artifacts you have
undertaken.
ALL code is to be fully documented and
submitted in folders “by type,” that means jsp
files together, .java files together, servlets, …etc.
Deliverable #11
Implementation #2 and and Demonstration






On the day you are demonstrating your projects (April
17th), you are to provide to me a hardcopy of your use
cases. I will arbitrarily select one or two for you to
demonstrate during class.
(I would like to meet with the team leader / designee,
the SQA individual and, if available, one of your lead
programmers in my office earlier on Monday, the 17th, if
that is feasible. Please email and we can discuss the
best time for you.)
You may also be asked some general questions.
Your demonstration, etc. should not last beyond thirty
minutes.
If you need separate computer support, you should plan
to go to class early to set up / connect to whatever you
need.
Good luck and have fun!