SPARK95. Ingmar Wirths. 12. Juli 2007

Transkript

1 SPARK95 Ingmar Wirths 12. Juli 2007

2 Motivation Ada wurde zur Programmierung von Mikroprozessoren entwickelt.

3 Motivation Ada wurde zur Programmierung von Mikroprozessoren entwickelt. Ein Systemversagen ist oft nicht tolerierbar.

4 Motivation Ada wurde zur Programmierung von Mikroprozessoren entwickelt. Ein Systemversagen ist oft nicht tolerierbar. Industrie und Militär verlangen für kritische Systeme Korrektheitsbeweise.

5 Einleitung SPARK ist eine annotierte Teilsprache von Ada.

6 Einleitung SPARK ist eine annotierte Teilsprache von Ada. SPARK Annotations sind Ada Kommentare: # foo;

7 Einleitung SPARK ist eine annotierte Teilsprache von Ada. SPARK Annotations sind Ada Kommentare: # foo; In SPARK geschriebene Programme können von jedem Ada Compiler übersetzt werden.

8 Einleitung SPARK ist eine annotierte Teilsprache von Ada. SPARK Annotations sind Ada Kommentare: # foo; In SPARK geschriebene Programme können von jedem Ada Compiler übersetzt werden. Einige Sprachkonstrukte aus Ada sind verboten.

9 Correctness by Construction Ada unterscheidet zwischen Kompilier- und Laufzeitfehlern

10 Correctness by Construction Ada unterscheidet zwischen Kompilier- und Laufzeitfehlern Das Ziel von SPARK ist es Programme zu schreiben, die keine Laufzeitfehler produzieren.

11 Correctness by Construction Ada unterscheidet zwischen Kompilier- und Laufzeitfehlern Das Ziel von SPARK ist es Programme zu schreiben, die keine Laufzeitfehler produzieren. Dazu wird der Programmcode mit dem SPARK Toolset einer statischen Analyse unterzogen.

12 Correctness by Construction Ada unterscheidet zwischen Kompilier- und Laufzeitfehlern Das Ziel von SPARK ist es Programme zu schreiben, die keine Laufzeitfehler produzieren. Dazu wird der Programmcode mit dem SPARK Toolset einer statischen Analyse unterzogen. SPARK kann Daten- und Informationsflussanalyse sowie Programmverifikation durchführen.

13 Datenflussanalyse Variablen müssen vor Benutzung initialisiert werden.

14 Datenflussanalyse Variablen müssen vor Benutzung initialisiert werden. Modus von Parametern (in, out, in out)

15 Datenflussanalyse Variablen müssen vor Benutzung initialisiert werden. Modus von Parametern (in, out, in out) Annotation einer globalen Variable in einer Prozedur: # global foo;

16 Informationsflussanalyse Abhängigkeiten von Variablen werden mit # derives X from X, Y; deklariert.

17 Informationsflussanalyse Abhängigkeiten von Variablen werden mit # derives X from X, Y; deklariert. Beispiel: procedure I n c r e m e n t (X : i n out Counter Type ) ; # g l o b a l Counter ; # d e r i v e s X from X, Counter ;

18 Programmverifikation Zusicherungen # assert

19 Programmverifikation Zusicherungen # assert Vor- und Nachbedingungen werden mit # pre bzw. # post deklariert.

20 Programmverifikation Zusicherungen # assert Vor- und Nachbedingungen werden mit # pre bzw. # post deklariert. Beispiel: procedure I n c r e m e n t (X : i n out Counter Type ) ; # d e r i v e s X from X ; # pre X < Counter Type L a s t ; # p o s t X = X + 1 ;

21 SPARK Toolset Der Examiner generiert verification conditions (VCs).

22 SPARK Toolset Der Examiner generiert verification conditions (VCs). Der Simplifier vereinfacht die VCs. Wenn die VCs zu true reduziert werden können, dann entspricht das Programm der annotierten Spezifikation.

23 Beispiel type T i s range ; procedure I n c (X : i n out T) # d e r i v e s X from X ; i s begin X := X + 1 ; end I n c ;

24 Beispiel p r o c e d u r e i n c 1. H1 : t r u e. H2 : x >= t f i r s t. H3 : x <= t l a s t. > C1 : x + 1 >= t f i r s t. C2 : x + 1 <= t l a s t.

25 Beispiel p r o c e d u r e i n c 1. H1 : x >= 128. H2 : x <= 128. > C1 : x <= 127.

26 Beispiel p r o c e d u r e i n c 1. H1 : x >= 128. H2 : x <= 128. > C1 : x <= 127. Der Benutzer kann VCs mit dem Proof Checker beweisen

27 Examiner

28 Examiner Syntaktische Analyse

29 Examiner Syntaktische Analyse Analyse der Programm Struktur

30 Examiner Syntaktische Analyse Analyse der Programm Struktur Semantische Analyse

31 Examiner Syntaktische Analyse Analyse der Programm Struktur Semantische Analyse Daten- und Informationsflussanalyse:

32 Daten- und Informationsflussanalyse Referenz auf nichtinitialisierte Variablen

33 Daten- und Informationsflussanalyse Referenz auf nichtinitialisierte Variablen Ineffektive Anweisung

34 Daten- und Informationsflussanalyse Referenz auf nichtinitialisierte Variablen Ineffektive Anweisung Inkonsistenzen im Informationsfluss

35 Daten- und Informationsflussanalyse Referenz auf nichtinitialisierte Variablen Ineffektive Anweisung Inkonsistenzen im Informationsfluss Schleifen Stabilität

