Isabelle - A Generic Theorem Proving Environment

Transkript

1 Westfälische Wilhelms-Universität Münster Ausarbeitung Isabelle - A Generic Theorem Proving Environment im Rahmen des Seminars Formale Spezifikation Markus Heinrich Themensteller: Prof. Dr. Herbert Kuchen Betreuer: Dipl.-Wirt.Inform. Christoph Lembeck Institut für Wirtschaftsinformatik Praktische Informatik in der Wirtschaft

2 Inhaltsverzeichnis 1 Einleitung Grundlagen des Theorem Proving mit Isabelle/HOL Kurzbeschreibung von Isabelle/HOL Definitionen Das Beweisen von Theoremen mit Isabelle/HOL Beweise im Rahmen funktionaler Programmierung Datentypen Funktionen Beweise von funktionalen Programmen Beweise im Rahmen der Logik Beweise mit Hilfe von Regeln Beweise mit Hilfe des Classical Reasoner Proof-General und Isabelle Praktische Anwendungen Zusammenfassung Literaturverzeichnis II

3 Abbildungsverzeichnis Abb.: 1 Beispiele für α und β Regeln Abb.: 2 Anwendung des Tableauverfahrens Abb.: 3 Screenshot Proof-General Abb.: 4 Arbeiten mit Proof-General III

4 Kapitel 1: Einleitung 1 Einleitung In den letzten Jahrzehnten sind Softwareprogramme und ihre dazugehörige Hardware ein Teil des täglichen Lebens geworden. Sie steuern heute unterschiedlichste Maschinen, von Waschmaschinen über Airbags, bis hin zu Atomkraftwerken. Eine Möglichkeit die Korrektheit dieser Programme zu überprüfen, besteht darin, ausgiebige Tests durchzuführen. Der Nachteil dieser Methode ist, dass sie zwar Fehler finden kann, jedoch keinen Beweis liefert, dass eine Software fehlerfrei ist [Oh00]. In sicherheitskritischen Bereichen empfiehlt es sich daher, die Korrektheit der Programme formal zu beweisen. In der Vergangenheit wurden diese Beweise von Hand geführt. Dies ist jedoch zum einen fehleranfällig, zum anderen mit zunehmender Komplexität der Programme nicht mehr praktikabel [Oh00]. An dieser Stelle setzt das Forschungsgebiet das "automated Theorem Proving" an. Ziel ist es die Beweisführung mit Hilfe von Rechnern und Software zu unterstützen und damit zum einen die Komplexität zu reduzieren und zum anderen die Wahrscheinlichkeit von Fehlern in der Beweisführung zu verringern. Neben der Verifikation von Soft- und Hardware befasst sich das automated Theorem Proving mit der Unterstützung von mathematischen und logischen Beweisen. Das Forschungsgebiet lässt sich in zwei Bereiche unterteilen: "fully-automated Theorem Proving" und "semi-automatic Theorem Proving". Im Gegensatz zum "fully-automated Theorem Proving" findet beim "semi-automatic Theorem Proving" während der Beweisführung, eine mehr oder weniger starke Interaktion zischen Computer und Benutzer statt, in dessen Verlauf der Mensch die Beweisführung lenkt. Im Rahmen dieser Seminararbeit wird der "semi-automatic Theorem Prover" Isabelle/HOL vorgestellt. Hierzu wird zunächst das Programm grob beschrieben und anschließend die zentralen Grundbegriffe definiert. Im Hauptteil wird dargelegt wie man Beweise mit Hilfe von Isabelle durchführen kann. Hierbei erfolgt eine Unterteilung in die Bereiche funktionale Programmierung und Logik. Im Anschluss daran wird Isabelles grafische Benutzeroberfläche Proof-General beschrieben. Abschließend werden einige praktische Anwendungen dargelegt. Im letzten Kapitel werden die Ergebnisse zusammengefasst und ein kurzer Ausblick auf mögliche Entwicklungen gegeben. 1

5 Kapitel 2: Grundlagen des Theorem Proving mit Isabelle/HOL 2 Grundlagen des Theorem Proving mit Isabelle/HOL 2.1 Kurzbeschreibung von Isabelle/HOL Isabelle ist ein generischer, semiautomatischer Theorem Prover, welcher mit einer Reihe verschiedener Logiken instanziiert werden kann. Das hier vorgestellte Isabelle/HOL ist eine besonders weit entwickelt Instanz von Isabelle für Beweise im Rahmen der Higher Order Logic [Me00]. Das Programm Isabelle wurde in der Programmiersprache ML implementiert. Die Abkürzung ML steht für "Meta Language". ML wurde ursprünglich für die Interaktion zwischen Mensch und Maschine beim Durchführen von Beweisen entwickelt. An einigen Stellen wurde die Syntax von Isabelle/HOL daher von ML beeinflusst [NPW04]. Neben der hier vorgestellten Isabelle/HOL-Syntax existiert eine Erweiterung mit dem Namen Isabelle/HOL/ISAR [Ni02]. Sie verfolgt das Ziel die Beweisführung für Menschen lesbarer zu machen und eignet sich besonders für mathematische Beweise [MF03]. Ein Nachteil der ISAR-Syntax ist jedoch, dass der Benutzer eine genaue Vorstellung davon haben muss, welche Fakten in jeder Phase des Beweises als nächstes bewiesen werden müssen [MF03]. Dies erschwert den Einstieg in Isabelle und ist der Grund dafür, dass im Folgenden die Isabelle/HOL-Syntax beschrieben wird. Um die Wirkungsweise von Isabelle zu verdeutlichen, erfolgt bei der Erklärung eine Zweiteilung in die Bereiche funktionale Programmierung und Logik. In jedem umfangreicheren Beweis wird man jedoch weder ausschließlich mit funktionaler Programmierung noch exklusiv mit Logik arbeiten können. Da Isabelle jedoch ein relativ komplexes Werkzeug ist, erscheint die Zweiteilung trotz allem sinnvoll, um den Überblick über das Programm zu erleichtern. Für die Eingabe der Theorien in Isabelle stehen im Wesentlichen zwei verschiedene Möglichkeiten zur Verfügung. Zum einen ist eine Interaktion auf Shell-Ebene möglich, zum anderen steht die grafische Benutzeroberfläche "Proof-General" zur Verfügung. Proof-General wurde von DAVID ASPINALL entwickelt und ist das in der Praxis zur Zeit empfohlene und meist verwendete Software Produkt zum Ausführen von Beweisen mit Isabelle [NPW04]. 2

