ProjectProject DeliverablesDeliverables

Version 1: 08/30/2005

Note: This document contains the deliverables for a two semester course.

These items WILL change as the courses progress.

Overview of GuidanceOverview 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 DeliverablesFormat 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 aheadArtifacts Folder

Contents discussed ahead.

Management FolderDocuments

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 FolderDocuments

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 FolderDocuments

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 #1Deliverable #1

Business Modeling(Domain Analysis)

Deliverable #1 Business ModelingBusiness 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;

Deliverable 1 – Business ModelDomain 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.

Business Vision DocumentGuidance

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 Guidance

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 Case ModelGuidance with Rose

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.

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, ….

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.

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 #2Deliverable #2

Domain ModelThe Vision Document -

ApplicationStatement of Work

Deliverable #2 - Artifacts Purpose: Develop Key Artifacts. (Inception Phase) Address all items in Management Folder. 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).

Build a Vision Document for the Application to be developed.

Will include User Needs and Features Develop a Statement of Work – assigning responsibilities to different roles to be accommodated on

the team. Review / upgrade previous artifacts.

Business Use Case Model

Use Cases and Actors - Modeled

Business Vision document - text

Business Glossary - text

Business Rules - text

Domain Model - GuidanceDomain 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 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.

The Vision Document This represents the vision for the application you will

be developing. An essential artifact. Use the template provided. Modify items as need. (Software Quality Analyst on your team will learn/use

Requisite Pro. Take the Requisite Pro Quick Tour…) One other team members should be conversant.

Needs and Features: This essential document and should provide a

capturing of ‘user needs.’ These “needs” will be mapped into “features” which

will be later traced into use cases in the form of functional requirements.

Be sure to review the link on my web page to ‘Great Article…..’ Gives very valuable information (not found in your books) on needs, features, use cases.

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.

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.

Statement of Work

My 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)

Second Semester StudentsSecond Semester StudentsGo to Slide 29Go 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-deliverables 3 and 4 where the Façade-level use case is expanded to include the level use case is expanded to include the basic course of events (but not all basic course of events (but not all alternatives and exceptions) and possibly alternatives and exceptions) and possibly the activity diagrams or at least the activity diagrams or at least identification (not expansion) of identification (not expansion) of alternative / exceptional threads. alternative / exceptional threads.

This will be added next iteration of this This will be added next iteration of this course…course…

Deliverable #3 - Use Case - Façade Deliverable #3 - Use Case - Façade Iteration plus Initial User Interface Iteration plus Initial User Interface

Prototype Prototype due: Monday 10/25due: Monday 10/25

