Building bug-free O-O software: An introduction to Design by Contract

Eiffel Software

Presented by Bert Bruce

Software Quality In an early paper we learned that

most S/W companies consider time-to-market so important that Quality concerns get little attention

But reliable software means much lower support costs and better long-term productivity

Many small companies fail because they don’t plan for their success by building in the requisite Quality

Software Quality Reliability is a major component

Correctness Does what it is supposed to

Robustness Handles abnormal conditions

Reliable code can be produced using Static typing Automatic garbage collection Lots of re-use

But we can do more….

Design by Contract The term “Design by Contract is

trademarked by Eiffel Software Presumably one can use the

term in lower case without violating their trademark

Design by Contract is a software development methodology

Eiffel is a language that embodies DbC

But can be used in other languages as well

Design by Contract Software - set of communicating

components Interaction should be based on precise

and complete set of mutual obligations E.g. contracts

Actually all software is design by contract The issue - is the contract

Verbal? Informal or formal? Implied or explicit? Complete? Binding?

A Good Example of a Bad Example Data base system for queries on

multi-terabyte databases Ran on massively parallel SIMD

machine (up to 16000 processors)

Execute complex queries in minutes rather than hours

Competing with Teradata Wonderful Computer Science

Based on founder’s PhD thesis Horrible Software Engineering

A Good Example of a Bad Example

SQL Parser

Parallelizer

Code Generator

Runtime Environment

Informal Contracts

I don’t remember seeing anything in writing

Query

A Good Example of a Bad Example Could never work on more than

simplest cases Took entire team to find and fix

every bug No ability to test harness components Many bugs were of the “Oh, I thought

you were going to…” type (informal, unwritten, implied contracts)

Ultimately burned a lot of VC money and died

Specifications

DbC is based on specifications As precise as possible As complete as possible What software will do What software won’t do

Very difficult to do completely But even a small amount can

reap big rewards Having no spec => little chance

code will do what is wanted

Specifications DbC says every software element

should have a specification Embed the spec in the code

Insures they are coupled Only one representation – no

translation or loss of sync Can be used for efficient

implementation Seamless – throughout the software

lifecycle Only one document

Provides basis for testing

Contract An agreement between a supplier

and a client Each has obligations and benefits Example – a dictionary write procedure

Client assures preconditions – table is not full and key is not empty string

Client benefits from postconditions – table has been updated with proper key

Supplier must insure postcondition – table has been updated

Supplier may assume precondition – no need to do anything if table full or empty key

Contract Sample code:

put (x: ELEMENT; key: STRING) is -- Insert x so that it will be retrievable through

key. require count <= capacity

not key.empty do

... Some insertion algorithm ... ensure

has (x) Item (key) = x count = old count + 1

end

Preconditions

Postconditions

Implementation

Eiffel has these keywords built into the language

Other languages can support this by extensions Use keywords in formatted

comments Use preprocessor to process these

comments Commercial products available for

C, C++, C#, Java, PHP, Perl and others

Contract as a Design Tool Use the notation to design

modules before implementation Code can be added directly later

No need to translate from a specification document

Allows system to be modeled before implementation

Implementation does not need to (and should not) check the contract

Design Example

Chemical plant Objects in model: Tank, pipe,

valve, control room,…. Method to fill tank might be:fill is

-- Fill tank with liquid require in_valve.open

out_valve.closed deferred -- i.e., no implementation ensure

in_valve.closed out_valve.closed Is_full

end

Invariants Class variable property

True in all instances of the class Provide legal range or

characteristics for a variable Independent of method code Examples

0 <= count // limits rangecount <= maxVal // of count

getsOvertime = (status == nonExempt)

and (hours > 40)

Invariants

Invariants characterize the class Not just value at the moment,

but always Part of contract Independent of code

Relieve the implementation code of the responsibility to check for legal values

Documentation

Single source file makes it easy to document the code

Class code without the implementation code is the contract i.e. Module names, parameters,

requires, ensures, invariants Provides a communication tool

for non-programmers E.g. managers, PMs, customers, etc.

Testing

Preconditions and postconditions are like asserts

Selectively compile code into module to test the conditions

Possible options: Preconditions only Pre and postconditions Invariants All assertions

Testing

The compiled-in code will find run-time design and implementation flaws during QA cycle

The testing instrumentation can be used just for testing and not compiled in for shipping product

Inheritance Subclasses inherit the parent

class contract Principle of Subcontracting: a

subclass may weaken the precondition but not strengthen it and strengthen a postcondition but not weaken it To “weaken” means allowing a

larger set of conditions This principle ensures compatible

semantics for subclasses

Exception Handling

An exception represents the failure of a module to fulfill a contract Hardware problem Called routine failed Bug in implementation

Exception Options Retry Organized Panic

Clean up and exit Treat as False Alarm

Exception Handling

In Eiffel, an exception invokes a “rescue” clause At first blush, like a “catch”, but

more powerful Rescue clause can include a

“retry” invocation to re-execute the code body of the module

Local variables not re-initialized on retry, so code can keep state information like a retry count

Future Work

Extensions for concurrent programming and distributed objects

Extended specification language constructs for a richer set of assertions Possible examples – side effect

constraints or performance constraints

Summary

In the real world, good contracts, treaties, etc. that are met make things flow smoothly

Bad or unmet contracts cause chaos

Modeling software development on what works in the real world makes a lot of sense

I wish I had known about DbC many years ago