Business Modeling Domain Modeling Source Use Case Driven

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

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

Put our Approach into Perspective u Three schools of thought in the OO community for developing systems. 1. Data centered approach u 2. Structural approach u 3. Scenario-based approach – grounded in usage scenarios. u – Derived largely from ER modeling – Method includes ERDs, DFDs, STDs. – Method decomposes a system along data boundaries. – Start with OO programming perspective and work up – Good for detailed design and coding; not much analysis – Decomposed a system along usage boundaries. u 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…

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

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

The Main Initial Activities Business Modeling –vision, business rules, domain model and glossary artifacts are essential. u Business Model u Business Object Model u Then, we will need to (soon) u – 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…. u Review like Mad. A Milestone.

Emphasis on Domain Model u u u 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. – – – u 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.

Sources of Information for Domain Modeling u High-level problem statements u Lower level requirements u Expert knowledge of problem space u Others discussed – Interviews – Questionnaires – Web pages – Quarterly reports…. .

Procedure for Discovery Go through written material (requesting clarification when necessary) u Circle nouns / noun phrases u – 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.

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

Associations and Multiplicity Label the associations as best you can. u Try to identify multiplicities, but don’t spend too much time. u Aggregations – identify classes such that one class is ‘made up’ from smaller pieces… ‘has a’ or ‘kind of’. u Also, there is composition – where one piece is ‘owned’ by another – later…. . u Focus on simple aggregations now. u

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

Relational Databases u 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.

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

10 Top Domain Modeling Errors u u u 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

Continuing… u u u 5. Presume a specific implementation strategy without modeling the problem space. 4. use hard-to-understand names for your classes – like c. Port. Mgr. Intf – instead of intuitively obvious ones, such as Portfolio. Manager. 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.