An Introduction to Object-Oriented

Analysis and Design and the Unified

Process
Applying UML and Patterns, 3rd
ed. Craig Larman, pp. 100 196
Kakarontzas George
gkakaron@teilar.gr
Other Requirements
Use cases document most of the requirements
(mostly functional requirements)
Non-functional requirements are usually
captured in UP in the Supplementary
Specification
Other documents include:
The Glossary: terms and definitions
The Vision: an executive summary. Communicates
the big ideas behind the project.
The Business Rules (or Domain Rules): rules
transcending any particular application (e.g. tax rules)
Supplementary Specification
When first writing a use case, non-functional
requirements (the URPS in FURPS) should
be informally written in the Special
Requirements section
After that informal step they should be moved to
the Supplementary Specification in order to be
analyzed more thoroughly and have all non-
functional requirements kept in on place, for
reference during architectural analysis and
design.
On to Elaboration
Elaboration follows Inception and is the
second phase of the UP
During Elaboration:
the core, risky software architecture is
programmed and tested
the majority of requirements are discovered
and stabilized
the major risks are mitigated or retired
Key Ideas and Best Practices in
Elaboration
Do short timeboxed risk-driven iterations
Start programming early
Adaptively design, implement, and test the core
and risky parts of the architecture
Test early, often, realistically
Adapt based on feedback from tests, users,
developers
Write most of the use cases and other
requirements in detail, through a series of
workshops, once per elaboration iteration
UP Artifacts that may start in Elaboration
Artifact Comment

Domain Model This is a visualization of the domain concepts; it is similar to

a static information model of the domain entities.

Design Model This is the set of diagrams that describes the logical design.
This includes software class diagrams, object interaction
diagrams, package diagrams, and so forth.
Software A learning aid that summarizes the key architectural issues
Architecture and their resolution in the design. It is a summary of the
Document outstanding design ideas and their motivation in the
system.
Data Model This includes the database schemas, and the mapping
strategies between object and non-object
representations.
Use-Case A description of the user interface, paths of navigation,
Storyboards, usability models, and so forth.
UI Prototypes
You didnt understand elaboration
when
It is more than "a few" months long for most projects.
It only has one iteration (with rare exceptions for well-
understood problems).
Most requirements were defined before elaboration.
The risky elements and core architecture are not being
tackled.
It does not result in an executable architecture; there is
no production-code programming.
It is considered primarily a requirements or design
phase, preceding an implementation phase in
construction.
You didnt understand elaboration
when (cont.)
There is an attempt to do a full and careful
design before programming.
There is minimal feedback and adaptation; users
are not continually engaged in evaluation and
feedback.
There is no early and realistic testing.
The architecture is speculatively finalized before
programming.
It is considered a step to do the proof-of-concept
programming, rather than programming the
production core executable architecture.
 Use Case Ranking
Use cases are ranked for implementation.
Earlyiterations will implement high ranking use cases
and use case scenarios.
For example:
Requirement Comment
(Use Case
Rank or Feature)
High Process Sale Scores high on all rankings.
Logging Pervasive. Hard to add late.

Medium Maintain Users Affects security subdomain.

Low
Domain Modelling
Domain modelling is concerned with
identifying conceptual classes related to
the current iteration.
The initial domain model is created during
the first iteration of the elaboration phase.
The domain model contains the
conceptual classes as well as appropriate
attributes and associations.
 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 associations some terms in
attributes, associations that undergo state changes the domain
model
Use-Case Model

Process Sale Operation: enterItem() conceptual

Cashier: classes in
1. Customer arrives Item ID: the
Post-conditions:
... ... domain
Require- -...
2. ... inspire the
ments
3. Cashier enters names of
Operation Contracts Glossary some
item identifier.
4.... software
classes in
Use Case Text the design

Design Model

: Register : ProductCatalog : Sale

enterItem
(itemID, quantity)
Design
spec = getProductSpec( itemID )

addLineItem( spec, quantity )

...
An Example Domain Model for the
POS System
concept Sales
Item
or domain LineItem Records-sale-of
object 1
quantity 0..1

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

1 1

Sale Store

attributes date address

