Prädikatenlogik - Micromodels of Software

Transkript

1 Prädikatenlogik - Micromodels of Software Philipp Koch Seminar Logik für Informatiker Universität Paderborn Revision: 30. Mai

2 Inhaltsverzeichnis 1 Motivation 3 2 Modelle Definition eines Modells Modelle von Software Grenzen der Modellüberprüfung Überprüfung von micromodels of software Modellprüfungen in Alloy Alloy Signaturen assertion checking consistency checking Einschränkung der micromodels Zusammenfassung 10 5 Literatur 11 2

3 1 Motivation Prädikatenlogik stellt Aussagen mit Hilfe von Prädikaten und Funktionen formal dar. Auch wenn Syntax und Semantik bekannt sind, stellt sich noch die Frage, wie dieses Konzept praktisch in der Informatik angewandt werden kann. Eine Möglichkeit ist es, mittels der Prädikatenlogik Aussagen über Software zu treffen und zu überprüfen. Ein Programm lässt sich formal als Automat mit Zuständen darstellen. Im folgenden möchte ich darlegen, wie solche Automaten als Modelle betrachtet und für prädikatenlogischen Formeln überprüft werden können. Danach stelle ich ein Konzept vor, um komplexere Softwaremodelle verifizieren zu können. Zum Verständnis dieser Arbeit ist eine Kenntnis von Grundlagen der Prädikatenlogik, insbesondere der Syntax nötig. 2 Modelle 2.1 Definition eines Modells Um prädikatenlogische Formeln überhaupt anwenden zu können, muss vorher definiert sein, welche Werte Variablen annehmen können. Erst so ergibt sich eine Bedeutung der Funktionen und Prädikate. Sei F eine Menge aus Funktionssymbolen und P eine Menge aus Prädikatssymbolen, jedes Symbol mit einer fest definierten Anzahl an Argumenten. Ein Modell für (F, P ) besteht nun aus: 1. Einer nicht-leeren Menge A, den konkreten Werten 2. Für jedes Funktionssymbol ohne Argumente f F ein konkretes Element f M aus A 3. Für fedes f F mit der Anzahl Argumenten n > 0 eine konkrete Funktion f M : A n A 4. Für jedes p P mit der Anzahl von Argumenten n > 0 eine Teilmenge P M A n Ein Modell besteht also aus einem Werteuniversum A, aus dem alle möglichen Variablenbelegungen stammen, aus konstanten Funktionen, die einen bestimmten Wert zurückliefern, aus der Definition, welche Werte die Funktionen zurückliefern, und aus den Mengen, für die ein Prädikat wahr wird. Für ein solches konkretes Modell kann nun für jede prädikatenlogische Formel eine eindeutige Aussage getroffen werden. 2.2 Modelle von Software Mit so definierten Modellen kann man leicht Automaten darstellen. Sei F := {i} und P := {R, S}, wobei i eine Konstate ist, R ein Prädikatensymbol mit zwei 3

4 Argumenten und S ein Prädikatensymbol mit einem Argument. Ein Modell besteht nun aus dem Wertebereich A, und konkreten Interpretationen von i, R und S. Für einen Automaten bedeutet dies: A ist die Menge aller Zustaände i M ist der Startzustand R M ist die Menge aller Zustandsübergänge S M ist die Menge aller akzeptierenden Zuständen Ein so definiertes Modell eines Automaten ist nun konkret, und prädikatenlogische Formeln können eindeutig bezüglich dieses Modells ausgewertet werden. Beispiel Sei A := {a, b, c}, i M := a, R M := {(a, a), (a, b), (b, c), (c, c)}, und S M := {b, c}. Dies ist ein vollständig definierter Automat mit Startzustand, Zustandsübergängen und akzeptierenden Zustände, und gleichzeitig ein Modell der Prädikatenlogik. Nun können Aussagen überprüft werden. Die Formel S(i) sagt aus, dass der Startzustand nicht gleichzeitig ein akzeptierender Zustand des Automaten ist. Für das gegebene Beispiel ist diese Aussage wahr, da a / S. a ist der Startzustand, während nur b und c akzeptierende zustände sind. Die Formel x y S(x) R(x, y) sagt aus, dass es einen Zustand gibt, der kein akzeptierender Zustand ist, und für diesen kein Zustandsübergang zu einem anderen Zustand existiert, also dass es einen Deadlock im Automaten gibt. Für das gegebene Beispiel diese Aussage falsch. Der einzige nicht akzeptierende Zustand des Automaten ist a. Von diesem aus gibt es gleich zwei Zustandsübergänge, (a, b) und (a, c). Daher ist der Automat frei von Deadlocks. 4

