Object-Oriented Analysis

& Design
面向对象的分析与设计

1
Part 3: Elaboration Iteration 1 Basics

• Chapter 8 . Iteration 1basics

• Chapter 9 . Domain Models
• Chapter 10 . System Sequence Diagrams
• Chapter 11 . Operation Contracts
• Chapter 12 . Requirements to Designiteratively
• Chapter 13 . Logical Architecture and UML Package
Diagrams
• Chapter 14 . On to Obiect Design

2
Chapter 9 . Domain Models

• Obiectives：
• Identify conceptual classes related to the current iteration
• Create an initial domain mode
• Model appropriate attributes and associations

3
Introduction

• A domain model is the most important and classic model

in OO analysis.
• It illustrates noteworthy concepts in a domain. It can act as
a source of inspiration for designing some software objects
and will be an input to several artifacts explored in the case
studies.
• In an agile modeling and UP spirit, a domain model is
optional.
• The related use case concepts and insight of experts will
be input to its creation.

4
 Sample UP Artifact Relationships

Domain Model

Sale 1 1..* Sales ...

Business LineItem
Modeling date
quantity
...
...

conceptual classes – the domain objects,

elaboration of
terms, concepts attributes, and
some terms in
attributes, associations that undergo
the domain
associations state changes
model
Use-Case Model
conceptual
Process Sale Operation:
enterItem(…) Cashier: …
classes in the
Item ID: … domain inspire
1. Customer
arrives ... Post-conditions: ... the names of
Requirements -...
2. ... some software
3. Cashier enters classes in the
Operation Contracts Glossary
item identifier.
4....
design

Use Case Text

Design Model

: Register : ProductCatalog : Sale

enterItem
Design (itemID, quantity)

spec = getProductSpec( itemID

)
addLineItem( spec,
quantity )

...
5
A Domain Model Example

concept Sales
Item
or domain LineItem Records-sale-of
object quantity 1
0..1

1..* *
Stocked-in
association Contained-in

1 1

Sale Store
attributes date address
time name
1
1
1
Houses
Paid-by 1..*

1 Register
Captured-on
Payment
1
amount

6
Domain Models within the UP

• The UP Domain Model is usually both started and

completed in the elaboration phase.

7
Domain Model

• Domain model
• illustrates meaningful conceptual classes in the problem domain
• is a source of inspiration for design software objects
• A domain model can be illustrated by a set of UML class diagrams
• Domain objects or conceptual classes
• associations between conceptual classes
• attributes of conceptual classes
• Identify a rich set of objects or conceptual classes is at the
heart of OOA.
If it is done with skill and short time investment (no more than a few
hours in each early iteration) , it usually pays off during design ,
when it supports better understanding and communication

8
Domain Model

• Key idea: Domain Model – A Visual Dictionary of Abstractions

• only the noteworthy concepts are included
• a simplified representation of the domain

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

date it is a not a picture of

time a software class

9
Domain Models Are Not Models of Software
Components

SalesDatabase software artifact; not part

void of domain model
a

Sale
void software class; not part
a date of domain model
time

print()

the following elements are not suitable in a domain model：

• Software artifacts , such as a window or a database , unless the domain
being modeled is of software concepts , such as a model of graphical user
interfaces.
• Responsibilities or methods.
10
 Conceptual Classes

Sale concept's symbol

date
time Symbol:words or images representing a conceptual class

"A sale represents the event concept's intension

of a purchase transaction. It
has a date and time."
Intension: the definition of a conceptual class

sale-1

sale-2 concept's extension

sale-3

sale-4
Extension:the set of examples to which the conceptual
class applies
11
 Conceptual Classes

• Domain Models and Decomposition

• “Divide-and-conquer” is a basic strategy in software engineering in order to
divide the problem space into comprehensible units

• A conceptual distinction between OOA and structured analysis is:

division by conceptual classes (objects) rather than by functions