time 0..1 name
1
1
Houses
Paid-by 1..*

1 Register
Captured-on
Payment
1
amount
Domain Model Definition
In the UP, the term "Domain Model" means a
representation of real-situation conceptual classes, not
of software objects. The term does not mean a set of
diagrams describing software classes, the domain layer
of a software architecture, or software objects with
responsibilities.
Domain model depicts:
Domain objects (or conceptual classes)
Associations between conceptual classes
Attributes of conceptual classes
It doesnt contain operations
It serves as a visual dictionary of the noteworthy
abstractions, domain vocabulary, and information
content of the domain.
Elements not Suitable
for a Domain Model
A domain model is not a software representation, and some
elements are not appropriate for it:
Software classes (such C# or Java classes)
Elements representing artifacts related to the implementation of the
system (e.g. a database, or a window) unless the domain being
modeled is of software concepts (e.g. a Graphical User Interface library)
Responsibilities or methods
SalesDatabase
oid
software artifact; not part
a v of domain model

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

print()
What are Conceptual Classes?
Sale concept's symbol

Formally, a conceptual date

class may be considered
in terms of its symbol,
intension, and extension:
time
"A sale represents the event
of a purchase transaction. It
concept's intension

Symbol words or images has a date and time."

representing a conceptual
class.
Intension the definition of sale-1

a conceptual class. sale-3

sale-2 concept's extension

Extension the set of

sale-4
examples to which the
conceptual class applies.
Lower Representation Gap
There are two reasons to create a domain
model:
The first is getting to know the domain during early
elaboration iterations, understanding the concepts
involved and their relationships
The second is that the domain model inspires the
software classes of the domain layer in the design
model. This prevents software from being far away
from the reality of the domain. The similarity of
concepts in the domain layer with concepts of the
domain is known as lower representation gap.
Lower Representation Gap
Example UP Domain Model
Stakeholder's view of the noteworthy concepts in the domain.

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

getBalance(): Money getTotal(): Money

...

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
1. Find conceptual classes by
a) Reusing existing domain models
b) Using a category list
c) Identification of noun phrases
2. Draw the identified conceptual classes
as UML classes in a class diagram
3. Add to conceptual classes associations
and attributes (but not methods)
Common Categories of
Domain Classes
Business transactions: Sale, Payment
Transaction line items: SalesLineItem
Product or service related to a transaction
line item: Item
Where is the transaction recorded?
Register
Roles of people or organization related to
the transaction; actors in the use case:
Cashier, Customer, Store
Common Categories of
Domain Classes (cont.)
Noteworthy events, often with a time or
place, we need to remember: Sale,
Payment
Physical objects: Item, Register
Descriptions of things: ProductDescription
Catalogs: ProductCatalog
Containers of things (physical or
information): Store
Common Categories of
Domain Classes (cont.)
Things in a container: Item
Other collaborating systems:
CreditAuthorizationService
Records of finance, work, contracts, legal
matters: Receipt, Ledger
Financial instruments: Cash, Check
Schedules, manuals, documents that are
regularly referred to in order to perform
work: DailyPriceChangeList
Noun Phrases Identification
Identify nouns and noun phrases in a
textual description of the domain and
consider them as candidate conceptual
classes and attributes
Caution:
Mechanical noun-to-class mapping isnt
possible
Natural language is ambiguous
 Using Use Case Text Descriptions to
Identify Nouns and Noun Phrases
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
information 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).
Drawing Conceptual Classes as
UML Classes
After discovering the conceptual classes we can
start creating our domain model, as in the figure
which contains the conceptual classes for the
initial POS domain model.
Register Item Store Sale

Sales
Cashier Customer Ledger
LineItem

Cash Product Product

Payment Catalog Description
Report Objects &
Domain Vocabulary
Dont include Report Objects (e.g. Receipt) since
their information is derived by other conceptual
classes.
Include them only when they have a special role in
terms of business rules (e.g. a receipt entitles the
bearer to return purchased items).
Use the domain vocabulary
Use the existing names in the territory
Exclude irrelevant out-of-scope features
Do not add things that are not there.
Modeling the Unreal World