5 2.3 Grenzen der Modellüberprüfung Mit dem oben erklärten Prinzip der Überprüfung von Modellen ist es möglich, eine Aussage für jedes einzelne konkrete Modell zu verifizieren. Wenn man aber Überprüfen möchte, ob Software eine bestimmte Eigenschaft erfüllt, dann hat man aber nicht immer ein fertiges Programm, dass sich so testen lässt. Vielmehr ist es auch von Interesse, ob bei gegebenen Anforderungen, die beim Softwareentwurf gestellt werden, bestimmte Eigenschaften immer gelten. Die Anforderungen müssen dabei aber nicht unbedingt so genau definiert sein, dass sich ein konkretes Modell erstellen lässt. Hier scheint model checking nicht benutzbar zu sein, da ein Modell nicht nur einige gegebene Anforderungen definiert, sondern vollständig ist und keinen Spielraum mehr lässt. Folglich könnte das Prinzip der semantischen Folgerung sinnvoller einzusetzen sein. Hier ist die Schwierigkeit aber, dass nicht jedes Problem entscheidbar ist. Da wir aber nach einer Lösung suchen, mit Prädikatenlogik praktisch in der Informatik Probleme zu entscheiden, wäre dieser Ansatz unbefriedigend. Man benötigt also ein entscheidbares Problem, das aber nicht nur für ein, sondern viele Modelle gilt. Folglich versuchen wir, unsere Software möglichst genau mit einer Menge von Modellen zu beschreiben und testen dann, ob diese bestimmten Eigenschaften genügen. Diese Modelle heißen nach Daniel Jackson micromodels of software 2.4 Überprüfung von micromodels of software Greifen wir die Definition von oben für ein Modell eines Automaten auf, mit F := {i} und P := {R, S}. Dies ist noch kein konkretes Modell, da noch der Wertebereich A und die Interpretationen i M, R M und S M fehlen. Da nun aber nicht ein einzelnes Modell überprüft werden soll, sondern viele, können unter Umständen keine Interpretationen angegeben werden. In der Praxis könnte es zum Beispiel sein, dass noch nicht alle Aspekte der Software entworfen wurden oder dass für die Zukunft Erweiterungen oder Änderungen geplant sind. Sei µ die Menge aller möglicher Implementierungen M i einer Software. Für eine Aussage ψ möchte man nun in Bezug auf µ prüfen, ob sie wahr oder falsch ist. assertion checking prüft, ob ψ für alle Implementationen M i µ wahr ist. Ein Beispiel wäre der oben bereits durchgeführte Test von S(i) für alle M i µ, also der Test für jedes einzelne Modell M i, ob der Startzustand kein akzeptierender Zustand ist. Nur wenn der Test für jedes einzelne Modell wahr ist, wird ein wahr zurückgeliefert. consistency checking prüft, ob ψ für mindestens eine Implementation M i µ wahr ist. Ein Beispiel hierfür wäre der Test von x y S(x) R(x, y) für alle M i µ. In diesem Fall wird ein wahr zurückgeliefert, wenn auch nur bei einem einzigen Modell M i ein Deadlock bei einem nicht akzeptierenden Zustand auftritt. Möchten wir diese beiden Beispieltest durchführen, stellt sich die Frage, wie µ 5

