Domain Model

Domain Models
„ Fundamental OO analysis model
– Shows important concepts in the domain of
interest
– Visual dictionary of concepts & their
relationships
– Inspiration for SW objects in class diagram
– Depicts objects, their attributes, associations
between objects
– Does NOT show object’s operations
 Sam ple UP Artifact Relationships

Dom ain M odel

Sale 1 1..* Sales

Business ...
LineItem
M odeling
date
...
... quantity

conceptual classes – the domain objects, elaboration of

terms, concepts attributes, and associations some terms in
attributes, associations that undergo state changes the dom ain
model
Use-Case Model

Process Sale Operation: enterItem(… ) conceptual

Cashier: … classes in
1. Customer arrives Item ID: … the
Post-conditions:
... ... domain
Require- -...
2. ... inspire the
m ents
3. Cashier enters names of
Operation Contracts Glossary some
item identifier.
4.... software
classes in
Use Case Text the design

Design Model

: Register : ProductCatalog : Sale

enterItem
(itemID, quantity)
Design
spec = getProductSpec( itemID )

addLineItem ( spec, quantity )

...
Partial Domain Model – A Visual Dictionary

concept Sales
Item
or dom ain LineItem Records-sale-of
object 1
quantity 0..1

1..* *
Stocked-in
association Contained-in

1 1

Sale Store

attributes date address

tim e 0..1 nam e
1
1
Houses
Paid-by 1.. *

1 Register
Captured-on 4
Paym ent
1
am ount
 Domain Model
„ It shows an abstraction of the conceptual
classes, because there are many other
things one could communicate about
registers, sales, and so forth.
„ Guideline:
– Avoid a waterfall-mindset big-modeling effort
to make a thorough or "correct" domain
model. it won't ever be either, and such over-
modeling efforts lead to analysis paralysis,
with little or no return on the investment.
 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

 Conceptual classes not
Software Objects

S a le sD a ta b a se
o id
so ftw a re a rtifa ct; n o t p a rt
av o f d o m a in m o d e l

S a le
o id so ftw a re cla ss ; n o t p a rt
av d a te o f d o m a in m o d e l
tim e

p rin t()
 Conceptual Classes
„ The domain model illustrates conceptual classes or
vocabulary in the domain.
„ Informally, a conceptual class is an idea, thing, or
object.
„ Conceptual class may be considered in terms of its
– Symbol – words or images representing a conceptual class
– Intension – the definition of a conceptual class
– Extension – the set of examples to which the conceptual class
applies
„ Example
– Symbol – Sale
– Intension – represents the event of a purchase transaction, and
has a date and time
– Extension – all the examples/instances of sales
A Conceptual Class has a Symbol, Intension,
and Extension
Sale concept's sym bol

date
tim e

"A sale represents the event concept's intension

of a purchase transaction. It
has a date and tim e."

sale-1

sale-2 concept's extension

sale-3

sale-4
 Domain models
„ Don’t confuse with data model
– Object might have attributes that aren’t
persisted
– Object might have no attributes
– Such objects wouldn’t be in a data model
 Domain Models
„ Domain model simpler than full-blown
design class model
„ Easier for users to understand
„ Use it to educate users about basic OO
modeling
„ Reduces tendency for modeler to drill too
deep too quickly
 Motivation: Domain Models
„ OO modeling lowers the representational
gap between our mental and software
models.
„ Use software class names in the domain
layer inspired from names in the domain
model, with objects having domain-
familiar information and responsibilities.
 Lower Representational Gap with OO Modeling
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.
 Domain Models
„ How to create a domain model?
– Bounded by the current iteration
requirements under design:
ƒ Find the conceptual classes
ƒ Draw them as classes in a UML class diagram.
ƒ Add associations and attributes
Guideline: How to Find Conceptual Classes?

1. Reuse or modify existing models

2. Use a category list
3. Identify noun phrases
 Conceptual Class Category Examples
business transactions Sale, Payment
Guideline: These are critical (they Reservation
involve 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 Cashier, Customer, Store
related to the transaction; actors MonopolyPlayer Passenger,
in the use case Airline
Guideline: We usually need to know
about the parties involved in a
transaction.
 Conceptual Class Category Examples
noteworthy events, often with a time or place Sale, Payment MonopolyGame
we need to remember Flight
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 p. 147 for discussion. FlightDescription
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 Receipt, Ledger
matters MaintenanceLog
financial instruments Cash, Check, LineOfCredit
TicketCredit
schedules, manuals, documents that are DailyPriceChangeList
regularly referred to in order to perform work RepairSchedule
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 for
 Example
„ 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).
 Initial POS Domain Model

Register Item Store Sale

Sales
Cashier Custom er Ledger
LineItem

Cash Product Product

Paym ent Catalog Description
 Guidelines
„ Agile Modeling and Maintain the Model in a Tool
„ Report Object in the domain
– include it in domain model or not?
– e.g., Receipt is only a report of Sale and Payment
„ Think like a Mapmaker
– Use the existing names in the territory. For example,
if developing a model for a library, name the
customer a "Borrower" or "Patron" the terms used by
the library staff.
– Exclude irrelevant or out-of-scope features.
 Guidelines
„ How to Model the Unreal World?
– e.g., Software for Telecommunication
– It requires a high degree of abstraction
ƒ listening carefully to the core vocabulary and
concepts that domain experts use.
„A Common Mistake with Attributes vs.
Classes
– If we do not think of some conceptual class X
as a number or text in the real world, X is
probably a conceptual class, not an attribute.
 Guidelines
