January 200592.3913 Ron McFadyen1 Domain Models Domain Model: a visual representation of conceptual...

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


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


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


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

...


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)...


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


•Register

•Item

•Store

•Sale

•Payment

•Product Catalog

• Product Specification

•Sales Line Item

•Cashier

•Customer

•Manager

Section 10.3 Candidate Conceptual Classes

No “correct” list


•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


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 …


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


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


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


Classes are usually derived from:

Where NextGen POS

things register, item

roles cashier

events sale


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


Associations

Person Company1..* 1

Member Book* *

*

0,1Employee


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


Associations

Person Company1..* 1

Member Book* *

*

0,1Employee

reports to

supervised

supervisor

borrowerborrows

Works for

employee employer


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


• attributes are preferably primitive (or just data types)

boolean, date, number, string, ...

Invoice

invDate: date

Attributes


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



• 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


•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


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


Attributes


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


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


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


Generalization

Multiple subclasses can be grouped to indicate they are relatedsubclasses

LibraryMember


It then becomes meaningful to consider certain constraints:

complete, incomplete, disjoint, overlapping


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



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


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

*


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


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


What is the difference:

Payment

Unauthorized Payment

Authorized Payment

PaymentState

Unauthorized State Authorized State

Payment Is-in

* 1


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?


Generic UML class diagram

Component

Operation()

Leaf

Operation()

Composite

Operation()Other()

*Client

Composite Pattern


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.


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

January 200592.3913 Ron McFadyen1 Domain Models Domain Model: a visual representation of conceptual...

Documents

Transcript of January 200592.3913 Ron McFadyen1 Domain Models Domain Model: a visual representation of conceptual...