6 am besten zu definieren ist. Wenn man für µ die Anzahl aller möglichen Automaten wählt, tritt schnell das Problem auf, dass das gestellte Problem unentscheidbar ist, da eine unendlich große Menge an Automaten überprüft werden muss. Es gibt nun 2 Möglichkeiten, dieses Problem zu umgehen: Entweder kann man µ doch noch weiter konkretisieren, oder man beschränkt die Größe der Modelle. Da der Test für allgemeine Automaten durchgeführt werden soll, kann keine Konkretisierung stattfinden. Es bleibt also die Größenbeschränkung. Diesen Ansatz nutzt das Tool Alloy. Sind alle Modelle in der Größe beschränkt, muss jedoch beachtet werden, dass die Antwort des Tests für größere Modelle gelten kann aber nicht muss. Wird bei der Überprüfung ein falsch zurückgegeben, gab es schon kleine Modelle, für welche die Aussage nicht gilt. Würde die Menge der zu prüfenden Modelle vergrößert, wäre das Ergebnis also das selbe. Bei einem falsch kann also auf jeden Fall geschlossen werden, dass die Softwaremodelle den Anforderungen nicht genügen. Wird bei der der Überprüfung ein wahr zurückgegeben, kann daraus nur geschlossen werden, dass die gewählte Menge an Modellen den Anforderungen genügt. Es kann vermutet werden, dass auch größere Modelle noch einer Überprüfung standhalten, da Probleme oft schon bei kleinen Modellen auftreten, aber eine Sicherheit besteht in diesem Fall nicht. 3 Modellprüfungen in Alloy 3.1 Alloy Alloy ist ein Tool zur Überprüfung von micromodels. Es ist in Java implementiert, bietet eine grafische Benutzeroberfläche und ist frei im Internet erhältlich. Es benutzt den oben geschilderten Ansatz, Modellmengen zu überprüfen und sowohl assertion checking als auch consistency checking sind möglich. Bleiben wir bei den beiden schon benutzten Beispielen und betrachten die Implementierung in Alloy. 3.2 Signaturen Für eine Überprüfung von Modellen muss zunächst µ, die Menge an konkreten Modellen, im Programm abgebildet werden. Für das Modell eines Automaten muss zum Beispiel definiert sein, dass A, i, R und S zu jedem Automaten gehören. In Alloy werden die Anforderungen für µ in einer signature definiert. sig StateMachine { A: set State, i: A, R: A -> A, S: set A} 6

