TK2023 Object-Oriented Software Engineering

CHAPTER 5DOMAIN MODELLING

INTRODUCTION

One of the steps in object-oriented analysis is the decomposition of a domain of interest into individual conceptual classes or objects (real-world objects).

An important artifact created in this step is a domain model (also known as conceptual model, domain object model and analysis object model).

DOMAIN MODELS

A domain model is a visual representation of conceptual classes or real-world objects in a domain of interest.

In UML, a domain model is illustrated with a set of class diagrams in which no operations are defined.

It shows: conceptual classes (concepts / domain objects) associations between conceptual classes attributes of conceptual classes

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 4

conceptor domain object

association

attributes

DOMAIN MODEL - A VISUAL DICTIONARY OF ABSTRACTIONS Note that the diagram in the previous slide

depicts an abstraction of the conceptual classes; details which are uninteresting to the modellers are ignored in the diagram.

The visual makes it easy to comprehend the discrete elements and their relationships. Thus, the domain model may be considered a visual dictionary of abstractions of the domain.

DOMAIN MODELS DO NOT SHOW SOFTWARE COMPONENTS A domain model is a visualization of things in the

real-world domain of interest, not of software classes.

The following elements are not suitable in a domain model: software artifacts

responsibilities or methodsSale

dateprint()

POSApplet

IDENTIFYING CONCEPTUAL CLASSES In iterative development, a domain model is

incrementally built over several iterations in the elaboration phase.

In each iteration, the domain model is limited to the prior and current scenarios under consideration.

It is okay to miss conceptual classes during the initial identification step. The domain model can be updated when they are discovered later (e.g. during design work).

STRATEGIES FOR IDENTIFYING CONCEPTUAL CLASSES The following techniques can be used:

use a conceptual class category list identify noun phrases

Identify nouns and noun phrases in textual descriptions of a domain, and consider them as candidate classes or attributes.

Weakness: natural language is imprecise E.g. different noun phrases may represent the

same conceptual class or attribute.

use analysis patterns Analysis patterns are existing partial

domain models created by experts

CASE STUDY: PROCESS SALE Based on a simplified scenario of Process

Sale, the following candidate conceptual classes are identified using the first two techniques above:

Register ProductSpecification

Item SalesLineItem

Store Cashier

Sale Customer

Payment Manager

ProductCatalog

REPORT OBJECTS

Should "receipt" be included in the domain model? One reason to exclude it:

A receipt is a report of a sale. In general, it is not useful to include conceptual classes that reports information that can be derived from other sources.

One reason to include it: A receipt has a special role in the domain. A customer

needs a receipt in order to return bought items.

BUILDING A DOMAIN MODEL Apply the following steps:

1. Identify candidate conceptual classes related to the current requirements (use case) under consideration.

2. Represent those classes in a domain model.

3. Add associations necessary to record relationships for which there is a need to preserve some memory.

4. Add attributes necessary to fulfill the information requirements.

SOME GUIDELINES

Use the vocabulary of the domain when naming conceptual classes and attributes. For example, in the library domain, the term

"Borrower" or "Patron" is used rather than "Customer"

You should not include conceptual classes in the problem domain not pertinent to the requirements. For the case study, "Pen" and "PlasticBag" should

not be included.

You should not include things not in the problem domain. For example, "Flight" does not exist in the library

domain.

ATTRIBUTE OR CONCEPTUAL CLASS? A common mistake when building a domain

model is to represent something as an atribute when it should have been a conceptual class.

Salestore

Sale StorephoneNumber

ORRepresent "store"as an attribute

Represent "store"as a conceptualclass

Use the following rule of thumb:

If we do not think of some conceptualclass X as a number or text in the realworld, then X is probably a conceptualclass and not an attribute.

Another example,

Flightdestination OR

Flight Airportname

Consider our case study. Let's assume that: An "Item" represents a physical item in a store. An "Item" has a description, price and itemID,

which are not recorded elsewhere. Everyone working in the store has amnesia. Every time a real physical item is sold, a

corresponding software object "Item" is deleted from the computer memory.

“Rice Brand X”RM0.6011234

“Rice Brand X”RM0.6011234

“Rice Brand X”RM0.6011234

“Rice Brand X”RM11.00U110-134

“Rice Brand X”RM11.00U110-134

“Rice Brand X”RM11.00U110-134

SPECIFICATION OR DESCRIPTION CONCEPTUAL CLASSES

Problems: Information about the price of a "Rice Brand X"

product is lost if the shop is sold out of "Rice Brand X" products.

Space inefficiency as the price and itemID of "Rice Brand X" are duplicated for every "Item" instance of the same product.

This illustrates the need for conceptual classes that are specifications or descriptions of other things.

Example:

ItemdescriptionpriceserialNumberitemID

ItemserialNumber

ProductSpecificationdescriptionpriceitemID

*1

Describes

1 *

Add a specification or description conceptual class when: There needs to be a description about an item or

service, independent of the current existence of any examples of those items or services.

Deleting instances of things they describe results in a loss of information that needs to be maintained.

It reduces redundant or duplicated information.

Another example:

Airportname

Flightdatetime

FlightDescriptionnumber

1

*

1

*Describes-flights-to

1*

Described-by

* 1

Airportname

Flightdatenumbertime

* 1

Flies-to

1*

