CSE 432S/533S: Project Implementation

Guidelines for the Implementation Document

In general, the level of functionality you should be aiming for by the implementation document deadline is for a "working prototype", i.e., one that (1) can exercise the major subsystems of your design, and (2) for each subsystem can demonstrate the basic functions you have designed for a single scenario with no bad inputs, or other complications - this scenario is sometimes called the "happy path" scenario. In the evaluation stage, however, you will then refine your testing and evaluation code further to address scenarios involving problematic inputs, and other situations that could break the prototype code - basically your job in that last stage will be to try to make your prototype as robust, efficient, etc. as possible, beyond the level expected for the implementation stage which is simply to have a reasonable basic functionality working.

Each project's implementation document should provide a narrative describing (and comments in your declaration and definition files should point out) how the low level design is mapped into the implementation, which is the first working prototype of the system. This should be an English summary of how you converted and extended (and possibly revised) the class and function layouts given in your low level design document to achieve the working prototype. You should be especially careful to explain how the associations and interactions between the classes (1) impacted how you wrote the definitions of the functions and class methods, and (2) were leveraged by those functions and class methods to implement the interactions between the classes that you specified in your high level and low level design documents. The idea of this summary is to give the reader of your implementation document a single place where they can see how you moved from low level design to implementation.

Deliverable: Implementation Document

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

2. an implementation overview section that describes how you mapped your low level design into your implementation, and gives an English explanation of the code files (described in the next sections) and their contents, especially focusing on the class and function definitions in the source file listings in the last section of this document. In this section you should describe how the class associations and interactions specified in your high level and low level design documents both shaped and were shaped by your implementation of those definitions.

3. a project implementation code file outline section that will serve as a "packing slip" for the code files in your implementation. Please make sure that if you have added/removed/renamed/etc. any classes/methods/member variables/functions/etc. since your low level design, those changes are reflected in this list. It should:
   • state the language (or languages) in which you are implementing your project,
   • list the names of the source and header code files that contain your implementation,
   • list the classes and functions that 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 is declared.

4. a project declaration and definition code file listing section that contains the code files holding the declarations and definitions of the classes, functions, member functions, and member variables in your implementation. The comments in the listing should reflect a summary of the information provided in (1) the implementation overview section of this document, and also (2) the high level and low level design overviews from the previous two documents. Thus, the comments in the code should offer a pretty thorough view of the design patterns you chose, how they mapped into the high level and low level designs, and then into your implementation, but in contrast to the implementation overview section where the entire summary is in one place, the comments should reflect how each function, etc. plays its part locally in that overall technical structure.

5. an instructions for building and running the prototype section, that gives step by step instructions for building and running your code on a platform that is available in one of the CEC Windows or Linux labs. If there are any libraries, etc. that need to be downloaded in order to build or run your prototype, you should also say what they are and give step by step instructions for downloading them and using them in your project. One option is to set up a demo environment in your team account on the CEC machines, and provide directions (including if necessary directions for gaining access permissions) for running your implementation there.

Participation: every member of your team should be significantly involved in the production of the code and the writing 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 implementation document and write it up as long as the other team members contributed materially to the discussion that is captured. Similarly, some team members may develop different parts of the implementation code, while others may contribute by testing and debugging it.

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

As with the requirements, high level design, and low level design documents, your team should treat this implementation 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.