6 Kapitel 2: Grundlagen des Theorem Proving mit Isabelle/HOL 2.2 Definitionen Bevor die Durchführung von Beweisen mit Hilfe von Isabelle begonnen werden kann, sollen zunächst einige häufig verwendete Begriffe definiert werden. Das Zentrale Konstrukt bei der Verwendung von Isabelle sind die Theorien. Theorien basieren auf bereits bestehenden Theorien und enthalten Deklarationen, Definitionen, Theoreme und Lemmata. Dies lässt sich wie folgt darstellen [NPW04]: Theorie T = T T n : Deklarationen, Definitionen, Theoreme und Lemmata Ende T steht dabei für eine Theorie, die auf den bestehenden Theorien T 1 bis T n aufbaut. Die eigentliche Beweisführung erfolgt innerhalb der Theoreme und Lemmata. Um eine Strukturierung der Beweise zu unterstützen bietet es sich an, den Begriff Theorem übergeordnet zu dem Begriff Lemma zu verwenden. Weitere wichtigere Begriffe sind Typen, Funktionen, und Variablen. Beispiele für Typen sind Basistypen, wie z.b. Wahrheitswerte oder die natürlichen Zahlen. Funktionen sind dadurch definiert, dass sie für jeden gegeben Input genau einen Output liefern. In Isabelle dürfen nur totale Funktionen verwendet werden. Dies bedeutet, dass alle Funktionen für jeden Input terminieren müssen [NPW04]. Variablen werden in Isabelle in drei verschiedene Arten unterschieden: Gebunde, ungebundene und schematische Variablen. Schematische Variablen können vom Programm mit einem beliebigen Wert initialisiert werden. Ein geläufigerer Begriff für diese Arten von Variablen, z.b. aus der Programmiersprache Prolog, ist logische Variable. Terme entstehen durch das Anwenden von Funktionen auf Argumente. Sei f eine Funktion vom Typ τ 1 =>τ 2 und t vom Typ τ 1. So ist f(t) ein Term vom Typ τ 2. Formeln sind eine spezielle Form von Termen. Sie sind vom Typ bool und verwenden die logischen Operatoren. Isabelle besitzt eine eigene Meta-Logik, welche drei verschiedene Symbole unterscheidet. Das Zeichen ==> ist das Meta-Symbol für Implikation [Me00]. Ein == drückt Gleichheit aus, es kann zur Definition von Konstanten verwendet werden [NPW04]. Das dritte Symbol ist der universelle Quantor!! auf Meta-Ebene. In den hier beschriebenen Anwendungen wird er allerdings nur von Isabelle intern verwendet. 3

7 3 Das Beweisen von Theoremen mit Isabelle/HOL 3.1 Beweise im Rahmen funktionaler Programmierung Datentypen Datentypen, und im speziellen induktive Datentypen, sind ein zentraler Bestandteil von funktionaler Programmierung und als solche auch ein zentraler Bestandteil von Isabelle. Die allgemeine Datentypdefinition in Isabelle entspricht dem folgenden Schema [NPW04]: datatype (,..., ) t = C C... 1 n k1 m m1 mkm Wobei die α i für verschiedene Typenvariablen des Datentyps stehen, und t für die Bezeichnung des eigentlichen Datentyps. Die C i sind Namen für Konstruktoren. Die Parameter τ ij beschreiben die Typenvariablen der Konstruktoren. Das klassische Beispiel für induktive Datentypen im Rahmen der funktionalen Programmierung sind Listen. Listen bestehen aus einem Kopf und einem Rest, wobei der Rest wiederum eine Liste ist. In Isabelle wird der Datentyp Liste wie folgt definiert: datatype 'a list = Nil Cons 'a "'a list" Der Konstruktor Nil steht für die leere Liste. Ein weiteres wichtiges Beispiel für induktive Datentypen sind Bäume. Für die Definition von Bäumen benötigt man, in enger Anlehnung an die Listen, zum einen ein Konstruktor für einen leeren Knoten, zum anderen ein Konstruktor für einen existierenden Knoten: datatype 'a baum = Nil Knoten "'a baum" 'a "'a baum" Isabelle bietet für Datentypen die Möglichkeit an, eine alternative Notation einzuführen. Dies führt zu einer erheblichen Vereinfachung bei der Darstellung. So müsste man für die Beschreibung einer einfachen Liste mit dem Inhalt 1 und 2 in herkömmlicher Weise folgende Darstellung wählen: Cons 1(Cons2 Nil). Definiert man den Datentypen jedoch wie folgt: datatype 'a list = Nil Cons 'a "'a list" ( infixr "#" 65) 4

8 lässt sich der oben beschriebene Sachverhalt als 1#2#Nil ausdrücken. Hierbei führt infixr zum einen Infix-Notation ein und legt zum anderen fest, dass das Zeichen # zur rechten Seite bindet. Die Zahl 65 gibt die Priorität des Zeichens an. Abstrakte Datentypen können in Isabelle mit Hilfe von typedecl definiert werden. In seltenen Fällen kann die Anwendung von typedef notwendig sein [NPW04]. Mit diesem Schlüsselwort lassen sich neue Typen aus Untermengen von bereits bestehenden Typen erstellen Funktionen Funktionen sind der zweite wichtige Bestandteil funktionaler Programmierung. Es ist wichtig festzuhalten, dass in Isabelle jede verwendete Funktion explizit deklariert sein muss [NPW04]. Verwendet man bei der Deklaration eine freie Typenvariable, führt Isabelle beim Aufruf der Funktion eine automatische Typeninferenz aus. Um die Lesbarkeit zu erhöhen empfiehlt es sich jedoch, die verwendeten Typen explizit anzugeben. Eine Funktion mal2 welche eine natürliche Zahl verdoppelt könnte demnach auf die folgenden zwei Arten deklariert werden: consts consts mal2 :: "'a => 'a" mal2 :: "nat => nat" Die Definition nicht rekursiver Funktion erfolgt mit Hilfe des Schlüsselwortes defs: defs mal2_def: "mal2 n == 2*n" Wobei mal2_def der Name der Definition ist. Konstanten können mit Hilfe des Schlüsselwortes constdefs definiert werden. Definitionen werden während eines Beweises nicht automatisch expandiert. Dies geschieht manuell mit Hilfe von: apply (unfold < Name der Definition >) Bei rekursiven Funktionen muss sichergestellt werden, dass sie trotz rekursiver Aufrufe terminieren. In Isabelle kann dies auf zwei verschiedene Arten geschehen. Bei der ersten Möglichkeit wird das Schlüsselwort primrec verwendet. Es kann immer dann angewandt werden, wenn eine rekursive Funktion über einen induktiven Datentypen definiert wird, wobei das Argument der Funktion bei jedem rekursiven Aufruf kleiner werden muss. In diesem Fall beweist Isabelle die Terminierung der Funktion automatisch. Allgemein lässt sich dies wie folgt darstellen [NPW04]: 5

