Software Design & Architecture

Domain Models
 What is Domain Model?

• Fundamental OO analysis model

– Shows important concepts in the domain of interest
– Depicts objects, their attributes, and associations between objects
– Visual dictionary of concepts & their relationships
– Inspiration for SW objects in class diagram
– Does NOT show object’s operations

2
 Process Sale Use Case from the NextGen POS
System
• Main Success Scenario (or Basic Flow):
1. Customer arrives at a POS checkout with goods and/or services to
purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price,
and running total. Price calculated from a set of price rules.
5. Cashier repeats steps 2-3 until indicates done.
6. System presents total with taxes calculated.
7. Cashier tells Customer the total, and asks for payment.
8. Customer pays and System handles payment.
9. System logs the completed sale and sends sale and payment
information to the external Accounting (for accounting and
commissions) and Inventory systems (to update inventory).
10. System presents receipt.
11. Customer leaves with receipt and goods (if any).

3
 Partial Domain Model – A Visual Dictionary
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 
Payment
1
amount
4
 Guidelines
1. Domain Objects

visualization of a real-world concept in

Sale the domain of interest

dateTime it is a not a picture of a software class

5
 Guidelines
2. Conceptual Objects, not Software Objects

SalesDatabase
oid
software artifact; not part
a v of domain model

Sale
void software class; not part
a date of domain model
time

print()

6
 Guidelines
3. Domain Models vs. Data Model

• Don’t confuse domain models with data model (database

models such as ERD)
– Object might have attributes that aren’t persisted

– Object might have no attributes

– Such objects wouldn’t be in a data model

7
 How to Create a Domain Model?

• Bounded by the requirements under design perform

following three steps:

1. Find the conceptual classes

2. Draw them as classes in a UML class diagram

3. Add associations and attributes

8
 Guidelines
1. How to find Conceptual Classes?

• Three methods/approaches to find conceptual classes

1. Reuse or modify existing models (if any)

2. Use a category list

3. Identify noun phrases in use case text

9
Method 2: Using a Category List
Conceptual Class Category Examples
business transactions Sale, Payment
Guideline: These are critical (they involve Reservation
money), so start with transactions.
transaction line items SalesLineItem
Guideline: Transactions often come with
related line items, so consider these next.
product or service related to a Item
transaction or transaction line item Flight, Seat, Meal
Guideline: Transactions are for something
(a product or service). Consider these next.
where is the transaction recorded? Register, Ledger
Guideline: Important. FlightManifest
roles of people or organizations related Cashier, Customer, Store
to the transaction; actors in the use case MonopolyPlayer Passenger,
Guideline: We usually need to know about Airline
the parties involved in a transaction.

List continues on next slide … 10

 Method 2: Using a Category List
Conceptual Class Category Examples
noteworthy events, often with a time or place we need Sale, Payment MonopolyGame Flight
to remember
physical objects Item, Register Board, Piece, Die
Guideline: This is especially relevant when creating Airplane
device-control software, or simulations.
descriptions of things ProductDescription
Guideline: See page. 147 of Craig Larman 3 edition for FlightDescription
rd

discussion.
catalogs ProductCatalog
Guideline: Descriptions are often in a catalog. FlightCatalog
containers of things (physical or information) Store, Bin Board Airplane
things in a container Item Square (in a Board) Passenger
other collaborating systems CreditAuthorizationSystem
AirTrafficControl
records of finance, work, contracts, legal matters Receipt, Ledger
MaintenanceLog
financial instruments Cash, Check, LineOfCredit
TicketCredit
schedules, manuals, documents that are regularly DailyPriceChangeList
referred to in order to perform work RepairSchedule 11
 Method 3: Finding Conceptual Classes with
Noun Phrase Identification
• Linguistic analysis:
– Identify the nouns and noun phrases in textual descriptions of a
domain, and consider them as candidate conceptual classes or
attributes
– Have to differentiate between attribute and class?
– A weakness of this approach is the imprecision of natural
language
– It is recommended in combination with the Conceptual Class
Category List technique.
• The fully dressed use cases are an excellent description to
draw from
12
 Process Sale Use Case from The NextGen POS
