CS 2390 W95 Design Document
Requirements
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.
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 description of the analysis using the graphical notation used in the
Coad/Nicola book.
- 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.
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 analysis annotated with the
interaction between the objects, as Coad/Nicola do (e.g., describing the flow
of messages and information between the objects.)
- 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.
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 program 1 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 programs 2 through 4, 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.
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.