Ein Fundament für Verifizierte Softwareentwicklungssysteme

Ein Fundament für Verifizierte 

Softwareentwicklungssysteme 

Christoph Kreitz 

Fachgebiet Intellektik, Fachbereich Informatik, Technische Hochschule Darmstadt 

Alexanderstr. 10, 64283 Darmstadt 

· Problemfeld: Rechnergestützte Softwareentwicklung 

· Repräsentation von Konzepten und Methoden 

· Verifizierte Realisierung von Synthesestrategien 

– am Beispiel “Entwicklung von Globalsuchalgorithmen” 

· Forschungsziele – Ausblick

Problemfeld 

• Software-Krise – ungelöst seit 25 Jahren 

– Kosten/Zeitaufwand: Erstellung, Wartung, Modifikation 

– Zuverlässigkeit: Korrektheit nicht testbar 

• Softwareentwicklung benötigt 

Kreativität 

+ logische Schlußfolgerungen 

+ Verarbeitung von Wissen (Erfahrung) 

+ sorgfältige Codierung (Disziplin) 

⇒ Kooperation zwischen Mensch und Maschine sinnvoll 

– Programmierer: Steuerung des Entwicklungsprozesses 

– Computer: Korrektheitsgarantie für erzeugte Software 

Verifizierte Softwareentwicklungssysteme 1 Ziele

Rechnerunterstützung bei Softwareentwicklung 

• CASE, Objektorientierung 

– Hilfe bei Systementwurf, Strukturierung, Spezifikation, 

– Wiederverwendbarkeit 

– Korrektheitsgarantie fehlt 

• Verifikation 

– Korrektheitsbeweis durch Rekonstruktion der Programmidee 

– Unterstützung bei Entwurf und Implementierung fehlt 

• Programmsynthese (‘Wissensbasierte Softwareentwicklung’) 

= Programmierung durch logische Schlußfolgerungsprozesse 

↦→ Implementierung schnell + garantiert korrekt 

+ Dokumentation des Entwicklungsprozesses 

↦→ Wartung / Modifikation leicht 


Programmsynthese 

• Praktisch orientierte Syntheseverfahren 

– theoretische Untersuchungen + ad hoc Codierung 

↦→ Prototypen erfolgreich: schnellere Entwicklung + schnellere Software 

KIDS: US-Army Transport Scheduling Algorithmus um Faktor 2000 (!!) schneller 

– Fehler bei Codierung des Verfahrens möglich 

↦→ keine echte Korrektheitsgarantie 

• Beweisbasierte Syntheseverfahren 

– Steuerung von Regeln eines ausdrucksstarken mathematischen Kalküls 

↦→ Korrektheitsgarantie für erzeugter Software 

– niedriges Abstraktionsniveau (elementare formale Logik) 

↦→ für Programmierer schwer verständlich (Kooperation unmöglich) 

↦→ nur “Spielbeispiele” praktisch lösbar 

Integration der Stärken beider Vorgehensweisen möglich? 


Ansatz: Integration durch Abstraktion 

• Ziel: verständliche logische Schlüsse 

– Schlußfolgerungen auf Ebene der Programmierkonzepte ↦→ praktisch nutzbar 

– Abstützung auf mathematisch gesichertem Kalkül ↦→ Korrektheitsgarantie 

• Ausgangspunkt: ausdrucksstarker logischer Basiskalkül 

⇒ Formalisierung der Grundkonstrukte vorhanden 

+ Interaktives Beweisentwicklungssystem (NuPRL) 

• Erweiterung: Formale Theorie der Programmierung 

– Formalisierung von Anwendungsbereichen + Programmierkonzepten 

– Verifikation bekanntes Wissens durch formale Lemmata & Theoreme 

– Erzeugung abgeleiteter Inferenzregeln auf hohem Abstraktionsniveau 

⇒ Kontrolle formaler Inferenzen durch Menschen möglich 

