6/12/2010

Software Engineering
Introduction to GRASP

Readings
y “Applying” Chapter 17
◦ GRASP: Designing Objects with
Responsibilities

y R. Wrifs-Brock, A. McKean
◦ Object Design: Roles, Responsibilities,
and Collaborations

1
 6/12/2010

The Design Context

Design
Classes
Domain
Classes
Domain Model UML Diagrams

Use Case Use Cases

Design UI Prototypes
Model SSD
Contracts

Supplementary Report
Specification Sketches
NFRs

Database
Models

UML vs. Design Principles

y The critical design tool for software
development is a mind well educated
in design principles.

y It is not the UML or any other

technology.

2
 6/12/2010

Responsibility
y A contract or obligation of a classifier
y Doing Responsibilities
◦ creating an object or doing a calculation
◦ initiating action in other objects
◦ coordinating activities in other objects

y Knowing Responsibilities
◦ knowing about private encapsulated data
◦ knowing about related objects
◦ knowing about things it can derive or calculate

Example
y Sale Responsibilities
◦ Creating SalesLineItem objects
◦ Knowing its total

y Granularity of responsibilities
y Responsibilities
p and Methods

3
 6/12/2010

GRASP
y 9 Patterns for assigning
responsibilities

y Patterns or principles?
◦ One person's pattern is another person's
primitive building block.

Some GRASP Patterns

Information
Creator
Expert

Low Coupling Controller

High
Cohesion

4
 6/12/2010

The Creator Pattern

Name Creator
Problem Who creates an A?
Solution Assign class B the responsibility to create
an instance of class A if one of these is true:
• B "contains" or compositely aggregates A.
• B records A.
A
• B closely uses A.
• B has the initializing data for A.

Who creates Square object?

Domain Model

10

5
 6/12/2010

Applying Creator

Dynamic
y Model

Static Model

11

The Information Expert Pattern

Name Information Expert

Problem What is a basic principle by which to assign
responsibilities to objects?

Solution Assign a responsibility to the class that has

the information needed to fulfill it.

12

6
 6/12/2010

Who knows about a Square object,

given a key?

13

The Low Coupling Pattern

Name Low Coupling

Problem How to reduce the impact of change?

Solution Assign responsibilities so that

(unnecessary) coupling remains low. Use
this principle to evaluate alternatives.

14

7
 6/12/2010

Coupling
y A measure of how strongly one
element is connected to
to, has
knowledge of, or depends on other
elements.

y Examples
◦ A subclass is strongly coupled to a superclass.
◦ An object A that calls on the operations of object
B has coupling to B's services.

15

Why Board over Dog?

16

8
 6/12/2010

Notes on Coupling
y Why is it bad?
y Strong and weak coupling
y Coupling to unstable objects

17

Common Forms of Coupling

y X has an attribute of Y
y A X object
j calls on services of a Y
object
y X has a method that references an
instance of Y
◦ Parameter, local variable, return value
y X is a direct or indirect subclass of Y
y Y is
i an iinterface,
t f andd X iimplements
l t
that interface
y X and Y access to a common shared
data
18

9
 6/12/2010

The Controller Pattern

Name Controller

Problem What first object beyond the UI layer receives and

coordinates ("controls") a system operation?
Solution Assign the responsibility to an object representing
one of these choices:
z The overall "system," a "root object," a device that
the software is running within,
within or a major subsystem
(these are all variations of a facade controller).
z A use case scenario within which the system
operation occurs (a use case or session controller)

19

SSD for Monopoly Game

20

10
 6/12/2010

Who is the controller?

21

Using Option 1
One controller per system

22

11
 6/12/2010

The High Cohesion Pattern

Name High Cohesion

Problem How to keep objects focused, understandable, and

manageable, and as a side effect, support Low
Coupling?

Solution Assign responsibilities so that cohesion remains

high. Use this to evaluate alternatives.

23

Cohesion
y Measures how functionally related the
operations of a software element are, and also
measures how much work a software element
is doing.
y Example
◦ Big: 100 methods – 2000 SLOC
◦ Small: 10 methods – 200 SLOC
y Low Cohesion ⇔ High Coupling

24

12
 6/12/2010

Cohesion Example

25

Notes on Cohesion
y Why is “low cohesion” bad?
y When lower cohesion is justified?
y How do you measure cohesion?

26

13