Operation Contracts

What Is Design By Contract?

What Are Operation
Contracts?

Design By Contract
Design by Contract (DbC) or Programming by
Contract is an approach to designing computer
software. It prescribes that software designers should
define formal, precise and verifiable interface
specifications for software components, which extend
the ordinary definition of abstract data types with
preconditions, postconditions and invariants. These
specifications are referred to as "contracts", in
accordance with a conceptual metaphor with the
conditions and obligations of business contracts.
Because Design by Contract is a registered trademark
[1] of Eiffel Software in the United States, many
developers refer to it as Programming by Contract,
Contract Programming, or Contract-First development.
(http://en.wikipedia.org/wiki/Design_by_contract)

 DbC is a metaphor on how elements of a software

system collaborate with each other, on the basis of
mutual obligations and benefits. The metaphor comes
from business life, where a "client" and a "supplier"
agree on a "contract" which documents that:
The supplier must provide a certain product
(obligation) and is entitled to expect that the client
has paid its fee (benefit).
The client must pay the fee (obligation) and is
entitled to get the product (benefit).
Both parties must satisfy certain obligations, such as
laws and regulations, applying to all contracts.
(http://www.eiffel.com/developers/design_by_contract.ht
ml)

Hoare Logic
Design by Contract has its routes in Hoare logic.
The central feature of Hoare logic is the Hoare
triple. A triple describes how the execution of a
piece of code changes the state of the
computation. A Hoare triple is of the form:
{P} C {Q}
where P and Q are assertions and C is a
command. P is called the precondition and Q the
postcondition: if the precondition is met, the
command establishes the postcondition.
Assertions are formulas in predicate logic.
(http://en.wikipedia.org/wiki/Hoare_logic)

Partial and total

correctness
Standard Hoare logic proves only partial
correctness, while termination would have
to be proved separately. Thus the intuitive
reading of a Hoare triple is: Whenever P
holds of the state before the execution of
C, then Q will hold afterwards, or C does
not terminate. Note that if C does not
terminate, then there is no "after", so Q
can be any statement at all. Indeed, one
can choose Q to be false to express that C
does not terminate.
(http://en.wikipedia.org/wiki/Hoare_logic)

Contracts in human affairs

(contract analogy slides by Prof. C. Constantinides)

Example: The railway passengers contract

Obligations
Client:
The passenger

Benefits

Arrive at the departure

station on time, take
the right train and get
off at the right station.

Supplier:
The railway
company
7

Obligations
Client:
The passenger

Supplier:
The railway
company

Arrive at the departure

station on time, take
the right train and get
off at the right station.

Benefits

Obligations of client,
are suppliers benefits!

No need to make sure

that passengers get to th
departure station on tim
take the right train or ge
8
off at the right station.

Obligations

Benefits

Client:
The passenger

Arrive at the departure

station on time, take
the right train and get
off at the right station.

Supplier:
The railway
company

Convey passenger
No need to make sure
from departure station that passengers get to th
to destination station. departure station on tim
take the right train or ge
9
off at the right station.

Client:
The passenger

Supplier:
The railway
company

Obligations

Benefits

Arrive at the departure

station on time, take
the right train and get
off at the right station.

No need to drive or
navigate from departure
station to destination
station.Obligations of supplie
are clients benefits!

Convey passenger
No need to make sure
from departure station that passengers get to th
to destination station. departure station on tim
take the right train or ge
10
off at the right station.

Class B

Class A
client

supplier

DbC views the relation between a class and its client(s) as a formal
agreement, or contract, expressing each partys benefits and
obligations.

Without such a precise definition we cannot have a significant

degree of trust in large software systems.

Contract violations lead to run-time errors, i.e. exceptions.

(slide by Prof. C. Constantinides)

11

Benefits and obligations

Class B

Class A
client

supplier

The clients obligations are the suppliers benefits and

vice-versa.
Classes/methods can be clients and suppliers too.
(slide by Prof. C. Constantinides)
12

Defensive programming
Design by Contract replaces defensive
programming by requiring that both parties
meet certain expectations. Therefore it is
no longer necessary to code against all
possible inputs.
The called method or class can rely on the
caller to meet the contract for inputs.
The caller can rely on the called method or
class to return values in keeping with the
contract.

Operational Contracts
For the purposes of this course you
will not be required to do design by
contract but you are expected to be
able to write operational contracts in
respect of system operations for your
project.
The same contract metaphor applied
in design by contract applies to the
writing of operational contracts

One-To-One Mapping?
If your System Sequence Diagram correctly
modeled system operations then each step
in the SSD (arrow on the graph) will map to
exactly one operational contract.
While this one-to-one mapping is the
theoretical ideal it is expected that in reality
the process of design will normally include a
great deal of discovery of new
requirements/operations and thus true oneto-one mapping is expected to be rare.

Use-Case Model: Adding Detail with

Operation Contracts
Contracts are documents that describe system
behavior.
Contracts may be defined for system operations.
Operations that the system (as a black box) offers in its public
interface to handle incoming system events.

The entire set of system operations across all use

cases, defines the public system interface.

(slide by Prof. C. Constantinides)

16

System operations and the system

interface

System

In the UML the system as

a whole can be
represented as a class.

makeNewSale()
addLineItem(id, quantity)
Contracts are written for
endSale()
makePayment(cashTendered) each system operation to

describe its behavior.

(slide by Prof. C. Constantinides)

17

Example contract: addLineItem

Contract CO2: addLineItem
Operation:
addLineItem (id: ItemID,
quantity: integer)
Cross References:
Use Case: Process Sale.
Preconditions:
There is a sale underway.
Postconditions:
Next Slide

(slide by Prof. C. Constantinides)

18

Postconditions:
A SalesLineItem instance sli was created. (instance
creation)
sli was associated with the Sale. (association formed)
sli.quantity was set to quantity. (attribute modification)
sli was associated with a ProductSpecification, based on
id match (association formed)

(slide by Prof. C. Constantinides)

19

Pre- and Postconditions

Preconditions are assumptions about the state of the
system before execution of the operation.
A postcondition is an assumption that refers to the
state of the system after completion of the operation.
The postconditions are not actions to be performed during
the operation.
Describe changes in the state of the objects in the Domain
Model (instances created, associations are being formed or
broken, and attributes are changed)

(slide by Prof. C. Constantinides)

20

Postconditions
In writing Operational Contracts
Postconditions are always specified in
terms of, and only in terms of:
1.The creation or destruction of Domain
Level Objects
2.The alteration of attribute values for
Domain Level Objects
3.The formation or dissolution of
associations between Domain Level
Objects

addLineItem postconditions
Instance Creation and Deletion
After the id and quantity of an item have been
entered by the cashier, what new objects should
have been created?
A SalesLineItem instance sli was created.

(slide by Prof. C. Constantinides)

22

 Attribute Modification
After the id and quantity of an item have been
entered by the cashier, what attributes of new or
existing objects should have been modified?
sli.quantity was set to quantity (attribute
modification).

(slide by Prof. C. Constantinides)

23

 Associations formed or broken

After the id and quantity of an item have been
entered by the cashier, what associations between
new or existing objects should have been formed or
broken?
sli was associated with the current Sale (association formed).
sli was associated with a ProductSpecification, based on id
match (association formed).

(slide by Prof. C. Constantinides)

24

Writing contracts may lead to domain

model updates
It is also common to discover the need to record new
concepts, attributes or associations in the Domain
Model.

(slide by Prof. C. Constantinides)

25

Guidelines for contracts

(slide by Prof. C. Constantinides)

makeNewSale()
Use Case:
Process Sale

addLineItem ()
endSale()
makePayment(
)

Use Case

System
Sequence
Diagram

Operation:
makeNewSale
...
System
Operation:
makeNewSale()
addLineItem
addLineItem(id, quantity)
...
endSale()
makePayment(cashTendered)
Operation:
endSale
...
Operation:
makePayment
...

System
Operations

Contracts

26