System
• Main Success Scenario (or Basic Flow):
1. Customer arrives at a POS checkout with goods and/or services to
purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier.
4. System records sale line item and presents item description, price,
and running total. Price calculated from a set of price rules.
5. Cashier repeats steps 2-3 until indicates done.
6. System presents total with taxes calculated.
7. Cashier tells Customer the total, and asks for payment.
8. Customer pays and System handles payment.
9. System logs the completed sale and sends sale and payment
information to the external Accounting (for accounting and
commissions) and Inventory systems (to update inventory).
10. System presents receipt.
11. Customer leaves with receipt and goods (if any).

13
 Initial POS Domain Model

Register Item Store Sale

Sales
Cashier Customer Ledger
LineItem

Cash Product Product

Payment Catalog Description

14
 Guidelines
1. Objects vs. Attributes

• Attributes are ‘simple’ data types

– e.g., number, text

• Concepts that are described by simple attributes are

objects
– A Store has an address, phone number, etc.

• As another example, consider the domain of airline

reservations. Should destination be an attribute of Flight,
or a separate conceptual class Airport?
15
 Guidelines
1. Objects vs. Attributes

Flight destination is a complex

Worse concept
destination

Flight 1 Flies-to 1 Airport

Better

16
 Guidelines
2. Description classes

• When to model with Description classes

– A description class Contain info that describes something else,
very common in OO models
• A ProductDescription that records the price, picture, and text
description of an Item.
– If description is not separate from the underlying object, then
deletion of the object results in loss of all info about that object
– Also error prone due to data duplication

17
 Guidelines
2. Description classes

Item

description Worse
price
serial number
itemID

ProductDescription
Item
description Describes Better
price 1 * serial number
itemID

18
 Guidelines
2. Description classes

• When Are Description Classes Useful?

– Add a description class (for example,
ProductDescription) when:
• There needs to be a description about an item or service,
independent of the current existence of any examples of those
items or services.
• Deleting instances of things they describe (for example, Item)
results in a loss of information that needs to be maintained,
but was incorrectly associated with the deleted thing.
• It reduces redundant or duplicated information.

19
 Associations
• Association is a meaningful relationship between objects
• Draw an association when knowledge of relationship needs to be
preserved
– For example, do we need to remember what SalesLineItem instances
are associated with a Sale instance? Definitely, otherwise it would
not be possible to reconstruct a sale, print a receipt, or calculate a
sale total.
– A Cashier may look up ProductDescriptions, but there is no need to
remember the fact of a particular Cashier looking up particular
ProductDescriptions.
• Consider including the following associations in a domain model:
– Associations for which knowledge of the relationship needs to be
preserved for some duration ("need-to-remember" associations).
– Associations derived from the Common Associations List.
20
 Association Notation

association

Records-current
Register Sale
1 1

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

Register Records-current  Sale

1 0..1

association name multiplicity

• An optional "reading direction arrow" indicates the direction to read the

association name; it does not indicate direction of visibility or navigation.
22
 Association Notation
• Applying UML: Roles
– Each end of an association is called a role. Roles may optionally have:
• multiplicity expression
• name
• navigability
• Applying UML: Multiplicity

Store Stocks Item

1
*

multiplicity of the role

Normally, the multiplicity at a particular moment in time 23

 Association Notation

• Name an association based on a ClassName-VerbPhrase-

ClassName format
– Simple association names such as "Has" or "Uses" are
usually poor, as they seldom enhance our understanding of
the domain.
– Sale Paid-by CashPayment

