Due in Class on November 19 with Presentations November 19 and 21

Assignment Requirements

Purpose and Content

The design document should also be an evolving document, or a living document.  You should begin by documenting the conceptual model of your system.  As you continue working, this model will be refined to include more detail, and some things will change.  By the time you turn in your design document, it should contain a reasonably accurate description of your final system.  You will also be asked to turn in a final version of the document at the end of the quarter that will include changes made to the requirements and design during the later stages of implementation.

The design document will consist of the following sections.  Sections 1-4 and 8-13 are updates of what you turned in for the Requirements Document.  The remaining sections, 5-7 and 14, are new to the Design Document.

1. Title Page
2. Summary
3. Glossary
4. Use Cases, Scenarios, Mock-up's

(whichever you focused on in Assignment 2)
 
 
 
5. Architecture Overview
• Architectural Style

What style of architecture did you adopt? Provide a reference to a defining document.

Shaw and Garlan (in Software architecture: perspectives on an emerging discipline) have identified the following list of architectural styles:

  1.Data Flow Style
        Batch Sequential
        Pipes and Filters
  2.Call and Return Style
        Main Program and Subroutines
        Hierarchical layers
        Object-oriented (client/server)
  3.Independent Components
        Communicating processes
        Event systems
  4.Virtual Machines
        Rule-based systems
        Interpreters
  5.Data-Centered Systems
        Transactional Database Systems
        Blackboard Systems
 

• System Architecture Overview

Others find that UML provides a sufficient architecture specification, but requires more than class diagrams.
This is the place for your "one great diagram" that shows how your system is built. You might want to use more than one diagram, to show, e.g., some different abstractions of the design (such as a data flow view, a layers of abstraction view, an object view, or an OS process view)

• Subsystem Narrative

What each subsystem means
• Major limitations on the current design
6. Modules Specification
• List of Modules within your system
• For each module, provide a Module Specification
• Name
• Definition/Purpose - what it is/does
• Narrative/Comment - how it works
• What are the interfaces or APIs? E.g., using Java terminology

public
private
protected
• Data - What state does it keep, what variables?
• Access - Who has access to the module/object/data?
• How does it fit into the inheritance/with/uses heirarchy?
• Constraints - what constraints are there for this object/module?
• Cardinality - How many will there be?
7. Team Specific diagrams

See your TA but likely notations include Entity-Relationship (ER) Diagrams for database projects, UML Sequence Diagrams for client-server applications, ontologies for knowledge-based projects, etc.
8. Deliverables
9. Delivery Platform
10. Terms and Authorization
11. Development Platform.
12. Milestones and Effort
13. Acceptance Test Plan

To be more specific in the update of your Acceptance Test Plan, create a script (2-4 pages) of your intended final presentation. The script may be in the form of an outline or bulleted list. In some cases, it will be close to your prototype demonstration. It should tell a choherent and convincing story that will make your client enthusiastic about signing off on your project!
You may refer to figures in other parts of your document such as use cases and / or mock-up's.
 
 
 
14. Unit and Integration Test Plans

Enumerate several key tests for evaluating individual modules and combinations of modules in your system.
For each test
• Test ID
• Purpose of Test
• Item(s) being tested
• Input specification or specific data being tested
• Output specification
• Expected Results or Test Oracle Mechanism
• Test environmental needs or special test procedures