CS 50, Winter 2010

Assignment 3 - Analysis and Design, Current Iteration

  1. Perform a domain analysis for the current development iteration - prepare the following artifacts:
    1. Begin a static class diagram - similar to text example Figure 9.27, p. 167 - include domain classes only at this stage. Use proper UML notation. Conceptual classes may be shown as simple, labeled boxes (no need to display attributes here).
    2. Begin class specifications, or source code - to provide the text portions of your domain model. For each class, either prepare a specification in this format:
      Name: [name of the class here]
      Description: [brief description (1-2 sentences) here]
      Attributes:
      [list one per line; show type of attribute if available]
      or even better, show this same information as the beginning of a Java class definition:
      /** [description] */
      class [name] {
      [attribute declarations - 1 per line, types optional]
      }
    3. System sequence diagrams - like text example Figure 10.2, p. 175. A separate diagram should be prepared for each use case in this development cycle (see p. 177 for relationship between use cases and SSDs).
    4. System operation contracts - like those in the text, pp. 190-191. One contract should be prepared for each event indicated in the system sequence diagrams.
  2. Meet with your TA to discuss your domain analysis - show her your DA artifacts, and discuss your plans for the design phase (it will help if you have some plans to discuss ;-).
  3. Design a system to satisfy the current iteration requirements - prepare/improve the following design artifacts:
    1. Expanded and upgraded static class diagram(s) - with design features as appropriate. Make separate diagrams for each package in the application logic layer at least, but exclude details of packages not to be created by your group.
    2. Package diagram - logical architecture view. Include the entire system architecture, like text Figure 13.2, p. 199, without specific details inside packages.
    3. Extended class specifications or source code.
      • If specifications, add a Methods section (after Name, Description, Attributes). List one method per line, showing parameters and types, including return type if not void. For example:
        Methods:
        addScore(points : int)
        totalScore() : double
        If source code, add method headers, but you may leave the bodies empty (if some methods are done, you don't have to remove the bodies).
      • Also show attribute types (e.g., score : double) in the Attributes section.
      • Remember to add any new classes introduced during system design.
      • Order the specifications (or source code) alphabetically within packages (i.e., all classes in the same package are grouped together).
    4. At least two interaction diagrams - sequence type (e.g., Figure 15.1, p. 222), communication type (e.g., Figure 15.2, p. 223), or a combination are acceptable.
      • Ideally, create an interaction diagram for each system event.
      • If a diagram cannot fit neatly on a page, consider splitting it into two diagrams.
    5. One or more statechart diagram(s) - a.k.a. "state machines" - focus on external system events in the context of use cases (see text figure 29.5, p. 491).
  4. Assemble and turn in a complete document - text must be typewritten, but hand-drawn diagrams are okay.
    • Assemble artifacts in the following order - and attach by a single staple in the upper left corner:
      1. Cover page with group ID, project title, and project team (member names).
      2. DA artifacts not revised during SD - system sequence diagrams, followed by system operation contracts.
      3. SD artifacts - in the order listed in part 3 above.
      4. Glossary - be sure to add names and descriptions of all classes, class attributes, associations, system events/operations, packages, methods, and any other new terms introduced to the system during DA and SD. Also remember to revise or delete any existing glossary entries if necessary.
    • Turn in the document before 5:00 pm, Friday, February 5 - as directed by your TA. Late submissions will be subject to grading penalties.
Updated January 17, 2010, by C. Michael Costanzo

CS 50 homepage