Business Modeling

1
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

2
Background

• A key component of Business Modeling (Domain
  Analysis) - in addition to Business Use Case
  Model and Business Object Model and other
  artifacts - is creating the Domain Model
• The Domain Model contains Key Abstractions
  (business / technology)
• Is a Visual Model of entities, relationships,
  multiplicities, and more.
• Prior to embarking on gathering requirements and
  capturing them via Use Cases (system use cases,
  that is), we need to understand the key entities
  in the domain business or technology domain.

3
Domain Modeling - an Introduction

• Domain Modeling is the task of discovering
  objects (classes, actually) that represent
  those 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.
• Primarily data attributes of domain entities.
• Similar to ERDs, but not the same.

4
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 them in the domain itself.
• As a Visual Model, they will help in
  understanding the domain.
• Also serve as a Glossary, in that the entities
  will contain attributes and other defining
  qualities.

5
Domain Modeling - continued

• The Domain Model not a class diagram
• Does NOT wholly support requirements analysis
  (ahead).
• Addresses entities in the domain of the
  organization apart from computer applications
  that may use them.
• Domain model contains entities, relationships and
  attributes
• Many entities may well be outside the application
  scope to be developed.
• Domain models are normally not concerned with
  representations of inheritance, polymorphism,
  etc, (as we would be when embarking on
  development of an application.)

6
Domain Modeling - continued

• Later, during requirements analysis, we will be
  developing class diagrams that will contain
  classes taken from the domain model.
• But the class diagrams (for development) will
  represent data that will be stored (persistent
  objects) and manipulated by the application.
• Application real software modules likely
  stored in a database
• Instances (objects) will be loaded from and
  stored back into a database as the application
  runs.

7
Domain Modeling - continued

• Models produced as part of requirements analysis
  (ahead lectures) will contain
• 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.

8
So, what do we do?

• Doing domain modeling is very important.
• But, we dont want to spend too much time and try
  to model everything!!!
• Yet we need to have a good starting point for
  requirements analysis to solve the problem.
• So, our domain modeling approach is to develop an
  initial set of classes.

9
Domain Modeling (cont.)

• ? The domain model can serve as a glossary of
  terms, which is very useful to use case
  developers
• Some approaches specify creation of a domain
  model OR a Glossary.
• The domain model consists of entities groups of
  objects with similar properties, common
  behaviors, common relationships, and common
  semantics.
• Need to develop a static model of the domain by
  finding appropriate entities that represent the
  real key abstractions in the domain.
• This serves to underpin system development later.

10
Domain Modeling (cont.)

• Carefully Review Sources of Domain Knowledge.
  Here are a few
• Interviews
• Questionnaires
• Quarterly Reports
• Mission Statements
• Subject Matter Experts (SMEs)
• Newsletters
• Web pages
• A companys 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.
• What does the organization DO? What is it all
  about?
• (We will do this again later when we undertake
  requirements analysisbut we will use Use Cases
  as the primary input, if we already have a domain
  model / glossary)

11
Developing Domain Classes

• Read sources very closely to capture these
  nouns and noun phrases.
• Verbs and verb phrases become candidate
  operations (methods later)
• Possessive phrases generally indicate that the
  nouns should be attributes rather than objects.
  Try to identify attributes / operations.
• Build associations (and name them) between the
  domain classes
• Add multiplicities carefully
• Dont worry about aggregations and association
  classes and much more unless these relationships
  are clearly evident.
• Model will undergo a refinement later. Try to
  capture all the domain info you can model it
  and verify it. Do in Rose or other suitable tool

12
Generalization Relationships and Associations

• If clear from your info gathering, build
  generalization relationships
• Parents, subclasses. Inheritance of attributes,
  methods, and associations!
• is a relationships.
• Associations are static relationships between
  classes.
• Show dependencies if needed.

13
Associations and Multiplicity

• Label the associations as best you can.
• Try to identify multiplicities, but dont 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.
• Dont stress on relationships that are not
  obvious at this time.

14
Association Classes

• Identify classes that particularly address the
  many-to-many relationships that link classes
• These associations typically have properties
  independent of classes they are linking.
• Most domain models have at least one or two link
  (sometimes called bridge) classes.
• Dont overuse these.

15
Following slide is an example (has a few errors
in it) that you may use as a guide.
16
Domain Model
MEMBER 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_Num
ber
SYSTEM_USER Member_ID System_User_Password System
_User_Title
UNIVERSITY University_ID_Number University_Name U
niversity_Address University_City University_Zip_C
ode
Is an authorized
Belob to
MEMBER_TYPE Member_Type_Number Member_Type_Descri
ption
Is categorized as
manages
FINANCE Financial_ID_Number Financial_Date Member
_ID Financial_Amount Financial_Desc Payment_Type_I
D
places
VENDOR Vendor_Number Vendor_Name Vendor_Address V
endor_City Vendor_State Vendor_Zip_Code Vendor_Pho
ne
SALE_ORDER SO_Order_Number SL_Line_Number SO_Orde
r_Date Member_ID
MEMORABILIA_INVENTORY Item_Number Item_Descriptio
n Cost_To_Member
tracks
PAYMENT_TYPE Payment_Type_ID Payment_Type_Desc
provides
Is generated for
contains
references
REPLENISH_LINE RL_Line_Number Supply_Number RL_Li
ne_Quantity
SUPPLIES Supply_Number Vendor_Number Item_Number
Cost_To_UPE
SALE_LINE SL_Line_Number Item_Number
REPLENISH_ORDER RO_Order_Number RL_Line_Number RO
_Order_Date
Is generated for
identifies
17
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.

18
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.

19
Transition to The Problem
Space!!!

• Area within which your application is to exist!

20
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

21
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
• Basis to answer the ultimate question
• Have we solved the problem?
• Be careful what you write!!!
• Wild inferences can be made.

22
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)

23
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.
• These 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.

24
Scope and Bounds

• Problem Statement (Vision) has scope that is,
  what the developed / enhanced application will
  accommodate.
• Problem Statement, via plain English text,
  actually at a high level, contains the scope.
• This is why the Vision Statement (or Problem
  Statement) should be followed by a list of
  features.
• More coming