Chapter 9

Domain Models

$PH\06f522\LarmanApplUMLandPtrns\larman3EdDgmsCh01-14\09_domainModelsR2.ppt – RJL060911

Fig. 9.1: Sample UP Artifact Relationships

Process Sale

1. Customer arrives ...2. ...3. Cashier enters item identifier .4....

Use Case Text

Operation : enterItem (…)

Post-conditions :- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

the domain objects, attributes, and associations that undergo state changes

Domain Model

Use-Case Model

Design Model

: Register

enterItem(itemID, quantity )

: ProductCatalog

spec = getProductSpec ( itemID )

addLineItem ( spec, quantity )

: Sale

. . .

conceptual classes in the domain

inspire the names of some software classes in the design

conceptual classes –terms, concepts attributes

,

associations

Cashier : …Item ID : …...

Glossary

elaboration of some terms in the domain model

Require -ments

Business Modeling

Design

Sample UP Artifact Relationships

Fig. 9.1

Process Sale

1. Customer arrives ...2. ...3. Cashier enters item identifier.4....

Use Case Text

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

the domain objects, attributes, and associations that undergo state changes

Domain Model

Use-Case Model

Design Model

: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

. . .

conceptual classes in the domain inspire the names of some software classes in the design

conceptual classes – terms, concepts attributes, associations

Cashier: …Item ID: …...

Glossary

elaboration of some terms in the domain model

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships

Fig. 9.2: Partial Domain Model – A Visual Dictionary

Register

Item

Store

addressname

Sale

date time

Payment

amount

SalesLineItem

quantity

Stocked-in

*

Houses

1..*

Contained-in

1..*

Records-sale-of

0..1

Paid-by

1

1

1

1

1

1

0..1

1

Captured-on

conceptor domain object

association

attributes

Fig. 9.3

Sale

dateTime

visualization of a real-world concept in the domain of interest

it is a not a picture of a software class

Fig. 9.4

SalesDatabase software artifact; not part of domain modelavo

id

software class; not part of domain model

Sale

datetime

print()

avoid

Fig. 9.5 A Conceptual Class has a symbol, an intension (metadata) and extension (data)

Sale

datetime

concept's symbol

"A sale represents the event of a purchase transaction. It has a date and time."

concept's intension

sale-1

sale-3sale-2

sale-4

concept's extension

Fig. 9.6 Lower the Representational Gap with OO Modeling

Payment

amount

Sale

datetime

Pays-for

Payment

amount: Money

getBalance(): Money

Sale

date: DatestartTime: Time

getTotal(): Money. . .

Pays-for

UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.

UP Design ModelThe object-oriented developer has taken inspiration from the real world domain in creating software classes.

Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.

1 1

1 1

A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter.

This reduces the representational gap.

This is one of the big ideas in object technology.

inspires objects

and names in

Fig. 9.7: Initial POS Domain Model

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Fig. 9.8: Initial Monopoly Domain Model

Fig. 9.9: Descriptions about other things

Item

descriptionpriceserial numberitemID

ProductDescription

descriptionpriceitemID

Item

serial number

Describes Better

Worse

1 *

Multiplicity ‘*’ means 0 to many Item instances are related to one Prod’ctDescr’n.

Multiplicity ‘1’ means one Prod’ctDescr’n instance is related to some # of Items.

Many invariant attributes are duplicated;This wastes space and causes the ‘double-maintenance’ problem – RJL.

Fig. 9.10: Descriptions about Other Things

Worse

Flight

date

time

FlightDescription

number

Airport

nameDescribes flights-to

Described-by

Flight

datenumbertime

Airport

name

Flies-to

Better

1

*1

*

1

*Clockwise Rulerelation name

is unambiguous

