Chapter 17

Designing with Responsibilities

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

OOD

• Requirements

• Domain model

• Then:– Define classes– Add methods to classes– Define messaging

• Simple! RIGHT? - NOT

RDD

• Responsibility - contract or obligation of a class

• Doing-– Doing something itself– Initiate an action in another object– Control or coordinate

• Knowing-– Private data– Related objects– Things it can calculate

Fig. 17.2

: Sale

makePayment(cashTendered)

: Paymentcreate(cashTendered)

abstract, implies Sale objects have a responsibility to create Payments

GRASP

• 9 patterns, first 5 in this chapter:– Creator– Information expert– Low coupling– Controller– High cohesion

Creator

• Problem: Who creates A?

• Solution: Assign creation to B– IF:

• B contains (compositely aggregates) A• B records A• B closely uses A• B has initializing data for A

Fig. 17.4 apply Creator

Fig. 17.5 Apply Creator

Information Expert

• Problem: Assign a responsibility to an object?

• Solution: Choose the class that has the information to fulfill the responsibility

Fig. 17.6

Low Coupling

• Problem: Reduce impact of change

• Solution: Keep coupling low!

Fig. 17.7

Controller

• Problem: What object beyond UI controls a system operation

• Solution: Assign responibility to object– If

• Overall “system”, “root object”, device that the software runs in, major subsystem

• Represents a use case scenario within which the operation occurs

Fig. 17.8 SSD

Fig. 17.9

Fig. 17.10

Next Steps

• Applied controller pattern

• Now what goes beyond the :MonoployGame class?

High cohesion

• Problem: Keep objects focused, understandable, manageable (side effect support low coupling)

• Solution: assign responsibilities to improve cohesion

Fig. 17.11

GRASP

• General Responsibility Assignment Software Patterns

• We just did 5 of 9

• There rest are in Chapter 25– Polymorphism, Pure Fabrication,

Indirection, Protected Variations