9 primrec f (x... (C... )... x ) = r k1 n f (x... (C... )... x ) = r 1 m m1 mkm nm m Wobei f für die Funktion, C i die Konstruktoren des Datentyps, τ ij für die Typenvariablen des Konstruktors und die x s für sonstige Variablen stehen, welche nicht unbedingt vorhanden sein müssen. Um primrec anwenden zu können müssen alle rekursiven Aufrufe in r a die folgende Form aufweisen: f(a 1... aj... a n a ) Eine weitere Restriktion von primrec ist, dass nur eine rekursive Gleichung pro Konstruktor erlaubt ist, wobei die Reihenfolge keine Rolle spielt [NPW04]. Ein einfaches Beispiel für die Verwendung von primrec ist die folgende Funktion, welche eine Liste in umgekehrter Reihenfolge darstellt: consts primrec "umd [] = []" umd :: "'a list => 'a list" "umd(x # xs) = (umd (x # [])" Die zweite Variante verwendet das Schlüsselwort recdef. Im Gegensatz zu primrec ist der Nutzer bei der Verwendung von recdef nicht auf die Rekursion über Datentypen beschränkt. Allerdings muss explizit eine Funktion measure definiert werden, welche bei jedem rekursiven Aufruf kleiner wird. Das Umdrehen einer Liste könnte demnach auch wie folgt definiert werden: consts recdef "umd [] = []" umd :: "'a list => 'a list" umd measure(%liste. length liste) "umd(x # xs) = (umd (x # [])" In der zweiten Zeile wird bei jedem Aufruf explizit die Länge der Liste gemessen. In einfachen Fällen kann Isabelle die Terminierung der Rekursion mit Hilfe der Funktion measure direkt beweisen. Sollte dies nicht gelingen, muss der Benutzer den Beweis selbst führen. Wichtig ist hierbei, dass die Funktion measure nicht das eigentliche Abbruchkriterium darstellt, sondern lediglich dazu verwendet wird, die Terminierung der Funktion zu beweisen. Folglich ist die Funktion measure nicht an einen bestimmten Wertebereich gebunden [NPW04]. 6

10 Auch für Funktionen lassen sich abkürzende Schreibweisen definieren. Eine Funktion anhlist, welche eine Liste an eine andere Liste anhängt, kann wie folgt deklariert werden: consts anhlist :: "'a list => 'a list => 'a list" ( infixr "@" 65) Beweise von funktionalen Programmen Nachdem die wichtigsten Bereiche der funktionalen Programmierung in Isabelle vorgestellt wurden, soll im Folgenden die Beweisführung für funktionale Programme dargestellt werden. Isabelle besitzt eine vordefinierte Theorie Main. In ihr sind eine Reihe von wichtigen Theorien, wie z.b. für arithmetische Berechnungen und Listen zusammengefasst. In den meisten Fällen empfiehlt es sich, die Theorie Main als Basis für Beweise einzubinden. Neben dem Einbinden der benötigten Theorien muss jeder neuen Theorie ein Name gegeben werden. Dieses Beispiel verwendet zur Illustration einen binären Baum und erhält daher den Namen BBaum. In Isabelle Syntax ergibt sich: theory BBaum = Main: Des Weiteren wird der Konstruktor für den Baum benötigt. Wie bereits oben erwähnt, lässt sich ein Binärbaum wie folgt beschreiben: datatype 'a baum = Nil Knoten "'a baum" 'a "'a baum" Es soll im Folgenden bewiesen werden, dass ein zweimal vertikal gespiegelter Baum wieder dem ursprünglichen Baum entspricht. Die Spiegelung eines Baumes lässt sich rekursiv mit Hilfe von primrec definieren. An dieser Stelle soll jedoch zur Illustration nicht primrec sondern recdef verwendet werden. Um recdef anwenden zu können, muss zunächst eine Funktion measure Funktion definiert werden. Diese könnte z.b. wie folgt aussehen: consts anzahlk :: "'a baum => nat" primrec "anzahlk Nil = 1" "anzahlk (Knoten l v r) = anzahlk(knoten l) anzahlk(knoten r)" In der ersten Zeile wurde die Funktion anzahlk zunächst deklariert. Die Funktion bildet einen Baum entsprechend der Anzahl seiner Knoten auf eine natürliche Zahl ab. Die Bestimmung der Anzahl der Knoten in einem Baum kann rekursiv mit Hilfe von primrec erfolgen. 7

11 Nachdem die measure Funktion definiert ist, kann die Funktion für die Spiegelung mit Hilfe von recdef definiert werden: consts spiegeln :: "'a baum => 'a baum" recdef "measure(%a. zaehler(a))" "spiegeln Nil = Nil" "spiegeln (Knoten l v r) = spiegeln(knoten r) + v + spiegeln(knoten l)" Die Deklaration in der ersten Zeile legt fest, dass bei einer Spiegelung eines Baumes wieder ein Baum entsteht. Ein gespiegelter leerer Baum ergibt wieder einen leeren Baum. Das Spiegeln eines nicht leeren Baumes geschieht durch rekursives Vertauschen der Subbäume. Nachdem die benötigten Funktionen definiert sind, kann mit dem eigentlichen Beweis begonnen werden. Dazu muss zunächst das zu beweisende Theorem aufgestellt werden. In Isabelle lässt es sich wie folgt darstellen: theorem spiegel2 : "spiegeln(spiegeln(a)) = a" Isabelle liefert daraufhin das erste zu lösende Subgoal, welches dem Theorem entspricht: goal (theorem (spiegel2), 1 subgoal): 1. spiegeln (spiegeln a) = a In der ersten Zeile kann man ablesen, dass in dem Theorem spiegel2 ein Subgoal zu lösen ist. In der folgenden Zeile ist es nummeriert aufgeführt. An dieser Stelle wird deutlich, dass es sich bei Isabelle um einen semi-automatischen Theorem Prover handelt: Isabelle gibt ausschließlich das zu lösende Subgoal aus. Hinweise darauf welche Methode zur Lösung anzuwenden ist, liefert das Programm nicht. Eigenschaften rekursiv definierter Funktionen lassen sich häufig mit Hilfe von Induktion beweisen [NPW04]. Das Verwenden von Methoden, die auch Tactics genannt werden, erfolgt in Isabelle mit Hilfe des Schlüsselwortes apply. Für den hier vorliegenden Sachverhalt muss Induktion über die Variable a angewandt werden: apply (induct_tac a) Nach Durchführung der Induktion liefert Isabelle eine Reihe von neuen Subgoals, die nun ebenfalls zu beweisen sind. Das Programm gibt folgende Meldung aus: 8

