Chapter 9

Domain Models

Domain Modeling

• After you have your requirements you start modeling the domain.

• You are still modeling the business, not the program classes

• Various influences:– Source of info is the use-cases– operational contracts (like pre- and post-conditions)– conceptual classes give us ideas for what to name

our program classes

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

Example:

• The following are the conceptual classes for Payment and Sale.

• Part of the Conceptual Perspective• Don’t be too thorough; avoid waterfall.

Fig. 9.2

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

NOTE: The directionof references.

What is a Domain Model

• Decompose the domain into noteworthy concepts and/or objects.

• The DM is a visual representation of real-situation objects and conceptual classes.

• Sometimes called Conceptual Model.• In UP, this is one of the Business Modeling artifacts.• Specifically, a class diagram with no operations or

behaviour.• Shows:

– domain objects– associations– attributes

And…

Sometimes called a visual dictionary.

What not to include:

• Software artifacts like databases, windows• Responsibilities (ie, methods)

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

SalesDatabase software artifact; not part of domain model

software class; not part of domain model

Sale

datetime

print()

Where does it fit?

• The Domain Model feeds into just one part of a program’s design.

• Typical program uses the MVC (Model-View-Controller) paradigm; the DM feeds the Model part only.

• The author uses the term “domain layer” to mean the software components that underlie the UI layer.

• We consider a conceptual class from 3 points of view– symbol: what words we use to name it– intension: its complete definition– extension: a set of examples of the class

Are Domain and Data Models the same?

• A Data Model is a model of persistent data; ie, data in a database or file system.

• Unlike a Data Model, just because we may never build the class, doesn’t mean we don’t put it in a Domain Model.

• Some Domain Model classes are purely behavioural

Fig. 9.5

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

Why Build a Domain Model?

• The developer has to understand the business so that is a good reason to build the Domain Model

• We want to use software artifact names that “remind” us of what real-world things they model. So it is a good idea to list those domain concepts (visually).

• The author calls this a “low representational gap”.•

Fig. 9.6

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

Guidelines:

• Limit yourself to the interests of the current iteration; don’t try to draw the entire Domain Model up front (waterfall).

• To decide what classes to use, look around at what other developers have done here or in this area of endeavour.

• Look for patterns others have built.• Our project uses Quartz.• Make lists.• Linguistic Analysis

List of Categories and possible classes

Business Transactions Sale, Payment, Reservation

Transaction Line Items SalesLineItem

Products or Services Item, Flight, Seat, Meal

Where Transaction Recorded Register, Ledger, Manifest

People’s Roles Cashier, Customer, Passenger

Place of Transaction Store, Airport, Plane, Seat

Noteworthy Events Sale, Payment, Flight

Physical Objects Item, Register, Board, Airplane

Descriptions of Things ProductDescription, FlightDescription

Conceptual Class Category Examples

List of Categories and possible classes

Catalogs ProductCatalog, FlightCatalog

Containers for Things Store, Bin, Airplane

Things in Containers Item, Square (on a Board), Passenger

Other Systems CreditAuthSystem, AirTrafficControl

Records of Finance, Work Receipt, Ledger, MaintenanceLog

Financial Instruments Cash, Check, LineOfCredit,TicketCredit

Schedules, Manuals, Docs DailyPriceChangeList, RepairSchedule

Conceptual Class Category Examples

Linguistic Analysis:

• Identify the nouns and verbs in text descriptions like a text-based Use-Case; consider these as candidate conceptual classes.

Fully Dressed Use Case (1):

• Scope: NextGenPOSApplication• Level: User Goal• PrimaryActor: Cashier• StakeholdersAndInterests:

– cashier wants: …– customer wants: …– company wants: …– manager wants: …– government wants: …– CC company wants: …

Fully Dressed Use Case (2):

• Preconditions: Cashier identified and authenticated• Postcondtions: Sale completed, tax calculated,

inventory updated, commission recorded, cc approval recorded

• MainSuccessScenario:1. Customer arrives with goods2. Cashier starts new sale3. Cashier enters item identifier4. Systems records sale and presents description and

running total (repeat 3-4 many times)1. System presents total2. …

POS Example:

• Take from our various analyses, the relevant class names.

• Don’t include things that aren’t part of this iteration, for example CreditCardAuthorization.

Fig. 9.7

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Fig. 9.8NOTE: We keep the box not fully formed; easyto add stuff.

What about Using a Tool?

• There is little motivation to update a model unless it is easy to do so.

