business modeling – the domain model source: use case driven object modeling with uml – a...
Post on 21-Dec-2015
214 views
TRANSCRIPT
![Page 1: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/1.jpg)
Business Modeling – The Domain Model
Source: Use Case Driven Object Modeling with UML – A Practical ApproachBy Doug Rosenberg ISBN: 0-201-43289-7Also, pp. 101-110 OOSE Text
![Page 2: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/2.jpg)
Background
A key component of Business Modeling (Domain Analysis) - in addition to Business Use Case Model and Business Object Model and other artifacts - is creating the Domain Model
The Domain Model contains Key Abstractions (business / technology) Is a Visual Model of entities, relationships, multiplicities, and more.
Prior to embarking on gathering requirements and capturing them via Use Cases (system use cases, that is…), we need to understand the key entities in the domain – business or technology domain.
![Page 3: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/3.jpg)
Domain Modeling - an Introduction
…
Domain Modeling is the task of discovering “objects” (classes, actually) that represent those entities and concepts.
Recognize that the domain model will be a superset of your entity classes needed for your application development. Your class diagrams – later on - will likely contain some of the
entities found in your domain model. Primarily ‘data’ – attributes of domain entities. Similar to ERDs, but not the same.
![Page 4: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/4.jpg)
Domain Modeling - continued
Domain Models sometimes considered ‘informal’ class diagrams. Developed as part of domain analysis (business modeling)
The ‘classes’ (entities) represent what you have learned about various ‘things’ (entities) and relationships between them in the domain itself.
As a Visual Model, they will help in understanding the domain. Also serve as a Glossary, in that the entities will contain attributes
and other defining qualities.
![Page 5: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/5.jpg)
Domain Modeling - continued
The Domain Model: not a class diagram Does NOT wholly support requirements analysis (ahead). Addresses entities in the domain of the organization – apart from
computer applications that may use them.
Domain model contains entities, relationships and attributes Many entities may well be outside the application scope to be
developed.
Domain models are normally not concerned with representations of inheritance, polymorphism, etc, (as we would be when embarking on development of an application.)
![Page 6: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/6.jpg)
Domain Modeling - continued
Later, during requirements analysis, we will be developing class diagrams that will contain classes taken from the domain model.
But the class diagrams (for development) will represent data that will be stored (persistent objects) and manipulated by the application. Application = real software modules – likely stored in a database Instances (objects) will be loaded from and stored back into a
database as the application runs.
![Page 7: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/7.jpg)
Domain Modeling - continued
Models produced as part of requirements analysis (ahead lectures) will contain: Entity classes - some may be derived from Domain
Model, Boundary classes - used for the user interface, and Control Classes used for controlling logic and
business rules, and more.
![Page 8: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/8.jpg)
So, what do we do?
Doing domain modeling is very important. But, we don’t want to spend too much time and
try to model everything!!! Yet we need to have a good starting point for
requirements analysis to solve the ‘problem.’ So, our domain modeling approach is to
develop an ‘initial’ set of classes.
![Page 9: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/9.jpg)
Domain Modeling (cont.)
The domain model can serve as a glossary of terms, which is very useful to use case developers Some approaches specify creation of a domain model OR a
Glossary.
The domain model consists of entities – groups of objects with similar properties, common behaviors, common relationships, and common semantics.
Need to develop a static model of the domain by finding appropriate entities that represent the real key abstractions in the domain. This serves to underpin system development later.
![Page 10: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/10.jpg)
Domain Modeling (cont.) Carefully Review Sources of Domain Knowledge. Here are a few:
Interviews Questionnaires Quarterly Reports Mission Statements Subject Matter Experts (SMEs) Newsletters Web pages A company’s e-business….
Look for nouns – these are candidate classes in the domain model. Examples: Menu, customer, food order, Payment, On-line order…
Customer (class with attributes /behaviors) ‘orders’ (relationship) Food (class with attributes) – captured graphically.
Customer and Food are entities related by Orders…. What does the organization DO? What is it all about? (We will do this again later when we undertake requirements analysis…but we will use
Use Cases as the primary input, if we already have a domain model / glossary)
![Page 11: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/11.jpg)
Developing Domain Classes Read sources very closely to capture these ‘nouns’ and noun phrases.
Verbs and verb phrases become candidate operations (methods later)
Possessive phrases generally indicate that the nouns should be attributes rather than objects. Try to identify attributes / operations.
Build associations (and name them) between the domain classes Add multiplicities carefully Don’t worry about aggregations and association classes and much more
unless these relationships are clearly evident.
Model will undergo a refinement later. Try to capture all the domain info you can; model it; and verify it. Do in Rose or other suitable tool
![Page 12: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/12.jpg)
Generalization Relationships and Associations
If clear from your info gathering, build generalization relationships Parents, subclasses…. Inheritance of attributes, methods, and
associations! ‘is a’ relationships….
Associations are static relationships between classes.
Show dependencies if needed.
![Page 13: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/13.jpg)
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 ‘is a kind of’. Also, there is composition – where one piece is ‘owned’ by
another – later….. Focus on simple aggregations now. Don’t stress on relationships that are not obvious at this
time.
![Page 14: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/14.jpg)
Association Classes
Identify classes that particularly address the many-to-many relationships that link classes
These ‘associations’ typically have properties independent of classes they are linking.
Most domain models have at least one or two link (sometimes called ‘bridge’) classes.
Don’t overuse these….
![Page 15: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/15.jpg)
Following slide is an example (has a few errors in it) that you may use as a guide.
![Page 16: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/16.jpg)
SYSTEM_USER
Member_IDSystem_User_PasswordSystem_User_Title
MEMBER_TYPE
Member_Type_NumberMember_Type_Description
SALE_ORDER
SO_Order_NumberSL_Line_NumberSO_Order_DateMember_ID
SALE_LINE
SL_Line_NumberItem_Number
MEMBER
Member_IDMember_Type_NumberMember_First_NameMember_Middle_InitialMember_Last_NameMember_AddressMember_CityMember_StateMember_Zip_CodeMember_Phone_NumberMember_EmailUniversity_ID_Number
MEMORABILIA_INVENTORY
Item_NumberItem_DescriptionCost_To_Member
UNIVERSITY
University_ID_NumberUniversity_NameUniversity_AddressUniversity_CityUniversity_Zip_Code
FINANCE
Financial_ID_NumberFinancial_DateMember_IDFinancial_AmountFinancial_DescPayment_Type_ID
PAYMENT_TYPE
Payment_Type_IDPayment_Type_Desc
REPLENISH_ORDER
RO_Order_NumberRL_Line_NumberRO_Order_Date
REPLENISH_LINE
RL_Line_NumberSupply_NumberRL_Line_Quantity
VENDOR
Vendor_NumberVendor_NameVendor_AddressVendor_CityVendor_StateVendor_Zip_CodeVendor_Phone
SUPPLIES
Supply_NumberVendor_NumberItem_NumberCost_To_UPE
Is an authorized
Belob to
Is categorized as
places
manages
Is generated forprovides
Is generated for identifies
tracks
references
contains
Domain Model
![Page 17: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/17.jpg)
8 Top Domain Modeling Errors
8. Start assigning multiplicities to associations right off the bat. Make sure that every association has an explicit multiplicity.
7. Do noun and verb analysis so exhaustive that you pass out along the way.
6. Debate whether to use aggregation or composition for each of your part-of associations
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.
![Page 18: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/18.jpg)
Continuing…
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.
![Page 19: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/19.jpg)
Transition to: The Problem Space!!!
Area within which your application is to exist!
![Page 20: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/20.jpg)
The Problem and the Scope
The term “problem domain” refers to the area that encompasses real-world persons, places, and/or things and concepts related to the problem that the system to be developed / enhanced, etc. is being ‘required’ to solve.
A ‘problem’ may be considered a ‘difficulty’ (inadequacy of current system) or ‘opportunity’ for benefit, or more
![Page 21: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/21.jpg)
Problem Statement (‘Vision’ of the Application to be Developed)
The problem statement should be a simple sentence or two. Usually then found in a Vision Document
VERY IMPORTANT Basis to answer the ultimate question:
Have we solved the problem? Be careful what you write!!! Wild inferences can be made.
![Page 22: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/22.jpg)
Sample Problem Statement(Student Registration System)
“The system will allow students to register for courses, and change their registration, as simply and rapidly as possible. It will help students achieve their personal goals of obtaining their degree in the shortest reasonable time while taking courses that they find most interesting and fulfilling.” (p. 107, OOSE)
![Page 23: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/23.jpg)
Scope and Its Bounds
Broader the scope, the more complex the application. Along with the problem statement, include a list of
features to be accommodated. This will narrow features. These can simply be ‘bulleted’ items
Scope, hence commitment, is clarified by listing features or sub-problems.
Determine that some of these are ‘out of scope’ or will be accommodated by a different application. Good to have a comprehensive list citing features that are
explicitly OUT of scope as well as those IN scope.
![Page 24: Business Modeling – The Domain Model Source: Use Case Driven Object Modeling with UML – A Practical Approach By Doug Rosenberg ISBN: 0-201-43289-7 Also,](https://reader036.vdocuments.mx/reader036/viewer/2022081519/56649d5f5503460f94a400d9/html5/thumbnails/24.jpg)
Scope and Bounds
Problem Statement (Vision) ‘has’ scope – that is, what the developed / enhanced application will accommodate.
Problem Statement, via plain English text, actually at a high level, contains the scope.
This is why the Vision Statement (or Problem Statement) should be followed by a list of ‘features.’
More coming…