Contents

• CSci 375/12 GRASP I
• Revision History
• The GRASP Patterns
• : What is a pattern
• : What is GRASP?
• : 17.1 UML vs Principles
• : 17.2 Object Design
• : Figure 17.1 How it all fits together
• : 17.3 Responsibilities -- things that objects know how to do
• : 17.4 GRASP -- good ways to allocate responsibilities to objects
• : 17.5 Connections
• : 17.6 Patterns
• : 17.7 Summary: process, responsibility metaphor, patterns, UML
• : 17.8 Short Example: Monopoly
• : 17.9 Applying GRASP
• : Beware the System Object
• : 17.10 Creator
• : 17.11 Information Expert
• : 17.12 Low Coupling
• : 17.13 Controller
• : 17.14 High Cohesion
• : 17.15 Resources
• Questions and Answers
• Exercises
• Next -- GRASP 1
• Project Step 5 Interactions and Classes
• Review Questions
• Standard Definitions

CSci 375/12 GRASP I


Table

Date	#	Topic (Participation 2pt)	Study pages (2 pts)	Quiz(15 pts)	Project Work(10 pts)
Previous	11	Class Diagrams	248-270	Q5(221-270)	-
Today	12	GRASP	271-319	-	W5(Interaction & Class Diagrams)
Next	13	Object Design	320-362	Q6(271-362)	-


(Close Table)


Revision History


Table

Version#	Date	Description	Author
0	2005-01-03	Used boiler plate to make template	RJB
1	2005-01-14	Added Chapter headings and Notes	RJB
2	2006-02-14	Updated to new look	RJB
3	2007-01-10	Added project link	RJB
4	2012-02-13	Added 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.
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!

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.

    

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.

    

    [ patterns.html#IDs_to_Objects ]

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

    

    [ 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 ]

Exercises

[ 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

Standard Definitions