Project
Project Deliverables Deliverables
Version 1: 08/29/2005
Note: This document contains the deliverables for a two semester course.
These items WILL change as the courses progress.
Overview of Guidance 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 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 Contents of Folder
Each Folder (i.e., Deliverable) is to contain
Management Folder:
a number of Word files discussed ahead
Artifacts 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 Domain Analysis Due: Wednesday 10/4
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;
To support these, a number of models and documents are needed.
Deliverable Artifacts:
The Business Vision Document.
Business Use Case Model
Use Cases and Actors - Modeled
Business Object Model
Use Cases realized with actors and entities for the modeling Use Cases realized with actors for the Use Case Descriptions.
Additional Artifacts
Business Vision document - text Business Glossary - text
Business Rules – text Business Risk List - text
Domain Model - model in Rational Rose (in next deliverable)
Guidance on Deliverable #1 The Vision Document
Use the templates provided. (You may use Requisite Pro. Take the Requisite Pro Quick Tour…)
This is an essential document and should provide a list of
‘features’ that the application to be developed should possess.
These features are not behavioral (like the Use Cases). These are text descriptions. Example of features:
ClassicsCD.com Web Shop Secure payment method.
Easy browsing for available titles.
Ability to check the status of an order.
Customer shall receive e-mail notification.
The catalog shall be highly scaleable to include many titles and effective searching through those titles.
Customer shall be able to customize the Web site.
Customer shall be able to register as a user for future purchases without needing to re-enter personal
information.
Guidance on Deliverable #1 The Business Case
Use the appropriate forms available at:
RUP document templates are located at the site http://jdbv.sourceforge.net/RUP.html.
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 of what they submitted.
Guidance on Deliverable #1 The Business Case
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 should be found in the Use Case View;
This is a single model of the key business processes of the organization.
Business Object Model in the Logical View.
All business object models and the business use case model are to be in a SINGLE copy of Rose.
(See examples on my web page.)
Put your Business Object Models within the Business Object Model folder within Logical View in Rose – see examples on web page.
Business object models are realizations of each of the business use cases and contain business actors. (All domain-oriented)
Deliverable #2 Deliverable #2
Vision Document and Statement of Work Vision Document and Statement of Work
due: October 13th due: October 13th
Develop the Vision Document Develop the Vision Document
Develop the Statement of Work Develop the Statement of Work
Iterate previous deliverable artifacts Iterate previous deliverable artifacts
This means address EACH component and This means address EACH component and fix/repair/enhance/improve, etc. and certify.
fix/repair/enhance/improve, etc. and certify.
Don’t make the same mistakes twice. Don’t make the same mistakes twice.
Add a Statement of Work (SOW), that is, Add a Statement of Work (SOW), that is, what is your team plan – who does what, what is your team plan – who does what,
what is your plan, etc. (See textbook)
what is your plan, etc. (See textbook)
Guidance on Deliverable #2 - Domain Model Guidance on Deliverable #2 - Domain Model
In In additionaddition to standard items, this deliverable requires a complete Domain to standard items, this deliverable requires a complete Domain Model. The Domain Model is essential to understanding the environment Model. The Domain Model is essential to understanding the environment within which the application to be developed will function. Include also a within which the application to be developed will function. Include also a Statement of Work.
Statement of Work.
Turn in CD that contains all models and has links to text descriptions.
Turn in CD that contains all models and has links to text descriptions.
Purpose:
Purpose:
Construct Domain Model (precursor activity to Use Case development)Construct Domain Model (precursor activity to Use Case development)
Is an essential activity to facilitate good use case development that contains glossary items and objects Is an essential activity to facilitate good use case development that contains glossary items and objects from the problem space (domain).
from the problem space (domain).
Deliverable Artifacts for Deliverable #2:
Deliverable Artifacts for Deliverable #2:
Domain Model – taking into consideration additional attributes, multiplicities, associations, Domain Model – taking into consideration additional attributes, multiplicities, associations, etc. The Domain Model should be captured as a
etc. The Domain Model should be captured as a separate folderseparate folder under the Logical View under the Logical View in your Rose Browser.
in your Rose Browser.
Statement of Work - a Word Document. See textbook and/or templates for formatStatement of Work - a Word Document. See textbook and/or templates for format
Other artifacts from Deliverable #1 to be
Other artifacts from Deliverable #1 to be revisited. revisited.
(Exec Summary will
(Exec Summary will cite what changescite what changes you have done to each artifact…) you have done to each artifact…) Business use case model
Business use case model
Use Cases and Actors - Modeled Use Cases and Actors - Modeled Business object model
Business object model
Business Vision document - text Business Vision document - text Business Glossary - text
Business Glossary - text Business Rules - text Business Rules - text
Guidance on Deliverable #2: Domain Model Guidance on Deliverable #2: Domain Model
Be certain to see example link on my web page and study Be certain to see example link on my web page and study
carefully the slides in the appropriate two lectures.
carefully the slides in the appropriate two lectures.
Be certain to fully consider my grading notes to you for Be certain to fully consider my grading notes to you for Deliverable #1 prior to submission of Deliverable #2.
Deliverable #1 prior to submission of Deliverable #2.
For first deliverable or two, the Iteration Plan may be For first deliverable or two, the Iteration Plan may be more ‘descriptive;’ that is, may contain textual
more ‘descriptive;’ that is, may contain textual descriptions. For
descriptions. For
subsequent iterations, plan will be more subsequent iterations, plan will be more cryptic, perhaps bulleted, perhaps tabular.cryptic, perhaps bulleted, perhaps tabular.
Not much verbiage. Activities undertaken, schedule, developers, Not much verbiage. Activities undertaken, schedule, developers, results…
results…
Second Semester Students Second Semester Students
Go to Slide 29 Go to Slide 29
There needs to be a deliverable between There needs to be a deliverable between
deliverables 3 and 4 where the Façade-level use deliverables 3 and 4 where the Façade-level use
case is expanded to include the basic course of case is expanded to include the basic course of events (but not all alternatives and exceptions) events (but not all alternatives and exceptions)
and possibly the activity diagrams or at least and possibly the activity diagrams or at least identification (not expansion) of alternative / identification (not expansion) of alternative /
exceptional threads.
exceptional threads.
This will be added next iteration of this course… This will be added next iteration of this course…
Deliverable #3 - Use Case - Façade Iteration Deliverable #3 - Use Case - Façade Iteration
plus Initial User Interface Prototype plus Initial User Interface Prototype
due: Monday 10/25 due: Monday 10/25
Executive Summary (overviews new artifacts and Executive Summary (overviews new artifacts and ALL changes/revisions to existing artifacts, such as ALL changes/revisions to existing artifacts, such as
the revised Iteration Plan, etc. as required.
the revised Iteration Plan, etc. as required.
Specific Work: Specific Work:
Revisit the Business Case (Deliverables 1 and 2) including Revisit the Business Case (Deliverables 1 and 2) including artifacts listed below and update them. (Risks Lists;
artifacts listed below and update them. (Risks Lists;
Business Rules; Domain Model; Statement of Work, etc.) Business Rules; Domain Model; Statement of Work, etc.)
Include an index (numbered) for Use Cases that Include an index (numbered) for Use Cases that follow. (discussed in class and via slides)
follow. (discussed in class and via slides)
Use Case Index is to contain a number, Use Case name, Use Case Index is to contain a number, Use Case name, short description, and other high level items you consider short description, and other high level items you consider important. Construct this in tabular form using a table in important. Construct this in tabular form using a table in Word. See power point slides for detailed attributes
Word. See power point slides for detailed attributes needed
needed
Guidance on Façade Iteration Guidance on Façade Iteration
Develop an overall Use Case Model (all application Use Develop an overall Use Case Model (all application Use Cases and Actors). Similar to Business Use Case Model.
Cases and Actors). Similar to Business Use Case Model.
Develop Develop Façade Use Case Descriptions Façade Use Case Descriptions and associated Use and associated Case Diagrams for each Use Case. for each Use Case.
Use Rose (Use Case View) for your models. Link the Use Use Rose (Use Case View) for your models. Link the Use Case Description text and ensure these descriptions are on Case Description text and ensure these descriptions are on
the CD you turn in for grading.
the CD you turn in for grading.
CEN 6016 students must use Requisite Pro* CEN 6016 students must use Requisite Pro*
Model your Façade Use Cases using the Kulak and Guiney Model your Façade Use Cases using the Kulak and Guiney book. Again, see power point lectures for
book. Again, see power point lectures for required required attributes
attributes . .
Additional information: Visual Modeling book and Rose Additional information: Visual Modeling book and Rose Basics (see power point lecture slides for examples on Basics (see power point lecture slides for examples on
including your Use Cases in your Rose Model in the Use including your Use Cases in your Rose Model in the Use
Case View.)
Case View.)
Guidance on
Guidance on : Facade Iteration : Facade Iteration
Remember that the Façade iteration names the Remember that the Façade iteration names the use case, identifies actors, provides a short
use case, identifies actors, provides a short description, frequently includes pre- and post description, frequently includes pre- and post
conditions, triggers, etc. But it does NOT conditions, triggers, etc. But it does NOT
include the detailed actor-system interactions.
include the detailed actor-system interactions.
See lecture notes for required attributes. See lecture notes for required attributes.
Must include all Use Cases. Must include all Use Cases.
Include your single Use Case Model in the Use Include your single Use Case Model in the Use Case View (in Rose) in the folder provided by Case View (in Rose) in the folder provided by
Rose. Note: this is NOT the Business Use Case Rose. Note: this is NOT the Business Use Case
Model, which has been completed; more, the Model, which has been completed; more, the
icons are different for the actors and use cases.
icons are different for the actors and use cases.
Be sure to note the differences.
Be sure to note the differences.
Guidance on User Interface Prototype Guidance on User Interface Prototype
Develop User Interface Prototype…needed for Develop User Interface Prototype…needed for
requirements capture!!! Iterate this a as needed.
requirements capture!!! Iterate this a as needed.
(Should be done in conjunction with the Façade Use (Should be done in conjunction with the Façade Use Case and will (together with Domain Model) greatly Case and will (together with Domain Model) greatly
assist you for Deliverable #4, your full-blown Use Case assist you for Deliverable #4, your full-blown Use Case
Descriptions with alternate and exception paths.
Descriptions with alternate and exception paths.
You may use any prototyping tool you wish: VB, Java, You may use any prototyping tool you wish: VB, Java, etc. Your prototype should include storyboarding.
etc. Your prototype should include storyboarding.
Most teams use static html; some use Front Page; some contain Most teams use static html; some use Front Page; some contain Javascript, etc.
Javascript, etc.
Recommend testing your interface with someone from a Recommend testing your interface with someone from a
different group. If you link up with me, I will be glad to assist.
different group. If you link up with me, I will be glad to assist.
To accompany the Façade Use Cases, user interface prototype To accompany the Façade Use Cases, user interface prototype needs to be total complete. While we are not including actor – needs to be total complete. While we are not including actor –
application ‘interchanges,’ these are essential for the next application ‘interchanges,’ these are essential for the next
deliverable.
deliverable.
See examples of initial user interface prototypes on my See examples of initial user interface prototypes on my web page.
web page.
See also (ahead) lecture slides on User Interface Design See also (ahead) lecture slides on User Interface Design
Deliverable #4 Deliverable #4
Full Use Cases Model & Activity Diagrams Full Use Cases Model & Activity Diagrams
due: 11/8 due: 11/8
Executive Summary Executive Summary
Develop Focused and Filled Use Case Descriptions and Develop Focused and Filled Use Case Descriptions and associated Use Case Diagrams for each Use Case.
associated Use Case Diagrams for each Use Case.
Use Rose (Use Case View) and Requisite Pro* Use Rose (Use Case View) and Requisite Pro*
Kulak and Guiney book (Use Cases); Visual Modeling book Kulak and Guiney book (Use Cases); Visual Modeling book and Rose Basics (see power point lecture slides for examples.) and Rose Basics (see power point lecture slides for examples.)
Each Each Use Case is to be accompanied by an Activity Diagram Use Case is to be accompanied by an Activity Diagram that should indicate flow for all paths in the Use Case
that should indicate flow for all paths in the Use Case
*CEN 6016 Students only *CEN 6016 Students only
(Recognize that Use Cases are really never ‘finished.’) (Recognize that Use Cases are really never ‘finished.’)
Your Use Case Diagrams will likely be supplemented with Your Use Case Diagrams will likely be supplemented with
Included or Extended Use Cases, as appropriate. Redo your Included or Extended Use Cases, as appropriate. Redo your
Use Case Model for the Application.
Use Case Model for the Application.
Guidance on Deliverable #4:
Guidance on Deliverable #4:
‘Complete’ Use Case Model
‘Complete’ Use Case Model
Executive Summary – as usual; All on CD.
Executive Summary – as usual; All on CD.
Complete Use Case Model and Use Case Diagrams Complete for for each each Use Use Case –
Case – This is a major assignment This is a major assignment . Consider alternative, . Consider alternative, exception flows, and ‘sub-flows’, using extension points as exception flows, and ‘sub-flows’, using extension points as
appropriate.
appropriate.
Reflect any use cases you feel are ‘included’ or ‘extending.’ Reflect any use cases you feel are ‘included’ or ‘extending.’
Activity Diagrams Activity Diagrams – one per Use Case (should include all – one per Use Case (should include all alternate paths) (Include as package in Rose Model)
alternate paths) (Include as package in Rose Model)
Put Use Cases into groups – packages that ‘seem’ to go Put Use Cases into groups – packages that ‘seem’ to go together functionally, like the GUI or those that address together functionally, like the GUI or those that address
business activities.
business activities.
(These will help in our architecture – as these will become likely (These will help in our architecture – as these will become likely subsystems).
subsystems).
Iterate on the Use Case Model and/or your User Interface Iterate on the Use Case Model and/or your User Interface Prototype (and any other documents) from Deliverable #3 as Prototype (and any other documents) from Deliverable #3 as
appropriate
appropriate
Guidance on Deliverable #4:
Guidance on Deliverable #4:
‘Complete’ Use Case Model
‘Complete’ Use Case Model
Allocate functional requirements to use casesAllocate functional requirements to use cases via the stories of via the stories of
interchange. (and domain objects) This is a painstaking and long task!
interchange. (and domain objects) This is a painstaking and long task!
It will underpin your entire design. Spend time here!!!! Recognize that It will underpin your entire design. Spend time here!!!! Recognize that Use Cases are NOT functional requirements; rather, they are stories of Use Cases are NOT functional requirements; rather, they are stories of
actor-application interactions which contain the required functionality.
actor-application interactions which contain the required functionality.
Requirements with extension points to address alternate and exception Requirements with extension points to address alternate and exception flows. – see class notes.
flows. – see class notes.
AllAll customer functionality should be accounted for here. Be certain to customer functionality should be accounted for here. Be certain to use your Domain Model and italicize or bold all references to entities in use your Domain Model and italicize or bold all references to entities in
the domain model.
the domain model.
Ensure everything the customer desires is accounted for!Ensure everything the customer desires is accounted for!
Keep the alternatives /exceptions WITH the use case. They should Keep the alternatives /exceptions WITH the use case. They should be included with the use case and not made separate. See
be included with the use case and not made separate. See examples on web page.
examples on web page.
Use the Use the User-Interface to ensure all functionality is captured. User-Interface to ensure all functionality is captured.
Develop Activity Diagrams – one Develop Activity Diagrams – one per Use Case – that captures all per Use Case – that captures all paths (scenarios) in a Use Case. See Visual Modeling text for paths (scenarios) in a Use Case. See Visual Modeling text for
examples and use Rose.
examples and use Rose.
Activity Diagrams should be placed in the Use Case View under Use Activity Diagrams should be placed in the Use Case View under Use Case Models in a Folder entitled Activity Diagrams
Case Models in a Folder entitled Activity Diagrams
Deliverable #5 - Developing the Analysis Model Deliverable #5 - Developing the Analysis Model
and Non-Functional Requirements - due 12/01 and Non-Functional Requirements - due 12/01
Analysis Model (Preliminary Design) Analysis Model (Preliminary Design)
Contains communicating Contains communicating boundary, control, entity boundary, control, entity objects with relationships
objects with relationships , etc. , etc.
Will flow from your use case narratives and prototypeWill flow from your use case narratives and prototype
Supports Interaction Modeling and much more…Supports Interaction Modeling and much more…
Designed to lead ultimately to the class model (static)Designed to lead ultimately to the class model (static)
Sources: Use your prototype (boundary) again, Sources: Use your prototype (boundary) again,
domain model (entities), and use case descriptions domain model (entities), and use case descriptions (control) in earnest. They are not enough, but will (control) in earnest. They are not enough, but will
help. See also your Vision Document.
help. See also your Vision Document.
See Visual Modeling See Visual Modeling Book; RUP; Logical View on Rose Book; RUP; Logical View on Rose
Guidance on Deliverable #5 Analysis Model Guidance on Deliverable #5 Analysis Model
Include boundary classes together, control classes Include boundary classes together, control classes together, and entity classes together all without together, and entity classes together all without
associations to other classes. (a one-page drawing) associations to other classes. (a one-page drawing) This should partition all the classes by type. Include This should partition all the classes by type. Include
all attributes / methods with each class, but not all attributes / methods with each class, but not
connectivity.
connectivity.
Follow this with a fully ‘connected’ model – for each Follow this with a fully ‘connected’ model – for each use case.
use case. Use those analysis classes appropriate to the use Use those analysis classes appropriate to the use case and associate the classes.
case and associate the classes.
Be sure to study textbook and lectures on boundary, Be sure to study textbook and lectures on boundary, control, and entity models
control, and entity models
Class structure may be realized with the standard Class structure may be realized with the standard stereotyped
stereotyped classes or the RUP icons classes or the RUP icons
Guidance on Deliverable #5 Analysis Model Guidance on Deliverable #5 Analysis Model
Remember, the validity of the model is simply can I Remember, the validity of the model is simply can I look at any path through a
look at any path through a use case use case and see and see where/which objects will accommodate all the where/which objects will accommodate all the functionality captured in a scenario? Can it be functionality captured in a scenario? Can it be
traced
traced (with your finger...) through the objects as (with your finger...) through the objects as you read through the path description?
you read through the path description?
This is the check to make! This is the check to make! Verify Verify Traceability!!! Traceability!!!
Try to cite as many attributes and methods Try to cite as many attributes and methods
(responsibilities) as possible in the respective class- (responsibilities) as possible in the respective class-
names – boundary, control, and entity.
names – boundary, control, and entity.
Yes, I am after associations, dependencies, etc. Yes, I am after associations, dependencies, etc.
among the classes – as much as practical.
among the classes – as much as practical.
Guidance on Deliverable #5 Analysis Model Guidance on Deliverable #5 Analysis Model
For boundary to control classes, the association line is sufficient, For boundary to control classes, the association line is sufficient, because it cannot be determined what method in control class because it cannot be determined what method in control class
will be invoked from the boundary class unless we consider a will be invoked from the boundary class unless we consider a
specific scenario. Better, though, is a series of boundary classes specific scenario. Better, though, is a series of boundary classes
constituting the interface. See lecture slides for example.
constituting the interface. See lecture slides for example.
Associations among entity classes should have the multiplicities, Associations among entity classes should have the multiplicities, aggregations, dependencies, etc. cited, as usual. They are
aggregations, dependencies, etc. cited, as usual. They are
appropriate here and may come from your domain model, which appropriate here and may come from your domain model, which
will VERY likely need upgrading after/during your exercise.
will VERY likely need upgrading after/during your exercise.
BE CERTAIN to look at the slides on my web site which BE CERTAIN to look at the slides on my web site which
‘supplement’ your readings! There are many examples of the
‘supplement’ your readings! There are many examples of the format you will need for the classes.
format you will need for the classes.
For next time:
For next time:
This Analysis Model assignment should This Analysis Model assignment should include a sequence diagram using the include a sequence diagram using the
analysis classes for each use case.
analysis classes for each use case.
Did not require this in the past – should Did not require this in the past – should have.
have.
Note: 2/9/05Note: 2/9/05
Guidance Deliverable 5: Non-Functional Requirements Guidance Deliverable 5: Non-Functional Requirements
See Use Case Textbook for ‘tables’ See Use Case Textbook for ‘tables’
Small systems: Small systems:
functionality; performance functionality; performance
Large systems: Large systems:
Portability; Maintainability; Scalability; Reliability; Portability; Maintainability; Scalability; Reliability;
Security Security
How about: How about:
Persistence? Persistence?
Will discuss more in class; Remember the Will discuss more in class; Remember the
Supplementary Specifications for Non-Functional Supplementary Specifications for Non-Functional
Requirements.
Requirements.
Thus the Supplementary Specifications Document Thus the Supplementary Specifications Document should be a Word document containing the non- should be a Word document containing the non-
functional ‘tables.’
functional ‘tables.’
Second Semester Deliverables Second Semester Deliverables
(anticipated) (anticipated)
Deliverable #6 – User Interface Design Deliverable #6 – User Interface Design
Deliverable #7 – Layered Architectural Design Deliverable #7 – Layered Architectural Design
Deliverable #8 – Detailed Design - Iteration Planning Deliverable #8 – Detailed Design - Iteration Planning and Use Case Realizations – Context Diagrams
and Use Case Realizations – Context Diagrams only. only.
Deliverable #9 – Subsystem Design – Interaction Deliverable #9 – Subsystem Design – Interaction Diagrams (both) and VOPC diagrams.
Diagrams (both) and VOPC diagrams.
Deliverable #10 –Class Design and Implementation #1; First Deliverable #10 –Class Design and Implementation #1; First Functional Demonstration
Functional Demonstration
Deliverable #11 – Final Deliverable: Complete Deliverable #11 – Final Deliverable: Complete
Implementation Model and Demonstration including client Implementation Model and Demonstration including client
testing.
testing.
Deliverable #6 - User Interface Design Deliverable #6 - User Interface Design
due: Wednesday, 26 January 2005 due: Wednesday, 26 January 2005
Purpose: To design a user interface that reflects Purpose: To design a user interface that reflects application functionality.
application functionality.
This should be a refinement of your initial user This should be a refinement of your initial user
interface prototype based on your further learning interface prototype based on your further learning
about your application.
about your application.
This user interface should demonstrate all required This user interface should demonstrate all required functionality as found in the use cases.
functionality as found in the use cases.
In your presentation, you are to In your presentation, you are to demonstrate demonstrate how how your UI satisfies all Usability Principles as cited in
your UI satisfies all Usability Principles as cited in the lecture slides and your text.
the lecture slides and your text.
Verify your UI by running it against your use cases Verify your UI by running it against your use cases to ensure all functionality is captured.
to ensure all functionality is captured.
Deliverable #6 - User Interface Design Deliverable #6 - User Interface Design
I should be able to access the Deliverable #6 I should be able to access the Deliverable #6 folder on your CD and bring up the UI and
folder on your CD and bring up the UI and execute it successfully.
execute it successfully.
Recognize that some of the windows / displays Recognize that some of the windows / displays will be / may be hard coded and that
will be / may be hard coded and that
demonstrated functionality may not be backed demonstrated functionality may not be backed
up with implemented code or efficient up with implemented code or efficient
algorithms. But the implied functionality must algorithms. But the implied functionality must
be evident.
be evident.
Text caveats in the UI are appropriate. Text caveats in the UI are appropriate.
Deliverable #7 – Layered Architecture Deliverable #7 – Layered Architecture
due: Wed, February 9, 2005 due: Wed, February 9, 2005
Layers: Layers:
You are to design a layered architectural prototype to You are to design a layered architectural prototype to accommodate your application requirements.
accommodate your application requirements.
The The namednamed layers are to consist of major subsystems and layers are to consist of major subsystems and
packages, their contents (other subsystems, packages, etc.). All packages, their contents (other subsystems, packages, etc.). All
component dependencies (coupling) are to be indicated via component dependencies (coupling) are to be indicated via
appropriate UML connectors.
appropriate UML connectors.
The main purpose and The main purpose and suggested contentssuggested contents of each of your of each of your layers must be spelled out in a text-accompanying document.
layers must be spelled out in a text-accompanying document.
(see lecture slides for examples) (see lecture slides for examples)
Your choice (decision) of architectural pattern should be fully Your choice (decision) of architectural pattern should be fully discussed using the eleven design principles; that is, how does discussed using the eleven design principles; that is, how does
your choice support the design principles enumerated upon in your choice support the design principles enumerated upon in the lecture slides and your textbook. (Word document, please) the lecture slides and your textbook. (Word document, please)
Deliverable #7 – Layered Architecture Deliverable #7 – Layered Architecture
Subsystems / Packages.Subsystems / Packages.
For each subsystem, you should provide a single sentence citing the purpose of For each subsystem, you should provide a single sentence citing the purpose of the subsystem (that is, how it ‘coheres’).
the subsystem (that is, how it ‘coheres’).
You should provide a rationale explaining exactly why specific subsystems / You should provide a rationale explaining exactly why specific subsystems / packages were placed in their respective layers; that is, a record of your
packages were placed in their respective layers; that is, a record of your design design decisions
decisions. (Cohesion). (Cohesion)
The detailed contents of the subsystems / packages (subsystems, packages, The detailed contents of the subsystems / packages (subsystems, packages, classes and their associations / dependencies) of each design element should be classes and their associations / dependencies) of each design element should be supplied at this time (cohesion). This means that classes, for example,
supplied at this time (cohesion). This means that classes, for example,
constituting a subsystem or package, must have their properties named and constituting a subsystem or package, must have their properties named and methods (responsibilities) cited – as much as possible.
methods (responsibilities) cited – as much as possible.
You should NOT INCLUDE the detailed description of properties (that is, float, 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 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 / methods nor the algorithms, etc. used by the methods. Only named methods / return items.
return items.
These models should be realized in Rose. Supplement this layered model These models should be realized in Rose. Supplement this layered model separately as needed in Word.
separately as needed in Word.
Deliverable #7 should have the Rose model in a folder with your other Rose Deliverable #7 should have the Rose model in a folder with your other Rose models. Of course, this is merely a significant extension of what you already models. Of course, this is merely a significant extension of what you already have. So, there should be a Rose folder.
have. So, there should be a Rose folder.
Also, all supporting Also, all supporting newnew documents for Deliverable #7 that are associated documents for Deliverable #7 that are associated with
with this deliverablethis deliverable need to be in a folder entitled: Architectural need to be in a folder entitled: Architectural Support Documents, and reside in the Deliverable #7 parent folder.
Support Documents, and reside in the Deliverable #7 parent folder.
Other documents, such as an executive summary, etc. should be separate as Other documents, such as an executive summary, etc. should be separate as
Deliverable #7 – Layered Architecture Deliverable #7 – Layered Architecture
Please note that your architectural modeling Please note that your architectural modeling (layers and their components, etc.) should be (layers and their components, etc.) should be
captured in Rose: Logical View, Design Model, captured in Rose: Logical View, Design Model,
<Layer-Name> Layer.
<Layer-Name> Layer.
The <Layer-Name> Layer has subfolders for The <Layer-Name> Layer has subfolders for packages, subsystems, etc., which you will like packages, subsystems, etc., which you will like
(I hope).
(I hope).
There are mechanisms for, say, a subsystem, to There are mechanisms for, say, a subsystem, to name the subsystem and site the dependencies name the subsystem and site the dependencies
and interfaces related to this subsystem.
and interfaces related to this subsystem.
Approximately what I’d like your deliverable to Approximately what I’d like your deliverable to look like:
look like:
…
…
… Presentation Layer
Application Layer
Middleware Layer
Name each of your layers (probably four…), subsubsystems, packages, classes, etc. etc.
Subsystem name Package Name Subsystem name
Package name
Package name Package name
Subsystem name
Subsystem name Subsystem name
However many
However many
However many
Architectural Layers – the basic idea
… additional layers as you decide.
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.
(name interface)
<<interface>>
Maintain Database
Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc……
Components and Their Interfaces
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/methods 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…
(name interface)
<<interface>>
Maintain Database
Addrec(xxxx, xx) bool UpdateRec(xx, xx) int DeleteREc(xxxxxx) etc……
…
… …
Design Elements in Each Component
1..2
*
Add properties, methods, and anything else that will assist in realizing the interface.
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 XXXX Package
Deliverable #8: Detailed Design - Overview Deliverable #8: Detailed Design - Overview
due: Wednesday, 2 March 2005 due: Wednesday, 2 March 2005
0. Folder with Deliverable #8 on CD. Executive 0. Folder with Deliverable #8 on CD. Executive Summary, as usual.
Summary, as usual.
1. A carefully constructed Iteration Plan. This 1. A carefully constructed Iteration Plan. This now becomes an essential part of your
now becomes an essential part of your
deliverable, as we are about to go into the deliverable, as we are about to go into the
Construction phase.
Construction phase.
2. A sequence diagram and a communications 2. A sequence diagram and a communications diagrams for the basic course of events for each diagrams for the basic course of events for each
of your use cases.
of your use cases.
The sequence diagram is to be fully annotated, as The sequence diagram is to be fully annotated, as shown in lecture slides.
shown in lecture slides.
This is a design-level sequence diagram, so it should This is a design-level sequence diagram, so it should include subsystems via their interfaces; also the
include subsystems via their interfaces; also the persistency mechanism.
persistency mechanism.
Deliverable #8: Detail Design – Iteration Plan Deliverable #8: Detail Design – Iteration Plan
Iteration Plan Iteration Plan
You should sketch out what you feel will be the number of You should sketch out what you feel will be the number of
iterations that will be needed and the features (scenarios) that iterations that will be needed and the features (scenarios) that you will implement in each iteration.
you will implement in each iteration.
Remember! Jump on the scenarios / features that you feel Remember! Jump on the scenarios / features that you feel present to your team the MOST RISK! Secondly, your most present to your team the MOST RISK! Secondly, your most important
important core functionalities core functionalities should be second. should be second.
Map these out into a number of iterations with short duration Map these out into a number of iterations with short duration and stick to the plan. Include dates, scenarios, and
and stick to the plan. Include dates, scenarios, and
responsible developers, expected outcomes, and room for responsible developers, expected outcomes, and room for your iteration assessment - shortcomings (a post mortem).
your iteration assessment - shortcomings (a post mortem).
Use Word or Excel. Include span time dates of iteration!
Use Word or Excel. Include span time dates of iteration!
Your first iteration must be totally understood before you start Your first iteration must be totally understood before you start it and you should have a ‘pretty good idea’ of the specifics of 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 your second. As you finish the first, roll into the second one anything ‘not quite right,’ finalize it before you start this one anything ‘not quite right,’ finalize it before you start this one and map out a ‘pretty good idea’ for the third iteration.
and map out a ‘pretty good idea’ for the third iteration.
Iterate.
Iterate.
Deliverable #8: Detail Design – Iteration Plan Deliverable #8: Detail Design – Iteration Plan
Technology Assessment. Technology Assessment.
Your iteration plan should include your Your iteration plan should include your
preliminary assessment of the technologies that preliminary assessment of the technologies that
you plan to use, where (for what features) you you plan to use, where (for what features) you
plan to use them, sources of knowledge of these plan to use them, sources of knowledge of these
technologies and overall assessment of your technologies and overall assessment of your
team’s familiarities with these technologies.
team’s familiarities with these technologies.
Tell me who knows what and the extent of that Tell me who knows what and the extent of that knowledge.
knowledge.
See examples on my web page . See examples on my web page .
Deliverable #8: Detail Design – Use Case Realizations Deliverable #8: Detail Design – Use Case Realizations
Interaction Diagrams. Interaction Diagrams.
For each Use Case, you are to develop a For each Use Case, you are to develop a
Sequence Diagram in Rose. These should be Sequence Diagram in Rose. These should be
located in the Logical View, Design Package, etc.
located in the Logical View, Design Package, etc.
Check out Use Case Realizations.
Check out Use Case Realizations.
Sequence diagrams are to be fully annotated Sequence diagrams are to be fully annotated and should include subsystem interfaces,
and should include subsystem interfaces, persistency references, etc. as appropriate.
persistency references, etc. as appropriate.
Be certain to look at past examples of sequence Be certain to look at past examples of sequence diagrams in the lecture slides.
diagrams in the lecture slides.
Use the toggle (F5) to generate the Use the toggle (F5) to generate the Communications Diagram.
Communications Diagram.
Deliverable #8: Detail Design – Use Case Realizations Deliverable #8: Detail Design – Use Case Realizations
Class Diagram Class Diagram
For each sequence diagram, you are to produce For each sequence diagram, you are to produce in Rose the VOPC (View of Participating Classes) in Rose the VOPC (View of Participating Classes)
for that sequence diagram.
for that sequence diagram.
Be certain to include all the associations, Be certain to include all the associations, multiplicities, etc. in this class diagram.
multiplicities, etc. in this class diagram.
Some of the details of Deliverable #7 that might Some of the details of Deliverable #7 that might not have gotten ‘finalized’ (the attributes and
not have gotten ‘finalized’ (the attributes and operations of some of the classes) will need to operations of some of the classes) will need to
be finalized at this time.
be finalized at this time.
Deliverable #9 – Detail Design Deliverable #9 – Detail Design
Subsystem Design and Realization – Subsystem Design and Realization –
due: 16 March 2005 due: 16 March 2005
For each subsystem, you are to provide an For each subsystem, you are to provide an interaction interaction diagram
diagram of at least one responsibility accommodated by of at least one responsibility accommodated by the subsystem from its interface. (lecture 32)
the subsystem from its interface. (lecture 32)
No more than one interaction diagram should address No more than one interaction diagram should address
accommodating persistency. You should, however, include one accommodating persistency. You should, however, include one that does this.
that does this.
You should also present the corresponding communications You should also present the corresponding communications (collaboration) diagram. Note the differences.
(collaboration) diagram. Note the differences.
You are also to provide the internal structure of your You are also to provide the internal structure of your
subsystems, like slides 4 and 6 in lecture 33. This is your subsystems, like slides 4 and 6 in lecture 33. This is your VOPC. These are to be fully annotated (dependencies, VOPC. These are to be fully annotated (dependencies, communications, multiplicities, etc.)
communications, multiplicities, etc.)
You are to annotate via stereotyping which objects are You are to annotate via stereotyping which objects are persistent in your modified VOPC as well as any other persistent in your modified VOPC as well as any other stereotyping you feel is necessary in this rendering. (see stereotyping you feel is necessary in this rendering. (see lectures on class design and persistency)
lectures on class design and persistency)
Deliverable #9 – Detail Design Deliverable #9 – Detail Design
Subsystem Design and Realization Subsystem Design and Realization
All messages in your sequence diagrams need to All messages in your sequence diagrams need to be numbered
be numbered as shown as shown in lecture 32 (numbers in lecture 32 (numbers and their sub-parts).
and their sub-parts).
ALL of your design class model elements must ALL of your design class model elements must have the package or subsystem they are
have the package or subsystem they are associated with in with the class header as associated with in with the class header as
shown in lecture 33. Packages and Subsystems shown in lecture 33. Packages and Subsystems should have a stereotype indicating the layer in should have a stereotype indicating the layer in
which they reside.
which they reside.
Sequence Diagrams may require UML Notes to Sequence Diagrams may require UML Notes to clarify interactions. Use them as necessary.
clarify interactions. Use them as necessary.
Deliverable #9 - Questions Deliverable #9 - Questions
What is a proxy class and what is its purpose? What is a proxy class and what is its purpose?
What do we mean by a dependency? What do we mean by a dependency?
What are the pros and cons of dependencies?What are the pros and cons of dependencies?
Under what kind of situation is a subsystem interface Under what kind of situation is a subsystem interface sufficient in a sequence diagram?
sufficient in a sequence diagram?
In behavioral modeling, when must the interface be In behavioral modeling, when must the interface be
realized? How is it done? What kind of model(s) is/are realized? How is it done? What kind of model(s) is/are
used to capture the details of the inner workings of a used to capture the details of the inner workings of a
subsystem?
subsystem?
Why should dependencies on a subsystem be on the Why should dependencies on a subsystem be on the subsystem interface?
subsystem interface?
Turn these in via a separate Word document. Turn these in via a separate Word document.
Deliverable #10 Deliverable #10
Class Design and Implementation #1 Class Design and Implementation #1
due 30 March due 30 March
In addition to Executive Summary, In addition to Executive Summary,
Update your Iteration Plan for remaining iterations Update your Iteration Plan for remaining iterations based on your assessment of the previous iterations.
based on your assessment of the previous iterations.
Document that assessment as part of the Iteration Document that assessment as part of the Iteration Plan (may use Word)
Plan (may use Word)
This may likely be a few paragraphs. Don’t wimp out on this!This may likely be a few paragraphs. Don’t wimp out on this!
Ensure all methods in your Use Case Realizations have Ensure all methods in your Use Case Realizations have full signatures in their calling sequences.
full signatures in their calling sequences.
Using Rose, ensure your classes and attributes are all Using Rose, ensure your classes and attributes are all correct by revising your VOPCs ensuring that all
correct by revising your VOPCs ensuring that all
connections are either associations or dependencies.
connections are either associations or dependencies.
This can be shown by clicking on objects across the top of This can be shown by clicking on objects across the top of sequence diagrams and filling in the window specifications.
sequence diagrams and filling in the window specifications.
Deliverable #10 Deliverable #10
Class Design and Implementation #1 Class Design and Implementation #1
due 30 March due 30 March
Document Document how how your Use Cases drove your Use Cases drove your iteration plan and development.
your iteration plan and development.
Document Document how how your architecture assisted your architecture assisted (was central) in your development.
(was central) in your development.
Demonstrate and Discuss your (first and) Demonstrate and Discuss your (first and) second Iteration
second Iteration in class (possibly) in class (possibly)
(not formal; 15 minutes per team) (not formal; 15 minutes per team)
Deliverable #10 Deliverable #10
Class Design and Implementation #1 Class Design and Implementation #1
due 30 March due 30 March
You are to include your source-level components. These You are to include your source-level components. These need to be organized ‘by design unit’ (that is, package, need to be organized ‘by design unit’ (that is, package,
subsystem), ‘by component’ (within these higher level subsystem), ‘by component’ (within these higher level
components). Read documentation section of components). Read documentation section of
Component View in Rose.
Component View in Rose.
Please note: Your source code absolutely must be Please note: Your source code absolutely must be internally documented with meaningful, guiding
internally documented with meaningful, guiding
comments. These will be reviewed very carefully!!!
comments. These will be reviewed very carefully!!!
So, your organization should be Component View, So, your organization should be Component View, Implementation Model, Package or Subsystem, and Implementation Model, Package or Subsystem, and
specific component within the owning package or specific component within the owning package or
subsystem.
subsystem.
Deliverable #11 – Final Deliverable #11 – Final
Testing and Demonstration Testing and Demonstration
This deliverable is a chance to This deliverable is a chance to finalize finalize any any shortcomings in your Iteration Plans, Rose shortcomings in your Iteration Plans, Rose
Models, or any design models/artifacts you have Models, or any design models/artifacts you have
undertaken.
undertaken.
ALL ALL code code is to be fully documented and is to be fully documented and
submitted in folders “by type,” that means jsp submitted in folders “by type,” that means jsp
files together, .java files together, servlets, …etc.
files together, .java files together, servlets, …etc.
