January 2005 92.3913 Ron McFadyen 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
January 2005 92.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
January 2005 92.3913 Ron McFadyen 3
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
January 2005 92.3913 Ron McFadyen 4
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
...
January 2005 92.3913 Ron McFadyen 5
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)...
January 2005 92.3913 Ron McFadyen 6
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
January 2005 92.3913 Ron McFadyen 7
•Register
•Item
•Store
•Sale
•Payment
•Product Catalog
• Product Specification
•Sales Line Item
•Cashier
•Customer
•Manager
Section 10.3 Candidate Conceptual Classes
No “correct” list
January 2005 92.3913 Ron McFadyen 8
•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
January 2005 92.3913 Ron McFadyen 9
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 …
January 2005 92.3913 Ron McFadyen 10
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
January 2005 92.3913 Ron McFadyen 11
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
January 2005 92.3913 Ron McFadyen 12
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
January 2005 92.3913 Ron McFadyen 13
Classes are usually derived from:
Where NextGen POS
things register, item
roles cashier
events sale
January 2005 92.3913 Ron McFadyen 14
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 CompanyAn employee is supervised by an employee
•Multiplicities• we indicate via multiplicities the range of allowable cardinalities for participation in an association• examples: 1, 1..*, 0..*, 1..3
January 2005 92.3913 Ron McFadyen 15
Associations
Person Company1..* 1
Member Book* *
*
0,1Employee
January 2005 92.3913 Ron McFadyen 16
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
January 2005 92.3913 Ron McFadyen 17
Associations
Person Company1..* 1
Member Book* *
*
0,1Employee
reports to
supervised
supervisor
borrowerborrows
Works for
employee employer
January 2005 92.3913 Ron McFadyen 18
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
January 2005 92.3913 Ron McFadyen 19
• attributes are preferably primitive (or just data types)
boolean, date, number, string, ...
Invoice
invDate: date
Attributes
January 2005 92.3913 Ron McFadyen 20
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
January 2005 92.3913 Ron McFadyen 21
• 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
January 2005 92.3913 Ron McFadyen 22
•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
January 2005 92.3913 Ron McFadyen 23
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
January 2005 92.3913 Ron McFadyen 24
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
January 2005 92.3913 Ron McFadyen 25
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
A partial domain model
January 2005 92.3913 Ron McFadyen 26
Generalization a generalization is a relationship between a general thing (the superclass or parent class) and a more specific kind of thing (the subclass or child class)example:a StaffMember is a specialized kind of LibraryMembera StudentMember is a specialized kind of LibraryMember
LibraryMember
StaffMember StudentMember
January 2005 92.3913 Ron McFadyen 27
Generalization
Multiple subclasses can be grouped to indicate they are relatedsubclasses
LibraryMember
StaffMember StudentMember
It then becomes meaningful to consider certain constraints:
complete, incomplete, disjoint, overlapping
January 2005 92.3913 Ron McFadyen 28
Generalization
Inheritance of attributes and behaviour:•everything a LibraryMember can do, a StaffMember can do•everything a LibraryMember can do, a StudentMember can do
•If a LibraryMember can borrow a book, so can a StaffMember and a StudentMember
•a StaffMember and a StaffMember have all the attributes the LibraryMember has, and possibly moreSpecialization: there are some things that a specialized class can do that a LibraryMember cannot
LibraryMember
StaffMember StudentMember
January 2005 92.3913 Ron McFadyen 29
example:
•a SavingsAccount is a specialized kind of BankAccount•a ChequingAccount is a specialized kind of BankAccount•a BankAccount is a specialized kind of Asset •RealEstate is …
Asset
RealEstate BankAccount Security
SavingsAccount ChequingAccount
January 2005 92.3913 Ron McFadyen 30
PaymentAmount: money
Cash Payment Credit Payment Cheque Payment
SalePays-for1 1
Every payment, regardless of whether it is cash, credit, or cheque, has an Amount and it is associated with a Sale
CreditCard Cheque
1
1
1
*
January 2005 92.3913 Ron McFadyen 31
Motivation for partitioning a conceptual class into subclasses:
•subclass has additional attributes of interest
•subclass has additional associations of interest
•subclass is operated on, handled, reacted to, or manipulated differently than the superclass or other subclasses
•the subclass concept represents an animate thing that behaves differently than the superclass or other subclasses
January 2005 92.3913 Ron McFadyen 32
The name Payment is italicized - meaning it is an abstract class
An abstract class is a class that will never be instantiated; only its subclasses can exist
If “Payment” was not in italics then a Payment could exist that is not a Cash, Credit, or Check payment
PaymentAmount: money
Cash Payment Credit Payment Cheque Payment
January 2005 92.3913 Ron McFadyen 33
What is the difference:
Payment
Unauthorized Payment
Authorized Payment
PaymentState
Unauthorized State Authorized State
Payment Is-in
* 1
January 2005 92.3913 Ron McFadyen 34
A composite is a group of objects in which some objects contain others; one object may represent groups, and another may represent an individual item, a leaf.
Composite Pattern
We will examine the composite pattern later in the course. At this time, we are many concerned with its structural aspect.
Consider the class diagram that follows. What objects does it allow us to instantiate and how will they relate to one another?
January 2005 92.3913 Ron McFadyen 35
Generic UML class diagram
Component
Operation()
Leaf
Operation()
Composite
Operation()Other()
*Client
Composite Pattern
January 2005 92.3913 Ron McFadyen 36
MachComponent
getMachineCount()
Machine
getMachineCount()
MachComposite
components: List
getMachineCount()
*PlantFloor
1
*1
Composite Pattern
Consider a UML class diagram for machines. Machines may be complex and contain other machines.
January 2005 92.3913 Ron McFadyen 37
An object diagram illustrating the machine on floor 5 of the plant
L1: Machine
M1: MachComposite
L2: Machine
L7: Machine L4: Machine
M9: MachComposite
floor5 :Plantfloor
Composite Pattern