• Conceptual Classes in the Sale Domain

Store Regist er Sale

12
Motivation : Why Create a Domain Model ?

• Lower Representational Gap with OO Modeling.

• This is a key idea in OO.
• Use software class names in the domain layer inspired
from names in the domain model, with objects having
domain-familiar information and responsibilities.
• This supports a low representational gap between our
mental and software models .

13
Lowering the Representational Gap

UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.

Payment Sale
A Payment in the 1 Pays-for 1
amount date
Domain Model is a time
concept, but a Payment
in the Design Model is a inspires
objects
software class. They are and
not the same thing, but names in

the former inspired the

naming and definition of Sale
Payment
the latter. amount: Money 1 Pays-for
1 date: Date
startTime: Time
getTotal(): Money
This reduces the getBalance(): Money
...
representational gap.
UP Design Model
This is one of the big
The object-oriented developer has taken inspiration
ideas in object
from the real world domain in creating software
technology.
classes.

Therefore, the representational gap between how stakeholders conceive the domain,
and its representation in software, has been lowered.
14
How to Create a Domain Model?

1. List the candidate conceptual classes using the Conceptual

Class Category List and noun phrase identification
techniques related to the current requirements under
consideration

2. Draw them in a domain model in a UML class diagram

3. Add the associations necessary to record relationships for

which there is a need to preserve some memory

4. Add the attributes necessary to fulfill the information

requirements

15
How to find Conceptual Classes?

Three strategies to identify conceptual classes

1. Reuse or modify existing models. There are published , well-
crafted domain models and data models( which can be
modified into domain models ) for many common domains,
such as inventory, finance, health, and so forth.
2. Use a category list
3. Identify noun phrases from Use Case text

16
Well-crafted Domain Models

17
Well-crafted Domain Models

18
Well-crafted Domain Models

19
Well-crafted Domain Models

20
Well-crafted Domain Models

21
Well-crafted Domain Models

22
Well-crafted Domain Models

23
Use a Conceptual Class Category List

Conceptual Class Category Examples

business transactions Sale, Payment

Guideline: there are critical (they involve Reservation

money), so start with transactions
transaction line items SalesLineItem

Guideline: transactions often come with related

line items, so consider these next
Product or service related to a transaction Item
or transaction line item
Flight, Seat, Meal
Guideline: tranactions are for something (a
product or service). Consider these next
Where is the transaction recorded? Register, Ledger

Guideline: important FlightManifest

24
Use a Conceptual Class Category List

Conceptual Class Category Examples

Roles of people or organizations related to Cashier, Customer, Store,
the transaction; actors in the use case MonopolyPlayer,
Passager, Ariline
Guideline: we usually need to know about the
parties involved in a transaction.
Place of transaction; place of service Store

Airport, Plane, Seat

Noteworthy events, often with a time or Sale, Payment,
place we need to remember MonopolyGame,
Flight
Physical objects Item, Register,
Board, Piece, Die,
Guideline: this is especially relevant when Airplane
creating device-control software, or simulations

25
Use a Conceptual Class Category List

Conceptual Class Category Examples

Description of things ProductDescription,
FlightDescription
Catalogs ProductCatalog,

Guideline: descriptions are often in a catalog FlightCatalog

Containers of things (physical or Store, Bin,
information) Board, Airplane
Things in a container Item, Square (in a board), Passager
Records of finance, work, contracts, legal Receipt, Ledger,
matters MaintenaceLog
Financial instruments Cash, Check, LineOfCredit,
TicketCredit
Schedules, manuals, documents that are DailyPriceChangeList
regularly referred to in order to perform
work RepairSchedule

26
 Finding Conceptual Classes with Noun
Phrase Identification

Main Success Scenario (or Basic Flow):

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. Price calculated from a set of price rules
Cashier repeats steps 2-3 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 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)

27
Finding Conceptual Classes with Noun
Phrase Identification
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
…