Modeling the unreal world (e.g.

telecommunication systems):
Requires a high degree of abstraction,
listening carefully to the core vocabulary and
concepts the domain experts use (e.g.
message, connection, port, dialog, route,
protocol are conceptual classes for telecom.
systems)
Is this Concept an Attribute or a
Class?
Attributes vs. Classes: perhaps the most common
mistake is representing something as an attribute when it
should be represented as a class.
Rule: 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
When do we Need Descriptions?
Add a description class (for example, ProductDescription) 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 (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

ProductDescription
Item
description Describes Better
price 1 * serial number
itemID
 Another Description Example
Assume we have an Flight
airline with a number date Flies-to
Airport
Worse

of flights. We use a number

time * 1 name

FlightDescription to
describe the service
of a particular flight
(i.e. its route) Flight
Described-by
FlightDescription Better
date
regardless of whether time * 1 number

this particular flight is *

Describes-flights-to
scheduled at the 1
moment or not. Airport

name
Associations in Domain Models
We use associations in domain models in order
to:
Denote a relationship that needs to be preserved for
some duration (need-to-remember associations)
Denote associations derived from the Common
Associations List (i.e. common categories of
associations)
Example:
We need to remember what SalesLineItem instances
are associated with a Sale, otherwise it would not be
possible to reconstruct a sale, print a receipt, or
calculate a sale total.
Associations on Domain Models
Be parsimonious about adding too many association
lines. Use the need-to-remember criterion and avoid
visual noise.
During domain modeling an association is not a
statement about :
data flows
foreign key relationships
instance variables, or
object connections
It is more a statement a relationship is meaningful in the
real domain (from a conceptual perspective).
Many such relationships, however, will be implemented
in software as paths of navigation and visibility (both in
Design and Data models).
Association Notation
An association is represented as a line between classes
with a capitalized association name.
The ends of an association may contain a multiplicity
expression indicating the number of instances that may
participate in the association.
association

Records-current
Register Sale
1 1
 Direction of Association
The association is inherently bidirectional. This traversal
is purely abstract; it is not a statement about connections
between software entities.
An optional "reading direction arrow" indicates the
direction to read the association name.
-"reading direction arrow"
-it has no meaning except to indicate direction of
reading the association label
-often excluded

Register Records-current Sale

1 0..1

association name multiplicity

Names of Associations
Name an association based on a ClassName-
VerbPhrase-ClassName format where the verb
phrase creates a sequence that is readable and
meaningful.
In naming associations avoid vague phrases or
phrases that dont enhance understanding of the
domain
For example
Sail Paid-by CashPayment
Not Sale Uses CashPayment
In general avoid names such as Has or Uses
UML Roles
Each end of an association is called a
role.
Roles may optionally have:
multiplicity expression
name
navigability
Multiplicity
zero or more;
* T
"many"
Multiplicity defines
how many instances 1..*
T one or more
of a class A can be
associated with one 1..40
T one to 40
instance of a class B
Store Stocks Item 5
1 T exactly 5
*
3, 5, 8
T exactly 3, 5, or 8
multiplicity of the role
Comments on Multiplicity
Multiplicity is about associations at a particular moment
(e.g. a Person can be Married-To one other Person at a
particular moment)
Multiplicity, even in domain models, is affected by the
reason we develop software: for example if a Person
works for one company at a time or many depends on
why were building the software for (tax department or
union).
What is the correct multiplicity for the Store-Item
association in the following figure (1 or 0..1)?

Store Stocks Item

1
or 0..1
*
Multiple Associations Between two
Classes
Two classes may have multiple associations
between them
The following example is from the airlines
domain
* Flies-to 1
Flight Airport
Flies-from
1
*
Finding Associations from a
Common Associations List
Category Examples
A is a transaction related to another transaction B CashPayment-Sale
Cancellation-Reservation
A is a line item of a transaction B SalesLineItem-Sale
A is a product or service for a transaction (or line Item-SalesLineItem
item) B (or Sale)
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/on B Register-Store, Item-Shelf
Square-Board
Passenger-Airplane
Finding Associations from a
Common Associations List (cont.)
Category Examples
A is a description for B ProductDescription-Item
FlightDescription-Flight
A is known/logged/recorded/reported/ Sale-Register
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
Partial POS Domain Model
Records-sale-of

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

Sale * Register
Captured-on
0..1 1

1 1 1
Paid-by Is-for Works-on
1 1 1

CashPayment Customer Cashier

Attributes
Attributes are information
that we need to
remember
The date and the time of a attributes
Sale Sale
The total amount of the
sale dateTime
The ID number of a / total : Money derived
Cashier attribute

In UML class diagrams

attributes are shown in
the second compartment
of the class box.
Full Attribute UML Syntax
The full syntax for an attribute in the UML is:
visibility name : type multiplicity = default {property-string}
Where:
Visibility: Is +, -, # or ~
Name: Is the name of the variable
Type: is a data type such as Integer, Date, String etc.
Multiplicity: is the multiplicity of the variable (e.g.
[0..20])
Default: is the default value for the variable
Property-String: a property of the variable such as
{readOnly} or {frozen}
As a convention, if visibility is missing, it is
assumed to be private (-).
Attribute Examples
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 guideline: put all attributes in the UP

Glossary, in addition to the Domain Model, since
the Glossary serves as the dictionary of the
domain. Alternatively, use a tool that integrates
UML models with a data dictionary.
Derived Attributes
The total attribute in the Sale can be calculated or derived from the
information in the SalesLineItems. When we want to communicate
that 1) this is a noteworthy attribute, but 2) it is derivable, we use the
UML convention: a / symbol before the attribute name.
SalesLineItem Item Each line item records a
0..1 Records-sale-of 1
separate item sale.
For example, 1 tofu package.

