Business Modeling Business Modeling Domain Modeling Domain Modeling

(1)

Business Modeling Business Modeling

Domain Modeling Domain Modeling

Source: Use Case Driven Object Modeling with Source: Use Case Driven Object Modeling with

UML – A Practical Approach UML – A Practical Approach

By By

Doug Rosenberg

ISBN: 0-201-43289-7

(2)

Background Background

 A key component of Business Modeling A key component of Business Modeling is creating the Domain Model

is creating the Domain Model

– Contains Key Abstractions present in the Contains Key Abstractions present in the problem domain.

problem domain.

 Prior to embarking on Use Case Prior to embarking on Use Case

Modeling, we need to understand the Modeling, we need to understand the

key entities in the problem space.

(3)

Put our Approach into Perspective Put our Approach into Perspective

 Three schools of thought in the OO community for Three schools of thought in the OO community for developing systems.

developing systems.

 1. Data centered approach 1. Data centered approach

– Derived largely from ER modeling Derived largely from ER modeling – Method includes ERDs, DFDs, STDs. Method includes ERDs, DFDs, STDs.

– Method decomposes a system along data boundaries. Method decomposes a system along data boundaries.

 2. Structural approach 2. Structural approach

– Start with OO programming perspective and work up Start with OO programming perspective and work up – Good for detailed design and coding; not much analysis Good for detailed design and coding; not much analysis

 3. Scenario-based approach – grounded in usage 3. Scenario-based approach – grounded in usage scenarios.

scenarios.

– Decomposed a system along usage boundaries. Decomposed a system along usage boundaries.

 We really combine all of these, but especially We really combine all of these, but especially Jacobson’s Objectory process (

Jacobson’s Objectory process (   RUP) and also RUP) and also OMT (Rumbaugh) for high level static modeling OMT (Rumbaugh) for high level static modeling

(preliminary design), and Booch for detailed static (preliminary design), and Booch for detailed static

and dynamic modeling…

(4)

Fundamental Questions – to Fundamental Questions – to

Always Guide your Activities Always Guide your Activities

 Who are the users of the system (actors) and Who are the users of the system (actors) and what are they trying to do?

what are they trying to do?

 What are the ‘real world’ (problem domain) What are the ‘real world’ (problem domain) objects and associations between them?

objects and associations between them?



That is, what are the key abstractions??? That is, what are the key abstractions???

 What objects are needed for each use case? What objects are needed for each use case?

 How do the objects collaborating within each How do the objects collaborating within each use case interact?

use case interact?

 How will we handle real-time control issues? How will we handle real-time control issues?

(depends on application, of course) (depends on application, of course)

 How are we really going to build this system How are we really going to build this system on a nuts-and-bolts level?

on a nuts-and-bolts level?

(5)

 All successful development efforts All successful development efforts require answers to all these

require answers to all these questions.

questions.

 Keep this in mind at all times. Keep this in mind at all times.

 They are They are all all answered over time and answered over time and in various activities developers

in various activities developers undertake.

undertake.

 Involve business modeling, Involve business modeling,

requirements, analysis, design requirements, analysis, design

(preliminary and detailed design) (preliminary and detailed design)

activities to answer all of these….

(6)

The Main Initial Activities The Main Initial Activities

 Business Modeling –vision, business rules, Business Modeling –vision, business rules, domain model and glossary artifacts are domain model and glossary artifacts are

essential.

 Business Model Business Model

 Business Object Model Business Object Model

 Then, we will need to (soon) Then, we will need to (soon)

– Create a rapid prototype of system Create a rapid prototype of system

– Identify your use cases using use case Identify your use cases using use case diagrams

diagrams

– Organize these into Organize these into packages packages

– Allocate functional requirements Allocate functional requirements to the use to the use cases and domain objects at this stage….

cases and domain objects at this stage….

 Review like Mad. A Milestone. Review like Mad. A Milestone.

(7)

Emphasis on Domain Model Emphasis on Domain Model

 Such an important activity!! Such an important activity!!

 Domain Modeling is the task of discovering Domain Modeling is the task of discovering

‘objects’ (classes really) that represent real world

‘objects’ (classes really) that represent real world things and concepts in the problem domain.

things and concepts in the problem domain.

 We actually work ‘outward’ from data requirements We actually work ‘outward’ from data requirements to build a ‘static model’ of the problem domain

to build a ‘static model’ of the problem domain relative to the proposed system.

relative to the proposed system.

– Note: this static model is a first cut! Note: this static model is a first cut!

– There is much we will not know – but will later…. There is much we will not know – but will later….

– Dynamic modeling later will drive the static model. Dynamic modeling later will drive the static model.

   The Domain Model serves as a glossary of terms The Domain Model serves as a glossary of terms (sometimes documented separately) for use by

(sometimes documented separately) for use by developers of the use cases.

developers of the use cases.

(8)

Sources of Information for Domain Sources of Information for Domain

Modeling Modeling

 High-level problem statements High-level problem statements

 Lower level requirements Lower level requirements

 Expert knowledge of problem space Expert knowledge of problem space

 Others discussed Others discussed

– Interviews Interviews

– Questionnaires Questionnaires – Web pages Web pages

– Quarterly reports….. Quarterly reports…..

