Design Documentation

Design Document Requirements
CS 2390 Winter '98

Documentation for each of your programs will represent 50% of the total grade on each program.

For each program, you will turn in a four part paper document: Sections 1 through 3 are the design documentation, and section 4 is the well-commented program code. Design documentation cannot be hand-written, except for the graphical notation.

1. Object-Oriented Analysis Documentation (1-2 pages)

For each program, show that you have analyzed the program using object-oriented analysis. Evidence for this analysis will include the following pieces of documentation:

• A list of classes that you decided to define.
• A text description of the analysis, with (1) a paragraph describing the overall architecture (e.g., how the objects in the analysis interact) and (2) at least one paragraph on each object/class in the analysis. Suggestion: Textual object scripts like those that the book uses are not required but would certainly help in understanding your analysis.

Remember that the goal of your object-oriented analysis is to be langauge independent - there should be no references to Smalltalk or C++ classes/syntax/anything in this section of your design document.

2. Object-Oriented Design Documentation (1-2 pages)

For each program, show that you have designed the program using object-oriented design. Evidence for this process will include the following pieces of documentation:

• The graphical notation from the design describing classes, class relationships, attributes, and services. The graphical notation can be hand-drawn.
• A text description of the analysis, with at least one paragraph for each set of interactions between objects. For example, in the Counter program, good design documentation would include a paragraph describing the interactions between
  • The increment button and the count model.
  • The decrement button and the count model.
  • The reset button and the count model.
  • The display box and the count model.
• One or more scenarios (usually defined as questions in the assignment). Explain the flow of control and data between different parts of your system.

As for the HIC (Human Interface Component): I really don't care if you deal with it in the OOA or OOD. We simply don't talk enough about analysis of interfaces for me to require much rigor in your writeup. However, we do talk about why we did what we did in interfaces, so I do expect some analysis of your interface. Whether it appears in your OOA or OOD is up to you.

3. Reuse Documentation (1-2 pages)

Convince the reader that you have considered how the objects you have analyzed, designed, and implemented (all or a subset) might be reused in a future project.

• For the Design Assignment only, describe in a paragraph one other application for some or all of the objects you have defined in your project. For example, for the Counter program, an application might be a child's game that displays a number and that number of apples each time that the child hits the add one or subtract one buttons. Most of the objects from the Counter program could be reused as-is in such an application.
• For Programing Assignments 1 and 3 (but not 2!), describe in a paragraph one other application for some or all of the objects you have defined in your project, then include an analysis using the book's graphical notation for the application. You don't need to completely analyze the alternate application! Rather, your analysis should include one to two new objects plus the objects from your project that you would reuse. The goal is for you to demonstrate that you have (1) thought about reuse of your objects and (2) can articulate that thought using the Coad/Nicola notation. N.B. If your reuse analysis contains phrases like "We could change the class to..." you've missed the point. Reuse means as-is.

4. Program Source with Comments (1-500 pages)

File out and print a copy of your program and include it in the packet that you hand in. Do not take the documentation in the Class Library to be your documentation standard! Rather, try to document more as you did in 1501/1502, e.g.:

• Comment each block of code.
• Comment each instance variable defined.
• Provide comments such that the comments can be read and understood even without the code.

You need to also email a copy of your code to your TA!