Executive Summary (overviews new artifacts Executive Summary (overviews new artifacts and ALL changes/revisions to existing artifacts, and ALL changes/revisions to existing artifacts, such as the revised Iteration Plan, etc. as such as the revised Iteration Plan, etc. as required.required.

Specific Work:Specific Work: Revisit the Business Case (Deliverables 1 and 2) Revisit the Business Case (Deliverables 1 and 2)

including artifacts listed below and update them. including artifacts listed below and update them. (Risks Lists; Business Rules; especially the (Risks Lists; Business Rules; especially the Domain Domain ModelModel; Statement of Work, etc.); Statement of Work, etc.)

Include an index (numbered) for Use Cases Include an index (numbered) for Use Cases that follow. (discussed in class and via slides)that follow. (discussed in class and via slides) Use Case Index is to contain a number, Use Case Use Case Index is to contain a number, Use Case

name, short description, and other high level items name, short description, and other high level items you consider important. Construct this in tabular you consider important. Construct this in tabular form using a table in Word. See power point slides form using a table in Word. See power point slides for detailed attributes neededfor detailed attributes needed

Guidance on Façade Guidance on Façade IterationIteration

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 Cases and Actors). Similar to Business Use Case Model.Model.

Develop Develop Façade Use Case DescriptionsFaçade Use Case Descriptions and associated and associated Use Case Diagrams for each Use Case. for each Use Case.

Use Rose (Use Case View) for your models. Link the Use Rose (Use Case View) for your models. Link the Use Case Description text and ensure these Use Case Description text and ensure these descriptions are on the CD you turn in for grading. descriptions are on 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 Model your Façade Use Cases using the Kulak and

Guiney book. Again, see power point lectures for Guiney book. Again, see power point lectures for required attributesrequired attributes. See examples of ‘reasonable’ . See examples of ‘reasonable’ student Use Cases examples posted on my web page.student Use Cases examples posted on my web page.

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 onGuidance on: Facade Iteration: Facade Iteration

Remember that the Façade iteration names Remember that the Façade iteration names the use case, identifies actors, provides a the use case, identifies actors, provides a short description, frequently includes pre- and short description, frequently includes pre- and post conditions, triggers, etc. But it does NOT post 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 Rose. Note: this is NOT the Business Use Case Model, which has been completed; Case Model, which has been completed; more, the icons are different for the actors more, the icons are different for the actors and use cases. Be sure to note the and use cases. Be sure to note the differences.differences.

Guidance on User Interface PrototypeGuidance 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 Most teams use static html; some use Front Page; some

contain Javascript, etc.contain 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 To accompany the Façade Use Cases, user interface

prototype needs to be total complete. While we are not prototype needs to be total complete. While we are not including actor – application ‘interchanges,’ these are including actor – application ‘interchanges,’ these are essential for the next deliverable. essential for the next deliverable.

See examples of initial user interface prototypes on See examples of initial user interface prototypes on my web page.my web page.

See also (ahead) lecture slides on User Interface See also (ahead) lecture slides on User Interface DesignDesign

Deliverable #4Deliverable #4Full Use Cases Model & Activity Full Use Cases Model & Activity

DiagramsDiagramsdue: 11/8due: 11/8

Executive SummaryExecutive 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 and Rose Basics (see power point lecture slides for examples.)examples.)

EachEach Use Case is to be accompanied by an Activity Use Case is to be accompanied by an Activity Diagram that should indicate flow for all paths in the Use Diagram that should indicate flow for all paths in the Use CaseCase

*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 Included or Extended Use Cases, as appropriate. Redo your Use Case Model for the Application.your 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 Complete Use Case Model and Use Case Diagrams for for

eacheach Use Case – Use Case – This is a major assignmentThis is a major assignment. Consider . Consider alternative, exception flows, and ‘sub-flows’, using alternative, exception flows, and ‘sub-flows’, using extension points as appropriate.extension points as appropriate.

Reflect any use cases you feel are ‘included’ or Reflect any use cases you feel are ‘included’ or ‘extending.’ ‘extending.’

Activity DiagramsActivity Diagrams – one per Use Case (should include – one per Use Case (should include all alternate paths) (Include as package in Rose Model)all 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 (These will help in our architecture – as these will become

likely subsystems).likely subsystems). Iterate on the Use Case Model and/or your User Iterate on the Use Case Model and/or your User

Interface Prototype (and any other documents) from Interface Prototype (and any other documents) from Deliverable #3 as appropriateDeliverable #3 as 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 interchange. (and domain objects) This is a painstaking and long task! It will underpin your entire design. Spend time long task! It will underpin your entire design. Spend time here!!!! Recognize that Use Cases are NOT functional here!!!! Recognize that Use Cases are NOT functional requirements; rather, they are stories of actor-application requirements; rather, they are stories of actor-application interactions which contain the required functionality.interactions which contain the required functionality.

Requirements with extension points to address alternate and Requirements with extension points to address alternate and exception flows. – see class notes.exception flows. – see class notes.

AllAll customer functionality should be accounted for here. Be customer functionality should be accounted for here. Be certain to use your Domain Model and italicize or bold all certain to use your Domain Model and italicize or bold all references to entities in the domain model.references to entities in 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 Keep the alternatives /exceptions WITH the use case. They should be included with the use case and not made should be included with the use case and not made separate. See examples on web page.separate. See examples on web page.

Use the Use the User-Interface to ensure all functionality is User-Interface to ensure all functionality is captured. captured.

Develop Activity Diagrams – one Develop Activity Diagrams – one perper Use Case – that Use Case – that captures all paths (scenarios) in a Use Case. See Visual captures all paths (scenarios) in a Use Case. See Visual Modeling text for examples and use Rose.Modeling text for examples and use Rose.

