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 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 range count <= 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