CSCI 1321 - Design Guidelines

This document details what is expected for the designs that you turn in during the course of this semester. For each and every assignment you will be expected to turn in a design one week prior to when the assignment itself is due. This design will lay out clearly how you intend to approach the problem in that assignment. Ideally this would be done using a standard design technique (such as UML). However, as most of you are not familiar with this (nor will you be during the course of the semester), this is the alternative approach that you can take. Note that if you happen to know UML or just want to get used to using it early on I would welcome design submissions in it. I should also note that this might be worth your while since there are nice design tools you can get that help you to create your designs with UML and some even use that to begin the process of code creation.

Your designs need to specify how you are breaking the problem up and what functionality each of the pieces you are breaking it up into will have. Because this class focuses on object-oriented programming in C++, the main pieces into which you will break things will be classes. You should include a description of every class that you are using and the methods and members of those classes. It should include not only a list of the methods and members, but also a description of what each one of them does as well as whether they are public, protected, or private or if they have modifiers such as static or const on them. For the methods it should also specify what formal arguments they take. The specification for the classes should also include information such as if they are templated and/or what other classes they inherit from. If you do have stand-alone functions (which you probably shouldn't have many of), they should also be listed in the design.

The design specification for your classes could actually take the form of well-documented header files that give the class declarations. They should not just be long paragraphs for each class. It is vital that they are easy to use. In addition to the description of each method and member it should include a good description of the class as a whole including how it should be used in code and any interesting features of that class that the user should know in order to more effectively utilize that class.

Following the descriptions of all of the classes and their pieces, you should have a general description of how those classes will be used in that particular program to implement the final solution. This can be a plain English description though if it is long it might be more understandable to break it up or use slightly more formal specifications. The idea here is that a reader should be able to read this section of the design and get a general understanding of how to program works. They can then look at the class specifications for a more detailed understanding.