Activity Diagrams should be placed in the Use Case View Activity Diagrams should be placed in the Use Case View under Use Case Models in a Folder entitled Activity under Use Case Models in a Folder entitled Activity DiagramsDiagrams

Deliverable #5 - Developing the Analysis Deliverable #5 - Developing the Analysis Model and Non-Functional Requirements - Model and Non-Functional Requirements - due 12/01due 12/01 Analysis Model (Preliminary Design)Analysis Model (Preliminary Design)

Contains communicating Contains communicating boundary, control, entity boundary, control, entity objects with relationshipsobjects 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 domain model (entities), and use case descriptions (control) in earnest. They are not descriptions (control) in earnest. They are not enough, but will help. See also your Vision enough, but will help. See also your Vision Document.Document. See Visual ModelingSee Visual Modeling Book; RUP; Logical View on RoseBook; RUP; Logical View on Rose

Guidance on Deliverable #5 Analysis Guidance on Deliverable #5 Analysis ModelModel

Include boundary classes together, control Include boundary classes together, control classes together, and entity classes together all classes together, and entity classes together all without associations to other classes. (a one-without associations to other classes. (a one-page drawing) This should partition all the page drawing) This should partition all the classes by type. Include all attributes / methods classes by type. Include all attributes / methods with each class, but not connectivity.with each class, but not connectivity.

Follow this with a fully ‘connected’ model – for Follow this with a fully ‘connected’ model – for each use case.each use case. Use those analysis classes Use those analysis classes appropriate to the use case and associate the classes.appropriate to the use case and associate the classes.

Be sure to study textbook and lectures on Be sure to study textbook and lectures on boundary, control, and entity models boundary, control, and entity models

Class structure may be realized with the Class structure may be realized with the standard standard stereotypedstereotyped classes or the RUP icons classes or the RUP icons

Guidance on Deliverable #5 Analysis Guidance on Deliverable #5 Analysis ModelModel

Remember, the validity of the model is simply Remember, the validity of the model is simply can I look at any path through a can I look at any path through a use caseuse case and and see where/which objects will accommodate all see where/which objects will accommodate all the functionality captured in a scenario? Can it the functionality captured in a scenario? Can it be be tracedtraced (with your finger...) through the (with your finger...) through the objects as you read through the path objects as you read through the path description? description?

This is the check to make! This is the check to make! VerifyVerify Traceability!!!Traceability!!! Try to cite as many attributes and methods Try to cite as many attributes and methods

(responsibilities) as possible in the respective (responsibilities) as possible in the respective class-names – boundary, control, and entity. class-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 Guidance on Deliverable #5 Analysis ModelModel

For boundary to control classes, the association line is For boundary to control classes, the association line is sufficient, because it cannot be determined what method sufficient, because it cannot be determined what method in control class will be invoked from the boundary class in control class will be invoked from the boundary class unless we consider a specific scenario. Better, though, is unless we consider a specific scenario. Better, though, is a series of boundary classes constituting the interface. a series of boundary classes constituting the interface. See lecture slides for example. See lecture slides for example.

Associations among entity classes should have the Associations among entity classes should have the multiplicities, aggregations, dependencies, etc. cited, as multiplicities, aggregations, dependencies, etc. cited, as usual. They are appropriate here and may come from usual. They are appropriate here and may come from your domain model, which will VERY likely need your domain model, which will VERY likely need upgrading after/during your exercise. 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 ‘supplement’ your readings! There are many examples of the format you will need for the classes.of the format you will need for the classes.

For next time:For next time:

This Analysis Model assignment This Analysis Model assignment should include a sequence diagram should include a sequence diagram using the analysis classes for each using the analysis classes for each use case.use case.

Did not require this in the past – Did not require this in the past – should have. should have.

Note: 2/9/05Note: 2/9/05

Guidance Deliverable 5: Non-Functional Guidance Deliverable 5: Non-Functional RequirementsRequirements

See Use Case Textbook for ‘tables’See Use Case Textbook for ‘tables’ Small systems: Small systems:

functionality; performancefunctionality; 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-Supplementary Specifications for Non-Functional Requirements.Functional Requirements.

