GRASP (cont.)
Cpt S 321 Washington State University
GRASP: 9 principles for assigning responsibilities
• We are already familiar with some of them:
• Information Expert • Low Coupling
• High Cohesion
• Polymorphism
• Today we will learn about:
• Creator
• Controller
• Pure Fabrication
• Indirection
• Protected variations
Domain model
• Definition: A conceptual model of the problem domain.
• Represents concepts and their relations
• Represents both state and behavior
• Resembles a class diagram visually but at a more high level – no implementation details are shown.
software Board object contains software Square objects. And then consistent with LRG and the
• Domain model
Creator advice, the Board will create Squares. Also, Squares will always be a part of one Board, and Board manages their creation and destruction; thus, they are in a composite aggregation association with the Board.
Example: Monopoly
Figure 17.3. Monopoly iteration-1 domain model.
Point-Of-Sale (POS) application
• Similar to the one used in retail stores: includes hardware, code bar scanner, and software
• Record sales
• Handle payments
• Customizable logic
• When a new sale is instantiated • When a new line item is added
Example of Use Case: UC1: Process Sale
• Primary Actor: Cashier
• Main Success Scenario:
Actor Action (or Intention)
1.Customer arrives at a POS checkout with goods and/or services to purchase.
2.Cashier starts a new sale. 3.Cashier enters item identifier.
Cashier repeats steps 3-4 until indicates done.
6.Cashier tells Customer the total, and asks for payment.
7.Customer pays.
System Responsibility
4.Records each sale line item and presents item description and running total.
5.Presents total with taxes calculated.
8.Handles payment.
9.Logs the completed sale and sends information to the external accounting (for all accounting and commissions) and inventory systems (to update inventory). System presents receipt.
POS application
Records-sale-of Described-by
1
Product Specification
Describes *
Partial domain model
1
0..1
*
11
*
1..*
Contains
Contained-in
1..* 1
1 Houses 1..*
*
1
1
Started-by 1
1Initiated-by 111
Paid-by 1
Records-sales-on 1
Logs- completed
Captured-on
Product Catalog
Store
1
Used-by *
Stocks
1..*
Sales LineItem
Item
Sale
11
Register
Manager
1 Initiated-by
Customer
Cashier
Payment
GRASP (cont.)
• Creator
Problem: Who should be responsible for creating a new instance of some
class?
Solution: Assign class B the responsibility to create an instance of class A if one of these is true (the more the better):
• B “contains” or compositely aggregates* A. (see next slide for definition)
• B records A.
• B closely uses A.
• B has the initializing data for A that will be passed to A when it is created. Thus B is an Expert with respect to creating A.
• B is a creator of A objects.
If more than one option applies, usually prefer a class B which compositely aggregates or contains class A.
Composition (or composite aggregation)
• A strong kind of whole-part aggregation • A composition relationship implies that
1) an instance of the part (such as a Square) belongs to only one composite instance (such as one Board) at a time,
2) the part must always belong to a composite (no free-floating Fingers), and
3) the composite is responsible for the creation and deletion of its parts either by itself creating/deleting the parts, or by collaborating with other objects. Related to this constraint is that if the composite is destroyed, its parts must either be destroyed, or attached to another composite.
Again: no free-floating Fingers allowed!
on, SalesLineltem instances. Consider the partial domain m
Sales
LineItem * Described-by
itemID
Figure 16.7 Partial domain model.
• Creator – example: In a POS application,
Since a Sate contains (in fact, aggregates) many SalesLineltem objects, the Cre-
creating SalesLineltem instances.
a SalesLineltem instance?
This leads to a design of object interactions as shown in Figure 16.8.
description quantity price
GRASP (cont.)
1
Specification
ator pattern suggests that Sale is a good candidate to have the responsibility of who should be responsible for creating
1
Contains
1..*
* Described-by
1
: Register
Figure 16.8 Creating a SalIensLteinrealtcemti.on diagram
makeLineItem(quantity)
: Sale
Figure 16.7 Partial domain model.
Since a S
Sale
date time
Partial domain model
Product Specification
description price itemID
makeLineItem(quantity)
create(quantity)
ate contains (in fact, aggregates) many SalesLinelt n suggests that Sale is a good candidate to have
creating SalesLineltem instances.
This leads to a design of object interactions as shown in Figu
: SalesLineItem
ator patter
Sales LineItem
quantity
: Register
: Sale
GRASP (cont.)
• Controller
Problem: What first object beyond the UI layer receives and coordinates
(“controls”) a system operation?
Solution: Assign the responsibility to a class representing one of the following choices:
• Represents the overall “system,” a “root object,” a device that the software is running within, or a major subsystem.
• Represents a use case scenario within which the system event occurs, often named
Note that ”form”, “window,” “view,” and “document” classes are not on this list. Such classes should not fulfill the tasks associated with system events; they typically receive these events and delegate them to a controller.
s a
tern [BMRSS96], introduced in Chapter 34.
GRASP (cont.)
• Controller – example
Interface Layer
tions may be assigned to the class System in some analysis model, erations. However, this does not mean that a software class named
ign. Rather, during design, a controller class is assigned the
presses button
: Cashier
a b c t t n i o _ n C P l i e c r k f o ( s r me n e d d ( e r a , c E t i v o e n n E t v A e r n g t u ) m e n t s )
: S: S a a l e l e J F F o r a r m m e
system event message
1: enterItem(itemID, qty)
controller
tions (see Figure 17.21).
Domain Layer
1.1: makeLineItem(itemID, qty)
:Sale
: : R? e? g? i s t e r
seful.
ed by other
GRASP (cont.)
in it.
ction diagrams, one of the examples in Figure 17.22 could be u
• Controller – example (cont.)
Figure 17.22. Controller choices.
ch of these classes is the most appropriate controller is influenc following section explores.
a
e
e system operations identified during system behavior analysis are assigned to
Discussion
GRASP (cont.)
• Pure Fabrication
Problem: What object should have the responsibility, when you do not want to violate High Cohesion and Low Coupling, or other goals, but solutions offered by Expert (for example) are not appropriate?
Solution:
• Assign a highly cohesive set of responsibilities to an artificial or convenience class that does not represent a problem domain concept something made up, to support high cohesion, low coupling, and reuse.
• Such a class is a fabrication of the imagination. Ideally, the responsibilities assigned to this fabrication support high cohesion and low coupling, so that the design of the fabrication is very clean, or pure hence a pure fabrication.
• Saving objects in a relational database is a very general task for which
many classes need support. Placing these responsibilities in the Sale class
suggests there is going to be poor reuse or lots of duplication in other classes
GRASP (cont.)
that do the same thing.
Thus, even though Sale is a logical candidate by virtue of Information Expert to
save itself in a database, it leads to a design with low cohesion, high coupling,
and low reuse potential—exactly the kind of desperate situation that calls for
• Pure Fabrication – example: Suppose that support is needed to save making something up.
Sale instances in a relational database.
A reasonable solution is to create a new class that is solely responsible for saving
• Option 1: Assign the responsibility to the Sale class (as per Information Expert) objects in some kind of persistent storage medium, such as a relational database;
2
• Ocapltlioitnth2e: CPrerastiseteanntSetworcalgaes.s’PTehrsisisctelanstsSitsoaraPguere Fabrication—a figment of the
• Why is Option 2 a better design choice?
imagination.
PersistentStorage
insert( Object )
update( Object ) …
By Pure Fabrication
GRASP (cont.)
• 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.
GRASP (cont.)
• Indirection – example
INDIRECTION
s : Sale
:TaxMasterAdapter
t := getTotal()
TCP socket communication
taxes := getTaxes( s )
…
xxx
«system» : TaxMaste
the adapter acts as a level of indirection to external systems
Figure 22.3 Indirection via the adapter.
GRASP (cont.)
• Protected Variations
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?
Solution: Identify points of predicted variation or instability; assign responsibilities to create a stable interface around them.
Note: The term “interface” is used in the broadest sense of an access view; it does not literally only mean a C# interface.
and so on.
«interface» ITaxCalculatorAdapter
getTaxes( Sale ) : List of TaxLineItems
GRASP (cont.)
• Protected Variations – example
Adapt er
…
…
TaxMasterAdapter
getTaxes( Sale ) : List of TaxLineItems
GoodAsGoldTaxPro Adapt er
getTaxes( Sale ) : List of TaxLineItems
By Polymorphism, multiple tax calculator adapters have their own similar, but varying behavior for adapting to different external tax calculators.
he Square creation problem, since no software classes are yet defined, we look at the
The Controller pattern answers this simple question: What first object after or beyon
odel in Figure 17.3 and see that a Board contains Squares. That’s a conceptual
should receive the message from the UI layer?
e, not a software one, but of course we can mirror it in the Design Model so that a oard object contains software Square objects. And then consistent with LRG and the
Let’s practice
To tie this back to system sequence diagrams, as a review of Figure 17.8 shows, the vice, the Board will create Squares. Also, Squares will always be a part of one Board,
operation is playGame. Somehow the human observer generates a playGame reque manages their creation and destruction; thus, they are in a composite aggregation
n with the Board.
• Recall the Monopoly game
by clicking on a GUI button labeled “Play Game”) and the system responds.
Figure 17.8. SSD for the Monopoly game. Note the play
operation.
Figure 17.3. Monopoly iteration-1 domain model.
Domain model Figure 17.9 illustrates a finer-SgrSaiDnedfolorokthatewhpalta’sygGoinagmone, aosspumeirnagtaioJanva Swin window and JButton button.[8] Clicking on a JButton sends an actionPerformed mes
t
v
B
d
d
d s
G
g
s object, often to the JFrame window itself, as we see in Figure 17.9. Thenand this is th
The Monopoly – questions
1. Who should create the Square object?
2. Who knows about a Square object, given a key?
3. Who is the Controller for the playGame system operation?
4. How should the controller interact with the rest of the classes in the domain layer?
5. Who should be responsible to handle the dice (rolling and summing the dice totals)?
a e d
u
s
e g
Suppose objects need to be able to reference a particular Square, given its name. Who sho
l
n agile modeling practice is to create parallel complementary dynamic and static
ls. Therefore, I’ve drawn both a partial sequence diagram and class diagram to reflect
1. Who should create the Square object?
ecision in which I’ve applied a GRASP pattern while drawing UML diagrams. See
and Figure 17.5. Notice in Figure 17.4 that when the Board is created, it creates a brevity in this example, I’ll ignore the side issue of drawing the loop to create all 40
• Answer: The Board
re 17.4.•AJpupslytifnigcathtieoCnr:eCatroeraptaotrt!ern in a dynamic model.
static model.
Partial sequence diagram Information Expert Partial class diagram
17.5. In a DCD of the Design Model, Board has a composite
Problem: Who knows about a Square object, given a key?
Figure 17.4. Applying the Creator pattern in a dynamic mode
Figure 17.5. In a DCD of the Design Model, Board has a compo aggregation association with Squares. We are applying Creator
ation association with Squares. We are applying Creator in a
static model.
The pattern Information Expert (often abbreviated to Expert) is one of the most basic responsibility assignment principles in object design.
2.W
key?
own state, the world around an object, information the object can derive, and so forth. In this
Aresponsibcilaitsyen,eteodbseinafobrlmeatotiornetfroirevitesfaunlfdillmprensteinftoramnyatoioneaSboqutaorethgeivreonbjietcstsn,aamneosbojmecet’sobjectmustknow
h
o
k
n
o
Bo
w
ard
wil
s
a
b
l ag
gr
o
u
ega
te
all
the
Sq
that a software Board will aggregate all the Square objects. Therefore, Board has the information drawing.
necessary to fulfill this responsibility. Figure 17.6 illustrates applying Expert in the context of drawing.
• Answer: The Board
• Justification: Information Expert!
t
a
S
own state, the world around an object, information the object can derive, and so forth. In this
(have the information) about all the Squares. We previously decided, as shown in Figure 17.5,
case, to be able to retrieve and present any one Squaregiven its namesome object must know
tha
ta
(have the information) about all the Squares. We previously decided, as shown in Figure 17.5,
soft
wa
Figure 17.6. Applying Expert. Figure 17.6. Applying Expert.
q
re
necessary to fulfill this responsibility. Figure 17.6 illustrates applying Expert in the context of
ua
u
reo
a
r
bj
ec
e
o
b
ts.
The
ref
j
e
c
t
,
g
o
re,
B
oa
rd
ha
i
v
s
th
e
n
a
e
infor
mation
Partial sequence diagram Partial class diagram
The next GRASP principle, Low Coupling, explains why Expert is a useful, core principle of OO The next GRASP principle, Low Coupling, explains why Expert is a useful, core principle of OO
design.
design.
Low Coupling
Low Coupling
3. Who is the Controller for the playGame
igure 17.10. Applying the Controller patternusing MonopolyGame.
system operation?
Connecting the UI layer to the domain layer of software objects.
WinForm application window
Monopoly Form
Btn_Click
F
4. How should the controller interact with the rest of the classes in the domain layer?
(notice that I’m still trying to use similar domain-relevant vocabulary) to hold all the dice, roll
them, and know their total. The new design is shown in Figure 25.8 and Figure 25.9. The Cup Figure 25.8. DCD for a Cup.
holds a collection of many Die objects. When one sends a roll message to a Cup, it sends a roll message to all its dice.
• Answer: Cup!
Figure 25.9. Using the Cup in the
5. Who should be responsible to handle the dice (rolling and summing the dice totals)?
Figure 25.8. DCD for a Cup.
Monopoly game.
Figure 25.9. Us
ing the Cup in the Monopoly game.