⇒ flexible, effiziente, zuverlässige Implementierung von Synthesesystemen 


Formalisierung von Programmiergrundwissen 

• Erweiterung des Kalküls auf Standard-Anwendungsbereiche 

– Definitionen für Operationen auf Zahlen, Tupeln, Folgen, Mengen, Bäumen. . . 

– Abstrakte Datentypen: Extraktion aus Formationstheorem 

– Faktenwissen: formal bewiesene Lemmata über Eigenschaften von Operationen 

⇒ Verifizierte Wissensbank 

• Leitlinie: Grundlehrbücher mit Standardwissen der Informatik 

– ca. 500 Definitionen / 4000 Lemmata (1/4 bereits vorhanden) 

• Display formaler Theorien ähnlich zur Textbuchform 

– mathematische Fonts, optionale Unterdrückung von Details, variable Displayform 

– Notation austauschbar durch NuPRL’s Display-Mechanismus 

· mathematisch: x ∈ S, S∪S’, {f(x)|x ∈ S ∧ p(x)} . . . 

· Programmiersprache: element(x,S), union(S,S’), mapfilter(f,S,p). . . 

Verifizierte Softwareentwicklungssysteme 5 Repräsentation durch Definition

Grundkonzepte der Programmierung 

• Repräsentation: Datentypen & Prädikate höherer Stufe 

SPECS ≡ D:TYPES × R:TYPES × D→IB × D×R→IB 

PROGRAMS ≡ spec:SPECS × D(spec)→R(spec) 

program is correct ≡ let ((D,R,I,O), body) = program in 

∀x:D. I(x) ⇒ O(x,body(x)) 

spec is satisfiable ≡ let... ∃body:D→R. (spec,body) is correct 

+ Notationen für komplexe Strukturen: 

FUNCTION f(x: D ): R WHERE I (x) RETURNS y SUCH THAT O (x,y) = body (x) 

FUNCTION f(x: D ):Set( R ) WHERE I (x) RETURNS { z | O (x,z)} = body (x) 

⇓ 

Programmynthese ˆ= ⊢ specification is satisfiable 

Verifizierte Softwareentwicklungssysteme 6 Repräsentation durch Definition

Repräsentation von Synthesestrategien 

• Strategie ˆ= semantisch motivierbare Umformung + syntaktische Suche 

• Semantische Einsicht ˆ= Metatheorem (innerhalb der Theorie) 

∀ parameters involved in the context. | ∀spec=(D,R,I,O):SPECS. 

main goal | spec is satisfiable 

⇐ precondition 1 | ⇐ ∀x:D. I(x) ⇒ ∃y:R.O(x,y) 

. | 

∧ precondition n | 

↦→ logisch-formale und verständliche Repräsentation 

+ formale Verifikation außerhalb des eigentlichen Syntheseprozesses 

+ abgeleitete Inferenzregel auf hohem Abstraktionsniveau 

– korrekt, verständlich & effizient (keine run-time Verifikation) 

+ implizites Verfahren zur Algorithmenkonstruktion 

– effiziente generierte Programme 

• Suchverfahren ˆ= Parameterbestimmung für Theorem 

⇒ verifizierte Implementierung durch Theoremaufruf 

Verifizierte Softwareentwicklungssysteme 7 Repräsentation durch formale Theoreme

Entwurf von Globalsuch-Algorithmen: 

Manipulation von Kandidatenmengen zur Bestimmung aller Lösungen 

Allgemeine Programmstruktur: (mathematische Notation) 

FUNCTION F(x:D):Set(R) WHERE I(x) RETURNS { z | O(x,z)} 

= if Φ(x,s 0 (x)) then Fgs(x,s 0 (x)) else ∅ 

FUNCTION Fgs(x,s:D×S):Set(R) WHERE I(x) ∧ J(x,s) ∧ Φ(x,s) 

RETURNS { z | O(x,z) ∧ sat(z,s)} 

