Software Verification Contracts, Trusted Components and Patterns

Chair of Software Engineering

Software VerificationContracts, Trusted Components

and Patterns

Bertrand MeyerManuel Oriol

Till BayETH, Fall 2008

Chair of Software Engineering

2

Today & next lecture

Aims of the courseIntroduction to issues of software qualityAxiomatic semantics and program correctness (1)

3

Aims of this course

To provide a survey of

Reuse and component technology, with a special emphasis on object-oriented approaches

Techniques for quality components

Software verification techniques

4

Topics Quality issues in software engineering Components and the notion of trusted component Designing O-O libraries Axiomatic Semantics and Program Correctness Componentization: turning patterns into

Components Automatic component testing techniques Program analysis Model checking Abstract interpretation Separation logic (guest lectures by Cristiano

Calcagno) Proof-Carrying Code

5

Basic references

Clemens Szyperski, Component Software, Addison-Wesley, 1998Bertrand Meyer, Object-Oriented Software Construction, 2nd edition, Prentice Hall, 1997Bertrand Meyer, Reusable Software, Prentice Hall, 1994Martin Abadi, Luca Cardelli: A Theory of Objects, Springer-Verlag, 1996Robert V. Binder: Testing Object-Oriented Systems: Models, Patterns, and Tools, Addison-Wesley, 1999. Karine Arnout: From Patterns to Components, ETH Ph.D. thesis, 2004Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995

6

OrganizationCourse page

http://se.ethz.ch/teaching/2008-F/tc-0239/index.htmlLectures:

Monday: 2 hoursWednesday: 1 hour -- exercises and applications

Assistant: Stephan van Staden Stephan.vanStaden@inf.ethz.ch

All exercises are optional, but will be corrected. They are an important preparation for the exam and the project.

Grading:Written exam on date of 15 December (lecture time):

70%Project (take-home exercise): 30%

7

Reading assignment“Ariane” paper: http://tinyurl.com/xy3sAlso read Ken Garlington’s criticism (link in the article) (and optionally) the official report on the Ariane crash

Chapter 9 of “Introduction to the Theory of Programming Languages”

8

PART 1: Introduction

Issues of Software Quality

9

Software quality: external vs internal External factors: visible to customers

(not just end users but e.g. purchasers)

Examples: ease of use, extendibility, timeliness

Internal factors: perceptible only to developers

Examples: good programming style, information hiding

Only external factors count in the end, but the internal factors make it possible to obtain them.

10

Software quality: product vs process

Product: properties of the resulting software

For example: correctness, efficiency

Process: properties of the procedures used to produce and “maintain” the software

11

External quality factors

CorrectnessRobustnessSecurityEase of useEase of learningEfficiency

ExtendibilityReusabilityPortability

TimelinessCost-effectiveness

Security

Hostility

Robustness

Errors

Correctness

Specification

Process quality:

Product quality (long-term):

Product quality (immediate):

12

Reliability

Correctness:The systems’ ability to perform according to specification, in cases covered by the specification

Robustness:The systems’ ability to perform reasonably in cases not covered by the specification

Security (integrity):The systems’ ability to protect itself against hostile use

13

Ariane 5, 1996

$500 million, not insured.40 seconds into flight, exception in Ada program not processed; order given to abort the mission.Exception was caused by an incorrect conversion: a 64-bit real value was incorrectly translated into a 16-bit integer.• Not a design error.• Not an implementation error.• Not a language issue.• Not really a testing problem.• Only partly a quality assurance issue.Systematic analysis had “proved” that the exception could not occur – the 64-bit value (“horizontal bias” of the flight) was proved to be always representable as a 16-bit integer !

14

Ariane-5 (Continued)It was a REUSE error:• The analysis was correct – for Ariane 4 !• The assumption was documented – in a design document !With assertions, the error would almost certainly (if not avoided in the first place) detected by either static inspection or testing:

integer_bias (b: REAL): INTEGER is require representable (b) do … ensure equivalent (b, Result) end

15

NIST report on “testing” (2002)

Monetary effect onDevelopers andUser due to“insufficient testing infrastructure”:

$59.5 billion

(Financial sector: $3.3 billion,auto/aerospace $1.8 billion etc.)

16

From reliability to security

Buffer overflow(Morris worm, most viruses)

See http://www.cert.org

Some_innocuous_public_command “Some message”(Or maybe just inputting text into a browser field)

17

Buffer overflow

Memory Setup

0 Max

Program Heap Stack

Stack frames

MainRout1Routn

Stack growth …

Stack top Stack bottom

18

Calling a routine

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…Args

ofRout

Localsof

Rout

Return address

19

Calling a utility

syslogd "Some error message“

finger Some_name

some_command "some text"

(Text input into some browser field)

20

Allocating the buffer

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…Args

ofRout

Return address

Other locals

Buffer

21

How was the routine coded?from i := 1 until

i > input_sizeloop

buffer [i] := input [i]i := i + 1

end

from i := 1 untili > input_size or i > buffer_size

loopbuffer [i] := input [i]i := i + 1

end

(1)

(2)

22

Allocating the buffer

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…Args

ofRout

Return address

Other locals

Buffer

23

Getting close

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…

Return address

Other locals

Buffer

24

Getting closer

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…

Return address

Other locals

Buffer

Available !

25

Inserting the code

0 Max

Program Heap Stack

Stack frames

MainRout1Routn…

Return address

Other locals

Buffer

Available !

Your Code

Modified Return Address

26

Buffer overflow: lessons

Lack of specificationLack of specification enforcementProgramming techniquesSecurity concepts

At the core, a programming methodology issue

27

Software quality (through technology)

A priori (build it right)Object technology, formal development

A posteriori (validate and fix it)Testing, abstract interpretation, model

checking

28

Management aspects

Process standards: CMMI, ISO 9001Get software in source from, benefit from public scrutinyMetrics collection and applicationCode reviews?

29

Today’s software is often good enough

Overall:Works most of the timeDoesn’t kill too many peopleNegative effects, esp. financial, are diffuse

Significant improvements since early years:Better languagesBetter toolsBetter practices (configuration management)

30

From “good enough” to good?

Beyond “good enough”, quality is economically badHe who perfects, dies

Actual

IdealQuality

1 2 3

Time4

Choose to release?

31

The economic argument

Stable system: Sum of individual optima = Global optimum

Non-component-based development: Individual optimum = “Good Enough Software” Improvements: I am responsible!

Component-based development: Interest of both consumer and producer: Better

components Improvements: Producer does the job

32

Quality through reuse

The good news:

Reuse scales up everything

33

Quality through reuse

The good news:

Reuse scales up everything

The bad news:

Reuse scales up everything

34

Trusted components

Confluence of

Quality engineeringReuse

35

Classifying components by...

Lifecycle role:• Analysis• Design• Implementation

Flexibility:• Static• Dynamic• Replaceable

Form of use:• Interface only• Source only• Source + hiding

Economics:• Free• Purchased• Rented

Abstraction level:• Functional (subroutine)• Casual (package)• Data (class)• Cluster (framework)• System (binary comp.)

36

This is a broad view of components

Encompasses patterns and frameworks

Software, especially with object technology, permits “pluggable” components (“don’t call us, we’ll call you”), where client programmers can insert their own mechanisms.

Supports component families