(9)

Procedure for Discovery Procedure for Discovery

 Go through written material (requesting Go through written material (requesting clarification when necessary)

clarification when necessary)

 Circle nouns / noun phrases Circle nouns / noun phrases

   domain objects.. Nouns and noun phrases tend domain objects.. Nouns and noun phrases tend to become objects and attributes.

to become objects and attributes.

– Eliminate unnecessary ones, too vague, things out Eliminate unnecessary ones, too vague, things out of scope, ….

of scope, ….

– ‘ ‘ Bold’ these items in appropriate documents or Bold’ these items in appropriate documents or create a separate

create a separate candidate class list. candidate class list.

– May be too large; after pairing, may be too small. 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 No more than one-hour max…. Will be refined later in creating analysis model – static.

later in creating analysis model – static.

(10)

Generalization Relationships and Generalization Relationships and

Associations Associations

 Build generalization relationships Build generalization relationships

– Parents, subclasses…. Inheritance of attributes, Parents, subclasses…. Inheritance of attributes, methods, and associations!

methods, and associations!

– ‘ ‘ is a’ relationships…. is a’ relationships….

 Associations are static relationships Associations are static relationships between classes.

between classes.

– Show Show dependencies dependencies but not actions or but not actions or messages.

messages.

– (actions best shown by operations and (actions best shown by operations and messages – later)

messages – later)

 Domain Model serves as the foundation of Domain Model serves as the foundation of our static class model!

our static class model! So very essential! So very essential!

(11)

Associations and Multiplicity Associations and Multiplicity

 Label the associations as best you can. Label the associations as best you can.

 Try to identify multiplicities, but don’t Try to identify multiplicities, but don’t spend too much time.

spend too much time.

 Aggregations – identify classes such that Aggregations – identify classes such that one class is ‘made up’ from smaller

one class is ‘made up’ from smaller pieces… ‘has a’ or ‘kind of’.

pieces… ‘has a’ or ‘kind of’.

 Also, there is composition – where one Also, there is composition – where one piece is ‘owned’ by another – later…..

piece is ‘owned’ by another – later…..

 Focus on simple aggregations now. Focus on simple aggregations now.

(12)

Association Classes Association Classes

 Classes that particularly address the Classes that particularly address the many-to-many relationships that

many-to-many relationships that tend to pair classes or link classes.

tend to pair classes or link classes.

 These do have properties These do have properties

independent of classes they are independent of classes they are

linking.

 Most domain models have at least Most domain models have at least one or two link classes.

one or two link classes.

 Don’t overuse these…. Don’t overuse these….

(13)

Relational Databases Relational Databases

 Sometimes relational databases have Sometimes relational databases have tables that are excellent sources of

tables that are excellent sources of domain classes.

domain classes.

– Normally contain too many attributes Normally contain too many attributes that don’t belong in the context of an that don’t belong in the context of an

object model….

– Can factor out a lot of these into Can factor out a lot of these into

groupings and call them ‘helper classes’

that may be linked via aggregations.

(14)

Consolidate Consolidate

 Put all this together…. Put all this together….

 Create your Domain Model. Create your Domain Model.

– Actually at the ‘analysis level’ Actually at the ‘analysis level’

– Problem space Problem space

– No implementation dependencies… No implementation dependencies…

 Iterate and refine. Iterate and refine.

 Build this glossary of terms that will serve Build this glossary of terms that will serve as nouns in your use case text.

as nouns in your use case text.

 Recognize that this is still only a skeleton Recognize that this is still only a skeleton of your object model.

of your object model.

 You will update as you go… You will update as you go…

(15)

10 Top Domain Modeling Errors 10 Top Domain Modeling Errors

 10. Start assigning multiplicities to associations 10. Start assigning multiplicities to associations right off the bat. Make sure that every

right off the bat. Make sure that every association has an explicit multiplicity.

association has an explicit multiplicity.

 9. Do noun and verb analysis so exhaustive that 9. Do noun and verb analysis so exhaustive that you pass out along the way.

you pass out along the way.

 8. Assign operations to classes without exploring 8. Assign operations to classes without exploring use cases and sequence diagrams.

use cases and sequence diagrams.

 7. Optimize your code for reusability before 7. Optimize your code for reusability before making sure you’ve satisfied the users’

making sure you’ve satisfied the users’

requirements.

 6. Debate whether to use aggregation or 6. Debate whether to use aggregation or

composition for each of your part-of associations

(16)

Continuing…

 5. Presume a specific implementation strategy 5. Presume a specific implementation strategy without modeling the problem space.

without modeling the problem space.

 4. use hard-to-understand names for your 4. use hard-to-understand names for your

classes – like cPortMgrIntf – instead of intuitively classes – like cPortMgrIntf – instead of intuitively

obvious ones, such as PortfolioManager.

 3. Jump directly to implementation constructs 3. Jump directly to implementation constructs such as friend relationships and parameterized such as friend relationships and parameterized

classes classes

 2. Create a one-for-one mapping between 2. Create a one-for-one mapping between

domain classes and relational database tables.

 1. Perform “premature patternization,” which 1. Perform “premature patternization,” which involves building cool solutions, from patterns, involves building cool solutions, from patterns,

that have little or no connection to user problems.