Professional Documents
Culture Documents
9 - Operation Contracts
9 - Operation Contracts
9 - 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)
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)
Obligations
Client:
The passenger
Benefits
Supplier:
The railway
company
7
Obligations
Client:
The passenger
Supplier:
The railway
company
Benefits
Obligations of client,
are suppliers benefits!
Obligations
Benefits
Client:
The passenger
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
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.
Class A
client
supplier
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.
System
makeNewSale()
addLineItem(id, quantity)
Contracts are written for
endSale()
makePayment(cashTendered) each system operation to
17
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)
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.
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).
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