GRASP_Designing Objects With Responsibilities.pdf

© Dr. Khalid Nazim S.A. B.E., M. Tech, MBA[IT], PhD, LMISTE, LMCSI, MIE
Associate Professor,
Department of Computer Science & Information,
Majmaah University, Az- Zulfi Campus, KSA.
CS 413: Software Modeling and Analysis

Week 10
Topics to be Discussed:
 Introduction to object design
 GRASP
 Information Expert
 Creator
 Low Coupling
 High Cohesion
 Controller

“After identifying your requirements and creating a
domain model, then add methods to the software
classes, and define the messaging between the
objects to fulfill the requirements.”
But how?
1. What method belongs where?
2. How should the objects interact?
This is a critical, important, and non-trivial task
Object Design

Introduction to Object Design
Inputs :
1. Use case text :
objects are designed to realize the use cases
2. System sequence diagrams :
identify the system operation messages
3. Operation contracts :
complement the use case.
4. Supplementary Specification :
1. nonfunctional requirements
2. Glossary
5. Domain Model :
help name and attributes of software object.

Object Design
Outputs :
1. UML interaction diagram
2. Class diagram
3. Package diagrams
4. UI sketches and prototypes
5. database models
Remember : not all the input artifacts are necessary.

UP artifacts influencing OO design
Operation:
enterItem(…)
Post-conditions:
- . . .
Operation Contracts
Sale
date
. . .
Sales
LineItem
quantity
1..*
1 . . .
. . .
Domain Model
Use-Case Model
Design Model
: Register
enterItem
(itemID, quantity)
: ProductCatalog
d = getProductDescription(itemID)
addLineItem( d, quantity )
: Sale
Require-
ments
Business
Modeling
Design
Sample UP Artifact Relationships
: System
enterItem
(id, quantity)
Use Case Text
System Sequence Diagrams
make
NewSale()
system
events
Cashier
Process
Sale
: Cashier
use
case
names
system
operations
Use Case Diagram
Supplementary
Specification
Glossary
starting events to
design for, and
detailed post-
condition to
satisfy
Process Sale
1. Customer
arrives ...
2. ...
3. Cashier
enters item
identifier.
inspiration for
names of
some
software
domain
objects
functional
requirements
that must be
realized by
the objects
ideas for
the post-
conditions
Register
...
makeNewSale()
enterItem(...)
...
ProductCatalog
...
getProductDescription(...)
...
1
*
non-functional
requirements
domain rules
item details,
formats,
validation

:Book
d := getDueDate()
getDueDate message implies
Book has responsibility for
knowing its due date.
Design of behavior implies assigning
responsibilities to software classes.
Responsibilities:
contract or obligation of a classifier
Responsibility-Driven Design (RDD)

GRASP Patterns / Principles
Acronym for General Responsibility
Assignment Software Patterns
The GRASP patterns are a learning aid to
1. Help one understand essential object
design
2. Apply design reasoning in a
methodical, rational, explainable
way.
This approach to understanding and using
design principles is based on patterns of
assigning responsibilities.

What’s Responsibility
Doing:
1. Doing something itself, such as creating an object or doing a
calculation
2. Initiating action in other objects
3. Controlling and coordinating activities in other objects.
Knowing:
1. Knowing about private encapsulated data
2. Knowing about related objects
3. Knowing about things it can derive or calculate

Responsibilities and Methods
: Sale
makePayment(cashTendered)
: Payment
create(cashTendered)
abstract, implies Sale objects have a
responsibility to create Payments

Responsibility Assignment is the Key
 Appropriate assignment of responsibilities
to classes is the key to successful design.
 There are fundamental principles in
assigning responsibilities that experienced
designers apply.
 These principles are summarized in the
GRASP patterns.

GRASP:
Defines nine basic OO design principles. memorization and application of these
patterns are critical for successful object-oriented designs.
1. Creator.
2. Information Expert.
3. Controller.
4. Low Coupling.
5. High Cohesion.
6. Polymorphism.
7. Pure Fabrication.
8. Indirection.
9. Protected Variations.
Memorizing and applying
these nine principles during
every design exercise is the
primary course objective.
General Responsibility Assignment Software Patterns

GRASP Patterns
Which class, in the general case is responsible?
1. You want to assign a responsibility to a class
2. You want to avoid or minimize additional
dependencies
3. You want to maximise cohesion and minimise
coupling
4. You want to increase reuse and decrease
maintenance
5. You want to maximise understandability etc..

Creator
Who should create an instance of a particular class?
Consider assigning Class B the responsibility to create an instance of
class A if one of the following is true:
1. B contains A.
2. B aggregates A.
3. B records A.
4. B closely uses A.