• That is why the author likes the whiteboard.• The practical reason for updating is to keep the model as

a documentation tool (for version 2).

Missing Classes (Receipt):

• This is a report on functionality of other classes so is a repetition of previously modeled info. Reason to exclude.

• Confers rights to return to Customer: Reason to Model• Not doing returns now: Leave it out.• Rules of Thumb:

– Use existing names– exclude features that are not part of the iteration or

plan– don’t add stuff that is not there

Weird Domains like Telecommunications:

• Some classes might be: Message, Connection, Port, dialog, Route, Protocol.

Attributes vs Classes:

• A common mistake is to cross identify these things.• Rule of Thumb 1: If you don’t think of something as a

number or string in the real world, it probably is a class.• Rule of Thumb 2: Classes are capable of independent

existence; attributes are properties of things.• Rule of Thumb 3: If all you know about something is it

exists and nothing else; it may be an attribute.

Examples:

Salestore

Sale Storephone

or?

Flightdestination

Flight Airportname

or?

When to Model Descriptions?

• A description class describes something else.• The difference between an object and a description of it

is like the difference between a copy of a book and a book itself. If you run out of copies you may still need to know about the book.

• Intension vs Extension• Physical Object vs Type of Thing• So we need an Item class and a ProductDescription.• How do you tell them apart? Identify their keys or

identifying attributes.– serial number vs model number

Fig. 9.9

Item

descriptionpriceserial numberitemID

ProductDescription

descriptionpriceitemID

Item

serial number

Describes Better

Worse

1 *

Book Copy

Fig. 9.10

Worse

Flight

datetime

FlightDescription

number

Airport

name

Describes-flights-to

Described-by

Flight

datenumbertime

Airport

name

Flies-to

Better

1*

1*

1

*

What is the key?

Associations:

• A relationship between classes (or instances of classes).• When do we show them?

– when we need (real-world) to remember the other• Too many associations make for an unwieldy diagram• What associations are “implemented”?

– Not all– some new ones appear between software objects

• Representations:

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

How many instances of Sale can be associated with an instance of Register? Ans: 0 or 1

NOTE: Not over time!!

Fig. 9.13

ItemStore Stocks

*

multiplicity of the role

1

Many instances of itemwith the same store

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.

*

0 instances of Store related to some instance of Item

NOTE: For those in my database class: theseare not participation numbers.

Multiple Associations:

Fig. 9.16

Flight Airport

Flies-to

Flies-from

*

* 1

1

Employee manages

Where to Start Adding Associations:

A is a transaction related to another transaction B

Payment - Sale

A is a line item of a transaction B SalesLineItem - Sale

A is a product or service for a transaction (or line item) B

Item - SalesLineItem

A is a role related to a transaction B Customer - Payment

A is a physical or logical part of B Drawer - Register

A is physically or logically contained in B Register - Store

A is a description of B ProductDescription - Item

A is known/logged/captured in B Sale - Register

A is a member of B Cashier - Department

A is an organizational subunit of B Department - Store

A uses or manages or owns B Cashier - Register

A is next to B SalesLineItem - SalesLineItem

Fig. 9.17

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

Fig. 9.18

Attributes:

• A property of a class or association.• Find them in the text analysis of the requirements

Fig. 9.19

Sale

dateTime/ total : Money

attributes

derived attribute

derived

Fig. 9.20

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

NOTE: You can “invent” obvious data types on your own

Fig. 9.21

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

I disagree

An Item may never be sold

Fig. 9.22

Cashier

namecurrentRegister

Cashier

name

Register

number

Uses

Worse

Better

not a "data type" attribute

1 1

Register is a complex thing

Fig. 9.23

Flight

Flight

destinationWorse

BetterFlies-to Airport1 1

destination is a complex concept

Guidelines for Representing Data Types:

• composed of separate sections line an address• operations associated with it – social security number• has other attributes like validity date range• a quantity with a unit type• type abstraction: URL

Fig. 9.24

OK

OK

ProductDescription

ProductDescription

itemId : ItemID

1Store

Store

address : Address

11 1

ItemID

idmanufacturerCodecountryCode

Address

street1street2cityName...

Might need Addresses for a delivery schedule

Never gets shown as a class because it has not complexity other than the fact that it is a code.

Fig. 9.25

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

Don’t use attributes to represent associations in the Domain Model (ie foreign key syndrome)

Fig. 9.26

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

Quantities and Units

Fig. 9.27

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.28