The document discusses domain models and how they are represented using UML class diagrams. It explains that a domain model shows the key concepts or objects in a domain and the associations between them. It should not include software artifacts or responsibilities. Conceptual classes are identified by examining noun phrases. Descriptions classes are used to store attributes that describe other classes. Associations indicate meaningful relationships between classes that need to be preserved.

1. Domain Models

2. Domain Model in UML Class Diagram Notation
concept Sales
Item
or domain LineItem Records-sale-of
object 1
quantity 0..1
1..* *
Stocked-in
association Contained-in
1 1
Sale Store
attributes date address
time 0..1 name
1
1
Houses
Paid-by 1..*
1 Register
Captured-on 4
Payment
1
amount
A “visual dictionary”

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

4. visualization of a real-world concept in
Sale the domain of interest
dateTime it is a not a picture of a software class

5. SalesDatabase
oid
software artifact; not part
av of domain model
Sale
oid software class; not part
av date of domain model
time
print()

6. Software Class Names Inspired by Domain Model Objects
UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.
Sale
A Payment in the Domain Model Payment 1
1 Pays-for
is a concept, but a Payment in date
the Design Model is a software amount
time
class. They are not the same
thing, but the former inspired the
inspires
naming and definition of the
objects
latter.
and
names in
This reduces the representational
gap.
Sale
This is one of the big ideas in Payment
object technology. 1 1 date: Date
Pays-for
amount: Money startTime: Time
getBalance(): Money 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.

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

11. Identifying nouns as candidates for domain objects

12. Candidate Conceptual Classes: Process Sale, Iteration 1
Register Item Store Sale
Sales
Cashier Customer Ledger
LineItem
Cash Product Product
Payment Catalog Description

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

15. “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

16. Description class example
Item
description Worse
price
serial number
itemID
ProductDescription
Item
description Describes Better
price 1 * serial number
itemID

17. Description class example
Flight
Airport
date Flies-to Worse
number 1 name
time *
Flight
FlightDescription Better
Described-by
date
time * 1 number
*
Describes-flights-to
1
Airport
name
Even when that flight is not
scheduled that day, the flight description exists.

18. 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
association
Records-current
Register Sale
1 1

19. 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!

20. Common Associations List (i)

21. Common Associations List (ii)

22. Common Associations List (iii)

23. Association Directionalities
-"reading direction arrow"
-it has no meaning except to indicate direction of
reading the association label
-often excluded
Register Records-current 4 Sale
1 0..1
association name multiplicity

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

25. Association Multiplicities
Store Stocks Item
1
*
multiplicity of the role

26. Multiplicities
zero or more;
* T
"many"
1..*
T one or more
1..40
T one to 40
5
T exactly 5
3, 5, 8
T exactly 3, 5, or 8

27. Multiple Associations
* Flies-to 1
Flight Airport
Flies-from
1
*

28. POS Domain Model Example:
R e c o rd s -s a le -o f
P ro d u ct
Ledger P ro d u c t D e s c rip tio n
C a ta lo g C o n ta in s
1 1 .. *
1 1
1
0 ..1 R e c o rd s -
U s e d -b y D e s crib e s
a c c o u n ts -
S a le s fo r * *
L in e Ite m S to re
Ite m
S to c ks
1 1
* 1 ..*
1 .. *
1
C o n ta in e d -in Logs- H ouses
1 c o m p le te d 1 .. *
S a le * R e g iste r
C a p tu re d -o n
0 ..1 1
1 1 Is -fo r 1
P a id -b y 3 W o rk s -o n
1 1 1
C ashP aym ent C u s to m e r C a s h ie r

29. Example: Domain Model for the Monopoly Game

30. Attributes
attributes
Sale
dateTime
/ total : Money derived
attribute
• An attribute: A logical data value stored in an object

31. More detailed attribute notation
visibility name: type multiplicity = default value {property-string}
Sale Math Person
- dateTime : Date + pi : Real = 3.14 {readOnly} firstName
- / total : Money middleName : [0..1]
lastName
Private visibility Public visibility readonly
attributes attribute with initialization Optional value
• Attribute requirements (such as an optional middle name)
should also be placed in the Glossary.

32. Derivable attributes
SalesLineItem Item Each line item records a
0..1 Records-sale-of 1
separate item sale.
For example, 1 tofu package.
SalesLineItem Item
0..1 Records-sale-of 1..* Each line item can record a
group of the same kind of items.
For example, 6 tofu packages.
SalesLineItem Item
0..1 Records-sale-of 1..*
/quantity
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

33. Most attribute types should be primitive data types
Cashier
Worse not a "data type" attribute
name
currentRegister
Cashier Register
Better 1 Uses 1
name number
• 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.

34. Do we need a new box for these classes?
ItemID Address
Product 1 1 1 1 street1
OK id Store
Description street2
manufacturerCode
countryCode cityName
...
Product Store
Description
OK address : Address
itemId : ItemID

35. Attributes representing “foreign keys”
• Avoid them!
Cashier
Worse a "simple" attribute, but being
name used as a foreign key to relate to
currentRegisterNumber another object
Cashier Register
Better 1 Works-on 1
name number

36. Payment
not useful
amount : Number
Payment Quantity Unit
Has-amount4 Is-in4
1 1
* amount : Number * ...
Payment quantities are pure data
values, so are suitable to
amount : Quantity better
show in attribute section
Payment variation: Money is a
specialized Quantity whose
amount : Money unit is a currency

37. POS Domain Model Example:
R e c o rd s -s a le -o f
P ro d u c t
Ledger P ro d u c t D e s c rip tio n
C a ta lo g C o n ta in s
1 ite m ID
1 .. *
d e s c rip tio n
1 1
1 p ric e
0 ..1 R e c o rd s -
U s e d -b y D e s c rib e s
a c c o u n ts -
S a le s fo r * *
L in e Ite m S to re
Ite m
S to c k s
q u a n tity 1 nam e 1
a d d re s s * 1 ..*
1 .. *
1
C o n ta in e d -in Logs- H ouses
1 c o m p le te d 1 .. *
S a le * R e g is te r
d a te T im e C a p tu re d -o n id
0 ..1 1
/ to ta l
1
1 1
Is -fo r 3 W o rk s -o n
P a id -b y
1 1 1
C ashP aym ent C u s to m e r C a s h ie r
a m o u n tT e n d e re d id

38. POS Domain Model Example:

39. Monopoly Domain Model Example