I rearranged model Items to illustrate 2DTopological Order:(by relational multiplicity – RJL.(I use one above/left of many.) David Hay/Oracle both reverse this orientation!

Fig. 9.11

SaleRegisterRecords-current

1 1

association

Fig. 9.12

SaleRegister Records-current 0..11

association name multiplicity

-"reading direction arrow"-it has no meaning except to indicate direction of reading the association label-often excluded

Fig. 9.13

ItemStore Stocks

*

multiplicity of the role

1

Fig. 9.14

zero or more; "many"

one or more

one to 40

exactly 5

T

T

T

T

*

1..*

1..40

5

T3, 5, 8

exactly 3, 5, or 8

Fig. 9.15

ItemStore Stocks 1

or 0..1

Multiplicity should "1" or "0..1"?

The answer depends on our interest in using the model. Typically and practically, the muliplicity communicates a domain constraint that we care about being able to check in software, if this relationship was implemented or reflected in software objects or a database. For example, a particular item may become sold or discarded, and thus no longer stocked in the store. From this viewpoint, "0..1" is logical, but ...

Do we care about that viewpoint? If this relationship was implemented in software, we would probably want to ensure that an Item software instance would always be related to 1 particular Store instance, otherwise it indicates a fault or corruption in the software elements or data.

This partial domain model does not represent software objects, but the multiplicities record constraints whose practical value is usually related to our interest in building software or databases (that reflect our real-world domain) with validity checks. From this viewpoint, "1" may be the desired value.

*

Fig. 9.15

ItemStore Stocks

1or 0..1

Multiplicity should be "1" or "0..1"?

The answer depends on our interest in using the model. Typically and practically, the multiplicity communicates adomain constraint that we care about being able to check in software, if this relationship was implemented or reflectedin software objects or a database. For example, a particular item may become sold or discarded, and thus no longer

stocked in the store. From this viewpoint, "0..1" is logical, but ...

Do we care about that viewpoint? If this relationship was implemented in software, we would probably want to ensurethat an Item software instance would always be related to 1 particular Store instance, otherwise it indicates a fault or

corruption in the software elements or data.

This partial domain model does not represent software objects, but the multiplicities record constraints whose practicalvalue is usually related to our interest in building software or databases (that reflect our real-world domain) with validity

checks. From this viewpoint, "1" may be the desired value.

*

Fig. 9.16

Flight Airport

Flies-to

Flies-from

*

* 1

1

Which relation name conforms to the Clockwise Rule? - RJL

Fig. 9.17: NextGen POS: partial domain model

Register

ItemStore

Sale

CashPayment

SalesLineItem

CashierCustomer

ProductCatalog

ProductDescription

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

06f522 Assignment 1a, due 9/12:Redraw, topologicallysorted; use 2-ucLetter

symbols as box labels;include dictionary of

<symbol, name> pairs.

Fig. 9.18: Monopoly partial domain model

Fig. 9.19: Class and Attributes

Sale

dateTime/ total : Money

attributes

derived attribute

Fig. 9.20: Attribute Notation in UML

Sale

- dateTime : Date- / total : Money

Private visibility attributes

Math

+ pi : Real = 3.14 {readOnly}

Public visibility readonly attribute with initialization

Person

firstNamemiddleName : [0..1]lastName

Optional value

Fig. 9.21: Recording the quantity of Items sold in a line item

SalesLineItem ItemRecords-sale-of 10..1

SalesLineItem ItemRecords-sale-of 0..1 1..*

Each line item records a separate item sale.For example, 1 tofu package.

Each line item can record a group of the same kind of items.For example, 6 tofu packages.

SalesLineItem

/quantity

ItemRecords-sale-of 0..1 1..*

derived attribute from the multiplicity value

[Here an item quantity attribute could be added to a single SalesLineItem;but it can’t be derived because there is only one associated item.]

[Now the associated item only needs to have multiplicity 1, illustrating one possible justification for evolving a conceptual model into a different design model. – RJL]

Fig. 9.22: Relate with associations, not attributes

Cashier

namecurrentRegister

Cashier

name

Register

number

Uses

Worse

Better

not a "data type" attribute

1 1

[The ‘uses’ relation implies an implicit oid or foreign key attribute in Cashier, to identify the (currently) assigned Register. –RJL ]

06f522 assignment 1b, due 9/12: Expand/redraw this model to include the temporal history of Cashier to Register assignments over time: Add new attributes and associations and state your assumptions.

Fig. 9.23: Don’t show complex concepts as attributes; use associations.

Flight

Flight

destinationWorse

BetterFlies-to Airport1 1

destination is a complex concept

Fig. 9.24: Two ways to indicate a data type property of an object.

OK

OK

ProductDescription

ProductDescription

itemId : ItemID

1Store

Store

address : Address

11 1

ItemID

idmanufacturerCodecountryCode

Address

street1street2cityName...

Fig. 9.25: Do not use attributes as foreign keys.*

Cashier

namecurrentRegisterNumber

Cashier

name

Register

number

Works-on

Worse

Better

a "simple" attribute, but being used as a foreign key to relate to another object

1 1

* Fkeys are redundant if implied by association links. Warning: This may also force surrogate keys with standard naming conventions. [Disclaimer: I Iike surrogate keys – RJL]

Fig. 9.26: Modeling Quantities

Payment

amount : Number

Payment Quantity

amount : Number

Unit

...

Payment

amount : Quantity

Has-amount1*

Is-in1*

not useful

quantities are pure data values, so are suitable to show in attribute section better

Payment

amount : Money

variation: Money is a specialized Quantity whose unit is a currency

Fig. 9.27: NextGen POS partial domain modelCan you abbreviate names and sort by fanout?

Register

id

ItemStore

nameaddress

Sale

dateTime/ total

CashPayment

amountTendered

SalesLineItem

quantity

Cashier

id

Customer

ProductCatalog

ProductDescription

itemIDdescriptionprice

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

Fig. 9.27B: NextGen POS partial domain model[With abbreviated names, leveled by fanout]

Register

id

ItemStore

nameaddress

Sale

dateTime/ total

CashPayment

amountTendered

SalesLineItem

quantity

Cashier

id

Customer

ProductCatalog

ProductDescription

itemIDdescriptionprice

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

Level Symbol EntityType1 LG Ledger1 PC ProductCatalog2 PD ProductDescription2 SR StoRe3 CU Customer3 CH CasHier3 IT ITem3 RG ReGister4 SA Sale5 CP CashPayment5 SL SalesLineitem

09_domainModelsR2.ppt slide 31

Fig. 9.21C: NextGen - Topological sort by fanout [and optionality]

Level Symbol EntityType

• 1 LG Ledger

• 1 PC ProductCatalog

• 2 PDProductDescription

• 2 SR StoRe

• 3 CU Customer

• 3 CH CasHier

• 3 IT ITem

• 3 RG ReGister

• 4 SA Sale

• 5 CP CashPayment• 5 SL SalesLineitem

LG PC

PDSR

CU

CH ITRG

SA

CP SL

?

09_domainModelsR2.ppt - slide 32

Fig. 9.28: Monopoly Partial Domain Model