SalesLineItem Item
0..1 Records-sale-of 1..* Each line item can record a
group of the same kind of items.
For example, 6 tofu packages.

SalesLineItem Item
0..1 Records-sale-of 1..*
/quantity

derived attribute from

the multiplicity value
Attributes have Data Types
The attributes in a domain model should
preferably be data types. Very common data
types include: Boolean, Date (or DateTime),
Number, Character, String (Text), Time.
Other common types include: Address, Color,
Geometrics (Point, Rectangle), Phone Number,
Social Security Number, Universal Product Code
(UPC), SKU, ZIP or postal codes, enumerated
types
Avoid Showing Complex Concepts
as Attributes
Cashier
Worse not a "data type" attribute
name
currentRegister

Cashier Register
Better 1 Uses 1
name number

Flight destination is a complex

Worse concept
destination

Flight 1 Flies-to 1 Airport

Better
Data Types vs. Classes
Data type is a UML term that implies a set
of values for which unique identity is not
meaningful. By contrast classes represent
entities in which identifying between
different instances is meaningful even
when their value might be the same.
Data types are also immutable
When to Define new Data Types
Represent what may initially be considered a number or
string as a new data type class in the domain model if:
It is composed of separate sections.
phone number, name of person
There are operations associated with it, such as parsing or
validation.
social security number
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.
item identifier in the sales domain is a generalization of types such
as Universal Product Code (UPC) and European Article Number
(EAN)
 Data Types as Classes in the
Conceptual Model
Should we show data types as class boxes in the
domain model?
There is no correct answer: it depends on how the domain model
is being used as a tool of communication, and the significance of
the concept in the domain.
ItemID Address

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

Product Store
Description
OK address : Address
itemId : ItemID
Modeling Quantities and Units
Most numeric quantities should not be represented as plain
numbers. Consider price or weight. Saying "the price was 13" or "the
weight was 37" doesn't say much. Euros? Kilograms?
it is common to require knowledge of the unit to support conversions
Payment
not useful
amount : Number

Payment Quantity Unit

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

Payment quantities are pure data

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

Payment variation: Money is a

specialized Quantity whose
amount : Money unit is a currency
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 1
address * 1..*
1..*
1
Contained-in Logs- Houses
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
 Domain Models Within the UP
Discipline Artifact Incep. Elab. Const. Trans.
Iteration I1 E1..En C1..Cn T1..T2

Business Modeling Domain Model s

Requirements Use-Case Model (SSDs) s r
Vision s r
Supplementary Specification s r
Glossary s r
Design Design Model s r
SW Architecture Document s
Data Model s r

