copyright ©2004 cezary z janikow 1 domain model n visualization of entities and relationships n in...

Copyright ©2004 Cezary Z Janikow 1

Domain Model

Visualization of entities and relationships In UP presented as Class Diagrams

– Classes, Relationships, Attributes in the domain

Important analysis artifacts– Driven by use case

– Stipulates initial design ideas in contracts

– Stipulates final design in Interactions

– Provides visual dictionary

Moves through different perspectives– Conceptual: from use case

– Design: from Interactions

– Implementation: implementation details


Domain Model: when

Start in Inception

Most efforts to detail in Elaboration


Domain Model

Process Sale

1. Customer arrives ...2. ...3. Cashier enters item identifier.4....

Use Case Text

Operation: enterItem(…)

Post-conditions:- . . .

Operation Contracts

Sale

date. . .

SalesLineItem

quantity

1..*1 . . .

. . .

the domain objects, attributes, and associations that undergo state changes

Domain Model

Use-Case Model

Design Model

: Register

enterItem(itemID, quantity)

: ProductCatalog

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

: Sale

. . .

conceptual classes in the domain inspire the names of some software classes in the design

conceptual classes –terms, concepts attributes, associations

Cashier: …Item ID: …...

Glossary

elaboration of some terms in the domain model

Require-ments

Business Modeling

Design

Sample UP Artifact Relationships


Domain Model: partial POS example (conceptual)

Register

Item

Store

addressname

Sale

date time

Payment

amount

SalesLineItem

quantity

Stocked-in

*

Houses

1..*

Contained-in

1..*

Records-sale-of

0..1

Paid-by

1

1

1

1

1

1

0..1

1

Captured-on

conceptor domain object

association

attributes


Class Diagram

Static view of the domain

Presents domain conceptual classes

And not proposed implementation or design classes

Sale

dateTime

visualization of a real-world concept in the domain of interest

it is a not a picture of a software class

SalesDatabase software artifact; not partof domain modelavoid

software class; not partof domain model

Sale

datetime

print()

avoid


Conceptual Class

Symbol

Intension: definition

Extension: set of elements

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


Domain Model vs. Design Model

Same names and notation lower the representation gap

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


Domain Model vs. Data Model?

Domain Model

– Concepts, entities, can be abstract

– Relations

– Attributes

Data Model

– How data is stored into persistent storage

– Pure data, in files or databases


Domain Model: how to create?

1. Find conceptual classes

– Refine existing model and/or use patterns

– Explore concepts in the Category List

See Table 9.1

– Explore Noun Phrases

Lexical/linguistic analysis of use cases and other text documents

See pate 142

2. Add associations

3. Add attributes


Conceptual classes in POS

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Class or Attribute?

– Use the 3 object properties to test

– Remember design will change things if needed


Description Classes

Class that describes something else

– Example:

Item object represents physical object

Description of the object is separate

In the design perspective, we need to retain description even if sold out on items (and thus no item objects)

Item

descriptionpriceserial numberitemID

ProductDescription

descriptionpriceitemID

Item

serial number

Describes Better

Worse

1 *


Rules for having Description classes

– If descriptions are independent of the exietence of items

– If deleting an object deletes information that may need to be maintained

– If it reduces duplications or adds clarity

Worse

Flight

datetime

FlightDescription

number

Airport

name

Describes-flights-to

Described-by

Flight

datenumbertime

Airport

name

Flies-to

Better

1*

1*

1

*


Associations

Relationships between classes

– Stemming from relationships on objects

Transient (for some duration that we need to investigate details of)

Persistent

Derived from Analysis or the Association List (Table 9.2)

In the conceptual model, association is just a statement about the relationships

– If message need to be passes, it will persist in the design model (from Interactions)

Visibility and navigability will have to be established


SaleRegister Records-current 0..11

association name multiplicity

-"reading direction arrow"-it has no meaning except to indicate direction of reading the association label-often excluded

Association Notations


Associations

Naming

