CSE 432S/533S: Project Low Level Design II

Guidelines for the Low Level Design

How the associations are designed is up to you to decide, largely based on your second high level design and any changes you need to make to it as you refine the details of the design in this stage. For example if each instance of class X needs to have access to an instance of class Y, you might in one case say, "class X will have a member variable named "y_ref_" that is a pointer to an instance of class Y". Alternatively, in another case you might say "class Y will be a singleton that provides access through its instance() method".

By the end of this stage, the code should be "all but written". That is, in the implementation stage you will still need to fill in the definitions of the methods and functions you have declared and make any extensions to the code required by those definitions. However, other than that, by the end of the low level design stage you should have at least a very detailed declaration of the structure of your code, which realizes the requirements you gave for the second project cycle.

The low level design document should contain a listing of the declarations of all the classes, non-member-functions, and class member functions that will be defined during the subsequent implementation stage, along with the associations between those classes and any other details of those classes (such as member variables) that are firmly determined by the low level design stage. The low level design document should also describe the classes, function signatures, associations, and any other appropriate details, which will be involved in testing and evaluating the project according to the evaluation plan defined in the project's requirements document.

More importantly, each project's low level design document should provide a narrative describing (and comments in your declaration and definition files should point out) how the high level design is mapped into its detailed low-level design, which is just a step away from the implementation itself. This should be an English description of how you converted the technical diagrams (and text descriptions) found in your high level design into appropriate class and function declarations in your low level design. You should be especially careful to explain how the class roles and their methods were combined in your low level design, and any changes that you decided to make in combining and refining them.

Deliverable: Low Level Design Document

1. a cover page with the title of the project, the nature of the document (low level design II), the names of the team members who contributed materially to the document, and the date the document was submitted. In creating your low level design document, you can either add the following new sections to your requirements document, or if you prefer you can create a separate low level design document.

2. a low level design overview section that describes how you mapped your high level design into your low level design, and gives an English explanation of the code files (described in the next sections) and their contents, especially focusing on the class and function declarations in the declaration (header) file listings in the last section of this document. In this section you should (1) list each class, (2) say what role each class plays in each of the design patterns in which it is involved, (3) describe what each of its member functions will do (once you have implemented their definitions in the next stage), and (4) how the associations between the classes will be used by those functions.

3. a project code file outline section that will serve as a "packing slip" for the code files in your low level design and your implementation. It should:
   • state the language (or languages) in which you will implement your project in the second project cycle, and say whether or not the set of languages used in the second cycle differs (and if so, how) from the set of languages used in the first cycle;
   • list the names of the source and header code files that will contain your implementation;
   • list the classes and functions that will appear in those files, saying whether each class or function is declared or defined in that file; and
   • identify all of the instances of the different kinds of associations (for example, inheritance, ownership, reference counting, etc.), between the classes and describe how each association will be declared.

4. a project declaration code file listing section that contains a listing of the code files containing the declarations of the classes, functions, and class associations in your low level design. The comments in the listing should reflect a summary of the information provided in the low level design overview section, i.e., showing the mapping between design pattern roles into classes, indicating how each association variable (e.g., references and pointers to instances of other classes) is used, etc.

Participation: every member of your team should be significantly involved in the production of this document, though how you structure the interactions within the team is up to you. For example, it's fine for one person to capture notes from a group discussion of the low level design document and write it up as long as the other team members contributed materially to the discussion that is captured.

Deadline: by 11:59pm on Friday June 26, 2009, please e-mail your team's low level design document to Prof. Gill at cdgill@cse.wustl.edu.

As with the requirements and high level design documents, your team should treat this low level design document as a "work in progress", evolving it appropriately throughout the development cycle, and by the evaluation stage the documents you have produced previously should constitute most of your final project report, other than the evaluation scenario descriptions, evaluation results, and analysis which you will add in that last stage of the cycle.