Thus the Supplementary Specifications Thus the Supplementary Specifications Document should be a Word document Document should be a Word document containing the non-functional ‘tables.’containing the non-functional ‘tables.’

Second Semester DeliverablesSecond Semester Deliverables(anticipated)(anticipated)

Deliverable #6 – User Interface DesignDeliverable #6 – User Interface Design Deliverable #7 – Layered Architectural DesignDeliverable #7 – Layered Architectural Design Deliverable #8 – Detailed Design - Iteration PlanningDeliverable #8 – Detailed Design - Iteration Planning

and Use Case Realizations – Context Diagrams and Use Case Realizations – Context Diagrams only. only.

Deliverable #9 – Subsystem Design – InteractionDeliverable #9 – Subsystem Design – InteractionDiagrams (both) and VOPC diagrams. Diagrams (both) and VOPC diagrams.

Deliverable #10 –Class Design and Implementation Deliverable #10 –Class Design and Implementation #1; First Functional Demonstration#1; First Functional Demonstration

Deliverable #11 – Final Deliverable: CompleteDeliverable #11 – Final Deliverable: CompleteImplementation Model and Demonstration including Implementation Model and Demonstration including client testing. client testing.

Deliverable #6 - User Interface Deliverable #6 - User Interface DesignDesign

due: Wednesday, 26 January 2005due: 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 interface prototype based on your further learning about your application.learning about your application.

This user interface should demonstrate all This user interface should demonstrate all required functionality as found in the use required functionality as found in the use cases.cases.

In your presentation, you are to In your presentation, you are to demonstratedemonstrate how your UI satisfies all Usability Principles as how your UI satisfies all Usability Principles as cited in the lecture slides and your text.cited in the lecture slides and your text.

Verify your UI by running it against your use Verify your UI by running it against your use cases to ensure all functionality is captured. cases to ensure all functionality is captured.

Deliverable #6 - User Interface Deliverable #6 - User Interface DesignDesign

I should be able to access the Deliverable I should be able to access the Deliverable #6 folder on your CD and bring up the UI #6 folder on your CD and bring up the UI and execute it successfully.and execute it successfully.

Recognize that some of the windows / Recognize that some of the windows / displays will be / may be hard coded and displays will be / may be hard coded and that demonstrated functionality may not that demonstrated functionality may not be backed up with implemented code or be backed up with implemented code or efficient algorithms. But the implied efficient algorithms. But the implied functionality must be evident.functionality must be evident.

Text caveats in the UI are appropriate.Text caveats in the UI are appropriate.

Deliverable #7 – Layered Deliverable #7 – Layered Architecture due: Wed, February 9, Architecture due: Wed, February 9,

20052005 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 layers are to consist of major subsystems and packages, their contents (other subsystems, and packages, their contents (other subsystems, packages, etc.). All component dependencies (coupling) packages, etc.). All component dependencies (coupling) are to be indicated via appropriate UML connectors. are to be indicated via appropriate UML connectors.

The main purpose and The main purpose and suggested contentssuggested contents of each of of each of your layers must be spelled out in a text-accompanying your layers must be spelled out in a text-accompanying document. (see lecture slides for examples)document. (see lecture slides for examples)

Your choice (decision) of architectural pattern should be Your choice (decision) of architectural pattern should be fully discussed using the eleven design principles; that fully discussed using the eleven design principles; that is, how does your choice support the design principles is, how does your choice support the design principles enumerated upon in the lecture slides and your enumerated upon in the lecture slides and your textbook. (Word document, please)textbook. (Word document, please)

Deliverable #7 – Layered Deliverable #7 – Layered ArchitectureArchitecture

Subsystems / Packages.Subsystems / Packages. For each subsystem, you should provide a single sentence citing the For each subsystem, you should provide a single sentence citing the

purpose of the subsystem (that is, how it ‘coheres’). purpose of the subsystem (that is, how it ‘coheres’). You should provide a rationale explaining exactly why specific You should provide a rationale explaining exactly why specific

subsystems / packages were placed in their respective layers; that is, a subsystems / packages were placed in their respective layers; that is, a record of your record of your design decisionsdesign decisions. (Cohesion). (Cohesion)

