anwendung formaler verifikation - formal.iti.kit.edu fileumfang und struktur 3 sws = 21...

KIT – University of the State of Baden-Wurttemberg and National Large-scale Research Center of the Helmholtz Association

Prof. Dr. Bernhard Beckert · Dr. Vladimir Klebanov | SS 2010

Organisatorisches

Anwendung formaler Verifikation

KIT – INSTITUT FUR THEORETISCHE INFORMATIK

Organisatorisches

Webseite zur Vorlesung

http://formal.iti.kit.edu/teaching/AnwendungFormalerVerifikation/

Alle fur die Vorlesung relevanten Informationen und Materialien:

Termine und aktuelle InformationenFolienTools und weitere Materialien

Organisatorisches Introduction Motivation

Prof. Dr. Bernhard Beckert · Dr. Vladimir Klebanov – Anwendung formaler Verifikation SS 2010 2/20



Organisatorisches

Zielgruppe

Diplom Informatik, Master Informatik

Vertiefungsfacher

Theoretische GrundlagenSoftwaretechnik und Ubersetzerbau

Modul Formale Methoden



Organisatorisches

Umfang und Struktur3 SWS = 21 Doppelstunden im Semesteraufgeteilt in sieben Einheiten mit je zwei DoppelstundenVorlesung und einer Doppelstunde UbungUbungen: Verfahren werden anhand konkreterVerifikatiossysteme praktisch erprobtVorlesung und Ubung gehen fließend ineinander uber



Organisatorisches

TermineDonnerstags, 11:30-13:00Freitags, 11:30-13:00

An welchen 21 der 28 moglichen Termine eineVorlesung/Ubung stattfindet steht auf der Webseite!



Organisatorisches

Vorlesungseinheiten

1 Funktionaler Eigenschaftenimperativer und objekt-orientierter Programme

Java Modeling LanguageDynamische Logik

2 Nebenlaufige Programme(Concurrency)

Rely/Guarantee

3 TemporallogischeEigenschaften

Model Checking

4 Hybride Systeme Model Checking, Dynami-sche Logik

5 Echtzeiteigenschaften Timed Automata, UPPAAL6 Informationsfluss-

EigenschaftenDynamische Logik, Typsys-teme

7 Protokollverifikation Termersetzungsverfahren(Rewriting)



Verwandte Vorlesungen

Formale Systeme (Beckert/Schmitt)Formale Systeme II (Schmitt/Beckert)Spezifikation und Verifikation von Software / FormalerEntwurf und Verifikation von Programmen(Schmitt/Beckert)Theorembeweiser und ihre Anwendungen(Snelting/Wasserrab)Model Checking (Sinz/Tveretina)Modellgetriebene Software-Entwicklung(Reussner/Becker)



KIT – University of the State of Baden-Wurttemberg and National Large-scale Research Center of the Helmholtz Association

Prof. Dr. Bernhard Beckert · Dr. Vladimir Klebanov | SS 2010

Introduction

Applications of Formal Verification

KIT – INSTITUT FUR THEORETISCHE INFORMATIK

Motivation:Software Defects cause BIG Failures

Tiny faults in technical systems can have catastrophicconsequences

In particular, this goes for software systemsAriane 5Mars Climate Orbiter, Mars SojournerLondon Ambulance Dispatch SystemDenver Airport Luggage Handling SystemPentium BugEC-Karten Bug


Prof. Dr. Bernhard Beckert · Dr. Vladimir Klebanov – Applications of Formal Verification SS 2010 9/20

Motivation:Software Defects causeOMNIPRESENT Failures

Ubiquitous Computing results in Ubiquitous Failures

Software these days is inside just about anything:MobilesSmart devicesSmart cardsCarsAviation

⇒ software—and specification—quality is a growing legal issue



Achieving Reliability in Engineering

Some well-known strategies from civil engineeringPrecise calculations/estimations of forces, stress, etc.Hardware redundancy (“make it a bit stronger thannecessary”)Robust design (single fault not catastrophic)Clear separation of subsystemsAny air plane flies with dozens of known and minor defectsDesign follows patterns that are proven to work



Why This Does Not Work ForSoftware

Software systems compute non-continuous functionsSingle bit-flip may change behaviour completelyRedundancy as replication doesn’t help against bugsRedundant SW development only viable in extreme casesNo clear separation of subsystemsLocal failures often affect whole systemSoftware designs have very high logic complexityDesign practice for reliable software in immature statefor complex, particularly, distributed systemsCost efficiency favoured over reliabilityExtremely short innovation cycles



Limitations of Testing

Testing shows the presence of errors, in general not theirabsence(exhaustive testing viable only for trivial systems)Representativeness of test cases/injected faults subjectiveHow to test for the unexpected? Rare cases?Testing is labor intensive, hence expensive



Formal Methods: The Scenario

Rigorous methods used in system design and developmentMathematics and symbolic logic⇒ formalIncrease confidence in a systemTwo aspects:

System implementationSystem requirements

Make formal model of both and use tools to provemechanicallythat formal execution model satisfies formal requirements



Formal Methods: The Vision

Complement other analysis and design methodsAre good at finding bugs(in code and specification)Reduce development (and test) timeCan ensure certain properties of the system modelShould ideally be as automatic as possible



Various Properties(Require Different Verification Techniques)

Simple propertiesSafety propertiesSomething bad will never happen (eg, mutual exclusion)Liveness propertiesSomething good will happen eventually

General properties of concurrent/distributed systemsdeadlock-free, no starvation, fairness

Non-functional propertiesRuntime, memory, usability, . . .

Full behavioural specificationCode satisfies a contract that describes its functionalityData consistency, system invariants(in particular for efficient, i.e. redundant, datarepresentations)Modularity, encapsulationRefinement relation



The Main Point of Formal Methods isNot

To show “correctness” of entire systemsWhat IS correctness? Always go for specific properties!To replace testing entirely

Formal methods work on models, on source code, or, atmost, on bytecode levelMany non-formalizable properties

To replace good design practices

There is no silver bullet!

No correct system w/o clear requirements & good designOne can’t formally verify messy code with unclear specs



But . . .

Formal proof can replace (infinitely) many test casesFormal methods can be used in automatic test casegenerationFormal methods improve the quality of specs(even without formal verification)Formal methods guarantee specific properties of a specificsystem model



Formal Methods Aim at:

Saving moneyIntel Pentium bugSmart cards in bankingSaving timeotherwise spent on heavy testing and maintenanceMore complex productsModern µ-processorsFault tolerant softwareSaving human livesAvionics, X-by-wireWashing machine



Tool Support is Essential

Some Reasons for Using ToolsAutomate repetitive tasksAvoid clerical errors, etc.Cope with large/complex programsMake verification certifiable



anwendung formaler verifikation - formal.iti.kit.edu fileumfang und struktur 3 sws = 21...

Documents