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

1. Building bug-free O-O software: An introduction to Design by Contract Eiffel Software Presented by Bert Bruce

2. 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

3. 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….

4. 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

5. 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?

6. 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

7. A Good Example of a Bad Example Query SQL Parser Informal Contracts I don’t remember seeing anything in writing Parallelizer Code Generator Runtime Environment

8. 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

9. 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

10. 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

11. 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

12. 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

13. 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

14. 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

15. 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

16. 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)

17. 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

18. 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.

19. 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

20. 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

21. 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

22. 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

23. 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

24. 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

25. 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