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

This page is intended to help each project team define the high level design for the second project cycle. The high level design defined in this stage will also carry forward into (and be refined in) subsequent stages of the second project cycle.

Guidelines for the High Level Design

Each project's High Level Design II document should provide a complete (though still high level at this stage) specification of the design for the software that will be developed in the project. The high level design description should contain at a minimum the names of the classes that will be developed during the low level design and implementation stages, the important associations between those classes (for example, inheritance, ownership, reference counting, etc.), and any details of those classes that already are firmly determined by the high level design stage. The high level design document should also describe the classes, associations, and any appropriate details, that 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 high level design document for the second project cycle should again provide a narrative describing how each of the design forces that were defined in the preceding requirements stage is resolved by that design specification, and in particular which design patterns were applied (and in what order) to generate the design specification from the design forces arising from the project's requirement specification. The high level design document should also describe the design patterns that were applied to arrive at the testing design, which may require further thought about the design forces that are implied by the statements in the evaluation plan.

Whereas the requirements document for the second project cycle was based mainly on English sentences, the high level design document should begin to move from English descriptions (which are of course still important in explaining the design narratives described above) toward more technical representations like class structure diagrams, interaction diagrams, etc. An important issue in using these more technical representations is that you still need to show clearly how the design emerged from the requirements, as you applied different design patterns to arrive at your design. Each team is free to choose how they represent the pattern structure within the high level design itself in each of the more technical representations, as long as it is understandable, is well explained in the high level design document, and adequately captures the pattern structure itself.

As with anticipating requirements, in practice it is sometimes difficult to anticipate all of the considerations that will come up during design and implementation up front, and so it is sometimes necessary and often beneficial to revisit high level design during later stages. Beware, however, of letting the scope of the project design change (sometimes known as "scope creep") as that can put the timeline and quality of the project in jeopardy.

Also, there will likely be a number of design decisions and details in each project that fall outside what is addressed by the set of design patterns we'll consider in this course. You should feel free to look up and describe other documented design patterns (citing the sources of those design patterns appropriately) if you would like, or you can simply note which design features fall outside the scope of the GoF design patterns. In either case you should again scan through the brief pattern descriptions on the inside cover of the GoF book, note the patterns that seem related to your design, and then examine each of those patterns in more detail to make sure you've adequately considered which of the GoF design patterns are relevant to your design.

Deliverable: High Level Design II Document

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

a cover page with the title of the project, the nature of the document (second high level design), the names of the team members who contributed materially to the document, and the date the document was submitted. In creating your high level design document, you can either add the following new sections to your requirements document, or if you prefer you can create a separate high level design document.
a project design overview, including a brief English discussion of the classes involved and how the classes are related through structural associations or through behavior (interactions). This overview should cover both the design of the project solution itself, and the design of the evaluation and testing software that will be used in the evaluation stage.
a summary of the project's design evolution from requirements to high level design, including which design issues were the most challenging, which design issues were relatively straightforward, and anything otherwise noteworthy about the design issues your team considered in moving from requirements to high level design. In this section, please identify the design patterns that your team identified as being relevant to your design, and please distinguish new patterns (and new uses of the same pattern) for the second project spiral, from those that are carrying over from the first one.
Please describe how each of the design patterns you applied in arriving at your second high level design helped to address each of the design forces arising from the requirements (or from previously applied patterns), and please also note new design forces (if any) that were missed during the second requirements stage but now have been identified, or that resulted from applying a particular pattern during the second high level design stage itself.
a reasonably detailed technical representation of the high level design, using class diagrams, interaction diagrams, CRC cards, or other representations, along with English descriptions that explain the class diagrams etc., in detail. This technical representation should cover both the design of the project solution itself, and the design of the evaluation and testing software that will be used in the evaluation stage. One idea for how to do this is first to describe the core solution, and then to describe the evaluation and testing software and how it will interact with the core solution being evaluated.

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 high 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 Tuesday, June 23, 2009, please e-mail your team's high level design document for the second project cycle to Prof. Gill at cdgill@cse.wustl.edu.

As with the second requirements document, our team should treat this second high level design document as a "work in progress", evolving it appropriately throughout the second 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.