36 Daten- und Informationsflussanalyse Referenz auf nichtinitialisierte Variablen Ineffektive Anweisung Inkonsistenzen im Informationsfluss Schleifen Stabilität Nichtbenutzte Variablen

37 Daten- und Informationsflussanalyse Referenz auf nichtinitialisierte Variablen Ineffektive Anweisung Inkonsistenzen im Informationsfluss Schleifen Stabilität Nichtbenutzte Variablen Variablen, deren Wert konstant bleibt

38 Laufzeitfehleranalyse Array Index nicht im Bereich

39 Laufzeitfehleranalyse Array Index nicht im Bereich Wertbereichfehler

40 Laufzeitfehleranalyse Array Index nicht im Bereich Wertbereichfehler Division durch 0

41 Laufzeitfehleranalyse Array Index nicht im Bereich Wertbereichfehler Division durch 0 Numerischer Überlauf

42 Laufzeitfehleranalyse Der Run-Time Error Checker generiert systematisch für alle möglichen Laufzeitfehler Bedingungen, unter denen diese nicht auftreten.

43 Laufzeitfehleranalyse Der Run-Time Error Checker generiert systematisch für alle möglichen Laufzeitfehler Bedingungen, unter denen diese nicht auftreten. Der Simplifier kann viele dieser Bedingungen erfüllen.

44 Laufzeitfehleranalyse Der Run-Time Error Checker generiert systematisch für alle möglichen Laufzeitfehler Bedingungen, unter denen diese nicht auftreten. Der Simplifier kann viele dieser Bedingungen erfüllen. Die übrig gebliebenen Bedingungen können mit dem Proof Checker erfüllt werden.

45 Programmverifikation Partielle Korrektheit: Vorbedingung ist erfüllt Programm terminiert Nachbedingung ist erfüllt

46 Programmverifikation Partielle Korrektheit: Vorbedingung ist erfüllt Programm terminiert Nachbedingung ist erfüllt Totale Korrekheit: Programm ist partiell korrekt und terminiert immer

47 Programmverifikation Partielle Korrektheit: Vorbedingung ist erfüllt Programm terminiert Nachbedingung ist erfüllt Totale Korrekheit: Programm ist partiell korrekt und terminiert immer Die Korrektheit wird mit dem SPARK Toolset überprüft.

48 Programmverifikation Partielle Korrektheit: Vorbedingung ist erfüllt Programm terminiert Nachbedingung ist erfüllt Totale Korrekheit: Programm ist partiell korrekt und terminiert immer Die Korrektheit wird mit dem SPARK Toolset überprüft. Worst-Case Ausführungszeit wird ermittelt.

49 Spracheigenschaften Keine Exceptions

50 Spracheigenschaften Keine Exceptions Keine Rekursion

51 Spracheigenschaften Keine Exceptions Keine Rekursion Keine dynamische Speicherverwaltung

52 Spracheigenschaften Keine Exceptions Keine Rekursion Keine dynamische Speicherverwaltung Keine generischen Typen

53 Spracheigenschaften Keine Exceptions Keine Rekursion Keine dynamische Speicherverwaltung Keine generischen Typen Funktionen dürfen keine Seiteneffekte enthalten

54 Objektorientierung Konstruktoren und Destruktoren Explizite Speicherverwaltung

55 Objektorientierung Konstruktoren und Destruktoren Explizite Speicherverwaltung Kapselung: package als Klasse

56 Objektorientierung Konstruktoren und Destruktoren Explizite Speicherverwaltung Kapselung: package als Klasse Abstraktion mit der Deklaration von packages

57 Objektorientierung Konstruktoren und Destruktoren Explizite Speicherverwaltung Kapselung: package als Klasse Abstraktion mit der Deklaration von packages Modulare Programmierung

58 Objektorientierung Konstruktoren und Destruktoren Explizite Speicherverwaltung Kapselung: package als Klasse Abstraktion mit der Deklaration von packages Modulare Programmierung Vererbung

59 Objektorientierung Konstruktoren und Destruktoren Explizite Speicherverwaltung Kapselung: package als Klasse Abstraktion mit der Deklaration von packages Modulare Programmierung Vererbung Keine Polymorphie

60 Beispiel package P i s procedure Exchange (X, Y : i n out I n t e g e r ) ; # d e r i v e s X from Y & # Y from X ; # p o s t X = Y and Y = X ; end P ; package body P i s procedure Exchange (X, Y : i n out I n t e g e r ) i s T : I n t e g e r ; begin T := X ; X := Y ; Y := T; end Exchange ; end P ;

61 Beispiel p r o c e d u r e e x c h a n g e 1. H1 : t r u e. H2 : x >= i n t e g e r f i r s t. H3 : x <= i n t e g e r l a s t. H4 : y >= i n t e g e r f i r s t. H5 : y <= i n t e g e r l a s t. > C1 : y = y. C2 : x = x.

62 Zusammenfassung SPARK analysiert Programme zur Entwicklungszeit.

63 Zusammenfassung SPARK analysiert Programme zur Entwicklungszeit. Das fertige Programm verhält sich garantiert den annotierten Spezifikationen entsprechend.

64 Zusammenfassung SPARK analysiert Programme zur Entwicklungszeit. Das fertige Programm verhält sich garantiert den annotierten Spezifikationen entsprechend. Mit SPARK entwickelte Programme genügen strengen Standards aus Industrie und Militär.