SWEN30006
Software Design and Modelling
GRASP:
More Objects with Responsibilities
Textbook: Larman Chapter 25
“Luck is the residue of design.” —Branch Rickey
Learning Objectives
On completion of this topic you should be able to:
• Apply four of the GRASP principles or patterns for Object-Oriented Design.
– Polymorphism – Indirection
– Pure Fabrication
– Protected Variation
3
(Revisited) GRASP: General Responsibility Assignment Software Patterns/Principles
• GRASP – Definition: A set of patterns (or principles) of assigning responsibilities into an object.
• GRASP aids in applying design reasoning in a methodical, rational, and explainable way
– Given a specific category of problem, GRASP guides the assignment of
responsibilities to objects
• Useful to know and support Responsibility-Driven Design (RDD)
• Pattern – Definition:
– A named and well-known problem/solution pair that can be applied in new contexts
– A recurring successful application of expertise in a particular domain
4
(Last Week) GRASP: Learning Aid for RDD
• This subject will cover the 9 GRASP patterns/principles – Creator
– Information Expert
– Low Coupling
– High Cohesion
– Controller*
– Polymorphism
– Indirection
– Pure Fabrication
– Protected Variations
*Controller will be covered in Workshop 5 supplementary material
(This Week) GRASP: Learning Aid for RDD
• This subject will cover the 9 GRASP patterns/principles – Creator
– Information Expert
– Low Coupling
– High Cohesion
– Controller*
– Polymorphism
– Indirection
– Pure Fabrication
– Protected Variations
But first …
More about Domain Model: Generalization-specialization hierarchy
*Controller was covered in Workshop 6 supplementary material
Domain Model:
Generalization- specialization hierarchy
8
Domain Model: Similar Concepts
• In the problem domain, there might be concepts that look very similar Week 2 Lecture’s exercise: Identifying conceptual class
The library has users who can borrow items.
The library holds both books and videos: all items have a title and year of production (and a due date if they have been borrowed), while only books have authors and only videos have a duration
There are different kinds of users: students, staff, and guests. The only difference between these user types is that they have a different borrowing limit (max number of items they can borrow) which is based on their user type.
The library keeps track not only of which items are out on loan now, but the complete history of which users borrowed which items for which periods.
Partial domain model
– The conceptual classes are not well organized.
– The association between items, books, and video is missing. Same for users
9
• •
When concepts are very similar, it is valuable to organise them
Generalization: The activity of identifying commonality among concepts
– Define superclass (general concept)
– Define relationships with subclasses (specialized concepts)
– Conceptual subclasses and superclasses are related
in terms of set membership
Superclass (General Concept)
Subclass (Specialized Concept)
Domain Model: Generalization-Specialization Class Hierarchy (or Class Hierarchy)
Payment
• Why? these are conceptual classes, not software
– Economy of expression
– Reduction in repeated information
– Improved comprehension
The class hierarchy of the domain model often inspires the design of software objects in the design model.
A Domain Class Model
classes
Cash Payment
Credit Payment
Check Payment
See more in Textbook Chapter 31
10
supercla
concept
s
Domain Model: Generalization-Specialization Class Hierarchy (or Class Hierarchy)
Guideline for creating subclasses:
1. Subclass has additional attributes of interest
2. Subclass has additional associations of interest
3. Subclass is operated on, handled, reacted to, or manipulated differently to the other classes in noteworthy ways
Modelling Guidelines:
a) Declare superclasses abstract
b) Append the superclass name to the subclass
11
Class Hierarchy: Example
The library has users who can borrow items.
The library holds both books and videos: all items have a title and year of production (and a due date if they have been borrowed), while
only books have authors and only videos have a duration
There are different kinds of users: students, staff, and guests. The only difference between these user types is that they have a different
borrowing limit (max number of items they can borrow) which is based on their user type.
The library keeps track not only of which items are out on loan now, but the complete history of which users borrowed which items for which periods.
Use r
– kind :{student, staff, guest} – borrowLimit
Loan
– returned?
item
– title
– yearProduced – due :Date
book
– authors
loaned to on loan 1**1
Partial domain model
No difference in behaviours or attributes so can’t justify different user kinds as different classes.
Number of unreturned load should not exceed borrowLimit
video
– duration
12
GRASP: Polymorphism
13
Polymorphism
• Problem (1): How handle alternatives based on type?
– Conditional variation: Adding new alternatives and if-then-else (or case-statement) are required
many places
– E.g., behaviour varies based on some conditions
• Problem (2): How to create pluggable software components?
– E.g., Client-Server relationship: How to replace Server component without affecting Client?
• Solution: When related alternatives or behaviors vary by type (class), assign responsibility for the behavior—using polymorphic operations—to the types for which the behavior varies
– Polymorphic operations: Operations with the same interface
– Corollary: Do not test for the type of an object and use conditional logic to perform varying alternatives based on type.
14
Example: Monopoly
Monopoly Game Simulation Domain Model
Use case: When a player lands on a square, different actions will occur based on the types of square, e.g.,
• “Go Square”: A player receives $200
• “Income Tax”: A player pays a tax of the income
• “Regular Square”: A player does nothing
Realization: The different types of Square can be seen as concepts in the domain as well. It should be captured in the domain model
→ Since the concepts are similar, use a generalization specialization class hierarchy (class hierarchy) to organize these concepts
15
Example: Monopoly – Update Domain Model Use case: When a player lands on a square, different
actions will occur based on the types of square, e.g.,
• “Go Square”: A player receives $200
• “Income Tax”: A player pays a tax of the income
• “Regular Square”: A player does nothing
Monopoly Game Simulation Domain Model
16
Example: Monopoly – Create Design Model (1)
Observation: Based on Use case and domain model, a different type of square has a different rule (i.e., behaviour)
Corollary: We should not design of our software objects with case logic (e.g., a switch statement)
→ If a switch case (or if-else) is used in Square class, the class can have low cohesion and can be bloated!
Monopoly Game Simulation Domain Model
17
Example: Monopoly – Create Design Model (2)
Analysis: There are alternatives based on type of Squares → Polymorphism should be used.
Approach: Based on Polymorphism, we should create a polymorphic operation for each type for which the behavior varies.
• What are types that Square varies?
→ ”Go Square”, “RegularSquare”, “IncomeTaxSquare”, so on
• What is the operation that varies?
→ The behaviour of Square will vary when a player lands on a square
→ Then, the responsibility of “landedOn” should be a polymorphic operation
Use an abstract class to create a common interface
Partial design model
Implements landedOn operation based on type
18
Example: Monopoly
The behaviour of square is based on the type of Square that Board returns to Player
19
Polymorphism: Discussion
• Polymorphism is a fundamental pattern in designing how a system is organised to handle similar variations
– Based on Polymorphism, a design is easily extended to handle new variations
• Contraindications:
– Designing systems with interfaces and polymorphism for speculative “future-
proofing” against an unknown variation could be useful.
– However, the unnecessary effort might occur if polymorphism is applied at the points where variations, in fact, are improbable and will never actually arise.
20
GRASP:
Pure Fabrication
21
Pure Fabrication
• Problem: Which object should have responsibility when you do not want to violate High Cohesion and Low Coupling, but solutions offered by other patterns (e.g. Expert) are not appropriate?
– Domain model often inspires the design of software objects (achieving low representational gap)
– In many situations, assigning responsibilities only based on the domain model often leads to the problem of poor cohesion or coupling.
• Solution: Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept
– Made up a class to support high cohesion, low coupling, and reuse
22
Example: Monopoly
Who should be responsible for rolling the dice?
• Based on the domain model & Expert, MonopolyGame class should be assigned for this responsibility
Discussion: It is acceptable, but leads to low cohesion
Based on the domain model, the design can violate high cohesion
Let’s use Pure Fabrication!
Monopoly Game Simulation Domain Model
23
Example: Monopoly
Who should be responsible for rolling the dice?
Solution: By Pure Fabrication, let’s create an artificial class which is responsible for rolling dice
In the domain, Cup was not used in Monopoly Game
24
Pure Fabrication: Contraindications
• Pure Fabrication should not be used as excuse to add new objects
• If overused Pure Fabrication, the design can end up with one class has one
responsibility
– Too many behavior objects that have responsibilities not co-located with the information required for their fulfillment
– can adversely affect coupling (i.e., high dependencies)
25
GRASP: Indirection
27
Indirection
• Problem: Where to assign a responsibility, to avoid direct coupling between two (or more) things?
– How to de-couple objects so that low coupling is supported and reuse potential remains higher?
• Solution: Assign the responsibility to an intermediate object to mediate between other components or services so that they are not directly coupled.
– The intermediary creates an indirection between the other components.
class With Indirection
Dependent +depends on Indirection +hides Questionable Element 1..* 1 Element 1 1 Element
class Without Indirection
Dependent +depends on Questionable Element 1..* 1 Element
28
Example: POS
TaxMasterSystem can
be accessed via TCP
POS will use Tax Master System (an external service) to calculate tax. Who should be responsible for calculating tax?
• By Expert, Sale is responsible for calculating total. TCP socket So, Sale should also calculate tax
. . . «actor»
• Should Sale be directly use TaxMasterSystem via
: Sale
communication
:TaxMasterAdapter
t = getTotal
<
communication
…
xxx
:TaxMasterSystem
TCP communication?
Discussion: If this responsibility is assigned to Sale,
the adapter acts as a level of
→ a lot of TCP communication to TaxMasterSystem
indirection to external systems
will be implemented in Sale
→ Sale class is highly coupled with TaxMasterSystem
29
Example: POS
Solution: By Indirection, the responsibility of communicating with TaxMasterSystem should be assigned to an intermediate class, i.e., TaxMasterAdapter
TaxMasterAdapter helps us decouple between Sale and TaxMasterSystem
: Sale
:TaxMasterAdapter
t = getTotal
TCP socket communication
taxes = getTaxes( s )
…
xxx
.. .
«actor» :TaxMasterSystem
the adapter acts as a level of indirection to external systems
30
Indirection: Discussion
• Many Pure Fabrications are generated because of Indirection.
– Indirection: Assigning any class as an intermediary
– Pure Fabrications: Assign an artificial class (that does not represent the domain) as an intermediary
• The motivation for Indirection is usually Low Coupling (i.e., decouple objects for future reuse)
• Old adage:
“Most problems in computer science can be solved by another level of indirection”
• Counter adage:
“Most problems in performance can be solved by removing another layer of indirection!”
31
GRASP:
Protected Variations
Protected Variation
• Problem: How to design objects, subsystems, and systems so that the variations or instability in these elements does not have an undesirable impact on other elements?
– Points of change include:
Variation point: variations in existing system or requirements Evolution point: speculative variations that may arise in the future
• Solution:
– Identify points of known or predicted variation or instability;
– Assign responsibilities to create a stable interface* around them
*Interface: a means of access (not only a programming language interface or Java interface)
33
Example: POS
POS currently uses ‘TaxMasterSystem’ to calculate tax. In the future, other tax calculators might be used. Analysis: To protected variation:
1. →
2. →
→ →
What is the point that will be known or predicted variation or instability?
The point of instability or variation is the different interfaces or APIs of external tax calculators
Assign responsibilities to create a stable interface* around them Use Indirection to create a stable interface
For other calculators, API might be used instead of TCP
yet, the behaviour of getTaxes() varies based on the type of tax calculators
By Polymorphism, let’s make getTax() as a polymorphic operation!
t = getTotal
: Sale
taxes = getTaxes( s )
Indirection creates a stable interface for Sale (i.e., getTaxes)
34
…
xxx
.. .
:TaxMasterAdapter
TCP socket communication
«actor» :TaxMasterSystem
the adapter acts as a level of indirection to external systems
Example: POS
Polymorphism protects the variation of behaviors
«interface» ITaxCalculatorAdapter
getTaxes( Sale ) : List
Indirection level protects the variation of interfaces
Adapter
…
…
GoodAsGoldTaxPro Adapter
getTaxes( Sale ) : List
TaxMasterAdapter
getTaxes( Sale ) : List
Varied interfaces and behaviors
Service via TCP communication
A software package
By Polymorphism, multiple tax calculator adaptersvhiavAePI their own similar, but varying behavior for adapting to different external tax calculators.
35
Protected Variation: Discussion
• Protected Variation (PV) is very important, fundamental principle of software design!
• PV is a root principle motivating most of the mechanisms and patterns in programming and design.
– For example: Core Protected Variations Mechanisms, Data-Driven Design, Service Lookup, Interpreter-Driven Design, (See more in textbook)
• PV is equivalent to Open-Closed Principle (OCP), described by Bertrand Meyer
– OCP: Modules should be both open (for extension; adaptable) and closed (to modification that
affects clients).
– A class can be closed w.r.t. attribute access (access methods only – no changes), but open to modification of underlying attributes (+ addition of new methods).
• Contraindications: Similar to Polymorphism
– Cost of speculative “future-proofing” at evolution points can outweigh the benefits
– It may be cheaper/easier to rework a simple “brittle” design
36
Relationship between GRASP Principles
For example:
Low coupling is a way to achieve protection at a variation point.
Polymorphism is a way to achieve protection at a variation point, and a way to achieve low coupling.
GRASP Principles
Protected Variation
Low Coupling
High Cohesion
Controller
Polymorphism
Indirection
Pure Fabrication
Ex pe rt
C re a to r
37
Summary & Remarks
• Protected Variation, Low Coupling, and High Cohesion are fundamental principles that we aim to achieve when designing software objects
• Use the remaining 6 GRASP patterns to achieve the principles
38
Exercise: Library borrowing system
A domain model of Library Borrowing System
40
Exercise: Analyze the design model based on GRASP
• Which GRASP principles that are likely being violated?
• And how can we improve?
41
Lecture Identification
Lecturer: Philip Dart
Semester 1, 2021
© University of Melbourne 2021
These slides include materials from:
Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition, by Craig Larman, Pearson Education Inc., 2005.