= { z | z ∈ ext(s) ∧ O(x,z) } ∪ ∪{ Fgs(x,t) | t ∈ split(x,s) ∧ Φ(x,t) } 

• Deskriptoren s ∈ S für Kandidatenmengen 

J(x,s) : s sinnvoll für x — sat(z,s) : z gehört zur “Menge” s 

• Initialdeskriptor s 0 (x) ∈ S – umfaßt alle Lösungen 

• Direkte Extraktion ext(s) ∈ Set(R) von Lösungskandidaten 

• Suche: rekursive Aufspaltung split(x,s) ∈ Set(S) von Deskriptoren 

• notwendige Filter Φ(x,s) – Elimination unnötiger Deskriptoren 

+ 5 Axiome für Korrektheit und Terminierung 

⇒ wohlfundierte “Globalsuchtheorie” liefert korrekte Lösung 

Verifizierte Softwareentwicklungssysteme 8 Globalsuch-Strategie

GS-Theorie und Filter: Beispiele 

gs seq(α) ≡ D ↦→ Set(α) 

R ↦→ Seq(α) 

I ↦→ λS. true 

O ↦→λS, L. range(L)⊆S 

S ↦→ Seq(α) 

J ↦→λS, V. range(V)⊆S 

s 0 ↦→ λS. [] 

sat ↦→λL, V. V⊑L 

split↦→λS, V. {V·i|i ∈ S} 

ext ↦→ λV. {V} 

Lemma: ∀α:TYPES. ∀k:IN. 

- gs seq(α) is a GS theory 

- λS,V.|V|≤k wf-filter for gs seq(α) 

- λS,V.|V|≤k*length(S) wf-filter for gs seq(α) 

- λS,V.nodups(V) wf-filter for gs seq(α) 


GS-Theorien: Formalisierung von Struktur und Axiomen 

GS ≡ spec:SPECS × S:TYPES × D×S→IB × ... 

G is a GS-theory 

≡ let ((D,R,I,O), S, J, s 0 , sat, split, ext) = G in 

∀x:D. I(x) ⇒ s 0 (x) halts ∧ J(x,s 0 (x)) 

∧ ∀x:D.∀s:S. I(x) ∧ J(x,s) ⇒ ∀t ∈ split(x,s).J(x,t) 

∧ ∀x:D.∀z:R. I(x) ∧ O(x,z) ⇒ sat(z,s 0 (x)) 

∧ ∀x:D.∀s:S. I(x) ∧ J(x,s) ⇒ ∀z:R.O(x,z) ⇒ 

sat(z,s) ⇔ ∃k:IN.∃t ∈ split k (x,s). z ∈ ext(t) 

Filters(G) 

≡ let ...=G in D×S→IB 

Φ necessary for G 

≡ let ...=G in ∀x:D.∀s:S. ∃z:R. sat(z,s) ∧ O(x,z) ⇒ Φ(x,s) 

Φ wf-filter for G 

≡ let ...=G in ∀x:D.∀s:S. I(x) ∧ J(x,s) ⇒ 

∃k:IN. splitΦ k (x,s) = ∅ 

G generalizes spec with θ 

≡ let ...=G. and (D’,R’,I’,O’)=spec in 

R’⊂R ∧ 

Gθ(spec) ... 

. 

∀x:D’. I’(x) ⇒ I(θ(x)) ∧ ∀z:R’. O’(x,z) ⇒ O(θ(x),z) 


Entwurfsstrategie: Formalisierung als Theorem 

∀spec=(D,R,I,O):SPECS. 

FUNCTION F(x:D):Set(R) WHERE I(x) RETURNS {z | O(x,z)} is satisfiable 

⇐ ∃G:GS. G is a GS-Theory 

∧ ∃θ:D→DG. G generalizes spec with θ 

∧ ∃Φ:Filters(G). Φ wf-filter for G ∧ Φθ necessary for Gθ(spec) 

