Business Modeling –
The Domain Model
Source: Use Case Driven Object Modeling with UML – A
Practical Approach
By Doug Rosenberg ISBN: 0-201-43289-7
Also, pp. 101-110 OOSE Text
Modified 10/10/11
Background
 A key component of Business Modeling (Domain Analysis) -
is creating the Domain Model
 The Domain Model contains Key Abstractions (business /
technology)
 Is a Visual Model of entities, relationships, multiplicities, and
more.
Domain Modeling - an Introduction
 Domain Modeling is the task of discovering “business
objects” that represent those business entities and concepts.
  Recognize that the domain model will be a superset of
your entity classes needed for your application development.


Your class diagrams – later on - will likely contain some of
the entities found in your domain model.
Similar to ERDs, but not the same.
 Fully-attributed list (not a schema or physical database design…)
Domain Modeling - continued
 Domain Models sometimes considered ‘informal’ class diagrams.
 Developed as part of domain analysis (business modeling)
 The ‘classes’ (entities) represent what you have learned about
various ‘things’ (entities) and relationships between/among them
in the domain itself.
 As a Visual Model, they will help in understanding the domain.
 Also serves as a Glossary, in that the entities will contain
attributes and other defining qualities.
Domain Modeling - continued
 The Domain Model: not a class diagram
 Does NOT wholly support requirements analysis (ahead).
 Is not INTENDED to…
 Addresses entities are in the domain of the organization – that
may be quite apart from a computer application that may use them.
 Domain models are normally not concerned with
representations of inheritance, polymorphism, … (as we
would be when embarking on development of an application.)
Domain Modeling - continued
 During requirements analysis – we will be developing
class diagrams that will contain entities (classes) taken
from the domain model.
 (Software) class diagrams (for development) will represent
data that will be stored ( often as persistent objects) and
manipulated by the application.


Application deals with real software modules – likely stored in a
database
Instances (objects) will be loaded from and stored back into a
database as the application runs.
Domain Modeling - continued
 Models produced as part of requirements analysis
(ahead lectures) are frequently:



Entity classes - some may be derived from Domain
Model,
Boundary classes - used for the user interface, and
Control Classes used for controlling logic and
business rules, and more.
So, what do we do?
 Domain modeling is very important.
 Don’t spend too much time trying to model everything!!!
 Yet we need to have a good starting point for
requirements analysis to solve the ‘problem.’
 So, do domain modeling to develop an ‘initial’ set of
classes.

We are developing a static model of the domain by finding
appropriate entities that represent the real key abstractions
in the domain.
Developing Entities for Domain Model
 Sources (again) of Domain Knowledge. Here are a few:









Interviews
Questionnaires
Quarterly Reports
Mission Statements
Subject Matter Experts (SMEs)
Newsletters
Web pages
A company’s e-business….
Look for nouns – these are candidate classes in the domain model.
 Examples: Menu, customer, food order, Payment, On-line order…
Customer (class with attributes /behaviors) ‘orders’
(relationship) Food (class with attributes) – captured
graphically.
 Customer and Food are entities related by Orders….

Developing Domain Entities
 Read sources very closely to capture these ‘nouns’ and
noun phrases.
 Possessive phrases generally indicate that the nouns should
be attributes rather than objects. Try to identify attributes /
operations.
 Build associations (& name them) between domain classes
 Add multiplicities carefully
 Don’t worry about aggregations and association classes and
much more unless these relationships are clearly evident.
 Capture domain entities (model) in Rose or other tool.
Generalization Relationships and
Associations
 If clear from your info gathering, build generalization
relationships


Parents, subclasses…. Inheritance of attributes, methods, and
associations! Not a must, but if clear: do it.
‘is a’ relationships….
 Associations are static relationships between classes.
 Show dependencies if needed.
Associations and Multiplicity
 Label the associations as best you can.
 Try to identify multiplicities, but don’t spend too much time.
 Aggregations – identify classes such that one class is
‘made up’ from smaller pieces… ‘has a’ or ‘is a kind of’.
 Also, there is composition – where one piece is ‘owned’
by another – later…..
 Focus on simple aggregations now.
 Don’t stress on relationships that are not obvious
