1. Harsh Jegadeesan’s CLASSROOM
DOMAIN MODELING
BITS Pilani
Off-Campus Work-Integrated Learning Programmes

4. AGENDA
Visualization
Adding Association
Adding Attributes

5. SETTING DIRECTION
Now that we are starting to look at diagrams, I
want to emphasize that this is a class on analysis
and design, not diagramming. While it may look
good on your resume that you can use UML, your
career depends on being able to translate ideas
into good systems.
That is much more difficult.
All the best!

6. DOMAIN MODEL RELATIONSHIPS
Business Model
Domain Model
Classes, attributes, Elaboration on some terms
associations
Domain Glossary
Use Case Model objects
Requirements
Interaction Diagrams
Design

7. WHAT IS A DOMAIN MODEL ?
A domain model:
Illustrates meaningful conceptual classes in a problem
domain.
Is a representation of real-world concepts, not software
components.
Is NOT a set of diagrams describing software classes, or
software objects and their responsibilities.

8. A DOMAIN MODEL IS THE MOST IMPORTANT OO
ARTIFACT
Its development entails identifying a rich set of
conceptual classes, and is at the heart of object
oriented analysis.
It is a visual representation of the decomposition of a
domain into individual conceptual classes or objects.
It is a visual dictionary of noteworthy abstractions.

9. DOMAIN MODEL UML NOTATION
Illustrated using a set of class diagrams for which no
operations are defined.
It may contain:
Domain Objects or Conceptual Classes
Associations between conceptual classes
Attributes of conceptual classes

10. AD M S
ARTIFACT
A Conceptual class: Software Artifacts:
Sale SalesDatabase
Date
vs.
Time Sale
Date
Time
Print()

11. THINK OF CONCEPTUAL CLASSES IN TERMS OF:
Symbols – words or images
Intensions – its definition
Extensions – the set of examples to which it applies
Symbols and Intensions are the practical
considerations when creating a domain model.

12. DECOMPOSITION:
A central distinction between Object-oriented analysis
and structured analysis is the division by objects
rather than by functions during decomposition.
During each iteration, only objects in current scenarios
are considered for addition to the domain model.

13. CONCEPTUAL CLASS IDENTIFICATION:
It is better to over-specify a domain with lots of fine-
grained conceptual classes than it is to under-specify
it.
Discover classes up front rather than later.
Unlike data modeling, it is valid to include concepts for
which there are no attributes, or which have a purely
behavioral role rather than an informational role.

14. IDENTIFY CONCEPTUAL CLASSES BY CATEGORY
LIST:
Common Candidates for classes include:
Tangible objects, Descriptions, Roles,
Places, Transactions, Containers,
Systems, Abstract nouns, Rules,
Organizations, Events, Processes,
Written Materials, Catalogs, Records,
Financial Instruments and Services

15. IDENTIFY CONCEPTUAL CLASSES BY NOUN
PHRASE:
Identify Nouns and Noun Phrases in textual
descriptions of the domain.
Fully dressed Use Cases are good for this type of
linguistic analysis.
It’s not strictly a mechanical process:
Words may be ambiguous
Different phrases may represent the same concepts.

16. SALES DOMAIN EXAMPLE –
‘PURCHASE ITEMS’ USE CASE
We find concepts such as Register, Sale, Item,
Customer, Receipt etc. in this use case.
Should we include Receipt in the Model?
Con: As a report of a sale, it’s duplicate info.
Pro: Business Rules for a Return require that
the customer has a receipt.
Suggestion: Include it in the iteration where
the Return Use Case is covered.

17. STEPS TO CREATE A DOMAIN MODEL
Identify Candidate Conceptual classes
Draw them in a Domain Model
Add associations necessary to record the relationships
that must be retained
Add attributes necessary for information to be
preserved
Apply existing Analysis Patterns

18. APPLY THE MAPMAKER STRATEGY
Use existing names for things, the vocabulary of the
domain
Exclude irrelevant features
Do not add things that are not there

19. A COMMON MISTAKE - CLASSES AS ATTRIBUTES
Rule: If we do not think of a thing as a number or text
in the real world, then it is probably a conceptual
class.
If it takes up space, then it is likely a conceptual
class.
Examples:
A Store is not an attribute of a Sale
A Destination is not an attribute of a flight

