CSE 432S/533S: Project High Level Design

This page is intended to help each project team define the high level design for the first project cycle. The high level design defined in this stage will also carry forward into the second project cycle with refinements to the high level design from the first cycle being driven by requirements for the second project cycle.

Guidelines for the High Level Design

Each project's high level design 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 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 should provide a narrative describing how the design forces that were defined in the preceding requirements stage are 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 was based mainly on English sentences (e.g., requirements would contain words like "should", "will", "if", etc.), the 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. Two examples from the Pattern Hatching text, on pages 29 and 58 show different ways of showing the pattern structure for a design's class structure diagrams - similar ideas could be used for interaction diagrams as well. 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 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 at least 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.

Examples of High Level Design

Chapter 2 in the GoF textbook gives a good illustration of both the kind of design narrative that you should aim for in your high level design documents and of the technical representations such as class diagrams, which are useful in determining and documenting your high level designs. Skimming ahead through Chapter 2 in the Pattern Hatching textbook also can be very useful, as it offers a well written account of the kind of design decision process through which a good high level design can be reached. It is imporant that in your high level design document you not only describe what your design is and how that design evolved from the requirements, but also why the design choices at each step of that evolution from requirements to high level design were made.

Other Sources of Information

Section 3 (Design and Implementation) Mike Sorensen's medical information system design document shows a mixture of high level design and low level design elements, which are worth reading for comparison in this stage and the next, but which may be slightly more involved than you may want to aim for in the first development cycle. Section 4 (The Design Path) of that document is particularly appropriate to this stage of the development cycle, as it illustrates the design decision process very well, albeit spanning several design iterations over an entire semester.

Deliverable: High Level Design 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:

  1. a cover page with the title of the project, the nature of the document (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.

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

  3. 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. In narrative form (i.e., as though telling a story), please describe how each of the design patterns you applied in arriving at your high level design helped to address design forces arising from the requirements (or from previously applied patterns), and please also note new design forces (if any) that resulted from applying a particular pattern.

  4. 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 2, 2009, please e-mail your team's high level design document to Prof. Gill at cdgill@cse.wustl.edu.

As with the requirements document, our team should treat this high 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.