The design of large systems is still a bit of an art. However, going through the process of writing a design specification before you write the code will help to give the process some solidity. It also gives you the opportunity to try out different designs, and modify your design before you write any code when changes are still inexpensive. During the design process, you should focus on the parts of the design essential to producing a core system and merely outline extensions to a more complete system. One of your major goals is to get something working by your deadline, even if it isn't the full system. Thus, you should determine what needs to go into a skeletal system and design those components first.

The end goal in the design process is a detailed design document that is complete enough to be a reference from which any competent software engineer can produce code and test plans. Once each section of the design has been completed, you should do a group walkthrough to make sure that every group member agrees to the design. This is also going to be one of the major ways that you discover conflicts between parts of the design that different people developed.

Your design should take good object-oriented design principles into account. You want to aim for an abstract, de-coupled, extensible, and maintainable system. You should also isolate any potential machine dependencies.

You must write this document in HTML, and put the paper on one of your home pages. On Tuesday, October 27^th, you must give the URL of your write-up to each of your reviewers (to be assigned in class). They will have 48 hours to give you feedback about your write-up. Then, you will have five days to revise your document, and submit the final version on Tuesday, November 3^rd. Note that both the design spec and the reviews will be graded.

The review should be on the order of a half page, and should include both comments about what they liked about the spec, and where it can be improved. Offer suggestions on both a detailed, and a structural level.

You must turn in your project in the following way:

• You must put a link to your revised document, and all of your reviews on the Web, and then email the URL to the TA at mailto:sbw@cs.umd.edu with a subject line of "CMSC435 Design Specification".

If the final version is not turned in by Tuesday, November 3^rd, at class time (2pm), it will be considered late. On the course home page, we will make links to all of your documents so you can see what your fellow-students created.

Your design should consist of the following six things: A summary description of the system, a UML Class Diagram of all of your non-trivial objects, UML Sequence Diagrams of important life-cycles of your objects, a UML Package Diagram of the relationship between your packages with each other and system packages, an overview description of each class, and finally, a rough timeline describing in what order and when you write each part of this project.

This section should describe an overview of the system design. It should start with a short summary of what the system does. It should then describe the large components of the system, what they do generally, and how they interact. It should specify what languages are used in each component, what computer systems each component will run on, what external libraries will be used, etc. It will probably be appropriate to have a diagram which summarizes the components and their interactions.

This section should present the class hierarchy used to build your system. We will use the graphical notation described in UML Distilled by Fowler (see Chapters 4, 5). In this diagram, all non-trivial classes should be represented, but instance variables and other private items can be left out. Methods can be summarized. I.e., if there are eight different 'search' methods, then just a single search method can be shown here.

A sequence diagram shows the flow of control while your system is running (see UML Distilled Chapter 6). You should draw a sequence diagram for every major system interaction. This will provide an example of a potential execution of a portion of your system. It is not intended to be complete, but is meant to give a feel of the dynamic nature of the system. It should show how objects get created and deleted over time for specific actions (such as firing an Asteroids bullet), and show what objects are responsible for creating other objects and for communicating with them. It will not be complete, but should show many of the major requests and objects.

A package diagram shows the packages of classes and the dependencies among them (UML Distilled Chapter 7). Draw a package diagram for you system including the Java system packages it depends on.

This is the place to fill in some details of your Design Specification. It should contain a summary description of the public portion of every class. That is, it should specify the class interface and a description of what it does. Each class should contain a description of what it does and what data structures it uses.

The easiest way to write your class descriptions is to use javadoc. After you have written the above UML diagrams, write the Java code for your class definitions without defining the body of your methods or any of your private data (actually, define your method bodies with a simple open/close brace '{}'). Instead, just declare your class interface by defining methods, and documenting each method with javadoc style documentation. Then, run javadoc, and the javadoc output is your class descriptions.

Each method of each class should be listed with its signature (parameter and return types) and a description of what it does. All pre and post conditions should be specified as well as any side effects. Error handling descriptions should also be included here. What is the range of legal values? What happens when other values are found? How are other errors handled?

Be sure to use a consistent naming strategy that is consistent with the Java Coding Conventions (http://www.javasoft.com/docs/codeconv/html/CodeConventionsTOC.doc.html). If you haven't already, read Chapter 9 of Code Complete that describes issues about naming.

You must define a rough schedule for your project implementation with a timeline. You should write a basic Gantt chart that shows when each part of the project is scheduled to be written, and what parts of the project will be written in parallel with other parts. Be sure to include time for testing your code, both at a unit and system level. This schedule will give you a rough idea of how much time you have to work on each aspect of your system, and how you can allocate people to work on different parts.