building bug free o o software an introduction to design by contract n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Building bug-free O-O software: An introduction to Design by Contract PowerPoint Presentation
Download Presentation
Building bug-free O-O software: An introduction to Design by Contract

Loading in 2 Seconds...

play fullscreen
1 / 25

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


  • 93 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Building bug-free O-O software: An introduction to Design by Contract' - ziazan


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
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
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 quality1
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
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 contract1
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
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 example1
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

a good example of a bad example2
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
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
specifications1
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
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
contract1
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
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
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
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
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)

invariants1
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
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
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
testing1
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
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
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 handling1
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
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
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