Candidate Conceptual Classes for the Sales Domain

• The list is constrained to the current iterations
Register ProductSpecification
Item SalesLineItem
Store Cashier
Sale Customer
Payment Manager
ProductCatalog 28
Initial POS Domain Model

Register Item Store Sale

Sales
Cashier Customer Ledger
LineItem

Cash Product Product

Payment Catalog Description

29
Initial Monopoly Game Domain Model

30
Domain Modeling Guidelines (cont.)

• Agile Modeling maintain the Model in a Tool ?

• in agile modeling, the purpose of creating a domain model
is to quickly understand and communicate.
• Perfection is not the goal.
• agile models are usually discarded shortly after creation.
• From this viewpoint, there is no motivation to maintain or
update the model.
• Often the evolving domain layer of the software hints at
most of the noteworthy terms, and a long-life OO analysis
domain model doesn't add value.

31
Domain Modeling Guidelines (cont.)

• On Naming and Modeling Things: The Mapmaker Strategy

or Use the Domain Vocabulary strategy.
• Use the existing names in the territory

• Exclude irrelevant features

• Do not add things that are not there

• How to Model the Unreal World?

• Some software systems are not natural or business domains,

telecommunications system is an example.

• It requires a high degree of abstraction, listening carefully to the

core vocabulary and concepts that domain experts use.

• For example, Message , Connection , Port , Dialog , Route ,

Protocol are some candidate conceptual classes related to the
domain of a telecommunications.
32
Domain Modeling Guidelines (cont.)

• A Common Mistake in Identifying Conceptual Classes

• represent something as an attribute when it should have been a
concept.
• a rule of thumb: if we do not think of some conceptual class X as a
number or text in the real world, X is probably a conceptual class,
not an attribute

Sale Sale Store

or... ?
store phoneNumber

Flight Flight Airport

or... ?
destination name

33
When to Model with 'Description' Classes?

• A description class contains information that describes something

else.
• 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 (for example, Item) results in
a loss of information that needs to be maintained, but was incorrectly
associated with the deleted thing.
• It reduces redundant or duplicated information
Item
description Worse
price
serial number
itemID

ProductSpecification
Item
description Describes Better
price
1 * serial number

itemID
34
Descriptions in the Airline Domain
• Consider an airline company that suffers a fatal crash of one of its planes.
Assume that all the flights are cancelled for six months pending completion of an
investigation. Also assume that when flights are cancelled , their corresponding
Flight software objects are deleted from computer memory . Therefore , after the
crash, all Flight software objects are deleted.

Flight
Airport
date Flies-to Worse
number
time
* 1 name

Flight
Better
date Described-by FlightDescription

time * 1 number
*
Describes-flights-to
1

Airport
name 35
 Associations

• It's useful to find and show associations that are needed to satisfy the
information requirements of the current scenarios under development,
and which aid in understanding the domain.
• An association is a relationship between classes (more precisely,
instances of those classes) that indicate some meaningful and
interesting connection.
• In the UML , associations are defined as the semantic relationship
between two or more classifiers that involve connections among their
instances.
association

Records-current
Register Sale
1 1

36
 When to show an association

• Criteria for Useful Associations:

• Associations for which knowledge of the relationship needs to
be preserved for some duration (“need-to-know”
association)
• Associations derived from the Common Association List
• For example, we need to remember what Saleslineitem instances
are associated with a Sale instance, otherwise it would not be
possible to reconstruct a sale, print a receipt, or calculate a sale
total.
• In the monopoly domain, we need to remember what Square a
Piece ( or Player ) is on, the game doesn't work if that isn't
remembered. Likewise, we need to remember what Piece is
owned by a particular Player.

37
The UML Association Notation

• An association is represented as a line between classes with a

capitalized association name .

-"reading direction arrow"

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

Records-current ►
Register Sale
1 0..1

association name multiplicity

38
 How to Name an Asociation in UML

