Contracts Trusted Components and Patterns Bertrand Meyer Manuel Oriol Till Bay ETH Fall 2008 Chair of Software Engineering 2 Today amp next lecture Aims of the course Introduction to issues of software quality ID: 392834
Download Presentation The PPT/PDF document "Software Verification" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Software VerificationContracts, Trusted Componentsand Patterns
Bertrand MeyerManuel OriolTill BayETH, Fall 2008
Chair of Software EngineeringSlide2
2Today & next lectureAims of the courseIntroduction to issues of software qualityAxiomatic semantics and program correctness (1)Slide3
3Aims of this courseTo provide a survey ofReuse and component technology, with a special emphasis on object-oriented approachesTechniques for quality componentsSoftware verification techniquesSlide4
4TopicsQuality issues in software engineeringComponents and the notion of trusted component
Designing O-O librariesAxiomatic Semantics and Program CorrectnessComponentization: turning patterns into ComponentsAutomatic component testing techniques
Program analysisModel checking
Abstract interpretationSeparation logic (guest lectures by Cristiano Calcagno)
Proof-Carrying CodeSlide5
5Basic referencesClemens Szyperski, Component Software, Addison-Wesley, 1998Bertrand Meyer,
Object-Oriented Software Construction, 2nd edition, Prentice Hall, 1997Bertrand 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
:
D
esign Patterns: Elements of Reusable Object-Oriented Software
, Addison-Wesley, 1995Slide6
6OrganizationCourse pagehttp://se.ethz.ch/teaching/2008-F/tc-0239/index.html
Lectures: Monday: 2 hours Wednesday: 1 hour -- exercises and applicationsAssistant: Stephan van
Staden Stephan.vanStaden@inf.ethz.chAll 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
%Slide7
7Reading 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”Slide8
8PART 1: IntroductionIssues of Software QualitySlide9
9Software 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 developersExamples: good programming style, information hiding
Only external factors count in the end, but the internal factors make it possible to obtain them.Slide10
10Software 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 softwareSlide11
11External quality factorsCorrectnessRobustnessSecurity
Ease of useEase of learningEfficiencyExtendibility
ReusabilityPortability
TimelinessCost-effectiveness
Security
Hostility
Robustness
Errors
Correctness
Specification
Process quality:
Product quality (long-term)
:
Product quality (immediate)
:Slide12
12ReliabilityCorrectness:The systems’ ability to perform according to specification, in cases covered by the specificationRobustness:The systems’ ability to perform reasonably in cases not covered by the specification
Security (integrity):The systems’ ability to protect itself against hostile useSlide13
13Ariane 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 !Slide14
14Ariane-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
)
endSlide15
15NIST 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.)Slide16
16From reliability to securityBuffer 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)Slide17
17Buffer overflowMemory Setup
0Max
Program
Heap
Stack
Stack frames
Main
Rout
1
Rout
n
Stack growth
…
Stack top
Stack bottomSlide18
18Calling a routine0
Max
Program
Heap
Stack
Stack frames
Main
Rout
1
Rout
n
…
Args
of
Rout
Locals
of
Rout
Return addressSlide19
19Calling a utilitysyslogd "Some error message“
finger Some_namesome_command "some text"
(Text input into some browser field)Slide20
20Allocating the buffer0
Max
Program
Heap
Stack
Stack frames
Main
Rout
1
Rout
n
…
Args
of
Rout
Return address
Other locals
BufferSlide21
21How was the routine coded?
from i
:= 1 until i >
input_sizeloop
buffer
[
i
] :=
input
[
i
]
i
:=
i
+ 1
end
from
i
:= 1
until
i
>
input_size
or
i
>
buffer_size
loop
buffer
[i] :=
input
[
i
]
i
:=
i
+ 1
end
(1)
(2)Slide22
22Allocating the buffer0
Max
Program
Heap
Stack
Stack frames
Main
Rout
1
Rout
n
…
Args
of
Rout
Return address
Other locals
BufferSlide23
23Getting close0
Max
Program
Heap
Stack
Stack frames
Main
Rout
1
Rout
n
…
Return address
Other locals
BufferSlide24
24Getting closer0
Max
Program
Heap
Stack
Stack frames
Main
Rout
1
Rout
n
…
Return address
Other locals
Buffer
Available !
Slide25
25Inserting the code0
Max
Program
Heap
Stack
Stack frames
Main
Rout
1
Rout
n
…
Return address
Other locals
Buffer
Available !
Your Code
Modified Return AddressSlide26
26Buffer overflow: lessonsLack of specificationLack of specification enforcementProgramming techniquesSecurity concepts
At the core, a programming methodology issueSlide27
27Software quality (through technology)A priori (build it right)
Object technology, formal developmentA posteriori (validate and fix it) Testing, abstract interpretation, model checkingSlide28
28Management aspectsProcess standards: CMMI, ISO 9001Get software in source from, benefit from public scrutinyMetrics collection and applicationCode reviews?Slide29
29Today’s software is often good enoughOverall:Works most of the timeDoesn’t kill too many peopleNegative effects, esp. financial, are diffuseSignificant improvements since early years:
Better languagesBetter toolsBetter practices (configuration management)Slide30
30From “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?Slide31
31The economic argumentStable system:Sum of individual optima = Global optimumNon-component-based development:Individual optimum = “Good Enough Software”Improvements: I am responsible!
Component-based development:Interest of both consumer and producer: Better componentsImprovements: Producer does the jobSlide32
32Quality through reuseThe good news:Reuse scales up everythingSlide33
33Quality through reuseThe good news:Reuse scales up everythingThe bad news:
Reuse scales up everythingSlide34
34Trusted componentsConfluence ofQuality engineeringReuseSlide35
35Classifying components by...Lifecycle role:
AnalysisDesignImplementation
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.)Slide36
36This is a broad view of componentsEncompasses patterns and frameworksSoftware, 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