Chapter 17

Initial Object Design Inputs:

• requirements meetings

• various Use Cases – 10% complete

• Key risks addressed with preliminary programming

• System Sequence Diagrams

• The Domain Model

• Glossary

• Use Case post-conditions clarify proposed achievements.

Object Design Activities:

• Test-first development (test code <--> production code)

• Some UML modeling

• Sequence Diagrams concurrent with Class Diagrams

• Apply GRASP principles and GoF Design Patterns

• Follow RDD – responsibility-driven design

• Class diagrams are intended for understanding, not documentation

Object Design Outcome:

• Add methods to appropriate classes.

• This simplistic description hides the deep principles and issues involved and he consequences of getting it wrong.

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

inputs and outputsof a day of design

Responsibility-Driven Design (RDD):

• Think in terms of responsibilities, roles and collaborations

• Two kinds:

– doing

– knowing

• Think about responsibility “granularity”

• Responsibilities happen in conjunction with collaborations between objects.

Responsibility-Driven Design (RDD):

• Doing:

– doing something itself

– initiating action in others

– controlling or coordinating activities across various objects

Responsibility-Driven Design (RDD):

• Knowing:

– knowing about private data

– knowing about related objects

– knowing about secondary data it can calculate (result of a method call)

Guidelines:

• Domain Model guides what classes “know”

• Results in “low representational gap”

• keep your eye on responsibility “granularity”

– big responsibilities get spread over many classes

– small responsibilities may take only one method

• Collaboration is everywhere – methods talk to one another

RDD as Metaphor:

• An OO Design seen as a community of collaborating responsible objects.

GRASP:

• General Responsibility Assignment Software Patterns or Principles

• Basic principles to follow when assigning responsibilities

• Used in place of experience

• based on recognized successful patterns

GRASP Principles:

• Information Expert: assign responsibility to the knowledgeable class; the one with the necessary info

• Creator: Creation responsibility goes to the class that

– contains an object

– aggregates an object

– has initializing data

• Controller: A class that represents the overall system, “root”, a device, a subsystem or a Use Case goal. This is the first class beyond the UI.

• Low Coupling: Keep unnecessary coupling to a minimum. Typically one of many alternatives.

GRASP Principles:

• High Cohesion: assign responsibility so cohesion remains high. Typically one of many alternatives.

• Polymorphism: Assign responsibilities as behaviour varies by type. Use polymorphism.

• Pure Fabrication: When a highly cohesive set of behaviours needs a home and no domain object does it.

• Indirection: Use an intermediate object when you don't want to classes to know about each other.

• Protected Variations: Protecting against instability if variations need frequent tweaking. Identify places of predictable instability and protect them with an interface.

Fig. 17.2

: Sale

makePayment(cashTendered)

: Paymentcreate(cashTendered)

abstract, implies Sale objects have a responsibility to create Payments

What GRASP principles are applied here?

Patterns:

• A pattern is a named description of a problem and its solution that can be applied to new contexts.

• Naming a pattern is important. If you can't name it you don't understand it.

• Patterns are all old friends. Keep to the tried and true.

• “New” pattern is an oxymoron.

• Own the GoF book – Design Patterns

Fig. 17.3

What GRASP patterns are in use?

Fig. 17.5

Board aggregates Square. Start there.

Find the GRASP patterns in use here:

• Creator: Board creates Square (LRG) since it aggregates squares.

• Information expert: To retrieve one square one needs to know about all squares. This is Board's job as aggregator.

• Low Coupling: Knowing about squares as a collection and then individually means low coupling.

• Controller:

• High Cohesion:

Fig. 17.4

Fig. 17.6

Find the GRASP patterns in use here:

• Low Coupling: Knowing about squares as a collection and then individually means low coupling.

• Controller:

• High Cohesion:

Fig. 17.7

Fig. 17.8

Fig. 17.9

Fig. 17.10

Fig. 17.11

Fig. 17.12

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Fig. 17.12

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Fig. 17.13

: Register : Sale

makeLineItem(quantity)

: SalesLineItemcreate(quantity)

Fig. 17.13

: Register : Sale

makeLineItem(quantity)

: SalesLineItemcreate(quantity)

Fig. 17.14

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Fig. 17.14

Sale

time

SalesLineItem

quantity

ProductDescription

descriptionpriceitemID

Described-by*

Contains

1..*

1

1

Fig. 17.15

Sale

time...

getTotal()

:Salet = getTotal

New method

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

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

Fig. 17.17

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()

ProductDescription

descriptionpriceitemID

getPrice()New method

:ProductDescription

1.1: p := getPrice()

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

Fig. 17.17

Sale

time...

getTotal()

SalesLineItem

quantity

getSubtotal()

ProductDescription

descriptionpriceitemID

getPrice()New method

:ProductDescription

1.1: p := getPrice()

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

Fig. 17.18

: Register p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

Fig. 17.18

: Register p : Payment

:Sale

makePayment() 1: create()

2: addPayment(p)

Fig. 17.19

: Register :Sale

:Payment

makePayment() 1: makePayment()

1.1. create()

Fig. 17.19

: Register :Sale

:Payment

makePayment() 1: makePayment()

1.1. create()

Fig. 17.20

System

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

Fig. 17.20

System

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

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

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

Fig. 17.22

:RegisterenterItem(id, quantity)

:ProcessSaleHandlerenterItem(id, quantity)

Fig. 17.22

:RegisterenterItem(id, quantity)

:ProcessSaleHandlerenterItem(id, quantity)

Fig. 17.23

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

ProcessSaleHandler

...

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

System

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

enterReturnItem()makeNewReturn(). . .

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

HandleReturnsHandler

...

enterReturnItem()makeNewReturn(). . .

Fig. 17.23

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

ProcessSaleHandler

...

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

System

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

enterReturnItem()makeNewReturn(). . .

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

HandleReturnsHandler

...

enterReturnItem()makeNewReturn(). . .

Fig. 17.24

actionPerformed( actionEvent )

:Register

: Cashier

:SaleJFrame

presses button

1: enterItem(itemID, qty)

:Sale1.1: makeLineItem(itemID, qty)

UI Layer

Domain Layer

system operation message

controller

Fig. 17.24

actionPerformed( actionEvent )

: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

actionPerformed( actionEvent )

: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

Fig. 17.25

Cashier

:SaleJFrame

actionPerformed( actionEvent )

: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

Fig. 17.26

: Register : Sale

addPayment( p )

p : Paymentcreate()makePayment()

Fig. 17.26

: Register : Sale

addPayment( p )

p : Paymentcreate()makePayment()

Fig. 17.27

: Register : Sale

makePayment()

: Paymentcreate()

makePayment()

Fig. 17.27

: Register : Sale

makePayment()

: Paymentcreate()

makePayment()