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
Sample UP Artifact Relationships
Domain Model
Business
Modeling
Sale
Sales
LineItem
1..*
1
date
...
...
...
quantity
the domain objects,
attributes, and associations
that undergo state changes
conceptual classes –
terms, concepts
attributes, associations
elaboration of
some terms in
the domain
model
Use-Case Model
Requirements
Process Sale
Operation: enterItem(…)
1. Customer arrives
...
2. ...
3. Cashier enters
item identifier.
4....
Post-conditions:
-...
Operation Contracts
Cashier: …
Item ID: …
...
Glossary
Use Case Text
Design Model
: Register
Design
: ProductCatalog
enterItem
(itemID, quantity)
spec = getProductSpec( itemID )
addLineItem( spec, quantity )
...
: Sale
conceptual
classes in
the
domain
inspire the
names of
some
software
classes in
the design
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
concept
or domain
object
Sales
LineItem
1
0..1
quantity
Item
Records-sale-of
*
1..*
Stocked-in
association
Contained-in
1
1
Sale
attributes
date
time
Store
address
name
0..1
1
1
Houses
Paid-by
NOTE: The direction
of references.
1
Payment
amount
1..*
Register
Captured-on 
1
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
v
is
u
a
liz
a
t
io
n
o
fa
r
e
a
lw
o
r
ld
c
o
n
c
e
p
tin
t
h
e
d
o
m
a
in
o
fin
t
e
r
e
s
t
S
a
le
d
a
t
e
T
im
e
itis
a
n
o
ta
p
ic
t
u
r
e
o
fa
s
o
f
t
w
a
r
e
c
la
s
s
d
i
o
v
a
S
a
le
s
D
a
ta
b
a
s
e
d
avoi
S
a
le
d
a
te
tim
e
p
r
in
t(
)
s
o
ftw
a
r
e
a
r
tifa
c
t
;n
o
tp
a
r
t
o
fd
o
m
a
in
m
o
d
e
l
s
o
ftw
a
r
e
c
la
s
s
;n
o
tp
a
r
t
o
fd
o
m
a
in
m
o
d
e
l
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
concept's symbol
Sale
date
time
"A sale represents the event
of a purchase transaction. It
has a date and time."
concept's intension
sale-1
sale-2
sale-3
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
UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.
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.
Sale
Payment
1
1
Pays-for
date
time
amount
inspires
objects
and
names in
This reduces the representational
gap.
Sale
This is one of the big ideas in
object technology.
Payment
amount: Money
getBalance(): Money
1
Pays-for
1
date: Date
startTime: Time
getTotal(): Money
...
UP Design Model
The 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.
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
Conceptual Class Category
Examples
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
List of Categories and possible classes
Conceptual Class Category
Examples
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
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 goods
2. Cashier starts new sale
3. Cashier enters item identifier
4. Systems records sale and presents description and
running total
(repeat 3-4 many times)
1. System presents total
2. …
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
R
e
g
is
te
r
S
a
le
s
L
in
e
Ite
m
C
a
s
h
P
a
y
m
e
n
t
Ite
m
S
to
r
e
S
a
le
C
a
s
h
ie
r
C
u
s
to
m
e
r
L
e
d
g
e
r
P
r
o
d
u
c
t
C
a
ta
lo
g
P
r
o
d
u
c
t
D
e
s
c
r
ip
tio
n
Fig. 9.8
NOTE: We keep the box not fully formed; easy
to 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:
Sale
store
or?
Sale
Store
phone
Flight
destination
or?
Flight
Airport
name
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
W
o
rse
description
price
serialnum
ber
item
ID
P
roductD
escription
description
price
item
ID
Book
Item
D
escribes
1
*
B
etter
serialnum
ber
Copy
Fig. 9.10
Flight
date
number
time
Airport
Flies-to
Worse
1
*
name
What is the key?
Flight
FlightDescription
Described-by
date
time
*
1
Better
number
*
Describes-flights-to
1
Airport
name
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
a
s
s
o
c
ia
tio
n
R
e
g
is
te
r
R
e
c
o
rd
s
-c
u
rre
n
t
1
1
S
a
le
Fig. 9.12
-"readingdirectionarrow
"
-it hasnom
eaningexcept toindicatedirectionof
readingtheassociationlabel
-oftenexcluded
Register
Records-current 
1
0..1
NOTE: Not over time!!
associationnam
e
m
ultiplicity
How many instances of Sale can be associated
with an instance of Register? Ans: 0 or 1
Sale
Fig. 9.13
re
to
S
s
k
c
to
S
1
*
m
Ite
Many instances of item
with the same store
le
ero
fth
ityo
lic
ltip
u
m
Fig. 9.14
*
1..*
1..40
5
3, 5, 8
T
zero or more;
"many"
T
one or more
T
one to 40
T
exactly 5
T
exactly 3, 5, or 8
NOTE: For those in my database class: these
are not participation numbers.
Fig. 9.15
0 instances of Store related to some instance of Item
S
tocks
S
tore
1
or0..1
Item
*
M
ultiplicityshould"1"or"0..1"?
T
heansw
erdependsonourinterest inusingthem
odel.T
ypicallyandpractically,them
uliplicitycom
m
unicatesa
dom
ainconstraint that w
ecareabout beingabletocheckinsoftw
are,if thisrelationshipw
asim
plem
entedor
reflectedinsoftw
areobjectsoradatabase. F
orexam
ple,aparticularitemm
aybecom
esoldordiscarded, andthus
nolongerstockedinthestore.F
romthisview
point,"0..1"islogical,but ...
D
ow
ecareabout that view
point?If thisrelationshipw
asim
plem
entedinsoftw
are, w
ew
ouldprobablyw
ant toensure
that anItemsoftw
areinstancew
ouldalw
aysberelatedto1particularS
toreinstance,otherw
iseit indicatesafault or
corruptioninthesoftw
areelem
entsordata
.
T
hispartialdom
ainm
odeldoesnot represent softw
areobjects,but them
ultiplicitiesrecordconstraintsw
hose
practicalvalueisusuallyrelatedtoourinterest inbuildingsoftw
areordatabases(that reflect ourreal-w
orlddom
ain)
w
ithvaliditychecks.F
romthisview
point,"1"m
aybethedesiredvalue.
Multiple Associations:
Fig. 9.16
*
F
lig
h
t
F
lie
s
-to
1
A
irp
o
rt
F
lie
s
-fro
m
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
Records-sale-of
Ledger
Product
Description
Product
Catalog
Contains
1
1
1..*
1
Recordsaccountsfor
0..1
Sales
LineItem
1
Used-by
Describes
*
*
Store
Item
Stocks
1
1
*
1..*
1..*
Contained-in
1
Logscompleted
1
*
Sale
Houses
1..*
Register
Captured-on
0..1
1
Paid-by
1
CashPayment
1
1
Is-for
1
Customer
1
 Works-on