The detailed contents of the subsystems / packages (subsystems, The detailed contents of the subsystems / packages (subsystems, packages, classes and their associations / dependencies) of each design packages, classes and their associations / dependencies) of each design element should be supplied at this time (cohesion). This means that element should be supplied at this time (cohesion). This means that classes, for example, constituting a subsystem or package, must have classes, for example, constituting a subsystem or package, must have their properties named and methods (responsibilities) cited – as much as their properties named and methods (responsibilities) cited – as much as possible. possible.

You should NOT INCLUDE the detailed description of properties (that is, You should NOT INCLUDE the detailed description of properties (that is, float, char, integer, String, etc.) nor the number and types of parameters float, char, integer, String, etc.) nor the number and types of parameters for the methods nor the algorithms, etc. used by the methods. Only for the methods nor the algorithms, etc. used by the methods. Only named methods / return items.named methods / return items.

These models should be realized in Rose. Supplement this layered These models should be realized in Rose. Supplement this layered model separately as needed in Word.model separately as needed in Word.

Deliverable #7 should have the Rose model in a folder with your other 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 Rose models. Of course, this is merely a significant extension of what you already have. So, there should be a Rose folder.you already have. So, there should be a Rose folder.

Also, all supporting Also, all supporting newnew documents for Deliverable #7 that are documents for Deliverable #7 that are associated with associated with this deliverablethis deliverable need to be in a folder entitled: need to be in a folder entitled: Architectural Support Documents, and reside in the Deliverable #7 Architectural Support Documents, and reside in the Deliverable #7 parent folder.parent folder.

Other documents, such as an executive summary, etc. should be Other documents, such as an executive summary, etc. should be separate as usual.separate as usual.

Deliverable #7 – Layered Deliverable #7 – Layered ArchitectureArchitecture

Please note that your architectural Please note that your architectural modeling (layers and their components, modeling (layers and their components, etc.) should be captured in Rose: Logical etc.) should be captured in Rose: Logical View, Design Model, <Layer-Name> Layer.View, Design Model, <Layer-Name> Layer.

The <Layer-Name> Layer has subfolders The <Layer-Name> Layer has subfolders for packages, subsystems, etc., which you for packages, subsystems, etc., which you will like (I hope).will like (I hope).

There are mechanisms for, say, a There are mechanisms for, say, a subsystem, to name the subsystem and subsystem, to name the subsystem and site the dependencies and interfaces site the dependencies and interfaces related to this subsystem.related to this subsystem.

Approximately what I’d like your Approximately what I’d like your deliverable to look like:deliverable to look like:

…

…

…

Presentation Layer

Application Layer

Middleware Layer

Name each of your layers (probably four…), subsubsystems, packages, classes, etc. etc.

See next page.

Subsystem name Package Name Subsystem name

Package name

Package name