7 Dies ist eine Signatur in Alloy. Mit sig wird eine Signatur eingeleitet, danach folgt der Name, hier StateMachine. Im Körper der Signatur werden A, i, R und S definiert. Die Wertemenge A wird in der Signatur als A: set State abgebildet, also als eine Menge aus Zuständen. Der Anfangszustand i ist ein Wert aus A, also i: A. S ist eine Teilmenge aus A, durch S: set A definiert. Die Zustandsübergänge R, sind immer Übergänge von einem Zustand aus der Menge A zu einem anderen: R: A -> A. Da bisher noch nicht definiert ist, wie ein Zustand State aussieht, muss dies auch noch getan werden. Dafür wird eine weitere Signatur genutzt. sig State { } Diese Signatur enthält in diesem Fall keine interne Struktur. Hier ist auch keine nötig, da in den folgenden Beispielen nur die Beziehungen und die Art der Zustände geprüft werden soll, nicht aber spezielle Eigenschaften. Natürlich liessen sich auch der Aufbau und die Struktur eines Zustandes modellieren und in der Praxis könnte dies auch nötig sein, wenn man darüber Aussagen treffen möchte. Trotzdem ist die Signatur wichtig, damit Alloy hinterher Instanzen der Signatur bilden kann um Zustände für einen Automaten zu erstellen. Mit diesen beiden Signaturen ist nun µ als Menge aller Automaten definiert. Im folgenden muss nun noch der Test einer prädikatenlogischen Formel definiert werden, und die Anzahl der Modelle beschränkt werden, um ein Ergebnis zu erhalten. 3.3 assertion checking Die erste Möglichkeit, eine prädikatenlogische Formel für die Modelle zu überprüfen, ist assertion checking. Wählen wir als Beispiel wieder S(i) und überprüfen, ob diese Eigenschaft für alle Modelle der Signatur StateMachine gilt. assert FinalNotInitial { all M : StateMachine no M.i & M.F } check FinalNotInitial for 3 but 1 Statemachine Dies ist ein möglicher assertion check. Er beginnt mit assert und hat den Namen FinalNotInitial. all M : StateMachine teilt Alloy mit, dass die folgende Bedingung für alle Modelle M des Typs StateMachine überprüft werden soll. Für jedes einzelne Modell wird auf auf die internen Variablen M.i, den Anfangszustand des Modells, und auf M.F, die Menge der akzeptierenden Zustände, zugegriffen. no M.i & M.F verknüpft die beiden als Behauptung, dass kein Zustand gleichzeitig Startzustand und akzeptierender Zustand ist. check FinalNotInitial lässt Alloy nach einem Gegenbeispiel für die vorher aufgestellte Behauptung suchen. Damit nicht die unendlicher Menge aller Au- 7

8 tomaten untersucht wird, ist am Ende noch die Einschränkung for 3 but 1 Statemachine gegeben. Aus den Signaturen werden konkrete Modelle erstellt, mit der Auflage, dass aus keiner Signatur mehr als 3 Elemente erstellt werden. Zusätzlich wird durch but 1 Statemachine die Anzahl der Automaten pro Modell auf 1 beschränkt. Jedes zu prüfende Modell besteht also aus genau einem Automaten, der maximal 3 Zustände hat. Diese Menge ist endlich und kann überprüft werden. In diesem Fall wird Alloy ein Gegenbeispiel für die Behauptung finden, da es durchaus Automaten mit 3 Zuständen gibt, die einen Zustand enthalten, der Startzustand und akzeptierender Zustand ist. Ein solches Gegenbeispiel ist das Modell eines Automaten mit A = {a, b, c}, i M = c, R M = {(a, a)} und S M = {b, c}. Da es in der Praxis auch interessant sein kann, welche Modelle aus µ den gegebenen Bedingungen nicht genügen, und nicht nur die Tatsache, dass es überhaupt Fehler gibt, lässt sich bei Alloy auch einstellen, dass nicht nur ein Gegenbeispiel gesucht wird. Falls vorhanden können auch mehrere oder alle ausgegeben werden. 3.4 consistency checking Die andere Möglichkeit, eine Modellmenge zu überprüfen, ist der consistency check. Dieser überprüft nicht, ob die Aussage für alle Modelle gilt, sondern ob es mindestens eins gibt, das den Anforderungen genügt. Auch hier betrachten wir ein bekanntes Beispiel: x y S(x) R(x, y) Nun wird getestet, ob es ein Modell mit dieser Eigenschaft gibt. Die Modelle werden wieder mit der selben Signatur StateMachine wie zuvor erzeugt. fun AGuidedSimulation(M : StateMachine, s : M.A){ no s.(m.r) not s in M.F } run AGuidedSimulation for 3 but 1 Statemachine Dieser consistency check ist eine Funktion und wird mit fun eingeleitet. Er bekommt 2 Parameter übergeben. Zunächst M, ein Modell des Typs StateMachine und danach s, einen Zustand aus der Menge aller Zustände A des Automaten M. Im folgenden werden 2 Bedingungen überprüft. not s in M.F greift auf M.F, die Menge der akzeptierenden zustände des Modells zu. Der Zustand s wird mit dieser Menge verglichen, und es wird geprüft, ob er kein akzeptierender Zustand 8

