Upload
teresa-benn
View
218
Download
0
Tags:
Embed Size (px)
Citation preview
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