Informatics 43 Spring 2009
Course Project
Phase 2: Architectural and Module Design

Due date and time: Friday, May 8, 9:00pm


Since delivering your requirements specification in the previous phase, additional negotiations have taken place between the project team and the customer. During those negotiations, some aspects of the plans made previously have been changed (as they often do):

Now that the requirements specification has been completed, it is time to turn your attention to the system's design. As we discussed in lecture, we can think of design as being comprised of two simultaneous activities:

There is not necessarily an obvious line we can draw between architectural design and module design. The former focuses on the "big picture," the latter on the "small picture," but it's not exactly clear where the division between the big and small pictures are. It's also not as though we first do architectural design, then do module design; these activities complement one another and are best approached together.

This phase of the course project requires you to produce a design specification, in which you'll describe aspects of a design for TPES. It will give you the opportunity to explore architectural and module design, as well as provide you with experience using the Unified Modeling Language (UML) to describe aspects of your design. In the next phase, you'll implement portions of your design, so it's to your advantage to think things through carefully in this phase; work spent now discovering a clean design will reduce the time you spend in the implementation.

Software design is a complex topic that is learned as much by experience as anything else. That said, there are principles that are nearly universal; good designs almost always follow certain guidelines, implicitly or explicitly. Knowing these principles helps you to find a good design, especially when you're still gaining experience. A few of these principles are:

You should bear these principles in mind as you work on your design.

Your design specification

Your design specification should focus on the design of the model for TPES. In other words, consider the data that the system stores and the operations that can be performed on that data, but avoid designing the details of the user interface. Be sure that your design addresses all of the requirements that comprise Implementation Phase 1 in the Official Requirements Specification.

Your design specification should be comprised of the following sections, in the order listed below.

There are many software packages that are capable of producing UML Class Diagrams. In the ICS labs, you'll find Microsoft Visio, which does a reasonably good job of it; you can then copy-and-paste your entire UML Class Diagram from Visio into a Microsoft Word document. Essentially, anything is fine with us, as long as we understand it and as long as it can be included in your document; this includes drawing the diagram by hand (neatly enough for us to be able to read it), scanning it, and copying it into your document.

Assume that your design will be implemented in Java.


You are required to deliver your design specification as a single document in one of the following formats: Microsoft Word (.doc or .docx), Rich Text Format (.rtf), or PDF (.pdf).

Follow this link for a discussion of how to submit files via Checkmate, an ICS-built online assignment submission system. Be aware that I'll be holding you to all of the rules specified in that document, including the one that says that you're responsible for submitting the version of the specification that you want graded. We won't regrade your work simply because you submitted the wrong version accidentally.