High Level Design Document Format
Team Name, Logo (optional), Deliverable name (e.g. "Web Calendar Design
Document"), Date, Course-Section.
Clearly describes each group member's contribution in producing the
This is the first place other developers/maintainers will look to learn
how your project works. It must provide a comprehensive outline of the
entire design. The design lead is responsible for writing the overview.
Write this section as HTML and place it in the javadoc overview
- Identifying info: project name, team name, authors, version,
- Design Overview. This crucial section provides an overall view of
design. Use your best technical writing to communicate to other
the framework of your design solution. It must clarify the essence of
design to someone who is not familiar with it. Try to limit this to one
- Design Issues. There are many tradeoffs in design, a few of which
in class. Describe the key design issues raised in your project, what
(or tradefoffs) you made, and your rationale. (You can think of this
as being the background that lead to your Overview above). This section
may be 3 pages or longer. Examples
of Design Issues
- Tools: Compilers and other development tools used, and their
- Libraries: Indicate what pre-existing libraries are used in your
why you selected them, any licensing restrictions that may apply.
- External References: Indicate where associated project documents
found: specification document, prototype, structure chart diagram,
patterns, coding standards, etc. If these references are in digital
provide the file name or URL. MAKE SURE THESE ARE ACCURATE when the
deliverable is submitted.
Class Diagram or Structure Chart
This diagram is the core of your design. Think of it as the blueprint
your software design. This diagram shows the relationship among all the
classes in your design. You need not show the classes that create and
the GUI. It's recommended that you use a design tool
such as Rational Rose to facilitate ease of modification (as this chart
changes a lot during the design phase). Quality hand illustration is an
acceptable alternative. The chart may be quite large. If it spans
pages be sure the page ordering or hierarchy is clearly indicated
some page numbering scheme or connector labels. You may create your
chart on a single large piece of poster board if you desire. (One
of this is that it can be hung on the wall of your team meeting space.)
Alternatively, place an image of your class diagram on your team web
Note: If you are reusing code don't draw the entire structure of the
Note: If significant portions of your solution are functions (i.e.,
complex methods) rather than classes consider showing their
with a structure
Class Skeletons or Module Headers
You must implement and compile (not execute) the class
for each class in your class diagram. (Don't forget to count compile
defects - see QA plan). The purpose and interface for the
class is documented as Javadoc comments and must adhere to Javadoc
style. The Javadocs can be placed on your team web page.
Each class in your system is to be assigned to an individual author
who designs the class and writes the class definition. Each team member
is responsible for at least one prominent class in your system.
A class definition consists of:
- A Class Header
- Method (Operation) name - must correspond exactly with the name
the class diagram.
- Purpose - Describe the purpose of this operation. Must be a
English sentence using terms from the problem domain.
- Parameters and return types - name, type, and description.
- Exceptions thrown.
- (Design By Contract teams) Pre- and Post- conditions (except
methods). Recommended: use custom
- (Error-Checking teams) Document all error handling.
- Read and adhere to the conventions for Javadoc
- Refer to this example of javadoc for a class
definition and the source
which produced it.
- Consider grouping your classes using the Java packages framework.
approach is to separate View classes (e.g. GUI) from Model classes.
- If you are reusing code, don't include the headers of the reused
- Your ADT's must handle their own persistence.
That is, you can't use a DBMS or file system provided by the target
Consult the instructor if you have questions or want to negotiate this
Interaction Diagrams (as appropriate)
Also known as sequence diagrams or event trace diagrams. They
specific details about the order in which events occur and how the
interact. They show the sequence in which objects pass messages
each other. Use some standard diagramming notation such as UML.
Rose or similar tool recommended. How do you decide appropriateness?
your judgement to determine which Use Cases are complex enough that you
need to clarify the interations. As a guideline, an interaction diagram
is probably appropriate if the Use Case has more than two objects
or has more than four steps.
Document how you have decided to implement your data abstractions.
a javadoc comment for each composite data structure in your solution.
array, vector, etc). This implementation should be private, so you will
need to used the -private flag on the javadoc command. Be sure for each
major data structure there is a rationale provided in "Design Issues"
explains your implementation choice.
/** The cipher key is an array of 26 characters,
* one to correspond to each letter of the alphabet.
private char CipherKey;
If your design includes external data files, show the exact
of each file using javadoc in the appropriate class in your design.
- FTR Review Summary report
- Compilation Listings showing a successful compile of all modules.
are using JDK, use the -verbose flag on javac and
include a screen capture of the output. Also include the output from
Checklist, (with items checked off), signed by your QA person. You
must provide an explanation for any items not checked off. If an item
missing or obviously unsatisfactory that has been checked off, the
document will be returned for correction and a late penalty will accrue.
Submitting your high level design
printouts of all the items above in an
inexpensive 3-ring binder. If your design diagram is extremely
large you may submit your finished
chart on a single large piece of poster board.
Order the javadocs in
Follow the writing requirement guidelines
for all other printed output.
|Added submission guidelines.
||Minor edits and clarifications.
Added an example class definition in Javadoc.
||Removed PSP forms
||Revised for Spring 2001
||Moved Software Architecture to Design Issues and added
Added an example of an ADT description.
||Added Defect logs to appendix