Upload
estella-caitlin-mills
View
217
Download
1
Embed Size (px)
Citation preview
1/24
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
2/24
Background A key component of Business Modeling (Domain Analysis) - in addition to
Business Use Case Model and Business Object Model and other artifacts - is the Domain Model Recall the Business Model is not only a graphical model, but also
other artifacts such as the Business Vision, Business Rules, Business Glossary, Business Risk List, and the Domain Model.
All relate to the enterprise / organization.
The Domain Model contains Key Abstractions (business / technology) Is a Visual Model of business entities, relationships, multiplicities, and
more.
Prior to embarking on gathering requirements and capturing them via Use Cases (application use cases, requirements use cases, that is…), we need to understand the key entities in the business domain.
3/24
Domain Modeling - an Introduction
Domain Modeling is the task of discovering “objects” (classes, actually) that represent those business entities and concepts.
Recognize that the domain model will be a superset of your entity classes needed for your application development. These class diagrams – later on - will likely contain some of the
entities found in your domain model. These appear similar to ERDs, but they are not the same.
Fully-attributed list (not a schema or physical database design…)
4/24
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/among them in the business domain itself.
As a Visual Model, this model helps in understanding the domain.
Also serves as a Glossary, in that the entities will contain attributes and other defining qualities. Think ‘Customer, ’ ‘Product Line’ etc.
5/24
Domain Modeling - continued
The Domain Model: Does NOT wholly support requirements analysis (ahead). Is not INTENDED to… Addresses entities in the domain of the organization – that may be
quite apart (superset) from a computer application that may use them.
Are normally not concerned with representations of inheritance, polymorphism, etc, but can show aggregation, multiplicities, etc. (as we would be when embarking on development of an
application.)
6/24
Domain Modeling - continued In requirements analysis –
as part of gathering information on the application to be developed,
we develop class diagrams - contain entities (classes) taken from the domain model.
But the class diagrams (for development) will represent data that will be stored and manipulated by the application.
Class diagrams also include operations (methods, uses)
7/24
Domain Modeling - continued
Models produced as part of requirements analysis (ahead lectures) will contain: Entity classes –
some may be derived from Domain Model, (Most complicated) Boundary classes –
used for the user interface and external system interfaces with, perhaps, systems/ databases that already exist;
Control Classes used for controlling logic and business rules, and, in general,
orchestrating the application functions.
8/24
So, what do we do? Doing domain modeling is very important. Don’t want to spend too much time trying 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 business entities (nouns).
This is a a static model of the domain by finding appropriate entities that represent the real key abstractions in the domain. A ‘key abstraction’ example is Customer, Product, Account,
etc. Serve to underpin system development later.
9/24
Developing Entities for Domain Model Sources (again) 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 in these sources! – these are candidate classes in the domain model. More examples: Menu, Customer, Food order, Payment, On-line order…Things!
Customer (class with attributes) ‘orders’ (relationship) Food (class with attributes)
Capture graphically! ‘Customer’ and ‘Food’ are entities related by ‘Orders’ with multiplicity 1..n.
10/24
Developing Domain Entities Read sources very closely; Capture these ‘nouns’ and noun phrases. Look for the ‘things’ in the domain…
Possessive phrases generally indicate that the nouns should be attributes rather than objects. Try to identify attributes but omit operations.
Build associations (and name them) between domain entities Add multiplicities carefully Don’t worry about aggregations and association classes and much
more unless these relationships are clearly evident.
Model in some tool.
11/24
Generalization Relationships and Associations
If clear from your info gathering, build generalization relationships Parents, subclasses…. Inheritance of attributes, methods, and
associations! Not a must, but if clear: do it. ‘is a’ relationships….
Associations are static relationships between classes. Semantic relationships. A class may have many students…
Show dependencies if needed.
12/24
Associations and Multiplicity
Label the associations as best you can (and you should) 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’. You are familiar with this concept from OOP.
Also, there is composition – where one piece is ‘owned’ by another – later…..
Focus on simple aggregations now. Don’t stress on relationships not obvious at this time.
13/24
Association Classes
Identify classes that particularly address the ‘many-to-many’ relationships that link classes patient and doctor? m:n?
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. We really don’t care at this time…(These are implementation dependencies)
Don’t overuse these….
14/24
Following slide is an example (has a few errors in it) that you may use as a guide.
See also my web page…
15/24
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
Belogs to
Is categorized as
places
manages
Is generated forprovides
Is generated for identifies
tracks
references
contains
Domain Model More database notation here (cardinality; modality)
16/24
FINANCE
DateAccountsReceivablesAccountsPayablesDescriptionLiabilities
SCHEDULE
WorkerIDDayHourPrintSchedule
WORKER
WorkerIDWorkerNameWorkerGroupIDWorkerPhoneWorkerAddressWorkerSalaryWorkerSSN
11..* 11..*
viewed by / views
ONLINE_ORDER
CustomerNoDishIDCustomerSpecialRequestOrderTrackingNumber
MENU
MenuDayDishIDDishNameDishDescriptionDishPrice
CUSTOMER
CustomerNameCustomerPhoneCustomerNo
1..*
1
1..*
1
placed by / orders
1..*
1..*
1..*
1..*
viewed by / views
PAYMENT
CustomerNoCustomerCreditCardTotalChargeOrderTrackingNumber
1..*
1
1..*
1
pays / paid by
WORKER_GROUP
WorkerGroupIDWorkerGroupCategory
1..*
1
1..*
+management 1
manages / managed by
1..*1
1..*+management
1 changes / modified by
1..*
1
1..*
+management 1
makes / made by
1..*
1
1..*
1
has / is in
1..*
1
1..*
+management1
maintains / maintained by
1..*1..* 1..*1..* views / viewed by
1..*
1
1..*+management
1
accepts / accepted by
Another example: note the associations; attributes;roles, multiplicities, etc. Not the ‘core abstractions.’
17/24
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. Undertake noun and verb analysis so exhaustively 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.
18/24
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.
19/24
Transition to: The Problem Space!!!
Area within which your application is to exist!
20/24
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
21/24
Problem Statement (‘Product Vision’ - Statement of Need.)
The problem statement should be a simple sentence or two or three. Usually then found in a Product Vision Document
VERY IMPORTANT; Needs are very high level and usually include more than that which can be accommodated by an automated system.
Basis to answer the ultimate question: Have we solved the problem?
Be careful what you write!!! Wild inferences can be made.
22/24
Sample Problem Statement – Need.(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.”
23/24
Scope and Its Bounds
Broader the scope, the more complex the application.
Scope exists along with the problem statement This will narrow include a list of features. Features can be accommodated by an automated system. 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.
24/24
Scope and Bounds
Problem Statement (Product Vision) ‘has’ scope – that is, what the developed / enhanced application will accommodate.
This is why the Product Vision Statement includes a list of ‘features.’
More coming…