Domain Models

Chapter 9

Applying UML and Patterns

-Craig Larman

Introduction

Remember:

• Use cases are not object-oriented requirement analysis , but they emphasize an activity view.

A domain model is the most important and classic-model in Object Oriented Analysis

2

Domain model ? A domain model is a visual representation of

conceptual classes (idea, thing or object) or real-situation objects in a domain.

Make it easier to understand the key concepts and the stakeholders view.

A UP domain model is a visualization of things in a real-situation domain of interests, not of software objects such as Java or C# classes.

It is part of the Business Model artifact

4

Domain Model Relationships

Domain Model

Use Case Model

Interaction Diagrams

Glossary

Design

Requirements

Business Model

Classes, attributes, associations

Domain Objects = conceptual classes

Elaboration on some terms

Fig. 9.1 Example

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

6

Domain Model -UML Notation

Illustrated using a set of class diagrams for which no operations are defined.

It may contain: Domain Objects or Conceptual Classes Associations between conceptual

classes Attributes of conceptual classes

7

A Domain Model is not a Software Artifact

Sale

Date

Time

A Conceptual class:

A Domain Model is not a Software Artifact

Sale

Date

Time

Print()

Software Artifacts:

Object responsibilities is not part of the domain model. (But to consider during Design)

9

Think of Conceptual Classesin terms of:

Symbols – words or images Intensions – its definition (what does it represent) Extensions – the set of examples to which it

applies.

Note ; during each iteration, only objects in current scenarios are considered for addition to the domain model.

Symbol, intension and extension.

Sale

datetime

concept's symbol

"A sale represents the event of a purchase transaction. It has a date and time."

concept's intension

sale-1

sale-3sale-2

sale-4

concept's extension

Fig 9.5

All the examples of sales

Question : Why create Domain model ?Answer : To take inspiration of real world domain to create software classes

Question : Why create Domain model ?Answer : To take inspiration of real world domain to create software classes

How to find these conceptual classes ?

14

Method1 : Identify Conceptual Classes by Category List: p 140-141

Common Candidates for classes include:

Descriptions

Roles

Places

Transactions

Containers

15

Abstract nouns

Rules

Organizations

Events

Processes

16

Written Materials

Catalogs

Records

Financial Instruments

Services

Systems

17

Method2: Conceptual Classes with Noun Phrase Identification

Identify Nouns and Noun Phrases in textual descriptions of the domain.

Fully dressed Use Cases, problem definition are good for this type of linguistic analysis.

It’s not strictly a mechanical process: Words may be ambiguous Different phrases may represent the same

concepts.

Main Success Scenario (or Basic Flow):

• 1. Customer arrives at 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.

• Price calculated from a set of price rules.

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

18

8. System logs completed sale and sends sale and payment information to the external

accounting system (for accounting and commissions) and Inventory system (to update inventory).

9. System presents receipt.

10. Customer leaves with receipt and goods (if any).

Extensions (or alternative Flows)

7a. Paying by cash:

• 1. Cashier enters the cash amount tendered.

• 2. System presents the balance due, and releases the cash drawer.

• 3. Cashier deposits cash tendered and returns balance in cash to Customer.

• 4. System records the cash payment.

19

Fig. 9.7

StoreRegister SaleItem

CashPayment

SalesLineItem

Cashier Customer

ProductCatalog

ProductDescription

Ledger

Remember : There is no such things as a correct list. Brainstorm what you consider noteworthy to be a candidate. But in general , different modelers will find similar lists.

Suppose all the items (ObjectBurgers) are sold out and then deleted.

Someone ask you “”How much do ObjectBurgers cost ?

When to model Specification/Description Conceptual Classes?

Example1: Fig. 9.9

Item

descriptionpriceserial numberitemID

ProductDescription

descriptionpriceitemID

Item

serial number

Describes Better

Worse

1 *

23

When to model Specification/Description Conceptual Classes?

A Class that records information about an item.

Even if all Instances of the item are sold out, the description remains.

It avoids duplication of recording the descriptive information with each instance of the item.

Example2 : Fig. 9.10

Worse

Flight

datetime

FlightDescription

number

Airport

name

Describes-flights-to

Described-by

Flight

datenumbertime

Airport

name

Flies-to

Better

