Design

You must generate the design for this project.  The design represents the set of classes and their responsibilities and collaborations that you code to implement the program.  Do not short change yourself by spending too little time formulating your design.  Too many programmers start writing code before they understand how the program is supposed to work and before creating a good design that supports the requirements.

Use inheritance and polymorphism to the fullest extent possible.  A well-defined abstract class at the head of a multi-level inheritance hierarchy can make your programming task immensely easier.  It will also reduce the amount of code that you have to generate.

You will submit your design (UML diagram and pseudo-code) on paper in lecture on the design due date.

Note: if you intend to work with a partner you must announce this on your design submission.  No teams will be allowed to be formed after this time.

Class Structure UML Diagram

You design has two components.  The first is a UML diagram that shows the classes that you will use.  This diagram follows the standard format for UML diagrams.  There is a chart summarizing UML available from Rational Corp. here. The essential points for your work are as follows:

1. Each class is diagrammed in its own box.  The box is divided into three sections.  The top section has the class name.  The middle section contains the class state, i.e. instance and class variables.  The bottom section contains the class behavior, i.e. methods.
2. State is shown with the data type and name for the variable in the form,
   
           variable-name : data-type
   
3. Behavior is shown with the method name, return type and parameter list.  A method entry has the following form,
   
        method-name(param-name : data-type, other params) : return-type
   
4. You do not need to list accessor or mutator methods for a class.
5. Access control for methods and variables is specified as: - for private, # for protected, + for public.
6. If a class or method is abstract it is shown italicized.
7. An interface is can be indicated with <<interface>> added in the top portion of the class box under the interface name.
8. Relationships between classes take several forms.  Inheritance ("extension" in Java) is expressed as a solid arrow line pointing from the sub-class to the super-class.  The arrow head is a hollow triangle.  Interface implementation is expressed as a dotted arrow line pointing from the implementing class to the interface, again with a hollow arrow head.  Client-server associations, often representing has-a relationships, are shown as a solid arrow line pointing from the client to the server.  The arrow head is simply two lines.
9. Classes that you use from the standard Java distribution need only be shown as a box with the class name in it.  You do not have to detail any of the state or behavior.
10. If all classes make use of a class from the standard Java distribution (String is most likely in this category) you do not have to show the association from every class.  To reduce diagram clutter just add a notation at the bottom of the diagram that all classes use the class.

You can use xfig or Rational Rose on the CS department Unix systems.  You can also use any other drawing program that you may be familiar with.  You will have to hand in a hardcopy of the UML diagram. (To use Rational Rose see information that Prof. Heliotis has made available.  There are also a number of tutorials and references for Rational Rose off the CS 4 tools and documentation page.

Class Descriptions/Pseudo-code

On the design due date you will also submit a document that contains a brief description of each class in your design.  Your descripton must state what role the class plays in your design and how it interacts with other classes ion the system.  You must also provide a pseudo-code description of the operation of every non-trivial method in each class.  This should be a description of what each of the methods will do written in a structured English format.  It is not Java code but rather a description of what the program code will do.  Indent the pseudo-code where appropriate based on the control structures that you plan to use.

All non-trivial methods must be documented.  Do not confuse trivial with simple.  Most of the methods will probably appear to be rather simple, i.e. easy to understand.  Trivial means short.  Less than five lines of code.  Any method that will be more than five or so lines of code, or have more than a single control statement (if, while, switch) must have pseudo-code documentation.

After you finish your design and begin writing the source code copy your pseudo-code into comment blocks within the class's Java file.  This will probably give you most of what you need for the required code commentary.

GUI Prototype

Your design document must also include a computer generated drawing of what your GUI will look like.  The best thing to do would be to write a prototype of your GUI (a GUI prototype displays all the components of your GUI but does not connect any actions to the components) and the print out a screenshot.  If you are short on time you may hand in a computer generated drawing of what you think your GUI will look like.

Special Notes

1. Any diagrams, class descriptions, pseudo-code, or GUI prototypes that are handwritten will not be accepted!
2. Your design is not cast in concrete.  You can make changes to the design as you progress with your implementation.  You may want to change the design based on comments made by your instructor or on your experience implementing the project. Ask if you should provide a revised design with the final submission.

Submission

Your instructor will collect your design documentation in lecture on the design due date.