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