9 ist. no s.(m.r) überprüft ob die Menge s.(m.r) leer ist. Die Menge besteht aus allen Zuständen des Automaten, zu denen man über einen Zustandsübergang von s aus gelangen kann. Wenn diese Menge leer ist, und auch die erste Bedingung gilt, ist ein Zustand gefunden, der ein Deadlock ist, aber kein akzeptierender Zustand. Ein Modell mit einem solchen Zustand erfüllt unsere prädikatenlogische Formel. Zuletzt wird mit run AGuidedSimulation die Funktion ausgeführt und ein Positivbeispiel gesucht. Wieder findet durch for 3 but 1 Statemachine eine Beschränkung der Modellmenge statt: Es werden Modelle erstellt, die einen Automaten und maximal 3 Zustände haben. Dieser Beispieltest wird ein positives Ergebnis liefern, da es Automaten mit maximal 3 Zuständen gibt, die einen Deadlock bei einem nicht akzeptierenden Zustand haben. Eine mögliche Rückgabe ist der Automat A = {a, b, c}, i M = b, R M = {(a, b)} und S M = {c}. Der Deadlock-Zustand ist hier der Zustand b. Er ist Anfangszustand, aber kein Zustandsübergang führt aus ihm heraus. Auch hier ist es möglich, Alloy mehrere positiv getestete Modelle ausgeben zu lassen. 3.5 Einschränkung der micromodels In den beiden Beispielen wurde die Menge aller Automaten überprüft, mit der einzigen Einschränkung der Größe. Es lassen sich aber auch andere Einschränkungen definieren. Signaturen seien wieder StateMachine und State. assert NoTrans { all M : StateMachine with M all x, y, z: A z in y.r && y in x.r => not z in x.r } check NoTrans for 3 but 1 Statemachine Seien x, y und z Zustände eines Automaten. Dieser assertion check prüft, ob für alle Modelle gilt, dass wenn es die Zustandsübergänge (x, y) und (y, z) gibt, nicht der Übergang (x, z) existiert. Das with M dient hier nur der verkürzten Schreibweise, damit im folgenden beispielsweise A anstatt M.A benutzt werden kann. Bei dieser Eingabe findet Alloy schnell das Gegenbeispiel mit dem Zustandsübergang (x, x). Wenn man nun nicht nur diese triviale Lösung haben möchte, kann man Zustandsübergänge von einem Zustand auf sich selbst ausschliessen. Dies ist eine weiter Möglichkeit, neben der Größe die micromodells einzuschränken: Beschränkung durch Fakten. Die Aussage x R(x, x) 9

10 kann wie folgt in Alloy abgebildet werden: fact NoLoop { all M : StateMachine, w : M.A not w in w.(m.r) } Nun werden nur Modelle betrachtet, für die das Fakt wahr ist, dass w nicht in der Menge der Zustände liegt, zu denen man über einen Zustandsübergang von w aus gelangen kann. Jetzt findet Alloy ein komplexeres Modell als Gegenbeispiel. 4 Zusammenfassung Zusammendfassend lässt sich sagen, dass das normale model checking für konkrete Modelle von Software ideal ist, aber schnell an seine Grenzen stößt. Die Überprüfung mit micromodels ist für nicht vollständig definierte Software oder Programmgruppen geeignet. Mit Alloy hat man ein Tool, dass sehr effizient micromodells überprüfen kann, allerdings auch nicht auf unendliche Mengen an Modellen angewandt werden kann. Dafür ist es sehr praxistauglich und bietet durch die Ausgabe der Positiv- oder Negativbeispiele im Gegensatz zu einem einfachen model check grosse Vorteile. 10

11 5 Literatur M. Huth and M. Ryan: Logic in Computer Science. Cambridge University Press, 2nd Edition, 2004 G. Goos: Vorlesungen über Informatik, Band 1. Springer-Verlag, 3. Auflage,