∧ ∃Ψ:Filters(Gθ(spec)). Ψ necessary for Gθ(spec) 

Beweisskizze: 

Gegeben: G = ((D’,R’,I’,O’), S, J, s 0 , sat, split, ext), θ, Φ, und Ψ. 

Lösungsprogramm: Instantiierung des Standard-Globalsuchalgorithmus (mathematische Notation) 

letrec fgs(x,s) = { z | z ∈ ext(s) ∧ O(x,z) } 

∪ ∪{ fgs(x,t) | t ∈ split(θ(x),s) ∧ Φ(θ(x),t) ∧ Ψ(x,t) } 

in 

if Φ(θ(x),s 0 (θ(x))) ∧ Ψ(x,s 0 (θ(x))) then fgs(x,s 0 (θ(x))) else ∅ 

Korrektheit: Induktion (Anzahl Rekursionsschritte bis Splitting unmöglich) + Wohlfundiertheit 

(Formaler Beweis mit NuPRL) 


Entwurfsstrategie: Theoremanwendung + Folgeschritte 

1. Formuliere Syntheseproblem als Beweisziel 

⊢ FUNCTION F(x: D ):Set( R ) WHERE I(x) RETURNS {z | O(x,z) } 

is satisfiable 

2. Wende Synthesetheorem an wie eine Inferenzregel 

3. Als Unterziel bestimme G, θ, Φ und Ψ. 

(a) Wähle GS-theorie G aus Wissensbank (enthält 6-10 GS-theorien) 

mit Bildbereich R oder einer Obermenge davon 

(b) Bestimme Substitution θ 

Direkt oder Extraktion aus konstruktivem Beweis der Generalisierung 

(c) Wähle wf-filter Φ für G aus Wissensbank (3-4 Möglichkeiten) 

Zeige: Φθ notwendig für Gθ(spec) 

(d) Bestimme zusätzlichen Filter Ψ heuristisch 

Eigenschaften von x und s, die leicht aus sat(z,s) ∧ O(x,z) ableitbar sind 

⇒ ENDE: System extrahiert Instanz des Standard-Globalsuchalgorithmus 


Costas Arrays Synthese: Problemstellung 

Costas Array der Größe n: Permutation von {1..n} ohne doppelte Elemente in 

den Zeilen der Differenzentafel 

1 4 2 3 

-3 2 -1 

-1 1 

-2 

Ziel: Berechnung aller Costas Arrays der Größe n 

0. Formalisiere unbekannte Begriffe: 

perm(L,S) ≡ nodups(L) ∧ range(L)=S 

dtrow(L,j) ≡ [L[i]-L[i+j] | i ∈ [1..length(L)-j] ] 

1. Formalisiere Syntheseproblem als Beweisziel 

FUNCTION Costas(n: Z):Set( Seq( Z) ) WHERE n≥1 

RETURNS {p | perm(p,{1..n}) ∧ ∀j ∈ dom(p).nodups(dtrow(p,j))} 


Verifizierte Softwareentwicklungssysteme 13 Costas Arrays Synthese

# top 

Costas Arrays Synthese 2: Zentraler Schritt 

⊢ FUNCTION Costas(n: Z):Set( Seq( Z) ) WHERE n≥1 



BY call ‘GS-theorem‘ 

1. ⊢ ∃G. G is a GS-Theory 

∧ ∃θ. G generalizes spec with θ 

∧ ∃Φ. Φ wf-filter for G ∧ Φθ necessary for Gθ(spec) 

∧ ∃Ψ. Ψ necessary for Gθ(spec) 

where spec = ( Z, Seq( Z), λn. n≥1, 

λn,p. perm(p,{1..n}) ∧ ∀j ∈ dom(p).nodups(dtrow(p,j)) ) 

Typinformation zugunsten der Lesbarkeit unterdrückt (Display-Mechanismus) 

Restliche Aufgabe: Bestimmung von G, θ, Φ und Ψ. 

