Domain Models

Domain Model in UML Class Diagram Notation

concept or domain object Sales LineItem quantity 1..* association Stocked-in Contained-in 1 Sale attributes date time 1 Paid-by 1 Payment amount Store address name 1 Houses 1..* Register Captured-on 4 1 1 0..1 Records-sale-of 1 Item

0..1

A visual dictionary

Domain Models

Key object-oriented analysis step: Decompose domain into noteworthy concepts or objects UML class diagrams used to draw domain models
Conceptual perspective. Shows:
Domain objects (conceptual classes) Associations between domain objects Attributes of conceptual classes

Domain model is NOT a model of software objects or our design The following should NOT be in a domain model
Software artifacts: Window, database, Responsibilities or methods

Sale dateTime

visualization of a real-world concept in the domain of interest it is a not a picture of a software class

id o av

SalesDatabase

software artifact; not part of domain model

id o av

Sale date time print() software class; not part of domain model

Software Class Names Inspired by Domain Model Objects

UP Domain Model Stakeholder's view of the noteworthy concepts in the domain. A Payment in the Domain Model is a concept, but a Payment in the Design Model is a software class. They are not the same thing, but the former inspired the naming and definition of the latter. This reduces the representational gap. This is one of the big ideas in object technology. Payment amount: Money getBalance(): Money 1 Pays-for 1 date: Date startTime: Time getTotal(): Money ... Payment amount inspires objects and names in Sale Sale 1 Pays-for 1 date time

UP Design Model The object-oriented developer has taken inspiration from the real world domain in creating software classes. Therefore, the representational gap between how stakeholders conceive the domain, and its representation in software, has been lowered.

How to create a domain model?

Find conceptual classes

How?
Re-use or modify existing models Use a category list Identify noun phrases More on these later

Draw them as classes in a UML class diagram Add associations and attributes
More on this later

Identifying nouns as candidates for domain objects

Candidate Conceptual Classes: Process Sale, Iteration 1

Register

Item

Store

Sale

Sales LineItem

Cashier

Customer

Ledger

Cash Payment

Product Catalog

Product Description

Attributes vs. Classes

Should something be
an attribute of a class, or a separate conceptual class

Examples:
Store: An attribute of Sale or separate class
Store: Not a number or text Should be separate conceptual class

Flight destination: An attribute or a separate class

Destination is an airport, not a number Should be separate conceptual class

Guideline:
If we thing of something as simply a number or text in real life, it should be an attribute. Otherwise it should be a conceptual class.

Description Classes A description class contains information that describes something else
Example: ProductDescription Records price, picture and text description of an item

Why use them? Why not include all that information in the Product class?
We need this information stored and represented even though there are no objects of that particular product type. Dont want to duplicate product information for each duplicate product object
Serial number belongs with product object Picture of product belongs with product description

Need objects that are specifications or descriptions of other objects

Description class example

Item description price serial number itemID Worse

ProductDescription description price itemID Describes 1 Item

Better serial number

Description class example

Flight date number time Flies-to Airport Worse 1 name

Flight Described-by date time

FlightDescription 1 number

Better

*
Describes-flights-to 1 Airport name

Even when that flight is not scheduled that day, the flight description exists.

Associations

Association: A relationship between (instances of) classes that indicates some meaningful and interesting connection. Used to show relationships that need to be remembered and preserved for some duration
association

Register

Records-current 1 1

Sale

Which relationships need to be remembered?

Example: Does a Sale-SalesLineItem relationship need to be remembered (preserved)?\

Yes, otherwise cant process returns or exchanges.

Example: Cashier looks up ProductDescription

Dont need to remember/store.

Example:
What square is a Monopoly player on?
Need to remember

Dice total tells us which Square to move to

Do we need to store this fact with the Dice or the Square? No!

Common Associations List (i)

Common Associations List (ii)

Common Associations List (iii)

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

Register

Records-current 4 1 0..1

Sale

association name

multiplicity

How to name an association?