• Name an association based on a TypeName-VerbPhrase-TypeName format

where the verb phrase create a sequence that is readable and meaningful in
the model context.
Two common and equally legal formats for a
Store
compound association name:
1
• Records-current
Contains
• RecordsCurrent
1..*
Captures Paid-by
Register Sale Payment
1 1..* 1 1

Airline

1
Employs

1..*
Assigned-to ◄ Assigned-to
Person Flight Plane
1 * * 1
1 *

S uperv is es 39
 Roles

• Each end of an association is called a role, roles may

optionally have:
• multiplicity expression
• name
• navigability
• Multiplicity defines how many instances of a class A can be
associated with one instance of a class B.

Stocks
Store Item
1 *

multiplicity of the role

40
Multiplicity

* T
zero or more;
"many"

1..*
T one or more

1..40
T one to 40

5
T exactly 5

3, 5, 8
T exactly 3, 5, or 8

41
 Multiplicity

• The multiplicity value communicates how many instances can be validly

associated with another,at a particular moment, rather than over a span of
time.
• For example , it is possible that a used car could be repeatedly sold back to
used car dealers over time. But at any particular moment ,the car is only
Stocked-by one dealer. The car is not Stocked-by many dealers at any
particular moment .

The choice usually

depends on why we
are building the
software

42
Multiple Associations Between Two Types

• Two classes may have multiple associations between them in

a UML class diagram

* Flies-to 1

Flight Airport
Flies-from
* 1

43
 Finding Association with a Common
Association List

Category Examples
A is a transaction related to another CashierPayment – Sale
transaction B Cancellation - Reservation
A is a line item of a transaction B SalesLineItem - Sale
A is a product or service for a Item – SalesLineItem (or Sale)
transaction (or line item) B Flight - Reservation
A is a role related to a transaction B Customer – Payment
Passenger - Ticket
A is a physical or logical part of B Drawer – Register
Square – Board
Seat - Airplane
A is physically or logically contained in / Register – Store
on B Item –Self
Square – Board
Passenger - Airplane

44
Finding Association with a Common Association
List
Category Examples
A is a description for B ProductDescription – Item
FlightDescription - Flight
A is known / logged / recorded / Sale – Register
reported / captured in B Piece – Square
Reservation – FlightManifest
A is a member of B Cashier – Store
Player – MonopolyGame
Pilot - Airline
A is an organizational subunit of B Department – Store
Maintenance - Airline
A uses or manages or owns B Cashier – Register
Player – Piece
Pilot - Airplane
A is next to B SalesLineItem – SalesLineItem
Square – Square
City - City
45
Associations in the Domain Model
Records-sale-of

Described-by
1

Product
Product Spec ific ation
C atalog Contains
1 1..*

1
0..1
* Used-by
Describes
Sales * *
LineItem Store
Item
Stoc k s
1 1
* 1..*
1..*
Logs- 1 Houses
Contained-in
c om pleted
1 1.. *

Sale * R egis ter

Manager
C aptured-on Started-by
1 1 1 1

1
1
1 Initiated-by 1
Paid-by Records-sales-on
1 1 1
Initiated-by
Pay m ent Customer Cashier
1
46
Associations in the Domain Model

47
Associations in the Domain Model

48
 Attributes

• An attribute is a logical data values of an object.

• UML Attribute Notation

attributes
Sale
dateTime
/ total : Money derived
attribute

49
 Attributes

• The full syntax for an attribute in the UML is :

• visibility name: type multiplicity =default < property-string >

Sale Math Person

- dateTime : Date + pi : Real = 3.14 {readOnly} firstName
- / total : Money middleName : [0..1]
lastName
Private visibility Public visibility readonly
attributes attribute with initialization Optional value

• As a convention , most modelers will assume attributes have private

visibility ( - ) unless shown otherwise.

50
 Where to Record Attribute Requirements

• Attributes are very important requirements.