Package nameSubsystem 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) boolUpdateRec(xx, xx) intDeleteREc(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) boolUpdateRec(xx, xx) intDeleteREc(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 objects and dependencies.

XXXX Package

Deliverable #8: Detailed Design - OverviewDeliverable #8: Detailed Design - Overview due: Wednesday, 2 March 2005 due: Wednesday, 2 March 2005

0. Folder with Deliverable #8 on CD. 0. Folder with Deliverable #8 on CD. Executive Summary, as usual.Executive Summary, as usual.

1. A carefully constructed Iteration Plan. 1. A carefully constructed Iteration Plan. This now becomes an essential part of This now becomes an essential part of your deliverable, as we are about to go your deliverable, as we are about to go into the Construction phase.into the Construction phase.

2. A sequence diagram and a 2. A sequence diagram and a communications diagrams for the basic communications diagrams for the basic course of events for each of your use course of events for each of your use cases. cases. The sequence diagram is to be fully annotated, The sequence diagram is to be fully annotated,

as shown in lecture slides.as shown in lecture slides. This is a design-level sequence diagram, so it This is a design-level sequence diagram, so it

should include subsystems via their interfaces; should include subsystems via their interfaces; also the persistency mechanism.also the persistency mechanism.

Deliverable #8: Detail Design – Iteration Deliverable #8: Detail Design – Iteration PlanPlan

Iteration PlanIteration Plan You should sketch out what you feel will be the number You should sketch out what you feel will be the number

of iterations that will be needed and the features of iterations that will be needed and the features (scenarios) that you will implement in each iteration.(scenarios) that you will implement in each iteration.

Remember! Jump on the scenarios / features that you Remember! Jump on the scenarios / features that you feel present to your team the MOST RISK! Secondly, your feel present to your team the MOST RISK! Secondly, your most important most important core functionalitiescore functionalities should be second. should be second.

Map these out into a number of iterations with short Map these out into a number of iterations with short duration and stick to the plan. Include dates, scenarios, duration and stick to the plan. Include dates, scenarios, and responsible developers, expected outcomes, and and responsible developers, expected outcomes, and room for your iteration assessment - shortcomings (a room for your iteration assessment - shortcomings (a post mortem). Use Word or Excel. Include span time post mortem). Use Word or Excel. Include span time dates of iteration!dates of iteration!

Your first iteration must be totally understood before you Your first iteration must be totally understood before you start it and you should have a ‘pretty good idea’ of the start it and you should have a ‘pretty good idea’ of the specifics of your second. As you finish the first, roll into specifics of your second. As you finish the first, roll into the second one anything ‘not quite right,’ finalize it the second one anything ‘not quite right,’ finalize it before you start this one and map out a ‘pretty good before you start this one and map out a ‘pretty good idea’ for the third iteration. Iterate.idea’ for the third iteration. Iterate.

Deliverable #8: Detail Design – Iteration Deliverable #8: Detail Design – Iteration PlanPlan

Technology Assessment.Technology Assessment. Your iteration plan should include your Your iteration plan should include your

preliminary assessment of the technologies preliminary assessment of the technologies that you plan to use, where (for what that you plan to use, where (for what features) you plan to use them, sources of features) you plan to use them, sources of knowledge of these technologies and overall knowledge of these technologies and overall assessment of your team’s familiarities with assessment of your team’s familiarities with these technologies.these technologies.

Tell me who knows what and the extent of Tell me who knows what and the extent of that knowledge.that knowledge.

See examples on my web page .See examples on my web page .

Deliverable #8: Detail Design – Use Case Deliverable #8: Detail Design – Use Case RealizationsRealizations

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, located in the Logical View, Design Package, etc. Check out Use Case Realizations.etc. 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 Be certain to look at past examples of sequence diagrams in the lecture slides.sequence 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 Deliverable #8: Detail Design – Use Case RealizationsRealizations

Class DiagramClass Diagram For each sequence diagram, you are to For each sequence diagram, you are to

produce in Rose the VOPC (View of produce in Rose the VOPC (View of Participating Classes) for that sequence Participating Classes) for that sequence diagram. 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 Some of the details of Deliverable #7 that might not have gotten ‘finalized’ (the might not have gotten ‘finalized’ (the attributes and operations of some of the attributes and operations of some of the classes) will need to be finalized at this time.classes) will need to be finalized at this time.

Deliverable #9 – Detail DesignDeliverable #9 – Detail DesignSubsystem Design and Realization – Subsystem Design and Realization –

due: 16 March 2005due: 16 March 2005 For each subsystem, you are to provide an For each subsystem, you are to provide an interaction interaction

diagramdiagram of at least one responsibility accommodated of at least one responsibility accommodated by the subsystem from its interface. (lecture 32)by 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 accommodating persistency. You should, however, include one that does this.one 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 subsystems, like slides 4 and 6 in lecture 33. This is your VOPC. These are to be fully annotated your VOPC. These are to be fully annotated (dependencies, communications, multiplicities, etc.)(dependencies, communications, multiplicities, etc.)

You are to annotate via stereotyping which objects You are to annotate via stereotyping which objects are persistent in your modified VOPC as well as any are persistent in your modified VOPC as well as any other stereotyping you feel is necessary in this other stereotyping you feel is necessary in this rendering. (see lectures on class design and rendering. (see lectures on class design and persistency)persistency)

Deliverable #9 – Detail DesignDeliverable #9 – Detail DesignSubsystem Design and Realization Subsystem Design and Realization

All messages in your sequence diagrams All messages in your sequence diagrams need to be numbered need to be numbered as shownas shown in lecture in lecture 32 (numbers and their sub-parts).32 (numbers and their sub-parts).

ALL of your design class model elements ALL of your design class model elements must have the package or subsystem they must have the package or subsystem they are associated with in with the class header are associated with in with the class header as shown in lecture 33. Packages and as shown in lecture 33. Packages and Subsystems should have a stereotype Subsystems should have a stereotype indicating the layer in which they reside.indicating the layer in which they reside.

Sequence Diagrams may require UML Notes Sequence Diagrams may require UML Notes to clarify interactions. Use them as to clarify interactions. Use them as necessary.necessary.

Deliverable #9 - QuestionsDeliverable #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 Under what kind of situation is a subsystem

interface sufficient in a sequence diagram?interface 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) realized? How is it done? What kind of model(s) is/are used to capture the details of the inner is/are used to capture the details of the inner workings of a subsystem?workings of a subsystem?

