[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] w6.html Thu Feb 21 14:21:31 PST 2013


    Assigned Work 6: Using GRASP to design classes

    02005-02-14Copied from W5 and editedRJB
    12009-03-04More specific rules for InteractionsRJB

    (Close Table)


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

    3. SSDs of interesting scenarios

    4. A first logical architecture

    5. Interaction diagrams (sequence or communication).
    6. A design class diagram that supports the interaction diagrams.


    The deliverables form a packet and every element in the packet should be there in the listed order.
    1. At 2more than one (improved?) Interaction diagram (sequence or communication) that handles a system message from your SSD.
    2. At notes indicate the GRASP patterns you used to allocate responsibillities on your interaction diagrams.
    3. At least one improved class diagram that supports the interaction diagram.

    Note: as before each interaction diagram has precisely one found message that is taken from the SSD, and all the interaction diagrams are supported by a single design class diagram.

    Suggested Process

    1. Review previous documentation.
    2. Think and redraw diagrams: interactions+classes.
    3. Do many system events each with a single interaction diagram
    4. Accumulate methods and data into a single design class diagram!
    5. Present interaction and class diagram showing how you used at least one GRASP pattern.
    6. Submit one copy of one interaction digram with one or two GRASP patterns.


    In this and later iterations omitting or misusing GRASP will loose points.

    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. [ 02DiceGameClasses.gif ] (example).
  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 set of objects and/or classes 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 has no value now, 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 and Engineering School, CSUSB".
  16. RUP::Process="Rational UP", a proprietary version of UP.

  17. SSD::="System Sequence Diagrams", see chapter 10 and [ 02DiceGameSSD.gif ] (example).

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

( End of document ) <<Contents | Top