TK2023 Object-Oriented
Software Engineering
CHAPTER 5
DOMAIN MODELLING
INTRODUCTION


One of the steps in object-oriented analysis is
the decomposition of a domain of interest into
individual conceptual classes or objects (realworld objects).
An important artifact created in this step is a
domain model (also known as conceptual
model, domain object model and analysis
object model).
DOMAIN MODELS


A domain model is a visual representation of
conceptual classes or real-world objects in a domain
of interest.
In UML, a domain model is illustrated with a set of
class diagrams in which no operations are
defined.
It shows:
 conceptual classes (concepts / domain objects)
 associations between conceptual classes
 attributes of conceptual classes
Sales
LineItem
concept
or domain
object
1
0..1
quantity
Item
Records-sale-of
*
1..*
association
Stocked-in
Contained-in
1
1
Sale
attributes
date
time
Store
address
name
0..1
1
1
Houses
Paid-by
1
Payment
amount
1..*
Register
Captured-on 4
1
DOMAIN MODEL - A VISUAL
DICTIONARY OF ABSTRACTIONS


Note that the diagram in the previous slide
depicts an abstraction of the conceptual
classes; details which are uninteresting to the
modellers are ignored in the diagram.
The visual makes it easy to comprehend the
discrete elements and their relationships.
Thus, the domain model may be considered
a visual dictionary of abstractions of the
domain.
DOMAIN MODELS DO NOT
SHOW SOFTWARE COMPONENTS


A domain model is a visualization of things in the
real-world domain of interest, not of software
classes.
The following elements are not suitable in a
domain model:
POSApplet

software artifacts

responsibilities or methods
Sale
date
print()
IDENTIFYING CONCEPTUAL
CLASSES



In iterative development, a domain model is
incrementally built over several iterations in
the elaboration phase.
In each iteration, the domain model is limited
to the prior and current scenarios under
consideration.
It is okay to miss conceptual classes during
the initial identification step. The domain
model can be updated when they are
discovered later (e.g. during design work).
STRATEGIES FOR IDENTIFYING
CONCEPTUAL CLASSES

The following techniques can be used:
 use a conceptual class category list
 identify noun phrases


Identify nouns and noun phrases in textual
descriptions of a domain, and consider them as
candidate classes or attributes.
Weakness: natural language is imprecise

E.g. different noun phrases may represent the
same conceptual class or attribute.

use analysis patterns
 Analysis patterns are existing partial
domain models created by experts
CASE STUDY: PROCESS SALE

Based on a simplified scenario of Process
Sale, the following candidate conceptual
classes are identified using the first two
techniques above:
Register
Item
Store
Sale
Payment
ProductCatalog
ProductSpecification
SalesLineItem
Cashier
Customer
Manager
REPORT OBJECTS

Should "receipt" be included in the domain
model?

One reason to exclude it:


A receipt is a report of a sale. In general, it is not useful
to include conceptual classes that reports information
that can be derived from other sources.
One reason to include it:

A receipt has a special role in the domain. A customer
needs a receipt in order to return bought items.
BUILDING A DOMAIN MODEL

Apply the following steps:
1. Identify candidate conceptual classes related to
the current requirements (use case) under
consideration.
2. Represent those classes in a domain model.
3. Add associations necessary to record
relationships for which there is a need to
preserve some memory.
4. Add attributes necessary to fulfill the information
requirements.
SOME GUIDELINES

Use the vocabulary of the domain when
naming conceptual classes and attributes.


For example, in the library domain, the term
"Borrower" or "Patron" is used rather than
"Customer"
You should not include conceptual classes in
the problem domain not pertinent to the
requirements.

For the case study, "Pen" and "PlasticBag" should
not be included.

You should not include things not in the
problem domain.

For example, "Flight" does not exist in the library
domain.
ATTRIBUTE OR CONCEPTUAL
CLASS?

A common mistake when building a domain
model is to represent something as an atribute
when it should have been a conceptual class.
Represent "store"
as an attribute
OR
Represent "store"
as a conceptual
class

Use the following rule of thumb:
If we do not think of some conceptual
class X as a number or text in the real
world, then X is probably a conceptual
class and not an attribute.

Another example,
OR
SPECIFICATION OR DESCRIPTION
CONCEPTUAL CLASSES

Consider our case study. Let's assume that:




An "Item" represents a physical item in a store.
An "Item" has a description, price and itemID,
which are not recorded elsewhere.
Everyone working in the store has amnesia.
Every time a real physical item is sold, a
corresponding software object "Item" is deleted
from the computer memory.
“Rice Brand
X” Brand
“Rice
X”RM0.60
11234
RM11.00
U110-134
“Rice Brand
X” Brand
“Rice
X”RM0.60
11234
RM11.00
U110-134
“Rice Brand
X” Brand
“Rice
X”RM0.60
11234
RM11.00
U110-134

Problems:



Information about the price of a "Rice Brand X"
product is lost if the shop is sold out of "Rice
Brand X" products.
Space inefficiency as the price and itemID of
"Rice Brand X" are duplicated for every "Item"
instance of the same product.
This illustrates the need for conceptual
classes that are specifications or descriptions
of other things.

Example:

Add a specification or description conceptual
class 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 results
in a loss of information that needs to be
maintained.
It reduces redundant or duplicated information.

Another example:
Flight
date
number
time
Flight
date
time
Flies-to
*
1
Airport
name
Described-by
*
1
FlightDescription
number
*
Describes-flights-to
1
Airport
name
CASE STUDY: INITIAL DOMAIN
MODEL