• bad example (doesn't enhance meaning): Sale Uses

CashPayment
24
Association Notation

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

25
 Association Notation

• Multiple Associations Between Two Classes

* Flies-to 1
Flight Airport
Flies-from
1
*

Can have more than 1 association between classes.

26
 Association Notation

• How to Find Associations with a Common Associations

List?

27
 Common Associations List
Category Examples
A is a transaction related to another CashPayment, Sale
transaction B Cancellation, Reservation
A is a line item of a transaction B SalesLineItem, Sale
A is a product or service for a transaction Item, SalesLineItem (or Sale),
(or line item) B Flight, Reservation
A is a role related to a transaction B Customer, Payment
Passenger, Ticket
A is a physical or logical part of B Drawer, Register
Square, Board
Seat, Airplane
A is physically or logically contained in/on Register in Store, Item in Shelf
B Square on Board
Passenger in Airplane
A is a description for B ProductDescription, Item
FlightDescription, Flight
A is Sale, Register
known/logged/recorded/reported/captured Piece, Square
in B Reservation, FlightManifest
28
List continues on next slide …
 Common Associations List
Category Examples
A is a member of B Cashier, Store
Player, MonopolyGame
Pilot, Airline

A is an organizational subunit of Department, Store

B Maintenance, Airline

A uses or manages or owns B Cashier, Register

Player, Piece
Pilot, Airplane

A is next to B SalesLineItem, SalesLineItem

Square, Square
City, City

29
 Some Associations in the Domain Models

• Transactions related to another transaction: Sale Paid-by

CashPayment
• Line items of a transaction: Sale Contains SalesLineItem

• Product for a transaction (or line item): SalesLineItem

Records-sale-of Item

30
 NextGen POS Partial Domain Model Records-sale-of

Product
Ledger Product Description
Catalog Contains
1 1..*
1 1
1
0..1 Records-
Used-by Describes
accounts-
Sales for * *
LineItem Store
Item
Stocks
1 1
* 1..*
1..*
1
Contained-in Logs- Houses
1 completed 1..*

Sale * Register
Captured-on
0..1 1

1 1 Is-for 1
Paid-by  Works-on
1 1 1

CashPayment Customer Cashier

31
 Attributes

• Attribute is a logical data value of an object that needs to

be remembered
– Some attributes are derived from other attributes
• The usual ‘primitive’ data types
– Numbers, characters, Booleans
• Common compound data types
– Date, time (or dateTime), address, SSN, phoneNumber,
bar codes, etc.
– May become full class objects in design
32
 Attributes

• Include attributes that the requirements (for example, use

cases) suggest or imply a need to remember information.
– Sale needs a dateTime attribute.

– Store needs a name and address.

– Cashier needs an ID.

33
 Attribute Notation

attributes
Sale

dateTime
/ total : Money derived
attribute

34
 Data Types

• Relate with associations, not attributes.

Cashier
Worse not a "data type" attribute
name
currentRegister

Cashier Register
Better 1 Uses 1
name number

Don’t use an attribute in lieu of an association

35
 Two Ways to Indicate a Data Type Property of
an Object

ItemID Address

Product 1 1 1 1 street1
OK id Store
Description street2
manufacturerCode
countryCode cityName
...

Product Store
Description
OK address : Address
itemId : ItemID

36
 Do not Use Attributes as Foreign Keys

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

37
 NextGen POS Partial Domain Model Records-sale-of

Product
Ledger Product Description
Catalog Contains
1 itemID
1..*
description
1 1
1 price
0..1 Records-
Used-by Describes
accounts-
Sales for * *
LineItem Store
Item
Stocks
quantity name
1
address
1
* 1..*
1..*
1
Contained-in Logs- Houses
1 completed 1..*

Sale * Register

dateTime Captured-on id
0..1 1
/ total
1
1 1
Is-for  Works-on
Paid-by

1 1 1

CashPayment Customer Cashier

amountTendered id 38
 Recommended Reading

• Chapter # 9: Domain Models from Applying UML

and Patterns: An Introduction to Object-Oriented
Analysis and Design and Iterative Development by
Craig Larman, 3rd Edition

39