1. Business Modeling Domain 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 Jacobson’s 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 don’t 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.  Don’t overuse these….

13. Relational Databases  Sometimes relational databases have tables that are excellent sources of domain classes. –Normally contain too many attributes that don’t 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 you’ve 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.