Pattern:
Class name verb phrase class name Readable and meaningful

Try to avoid has or uses. These give no extra information

Association Multiplicities

Store

Stocks 1

Item

multiplicity of the role

Multiplicities

*
1..*

zero or more; "many"

one or more

1..40

one to 40

exactly 5

3, 5, 8

exactly 3, 5, or 8

Multiple Associations

*
Flight

Flies-to Flies-from

1 Airport 1

POS Domain Model Example:

R e c o rd s -s a le -o f P ro d u ct D e s c rip tio n C o n ta in s 1 1 0 ..1 S a le s L in e Ite m 1 R e c o rd s a c c o u n ts fo r 1 U s e d -b y D e s crib e s 1 .. * Ledger

P ro d u c t C a ta lo g

*
S to re S to c ks 1 1

*
Ite m

1 1 .. * C o n ta in e d -in 1 S a le Logsc o m p le te d

1 ..*

H ouses

1 .. * R e g iste r

*
C a p tu re d -o n 0 ..1 1

P a id -b y 1 C ashP aym ent

Is -fo r 1 C u s to m e r

3 W o rk s -o n 1 C a s h ie r

Example: Domain Model for the Monopoly Game

Attributes

attributes Sale dateTime / total : Money

derived attribute

An attribute: A logical data value stored in an object

More detailed attribute notation visibility name: type multiplicity = default value {property-string}

Sale - dateTime : Date - / total : Money

Math + pi : Real = 3.14 {readOnly}

Person firstName middleName : [0..1] lastName

Private visibility attributes

Public visibility readonly attribute with initialization

Optional value

Attribute requirements (such as an optional middle name) should also be placed in the Glossary.

Derivable attributes
SalesLineItem 0..1 Records-sale-of 1 Item Each line item records a separate item sale. For example, 1 tofu package.

SalesLineItem

0..1

Records-sale-of

1..*

Item

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

SalesLineItem /quantity

0..1

Records-sale-of

1..*

Item

derived attribute from the multiplicity value

The / sign: the value of this attribute can be calculated or derived from other attributes Still, it is noteworthy and may be recorded separately

Most attribute types should be primitive data types

Cashier Worse name currentRegister not a "data type" attribute

Cashier Better name

Uses

Register number

Guideline: The attributes in a domain model should be (simple, primitive) data types
Boolean, Date, Number (Integer, Real), String (Text), Time, Phone Number, ID Number, Postal Code,

Non-data type relationships (i.e., conceptual class relationships) should be expressed using associations, not attributes.

Do we need a new box for these classes?

ItemID OK Product Description 1 1 id manufacturerCode countryCode Store 1 1

Address street1 street2 cityName ...

OK

Product Description itemId : ItemID

Store address : Address

Attributes representing foreign keys Avoid them!

Cashier Worse name currentRegisterNumber

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

Cashier Better name

Works-on

Register number

Payment amount : Number

not useful

Payment

Has-amount4

Quantity 1 amount : Number

Is-in4

Unit 1 ...

*
Payment amount : Quantity

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 Example:

R e c o rd s -s a le -o f P ro d u c t D e s c rip tio n C o n ta in s 1 1 0 ..1 S a le s L in e Ite m q u a n tity 1 .. * C o n ta in e d -in 1 S a le d a te T im e / to ta l 1 P a id -b y 1 C ashP aym ent a m o u n tT e n d e re d 1 Is -fo r 1 C u s to m e r id Logsc o m p le te d 1 R e c o rd s a c c o u n ts fo r 1 U s e d -b y 1 .. * ite m ID d e s c rip tio n p ric e D e s c rib e s

Ledger

P ro d u c t C a ta lo g

*
S to re S to c k s nam e a d d re s s 1 1

*
Ite m

1 ..*

H ouses

1 .. * R e g is te r id 1 3 W o rk s -o n 1 C a s h ie r

*
C a p tu re d -o n 1 0 ..1

POS Domain Model Example:

Monopoly Domain Model Example