[Skip Navigation] [ CSUSB ] / [CNS] / [Comp Sci & Engineering] / [R J Botting] / [CS375] [Search ]
[About] [Contact] [Grades] [Objectives] [Patterns] [Projects] [Question] [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] w8.html Mon Sep 28 15:48:39 PDT 2009

Contents

    Assigned Work 8: The Third complete set of Models
    Table
    Version#DateDescriptionAuthor
    02005-03-04Copied from w7 and editedRJB
    12005-03-07CorrectedRJB

    (Close Table)

    Given
    1. Requirements
      • Vision
      • Business Case
      • Use Cases
      • Supplementary Specifications(if any)
      • Business Rules(if any)
      • Glossary
    2. Design
      • Domain model with classes, associations, and some attributes.

      • SSDs of interesting scenarios

      • A first logical architecture

      • Interaction diagrams (sequence or communication). (with GRASP)
      • a class diagram that supports all the interaction diagrams.

    In Class Deliverable

     Walk through another application of GRASP and or GoF in your project. Present a class diagram and interaction diagram that illustrates one GRASP or GoF.

    Paper Deliverables by standard deadline

     Model 3:
    1. Vision + Business case
    2. Use cases: more fully dressed ones... more scenarios
    3. Use case diagram
    4. Supplementary specifications: desirable qualities.
    5. Domain model class diagram.
    6. Glossary: define your terms
    7. Business Rules: any special domain rules.
    8. System Sequence Diagrams for some interesting scenarios.
    9. Interactions: sequence or communication diagrams for most of the interesting messages in your SSD.
    10. Design classes that support your interactions. With some comments explaining why (GRASP or GoF) you choose your design.

    Process
    1. Review previous documentation.
    2. Check the following list of common mistakes [BollojuLeung06] to see if you've done them.
    3. Think...
    4. Add new scenarios and use cases... Look for GRASP and GoF opportunities in your design.
    5. Think and edit existing...
    6. Walkthrough new stuff in class.

    Grading

     Everything should fit together.

    GRASP and GoF used properly.

    Standard Definitions

  1. CS202::= See http://cse.csusb.edu/dick/cs202/.
  2. CS372::= See http://cse.csusb.edu/dick/cs372/.

  3. DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  4. DRY::XP="Don't Repeat Yourself".

  5. ESSUP::Process= See http://www.ivarjacobson.com/essup.cfm, Ivar Jacobsen simplified "Essential" UP.

  6. Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  7. GoF::="Gang of Four", [ patterns.html#GoF ]
  8. 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 ]
  9. Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

  10. 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.

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

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

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

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

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

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

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

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

  22. 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 it now. In this class it means "It won't be on the final or in quizzes".

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

End