– Extraktion des Algorithmus automatisch nach Lösung dieses Ziels 


# top 1 

Costas Arrays Synthese 3(a): Wahl der GS-Theorie 

⊢ ∃G. G is a GS-Theory 

∧ ∃θ. G generalizes spec with θ 

∧ ∃Φ. Φ wf-filter for G ∧ Φθ necessary for Gθ(spec) 

∧ ∃Ψ. Ψ necessary for Gθ(spec) 


λn,p. perm(p,{1..n}) ∧ ∀j ∈ dom(p).nodups(dtrow(p,j)) ) 

BY ∃-intro gs seq( Z) THEN unfold ‘perm‘ 

1. ⊢ gs seq( Z) is a GS-Theory 

2. ⊢ ∃θ. gs seq( Z) generalizes spec with θ 

∧ ∃Φ. Φ wf-filter for gs seq( Z) ∧ Φθ necessary for gs seq( Z)θ(spec) 

∧ ∃Ψ. Ψ necessary for gs seq( Z)θ(spec) 


λn,p. nodups(p) ∧ range(p)={1..n} ∧ ∀j ∈ dom(p).nodups(dtrow(p,j)) ) 

Teilziel 1 ˆ= Lemma der Wissensbank 


# top 1 2 

Costas Arrays Synthese 3(b): Bestimmung der Substitution θ 

⊢ ∃θ. gs seq( Z) generalizes spec with θ 

∧ ∃Φ. Φ wf-filter for gs seq( Z) ∧ Φθ necessary for gs seq( Z)θ(spec) 

∧ ∃Ψ. Ψ necessary for gs seq( Z)θ(spec) 



BY ∃-intro λn.{1..n} 

1. ⊢ gs seq( Z) generalizes spec with λn.{1..n} 

where spec = ...... 

2. ⊢ ∃Φ. Φ wf-filter for gs seq( Z) ∧ Φθ necessary for gs seq( Z)λn.{1..n}(spec) 

∧ ∃Ψ. Ψ necessary for gs seq( Z)λn.{1..n}(spec) 


Teilziel 1 lösbar durch einfachen Beweiser 


# top 1 2 2 

Costas Arrays Synthese 3(c): Wahl des Filters Φ 

⊢ ∃Φ. Φ wf-filter for gs seq( Z) ∧ Φθ necessary for gs seq( Z)λn.{1..n}(spec) 

∧ ∃Ψ. Ψ necessary for gs seq( Z)λn.{1..n}(spec) 



BY ∃-intro λS,V.nodups(V) 

1. ⊢ λS,V.nodups(V) wf-filter for gs seq( Z) 

2. ⊢ λn,V.nodups(V) necessary for gs seq( Z)λn.{1..n}(spec) 


3. ⊢ ∃Ψ. Ψ necessary for gs seq( Z)λn.{1..n}(spec) 


Teilziel 1 ˆ= Lemma der Wissensbank 


Costas Arrays Synthese 3(c/d): Φθ notwendig/ Wahl von Ψ 

# top 1 2 2 2 

⊢ λn,V.nodups(V) necessary for gs seq( Z)λn.{1..n}(spec) 



BY undo abstractions THEN unfold ‘specialize‘ THEN unfold ‘necessary‘ 

1. ⊢ ∀n.∀V. (∃p. nodups(p) ∧ range(p)={1..n} ∧ ∀j ∈ dom(p).nodups(dtrow(p,j)) ∧ V⊑p) 

⇒ nodups(V) 

* BY autotactic 

# top 1 2 2 3 

⊢ ∃Ψ. Ψ necessary for gs seq( Z)λn.{1..n}(spec) 


(autotactic zerlegt logisch und konsultiert dabei Fakten der Wissensbank) 

BY undo abstractions THEN unfold ‘specialize‘ THEN unfold ‘necessary‘ 

