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

---

Background

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):

• The project now has a name: Triple P Enrollment System (TPES).
• Some of the requirements have been revisited and clarified, yielding an Official Requirements Specification. Please refer to this document for the remainder of this project; it supercedes the document you submitted in Phase 1.

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:

• Architectural design, in which we decide on the major modules of our system and the ways that they will interact with one another.
• Module design, in which we consider the individual modules and their interactions in more detail, including breaking some of the major modules in our architectural design into smaller ones, deciding on the set of methods that will be provided by our modules, and understanding how these modules are related to one another.

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:

• Rigor. We want to be sure that all of our requirements are met; obviously, a necessary (but certainly not sufficient) condition of a good design for a project is one that addresses the system's requirements.
• Information hiding. Modules hide design and implementation decisions. Its important to point out that we don't mean "hide" in the sense that no one can find out about them — if you have the source code, you can discover these decisions. The point is that other modules won't depend on these decisions, so that the decisions can be revisited without affecting the other modules.
• Separation of concerns. Modules should each solve a single problem; they should be designed in a way that allows them to be written and tested independently.
• High cohesion. The parts of a module are closely related to one another, instead of being a disparate collection of unrelated or loosely related parts.
• Low coupling. Modules rely on each other as little as possible.

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.

• Table of Contents, including page numbers.
• Introduction. Describe the architecture of your system at a high level. Where you used the architectural styles we discussed in lecture or are described in Section 11.4 of the textbook, make a note of them.
• UML Class Diagram. Draw a UML Class Diagram detailing the classes in your system and their relationships to one another. Include only public attributes and methods.
• Class Interface Specifications. For each class in your design, specify its interface, including at least the following information:
  • Which Official Requirements are addressed by this class? (You do not need to describe the requirements; the identifier, such as ES-1, will do.)
  • What information/decisions does this class hide?
  • List its set of public methods and constructors, including their names, parameters, return types, and a brief (e.g., one sentence) description.
  • Anything else that will help us to understand the class, such as its parent in an inheritance hierarchy.
• Integration Test Plan. Choose two classes that are related to one another (in some way other than inheritance) and describe a plan for testing their integration with one another. Your plan should be broken into test cases, with individual cases focused one one way that the two classes interact. Specify what objects will participate in the test, how they will be set up before the test, the steps that will be taken in the test, and the expected results (e.g., return values of methods, changes to the objects' internal state).

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.

---

Deliverables

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.