16
Business Modeling Business Modeling Domain Modeling Domain Modeling Source: Use Case Driven Object Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach with UML – A Practical Approach By By Doug Rosenberg Doug Rosenberg ISBN: 0-201-43289-7 ISBN: 0-201-43289-7

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

Embed Size (px)

Citation preview

Page 1: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Business ModelingBusiness ModelingDomain ModelingDomain Modeling

Source: Use Case Driven Object Modeling with Source: Use Case Driven Object Modeling with UML – A Practical ApproachUML – A Practical Approach

By By Doug RosenbergDoug Rosenberg

ISBN: 0-201-43289-7ISBN: 0-201-43289-7

Page 2: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

BackgroundBackground

A key component of Business Modeling A key component of Business Modeling is creating the Domain Modelis 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.key entities in the problem space.

Page 3: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Put our Approach into PerspectivePut 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 approach1. Data centered approach

– Derived largely from ER modelingDerived 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 approach2. Structural approach– Start with OO programming perspective and work upStart with OO programming perspective and work up– Good for detailed design and coding; not much analysisGood 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…and dynamic modeling…

Page 4: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Fundamental Questions – to Fundamental Questions – to Always Guide your ActivitiesAlways 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?

Page 5: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

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 allall 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….activities to answer all of these….

Page 6: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

The Main Initial ActivitiesThe 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.essential.

Business Model Business Model Business Object ModelBusiness Object Model Then, we will need to (soon)Then, we will need to (soon)

– Create a rapid prototype of systemCreate a rapid prototype of system– Identify your use cases using use case Identify your use cases using use case

diagramsdiagrams– Organize these into Organize these into packagespackages– Allocate functional requirementsAllocate 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.

Page 7: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Emphasis on Domain ModelEmphasis 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.

Page 8: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Sources of Information for Domain Sources of Information for Domain ModelingModeling

High-level problem statementsHigh-level problem statements Lower level requirementsLower level requirements Expert knowledge of problem spaceExpert knowledge of problem space Others discussedOthers discussed

– InterviewsInterviews– QuestionnairesQuestionnaires– Web pagesWeb pages– Quarterly reports…..Quarterly reports…..

Page 9: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Procedure for DiscoveryProcedure for Discovery Go through written material (requesting Go through written material (requesting

clarification when necessary)clarification when necessary) Circle nouns / noun phrasesCircle 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. 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.

Page 10: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Generalization Relationships and Generalization Relationships and AssociationsAssociations

Build generalization relationshipsBuild 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 dependenciesdependencies 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!

Page 11: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Associations and MultiplicityAssociations 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.

Page 12: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Association ClassesAssociation 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.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….

Page 13: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Relational DatabasesRelational 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….object model….

– Can factor out a lot of these into Can factor out a lot of these into groupings and call them ‘helper classes’ groupings and call them ‘helper classes’ that may be linked via aggregations.that may be linked via aggregations.

Page 14: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

ConsolidateConsolidate 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 spaceProblem 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…

Page 15: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

10 Top Domain Modeling Errors10 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.requirements.

6. Debate whether to use aggregation or 6. Debate whether to use aggregation or composition for each of your part-of associationscomposition for each of your part-of associations

Page 16: Business Modeling Domain Modeling Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7

Continuing…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.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 classesclasses

2. Create a one-for-one mapping between 2. Create a one-for-one mapping between domain classes and relational database tables.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.that have little or no connection to user problems.