s: start, r: refine
System Sequence Diagrams (SSD)

A system sequence diagram (SSD) is a

fast and easily created artifact that
illustrates input and output events related
to the systems under discussion.
They are used for operation contracts as
well as input to object design.
The UML contains notation in the form of
sequence diagrams to illustrate events
from external actors to a system.
 Sample UP Artifact Relationships
Domain Model

Sale 1 1..* Sales

Business ...
LineItem
Modeling
date
...
... quantity

Vision
Use-Case Model

Process Sale
Process
Sale
use 1. Customer
case arrives ...
Cashier
names 2. Cashier
makes new
sale.
3. ... Glossary
parameters and
Require-
Use Case Diagram Use Case Text return value details
ments
system
events

: System

Operation: : Cashier
enterItem() make Supplementary
system NewSale() Specification
Post-conditions: operations
enterItem
-...
(id, quantity)

Operation Contracts System Sequence Diagrams

starting events to design for

Design Model
: Register : ProductCatalog : Sale

enterItem
Design (itemID, quantity)

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

What is Depicted in an SSD
An SSD shows, for a particular course of
events within a use case, the external
actors that interact directly with the
system, the system (as a black box), and
the system events that the actors
generate. Time proceeds downward, and
the ordering of events should follow their
order in the scenario.
SSD for a Process Sale Scenario
system as black box

the name could be "NextGenPOS" but "System" keeps it

simple

the ":" and underline imply an instance, and are explained in a

later chapter on sequence diagram notation in the UML

external actor to Process Sale Scenario

system

: Cashier :System

makeNewSale

a UML loop loop [ more items ]

interaction enterItem(itemID, quantity)
frame, with a
boolean guard
expression description, total

endSale a message with

parameters
return value(s)
associated with the it is an abstraction
previous message total with taxes
representing the
system event of
an abstraction that entering the
ignores presentation makePayment(amount)
payment data by
and medium some mechanism
the return line is change due, receipt
optional if nothing is
returned
What are SSDs?
Use cases describe how external actors interact with
the software system we are interested in creating.
During this interaction an actor generates system
events to a system, usually requesting some system
operation to handle the event.
The UML includes sequence diagrams as a notation
that can illustrate actor interactions and the operations
initiated by them.
A system sequence diagram is a picture that shows,
for one particular scenario of a use case, the events
that external actors generate, their order, and inter-
system events. All systems are treated as a black box;
the emphasis of the diagram is events that cross the
system boundary from actors to systems.
Guideline: Draw an SSD for a main success scenario
of each use case, and frequent or complex alternative
scenarios.
Why Draw an SSD?
Because it is useful to know precisely what are
the external input events, the system events, to
which the system should react.
System events include:
External events from actors (humans or computers)
Timer events
Faultsor exceptions (usually caused by external
events).
SSDs depict system behavior in terms of what
the system does, not how it does it. System
behavior is also captured by use cases and
operation contracts (to be discussed later).
Relation between SSDs and
UML Sequence Diagrams
The UML does not define something
called System Sequence Diagrams. We
use the general UML sequence diagram
notation to create system sequence
diagrams.
The term system in SSDs is used to
emphasize the application of the UML
sequence diagram to systems viewed as
black boxes.
 Relationship Between SSDs and
Use Cases
Process Sale Scenario
: Cashier :System

makeNewSale
Simple cash-only Process Sale scenario:
loop [ more items ]
1. Customer arrives at a POS checkout enterItem(itemID, quantity)
with goods and/or services to purchase.
2. Cashier starts a new sale.
3. Cashier enters item identifier. description, total
4. System records sale line item and
presents item description, price, and
running total.
Cashier repeats steps 3-4 until indicates
done. endSale
5. System presents total with taxes
calculated.
6. Cashier tells Customer the total, and total with taxes
asks for payment.
7. Customer pays and System handles
payment. makePayment(amount)
...

change due, receipt

