Sept 2004 91. 3913 Ron McFadyen 1
Section 10.1 Domain Models
Domain Model: a visual representation of conceptual classes or real-world objects in a domain of interest
Domain models are also called conceptual models, domain object models, analysis object models
Domain models are illustrated with a class diagram containing
•Conceptual classes
•Associations
•Attributes
Sept 2004 91. 3913 Ron McFadyen 2
Domain model
Interface
Sale Payment
Log PersistenceFacade
applicationlogic anddomain objectlayer
technicalservices layer
minor focus
explore how to connect toother layers
primary focus ofcase study
explore how todesign objects
secondaryfocus
explore howto designobjects
Sept 2004 91. 3913 Ron McFadyen 3
Register
Item
Store
addressname
Sale
datetime
Payment
amount
SalesLineItem
quantity
Stocked-in
*
Houses
1..*
Contained-in
1..*
Records-sale-of
0..1
Paid-by
1
1
1
1
1
1
1
1
Captured-on
conceptor domainobject
association
attributes
Figure 10.1 Partial domain model
Sept 2004 91. 3913 Ron McFadyen 4
Sale
datetime
concept's symbol
"A sale represents the eventof a purchase transaction. Ithas a date and time."
concept's intension
sale-1
sale-3sale-2
sale-4
concept's extension
Figure 10.4 Conceptual class has a symbol, intension, extension
Sept 2004 91. 3913 Ron McFadyen 5
Strategy in OO analysis is
•Divide-and-conquer via conceptual classes
•Analysis task: identify concepts of interest and document these in the Domain Model.
Sept 2004 91. 3913 Ron McFadyen 6
Section 10.2 Identifying conceptual classes
Simple cash-only Process Sale scenario
1. Customer arrives at a POS checkout with goods and/or services to purchase
2. Cashier starts a new sale
3. Cashier enters item identifier
4. System records sale line item and presents item description, price, and running total
Cashier repeats steps 3-4 until indicates done
5. System presents total with taxes calculated
6. Cashier tells customer the total and asks for payment
7. Customer pays and System handles payment
...
Sept 2004 91. 3913 Ron McFadyen 7
Main Success Scenario
1. Customer arrives at a POS checkout with goods and/or services to purchase
2. Cashier starts a new sale
3. Cashier enters item identifier
4. System records sale line item and presents item description, price, and running total
Cashier repeats steps 3-4 until indicates done
5. System presents total with taxes calculated
6. Cashier tells customer the total and asks for payment
7. Customer pays and System handles payment
8. System logs the completed sale and sends sale and payment information to the external Accounting (for accounting and commissions) and inventory systems (to update inventory)
9. System presents receipt
10. Customer leaves with receipt and goods (if any)...
Sept 2004 91. 3913 Ron McFadyen 8
Main Success Scenario
•Price
•running total
• total
• taxes
• payment
•Accounting
• commissions
•inventory
• receipt
•Customer
• checkout
• goods
• services
•Cashier
• sale
•item identifier
•System
•sale line item
• item description
Sept 2004 91. 3913 Ron McFadyen 9
•Register
•Item
•Store
•Sale
•Payment
•Product Catalog
• Product Specification
•Sales Line Item
•Cashier
•Customer
•Manager
Section 10.3 Candidate Conceptual Classes
No “correct” list
Sept 2004 91. 3913 Ron McFadyen 10
•Draw the conceptual classes in the domain model
•Add associations necessary to record relationships for which there is some need to preserve some memory
•Add attributes
Section 10.4 Domain Modeling
Sept 2004 91. 3913 Ron McFadyen 11
Section 10.7 Specification (Description) conceptual classes
Include a specification class when
• we need a description of something irrespective of its existence
• deletions result in loss of information
• it reduces duplicated information
Sale
SaleLineItem ProductSpecification
We need Product Specifications … and we’ll need them in a catalog …
Sept 2004 91. 3913 Ron McFadyen 12
Section 10.7 Specification (Description) conceptual classes
A university will have a catalog that contains descriptions of courses.
Student
Enrollment CourseSpecification
We need Course Specifications … and we’ll need them in a catalog
Sept 2004 91. 3913 Ron McFadyen 13
Section 10.9 Lowering the Representational Gap
Domain Model provides a visual dictionary of the domain vocabulary and concepts
Payment
amount
Sale
datetime
Pays-for
Payment
amount: Money
getBalance(): Money
Sale
date: DatestartTime: Time
getTotal(): Money. . .
Pays-for
UP Domain ModelStakeholder's view of the noteworthy concepts in the domain.
UP Design ModelThe object-oriented developer has taken inspiration from the real world domainin creating software classes.
Therefore, the representational gap between how stakeholders conceive thedomain, and its representation in software, has been lowered.
1 1
1 1
A Payment in the Domain Modelis a concept, but a Payment inthe Design Model is a softwareclass. They are not the samething, but the former inspired thenaming and definition of thelatter.
This reduces the representationalgap.
This is one of the big ideas inobject technology.
inspiresobjects
andnames in
Sept 2004 91. 3913 Ron McFadyen 14
Classes are usually derived from:
Where Examples
things book, copy, course, student, building
roles library member, student, director of students,admissions clerk
events arrival, leaving, request
interactions meeting
• Good object oriented design results in a class model which does not distort the conceptual reality of the domain
Sept 2004 91. 3913 Ron McFadyen 15
Classes are usually derived from:
Where NextGen POS
things register, item
roles cashier
events sale
Sept 2004 91. 3913 Ron McFadyen 16
Ch 11 Associations
• correspond to verbs expressing a relationship between classes• objects do not exist in isolation - they fit together in some way
• examples: a Library Member borrows a Copy of a Booka Person works for a Company
•Multiplicities• we indicate via multiplicities the range of allowable cardinalities for participation in an association• examples: 1, 1..*, 0..*, 1..3
Person Company1..* 1
Sept 2004 91. 3913 Ron McFadyen 17
zero or more;"many"
one or more
one to forty
exactly five
T
T
T
T
*
1..*
1..40
5
T3, 5, 8 exactly three,
five or eight
Customer
Video
Rents
*
One instance of aCustomer may be rentingzero or more Videos.
One instance of a Videomay be being rented byzero or one Customers.
0..1
Multiplicity
Sept 2004 91. 3913 Ron McFadyen 18
Associations
• Names and roles
• you can name the relationship and indicate how to read it• you can give role names for participating objects
Person CompanyWorks for1..* 1
employer employee
The role of a Person in this relationship The role of a Company in this relationship
The name of the relationship and thedirection for reading the name
Sept 2004 91. 3913 Ron McFadyen 19
Register
ItemStore
Sale
Payment
SalesLineItem
CashierCustomer
Manager
ProductCatalog
ProductSpecification
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by Initiated-by
Logs-completed
*
Records-sales-on
1
1
1
1
1
1..*
11
1
1
1
1
1
1
1
1 1
1
Initiated-by
1
1
Figure 11.8 A partial domain model
Sept 2004 91. 3913 Ron McFadyen 20
Ch 12. Attributes
an object contains data which are defined as part of the Class definition
examples:• Students have names, addresses, etc; • Courses have titles, descriptions, prerequisite information.
Rectangle
corner: Point
Student
name: stringaddress: string
Sept 2004 91. 3913 Ron McFadyen 21
• attributes are preferably primitive (or just data types)
boolean, date, number, string, ...
Invoice
invDate: date
Attributes
Sept 2004 91. 3913 Ron McFadyen 22
Attributes
• show only “simple” relatively primitive types as attributes• connections to other concepts are to be represented as associations, not attributes • we do not show attributes that would be implementations of associations• example: an Invoice would not have an attribute for Customer; that is handled by the association between Customer and Invoice
Invoice
invDate: date
Customer
name: stringaddress: string
Sept 2004 91. 3913 Ron McFadyen 23
• Non-primitive types• where the associated things don’t need to be distinguished, such as phone number, quantities, points …• the abstraction makes sense in the problem domain
• a phone number has many parts• an item number that has subparts in its encoding• price is a Currency• amount is a Currency• qty_ordered is a Quantity• these make sense in the problem domain• the calculation: price * qty_ordered makes sense
Attributes
Sept 2004 91. 3913 Ron McFadyen 24
•An Invoice will have a grand total•Each Invoice Line will have a quantity ordered and a subtotal
InvLineamount: Currencyqty_ordered: Quantity
Quantity
amount: Number
InvoiceinvDate: dateamount: Currency
Attributes
Currency
amount: Number
Sept 2004 91. 3913 Ron McFadyen 25
Page 172: No Foreign Keys as attributes in the Domain Model• foreign keys are considered later in design
• example: an Invoice is not shown with an attribute for Customer; that is handled by the association between Customer and Invoice
Invoice
invDate: date
Customer
name: stringaddress: string
Attributes
Sept 2004 91. 3913 Ron McFadyen 26
Page 175: Derived attributes
• the UML notation is to prefix the attribute with a /
SalesLineItem
/quantity/subtotal
Item1..*0, 1
In this case, according to the model, there could be several items related to one line in the sale. These items are all the same type, and the quantity is therefore derivable by counting the number of related items. We are just adding more information to the model.
Attributes
Sept 2004 91. 3913 Ron McFadyen 27
Register
ItemStore
addressname
Sale
date
time
Payment
amount
SalesLineItem
quantity
CashierCustomer
Manager
ProductCatalog
ProductSpecification
descriptionpriceitemID
Stocks
*
Houses
1..*
Used-by
*
Contains
1..*
Describes
*
Captured-on
Contained-in
1..*
Described-by
*
Records-sale-of
0..1
Started-by
Paid-by Initiated-by
Logs-completed
*
Records-sales-on
1
1
1
1
1
1..*
11
1
1
1
1
1
1
1
1 1
1
Figure 12.9 A partial domain model