Domain Models

Domain Model in UML Class Diagram Notation

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 4

conceptor domain object

association

attributes

A “visual dictionary”

Domain Models

• Key object-oriented analysis step: Decompose domain into noteworthy concepts or objects

• UML class diagrams used to draw domain models – Conceptual perspective. Shows:

• Domain objects (conceptual classes) • Associations between domain objects • Attributes of conceptual classes

• Domain model is NOT a model of software objects or our design

• The following should NOT be in a domain model – Software artifacts: Window, database, … – Responsibilities or methods

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 modelavo

id

software class; not part of domain model

Sale

datetime

print()

avoid

Software Class Names Inspired by Domain Model Objec ts

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

How to create a domain model?

• Find conceptual classes – How?

• Re-use or modify existing models • Use a category list • Identify noun phrases • More on these later

• Draw them as classes in a UML class diagram

• Add associations and attributes – More on this later

Identifying nouns as candidates for domain objects

Candidate Conceptual Classes: Process Sale, Iterati on 1

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Attributes vs. Classes

• Should “something” be – an attribute of a class, or – a separate conceptual class

• Examples: – Store: An attribute of Sale or separate class

• Store: Not a number or text • Should be separate conceptual class

– Flight destination: An attribute or a separate class • Destination is an airport, not a number • Should be separate conceptual class

• Guideline: – If we thing of something as simply a number or text in

real life, it should be an attribute. – Otherwise it should be a conceptual class.

“Description” Classes

• A description class contains information that describes something else – Example: ProductDescription – Records price, picture and text description of an item

• Why use them? Why not include all that information in the Product class? – We need this information stored and represented even though

there are no objects of that particular product type. – Don’t want to duplicate product information for each duplicate

product object • Serial number belongs with product object • Picture of product belongs with product description

• Need objects that are “specifications” or “descriptions” of other objects

Description class example

Item

descriptionpriceserial numberitemID

ProductDescription

descriptionpriceitemID

Item

serial number

Describes Better

Worse

1 *

Description class example

Worse

Flight

datetime

FlightDescription

number

Airport

name

Describes-flights-to

Described-by

Flight

datenumbertime

Airport

name

Flies-to

Better

1*

1*

1

*

Even when that flight is not scheduled that day, the flight description exists.

Associations

• Association: A relationship between (instances of) classes that indicates some meaningful and interesting connection.

• Used to show relationships that need to be remembered and preserved for some duration

SaleRegisterRecords-current

1 1

association

Which relationships need to be remembered?

• Example: Does a Sale-SalesLineItem relationship need to be remembered (preserved)?\ – Yes, otherwise can’t process returns or exchanges.

• Example: Cashier looks up ProductDescription – Don’t need to remember/store.

• Example: – What square is a Monopoly player on?

• Need to remember

– Dice total tells us which Square to move to • Do we need to store this fact with the Dice or the Square? • No!

Common Associations List (i)

Common Associations List (ii)

Common Associations List (iii)

Association Directionalities

SaleRegister Records-current 40..11

association name multiplicity

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

How to name an association?

• Pattern: – Class name – verb phrase – class name – Readable and meaningful

• Try to avoid “has” or “uses”. These give no extra information

Association Multiplicities

ItemStore Stocks

*

multiplicity of the role

1

Multiplicities

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

Multiple Associations

Flight Airport

Flies-to

Flies-from

*

* 1

1

POS Domain Model Example:

R egiste r

ItemS tore

S a le

C ashP aym ent

S a lesL ine Item

C ash ierC ustom er

P roductC ata log

P roductD escrip tion

S tocks

*

H ouses

1..*

U sed -by

*

C onta ins

1 ..*

D escribes

*

C aptured -on

C onta ined -in

1 ..*

R ecords -sa le -o f

0 ..1

P a id-by Is-fo r

Logs -com ple ted

*

3 W orks-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

R ecords -accounts -

fo r

1

1

Example: Domain Model for the Monopoly Game

Attributes

Sale

dateTime/ total : Money

attributes

derived attribute

• An attribute: A logical data value stored in an object

More detailed attribute notation

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

visibility name: type multiplicity = default value {property-string}

• Attribute requirements (such as an optional middle name) should also be placed in the Glossary.

Derivable attributes

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

• The “/” sign: the value of this attribute can be calculated or derived from other attributes

• Still, it is noteworthy and may be recorded separately

Most attribute types should be primitive data types

Cashier

namecurrentRegister

Cashier

name

Register

number

Uses

Worse

Better

not a "data type" attribute

1 1

• Guideline: The attributes in a domain model should be (simple, primitive) data types – Boolean, Date, Number (Integer, Real), String (Text), Time, Phone

Number, ID Number, Postal Code, …

• Non-data type relationships (i.e., conceptual class relationships) should be expressed using associations, not attributes.

Do we need a new box for these classes?

OK

OK

ProductDescription

ProductDescription

itemId : ItemID

1Store

Store

address : Address

11 1

ItemID

idmanufacturerCodecountryCode

Address

street1street2cityName...

Attributes representing “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

• Avoid them!

Payment

amount : Number

Payment Quantity

amount : Number

Unit

...

Payment

amount : Quantity

Has-amount41*

Is-in41*

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

R eg is te r

id

ItemS to re

nam eaddress

S a le

da teT im e/ to ta l

C ashP aym en t

am oun tT ende red

S a lesL ine Item

quantity

C ash ie r

id

C ustom er

P roduc tC a ta log

P roductD escrip tion

item IDdescrip tionp rice

S tocks

*

H ouses

1 ..*

U sed -by

*

C on ta ins

1 ..*

D escribes

*

C aptu red -on

C on ta ined -in

1 ..*

R ecords -sa le -o f

0 ..1

P a id -by Is -fo r

Logs -com p le ted

*

3 W orks-on

1

1

1

1 1 ..*

1

1

1

1

1

1

1

0 ..1 1

1

Ledger

R eco rds -accoun ts -

fo r

1

1

POS Domain Model Example:

POS Domain Model Example:

Monopoly Domain Model Example