– Verb Phrases

Roles

– Each end

– Having

Names for the roles of the two classe/objects (sometime this is called “roles”)

MultiplicityHow many objects participate

NavigabilityHow one object will find the other object to send a message


Multiplicity

zero or more;"many"

one or more

one to 40

exactly 5

T

T

T

T

*

1..*

1..40

5

T3, 5, 8

exactly 3, 5, or 8

ItemStore Stocks

*

multiplicity of the role

1


Multiplicity

ItemStore Stocks

1or 0..1

Multiplicity should "1" or "0..1"?

The answer depends on our interest in using the model. Typically and practically, the muliplicity communicates adomain constraint that we care about being able to check in software, if this relationship was implemented or reflectedin software objects or a database. For example, a particular item may become sold or discarded, and thus no longerstocked in the store. From this viewpoint, "0..1" is logical, but ...

Do we care about that viewpoint? If this relationship was implemented in software, we would probably want to ensurethat an Item software instance would always be related to 1 particular Store instance, otherwise it indicates a fault orcorruption in the software elements or data.

This partial domain model does not represent software objects, but the multiplicities record constraints whose practicalvalue is usually related to our interest in building software or databases (that reflect our real-world domain) with validitychecks. From this viewpoint, "1" may be the desired value.

*


Multiple Associations

Two classes can have multiple relations

Flight Airport

Flies-to

Flies-from

*

* 1

1


Conceptual Domain Model in POS

Register

ItemStore

Sale

CashPayment

SalesLineItem

CashierCustomer

ProductCatalog

ProductDescription

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1


Attributes

Logical data value of an object

Carefully distinguish attributes from objects

– Do not use to relate classes or objects

Use associations instead

– Use as classes if

Composed of multiple elements (has attributes-states)

There are operations (behavior)

Has units of quantity


Attributes: notation

Sale

- dateTime : Date- / total : Money

Private visibility attributes

Math

+ pi : Real = 3.14 {readOnly}

Public visibility readonly attribute with initialization

Person

firstNamemiddleName : [0..1]lastName

Optional value

Sale

dateTime/ total : Money

attributes

derived attribute


Multiplicity vs. derived attribute

SalesLineItem ItemRecords-sale-of 10..1

SalesLineItem ItemRecords-sale-of0..1 1..*

Each line item records aseparate item sale.For example, 1 tofu package.

Each line item can record agroup of the same kind of items.For example, 6 tofu packages.

SalesLineItem

/quantity

ItemRecords-sale-of0..1 1..*

derived attribute fromthe multiplicity value


Attributes: examples

Cashier

namecurrentRegister

Cashier

name

Register

number

Uses

Worse

Better

not a "data type" attribute

1 1

Flight

Flight

destinationWorse

BetterFlies-to Airport1 1

destination is a complex concept


Attributes: examples

OK

OK

ProductDescription

ProductDescription

itemId : ItemID

1Store

Store

address : Address

11 1

ItemID

idmanufacturerCodecountryCode

Address

street1street2cityName...

Cashier

namecurrentRegisterNumber

Cashier

name

Register

number

Works-on

Worse

Better

a "simple" attribute, but being used as a foreign key to relate to another object

1 1


Attributes: examples of quantities

Payment

amount : Number

Payment Quantity

amount : Number

Unit

...

Payment

amount : Quantity

Has-amount1*

Is-in1*

not useful

quantities are pure data values, so are suitable to show in attribute section better

Payment

amount : Money

variation: Money is a specialized Quantity whose unit is a currency


POS Domain Model w/attributes

Register

id

ItemStore

nameaddress

Sale

dateTime/ total

CashPayment

amountTendered

SalesLineItem

quantity

Cashier

id

Customer

ProductCatalog

ProductDescription

itemIDdescriptionprice

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

Works-on

1

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1

Ledger

Records-accounts-

for

1

1

copyright ©2004 cezary z janikow 1 domain model n visualization of entities and relationships n in...

Documents