• Some modellers accept leaving such specifications only in the domain model,
but it's not a proper place to record attribute requirements, as people tend to
not look at the domain model in detail or for requirements guidance.
• Placing all such attribute requirements in the UP Glossary, which serves as a
data dictionary. Perhaps you've spent an hour sketching a domain model with
a domain expert; afterwards, you can spend 15 minutes looking through it
and transferring implied attribute requirements into the Glossary.
• Another alternative is to use a tool that integrates UML models with a data
dictionary; then all attributes will automatically show up as dictionary
elements.

51
What are Suitable Attribute Types

Focus on Data Type Attribute in the Domain Model

• The attributes should be “primitive” data types
• Ex. Numbers, Booleans, Date, String, Time, Character, …
• The attributes, normally, should not be a complex domain concept
• Ex. Sale, Airport
• A common mistake is modeling a complex domain concept as an attribute

Cashier not a "data type" attribute

Worse
name
currentRegister

Cashier Register
1 Uses 1
Better
name number

52
Data Types

• Data Types: a set of values for which unique identity is not meaningful
(in the context of our model of system)
• Separate instances of the Number 5
• Separate instances of the String “cat”
• Separate instances of PhoneNumber that contains the same
number
• Separate instances of Address that contain the same address
• Attributes should generally be data types

53
 When to Define New Data Type Classes

• Represent what may initially be considered a primitive data type (such as

a number or string) as a non-primitive class if:
• It is composed of separate sections:
• phone number, name of person
• there are operations usually associated with it, such as parsing or
validation
• social security number (SSN)
• it has other attributes
• promotional price could have a start (effective) date and end date
• it is a quantity with a unit
• payment amount has a unit of currency
• It is an abstraction of one or more types with some of these qualities
• UPC – Universal Product Code

54
Where to Illustrate These Data Type Classes?

• Since ItemID is a data type, it can be shown in the attribute compartment

of the class box
• If ItemID is a new type with its own attributes and associations, it can be
shown as a conceptual class in its own box
• It depends what you want to emphasize in the diagram

ItemID Address
Product 1 1 id 1 1
Store street1
OK Description
manufacturerCode street2
countryCode cityName
...

Product Store
Description
OK address : Address
itemId : ItemID

55
Modeling Attribute Quantities and Units

Payment not useful

amount : Number

Payment Quantity Unit

Has-amount Is-in
* 1 amount : Number * 1 ...

Payment quantities are pure data

values, so suitable to show
amount : Quantity better
in attribute section

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

56
Attributes in the NextGen Domain Model

Register Item Store Sale

address : Address date : Date
name : Text time : Time

Sales Cashier Customer Manager

LineItem
quantity : Integer

Product
Payment Product
Specification
amount : Money Catalog
description : Text
price : Money
id: ItemID

57
NextGen POS Domain Model (with attributes)
Records-sale-of

Product
Ledger Product Description
Catalog Contains
1 itemID
1..*
description
1 1
1 price
0..1 Records-
Used-by Describes
accounts-
Sales for * *
LineItem Store
Item
Stocks
quantity 1 name
address
1
* 1..*
1..*
Contained-in 1 Houses
Logs-
1 completed 1..*

Sale * Register

dateTime Captured-on
id
0..1 1
/ total
1
1 1
Is-for Works-on
Paid-by

1 1 1

CashPayment Customer Cashier

amountTendered id
58
Monopoly Game Domain Model (with attributes)

59
Conclusion

• Is the Domain Model Correct ?

• There is no such thing as a single correct domain model.
• All models are approximations of the domain we are attempting
to understand;
• Domain model is primarily a tool of understanding and
communication among a particular group.
• A useful domain model captures the essential abstractions and
information required to understand the domain in the context of
the current requirements, and aids people in understanding the
domainits concepts , terminology , and relationships.

60
Homework

• 进行本组目标系统领域模型的建模。

61
Thanks