chair of software engineering software verification contracts, trusted components and patterns...
Post on 21-Dec-2015
215 views
TRANSCRIPT
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 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 Software Construction, 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.htmlLectures:
Monday: 2 hoursWednesday: 1 hour -- exercises and applications
Assistant: Stephan van Staden [email protected]
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 Ariane crash
Chapter 9 of “Introduction to the Theory of Programming Languages”
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 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
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 untili > input_size
loopbuffer [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
Ideal
Quality
1 2 3
Time
4
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
33
Quality through reuse
The good news:
Reuse scales up everything
The bad news:
Reuse scales up everything
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.)