1. Chapter 9 DOMAIN MODELS Objectives
“It’s all very well in practice, but it will never work in theory.” - anonymous management maxim
Objectives
Identify conceptual classes related to the current iteration
Create an initial domain model
Model appropriate attributes and associations
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

2. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

3. A Domain Model is the most important model in OO analysis.
It introduces noteworthy concepts in a domain.
It can act as a source of inspiration for designing some software objects and will be input to several artifacts explored in the case studies.
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.
Note: A domain model is optional in UP.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

4. Domain Model Relationships
Business Model
Classes, attributes, associations
Elaboration on some terms
Use Case Model
Domain
objects
Glossary
Requirements
Interaction Diagrams
Design
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

5. Fig. 9.1 Sample UP artifact influence.
Sample UP Artifact Relationships
Domain Model
Sale 1 1 .. *
Sales
Business
. . .
LineItem
Modeling
date
. . .
. . .
quantity
conceptual classes –
the domain objects ,
elaboration of
Fig. 9.1 Sample UP artifact influence.
terms ,
concepts
attributes ,
and associations
some terms in
attributes ,
associations
that undergo state changes
the domain
model
Use -
Case Model
Process Sale
conceptual
Operation :
enterItem ( … )
Cashier : …
classes in 1 .
Customer arrives
Item ID : …
Post -
conditions :
the
...
domain
Require -
... -
. . . 2
. ...
inspire the
ments 3 .
Cashier enters
names of
Operation Contracts
Glossary
item identifier .
some 4
....
software
classes in
Use Case Text
the design
Design Model :
Register :
ProductCatalog :
Sale
enterItem (
itemID ,
quantity )
Design
spec =
getProductSpec (
itemID )
addLineItem (
spec ,
quantity )
. . .
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

6. A Domain Model is not a Software Artifact
A domain model is illustrated in UML using a set of
class diagrams for which no operations are defined.
SalesDatabase
Sale
Date
Time
vs.
Sale
Date
Time
Print()
A Conceptual class
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

7. Example: Fig 9.2 Partial domain model – a visual dictionary
A domain model may contain:
Domain Objects or Conceptual Classes
Associations between conceptual classes
Attributes of conceptual classes
No operations!
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

8. Fig. 9.4 A domain model does not show software artifacts or classes.
Fig. 9.3 A domain model shows real-situation conceptual classes, not software classes.
Fig. 9.4 A domain model does not show software artifacts or classes.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

9. Think of Conceptual Classes in terms of:
Fig. 9.5
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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

10. Fig. 9.6 Lower representational gap with OO modeling
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

11. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

12. Conceptual Class Identification:
It is better to overspecify a domain with lots of fine-grained conceptual classes than it is to underspecify 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

13. a. 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
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

14. b. 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.
Note that, it’s not strictly a mechanical process:
Words may be ambiguous
Different phrases may represent the same concepts.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

15. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

16. Fig. 9.7 Initial POS domain model
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

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
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

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
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

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.
Flight
Date
Time
Number
Flies-to
Airport
Name
vs.
Flight
Date
Time
FlightDesc
Date
Time
Airport
Name
Describes
-flights-to
Described-by
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

20. Fig. 9. 9 Descriptions about other things. The
Fig. 9.9 Descriptions about other things. The * means a multiplicity of “many.”
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

21. 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.
Fig Descriptions about other things.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

22. Monopoly Concepts (candidates)
Monopoly Game
Player
Piece
Square
Die
Board
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

23. UML Notation: Multiple Perspectives
UML describes raw diagram types, such as class diagrams. It does not impose a specific method or process.
UP, the Unified Process, applies raw UML to defined methodology models.
Remember, UML can be used for 3 different perspectives:
Essential – describe the real world
Specifications – software abstractions, such as components and their interfaces
Implementation – specific language (Java)
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

24. Introduction
Identify associations of conceptual classes needed to satisfy the information requirements of current scenarios.
Also identify the aid in comprehending the domain model.
Fig 9.11 Associations
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

25. Useful Associations
Associations for which knowledge of the relationship needs to be preserved for some duration.
Associations derived from the Common Associations List.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

26. Fig.9.12 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

27. Fig. 9.13 Multiplicity on an association.
Fig.9.14 Multiplicity values
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

28. Fig.9.15 Multiplicity is context dependent.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

29. 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.
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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

30. Common Associations List 2
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.
A is related to a transaction B. Eg: Customer-Payment.
A is a transaction related to another transaction B. Eg:Payment-Sale.
A is owned by B. Eg:Register-Store.
A is an event related to B. Eg:Sale-Customer.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

31. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

32. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

33. Roles Each end of an association is called a role. Roles may have name
multiplicity expression
navigability
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

34. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

35. Naming Associations
Name an association based on TypeName-VerbPhrase-TypeName format.
Names should start with a capital letter.
Legal formats are:
Paid-by
PaidBy
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

36. Associations Names Fig 5.Association names. Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

37. Multiple Associations
Two types may have multiple associations between them.
Fig. 9.16
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

38. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

39. Cleaning Associations
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.
Add comprehension-only associations to enrich critical understanding of the domain.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

40. Fig.9.17 NextGen POS partial domain model
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

41. Without need-to-know associations
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

42. Fig. 9.18 Monopoly partial domain model
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

43. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

44. 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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

45. UML Attribute Notation
Keep attributes simple
Distinguish between conceptual and implementation perspectives
Identify data types
Fig Class and attributes
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

46. visibility name: type multiplicity = default {property-string}
Fig Attribute notation in UML. Relate with associations, not attributes
visibility name: type multiplicity = default {property-string}
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

47. Fig.9.21 Recording the quantity of items sold in a line item.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

48. Non Primitive Data Type
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
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)
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

49. Non primitive Data Types
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
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
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

50. Fig.9.24 Two ways to indicate a data type property of an object.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

51. Fig.9.22 Relate with associations, not attributes.
Fig.9.23 Don’t show complex concepts as attributes; use associations.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

52. Fig.9.25 Do not use attributes as foreign keys
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

53. Fig.9.26 Modeling quantities
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

54. Fig.9.27 NextGen POS partial domain model
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

55. Fig.9.28 Monopoly partial domain model
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005

56. Domain Model Conclusion
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.
Dr. Kivanc Dincer
CS319 Week 4 - Oct.3,2005