Chapter 17. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after...

Chapter 17

GRASP

• General Responsibility Assignment Software Patterns (Principles)

• OOD: after identifying requirements, create domain model, define responsiblities and assign methods to classes

• define “messaging” (who sends the message)

• Patterns are a big part

Grasp Patterns

• Controller: go-between, UI and Domain– enhances low coupling– enhances reuse– represents “system” from the Use Case point

of view– shared: User Controller handles CreateUser

and DeleteUser use cases

Fig. 17.20

System

endSale()enterItem()makeNewSale()makePayment(). . .

system-leveloperations

Fig. 17.21

Which class of object should be responsible for receiving this system event message?

It is sometimes called the controller or coordinator. It does not normally do the work, but delegates it to other objects.

The controller is a kind of "facade" onto the domain layer from the interface layer.

actionPerformed( actionEvent )

: ???

: Cashier

:SaleJFrame

presses button

enterItem(itemID, qty)

UI Layer

Domain Layer

system operation message

big delegator

Fig. 17.22

:RegisterenterItem(id, quantity)

:ProcessSaleHandlerenterItem(id, quantity)

“system” or “handler”

Fig. 17.23

Register

...

endSale()enterItem()makeNewSale()makePayment()

makeNewReturn()enterReturnItem(). . .

System


makeNewReturn()enterReturnItem(). . .

system operations discovered during system behavior analysis

allocation of system operations during design, using one facade controller

ProcessSaleHandler

...


System


enterReturnItem()makeNewReturn(). . .

allocation of system operations during design, using several use case controllers

HandleReturnsHandler

...

enterReturnItem()makeNewReturn(). . .

each one handles a separate use case

Grasp Patterns

• Creator: not always a factory. B creates instances of A if:– B objects aggregate, record or closely use

many A objects– B objects have all the info needed to create

an A object

When to use a factory? in cases of significant complexity (AvailableStack), conditional creation (froma family of similar classes)

Fig. 17.12

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Fig. 17.13

: Register : Sale

makeLineItem(quantity)

: SalesLineItemcreate(quantity)

Grasp Patterns

• High Cohesion: evaluative pattern; keep objects appropriately focused, manageable and understandable.– responsibilities are strongly related

• Low Cohesion: hard to comprehend, hard to reuse, hard to maintain and adverse to change

Fig. 17.26

: Register : Sale

addPayment( p )

p : Paymentcreate()makePayment()

Fig. 17.27

: Register : Sale

makePayment()

: Paymentcreate()

makePayment()

Grasp Patterns

• Indirection: low coupling through use of intermediary objects.– Controller is an example

Grasp Patterns

• Information Expert: Responsibility delegation principle– put the responsibility with the object having

the most info needed to fulfill the responsibility– state the responsibility clearly first

– Look in Design Model first, then the Domain Model

– Expert is the most “intuitive” of patterns

Who should be responsible for knowing the grand total of a sale?

Fig. 17.14

Sale

time

SalesLineItem

quantity

ProductDescription


Described-by*

Contains

1..*

1

1

Domain Model Figure

Fig. 17.15

Sale

time...

getTotal()

:Salet = getTotal

New method

Fig. 17.16

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()New method

1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] : SalesLineItem

this notation will imply we are iterating over all elements of a collection

getTotal() needs getSubtotal().another Expert

Fig. 17.17

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()

ProductDescription


getPrice()New method

:ProductDescription

1.1: p := getPrice()

1 *: st = getSubtotal: Salet = getTotal lineItems[ i ] :SalesLineItem

getSubtotal() needs getPrice()

yet another Expert

Grasp Patterns

• Low Coupling: evaluative and supports:– lower dependency between the classes,– change in one class having lower impact on

other classes,– higher reuse potential.

Fig. 17.18

: Register p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

Register unnecessarily put in the middle between Sale and Payment

Fig. 17.19

: Register :Sale

:Payment

makePayment() 1: makePayment()

1.1. create() Register not involved in Payment

Grasp Patterns

• Polymorphism: variation of behaviours based on type assigned to types where the variation happens:– lower dependency between the classes,– change in one class having lower impact on

other classes,– higher reuse potential.

Grasp Patterns

• Protected Variations: protects objects from variations in other objects:– wrap the variation behind an interface facade,– adapter pattern,– uses polymorphism

Grasp Patterns