Partial POS domain model
Sale
time
Sales
LineItem
quantity
Product
Description
description
price
itemID
Described-by
*
Contains
1..*
1
1

Creating a SalesLineItem
: Register : Sale
makeLineItem(quantity)
: SalesLineItem
create(quantity)
1. Sale objects are given a responsibility to create Payments.
2. The responsibility is invoked with a makePayment message

Creating a Book
:Catalog
makeBook(title)
1: create(title)
:Book
by Creator

Information Expert
What is a basic principle by which to assign responsibilities to objects?
1. Assign a responsibility to the information expert —
2. The class with the information necessary to fulfill the responsibility.
:Library
borrowResource(callNum)
1: r := getResource(callNum): Resource
:Catalog
Catalog is an information expert on
finding and returning a resource,
based on a call number. It logically
contains all of them.
by Expert
What class should be responsible for
knowing a resource, given a call number?

Applying Expert in POS Application
Start assigning responsibilities by clearly stating the responsibility.
Who should be responsible for knowing the grand total of a sale?
Where do we look for the classes that have the information needed?
1. First, in the Design Model.
2. If no relevant classes there, look in the Domain Model, and add a
corresponding software class to the Design Model.

Associations of Sale in Domain Model
Sale
time
Sales
LineItem
quantity
Product
Description
description
price
itemID
Described-by
*
Contains
1..*
1
1

Partial Interaction and Class diagrams
Sale
time
...
getTotal()
:Sale
t = getTotal
New method
1. Adding a Sale class to the Design Model supports low representational gap.
2. Express responsibility of knowing the total of a sale with the method named
getTotal.
What information do we need to know to determine the line item subtotal?

SalesLineItem is Expert for Subtotal
Sale
time
...
getTotal()
SalesLineItem
quantity
getSubtotal()
New method
1 *: st = getSubtotal
: Sale
t = getTotal lineItems[ i ] :
SalesLineItem
this notation will imply we
are iterating over all
elements of a collection
How does the SalesLineItem find out the product price?
“Partial” information experts collaborate to fulfill the responsibility.

Product Description is Expert for Price
Sale
time
...
getTotal()
SalesLineItem
quantity
getSubtotal()
Product
Description
description
price
itemID
getPrice()
New method
:Product
Description
1.1: p := getPrice()
1 *: st = getSubtotal
: Sale
t = getTotal lineItems[ i ] :
SalesLineItem

GRASP_Designing Objects With Responsibilities.pdf

The Low Coupling Principle
Problem : Reduce the impact of change.
Solution: Assign responsibilities so that coupling remains low.
Use this principle to evaluate alternatives.
Coupling: how strongly one element is connected to, has knowledge of,
or relies on other elements.
1. Low coupling tends to reduce the time, effort, and defects in
modifying software.
2. Coupling per se is not a problem, only coupling to elements that
are unstable (likely to change).

Low Coupling in POS Case Study
What class should be responsible for creating a Payment instance
and associating it with the Sale?
1. Register?
2. Sale?
Creator pattern suggests Register should create the Payment.
A register records a payment in the real world.

Register creates Payment
: Register p : Payment
:Sale
makePayment() 1: create()
2: addPayment(p)
Register is coupled to both Sale and Payment.

Sale creates Payment
: Register :Sale
:Payment
makePayment() 1: makePayment()
1.1. create()
• Assuming that the Sale must eventually be coupled to
knowledge of a Payment, having Sale create the
Payment does not increase coupling.
– Low Coupling and Creator suggest different solutions.

Common Forms of Coupling in OO Languages
1. Type X has an attribute (data member, instance variable) that refers
to type Y or an instance of Y.
2. An object of type X calls on services of a type Y object.
3. Type X has a method that references an instance of type Y
(e.g., parameter, local variable, object returned from a method).
4. Type X is a subclass of type Y.
5. Type X implements the interface Y.

Controller Pattern
What first object beyond the UI layer receives and coordinates (“controls”) a
system operation message?
Solution:
Assign the responsibility to a class that represents one of the following options:
Option 1a: Represents the overall system or a root object.
E.g., an object called MonopolyGame.
Option 1b: Represents the device the software is running within.
E.g., Phone or BankCashMachine.
Not applicable in the Monopoly case.
Option 2: Represents the use case or session.
E.g., PlayMonopolyGameHandler.

Remind from analysis:
System Operations of POS Application

System Operations of POS Application
System
endSale()
enterItem()
makeNewSale()
makePayment()
. . .
During analysis, system operations may be
assigned to a System class.
1. Does not mean a software class
named System fulfills the system
operations during design.
2. During design, a controller class is
assigned the responsibility for
system operations.