12 goal (theorem (spiegel2), 2 subgoals): 1. spiegeln (spiegeln baum.nil) = baum.nil 2.!!baum1 a baum2. [ spiegeln (spiegeln baum1) = baum1; spiegeln (spiegeln baum2) = baum2 ] ==> spiegeln (spiegeln (Knoten baum1 a baum2)) = Knoten baum1 a baum2 In der ersten Zeile kann man ablesen, dass zwei neue Subgoals zu lösen sind. Das erste zu beweisende Subgoal besagt, dass ein leerer, zweimal gespiegelter Baum wieder einen leeren Baum ergibt. Das zweite Subgoal trifft die folgende Aussage: Wenn für einen Baum baum1 gilt, dass er zweimal gespiegelt wieder den Baum baum1 ergibt und wenn für einen Baum baum2 gilt, dass er zweimal gespiegelt wieder den Baum baum2 ergibt, dann gilt auch für einen Knoten baum1 a baum2, dass er zweimal gespiegelt, wieder den Knoten baum1 a baum2 ergibt. Die erste Zeile des zweiten Subgoals besagt, dass sich die Variablen baum1 a baum2 lokal auf dieses Subgoal beziehen. Erneut liefert Isabelle keinen Hinweis darauf, wie die beiden Subgoals zu lösen sind. In beiden Fällen muss Term Rewriting angewandt werden, welches in Isabelle durch die Methode simp ausgeführt wird. : apply (simp) Das Rewriting erfolgt durch sukzessive Anwendung instanziierter Gleichung, von links nach rechts, auf die entsprechenden Terme. Die verwendeten Gleichungen werden auch als Rewriting Rules bezeichnet. Das Rewriting wird im Folgenden am Beispiel des zweiten Subgoals näher beschrieben. Die Lösung des ersten Subgoals erfolgt analog. Die verwendeten Regeln ergeben sich hierbei aus der Definition der Funktion spiegeln, sowie den beiden Voraussetzungen des zweiten Subgoals: Regel1: Regel2: Regel3: Regel4: spiegeln Nil = Nil (Wird zum lösen des ersten Subgoals verwendet) spiegeln (Node l v r)= Node (spiegeln r) v (spiegeln l) spiegeln (spiegeln baum1) = baum1 spiegeln (spiegeln baum2) = baum2 Das zu beweisende Ziel des Subgoals lautet: spiegeln (spiegeln (Knoten baum1 a baum2)) = Knoten baum1 a baum2 Durch die Anwendung von simp werden die folgenden Schritte ausgeführt: 9

