DOMAIN MODELING Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s CLASSROOM BITS Pilani Off-Campus Work-Integrated Learning Programmes
DOMAINMODELING
Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s CLASSROOM
BITS PilaniOff-Campus Work-Integrated Learning Programmes
AGENDA
� Visualization
� Adding Association
� Adding Attributes
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 career depends on being able to translate ideas
into good systems.
That is much more difficult.
All the best!
DOMAIN MODEL RELATIONSHIPS
Domain ModelBusiness Model
Classes, attributes,
associationsElaboration on some terms
Use Case Model
Interaction Diagrams
Glossary
Design
Requirements
Domain
objects
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 � 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.
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.� It is a visual dictionary of noteworthy abstractions.
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 � Attributes of conceptual classes
A D M S
ARTIFACT
A Conceptual class:
Sale
Date
Time
SalesDatabase
Sale
Software Artifacts:
vs.Time Sale
Date
Time
Print()
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.
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.are considered for addition to the domain model.
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 which there are no attributes, or which have a purely
behavioral role rather than an informational role.
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
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:It’s not strictly a mechanical process:
� Words may be ambiguous
� Different phrases may represent the same concepts.
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.
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
preservedpreserved
� Apply existing Analysis Patterns
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
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:Examples:
� A Store is not an attribute of a Sale
� A Destination is not an attribute of a flight
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.information with each instance of the item.
DESCRIPTION OF A SERVICE EXAMPLE (FLIGHT)
Airport
Name
vs.
Flight
Date
Time
Number
Flies-to
Number
Flight
Date
Time
FlightDesc
Date
Time
Airport
NameDescribed
-by
Describes
-flights-to
MONOPOLY CONCEPTS (CANDIDATES)
Monopoly Game Player Piece
Die Board Square
AGENDA
� Visualization
� Adding Association
� Adding Attributes
OBJECTIVES
� Identify associations for a domain model.
� Distinguish between need-to-know and
comprehension-only associations.
INTRODUCTION
� Identify associations of conceptual classes needed to
satisfy the information requirements of current
scenarios.
� Also identify the aid in comprehending the domain
model.model.
ASSOCIATIONS
An association is a relationship between instances of
types that indicates some meaningful and interesting
connection
ASSOCIATIONS
association
Register
Sale Records-current
1 1
USEFUL ASSOCIATIONS
� Associations for which knowledge of the relationship
needs to be preserved for some duration.
� Associations derived from the Common Associations
List.
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.reader of the diagram.
UML ASSOCIATION NOTATION
- “read ing d irec tio n a rrow ”
- it h a s no m ean ing excep t to
ind ic a te d irec tio n o f read ing the
asso c ia tio n lab e l
- o ften exc lud ed
R eg is te r
S a le R eco rd s-cu rren t
1 11 1
m ultip lic ity
a sso c ia tio n nam e
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.
Eg: Register- Store.� A is physically contained in B . Eg: Register- Store.
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 � 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.
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.
Eg:City-City� A is next to B. Eg:City-City.
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.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.
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.
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.
ROLES
� Each end of an association is called a role.
� Roles may have
� name
� multiplicity expression� multiplicity expression
� navigability
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 � 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.
MULTIPLICITY
Store
Item Stocks
1 *
multiplicity of the
role
MULTIPLICITY
T
*
zero or more;
“many”
T
1..*
one or more;
T
1..40
one to 40
T
5
exactly 5
T
3,5,8
exactly 3,5 or 8
NAMING ASSOCIATIONS
� Name an association based on TypeName-VerbPhrase-
TypeName format.
� Names should start with a capital letter.
� Legal formats are:� Legal formats are:
� Paid-by
� PaidBy
ASSOCIATIONS NAMES
Paid-by Captures
1..* 11
Contains
1..*
1
Store
Register Sale Payment
1
Supervises
*
Assigned-to Assigned-to
* *1
Employs
1..*
1
Airline
Person Flight Plane
11
MULTIPLE ASSOCIATIONS
� Two types may have multiple associations between
them.
MULTIPLE ASSOCIATIONS
1
1
*
*
Flies-from
Flight Airport
Flies-to
Flies-from
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.options later on.
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.misses the point.
CLEANING ASSOCIATIONS 2
� Add comprehension-only associations to enrich critical
understanding of the domain.
A PARTIAL DOMAIN MODEL
Logs-
1
Describes
1..*
1
Records-sale-of
Described-by
*
1..* 1
1
Stocks
* 1
Contains
1..* 1
Product
Catalog
Product
Specfication
Store Item Sales
LineItem
Used-by
* 0..1 *
Initiated-by
Paid-by
Captured-on
Records-sales-on
Logs-
completed
1
1
1
1 1
1 1
1
1
*
1
1..* 1
1 1
Register Manager Sale
Cashier
Customer Payment
Started-by
Houses
1..*
Contained-in
Initiated-by
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.� Do not keep derivable association.
AGENDA
� Visualization
� Adding Association
� Adding Attributes
OBJECTIVES
� Learn how to identify and specify attributes in a
domain model
� Learn to distinguish attributes correctly
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
UML ATTRIBUTE NOTATION
VALID ATTRIBUTE TYPES
� Keep attributes simple
� Distinguish between conceptual and
implementation perspectives
Identify data types � Identify data types
RELATE WITH ASSOCIATIONS, NOT
ATTRIBUTES
AVOID REPRESENTING COMPLEX
DOMAIN CONCEPTS AS ATTRIBUTES
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
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)
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
NON PRIMITIVE DATA TYPE (3)
the manufacturer, product and EAN
• 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
NON PRIMITIVE DATA TYPE (4)
IF THE ATTRIBUTE CLASS IS A DATA TYPE,
IT MAY BE SHOWN IN THE ATTRIBUTE BOX
NO ATTRIBUTES AS FOREIGN KEY
MODELING ATTRIBUTE QUANTITIES AND UNITS
DOMAIN MODEL CONCLUSION
�A relatively useful model has been
created for the domain of the POS
application.
�A good domain model captures the �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.
THE END