Software Verification Contracts, Trusted Components and Patterns

1. Chair of Software Engineering Software VerificationContracts, Trusted Componentsand Patterns Bertrand Meyer Manuel OriolTill Bay ETH, Fall 2008

2. Today & next lecture • Aims of the course • Introduction to issues of software quality • Axiomatic 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, 1998 • Bertrand Meyer, Object-Oriented SoftwareConstruction, 2nd edition, Prentice Hall, 1997 • Bertrand Meyer, Reusable Software, Prentice Hall, 1994 • Martin Abadi, Luca Cardelli: A Theory of Objects, Springer-Verlag, 1996 • Robert V. Binder: Testing Object-Oriented Systems: Models, Patterns, and Tools, Addison-Wesley, 1999. • Karine Arnout: From Patterns to Components, ETH Ph.D. thesis, 2004 • Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides: Design Patterns: Elements of Reusable Object-Oriented Software, Addison-Wesley, 1995

6. Organization • Course page http://se.ethz.ch/teaching/2008-F/tc-0239/index.html • Lectures: • Monday: 2 hours • Wednesday: 1 hour -- exercises and applications • Assistant: Stephan van StadenStephan.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/xy3s Also read Ken Garlington’s criticism (link in the article) (and optionally) the official report on the Arianecrash 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. Errors Specification Hostility Robustness Correctness Security External quality factors Product quality (immediate): • Correctness • Robustness • Security • Ease of use • Ease of learning • Efficiency • Extendibility • Reusability • Portability • Timeliness • Cost-effectiveness Product quality (long-term): Process quality:

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): INTEGERisrequirerepresentable (b)do …ensureequivalent (b, Result)end

15. NIST report on “testing” (2002) Monetary effect on Developers and User 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 Max 0 Stack frames Stack growth Routn Rout1 Main … Program Heap Stack Stack top Stack bottom

18. Calling a routine Max 0 Stack frames Argsof Rout Routn Rout1 Main Locals of Rout … Program Heap Stack Return address

19. Calling a utility syslogd "Some error message“ fingerSome_name some_command "some text" (Text input into some browser field)

20. Allocating the buffer Max 0 Other locals Stack frames Argsof Rout Routn Rout1 Main … Buffer Program Heap Stack Return address

21. How was the routine coded? fromi := 1 untili > input_sizeloopbuffer [i] := input [i]i := i + 1end (1) fromi := 1 untili > input_sizeori > buffer_size loopbuffer [i] := input [i]i := i + 1end (2)

22. Allocating the buffer Max 0 Other locals Stack frames Argsof Rout Routn Rout1 Main … Buffer Program Heap Stack Return address

23. Getting close Max 0 Other locals Stack frames Routn Rout1 Main … Buffer Program Heap Stack Return address

24. Getting closer Max 0 Other locals Stack frames Routn Rout1 Main … Buffer Available ! Program Heap Stack Return address

25. Inserting the code Max 0 Modified Return Address Other locals Stack frames Routn Rout1 Main … Buffer Your Code Available ! Program Heap Stack Return address

26. Buffer overflow: lessons • Lack of specification • Lack of specification enforcement • Programming techniques • Security 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 9001 • Get software in source from, benefit from public scrutiny • Metrics collection and application • Code reviews?

29. Today’s software is often good enough • Overall: • Works most of the time • Doesn’t kill too many people • Negative effects, esp. financial, are diffuse • Significant improvements since early years: • Better languages • Better tools • Better practices (configuration management)

30. From “good enough” to good? • Beyond “good enough”, quality is economically bad • He who perfects, dies Quality Choose to release? Ideal Actual Time 1 2 3 4

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 engineering • Reuse

35. Abstraction level: • Functional (subroutine) • Casual (package) • Data (class) • Cluster (framework) • System (binary comp.) • Lifecycle role: • Analysis • Design • Implementation • Flexibility: • Static • Dynamic • Replaceable • Form of use: • Interface only • Source only • Source + hiding • Economics: • Free • Purchased • Rented Classifying components by...

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