What should be Controller for enterItem?

Controller choices ?
:Register
enterItem(id, quantity)
:ProcessSaleHandler
enterItem(id, quantity)
1. In the POS domain, Register (POS Terminal) is a specialized device
with software running on it.
2. ProcessSaleHandler represents a receiver of all system events of a
use case scenario.

Allocation of System Operations
Register
...
endSale()
enterItem()
makeNewSale()
makePayment()
makeNewReturn()
enterReturnItem()
. . .
System
endSale()
enterItem()
makeNewSale()
makePayment()
makeNewReturn()
enterReturnItem()
. . .
system operations
discovered during system
behavior analysis
allocation of system
operations during design,
using one facade controller
ProcessSale
Handler
...
endSale()
enterItem()
makeNewSale()
makePayment()
System
endSale()
enterItem()
makeNewSale()
makePayment()
enterReturnItem()
makeNewReturn()
. . .
allocation of system
operations during design,
using several use case
controllers
HandleReturns
Handler
...
enterReturnItem()
makeNewReturn()
. . .
During design, system operations identified during system behaviour analysis are
assigned to one or more controller classes.

Delegation
UI layer objects delegate system events to another layer.
1. UI layer shouldn’t contain application logic.
2. Increases potential for reuse.
3. Can “unplug” UI layer – use a different framework or run in
offline “batch” mode.
Controller should delegate the work that needs to be done to other
objects.
 It controls or coordinates the activity.

Desirable coupling of UI and domain layers

Undesirable coupling of UI to domain layer

Facade(Front/ Cover) Controller
Facade controller represents the overall system, device, or subsystem.
1. A façade or cover over other layers.
2. Abstraction of overall physical unit
e.g., Register, TelecommSwitch, Robot, or
3. Class representing entire system or concept
e.g., POSSystem, ChessGame.
4. Suitable when there are not too many system events or when UI
cannot choose between multiple controllers.

Use Case Controller
A use case controller handles system events for a single use case.
1. Can maintain information about the state of the use case.
E.g., detect out-of-sequence system events.
2. Different controller for each use case.
3. Not a domain object, but artificial construct (“pure fabrication”) to
support the system.
4. Use when there are many system events.
5. Factors handling into separate classes.

:Library
by Controller
Controller - Facades
1. Facades are “covers.”
2. Intent - A class that (in some way) represents an overall cover.
3. Many possibilities.
Example: The entire organization.

:LibSystem
:LibInfoSystem
Controller - Facades
Other facades? A class representing the “system.”
Examples:
1. The software information system.
2. The device that includes a computer and software such as an ATM.

High Cohesion
Solution
Assign a responsibility so that cohesion remains high
Problem
How to keep complexity manageable?
Cohesion is a measure of how strongly related and focused the responsibilities of an
element (classes, subsystems) are
A class with low cohesion does many unrelated things, or does too much work
They suffer from the following problems:
1. hard to understand
2. hard to reuse
3. hard to maintain
4. delicate; constantly effected by change

Benefits of High Cohesion
1. Clarity and ease of comprehension of the design is increased.
2. Maintenance and enhancements are simplified.
3. Low coupling is often supported.
4. The fine grain of highly related functionality supports increased
reuse because a cohesive class can be used for a very specific
purpose.

Reduced cohesion of Register(creator pattern)
: Register : Sale
addPayment( p )
p : Payment
create()
makePayment()
Low cohesion:
Register is taking part of the responsibility for fulfilling “makePayment” operation and
many other unrelated responsibility ( 50 system operations all received by Register).then it
will become burden with tasks and become incohesive

Higher Cohesion and Lower Coupling
: Register : Sale
makePayment()
: Payment
create()
makePayment()
Solution:
Delegate the payment creation responsibility to “Sale” to support high cohesion

 In Object-Oriented Analysis and Design (OOAD), General Responsibility
Assignment Software Patterns (GRASP) play a crucial role in designing effective
and maintainable software systems.
 GRASP offers a set of guidelines to aid developers in assigning responsibilities to
classes and objects in a way that promotes low coupling, high cohesion, and overall
robustness.
 By understanding and applying GRASP principles, developers can create software
solutions that are flexible, scalable, and easier to maintain over time.
Summary

GRASP_Designing Objects With Responsibilities.pdf

More Related Content

Similar to GRASP_Designing Objects With Responsibilities.pdf (20)

More from nazimsattar (20)

Recently uploaded (20)

GRASP_Designing Objects With Responsibilities.pdf