Design Documentation

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 (3-4 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 list of those that you considered but did not define is nice to have!)
• Text describing the roles for each class (responsibilities) and how the classes interact (collaborators).

This is essentially what BOOST provides for you, if you use it right! 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 (2-3 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, but BOOST can do it for you, too!
• 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 page)

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 a 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 a Counter program could be reused as-is in such an application.
• For all Programing Assignments, 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/Yourdon 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 ARE WELCOME TO USE ANYTHING YOU WANT FROM THE COWEB. But I do want to see a statement of what projects, cases, and pages you used in building your project -- a list of references, in a sense.