20. SPECIFICATION OR DESCRIPTION
CONCEPTUAL CLASSES
A Class that records information about an item.
Even if all Instances of the item are sold out, the
description remains.
Avoids duplication of recording the descriptive
information with each instance of the item.

21. DESCRIPTION OF A SERVICE EXAMPLE (FLIGHT)
Flight
Date Flies-to Airport
Time Name
Number vs.
Flight FlightDesc Airport
Described Describes
Date -by
Date -flights-to Name
Time Time

22. MONOPOLY CONCEPTS (CANDIDATES)
Monopoly Game Player Piece
Die Board Square

23. AGENDA
Visualization
Adding Association
Adding Attributes

24. OBJECTIVES
Identify associations for a domain model.
Distinguish between need-to-know and
comprehension-only associations.

25. INTRODUCTION
Identify associations of conceptual classes needed to
satisfy the information requirements of current
scenarios.
Also identify the aid in comprehending the domain
model.

26. ASSOCIATIONS
An association is a relationship between instances of
types that indicates some meaningful and interesting
connection

27. ASSOCIATIONS
association
Records-current
Register Sale
1 1

28. USEFUL ASSOCIATIONS
Associations for which knowledge of the relationship
needs to be preserved for some duration.
Associations derived from the Common Associations
List.

29. UML ASSOCIATION NOTATION
An association is represented as a line between classes
with an association name.
Associations are inherently bidirectional.
Optional reading direction arrow is only an aid to the
reader of the diagram.

30. UML ASSOCIATION NOTATION
- “ re a d in g d ire c tio n a rro w ”
- it h a s n o m e a n in g e x c e p t to
in d ic a te d ire c tio n o f re a d in g th e
a s so c ia tio n la b e l
- o fte n e x c lu d e d
R e c o rd s-c u rre n t
R e g is te r S a le
1 1
a s so c ia tio n n a m e m u ltip lic ity

31. FINDING ASSOCIATIONS
-COMMON ASSOCIATIONS LIST
The common categories that are worth considering are:
A is a physical part of B . Eg: Wing-Airplane
A is a logical part of B. Eg: SalesLineItem-Sale.
A is physically contained in B . Eg: Register- Store.

32. COMMON ASSOCIATIONS LIST 2
A is logically contained in B. Eg:ItemDescription-
Catalog.
A is a description of B.Eg:ItemDescription-Item.
A is a line item of a transaction or report
B.Eg:SalesLineItem-Sale.
A is a member of B .Eg: Cashier-Store.
A uses or manages B.Eg:Cashier-Register.

33. COMMON ASSOCIATIONS LIST 3
A is known/logged/recorded/reported/captured in B.Eg:
Sale-Register.
A is an organizational subunit of B .
Eg:Department-Store.
A communicates with B. Eg:Customer-Cashier.
A is next to B. Eg:City-City.

34. COMMON ASSOCIATIONS LIST 4
A is related to a transaction B. Eg: Customer-
Payment.
A is a transaction related to another transaction B.
Eg:Payment-Sale.
A is next to B. Eg:City-City.
A is owned by B. Eg:Register-Store.
A is an event related to B. Eg:Sale-Customer.

35. HIGH-PRIORITY ASSOCIATIONS
A is a physical or logical part of B.
A is physically or logically contained in/on B.
A is recorded in B.

36. ASSOCIATIONS GUIDELINES
The knowledge of the relationship needs to be
preserved for some duration.
Identifying conceptual classes is more important than
identifying associations.
Avoid showing redundant or derivable associations.

37. ROLES
Each end of an association is called a role.
Roles may have
name
multiplicity expression
navigability

38. MULTIPLICITY
Multiplicity defines the number of instances of a class
A ,that can be associated with one instance of class
B,at a particular moment.
Eg: In countries with monogamy laws,a person can be
married to 1 person at any particular time.But over a
span of time one person can be married to many
persons.

39. MULTIPLICITY
Stocks
Store Item
1 *
multiplicity of the
role

40. MULTIPLICITY
*
T zero or more;
“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

41. NAMING ASSOCIATIONS
Name an association based on TypeName-VerbPhrase-
TypeName format.
Names should start with a capital letter.
Legal formats are:
Paid-by
PaidBy

