[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] 12.html Mon Feb 13 15:55:20 PST 2012


    CSci 375/12 GRASP I

    Date#Topic (Participation 2pt)Study pages (2 pts)Quiz(15 pts)Project Work(10 pts)
    Previous11Class Diagrams248-270Q5(221-270)-
    Today12GRASP271-319-W5(Interaction & Class Diagrams)
    Next13Object Design320-362Q6(271-362)-

    (Close Table)

    Revision History

    02005-01-03Used boiler plate to make templateRJB
    12005-01-14Added Chapter headings and NotesRJB
    22006-02-14Updated to new lookRJB
    32007-01-10Added project link RJB
    42012-02-13Added pictures RJB

    (Close Table)

    The GRASP Patterns

    1. *** The GRASP patterns tell you what classes you may need, what operations they will need, and what messages they will send. The give a reason for each arrow and object in your interaction diagrams.
    2. **** When you read this chapter take note of how Larman documents the use of GRASP. He links a message to its objects with a GRASP pattern name. Do this in your projects in this class.

      What is a pattern

      An Example Pattern: The Pizza Inversion Pattern [ pizza-inv.html ] (Ho Ho Only Serious).

      What is GRASP?

      (see GRASP below).

      17.1 UML vs Principles

    3. * UML lets you communicate, recall, store ideas...
    4. * Principles help you choose the right way to go, make decisions and choices.

      17.2 Object Design

    5. ** OO design is about choosing who does what inside the computers.

      Figure 17.1 How it all fits together

      Artifacts and Relations in the UP [ artifactrelationships.gif ]

      17.3 Responsibilities -- things that objects know how to do

    6. * The R in gRasp.
    7. **** Objects are little capsules of intelligence.
    8. **** They know how and know what: they have operations and attributes.
    9. **** Responsibilities -- things an object can be trusted to do or recall.

      17.4 GRASP -- good ways to allocate responsibilities to objects

    10. Exercise: name as many GRASP as you can from memory.

      Here [ 16answer.html ] are the 9 GRASP principles/patterns

      17.5 Connections

      17.6 Patterns

    11. *** a workable resolution to a set of conflicting forces.
    12. * Patterns are the P in GRASP.
    13. * A Pattern is a "good enough" way of solving a complex problem. It balances the competing forces in a sensible way. It has been used on at least three similar situations. Patterns are found and recorded not created.

    14. * Patterns resolve a set of forces in a repeatable and useful way.

    15. *** See inside cover of book.
    16. See my notes [ patterns.html ]
    17. See the famous [ wiki?CategoryPattern ]
    18. See Brad Appletons Documents [ http://www.cmcrossroads.com/bradapp/docs/ ]

    19. For more Patterns and discussions of patterns see [ wiki ] (The WikiWikiWeb).
    20. Also checkout the Wikipedia entry [ GRASP_%28Object_Oriented_Design%29 ]

      17.7 Summary: process, responsibility metaphor, patterns, UML

      17.8 Short Example: Monopoly

    21. Exercise: can you reconstruct this example without looking at the book?
    22. By the way here is a first rough transcription of these figures into C++: [ testPlayMonopoly.cpp ]

      17.9 Applying GRASP

      The GRASP patterns or principles give hints as to which class does what. When you know that something must be done in your software..... GRASP guides you to the classes that will do it.

      Beware the System Object

      We are designing the contents of the system and so it must not appear in any design diagrams.

      17.10 Creator

    23. * This only applies to the operation of constructing a new object. Who does it? Who calls the constructor?
    24. *** take note of the suitable creators for an object. Make a list. Learn them!
    25. ** learn the sequence diagram notation
    26. *** This pattern suggests where the create function is called. In other words it tells you where the arrow should come from, not where it goes to. Create messages always go to a class.
    27. +++ The creator of a class of objects can also be made responsible for managing them: Deleting them, keeping lists of them, finding an object with a property, etc. But this may make it less cohesive and force others to be coupled to the creator.
    28. Creator::pattern=creating an object should be the responsibility of a class that is closely related to the created object. [owners and close friends make good creators]
    29. ++ you always need at least one way of creating an object that doesn't depend on already having an object of that type already. So which class or object is close enough to the created object.
    30. + Or else you can use a GoF Factory -- a GRASP Pure Fabrication (later). This is for creating complex polymorphic objects.
    31. ++ Danger: in the book the Creator pattern is limitted by the "High Cohesion" pattern (later). The "High Cohesion" pattern is a lot more than the Creator pattern. Pure_Fabrication.

      17.11 Information Expert

    32. A very powerful idea.
    33. Expert::pattern=allocate a responsibility to a class that has the information. Look in both the design classes and the domain model to find a type of object that knows enough to handle the responsibility. Knowledge includes having the data, and also knowing who has got the data! [Look for info in the domain]

    34. *** Tends to incorporate parts of the domain model into the software design.

      17.12 Low Coupling

    35. ***** Coupling has guided good software design for nearly 40 years.
    36. + Reduce dependencies between objects.
    37. Low_coupling::pattern=Assign a responsibilities so that class depends less on other classes using a "need to know basis". Organize responsibilities so that classes do not depend on each other two much.

      17.13 Controller

    38. Controller::pattern=Assign the responsibility for handling system event messages to a class representing either the whole system, device, or subsystem, or representing the use case /scenario within which the system event occurs.
    39. **** Don't fill up user interface classes with domain/business stuff.
    40. ** Don't clutter Doamin information with particular how a use case works.
    41. ***** You can ONLY use the controller pattern when the incoming message is from the User Interface.
    42. ** Controlers are only occasionally objects in Domain Model classes. Since these get messages because they know about real objects.
    43. Take note of the suitable controlers. Learn them.

      [Possible controllers]

    44. +++ A controler is often responsible for finding an object when the user supplies an identifier. See "IDs to Objects" on page 460 for the reasons for passing objects rather than ids. However the controler should not search for matching IDs. It should get help from parts of the domain layer, for example a Creator or a metaclass to find the right object. The found object can then be returned to the controller and passed to other parts of the system.

      [Controller asks creator to convert ID to Object]

      [ patterns.html#IDs_to_Objects ]

    45. **** Separate the model and view by a controler.

      Model-View-Controller packages in the UML

      [ patterns.html#MVC ]

    46. + Some people dislike use case/session controlers.
    47. ++ A scenario/use case controler is natural when the logic of the use case is complicated.
    48. + View is often technology dependent and Controllers determined by the user's needs of the moment.
    49. + The "model" or domain layer is independent of technology and inspired by the domain or business model.

      17.14 High Cohesion

    50. This is a general purpose rule.
    51. **** Cohesion has guided good software design for nearly 40 years.
    52. + Separate concerns into different classes.
    53. + place responsibilities to give focussed objects.
    54. High_cohesion::pattern=Design elements to have strongly related and focused responsibilities".

    55. + Ballancing cohesion and coupling is an art form.

    56. + The Controller Pattern often comes into conflict with High Cohesion in some designs. When it does look for smaller Controllers that can be more Cohesive.

    57. + The Creator Pattern comes into conflict with High Cohesion in some designs. When it does look for smaller Creators that can be more Cohesive.

      17.15 Resources

    . . . . . . . . . ( end of section The GRASP Patterns) <<Contents | End>>

    Questions and Answers

    [ 12q.html ]


    [ 12x.html ] Possble handout....

    Next -- GRASP 1

    Start by reviewing the [ 13.html ] on Object Design with GRASP.

    Project Step 5 Interactions and Classes

    [ w5.html ] is due next class.

Review Questions

[ 12r.html ]

Standard Definitions

  • Artifact::="Anything that is created in the course of a project".
  • artifact::=see above.
  • DCD::diagram="Design Class Diagram", shows the classes that will be implemented in code.
  • Deliverables::="A packet of artifacts that must be prepared by a deadline for review or distribution".
  • Glossary::= See http://cse.csusb.edu/dick/cs375/uml.glossary.html.
  • GoF::="Gang of Four", [ patterns.html#GoF ]
  • 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 ]
  • Grades::= See http://cse.csusb.edu/dick/cs375/grading/.

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

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

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

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

  • RJB::=The author of this document, RJB="Richard J Botting, Comp Sci and Engineering School, CSUSB".
  • RUP::Process="Rational UP", a proprietary version of UP.

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

  • TBA::="To Be Announced".

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

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

  • 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".

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