1. ⊢ ∃Ψ.∀n.∀V. (∃p. nodups(p) ∧ range(p)={1..n} ∧ ∀j ∈ dom(p).nodups(dtrow(p,j)) ∧ V⊑p) 

⇒ Ψ(n,V) 

* BY ∃-intro λn,V. ∀j ∈ dom(V).nodups(dtrow(V,j) THEN autotactic 


Costas Arrays Synthese: generiertes ausführbares Programm 



= 

letrec Costasgs(n,V) = 

{ p | p ∈ {V} ∧ perm(p,{1..n}) ∧ ∀j ∈ dom(p).nodups(dtrow(p,j))} 

∪ ∪ { Costasgs(n,W) | W ∈ {V·i|i ∈ {1..n}} ∧ nodups(W) 

∧ ∀j ∈ dom(W).nodups(dtrow(W,j)) } 

in 

if nodups([]) ∧ ∀j ∈ dom([]).nodups(dtrow([],j)) 

then Costasgs(n,[]) else ∅ 

Nach elementaren Optimierungen (weitere sind möglich) 



= 

letrec Costasgs(n,V) = 

(if perm(V,{1..n}) ∧ ∀j ∈ dom(V).nodups(dtrow(V,j)) then {V} else ∅) 

∪ ∪ { Costasgs(n,V·i) | i ∈ {1..n} ∧ nodups(V·i) ∧ 

∀j ∈ dom(V·i).nodups(dtrow(V·i,j)) } 

in 

Costasgs(n,[]) 


Laufende / geplante Forschungsarbeiten 

• Effiziente verifizierten Wissensbank 

– Computerrealisierung bisher formalisierter Anwendungsbereiche (900 Objekte, in Arbeit) 

– Formalisierung/Realisierung neuer Bereiche (ca. 4000 Objekte/Lehrbücher) 

– Automatische Instantiierung von Theoremen (Teilterm-matching 2. Stufe, in Erprobung) 

– Effiziente Organisation (eleganter Zugriff auf Lemmata) (Strukturierungsmethoden) 

• Repräsentation von Synthesestrategien 

– Globalsuch-Algorithmen, LOPS (Computerrealisierung in Arbeit) 

– Algorithmische Theorien (Divide& Conquer, Lokalsuche, . . . ) 

– Synthese durch Beweisplanung (Rippling, . . . ) (↦→ Diplomarbeiten) 

• Automatisierung konzeptionell einfacher Schlüsse 

– Matrix-basierte Beweisprozedur für konstruktive Logik (in Arbeit / Doktoranden) 

– anwendungsspezifische Beweistaktiken 

• Exemplarische Erprobung (Testbeispiele) 

Verifizierte Softwareentwicklungssysteme 20 Ausblick / Forschungsrichtungen

Ausblick 

• Formales Schließen auf sehr hohem Abstraktionsniveau 

– keine Abhängigkeit vom speziellen Kalkül (NuPRL) 

– Synthesen auch bei geringer automatischer Unterstützung möglich 

⇒ tatsächliche Kooperation zwischen Mensch und Maschine 

• Formale Theorie: Bindeglied zwischen ‘informaler’ Beschreibung und 

Realisierung von Strategien 

– Formulierung nahezu identisch mit Papierversion 

– Realisierung mit Beweiseditor ohne Modifikation 

⇒ verifizierte und effiziente Implementierung 

⇒ Integration verschiedener Programmsyntheseverfahren möglich 

– Erweiterbar auf andere Bereiche der Deduktion (Planen, Beweisen, . . . ) 

⇓ 

Fundament für flexible, praktisch nutzbare 

und zuverlässige Softwareentwicklungssysteme 

Verifizierte Softwareentwicklungssysteme 21 Ausblick / Forschungsrichtungen

Ein Fundament für Verifizierte Softwareentwicklungssysteme

Sie wollen auch ein ePaper? Erhöhen Sie die Reichweite Ihrer Titel.

Template löschen?

Als Template speichern?