[Skip Navigation] [ CSUSB ] / [CNS] / [CSE] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Schedule] [Syllabus]
Session: [01] [02] [03] [04] [05] [06] [07] [08] [09] [10] [11] [12] [13] [14] [15] [16] [17] [18] [19] [20]
[Text Version] w7.html Wed Jan 11 07:26:30 PST 2012


    Assigned Work 7: The Second complete set of Models

    02005-03-03Copied from W6 and editedRJB
    12005-03-03More specific rulesRJB

    (Close Table)
    We are now two thirds of the way through the course and you should have collected a lot of ideas about your project: Requirements, domain, and design.

    Now is the time to review it and redo as needed.


    1. Requirements
      • Vision
      • Business Case
      • Use Cases
      • SSDs of interesting scenarios
      • Supplementary Specifications(if any)
      • Business Rules(if any)
      • Glossary
    2. Domain model (classes, associations, and some attributes)
    3. Design
      1. A first logical architecture
      2. Interaction diagrams (sequence or communication).
      3. DCD -- Design Class Diagram that supports the interaction diagrams.

    Paper Deliverables

    The deliverables form a packet and every element in the packet should be there in the listed order. Model 2:
    1. Vision + Business case
    2. Use cases: more fully dressed ones... more scenarios
    3. Use case model
    4. Supplementary specifications: desirable qualities.
    5. Domain model
    6. Architecture -- package diagram
    7. Glossary: define your terms
    8. Business Rules: any special domain rules.
    9. System Sequence Diagrams for some interesting scenarios.
    10. Interactions: sequence or communication diagrams for some interesting messages in your SSD. One interaction per interesting message!
    11. Design classes that support your interactions. All in a single design class diagram.
    12. Include some comments explaining why (GRASP) you choose that assignment of messages to classes.

    In Class Deliverable

    Present the most exciting (least boring?) discovery you made in creating the paper work.

    Special rule for 2008: NO Logins!


    1. Review previous documentation.
    2. Think...
    3. Add new scenarios and use cases...
    4. Think and edit existing...


    Everything should fit together. This time I will be requiring better use of GRASP.

    Standard Definitions

  1. Artifact::="Anything that is created in the course of a project".
  2. artifact::=see above.
  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  5. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  6. GoF::="Gang of Four", [ patterns.html#GoF ]
  7. GRASP::patterns="General Responsibility Assignment Software Patterns", a set of guidelines for designing objects and classes. They take a single event that the system must handle and determine a good class to carry it out. See [ patterns.html#GRASP -- General Responsibility Assignment Software Patterns ]
  8. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  9. KISS::Folk_law="Keep It Simple, Stupid", in agile processes this means never drawing a diagram or preparing a document that doesn't provide value to the clients and stakeholders. In all processes it means never designing or coding what is not needed, see YAGNI.

  10. OO::shorthand="Object-Oriented".

  11. OOAD::="Object-Oriented Analysis and Design", See chapter 1 in text.
  12. patterns::="Documented families of problems and matching solutions", see Patterns.
  13. Patterns::= See http://cse.csusb.edu/dick/cs375/patterns.html.

  14. Process::="How to develop software".

  15. RJB::=The author of this document, RJB="Richard J Botting, Comp Sci Dept, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

  17. SSD::="System Sequence Diagrams", see chapter 10.

  18. TBA::="To Be Announced".

  19. UML::="Unified Modeling Language". [ Unified_Modeling_Language ]

  20. UP::="Unified Process", an iterative, risk-driven, and evolutionary way to develop OO software.

  21. YAGNI::XP="You Ain't Gonna Need It", an XP slogan that stops you planning and coding for things that are not yet needed. As a rule the future is not predictable enough to program a feature until the stakeholders actually need now. In this class it also means "It won't be on the final or in quizzes".

  22. XP::="Extreme Programming", the ultimate iterative, code-centric, user-involved process.