CSE 432S/533S: Project Low Level Design

This page is intended to help each project team define the low level design for the first project cycle. The low level design defined in this stage will also carry forward into the second project cycle with refinements to the low level design from the first cycle being driven both by lessons you learned in your implementation and evaluation that will follow your low level design, and by the requirements you establish for the second project cycle.

Guidelines for the Low Level Design

Each project's low level design document should provide a complete and detailed specification of the design for the software that will be developed in the project, including the classes, member and non-member functions, and associations between classes that are involved.

How the associations are designed is up to you to decide, largely based on your 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.

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 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

Using Word, LaTeX, or other editing tools as you prefer, you will produce a document that describes your team's low level design for the current development cycle of your project and that contains the following sections:

  1. a cover page with the title of the project, the nature of the document (low level design), 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 list each class and say what role it plays in each of the design patterns in which it is involved, describe what each of its member functions will do (once you have implemented their definitions in the next stage), and 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,
    • 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
    • list the associations (for example, inheritance, ownership, reference counting, etc.), between the classes and describes 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 5, 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 evaluation report, other than the evaluation results and analysis which you will add in that last stage of the cycle.