As part of your design, you should anticipate various ways your project could change. Perhaps a change in rules, or input syntax, or a whole new feature—who knows? Plan all of your project features to accommodate change, with minimal modification to your original program, and minimal recompilation. In your final design document, outline the ways in which your design accommodates new features and changes to existing features. Be specific. You may wish to implement some of these for extra credit. This discussion is a very important component of your design grade; if you spend less than a page on it, you probably aren’t saying enough.

Your documentation and design will be assessed via written documents that you will submit to Marmoset as pdfs.

Extra Credit Features

All of the available projects give you the opportunity to earn up to 10% extra credit for en- hancements to the core projects. Keep the following rules and guidelines in mind when planning enhancements:

? It is far more important to have your core project working well, than to have a poorly done project with extras. Remember, the enhancements are only worth 10%. Your documentation and design are also more valuable than your enhancements, so please take time to do these well.

? Your program must be able to run the core project, without enhancements, as well as with them. You are not allowed to submit two programs for grading, one with enhancements and one without. You are also not allowed to recompile your program with different compiler flags to produce versions with and without enhancements. You may select or deselect your enhancements via flag arguments on the command line. (E.g. ./project -enablebonus, or something similar.) Even better would be if you could turn your enhancements on and off dynamically, as the program is running.

? Markers will not assign values to individual bonus features during the demo. You may show what you have done, and the TA will take note, but values will be decided once all demos are completed.

? One enhancement that is available for all three projects is offered as a challenge: complete the entire project, without leaks, and without explicitly managing your own memory. In other words, handle all memory management via vectors and smart pointers. If you do this, there should be no delete statements in your program at all, and very few raw pointers (the only raw pointers you would be permitted to have are those that are not meant to express ownership). Successful completion of this challenge will earn you 4 of the available 10 bonus marks. If your program leaks, these marks cannot be earned. Also note that these 4 marks are not reserved for this feature; it is theoretically possible to get all 10 bonus marks without implementing this challenge.

On Due Date 1

Submit a plan of attack. This should include a UML that describes how you anticipate your system to be structured (even if you complete the project by due date 1, the UML you submit must be one that you built prior to starting the project).

Your UML should show the classes that make up your project and the relationships between them. You only need to show public methods (i.e, you can leave out private fields and pro- tected/private methods, unless you need to show them to illustrate a point, e.g., a design pattern). Do not show the big 5 operations, or any other constructors, accessors, or mutators. You will not graded on the degree to which you adhere to this model, but you will be asked to account for any differences that arise between this model and your final submission. File: uml.pdf.

In addition, your plan of attack must include a breakdown of the project, indicating what you

plan to do first, what will come next, and so on. Include estimated completion dates, and which partner will be responsible for which parts of the project. You should try to stick to your plan, but you will not be graded by the degree to which you stick to it. Your initial plan should be realistic, and you will be expected to explain why you had to deviate from your plan (if you did). File: plan.pdf.

Finally, your initial plan of attack must include answers to all questions listed within the project

specification itself. You should answer in terms of how you would anticipate solving these problems in your project, even though you are not strictly required to do so. If your answers turn out to be inconsistent with your final design, you will have an opportunity to submit revised answers on Due Date 2.

Your plan should be no more than 5 pages long.

On Due Date 2

On Due Date 2, you must submit all of your code to Marmoset, together with a Makefile, such that issuing the command make builds your project. Your executable should be called chess for Chess, raiinet for RAIINet, or biquadris for Biquadris.

In addition, you must submit a final design document. It must outline the final, actual design

of your project, and how it differed from your design on Due Date 1 (if it did). You should include an updated UML, reflecting the actual structure of your project. Do this even if it is the same as the original UML. Files: uml.pdf, design.pdf.

Your document should provide an overview of all aspects of your project, including how, at a

high level, they were implemented. If you made use of design patterns, clearly indicate where. Your system should employ good object-oriented design techniques, as presented in class.

Include all answers to questions posed within the project specification, and indicate how they differ from the answers you gave on Due Date 1 (if they did).

You should not expect the TA to read through all of your code. Therefore, your design document should stand alone – the TA should not need to have your code open in order to understand your document. However, if you wish to highlight certain aspects of your design, you should indicate clearly where they can be found in your code, if the TA wants to have a look.

The most important aspect of your design document is a discussion of how your chosen design accommodates change, as described earlier in this document. You should also discuss the cohesion and coupling of your chosen program modules. Most of the design portion of your grade will be based on this summary.

Finally, answer the following questions:

1. What lessons did this project teach you about developing software in teams? If you worked alone, what lessons did you learn about writing large programs?

2. What would you have done differently if you had the chance to start over?