13 Anwenden von Regel2 liefert: spiegeln (Knoten spiegeln(baum2) a spiegeln(baum1)) = Knoten baum1 a baum2 Anwenden von Regel2 liefert: Knoten (spiegeln(spiegeln(baum1)) a spiegeln(spiegeln(baum2)) = Knoten baum1 a baum2 Anwenden von Regel3 liefert: Knoten baum1 a spiegeln(spiegeln(baum2)) = Knoten baum1 a baum2 Anwenden von Regel4 liefert: Knoten baum1 a baum2 = Knoten baum1 a baum2 An dieser Stelle erkennt simp, dass beide Seiten identisch sind. Der Term erhält den Wert True und das Subgoal ist gelöst. Die Methode simp muss für jedes Subgoal einzeln angewandt werden. Eine Alternative stellt die Methode auto dar, welche sich auf alle Subgoals gleichzeitig bezieht. In beiden Fällen liefert Isabelle nach Abschluss der Beweisführung folgende Meldung: goal (theorem (spiegel2)): No subgoals! Der Beweis des Theorems ist damit abgeschlossen und kann mit Hilfe von done beendet werden. Soll die gesamte Theorie geschlossen werden, kann dies mit Hilfe von end geschehen. Es ist möglich die Methode simp um neue Rewriting Regeln zu erweitern. Wird z.b. die Theorie spiegel2 am Anfang wie folgt definiert: theorem spiegel2 [simp] : "spiegeln(spiegeln(a)) = a" so wird nach Abschluss des Beweises und anschließendem Aufruf der Methoden simp oder auto, jedes Auftreten von spiegeln(spiegeln(a)) direkt durch a ersetzt. Durch das Hinzufügen eigener Regeln, kann es allerdings zu Endlosschleifen kommen, so dass ein Aufruf von simp im Worst-Case nicht terminiert [NPW04]. Viele Probleme im Rahmen funktionaler Programmierung lassen sich mit der oben beschriebenen Vorgehensweise lösen. Dies liegt daran, dass funktionale Programme in der Regel auf Rekursion beruhen und sich damit die Anwendung der Methode induct_tac empfiehlt. Eine Handlungseinleitung für die Beweisführung könnte demnach wie folgt aussehen: Anwenden der Methode induct_tac Anschließend Anwenden der Methode auto oder simp. In komplexeren Beweisen müssen diese Methoden in mehreren Iterationen angewendet werden; die Vorgehensweise bleibt allerdings dieselbe. In einigen Fällen kann anstelle von Induktion auch eine Fallunterscheidung durchgeführt werden. Die entsprechende 10

14 Methode heißt case_tac. Allerdings soll hier nicht weiter darauf eingegangen werden, da sich alle Probleme, die sich mit Hilfe von case_tac lösen lassen, auch mit der Methode induct_tac beweisen lassen [NPW04]. 3.2 Beweise im Rahmen der Logik Beweise mit Hilfe von Regeln Bisher wurde nur der funktionale Teil von Isabelle betrachtet. Im zweiten Teil wird die Logik Isabelles näher beschrieben. Das Ableiten von Beweisen im Rahmen der Logik erfolgt in Isabelle in der Regel durch "Backward Reasoning". Dies bedeutet, dass der Beweis ausgehend vom zu beweisenden Theorem geführt wird. "Forward Reasoning" ist in Isabelle ebenfalls möglich, spielt jedoch nach Aussagen der einschlägigen Literatur eine untergeordnete Rolle und wird daher im Folgenden nicht näher beschrieben [NPW04]. Für jeden logischen Operator gibt es zwei verschiedene Arten von Regeln [NPW04]: Einführungsregeln Eliminationsregeln Einführungsregeln treffen Aussagen darüber wie ein Sachverhalt, wie z.b. P1 P2, bewiesen werden kann. Eliminationsregeln hingegen beschreiben, was aus einem bestimmten Sachverhalt, wie z.b. P1 P2, bewiesen werden kann. Die Regeln, werden mit Hilfe der Methoden rule und erule aufgerufen: apply apply (rule <Einführungsregel>) (erule <Eliminationsregel>) Um die Funktionsweise von Isabelle zu verdeutlichen, soll im Folgenden die genaue Wirkungsweise der beiden Methoden beschrieben werden [NPW04]. Es wird von der folgenden allgemeinen Definition einer Regel ausgegangen. Zur Verdeutlichung sind zusätzlich zwei Beispiele angegeben: P 1... Pn A B A B A C B C rule: erule: Q A B C Das zu beweisende Subgoal sei wie folgt aufgebaut:... 1 m A A B 11

15 Durch das Anwenden einer Einführungsregel, mit Hilfe der Methode rule, werden die folgenden Schritte ausgeführt: Zunächst wird das Ziel Q der Regel mit dem Ziel B des zu lösenden Subgoals unifiziert. Anschließend wird das Ziel des zu lösenden Subgoals B durch die Voraussetzungen der Regel P 1 P n ersetzt. Auf diese Weise entstehen n neue Subgoals. Beim Anwenden einer Eliminationsregel, mit Hilfe der Methode erule, werden hingegen folgende Schritte durchlaufen: Zunächst wird, wie bei der Einführungsregel, das Ziel Q der Regel mit dem Ziel B des Subgoals unifiziert. Gleichzeitig wird jedoch die Voraussetzung P 1, welche in Isabelle auch Hauptvoraussetzung genannt wird, mit der ersten möglichen Annahme A 1 A m des Subgoals unifiziert. Anschließend wird die mit P 1 unfizierte Annahme A k gelöscht. Das Subgoal wird durch die Voraussetzungen P 2 P n der Regel ersetzt. Auf diese Weise entstehen n-1 neue Subgoals. Werden durch die Anwendung einer Regel mehrere neue Subgoals generiert, wird dies als Subgoalsplitting bezeichnet [NPW04]. Die Namen einzelner Regeln sowie deren Definitionen können in [NPW04] nachgelesen werden. Wichtig ist, dass sich die Anwendung der Methode rule auf die rechte Seite der Formel auswirkt, während die Anwendung von erule die linke Seite einer Formel beeinflusst. Zudem können einige Regeln sowohl als Einführungsregel als auch als Eliminationsregel angewandt werden. Ihre Wirkungsweise ist in diesem Fall abhängig von der verwendeten Methode [NPW04]. Die Regeln in Isabelle lassen sich des Weiteren in zwei verschiedene Arten aufteilen: Sichere und unsichere Regeln. Sichere Regeln zeichnen sich dadurch aus, dass ein beweisbares Subgoal auch nach der Anwendung der Regel beweisbar bleibt. Bei Anwendung einer unsicheren Regel kann die Beweisbarkeit unter Umständen verloren gehen. Das folgende Beispiel verdeutlicht diesen Sachverhalt und dient gleichzeitig zur Illustration für die Anwendung einer Regel in Isabelle. Die angewandte Regel heißt disji1 und ist wie folgt definiert: 12

16 P P Q Das zu beweisende Theorem sei in Isabelle wie folgt definiert: theorem disj : "[ A ] ==> B A" Da es sich bei disji1 bei um eine Einführungsregel handelt, muss sie wie folgt angewendet werden: apply (rule disji1) Isabelle liefert das folgende, nicht mehr beweisbare Subgoal: goal (theorem (disj), 1 subgoal): 1. A ==> B Eine Anwendung der Regel disji2, welche analog zu disji1 definiert ist, hätte das gewünschte Ergebnis geliefert: goal (theorem (disj), 1 subgoal): 1. A ==> A Steht das Ziel des Subgoals in den Annahmen, kann das Subgoal mit Hilfe der Methode assumption gelöst werden. apply (assumption) Für den Fall, dass Regeln in der gleichen Kombination mehrfach hintereinander angewendet werden müssen, bietet Isabelle verschiedene Kontrollstrukturen an. Die wiederholte Anwendung einer Regel kann zum einen mit Hilfe der Methoden intro und elim ausgeführt werden: apply apply (intro <Einführungsregel>) (elim <Eliminationsregel>) Eine alternative Darstellungsform bieten die Zeichen + und?. Ein + steht für mindestens eine Ausführung, ein? für eine oder keine Ausführung der Regel. Werden zwei Regeln mit dem Zeichen getrennt, wird zunächst die erste Methode ausgeführt. Scheitert sie, kommt die zweite Methode zur Anwendung [NPW04] Beweise mit Hilfe des Classical Reasoner Das Anwenden von Regeln mit Hilfe der oben beschriebenen Methoden gibt dem Benutzer eine genaue Kontrolle über die in der Beweisführung angewandten Schritte. 13

17 Viele Theoreme können jedoch nicht in einigen wenigen Schritten bewiesen werden, was die Anwendung einzelner Regeln unkomfortabel macht. In diesen Fällen kann Isabelles Classical Reasoner verwendet werden [Pa04]. Der Classical Reasoner stellt eine Reihe von Methoden zur Verfügung, mithilfe derer sich Beweise aus dem Bereich der Logik automatisch lösen lassen. Da der Classical Reasoner in vielen Fällen auch Probleme aus der Mengenlehre lösen kann, werden die Regeln aus diesem Bereich hier nicht vertieft. Die wichtigste dieser Methoden heißt blast [NPW04]. Anders als bei der Verwendung einzelner Regeln kommt bei der Anwendung von blast nicht die Isabelle eigene Engine zum Einsatz. Der zu führende Beweis wird stattdessen direkt an den Classical Reasoner übergeben. Dort wird mit Hilfe eines Tableau Provers versucht, den Beweis zu führen. Der Prover ordnet hierbei jedem durchgeführten Schritt die entsprechende Isabelle Regel zu. Ist ein Beweis gefunden, wird eine entsprechende Liste von Regeln an Isabelle zurückgegeben [Pa99]. Tableau Prover arbeiten mit Hilfe von Bäumen. Befinden sich Literale oder Formeln auf demselben Ast, bedeutet dies, dass sie konjunktiv verknüpft sind. An der Wurzel des Baumes steht die ursprünglich zu beweisende Formel in negierter Form. Die einzelnen Äste werden mit Hilfe von α, β, γ und δ Regeln aufgebaut. Eine α Regel zerlegt hierbei eine konjunktive Formel in zwei Teile und legt sie auf demselben Ast ab. Eine β Regel zerlegt eine disjunktive Formel in zwei Teile und legt sie auf unterschiedlichen Ästen ab. Eine γ Regel instanziiert einen universellen Quantoren, während eine δ Regel einen existentiellen Quantor instanziiert [Pa99]. Die Beweisführung ist erfolgreich abgeschlossen, wenn jeder Ast einen Widerspruch enthält. Der Tableau Prover verwendet bei der Beweisführung eine iterative Tiefensuche [Pa04]. Allgemein hat diese den Zeitaufwand O(b d ) [RN04]. Wobei b den Verzeigungsfaktor und d die Suchtiefe darstellt. Beide Faktoren, und damit die Komplexität der Beweisführung, hängen jedoch stark von dem zu lösenden Problem ab. Im Besonderen hängt der Verzweigungsfaktor mit Anzahl der verwendeten β Regeln zusammen. Im Worst-Case muss daher von einer exponentiellen Zeitkomplexität ausgegangen werden. Die Vorgehensweise soll an einem Beispiel illustriert werden. Zu beweisen sei: (P-->Q)==>( Q--> P) 14

18 In diesem Fall werden ausschließlich die folgenden α und β Regeln benötigt [Le03]: α Regeln β Regeln Nr. α α1, α2 β β1, β2 1 (P-->Q) P, Q P-->Q P, Q 2 P P Abb.: 1 Beispiele für α und β Regeln Der Baum, der sich durch Anwendung der Regeln ergibt, sieht wie folgt aus: ((P-->Q)==>( Q--> P)) Negierte zu beweisende Formel (P-->Q) αregel Nr.1 βregel Nr.1 ( Q--> P) P Q Q P Q Widerspruch αregel Nr.1 αregel Nr.2 P Widerspruch Abb.: 2 Anwendung des Tableauverfahrens Der Tableau Prover kann durch eine weitgehende Vernachlässigung von Typen wesentlich schneller arbeiten, als dies durch direkte Anwendung der Regeln in Isabelle möglich wäre [Pa04]. In seltenen Fällen kann es hierdurch allerdings dazu kommen, dass die Ausführung eines gefundenen Beweises in Isabelle an inkompatiblen Typen scheitert [Pa99]. Aus Effizienzgründen verzichtet der Tableau Prover zusätzlich auf Unifikation höherer Ordnung [Pa99]. Eine Besonderheit des Tableau Provers von Isabelle ist, dass er Backtracking erlaubt. Scheitert der Beweis eines Theorems in einem Anlauf, so findet ein Backtracking bis zur letzten unsicheren Regel statt. An diesem Punkt wird dann eine andere Regel ausgeführt [NPW04]. Während der Beweisführung werden zunächst sichere und anschließend unsichere Regeln ausgeführt [Pa04]. Ein Nachteil der blast Methode liegt darin, dass sich nicht nachvollziehen lässt, wie ein Beweis geführt wurde. Dies stellt insbesondere dann ein Problem dar, wenn der 15

19 Beweis fehlschlägt. In einem solchen Fall würde Isabelle einfach eine Fehlermeldung ausgeben, die keinerlei Informationen darüber enthält, warum der Beweis nicht erfolgreich durchgeführt werden konnte. In diesem Fall kann die Anwendung der Methode clarify hilfreich sein. Sie führt ausschließlich sichere Regeln aus. Darüber hinaus finden keine Regeln Anwendung, die ein Subgoalsplitting beinhalten. Dies hat zur Folge, dass clarify lediglich einfache Umformungen vornimmt und bereits vor einem Scheitern des Beweises abbricht. Häufig können dadurch die schwierigen Stellen eines Beweises offen gelegt werden [NPW04]. Für die Beweisführung im Rahmen der Logik und der Mengenlehre ergibt sich somit folgenden Empfehlung: Wende die Methode blast an, um den Beweis zu führen. Wende im Falle eines Scheiterns von blast die Methode clarify an, um Gründe für ein Scheitern eines Beweises offen zu legen. Weitere Methoden, die nur einen Teil der Funktionalität von blast ausführen und sich daher ebenfalls zum Auffinden von problematischen Stellen innerhalb eines Beweises eignen sind clarsimp und safe. Die Methode clarsimp verhält sich hierbei wie clarify, verwendet aber zusätzlich noch die Funktionalität der Methode simp. Die Methode safe verwendet im Gegensatz zu clarify auch Regeln, welche ein Subgoalsplitting beinhalten. 3.3 Proof-General und Isabelle Die oben beschriebene Syntax, sowie alle vorgestellten Methoden, können auf der Shell-Ebene von Isabelle eingegeben werden. Es gibt allerdings eine komfortable Alternative, die neben einer grafischen Oberfläche noch eine Reihe weiterer Features bietet: Proof-General. Es wurde ursprünglich für Linux programmiert. Unter Windows kann es mit Hilfe der Cygwin-Umgebung installiert werden. Wenn Proof-General gestartet wird, erstellt es automatisch einen Script Buffer mit dem Namen "Scratch.thy". In dem Script Buffer können Theorien in der oben beschriebenen Form entwickelt werden. Unter der Vorraussetzung, dass bereits eine Theorie existiert kann sie über den Menüpunkt "FileOpen" geöffnet werden. Hat man diese Schritte durchgeführt, könnte der Bildschirm z.b. wie folgt aussehen: 16

20 Abb.: 3 Screenshot Proof-General Charakteristisch ist die Zweiteilung der Arbeitsoberfläche. Im oberen Bereich befinden sich die Bereits erwähnten Script Buffer. Im unteren Bereich wird, von Proof-General kontrolliert, einer der folgenden Buffer angezeigt [AK04]: Der Goal Buffer zeigt noch zu beweisende Subgoals an. Der Response Buffer zeigt dem Benutzer Fehlermeldungen an. Der Trace Buffer, der eine spezielle Version des Response Buffers darstellt, zeigt Meldungen zum Debugging an. In der Regel wird im oberen Bereich der Script-Buffer und im unteren Bereich der Goal Buffer angezeigt. Die Zentrale Steuerung der Beweisführung findet sich unterhalb der Menüleiste: Die beiden ersten Tasten "State" und "Context" steuern, falls nur zwei Buffer angezeigt werden, den Inhalt des unteren Buffers. "State" zeigt den Goal Buffer an. "Context" zeigt den Namen der aktuellen Theorie und alle eingebunden Theorien an. 17

21 Abb.: 4 Arbeiten mit Proof-General Die nächsten fünf Schaltflächen übernehmen die Steuerung der Interaktion zwischen Proof-General und Isabelle. Wird der Button "Next" gedrückt wird die erste noch nicht bearbeitete Zeile des Buffers an den Proof-Assistenten geschickt, wo sie verarbeitet wird. Isabelle unterscheidet drei verschiedene farbliche Hinterlegungen [AK04]: Hellblau bedeutet, die Zeile wurde bereits vom Proof-Assistenten verarbeitet und kann nicht mehr editiert werden. Orange bedeutet, die Zeile wurde bereits an den Proof-Assistenten gesendet, wartet aber noch auf Bearbeitung. Auch Orange markierte Zeilen können nicht mehr bearbeitet werden. Grau bzw. nicht hinterlegt, bedeutet, die Zeile wurde noch nicht an den Proof- Assistenten gesendet und kann deshalb noch editiert werden. Die Taste "Undo" kann benutzt werden einen Schritt zurück zu gehen, weil man z.b. eine vorhergehende Zeile doch noch einmal editieren möchte. "Use" schickt alle Zeilen auf einmal an den Proof-Assistenten, "Retract" macht alle Schritte auf einmal rückgängig. Wird die Schaltfläche "Goto" betätigt, werden alle Zeilen nacheinander an den Proof-Assistenten geschickt, bis es eine Fehlermeldung auftritt. Die Schaltfläche ermöglicht folglich bei längeren Beweisen ein schnelles Auffinden des für die Beweisführung problematischen Abschnittes. Ein weiteres interessantes Feature von Proof-General findet sich in der Menüleiste unter dem Punkt "Index". Hier kann direkt an verschiedene Stellen innerhalb eines Buffers gesprungen werden. Im Einzelnen können Theorien, Theoreme oder Deklarationen als Sprungpunkte ausgewählt werden. Dies ermöglicht ein schnelles Navigieren innerhalb langer Beweise. 18

22 Kapitel 4: Praktische Anwendungen 4 Praktische Anwendungen Die bisher vorgestellten Beispiele dienten der Illustration und wurden deshalb bewusst einfach gehalten. Beweise realweltlicher Probleme sind in der Regel deutlich komplexer. Für ihre Lösung werden daher zum Teil auch Konstrukte von Isabelle verwendet, die aufgrund ihrer vergleichbaren Funktionsweise mit den dargestellten Konstrukten, hier aus Übersichtlichkeitsgründen nicht vorgestellt wurden. Neben mathematischen [MF03] und logischen Beweisen [Oh97] ist die Formalisierung der Programmiersprache Java ein zentrales Forschungsgebiet. Es können zwei verschiedene Arten der Formalisierung von Programmiersprachen unterschieden werden. Beim shallow embedding wird lediglich die Semantik einer Programmiersprache in die Logik des Theorembeweisers eingebettet. Diese Vorgehensweise ist dann zu empfehlen, wenn man Aussagen über Anwendungen treffen möchte, die in der abgebildeten Sprache programmiert sind. Beim deep embedding werden sowohl die Syntax als auch die Semantik abgebildet [Oh00]. Dieses Vorgehen ist zu wählen, wenn man Aussagen über die Programmiersprache selbst treffen möchte. Auf diese Weise wurde bereits die Typensicherheit für eine vereinfachte Version von Java als auch für die JVM bewiesen [Oh00]. Als Beispiel für die Herangehensweise einer Formalisierung soll hier die Abbildung des Javatyps Integer in Isabelle beschrieben werden [RW03]. Java Integer haben eine Bit- Länge von 32. Zunächst muss daher der Wertebereich in Isabelle festgelegt werden: constdefs BitLength :: nat "BitLength == 32" MinInt :: int "MinInt == -(2^(BitLength+(-1)))" MaxInt :: int "MaxInt == (2^(BitLength+(-1)))+(-1)" Anschließend kann der neue Datentyp JavaInt definiert werden: typedef JavaInt = "{i::int. MinInt <= i & i<= MaxInt}" Die Definition muss mit Hilfe von typedef geschehen, dar JavaInt eine Untermenge des Typs int in Isabelle darstellt. Es werden von Isabelle automatisch zwei Funktionen bereitgestellt, welche die unterschiedlichen Typen aufeinander abbilden: Abs_JavaInt :: int => JavaInt Rep_JavaInt :: JavaInt => int 19

23 Kapitel 4: Praktische Anwendungen Die zweite Funktion kann ohne Probleme genutzt werden. Bei der ersten Funktion muss vor jeder Benutzung sichergestellt werden, dass sich der abzubildende int Wert auch in den definierten Wertebereich von JavaInt fällt. Dies kann mit Hilfe der folgenden Funktion geschehen, die alle int Werte in den definierten Bereich mapped: const IntToJavaInt :: int => JavaInt defs IntToJavaInt_def : "IntToJavaInt (x) == Abs_JavaInt(((x+(-MinInt))) mod( 2*(-MinInt)))" Mit Hilfe der Funktionen IntToJavaInt und Rep_JavaInt können die verschiedenen Operationen für Java Integer beschrieben werden. Hierzu erfolgt zunächst eine Typenumwandlung von JavaInt nach int. Auf den Isabelle Integer Werten wird dann die entsprechende Operation durchgeführt. Im Anschluss daran wird das Ergebnis wieder in einen Wert vom Typ JavaInt umgewandelt. Ein Beispiel hierfür ist die Addition: consts add :: "JavaInt => JavaInt => JavaInt" ( infixr "plus" 65) defs add_def : "add n m == IntToJavaInt ((Rep_JavaInt n)+(rep_javaint m))" Im Anschluss an die Definition muss das Verhalten der Addition abgebildet werden. Als Beispiel dient das Kommutativgesetz: theorem kommutativ : " x plus y = y plus x" Ein Beweis könnte z.b. wie folgt aussehen: lemma lemma1 [simp]: "(Rep_JavaInt n)+(rep_javaint m) = (Rep_JavaInt m)+(rep_javaint n)" apply (simp) done theorem kommutativ : " x plus y = y plus x" apply (unfold add_def) apply (simp) Zunächst wird bewiesen, dass das Kommutativgesetz für Isabelle Integer gilt. Das entsprechende Lemma wird der Methode simp übergeben, welche es anschließend nutzt, um das Theorem kommutativ zu lösen. Auf ähnliche Weise lassen sich auch die anderen Operationen sowie deren Verhaltensweisen in Isabelle abbilden. Formalisierungen dieser Art sind die Grundlage für die Verifikation von arithmetischen Java Programmen wie z.b. Verschlüsselungs- Werkzeugen [RW03]. 20

24 Kapitel 5: Zusammenfassung 5 Zusammenfassung Ziel dieser Seminararbeit war es den semi-automatischen Theorem Prover Isabelle/HOL vorzustellen. Zu diesem Zweck wurde im einführenden Kapitel zunächst Isabelle/HOL allgemein beschrieben. Der zentrale Bestandteil war hier die Beschreibung des grundlegenden Aufbaus eines Beweises in Isabelle. Im weiteren Verlauf wurde die Beweisführung mit Isabelle/HOL im Detail beschrieben. Hierbei wurden zwei verschiedene Bereiche unterschieden. Der erste Teil erläuterte die Beweisführung im Rahmen der funktionalen Programmierung. Zunächst erfolgte eine Beschreibung der Darstellung von Datentypen und Funktionen in Isabelle/HOL. Zentraler Bestandteil war die Entwicklung einer Handlungsanweisung für die Beweisführung im Rahmen funktionaler Programme. Herausgearbeitet wurde, dass die Anwendung der Methoden induct_tac und auto zu empfehlen ist. Im zweiten Teil wurde auf die Beweisführung im Rahmen der Logik eingegangen. Zunächst wurde die Beweisführung anhand von einzelnen Regeln beschrieben. Es zeigte sich, dass ihre Anwendung in langen Beweisen wenig praktikabel ist, da jeder Schritt des Beweises einzeln durchgeführt werden muss. Aus diesem Grund wurde die Methode blast vorgestellt, welche auch komplizierte Probleme aus dem Bereich der Logik sowie der Mengenlehre in einem Schritt zu lösen in der Lage ist. Für eine Beweisführung wurde daher die Anwendung der der Methode blast empfohlen. Anschließend wurde auf die Bedienung der grafischen Benutzeroberfläche Proof- General eingegangen. Hierbei wurden im Besonderen die unterschiedlichen Funktionen der verschiedenen Buffer dargestellt. Im letzten Kapitel wurden einige praktische Anwendungen näher dargelegt. Beispielhaft wurde die Formalisierung von Java Integern in Isabelle beschrieben. Die Tatsache, dass die Typensicherheit für eine nur leicht vereinfachte Variante von Java bewiesen wurde, zeigt die Mächtigkeit von Isabelle/HOL. Die Flexibilität wird durch die vielen verschiedenen Anwendungen im Bereich der mathematischen und logischen Beweise unterstrichen. Aufgrund dieser Flexibilität kann Isabelle bisher keine Unterstützung bei der Formalisierung einzelner Probleme anbieten. An dieser Stelle könnte das Programm durchaus sinnvoll erweitert werden. Zusammenfassend kann Isabelle/HOL als ein sehr flexibles, mächtiges Werkzeug zur Beweisführung mit einer allerdings geringen Benutzerunterstützung bei der Formalisierung von Problemen beschrieben werden. 21

25 Literaturverzeichnis [AK04] [Le03] [Me00] [MF03] [Ni02] David Aspinall, Thomas Kleymann: Proof General - Users Manual. Letzter Zugriff Reinhold Letz: Praktikum Beweiser. Letzter Zugriff: Merz Stephan: Weak Alternating Automata in Isabelle/HOL. In: Lecture Notes in Computer Science 1869, S , Springer Verlag, Laura I. Meikle, Jacques D. Fleuiot: Formalizing Hilbert s Grundlagen in Isabelle/Isar. Lecture Notes in Computer Science 2758, S , Springer Verlag, Tobias Nipkow: Structered Proofs in ISAR/HOL. In: Lecture Notes in Computer Science 2646, S , Springer Verlag, [NPW04] Tobias Nipkow, Lawrence C. Paulson, Markus Wenzel: Isabelle HOL. A Proof Assistant for Higher-Order Logic. Springer Verlag, [Oh97] [Oh00] [Pa99] [Pa04] [RS04] [RW03] David von Oheimb: Machine-supported Proofs for Relation Algebra. Lecture Notes in Computer Science 1249, S , Springer Verlag, David von Oheimb: Analyzing Java in Isabelle/HOL. Dissertation an der technischen Universität München, Lawrence C. Paulson: A Generic Tableau Prover and ist Integration with Isabelle. In: Journal of Universal Computer Science, 5(3), 1999, S Lawrence C. Paulson: The Isabelle Reference Manual. Letzter Zugriff: Stuart Russel, Peter Norvig: Künstliche Intelligenz - Ein moderner Ansatz. Pearson Verlag, Nicole Rauch, Burkhart Wolff: Formalizing Java s Two s-complement Integral Type In Isabelle/HOL. In: Electronic Notes in Theoretical Computer Science, Volume (80), 2003, S