How to Write a Design Document

Overview

What goes into a design document?

A design document is a complete high-level solution to the problem presented. It should be detailed enough that somebody who already understands the problem could go out and code the project without having to make any significant decisions. Further, if this somebody happens to be an experienced coder, they should be able to use the design document to code the solution in a few hours (not necessarily including debugging).

So what actually goes in?

For example, this is the pseudocode I would write for the existing Condition::Wait:

void Condition::Wait()
   waiter = new Semaphore, initially 0
   append waiter to waitQueue
   conditionLock->Release()
   waiter->P()
   conditionLock->Acquire()

Your pseudocode has to be precise. For instance, in describing your solution for the Communicator class, it is not enough to say
   if anybody's waiting, then signal cv
You need to say how you determine if anybody's waiting, e.g. by saying
   if (waitingReceivers>0 or waitingSenders>0) then signal cv

Also, another important thing to remember is that a design document needs to include the correctness invariants and testing strategy. The testing strategy includes a clear plan of the testing methodology and may include a description of test cases that will be used to test correctness invariants. Focus on the testing strategy. If you want, you may itemize things that will need testing.

What doesn't go into a design document?

Keep in mind that your TA understands the project very well. Do not restate the problem in your design document. Your TA is far more interested in your solution than in knowing that you understood the problem.

Your design document should contain very little actual code, if any at all. Include psuedocode for all complex procedures, but do not include Java code.

The purpose of pseudocode is to avoid all the annoying aspects of programming languages that make code both harder to write and harder to read. The purpose of pseudocode is not to be imprecise about how you solve a problem. Comments are welcome, but ASSERT and DEBUG statements, for example, do not belong in pseudocode.

Remember that we have to read your design documents. If you don't think we want to see it, don't put it in!

How do I convert x to PDF?

First convert to postscript: Then run the ps2pdf command on an instructional machine.

Be sure to make sure your .pdf file works before you turn it in (try viewing it with gs, gsview, or acroread).

How do I submit a design document?

Place your design in a file called projN-initial-design.[pdf/txt/html], where N is the project number. For project 1, your design document should be called proj1-initial-design.[pdf/txt/html]. Then run

  tar cf projN-initial-design.tar projN-initial-design.[pdf/txt/html]
followed by
  gzip projN-initial-design.tar

Now, in the directory containing projN-initial-design.tar.gz, run

  submit projN-initial-design
again, subtituting the project number for N. For project 1, you would type
  submit proj1-initial-design
To submit the final design doc, you similarly create a projN-final-design.[pdf/txt/html] and repeat the process, with 'initial' replaced with 'final'.