1*

1*

1

*

Association: Relationship between classes (more precisely, between instances of those classes).

SaleRegisterRecords-current

1 1

association

Fig. 9.11

Fig. 9.12

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: Relationship between classes (more precisely, between instances of those classes).

Fig. 9.13

ItemStore Stocks

*

multiplicity of the role

1

“many” ( 0 or more )

Multiplicity indicates how many instances can be validly associated with another instance, at a particular moment, rather than over a span of time. Example : monogamy

Fig. 9.14 : multiplicity values

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

Multiplicity communicates a domain constraint that will be reflected in software. How ?

ItemStore Stocks 1

or 0..1

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

The answer depends on our interest in using the model. Typically and practically, the muliplicity communicates a domain constraint that we care about being able to check in software, if this relationship was implemented or reflected in software objects or a database. For example, a particular item may become sold or discarded, and thus no longer stocked 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 ensure that an Item software instance would always be related to 1 particular Store instance, otherwise it indicates a fault or corruption in the software elements or data.

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

*

Fig. 9.15

Multiple Associations between two classes

Flight Airport

Flies-to

Flies-from

*

* 1

1

Attributes

A logical data value of an object. Imply a need to remember information.

• Sale needs a dateTime attributte

• Store needs a name and address

• Cashier needs an ID

31

Fig. 9.19

Sale

dateTime/ total : Money

attributes

derived attribute

Fig. 9.20

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

SalesLineItem ItemRecords-sale-of 10..1

SalesLineItem ItemRecords-sale-of 0..1 1..*

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

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

SalesLineItem

/quantity

ItemRecords-sale-of 0..1 1..*

derived attribute from the multiplicity value

Fig. 9.21 : Derived Attributes

The quantity entered by the cashier may be recorded as an attribute “quantity” of the SaleLineItem class. However the quantity can be calculated from the actual multiplicity value of the association

Fig. 9.22 : Association or attribute

Cashier

namecurrentRegister

Cashier

name

Register

number

Uses

Worse

Better

not a "data type" attribute

1 1

Most attribute type should be “primitive” data type, such as: numbers and booleans.

Attribute should not be a complex domain concept(Sale , Airport) CurrentRegister is of type “Register”, so expressed with an

association

Most attribute type should be “primitive” data type, such as: numbers and booleans.

Attribute should not be a complex domain concept(Sale , Airport) CurrentRegister is of type “Register”, so expressed with an

association

Fig. 9.23

Flight

Flight

destinationWorse

BetterFlies-to Airport1 1

destination is a complex concept

A destination airport is not a string, it is a complex thing that occupies many square kilometers of space. So “Airport” should be related to “Flight” via an association , not with attribute

Should the “ItemID” class be shown as a separate class ?

It depends on how the domain model is being used.

OK

OK

ProductDescription

ProductDescription

itemId : ItemID

1Store

Store

address : Address

11 1

ItemID

idmanufacturerCodecountryCode

Address

street1street2cityName...

Fig. 9.24 ItemID are primitive types(number, boolean, character, string…etc)

ItemID is a new type with its own attributes

Fig. 9.26 : Modeling quantities and Units

Price is a quantity with associated units. How should we model them?

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

39

A Common Mistake when modeling the domain- Classes or Attributes?

Rule: If we do not think of a thing as a number or text in the real world, then it is probably a conceptual class.

If it takes up space, then it is likely a conceptual class.

Examples: Is a store an attribute of a Sale ? Is a destination an attribute of a flight ?

Assignment 1: Mobile phone system Problem definition Consider a system for a simple mobile phone.

The phone can receive calls and call other phone numbers. It offers its owner a personal phone book to store namse and phone numbers. The phone book can be dynamically updated. The phone also manages a complete log of all incoming and outgoing calls and helps its owner to remember unanswered calls.

assignment

Find classes and attributes for the mobile phone system.

assignment

Find classes and attributes for the library system. For help see the videos from requirements to classes.

How to create a domain model

Find the conceptual classes Draw them as classes in a UML class

diagram Add associations and attributes

But remember

There is no such thing as a single correct domainmodel. All models are approximations of the domain we are attempting to understand.

We incrementally evolve a domain model over several iterations on attempts to capture all possible conceptual classes and relationsships.