1 / 25

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

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

wprince
Download Presentation

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

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related