Architecture and Design

The goal of this phase is to understand and clearly document both the high-level architecture and the detailed design of your project. At the end of this phase, you will have a detailed description of the objects that will be used to implement your project. Additionally, the relationships between these objects, such as inheritance, aggregation, and dependency will be recorded in a series of UML structure diagrams, while the dynamic behavior of the objects will be recorded as UML interaction diagrams.

Deliverable

Your design document should include:

• Title page
• Change log
• Table of contents
• Overview.
  You need to provide text providing an overview of the diagrams, and design choices embedded in these diagrams. Ideally, a reader who has previously seen your scenarios and requirements documents should be able to understand your design documents, based on the descriptive text you provide.
• A roadmap to the sections and diagrams in your document.
  The organization of the diagrams (why did you order the diagrams in a particular way).
• Major design decisions.
  Any unusual or noteworthy design decisions (why you think your 8-level deep inheritance hierarchy is the right choice).
• Modularization criteria.
  You should explain how you made your modularization decisions (how did you choose your objects).

• Architecture Diagram.
  This is a high-level overview of the components (users, computers, processes, etc) in your system and how they co-operate. It should include:
• users, computers,
• server processes, client processes, other major processes,
• data storage, major data pieces,
• major software classes/modules,
• communication paths, networking.

• UML Structure Diagrams.
  Each component in your architecture diagram contains one or more classes or objects. In a series of UML structure diagrams (that is, class, package, or object diagrams), describe the attributes and operations of these classes, as well as interrelationships such as inheritance, aggregation, and dependency.
• Refer to Practical UML
• A class may show up in several diagrams, but its internal details should only be shown once.
• Include a caption for each diagram.
• Include one or two sentences to help clarify each diagram.

• UML Interaction Diagrams.
  Pick 5-10 scenarios, or important functional aspects of your project as described in the requirements. For each of these scenarios, develop one or more UML interaction diagrams showing the sequence of calls among objects that implement the behavior in the scenario. Make sure it's clear which scenarios you're modeling.
• Refer to Practical UML
• Sequence diagrams -- better for showing when things happen.
• Collaboration diagrams -- better for showing who (which classes) makes things happen.
• For each diagram, include a reference to the relevant section of the requirements or scenarios deliverable.
• Include a caption for each diagram.
• Include one or two sentences to help clarify each diagram.

For more information, see the gradesheet.

You also need to turn in your meeting notes and time cards.