CSE 432S/533S: Project Implementation II

Guidelines for the Implementation Document

In general, the level of functionality you should be aiming for by the implementation document deadline is again for a "working prototype", i.e., one that (1) can exercise the major subsystems of your second project cycle's 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 (the "happy path" scenario). In the evaluation stage, however, you will then refine this 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.

More importantly, 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 a 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.

Please 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 in the second project development cycle.

Deliverable: Implementation Document

1. a cover page with the title of the project, the nature of the document (Implementation II), 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 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 and definition code file listing section that contains the code files containing 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 week's 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 section, that gives step by step instructions for logging in, 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 in this section giving us directions (and access) 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 second implementation stage and write them up as long as the other team members contributed materially to the discussion that is captured.

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

As with the requirements and high 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 final project report, other than the evaluation results and analysis which you will add in the last stage of the cycle.