Sept 200491. 3913 Ron McFadyen1 Section 10.1 Domain Models Domain Model: a visual representation of...

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


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


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


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


Strategy in OO analysis is

•Divide-and-conquer via conceptual classes

•Analysis task: identify concepts of interest and document these in the Domain Model.


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


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 …


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


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


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


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


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


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


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


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


• 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


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


Attributes


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


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

Sept 200491. 3913 Ron McFadyen1 Section 10.1 Domain Models Domain Model: a visual representation of...

Documents

Transcript of Sept 200491. 3913 Ron McFadyen1 Section 10.1 Domain Models Domain Model: a visual representation of...