Detailed Design Part 1 Roadmap

Documents included in this milestone:

· Examples of sequence diagrams are included in Design Documents, Part 2 Example

· Examples of class diagrams are included in Design Documents, Part 2 Example

· For a short description of class diagrams and sequence diagrams, see Detailed Design, part 2

Purpose of this milestone:

To take the functional information generated in the SRD and the User Manual and

· Capture it graphically

· Decompose the actions into smaller blocks for initial allocation to classes.

What it consists of:

· The first pass at your class diagram

· A sequence diagram for each of your Use Cases from the SRD, section 6

How you do it:

· Start by taking the Description of the Product in the Product Overview section of the SRD (section 1.1 of SRD). Underline all of the nouns and consider them as possible classes in your class diagram. Consider the types of relationships each of the classes have with other classes: association, generalization (where an instance of the subtype class may be used anywhere an instance of the supertype class is allowed), or aggregation (aggregate - some sort of whole-part or composition aggregation - a whole-part where the parts 'live' inside the whole and will be destroyed together with the whole). For associations, list the multiplicity, role names, and assocation names. For the generalizations, indicate (if possible) the characteristic that determines which of the subtype classes an object belongs to). For aggregates, try to determine whether it is a simple aggregate or a composition. Also show multiplicity and any special aggregation name (if used).

· Then, produce at least one sequence diagram for each of the use cases in your SRD. To do this, take each use case from section 6 of the SRD and make sure it is in the following form: always initiated by an actor and it is a complete description. You can do this in one of two ways: either use general use cases, or convert each use case to a number of scenarios. A general use case is a use case that shows all possible cases for that use case. It contains conditional logic. A scenario is one specific instance of a use case, and therefore, if the use case contains one two-way condition, then two scenarios are developed from that use case. Each of the scenarios starts at the beginning of the use case and travels a different path in the use case. For either method that you choose, take each step in each use case or each scenario and transform it into one or more messages on a sequence diagram. Each of these messages is from the actor to a class or from a class to another class. Use the classes that you've already placed on the first pass at your class diagram or add additional classes as needed. This is a hard task and typically requires iteration. When done with a sequence diagram, update your class diagram. Add all new classes. For each message in each of the sequence diagrams, add (as needed) operations to the appropriate classes in your class diagram. Remember, the receiving class (on the sequence diagram) needs to provide the operation (member function) for that message. Add class attributes to the class diagram for all parameters and constraints used on your sequence diagrams.