1
Cashier
Fig. 9.18
Attributes:
• A property of a class or association.
• Find them in the text analysis of the requirements
Fig. 9.19
a
ttrib
u
te
s
S
a
le
d
a
te
T
im
e
/to
ta
l :M
o
n
e
y
derived
d
e
rive
d
a
ttrib
u
te
Fig. 9.20
S
a
l
e
d
a
t
e
T
i
m
e
:D
a
t
e
/t
o
t
a
l:M
o
n
e
y
P
r
i
v
a
t
e
v
i
s
i
b
i
l
i
t
y
a
t
t
r
i
b
u
t
e
s
M
a
t
h
+
p
i:R
e
a
l=
3
.
1
4
{
r
e
a
d
O
n
l
y
}
P
e
r
s
o
n
f
i
r
s
t
N
a
m
e
m
i
d
d
l
e
N
a
m
e
:[
0
.
.
1
]
l
a
s
t
N
a
m
e
P
u
b
l
i
c
v
i
s
i
b
i
l
i
t
y
r
e
a
d
o
n
l
y
a
t
t
r
i
b
u
t
e
w
i
t
h
i
n
i
t
i
a
l
i
z
a
t
i
o
n
NOTE: You can “invent” obvious data types on your own
O
p
t
i
o
n
a
lv
a
l
u
e
Fig. 9.21
S
a
le
sL
in
e
Ite
m
S
a
le
sL
in
e
Ite
m
S
a
le
sL
in
e
Ite
m
An Item may never be sold
Ite
m
E
a
chlin
eite
m
re
co
rd
sa
se
p
a
ra
teite
m
sa
le
.
F
o
re
xa
m
p
le
,1to
fup
a
cka
g
e
.
1
..*
Ite
m
E
a
chlin
eite
m
ca
nre
co
rda
g
ro
u
po
fth
esa
m
ekin
do
fite
m
s
.
F
o
re
xa
m
p
le
,6to
fup
a
cka
g
e
s.
1
..*
Ite
m
0
..1
R
e
co
rd
s-sa
le
-o
f
1
0
..1
R
e
co
rd
s-sa
le
-o
f
0
..1
R
e
co
rd
s-sa
le
-o
f
/q
u
a
n
tity
d
e
rive
da
ttrib
u
tefro
m
th
em
u
ltip
licityva
lu
e
I disagree
Fig. 9.22
Register is a complex thing
C
a
s
h
ie
r
n
o
ta
"
d
a
t
a
t
y
p
e
"a
t
t
r
ib
u
t
e
W
o
r
s
e
n
a
m
e
c
u
r
r
e
n
t
R
e
g
i
s
t
e
r
C
a
s
h
ie
r
B
e
t
t
e
r
n
a
m
e
s
e
s
1 U
1
R
e
g
is
t
e
r
n
u
m
b
e
r
Fig. 9.23
W
o
r
s
e
F
lig
h
t
d
e
s
t
in
a
t
io
n
is
a
c
o
m
p
le
x
c
o
n
c
e
p
t
d
e
s
t
in
a
t
io
n
B
e
t
t
e
r
F
lig
h
t
lie
s
t
o 1 A
1 F
ir
p
o
r
t
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
Might need Addresses for a
delivery schedule
A
d
d
r
e
s
s
I
t
e
m
I
D
O
K
P
r
o
d
u
c
t
D
e
s
c
r
ip
t
io
n
P
r
o
d
u
c
t
D
e
s
c
r
ip
t
io
n
O
K
it
e
m
I
d
:I
t
e
m
I
D
1 1
id
m
a
n
u
f
a
c
t
u
r
e
r
C
o
d
e
c
o
u
n
t
r
y
C
o
d
e
S
t
o
r
e
1
1s
t
r
e
e
t
1
s
t
r
e
e
t
2
c
it
y
N
a
m
e
.
.
.
S
t
o
r
e
a
d
d
r
e
s
s
:A
d
d
r
e
s
s
Never gets shown as a class because it has not complexity
other than the fact that it is a code.
Fig. 9.25
Don’t use attributes to represent associations in
the Domain Model (ie foreign key syndrome)
C
a
s
h
ie
r
W
o
r
s
e
n
a
m
e
c
u
r
r
e
n
t
R
e
g
i
s
t
e
r
N
u
m
b
e
r
C
a
s
h
ie
r
B
e
t
t
e
r
n
a
m
e
a
"
s
im
p
le
"
a
t
t
r
ib
u
t
e
,b
u
tb
e
in
g
u
s
e
d
a
s
a
f
o
r
e
ig
n
k
e
y
t
o
r
e
la
t
e
t
o
a
n
o
t
h
e
ro
b
je
c
t
o
r
k
s
o
n1
1W
R
e
g
is
t
e
r
n
u
m
b
e
r
Fig. 9.26
Quantities and Units
P
a
y
m
e
n
t
n
o
tu
s
e
fu
l
a
m
o
u
n
t:N
u
m
b
e
r
P
a
y
m
e
n
t
*
P
a
y
m
e
n
t
a
m
o
u
n
t:Q
u
a
n
tity
P
a
y
m
e
n
t
a
m
o
u
n
t:M
o
n
e
y
H
a
s-a
m
o
u
n
t
1
Q
u
a
n
tity
a
m
o
u
n
t:N
u
m
b
e
r
q
u
a
n
titie
sa
rep
u
red
a
ta
v
a
lu
e
s,s
oa
res
u
ita
b
leto
s
h
o
wina
ttrib
u
tes
e
c
tio
n
v
a
ria
tio
n
:M
o
n
e
yisa
s
p
e
c
ia
liz
e
dQ
u
a
n
tityw
h
o
s
e
u
n
itisac
u
rre
n
c
y
Is
-in

*
U
n
it
1
...
b
e
tte
r
Fig. 9.27
Records-sale-of
Ledger
Product
Description
Product
Catalog
Contains
1
1
1..*
1
1
Recordsaccountsfor
0..1
Sales
LineItem
itemID
description
price
Used-by
Describes
*
*
Store
Item
Stocks
quantity
1
1..*
Contained-in
name
address
1
Logscompleted
1
*
Sale
*
1..*
Houses
1..*
Register
Captured-on
1
0..1
dateTime
/ total
1
id
1
1
Paid-by
1
CashPayment
amountTendered
1
Is-for
 Works-on
1
1
Customer
Cashier
id
Fig. 9.28