CASE STUDY: INITIAL DOMAIN MODEL

ItemRegister Store Sale

SalesLineItem Cashier Customer Manager

Payment ProductCatalog ProductSpecification

Based on the candidate conceptual classes identified previously, an initial domain model can be produced as follows:

ASSOCIATIONS

An association is a relationship between classes that indicates some meaningful and interesting connection.

Register Sale

11

Records-current

1 1

THE UML ASSOCIATION NOTATION

Sale Cashier

1** 1

Initiates

associations in domain models areinherently bidirectional

reading direction arrow - no special meaning, it's just to aid reading

multiplicity expressions

"Cashier initiates Sale"

CRITERIA FOR USEFUL ASSOCIATIONS We need to be selective when adding

associations to a domain model. There can be n*(n-1) possible associations in a

domain model with n different conceptual classes. Too many associations in a domain model can

make it difficult to understand which defeats its purpose as a communication tool.

Associations worth adding to a domain model are usually those for which knowledge of the relationship needs to be preserved for some duration (even for a millisecond).

For example,

The SalesLineItem objects associated with a Sale object need to be remembered; otherwise, it would not be possible to print a receipt, for instance.

Sale SalesLineItem

1..*11 1..*

Contains

Also, include associations as suggested by the requirements (use cases).

Sale Manager

1** 1

FINDING ASSOCIATIONS

Consider including the following associations in a domain model: Associations for which knowledge of the

relationship needs to be preserved for some duration ("need-to-know" associations).

Associations derived from the Common Associations List. Give priority to these categories

A is a physical or logical part of B A is physically or logically contained in/on B A is recorded in B

USEFUL GUIDELINES

Focus on "need-to-know" associations. It is more important to identify conceptual

classes than to identify associations. Too many associations tend to confuse a

domain model. Avoid showing redundant or derivable

associations.

Example:

SalesLineItem

Item

0..1

1..*

Sale1 1..*1 1..*

Contains

0..1

1..*

Records-Sale-Of

1..*

0..10..1

1..*

Involves

DERIVABLE

MULTIPLICITY

Multiplicity defines how many instances of a class A can be associated with one instance of a class B.

Store Item*1

Stocks

*1

association 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

Note that the multiplicity value is dependent on our interest as a modeler and software developer.

Consider the following possibilities:

husband

Person

1

1..4

Married-to

wife

1

Person

1

Married-to

wife

1

1husband

Person

1

1..*

Married-to

wife

1husband

NAMING ASSOCIATIONS The name of an association should be a verb or

a verb phrase. Ensure that it creates a sequence that is readable and meaningful in the model context. By convention, the default direction is left to right or top to bottom.

Airline

Flight PlanePerson

Employs

Supervises

Assigned-to Assigned-to

"Airline Employs Person"

"Plane Assigned-to Flight"

MULTIPLE ASSOCIATIONS BETWEEN TWO CLASSES It is not uncommon to have multiple

associations between two conceptual classes. Consider the following:

Both associations need to be shown separately as they indicate distinctly different relationships.

Flight Airport1* Flies-to

1* Flies-from

1

1*

*

ASSOCIATIONS AND IMPLEMENTATIONS Associations in a domain model represent

relationships that are meaningful in the real world.

Not all associations in a domain model need to be implemented in software.

DOMAIN MODEL FOR POS SYSTEM (WITH ASSOCIATIONS)

Register

ItemStore

Sale

Payment

SalesLineItem

CashierCustomer

ProductCatalog

ProductSpecification

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

3 Works-on

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1--

1

1

ADDING ATTRIBUTES

Besides associations, we also need to identify attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development.

ATTRIBUTE

An attribute is a logical data value of an object.

A domain model should include attributes for which the requirements (such as use cases) suggest or imply a need to remember information.

For example, a receipt normally includes the date and time of sale.

NOTATION FOR ATTRIBUTES

The type of an attribute is optional.

Saledate : Datetime attributes

GUIDELINES FOR IDENTIFYING ATTRIBUTES The attributes in a domain model should

preferably be simple attributes or data types.Examples of attribute types: Boolean, Date, Number, String (Text), Time Address, Colour, PhoneNumber,

SocialSecurityNumber, UniversalProductCode, Postcode

Consider the following:

Cashier

namecurrentRegister

Cashier

name

Register

numberWorks-on

1 1

This is not a "simple"attribute

Relate conceptual classes with an association, not with an attribute.

Flight

destination

destination is acomplex concept

AirportFlight

* 1* 1

Flies-to

ATTRIBUTES AS FOREIGN KEYS Do not use attributes as foreign keys to relate

conceptual classes (as typically done in relational database designs).

Use associations to relate those classes.

Register

numbercashierID

Register

number

Cashier

name11

Works-on

11

DOMAIN MODEL FOR POS SYSTEM

Register

ItemStore

Sale

Payment

SalesLineItem

CashierCustomer

ProductCatalog

ProductSpecification

Stocks

*

Houses

1..*

Used-by

*

Contains

1..*

Describes

*

Captured-on

Contained-in

1..*

Records-sale-of

0..1

Paid-by Is-for

Logs-completed

*

3 Works-on

1

1

1 1..*

1

1

1

1

1

1

1

0..1 1

1--

1

1

quantity

dateTimetotal

amountTendered

nameaddress

number

itemIDdescriptionprice

number