Domain Modelling
Presented By
Dr. Shazzad Hosain
Domain Models
 A domain model is a visual representation of conceptual classes
or real-world objects in a domain of interest.
 Identifying a rich set of objects or conceptual classes is at the heart
of object-oriented analysis
 In domain model no operations are defined. It may show
 Domain objects or conceptual classes
 Associations between conceptual classes
 Attributes of conceptual classes
Domain Model, a Visual Dictionary of Abstractions
Domain Models are not Models of Software Components
Domain model shows conceptual class, not software class
Domain Models and Decomposition
 In structured analysis the dimension of decomposition is by
processes or functions.
 In OO analysis the division is by conceptual classes or objects.
 Example conceptual classes in the Sale Domain
Conceptual Classes
1. A conceptual class is an idea, thing or object.
2. It may be considered in terms of its symbol, intension and extension
Conceptual Class Identification
 In incremental model iteratively identify classes rather than
identify all classes at the beginning.
 For example, if the iteration is limited to cash-only ProcessSale
scenario, then create domain model only for this one
 It is better to overspecify a domain model with lots of fine-grained
conceptual classes than to underspecify it.
Strategies to Identify Conceptual Classes
 Use a conceptual class category list
 Identify noun phrases, though need some art
Main Success Scenario (or Basic Flow):
1. Customer arrives at the POS checkout with goods and/or
services to purchase
2. Cashier starts a new sale
3. Cashier enters item identifier
4. …………
Conceptual Class Category List
Conceptual Class Category
Examples
Physical or tangible objects
Register, Airplane
Places
Store, Airport
Transactions
Sale, Payment, Reservation
Organizations
SalesDepartment, ObjectAirline
Rules and policies
RefundPolicy, CancellationPolicy
Things in a container
Item, Passenger
……
…….
Table 10.1 Conceptual Class Category List
Candidate Conceptual Classes for the
Sales Domain, an Example
Manager
Register
Cashier
Item
Payment
Store
ProductCatalog
Sale
Customer
ProductSpecification
There is no such thing as a “correct” list. It is somewhat arbitrary
collection of abstractions.
On Naming and Modeling Things:
The Mapmaker
 Make a domain model in the spirit of a cartographer
or mapmaker
 User the existing names in the territory
 Example, use “Borrower” or “Patron” for customer in
library domain
 Exclude irrelevant features
 Pen and PaperBag may be excluded from sales domain
 Do not add things that are not there
A Common Mistake in Identifying
Conceptual Classes
 If we do not think of some conceptual class X as a number or text
in the real world, X is probably a conceptual class, not an
attribute.
 Example: Should Store be an attribute of Sale, or a separate object
 Should destination be an attribute of Flight, or Airport be a
separate object
Resolving Similar Conceptual Classes
 Register vs. POST (point-of-sale terminal)
A domain model is not absolutely correct or wrong, but more or less useful; it is
a tool of communication
Specification or Description
Conceptual Classes
Worse
Better
 Assume that, Item instance represents a physical item in a store;
 An item has a description, price, itemID which are not recorded any-
where else.
 Every time a real physical item is sold, the corresponding Item
instance is deleted from “software land”
Another Specification Example
 Let an airline company suffers a fatal crash of one of its planes
 Consequently cancels all flights for investigation, delete Flight
instances, no longer a record of what flight routes the airline has
Descriptions of Services
 Flight example is about a service rather than a good (such as a
veggieburger item)
 Descriptions of services or service plans are commonly needed
 Another example: A mobile company sells difference packages
such as “bronze”, “gold”, “dijuce”, “nababi call rate” etc.
 So you need a description class separate from an actual sold
package.
Modeling the Unreal World
 Some software system has little analogy in real world e.g. software
for telecommunications.
 Still you can create a domain model.
Message
Connection
Route
Protocol
Port
Dialog
UML Notations, Models and Methods:
Multiple Perspectives
class
Domain concepts / conceptual class
Software / design class
Implementation class
e.g. Java Class
Lowering the Representational Gap
Domain Modeling Guidelines
 List the objects using category list and noun phrase identification
technique
 Draw them in a domain model
 Add associations necessary to record relationships
 Add attributes in necessary
Domain Model: Adding Associations
Associations
 An association is a relationship between types (or more
specifically instances of those types) that indicated some
meaningful and interesting connection.
Criteria for Useful Associations
 Knowledge of a relationship that needs to be preserved for some
duration – may milliseconds or years, depending on context. These
are known as “need-to-know” associations.
 Example: Do we need to remember SalesLineItem instances for
Sale instance.
 Example: Relationship between Sale and Manager?
 If n different objects then n*(n-1) associations. Be parsimonious.
 Associations derived from the Common Association List
UML Association Notation
Finding Associations –
Common Association List
Category
A is a physical part of B
A is a logical part of B
A is a description for B
A is a member of B
A communicates with B
A is owned by B
……..
Examples
Drawer – Register
Wing – Airplane
SalesLineItem – Sale
FlightDescription – Flight
Cashier – Store
Pilot – Airline
Customer – Cashier
Plane – Airline
………….
Table 11.1 Common Association List
Roles
 Each end of an association is called a role. Roles may optionally
have:
 Name (will discuss latter)
 Multiplicity Expression
 Navigability (will discuss latter)
Multiple Associations
 Two types may have multiple associations
Naming Associations
 TypeName –VerbPhrase – TypeName format where the verb phrase creates
a sequence that is readable and meaningful in the model context
 Should start with a capital letter
 Two common and equally legal formats for a compound association
name are:
 Paid-by
 PaidBy
How Detail Should Association Be?
 Finding conceptual classes is more important than finding
association. The majority of time spent in domain model creation
should be devoted to identifying conceptual classes, not
associations.
NextGen
POS Domain
Model
Suggestions
 Focus on need-to-know associations
 Avoid redundant or derivable associations
Domain Model: Adding Attributes
Attributes
 An attribute is a logical data value of an object
 Keep attributes simple
 E.g. Boolean, Date, Number, String, Time
 Other examples are Address, Color, Universal Product Code (UPC) etc.
 Relate conceptual classes with an association, not with an attribute
Examples
Non-primitive Data Type Classes
 Represent as non-primitive class if
 If composed of separate sections
 Phone number, name of person
 There are operations usually associated with it, such as parsing /
validation
 Social security number
 It has other attributes
 Promotional price could have start date and end date
 It is a quantity with a unit
 Payment amount has a unit of currency
 It is an abstraction of one or more types with some of these qualities
 Item identifier may be UPC or EAN (European Article Number)
Where to Illustrate Data Type Classes?
 A domain model is a tool of communication; choices about what is
shown should be made with that consideration in mind.
Design Creep: No Attributes as Foreign Keys
 Relate objects with an association, not with an attribute
Modeling Attribute Quantities and Units
 Most numeric quantities should not be represented as plain
numbers. Consider price or velocity that are associated with units.
Multiplicity From SalesLineItem to Item
 Derived attribute indicated with a “/” symbol
Domain Model
Conclusion
NextGen POS
System Model
References
 Chapter 10, 11, 12 of “Applying UML and Patterns – An
Introduction to Object-Oriented Analysis and Design and the
Unified Process” – by Craig Larman