„ 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?
 Guidelines: 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
Guidelines: Description classes

Item

description Worse
price
serial number
itemID

ProductDescription
Item
description Describes Better
price 1 * serial number
itemID
Guidelines : 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.
 Guidelines: Associations
„ Associations
– A meaningful relationship between objects
– 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.
 Guidelines: Associations
„ Why Should We Avoid Adding Many Associations?
– Many lines on the diagram will obscure it with "visual noise.“
– focus on "need-to-remember" associations.
„ Associations are NOT
– A model of data flows
– DB foreign keys
– Instance variables
– SW object connections
„ it is a statement that a relationship is meaningful in a
purely conceptual perspective in the real domain.
– Many, but not all, associations will be implemented eventually
Applying UML: Association Notation

association

Records-current
Register Sale
1 1
 Applying UML: Association Notation
-"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

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

association name; it does not indicate direction of visibility or
navigation.
Applying UML: 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
Applying UML: 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

S to re S to c k s Ite m
1
*

m u ltip lic ity o f th e ro le

Normally, the multiplicity at a particular moment in time

Applying UML: Association Notation

z e ro o r m o re ;
* T
"m a n y "

1 ..*
T o n e o r m o re

1 . .4 0
T o n e to 4 0

5
T e x a c t ly 5

3, 5, 8
T e x a c t ly 3 , 5 , o r 8
Applying UML: Association Notation
„ Multiple Associations Between Two Classes

* Flies-to 1
Flight Airport
Flies-from
1 between classes.
*
Can have more than 1 association
A class can also have an association with itself! Can you
think of an example?
Applying UML: Association Notation
„ How to Find Associations with a Common
Associations List?
 Common Associations List.
Category Examples
A is a transaction related to another transaction B CashPaymentSale
CancellationReservation

A is a line item of a transaction B SalesLineItemSale

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

A is a role related to a transaction B CustomerPayment

PassengerTicket

A is a physical or logical part of B DrawerRegister

SquareBoard
SeatAirplane

A is physically or logically contained in/on B RegisterStore, ItemShelf

SquareBoard
PassengerAirplane

A is a description for B ProductDescriptionItem

FlightDescriptionFlight

A is known/logged/recorded/reported/captured in B SaleRegister
PieceSquare
ReservationFlightManifest
 Common Associations List.
Category Examples

A is a member of B CashierStore
PlayerMonopolyGame
PilotAirline

A is an organizational subunit of B DepartmentStore

MaintenanceAirline

A uses or manages or owns B CashierRegister

PlayerPiece
PilotAirplane

A is next to B SalesLineItemSalesLineItem
SquareSquare
CityCity
 Example: 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.
 NextGen POS partial domain model.
R e c o r d s -s a le -o f

P ro d u c t
Ledger P ro d u c t D e s c r ip 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 c r ib e s
a c c o u n ts -
S a le s fo r * *
L in e Ite m S to r e
Ite m
S to c k s
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 is te r
C a p tu r e d - o n
0 ..1 1

1 1 Is -fo r 1
P a id - b y 3 W o r k s -o n
1 1 1

C ashP aym ent C u s to m e r C a s h ie r

 Attributes
„ Attributes
– 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
 Attributes
„ Includeattributes 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.
 Applying UML: Attribute
Notation

a ttr ib u te s
S a le

d a te T im e
/ to ta l : M o n e y d e r iv e d
a ttr ib u te
 Applying UML: Attribute
Notation

Sale Math Person

- dateTime : Date + pi : Real = 3.14 {readOnly} firstName

- / total : Money middleName : [0..1]
lastName

Private visibility visibility on

Showing domain
Public visibilitymodel
readonly is probably overkill. We’ll talk
attributes
about visibility laterattribute
in thewith initialization
course. Optional value
 Applying UML: Derived Attribute
„ The total attribute in the Sale can be calculated or
derived from the information in the SalesLineItems.

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
 Data Types
„ Relate with associations, not attributes.

Cashier
Worse not a "data type" attribute
name
currentRegister

Cashier Register
Better 1 Uses 1
nameDon’t use an attribute in lieu of an association
number
 Attributes

Flight destination is a com plex

W orse concept
destination

Flight 1 Flies-to 1 Airport

Better
 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
 Do Not Use Attributes as Foreign Keys

Cashier
W orse a "sim ple" attribute, but being
nam e used as a foreign key to relate to
currentRegisterNum ber another object

Cashier Register
Better 1 W orks-on 1
nam e num ber
 Modeling Quantities

Paym ent
not useful
am ount : Num ber

Paym ent Quantity Unit

Has-am ount4 Is-in4
1 1
* am ount : Num ber * ...

Paym ent quantities are pure data

values, so are suitable to
am ount : Quantity better
show in attribute section

Paym ent variation: M oney is a

specialized Quantity whose
am ount : M oney unit is a currency
NextGen POS Partial Domain Model
Records-sale-of

Product
Ledger Product Description
Catalog Contains
1 item ID
1..*
description
1 1
1 price
0..1 Records-
Used-by Describes
accounts-
Sales for * *
LineItem Store
Item
Stocks
quantity 1 nam e 1
address * 1..*
1..*
1
Contained-in Logs- Houses
1 com pleted 1.. *

Sale * Register

dateTim e Captured-on id
0..1 1
/ total
1
1 1
Is-for 3 W orks-on
Paid-by

1 1 1

CashPaym ent Custom er Cashier

am ountTendered id