Why should dependencies on a subsystem be on Why should dependencies on a subsystem be on the subsystem interface?the subsystem interface?

Turn these in via a separate Word document.Turn these in via a separate Word document.

Deliverable #10Deliverable #10Class Design and Implementation Class Design and Implementation

#1 due 30 March#1 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 Ensure all methods in your Use Case Realizations have full signatures in their calling sequences.have full signatures in their calling sequences.

Using Rose, ensure your classes and attributes are Using Rose, ensure your classes and attributes are all correct by revising your VOPCs ensuring that all 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 This can be shown by clicking on objects across the top of sequence diagrams and filling in the window top of sequence diagrams and filling in the window specifications.specifications.

Deliverable #10Deliverable #10Class Design and Implementation Class Design and Implementation

#1 due 30 March#1 due 30 March Document Document howhow your Use Cases drove your Use Cases drove

your iteration plan and development.your iteration plan and development. Document Document howhow your architecture your architecture

assisted (was central) in your assisted (was central) in your development.development.

Demonstrate and Discuss your (first and) Demonstrate and Discuss your (first and) second Iterationsecond Iteration in class (possibly) in class (possibly) (not formal; 15 minutes per team)(not formal; 15 minutes per team)

Deliverable #10Deliverable #10Class Design and Implementation Class Design and Implementation

#1 due 30 March#1 due 30 March You are to include your source-level components. You are to include your source-level components.

These need to be organized ‘by design unit’ (that These need to be organized ‘by design unit’ (that is, package, subsystem), ‘by component’ (within is, package, subsystem), ‘by component’ (within these higher level components). Read these higher level components). Read documentation section of Component View in Rose.documentation section of Component View in Rose.

Please note: Your source code absolutely must Please note: Your source code absolutely must be internally documented with meaningful, guiding be internally documented with meaningful, guiding comments. These will be reviewed very comments. These will be reviewed very carefully!!!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 – FinalDeliverable #11 – FinalTesting and DemonstrationTesting and Demonstration

This deliverable is a chance to This deliverable is a chance to finalizefinalize any shortcomings in your Iteration Plans, any shortcomings in your Iteration Plans, Rose Models, or any design Rose Models, or any design models/artifacts you have undertaken.models/artifacts you have undertaken.

ALL ALL codecode is to be fully documented and is to be fully documented and submitted in folders “by type,” that means submitted in folders “by type,” that means jsp files together, .java files together, jsp files together, .java files together, servlets, …etc.servlets, …etc.

There will NOT be a separate test plan There will NOT be a separate test plan document required, as originally planned. document required, as originally planned.

Deliverable #11 – FinalDeliverable #11 – FinalTesting and DemonstrationTesting and Demonstration

On the day you are demonstrating your projects, On the day you are demonstrating your projects, you are to provide to me a hardcopy of your use you are to provide to me a hardcopy of your use cases. I will arbitrarily select one or two for you cases. I will arbitrarily select one or two for you to demonstrate during class. to demonstrate during class.

You may also be asked some general questions.You may also be asked some general questions. Your demonstration, etc. should not last beyond Your demonstration, etc. should not last beyond

thirty minutes.thirty minutes. If you need separate computer support, you If you need separate computer support, you

should plan to go to class early to set up / should plan to go to class early to set up / connect to whatever you need.connect to whatever you need.

Good luck and have fun!Good luck and have fun!