42. ASSOCIATIONS NAMES
Store
1
Contains
1..*
Register Captures Sale Paid-by Payment
1 1..* 1 1
Airline
1
Employs
1..*
Person Assigned-to Flight Assigned-to Plane
1 * * 1
1 *
Supervises

43. MULTIPLE ASSOCIATIONS
Two types may have multiple associations between
them.

44. MULTIPLE ASSOCIATIONS
Flies-to
* 1
Flight Airport
* Flies-from 1

45. IMPLEMENTATION
The domain model can be updated to reflect the newly
discovered associations.
But,avoid updating any documentation or model
unless there is a concrete justification for future use.
Defer design considerations so that extraneous
information is not included and maximizing design
options later on.

46. CLEANING ASSOCIATIONS 1
Do not overwhelm the domain model with associations
that are not strongly required.
Use need-to-know criterion for maintaining
associations.
Deleting associations that are not strictly demanded
on a need-to-know basis can create a model that
misses the point.

47. CLEANING ASSOCIATIONS 2
Add comprehension-only associations to enrich critical
understanding of the domain.

48. A PARTIAL DOMAIN MODEL
Records-sale-of
Described-by
1
Product Product
Catalog Specfication
Contains
1 1..*
1 Describes
Used-by
0..1 * * *
Sales Store Item
LineItem
1 Stocks
1 * 1..*
1..* Logs- 1
completed
Contained-in Houses
1 1..*
Sale * Register Manager
Captured-on Started-by
1 1 1
1
1 1 1
Records-sales-on
Paid-by
1
Initiated-by
Cashier
Initiated-by 1
1 1
Payment Customer

49. CONCLUSION
When in doubt if the concept is required,keep the
concept.
When in doubt if the the association is required,drop
it.
Do not keep derivable association.

50. AGENDA
Visualization
Adding Association
Adding Attributes

51. OBJECTIVES
Learn how to identify and specify attributes in a
domain model
Learn to distinguish attributes correctly

52. ATTRIBUTES
After establishing classes based on the concepts of
use case scenarios, the scenarios are examined to
discover attributes
Attributes are logical data values of an object

53. UML ATTRIBUTE NOTATION

54. VALID ATTRIBUTE TYPES
Keep attributes simple
Distinguish between conceptual and
implementation perspectives
Identify data types

55. RELATE WITH ASSOCIATIONS, NOT
ATTRIBUTES

56. AVOID REPRESENTING COMPLEX
DOMAIN CONCEPTS AS ATTRIBUTES

57. NON PRIMITIVE DATA TYPE (1)
Represent what may be considered a primitive data type
(such as a number or string) as a non primitive class if:
• It is composed of separate sections.
phone number, name of person
• There are operations usually associated with it, such as
parsing or validation.
social security number
• It has other attributes
promotional price could have a start date and end
date

58. NON PRIMITIVE DATA TYPE (2)
• It has a quantity with a unit.
payment amount has a unit of currency
• It has abstraction of one or more types with some of
these qualities.
item identifier in the sales domain is a
generalization of types such as Universal product
code(UPC) or European Article Number(EAN)

59. NON PRIMITIVE DATA TYPE (3)
Applying these guidelines to the POS domain model
yields the following analysis:
• The item identifier is an abstraction of various
common coding codes schemes, including UPC-A,
UPC-E, and the family of EAN schemes. These
numeric coding schemes have subparts identifying
the manufacturer, product and EAN

60. NON PRIMITIVE DATA TYPE (4)
• The price and the amount attribute should be non
primitive Quantity or Money classes because they
are quantities in a unit of currency
• The address attribute should be a non primitive
Address class because it has separate sections

61. IF THE ATTRIBUTE CLASS IS A DATA TYPE,
IT MAY BE SHOWN IN THE ATTRIBUTE BOX

62. NO ATTRIBUTES AS FOREIGN KEY

63. MODELING ATTRIBUTE QUANTITIES AND UNITS

64. DOMAIN MODEL CONCLUSION
A relatively useful model has been
created for the domain of the POS
application.
A good domain model captures the
essential abstractions and information
required to understand the domain in
context of current requirements, and
aids people in understanding the
domain – its concepts , terminology, and the
relationships.

65. THE END