Download - Domain Modeling
![Page 1: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/1.jpg)
DOMAINMODELING
Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s Harsh Jegadeesan’s CLASSROOM
BITS PilaniOff-Campus Work-Integrated Learning Programmes
![Page 2: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/2.jpg)
![Page 3: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/3.jpg)
![Page 4: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/4.jpg)
AGENDA
� Visualization
� Adding Association
� Adding Attributes
![Page 5: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/5.jpg)
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!
![Page 6: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/6.jpg)
DOMAIN MODEL RELATIONSHIPS
Domain ModelBusiness Model
Classes, attributes,
associationsElaboration on some terms
Use Case Model
Interaction Diagrams
Glossary
Design
Requirements
Domain
objects
![Page 7: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/7.jpg)
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.
![Page 8: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/8.jpg)
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.
![Page 9: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/9.jpg)
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
![Page 10: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/10.jpg)
A D M S
ARTIFACT
A Conceptual class:
Sale
Date
Time
SalesDatabase
Sale
Software Artifacts:
vs.Time Sale
Date
Time
Print()
![Page 11: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/11.jpg)
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.
![Page 12: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/12.jpg)
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.
![Page 13: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/13.jpg)
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.
![Page 14: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/14.jpg)
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
![Page 15: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/15.jpg)
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.
![Page 16: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/16.jpg)
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.
![Page 17: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/17.jpg)
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
![Page 18: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/18.jpg)
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
![Page 19: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/19.jpg)
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
![Page 20: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/20.jpg)
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.
![Page 21: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/21.jpg)
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
![Page 22: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/22.jpg)
MONOPOLY CONCEPTS (CANDIDATES)
Monopoly Game Player Piece
Die Board Square
![Page 23: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/23.jpg)
AGENDA
� Visualization
� Adding Association
� Adding Attributes
![Page 24: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/24.jpg)
OBJECTIVES
� Identify associations for a domain model.
� Distinguish between need-to-know and
comprehension-only associations.
![Page 25: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/25.jpg)
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.
![Page 26: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/26.jpg)
ASSOCIATIONS
An association is a relationship between instances of
types that indicates some meaningful and interesting
connection
![Page 27: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/27.jpg)
ASSOCIATIONS
association
Register
Sale Records-current
1 1
![Page 28: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/28.jpg)
USEFUL ASSOCIATIONS
� Associations for which knowledge of the relationship
needs to be preserved for some duration.
� Associations derived from the Common Associations
List.
![Page 29: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/29.jpg)
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.
![Page 30: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/30.jpg)
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
![Page 31: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/31.jpg)
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.
![Page 32: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/32.jpg)
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.
![Page 33: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/33.jpg)
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.
![Page 34: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/34.jpg)
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.
![Page 35: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/35.jpg)
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.
![Page 36: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/36.jpg)
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.
![Page 37: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/37.jpg)
ROLES
� Each end of an association is called a role.
� Roles may have
� name
� multiplicity expression� multiplicity expression
� navigability
![Page 38: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/38.jpg)
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.
![Page 39: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/39.jpg)
MULTIPLICITY
Store
Item Stocks
1 *
multiplicity of the
role
![Page 40: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/40.jpg)
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
![Page 41: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/41.jpg)
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
![Page 42: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/42.jpg)
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
![Page 43: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/43.jpg)
MULTIPLE ASSOCIATIONS
� Two types may have multiple associations between
them.
![Page 44: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/44.jpg)
MULTIPLE ASSOCIATIONS
1
1
*
*
Flies-from
Flight Airport
Flies-to
Flies-from
![Page 45: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/45.jpg)
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.
![Page 46: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/46.jpg)
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.
![Page 47: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/47.jpg)
CLEANING ASSOCIATIONS 2
� Add comprehension-only associations to enrich critical
understanding of the domain.
![Page 48: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/48.jpg)
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
![Page 49: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/49.jpg)
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.
![Page 50: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/50.jpg)
AGENDA
� Visualization
� Adding Association
� Adding Attributes
![Page 51: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/51.jpg)
OBJECTIVES
� Learn how to identify and specify attributes in a
domain model
� Learn to distinguish attributes correctly
![Page 52: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/52.jpg)
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
![Page 53: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/53.jpg)
UML ATTRIBUTE NOTATION
![Page 54: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/54.jpg)
VALID ATTRIBUTE TYPES
� Keep attributes simple
� Distinguish between conceptual and
implementation perspectives
Identify data types � Identify data types
![Page 55: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/55.jpg)
RELATE WITH ASSOCIATIONS, NOT
ATTRIBUTES
![Page 56: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/56.jpg)
AVOID REPRESENTING COMPLEX
DOMAIN CONCEPTS AS ATTRIBUTES
![Page 57: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/57.jpg)
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
![Page 58: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/58.jpg)
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)
![Page 59: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/59.jpg)
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
![Page 60: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/60.jpg)
• 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)
![Page 61: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/61.jpg)
IF THE ATTRIBUTE CLASS IS A DATA TYPE,
IT MAY BE SHOWN IN THE ATTRIBUTE BOX
![Page 62: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/62.jpg)
NO ATTRIBUTES AS FOREIGN KEY
![Page 63: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/63.jpg)
MODELING ATTRIBUTE QUANTITIES AND UNITS
![Page 64: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/64.jpg)
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.
![Page 65: Domain Modeling](https://reader034.vdocuments.us/reader034/viewer/2022051109/547c9a96b4795984508b468f/html5/thumbnails/65.jpg)
THE END