Business Modeling Domain Modeling

1
Business ModelingDomain Modeling

• Source Use Case Driven Object Modeling with UML
  A Practical Approach
• By
• Doug Rosenberg
• ISBN 0-201-43289-7

2
Background

• A key component of Business Modeling is creating
  the Domain Model
• Contains Key Abstractions present in the problem
  domain.
• Prior to embarking on Use Case Modeling, we need
  to understand the key entities in the problem
  space.

3
Put our Approach into Perspective

• Three schools of thought in the OO community for
  developing systems.
• 1. Data centered approach
• Derived largely from ER modeling
• Method includes ERDs, DFDs, STDs.
• Method decomposes a system along data boundaries.
• 2. Structural approach
• Start with OO programming perspective and work up
• Good for detailed design and coding not much
  analysis
• 3. Scenario-based approach grounded in usage
  scenarios.
• Decomposed a system along usage boundaries.
• We really combine all of these, but especially
  Jacobsons Objectory process (? RUP) and also OMT
  (Rumbaugh) for high level static modeling
  (preliminary design), and Booch for detailed
  static and dynamic modeling

4
Fundamental Questions to Always Guide your
Activities

• Who are the users of the system (actors) and what
  are they trying to do?
• What are the real world (problem domain)
  objects and associations between them?
• That is, what are the key abstractions???
• What objects are needed for each use case?
• How do the objects collaborating within each use
  case interact?
• How will we handle real-time control issues?
  (depends on application, of course)
• How are we really going to build this system on a
  nuts-and-bolts level?

5

• All successful development efforts require
  answers to all these questions.
• Keep this in mind at all times.
• They are all answered over time and in various
  activities developers undertake.
• Involve business modeling, requirements,
  analysis, design (preliminary and detailed
  design) activities to answer all of these.

6
The Main Initial Activities

• Business Modeling vision, business rules, domain
  model and glossary artifacts are essential.
• Business Model
• Business Object Model
• Then, we will need to (soon)
• Create a rapid prototype of system
• Identify your use cases using use case diagrams
• Organize these into packages
• Allocate functional requirements to the use cases
  and domain objects at this stage.
• Review like Mad. A Milestone.

7
Emphasis on Domain Model

• Such an important activity!!
• Domain Modeling is the task of discovering
  objects (classes really) that represent real
  world things and concepts in the problem domain.
• We actually work outward from data requirements
  to build a static model of the problem domain
  relative to the proposed system.
• Note this static model is a first cut!
• There is much we will not know but will later.
• Dynamic modeling later will drive the static
  model.
• ?The Domain Model serves as a glossary of terms
  (sometimes documented separately) for use by
  developers of the use cases.

8
Sources of Information for Domain Modeling

• High-level problem statements
• Lower level requirements
• Expert knowledge of problem space
• Others discussed
• Interviews
• Questionnaires
• Web pages
• Quarterly reports..

9
Procedure for Discovery

• Go through written material (requesting
  clarification when necessary)
• Circle nouns / noun phrases
• ? domain objects.. Nouns and noun phrases tend to
  become objects and attributes.
• Eliminate unnecessary ones, too vague, things out
  of scope, .
• Bold these items in appropriate documents or
  create a separate candidate class list.
• May be too large after pairing, may be too
  small. Read between lines of source documents.
• No more than one-hour max. Will be refined later
  in creating analysis model static.

10
Generalization Relationships and Associations

• Build generalization relationships
• Parents, subclasses. Inheritance of attributes,
  methods, and associations!
• is a relationships.
• Associations are static relationships between
  classes.
• Show dependencies but not actions or messages.
• (actions best shown by operations and messages
  later)
• Domain Model serves as the foundation of our
  static class model! So very essential!

11
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 kind of.
• Also, there is composition where one piece is
  owned by another later..
• Focus on simple aggregations now.

12
Association Classes

• Classes that particularly address the
  many-to-many relationships that tend to pair
  classes or link classes.
• These do have properties independent of classes
  they are linking.
• Most domain models have at least one or two link
  classes.
• Dont overuse these.

13
Relational Databases

• Sometimes relational databases have tables that
  are excellent sources of domain classes.
• Normally contain too many attributes that dont
  belong in the context of an object model.
• Can factor out a lot of these into groupings and
  call them helper classes that may be linked via
  aggregations.

14
Consolidate

• Put all this together.
• Create your Domain Model.
• Actually at the analysis level
• Problem space
• No implementation dependencies
• Iterate and refine.
• Build this glossary of terms that will serve as
  nouns in your use case text.
• Recognize that this is still only a skeleton of
  your object model.
• You will update as you go

15
10 Top Domain Modeling Errors

• 10. Start assigning multiplicities to
  associations right off the bat. Make sure that
  every association has an explicit multiplicity.
• 9. Do noun and verb analysis so exhaustive that
  you pass out along the way.
• 8. Assign operations to classes without
  exploring use cases and sequence diagrams.
• 7. Optimize your code for reusability before
  making sure youve satisfied the users
  requirements.
• 6. Debate whether to use aggregation or
  composition for each of your part-of associations

16
Continuing

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