• Pure Fabrication: no relationship to domain objects but:– achieves low coupling, high cohesion, and

the reuse potential– alternative if Information Expert not available.

Object Design Overview

• Iterative context.

• requirements workshop

• 2-3 fully developed use cases

• high risks addressed

• some progress on domain model

Inputs and Relationship to OOD

• Use Case text: visible behaviour; our object will “realize” this behaviour

• System Sequence Diagrams: system-level messages. These are the initial messages in our program sequence diagrams

OOD Activities:

• Tools: GRASP, GoF Design Patterns

• Metaphor: assign responsibilities to collaborating objects

• Modeling Purpose: Understanding, not documentation.

• Next slide shows some activity inputs and outputs

Fig. 17.1

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

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

makeNewSale()

system events

Cashier

Process Sale

: Cashier

use case

names

system operations

Use Case Diagram

SupplementarySpecification

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

Sale

addLineItem1

Responsibility Driven Design

• Responsibility: Obligation or contract• Kinds of Responsibilities:

– Doing:• doing, initiating in others, controlling activities

– Knowing:• private data, related objects, calculations (guided by

Domain Model and low rep'l gap

– Collaboration:• objects need help from otehrs

Example: A Sale objects is responsible for creating a SalesLineItem object and knowing the running total

GRASP Principles

• A learning aid for object design based on patterns for assigning responsibilties

• Relationship to UML and Responsibilities

• Sequence Diagrams give us an opportunity to assign responsibilities

Fig. 17.2

: Sale

makePayment(cashTendered)

: Paymentcreate(cashTendered)

abstract, implies Sale objects have a responsibility to create Payments

Sales objects responsiblefor creating payment objects

What are Patterns?

• a software system whose design is guided by the use of general principles or idomatic solutions

Pattern Name Information Expert

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

Solution Assign responsibilities to the class that possesses the most information neededto fulfill it.

What are Patterns?

• A pattern is a named description of a (problem, solution) pair can be applied in a new context.

• patterns come with advice on how they should be used.

• Patterns are known by their names

“We'll expose the services of the persistence subsystem with a Facade, use an Abstract Factory for the Mappers classes and Proxy for lazy materialization”

Example

• In a molopoly game what object creates (invokes creation of) the individual squares that players can land on?– B objects aggregate, record or closely use

many A objects– B objects have all the info needed to create

an A object

A = Square ==> B = ?

Fig. 17.3Creator Pattern

Fig. 17.4

Fig. 17.5

Example

• In a molopoly game what objects know about a Square (given a key or square name)? Such an object is an Information Expert.

Again the answer is Board; this is reassuring.

Fig. 17.6

Example

• All other things being equal we should prefer a solution that exhibits low coupling.

• Low coupling tends to reduce the time, effort and defects associated with mmodifying software.

• Does Expert support Low Coupling?

Fig. 17.7

Example

• UI objects should not contain “business” logic

• UI objects should delegate any needed domain task to another.

• The Controller patter answers the question “What first object after the UI layer should receive a message from the UI layer for service?

System Sequence Diagram What class should havethis responsibility?

Controller Design

• Controllers should either:– represent the overall system ( a device the

software is running within) or a major subsystem; both variations of the Facade pattern, or

– represent a use case scenario context (such as a session controller)

Fig. 17.9

Example

• In the monopoly game, a MonopolyGame class represents the overall system.

• In the ATM example the ATM represents the device the software is running within.

• a PlayMonopolyGameHandler acts as a Session Controller (but we only have one session!).

Fig. 17.10 design based onController

:MonopolyGame

play gamewhat next?

Example

• Next slide shows two design approaches possible.

• Either one class does all the work or else work is delegated to other classes.

• Lession to learn: low cohesion leads to high coupling.

Fig. 17.11

Fig. 17.24


:Register

: Cashier

:SaleJFrame

presses button

1: enterItem(itemID, qty)

:Sale1.1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

system operation message

controller

Fig. 17.25

Cashier

:SaleJFrame


:Sale1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

It is undesirable for an interfacelayer object such as a window to get involved in deciding how to handle domain processes.

Business logic is embedded in the presentation layer, which is not useful.

SaleJFrame should not send this message.

presses button

Chapter 17. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after...

Documents

Transcript of Chapter 17. GRASP General Responsibility Assignment Software Patterns (Principles) OOD: after...