Due at beginning of lecture, Tuesday, June 2.

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 are updates of what you turned in for the Requirements Document.  The remainder of the sections are new to the Design Document.

1. Title Page
2. Summary
3. Use Cases
4. Milestones and Effort

 
5. Class Diagrams
• The class diagram shows the static structure of classes in the system.
• Include each class in your design, along with its attributes and operations (methods).
• Include associations between classes, including generalization (inheritance).
6. Activity Diagrams
• The activity diagram shows the (dynamic) flow of control in the system.
• Include information about which object is responsible for each activity using swim lanes or labeling each activity with the name of the object.

Comments

Even if your implementation language is not object-oriented, you can design your system using object-oriented concepts, and this will lead to a better design.