Following slide is an example
(Has a few errors in it) that you may
use as a guide.
See also my web page…
Domain Model
MEMBER
SYSTEM_USER
Is an authorized
Member_ID
System_User_Password
System_User_Title
MEMBER_TYPE
Is categorized
as
Member_Type_Number
Member_Type_Description
Member_ID
Member_Type_Number
Member_First_Name
Member_Middle_Initial
Member_Last_Name
Member_Address
Member_City
Member_State
Member_Zip_Code
Member_Phone_Number
Member_Email
University_ID_Number
UNIVERSITY
Belob to
manages
FINANCE
Financial_ID_Number
Financial_Date
Member_ID
Financial_Amount
Financial_Desc
Payment_Type_ID
places
VENDOR
SALE_ORDER
MEMORABILIA_INVENTORY
SO_Order_Number
SL_Line_Number
SO_Order_Date
Member_ID
Item_Number
Item_Description
Cost_To_Member
University_ID_Number
University_Name
University_Address
University_City
University_Zip_Code
Vendor_Number
Vendor_Name
Vendor_Address
Vendor_City
Vendor_State
Vendor_Zip_Code
Vendor_Phone
tracks
PAYMENT_TYPE
Is generated for
contains
provides
Payment_Type_ID
Payment_Type_Desc
references
SUPPLIES
SALE_LINE
SL_Line_Number
Item_Number
REPLENISH_LINE
Supply_Number
Vendor_Number
Item_Number
Cost_To_UPE
RL_Line_Number
Supply_Number
RL_Line_Quantity
Is generated for
REPLENISH_ORDER
identifies
RO_Order_Number
RL_Line_Number
RO_Order_Date
8 Top Domain Modeling Errors
 8. Start assigning multiplicities to associations right off the bat. Make
sure that every association has an explicit multiplicity.
 7. Do noun and verb analysis so exhaustive that you pass out along the
way.
 6. Debate whether to use aggregation or composition for each of your
part-of associations
 5. Presume a specific implementation strategy without modeling the
problem space.
 4. Use hard-to-understand names for your classes – like cPortMgrIntf –
instead of intuitively obvious ones, such as PortfolioManager.
Continuing…
 3. Jump directly to implementation constructs such
as ‘friend’ relationships and parameterized classes
 2. Create a one-for-one mapping between domain
classes and relational database tables.
 1. Perform “premature patternization,” which involves
building cool solutions, from patterns, that have little
or no connection to user problems.
Transition to:
The Problem Space!!!
 Area within which your application is to exist!
The Problem and the Scope
 The term “problem domain” refers to the area
that encompasses real-world persons, places,
and/or things and concepts related to the
problem that the system to be developed /
enhanced, etc. is being ‘required’ to solve.
 A ‘problem’ may be considered a ‘difficulty’
(inadequacy of current system) or ‘opportunity’
for benefit, or more
Problem Statement (‘Vision’ of the
Application to be Developed)
 The problem statement should be a simple
sentence or two.

Usually then found in a Vision Document
 VERY IMPORTANT; High level…
 Basis to answer the ultimate question:

Have we solved the problem?
 Be careful what you write!!!
 Wild inferences can be made.
Sample Problem Statement
(Student Registration System)
 “The system will allow students to register for
courses, and change their registration, as simply
and rapidly as possible. It will help students
achieve their personal goals of obtaining their
degree in the shortest reasonable time while
taking courses that they find most interesting and
fulfilling.” (p. 107, OOSE)
Scope and Its Bounds
 Broader the scope, the more complex the application.
 Along with the problem statement, include a list of
features to be accommodated.

This will narrow features; Can simply be ‘bulleted’ items
 Scope, hence commitment, is clarified by listing
features or sub-problems.
 Determine that some of these are ‘out of scope’ or will
be accommodated by a different application.

Good to have a comprehensive list citing features that are
explicitly OUT of scope as well as those IN scope.
Scope and Bounds
 Problem Statement (Vision) ‘has’ scope – that is,
what the developed / enhanced application will
accommodate.
 This is why the Vision Statement (or Problem
Statement) should be followed by a list of
‘features.’
 More coming…