How to name System Events and
Operations?
System events should be expressed at the
abstract level of intention rather than in
terms of the physical input device.
Which is better: scan(itemID) or
enterItem(itemID)?
TheenterItem name is better since it
communicates intention rather than the input
device.
SSDs and the UP
UP doesnt mention explicitly SSDs, but you can
use them since the UP is very flexible allowing
any useful technique to be applied in its context.
Most SSDs are created during elaboration,
when it is useful to identify the details of the
system events to clarify what major operations
the system must be designed to handle, write
system operation contracts, and possibly to
support estimation
Operation Contracts
Operation contracts use a pre- and post-
condition form to describe detailed
changes to objects in a domain model, as
the result of a system operation.
Although operation contracts are usually
used in a Design Model for object
methods, they can also be used in a
Domain Model as contracts of high-level
system operations.
 Sample UP Artifact Relationships
Domain Model

Sale 1 1..* Sales

Business ...
LineItem
Modeling
date
...
... quantity

Vision
Use-Case Model

Process Sale
Process
Sale
use 1. Customer
case arrives ...
Cashier
names 2. ...
3. Cashier
enters item
identifier. Glossary
Require-
Use Case Diagram Use Case Text
ments
ideas for system
the domain events requirements
the post-
objects, that must be
conditions
attributes, satisfied by
: System
and the software
associations Operation: : Cashier
that undergo enterItem() make Supplementary
changes system NewSale() Specification
Post-conditions: operations
enterItem
-...
(id, quantity)

Operation Contracts System Sequence Diagrams

starting events to
design for, and
more detailed
requirements that Design Model
must be satisfied : Register : ProductCatalog : Sale
by the software
enterItem
Design (itemID, quantity)

spec = getProductSpec( itemID )

addLineItem( spec, quantity )

What are the Sections of a
Contract?
Operation: Name of operation, and parameters
Cross References: Use cases this operation
can occur within
Preconditions: Noteworthy assumptions about
the state of the system or objects in the Domain
Model before execution of the operation. These
are non-trivial assumptions the reader should be
told.
Postconditions: This is the most important
section. The state of objects in the Domain
Model after completion of the operation.
Example: the enterItem system
operation contract
Operation: enterItem(itemID: ItemID, quantity:
integer)
Cross References: Use Cases: Process Sale
Preconditions: There is a sale underway.
Postconditions:
A SalesLineItem instance sli was created (instance
creation).
sli was associated with the current Sale (association
formed).
sli.quantity became quantity (attribute modification).
sli was associated with a ProductDescription, based
on itemID match (association formed).
Postcondition Definition
The postconditions describe changes in
the state of objects in the domain model.
Domain model state changes include:
instances created or deleted
associations (or to be precise, UML links
which are instantiations of associations)
formed or broken, and
attributes changed value.
Discussion on Postoconditions
Postconditions are not actions to be performed during
the operation; rather, they are observations about the
domain model objects that are true when the operation
has finished, after the smoke has cleared.
Breaking associations is rare
Example: Operation for the deletion of line items
Instance deletions are most rare:
Example: after a person has declared bankruptcy and seven or
ten years have passed, all records of their bankruptcy
declaration must be destroyed, by law.
Note: this is a conceptual perspective, not
implementation. These are not statements about freeing
up memory in a computer occupied by software objects.
Why Postconditions
Postconditions are only necessary when the
outcome of a system operation is not clear from
the use case description.
We could put these conditions in the use case, but
that would make them too verbose.
Contracts are excellent tool for requirements
analysis: they describe in detail the changes
required by system operations (in terms of the
domain model objects), without describing how
they are achieved.
The Most Common Mistake in
Writing Contracts
The most common problem is forgetting to
include the forming of associations. Particularly
when new instances are created, it is very likely
that associations to several objects need be
established. Don't forget!
For example:
A SalesLineItem instance sli was created (instance
creation).
sli was associated with the current Sale (association
formed).
In this example instance creation is followed by an
association formation.
UML Formal Definitions of
Operations and Methods
An operation is a specification of a
transformation or query that an object may be
called to execute.
[A method is] the implementation of an
operation. It specifies the algorithm or procedure
associated with an operation.
In the UML metamodel operations have a
signature (name and parameters) and are
associated with constraints (preconditions and
postconditions).
The formal language for expressing constraints
in UML is OCL (Object Constraint Language).