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
Classes, attributes, Elaboration on some terms
Use Case Model objects
7. WHAT IS A DOMAIN MODEL ?
A domain model:
Illustrates meaningful conceptual classes in a problem
Is a representation of real-world concepts, not software
Is NOT a set of diagrams describing software classes, or
software objects and their responsibilities.
8. A DOMAIN MODEL IS THE MOST IMPORTANT OO
Its development entails identifying a rich set of
conceptual classes, and is at the heart of object
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
A Conceptual class: Software Artifacts:
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.
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
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
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
Identify Nouns and Noun Phrases in textual
descriptions of the domain.
Fully dressed Use Cases are good for this type of
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
Apply existing Analysis Patterns
18. APPLY THE MAPMAKER STRATEGY
Use existing names for things, the vocabulary of the
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
If it takes up space, then it is likely a conceptual
A Store is not an attribute of a Sale
A Destination is not an attribute of a flight
20. SPECIFICATION OR DESCRIPTION
A Class that records information about an item.
Even if all Instances of the item are sold out, the
Avoids duplication of recording the descriptive
information with each instance of the item.
21. DESCRIPTION OF A SERVICE EXAMPLE (FLIGHT)
Date Flies-to Airport
Flight FlightDesc Airport
Date -flights-to Name
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
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-
A is a description of B.Eg:ItemDescription-Item.
A is a line item of a transaction or report
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:
A is an organizational subunit of B .
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-
A is a transaction related to another transaction B.
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
Avoid showing redundant or derivable associations.
Each end of an association is called a role.
Roles may have
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
The domain model can be updated to reflect the newly
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
Deleting associations that are not strictly demanded
on a need-to-know basis can create a model that
misses the point.
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
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
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
64. DOMAIN MODEL CONCLUSION
A relatively useful model has been
created for the domain of the POS
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