Based on the candidate conceptual classes
identified previously, an initial domain model
can be produced as follows:
Register
Store
SalesLineItem
Payment
Cashier
ProductCatalog
Item
Sale
Customer
Manager
ProductSpecification
ASSOCIATIONS

An association is a relationship between classes
that indicates some meaningful and interesting
connection.
Records-current
Register
1
Sale
1
THE UML ASSOCIATION
NOTATION
reading direction arrow
- no special meaning, it's just to aid reading
"Cashier initiates Sale"
Initiates
Sale
*
Cashier
1
multiplicity expressions
associations in domain models are
inherently bidirectional
CRITERIA FOR USEFUL
ASSOCIATIONS

We need to be selective when adding
associations to a domain model.


There can be n*(n-1) possible associations in a
domain model with n different conceptual classes.
Too many associations in a domain model can
make it difficult to understand which defeats its
purpose as a communication tool.


Associations worth adding to a domain model are
usually those for which knowledge of the
relationship needs to be preserved for some
duration (even for a millisecond).
For example,
Contains
Sale
SalesLineItem
1
1..*
The SalesLineItem objects associated with a Sale
object need to be remembered; otherwise, it would
not be possible to print a receipt, for instance.

Also, include associations as suggested by the
requirements (use cases).
Sale
Manager
*
1
FINDING ASSOCIATIONS

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-know" associations).
Associations derived from the Common
Associations List.

Give priority to these categories
 A is a physical or logical part of B
 A is physically or logically contained in/on B
 A is recorded in B
USEFUL GUIDELINES




Focus on "need-to-know" associations.
It is more important to identify conceptual
classes than to identify associations.
Too many associations tend to confuse a
domain model.
Avoid showing redundant or derivable
associations.

Example:
Contains
Sale
SalesLineItem
1
1..*
0..1
0..1
Records-Sale-Of
1..*
Involves
Item
1..*
DERIVABLE
MULTIPLICITY

Multiplicity defines how many instances of a
class A can be associated with one instance of
a class B.
Stocks
Store
Item
1
*
association multiplicity
*
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 that the multiplicity value is dependent on our
interest as a modeler and software developer.
Consider the following possibilities:
Married-to
Married-to
husband
husband
husband 1
1
Person wife
1
Married-to
Person wife
1..4
1
Person wife
1..*
NAMING ASSOCIATIONS

The name of an association should be a verb or
a verb phrase. Ensure that it creates a
sequence that is readable and meaningful in the
model context. By convention, the default
direction is left to right or top to bottom.
"Airline Employs Person"
Airline
Employs
Person
Supervises
Assigned-to
Flight
Assigned-to
Plane
"Plane Assigned-to Flight"
MULTIPLE ASSOCIATIONS
BETWEEN TWO CLASSES

It is not uncommon to have multiple
associations between two conceptual classes.
Consider the following:
*
Flies-to
1
Flight
Airport
*
Flies-from
1
Both associations need to be shown separately
as they indicate distinctly different relationships.
ASSOCIATIONS AND
IMPLEMENTATIONS


Associations in a domain model represent
relationships that are meaningful in the real
world.
Not all associations in a domain model need
to be implemented in software.
DOMAIN MODEL FOR POS
SYSTEM (WITH ASSOCIATIONS)
Records-sale-of
Product
Specification
Product
Catalog
Contains
1
-
0..1
Sales
LineItem
1..*
1
1
Used-by
*
*
Store
Item
Stocks
1
1
*
1..*
1..*
Contained-in
1
Logscompleted
1
*
Sale
Houses
1..*
Register
Captured-on
0..1
1
Paid-by
1
Payment
1
1
Is-for
1
Customer
1
Describes
3 Works-on
1
Cashier
ADDING ATTRIBUTES

Besides associations, we also need to
identify attributes of conceptual classes that
are needed to satisfy the information
requirements of the current scenarios under
development.
ATTRIBUTE


An attribute is a logical data value of an
object.
A domain model should include attributes for
which the requirements (such as use cases)
suggest or imply a need to remember
information.
For example, a receipt normally includes the date
and time of sale.
NOTATION FOR ATTRIBUTES
attributes

The type of an attribute is optional.
GUIDELINES FOR IDENTIFYING
ATTRIBUTES

The attributes in a domain model should
preferably be simple attributes or data types.
Examples of attribute types:

Boolean, Date, Number, String (Text), Time

Address, Colour, PhoneNumber,
SocialSecurityNumber, UniversalProductCode,
Postcode

Consider the following:
This is not a "simple"
attribute
Cashier
name
currentRegister
Cashier
name
1
1
Works-on
Register
number

Relate conceptual classes with an association,
not with an attribute.
destination is a
complex concept
Flies-to
Flight
*
Airport
1
ATTRIBUTES AS FOREIGN KEYS

Do not use attributes as foreign keys to relate
conceptual classes (as typically done in relational
database designs).

Use associations to relate those classes.
DOMAIN MODEL FOR POS
SYSTEM
Records-sale-of
Product
Specification
Product
Catalog
Contains
1
-
0..1
Sales
LineItem
1..*
1
itemID
description
price
1
Used-by
*
*
Store
quantity
1
Item
Stocks
name
address
1
*
1..*
1..*
Contained-in
1
*
Sale
1
Payment
amountTendered
1
1
Houses
1..*
Register
Captured-on
0..1
1
dateTime
total
Paid-by
1
Logscompleted
Is-for
number
1
3 Works-on
1
Customer
Describes
1
Cashier
number