Kontrakte, Abstrakte Datentypen und Verfeinerung

Transkript

1 Kontrakte, Abstrakte Datentypen und Verfeinerung 229

2 Kontrakte 230

3 Vor- und Nachbedingungen, Kontrakte Ein Kontrakt für eine Prozedur p (oder auch für eine Methode) besteht (mindestens) aus einer Vorbedingung ϕ (präd.log. Formel) einer Nachbedingung ψ (präd.log. Formel) der Angabe der input-parameter (incl. gelesene globale Variablen) der Angabe der output-parameter (incl. geschrieben globale Variablen). Dazu kommt natürlich eine informelle Beschreibung: U.a. Name und Zweck der Operation, Querverweise zu Use Cases, etc. Bemerkung: Für KIV-Prozeduren fehlen die globalen Variablen. Sie müssen als I/O-Parameter addiert werden. 231

4 Vor- und Nachbedingungen, Kontrakte Definition: Eine Methode mit Implementierung mit Rumpf α erfüllt einen Kontrakt, falls die Parameter korrekt gegeben und der Rumpf total korrekt bzgl. Vor- und Nachbedingung ist. Formal also muss gelten: Im Hoare-Kalkül: ϕ α ψ In Dynamischer Logik: ϕ α ψ Bemerkung:(Vorbedingung in Kontrakten) Wenn die Vorbedingung nicht eingehalten wird, darf beliebiges passieren: Absturz, Exception, Nichtterminierung, reguläres Ergebnis, illegaler Speicher etc. 232

5 Zwei Beispiekontrakte Beispiel 1 (Revertieren einer Liste): Eingabe und Ausgabe: Liste x Vorbedingung: x = y Nachbedingung x = reverse(y) Beispiel 2 (Entfernen eines Element von einem Stack): Eingabe: Stack st. Ausgabe: Modifizierter Stack st und Element a. Vorbedingung: st = st 0 st emptystack Nachbedingung st = pop(st 0 ) a = top(st 0 ) y und st 0 sind logische Variablen, die nur zur Spezifikation benötigt werden. Alles andere sind Programmvariablen. 233

6 Kontrakte für Java Für Java oder C# sind die Argumente Eingabeparameter und das Ergebnis der einzige Ausgabeparameter. Es gibt immer genau einen IO-Parameter: den Speicher Der Speicher wird gelesen/modifiziert ist nicht aussagekräftig Deshalb: Genauere Angaben,welche Objekte/Assoziationen gelesen/geschrieben/erzeugt werden sind in Vor- und Nachbedingung erforderlich! Die Nachbedingung kann auch: Wirft für bestimmte Eingaben eine bestimmte Exception lauten. Sinnvollerweise teilt man die Nachbedingung deshalb in einen regulären und einen Exception-Teil. 234

7 Kontrakte als Relation: Beispiele Statt getrennt Vor- und Nachbedingung anzugeben, kann man äquivalent den Kontrakt auch als Prädikat angeben, das die Relation zwischen Anfangs- und Endzustand beschreibt. Für die Beispiele lauten die Prädikate REV(x,x ) y. x = y x = reverse(y) POP(st,st,a ) st 0. st = st 0 st emptystack st = pop(st 0 ) a = top(st 0 ) Die Formeln können vereinfacht werden: REV(x,x ) x = reverse(x) POP(st,st,a ) st emptystack st = pop(st) a = top(st) 235

8 Kontrakte als Relation Benötigt wird Konvention für Start- und Endwert einer Variable. Je nach Spezifiaktionssprache verschieden. Z: x bezeichnet den Startwert, x den Endwert VDM: pre(x) für den alten, x für den neuen JML (für Java): \old(x) für den alten und x für den neuen Die Relation ist die Konjunktion von Vor- und Nachbedingung, wobei in der Nachbedingung x statt x genommen wird In der Relation stehen nur die Programmvariablen Logische Variablen werden existenzquantifiziert, fallen häufig weg. Relationale Spezifikation ist etwas eleganter als getrennte Vor- und Nachbedingung (Programmvariablen klar, keine log. Variablen) Relational beschreibene Kontrakte heissen oft auch Operationen. 236

9 Kontrakt REV vs. reverse Funktion Was ist neu im Kontrakt REV(x,x ) x = reverse(x) gegenüber der Funktionsdefinition? Der Kontrakt legt fest, dass x Programmvariable ist, und überschrieben wird! Der Kontrakt REV(x,z ) z = reverse(x) besagt dagegen, daß x nur gelesen, und z überschrieben wird. 237

10 Vorbedingung relationaler Kontrakte Relationale Spezifikation verhindert auch, das die Nachbedingung noch implizit Vorbedingungen stellt: Beispiel: Vorbedingung: x = y Nachbedingung: x = reverse(y) x []. Für die Eingabe x = [] ist es nicht möglich, den Kontrakt zu erfüllen, obwohl die Vorbedingung immer erfüllt ist. Definition: Für eine Operation OP(x,y ) ist die Vorbedingung pre(op) für die Eingaben x die Formel: pre(op)(x) : y. OP(x,y ). 238

11 Kontrakte in der Spezifikationssprache Z Ein Kontrakt wird in der Spezifikationssprache Z als Schema bechrieben: OP x in? out! ϕ(in?, x) ψ(x, x, out!) ;; modifizierter Zustand ;; Eingaben ;; Ausgaben ;; Vorbedingung ;; Zeilen konjunktiv verknüpft ;; Nachbedingung 239

12 Beispielkontrakte als Relationen REV x : list x = reverse(x) POP st : stack a! : elem GET s : set a! : elem s empyset a! s st emptystack a! = top(st) st = pop(st) Beobachtung: Datentypoperationen wie POP, REV duplizieren die algebraische Operation (reverse, pop) im wesentlichen. Allerdings vermeiden sie Unterspezifikation (POP) und können indeterministisch sein (GET). 240

13 Abstrakte Datentypen 241

14 Abstrakte Datentypen Eine Grundidee zur mathematischen Beschreibung eines Softwaresystems ist die eines Automaten mit Zuständen und Abläufen. Es gibt dann: Eine Menge möglicher Systemzustände (in Vorlesung SWT durch Klassendiagramm beschrieben) Einen Anfangszustand (oder mehrere). Eine Anzahl Systemoperationen (Vorlesung SWT!). Die Operationen bekommen Eingaben, modifizieren den Systemzustand und produzieren Ausgaben. Dadurch entstehen Abläufe. Für die Modellierung verwenden wir: Belegungen von Variablen mit algebraisch spezifizierte Datenstrukturen zur Beschreibung von Zuständen Kontrakte zur Beschreibung der Systemoperationen 242

15 Abstrakte Datentypen Ein Abstrakter Datentyp DT = (S, INIT, {OP i } i I ) besteht aus Einer Zustandsmenge S. Typischerweise besteht S aus der Belegung eines Vektors von Variablen mit algebraisch spezifizierten Datentypen. Einer Menge von Initialzuständen INIT S. Einer Menge (für i I) von (relational definierten) Kontrakten: OP i IN i S S OUT i Die Kontrakte werden auch Operationen genannt. Jede Operation hat Eingaben aus IN i (kann für einzelne Operationen wegfallen) modifiziert den Zustand S hat eine Eingabe aus OUT i (kann für einzelne Operationen wegfallen) 243

16 Algebraischer Datentyp: queue Gegeben seien algebraisch spezifizierte Queues von integers (als Instanz von Listen spezifiziert) mit Operationen: Sorte queue Konstante emq (die leere Queue) Konstruktor + : elem queue queue (vorne an die Queue anfügen) Funktion enq : queue int queue (hinten an die Queue anfügen) Funktion deq : queue queue (vorne wegnehmen) Funktion hd : queue int (vorderstes Element) Kann aus Listen abgeleitet werden: Leere Liste entspricht leerer Queue hd und deq sind die Selektoren.first und.rest enq ist attach (hinten anhängen an die Liste) 244

17 Abstrakter Datentyp: queue Zustand = Eine Variable q vom Typ queue Initialzustand: q = emq Freier Datentyp für das Resultat von DEQ: elemornone = mk(..elem : elem) none 3 Operationen: EMQ, ENQ, DEQ none könnte in einer Implementierung eine Exception werden, aber auch ein Spezialwert bleiben. 245

18 Kontrakte für queue-operationen EMQ q : queue q = emq ENQ q : queue a? : elem q = enq(q, a?) DEQ q : queue an! : elemornone q = emq q = emq an! = none q emq q = deq(q) an! = mk(hd(q)) 246

19 Zur Verwendung von abstrakten Datentypen Grundidee: Die Verwendung des Datentyps ist immer innerhalb einer Umgebung Die Umgebung kann sehr verschieden sein: Ein Programm, das die Operationen aufruft Benutzer, der die Operationen per Knopfdruck aufruft Systemumgebung aus anderen Rechnern (Clients, die auf einen Server zugreifen etc.) 2 Grundannahmen: Operationen sind atomar ( Transaktionscharakter ) Beobachtet werden nur input/output, der Zustand ist unsichtbar 247

20 Abläufe eines Datentyps (informell) Ein Ablauf (auch: Szenario) entsteht dadurch, dass die Umgebung Operationen aufruft: Das System startet in Zustand s 0 (unsichtbar). Eine Operation OP k1 aufgerufen mit Eingabe i 1. Zustand ändert sich zu s 1 (unsichtbar) und Ausgabe ist o 1. Zwei Fälle: Vorbedingung pre(op)(i 1,s 0 ) ist verletzt, dann ist die Ausgabe o 1 beliebig, und auch alle weiteren Operationen dürfen Beliebiges tun. Wenn Vorbedingung erfüllt, dann muss OP k1 (i 1,s 0,s 1,o 1 ) gelten. Umgebung beobachtet (k 1,i 1,o 1 ) für die Operation Anschliessend ruft die Umgebung die Operation OP k2 Die Umgebung beobachtet (k 2,i 2,o 2 ) Insgesamt entsteht eine Folge von Beobachtungen: (k 1,i 1,o 1 ) (k 2,i 2,o 2 )... (k m,i m,o m ) 248

21 Abläufe eines Datentyps Gegeben sei ein Datentyp DT = (S, INIT, {OP i } i I ) Ein Ablauf eines Datentyps ist eine Folge (k 1,i 1,o 1 ) (k 2,i 2,o 2 )... (k m,i m,o m ) mit m 0, zu der es Zustände s 0 INIT, s 1,... s m S und ein p m +1 gibt (die erste schiefgehende Operation, falls p m), so daß (in i,s i 1, s i, out i ) OP ki für 1 i < p. Falls 1 p m, ist pre(op kp )(i p,s p 1 ) falsch, und alle s i, o i für i p sind beliebig. Die Semantik SEM(DT) eines Datentyps ist die Menge aller möglichen Abläufe 249

22 Verfeinerung (Refinement) 250

23 Refinement: Die generelle Idee Die Grundfrage, auf die Verfeinerung (engl. refinement) Antwort gibt, ist immer: Gegeben eine abstrakte Beschreibung eines Systems. Wie kommt man systematisch und schrittweise zu einer korrekten Implementierung? Refinement gibt es in einer grossen Zahl von Varianten: Für algebraische (zustandslose) Systeme (algebraisches Refinement, Moduln) Für parallele (event-basierte) Systeme (CSP Refinement/(Bi-)Simulation) Für zustandsbasierte Datentypen: Relational: Data Refinement Operational: ASM Refinement Für Automaten: IO-Automata Refinement 251

24 Data Refinement Grundidee: Gegeben sei ADT = (AS, AINIT, {AOP i } i I ). Der Zustand AS ist nach aussen hin unsichtbar. Er kann deshalb durch einen konkreten Zustand ersetzt werden, wenn sich die Funktionalität nach aussen hin nicht ändert. Sei also ein konkreter Datentyp CDT = (CS, CINIT, {COP i } i I ) gegeben (selbe Menge von Operationen, anderer Zustand) Der konkrete Datentyp ist eine korrekte Verfeinerung des abstrakten, wenn keine Umgebung bemerken kann, dass sie statt des abstrakten den konkreten Datentyp verwendet. Es gilt also das Substitutionsprinzip, dass alle abstrakten durch konkrete Operationen ersetzt werden können Das Verfahren kann iteriert werden schrittweiser Übergang von abstrakter Spezifikation zu konkreter Implementierung 252

25 Data Refinement Die Verfeinerung von ADT = (AS, AINIT, {AOP i } i I ) zu CDT = (CS, CINIT, {COP i } i I ) ist korrekt, wenn alle Abläufe des konkreten Datentyps auch Abläufe des abstrakten sind. Kurz: SEM(CDT) SEM(ADT) Besonderheiten: Der konkrete Datentyp kann durchaus weniger Abläufe haben Er kann weniger nichtdeterministisch sein (z. B. indeterministische Selektion aus Menge durch deterministische Selektion des ersten Listenelements ersetzt) Er kann undefinierte Operationen (Zustand vorher ausserhalb der Vorbedingung) durch definierte ersetzen 253

26 Der konkrete algebraische Datentyp Die queue wird durch einen Heap H und einen Zeiger r, der auf den Anfang einer Folge von Zellen zeigt, repräsentiert. Der konkrete Datentyp wird gleich durch ein Programm implementiert, nicht zuerst spezifiziert. Der Speicher hat als Schlüssel References (Typ Ref) mit null: Ref Der Speicher enthält als Daten (freier Datentyp): conscell =.. (..val : elem;..nxt : Ref) Die null-referenz entspricht einer leeren Queue. deq# relativ einfach enq# muss die Verkettung bis zum Ende ablaufen, dann hinten anhängen 254

27 Wie verifiziert man Data Refinement? Data Refinement verlangt Teilmenge aller Abläufe. Wie zeigen? Grundidee: Zeige, dass eine konkrete Operation eine abstrakte simuliert. (Daraus folgt Refinement per Induktion über die Länge von Abläufen) as 0 AOP k1 as 1 AOP k2 as 2... as m cs 0 ABS COP k1 cs 1 ABS COP k2 cs 2 ABS... cs m ABS Die Operationen müssen dieselben Ein-/Ausgaben haben. Vor- und nach jeder Operation muss der konkrete Zustand einen abstrakten Zustand repräsentieren. Das wird durch eine Formel ABS beschrieben. 255

28 Abstraktionsrelation Eine Abstraktionsrelation (oder auch eine Simulation, Kopplungsinvariante, Repräsentationsrelation engl. simulation, representation relation, coupling invariant) ist eine Relation ABS AS CS zwischen den beiden Zuständen. In KIV spezifizieren wir ein Prädikat abs(as 1,..., as n,cs 1,... cs m ), wobei as 1,..., as n und cs 1,... cs m die Programmvariablen des abstrakten bzw. konkreten Zustands sind. ABS(as,cs) besagt: Der Zustand cs repräsentiert den abstrakten Zustand as. Die Relation ist meist eine partielle Funktion (deshalb auch Abstraktionsfunktion): Ein konkretes Datum repräsentiert höchstens ein abstraktes) 256

29 Die Repräsentationsrelation für das Beispiel Im Speicher H steht unter r eine Kette von Zellen, deren Inhalte die Inhalte der Queue q sind abs(r,h,q) besagt Speicherinhalt unter r in H repräsentiert die Queue q. Formale Definition (rekursiv über queues): abs(r,h,emq) r = null abs(r,h, a + q) r null r H H[r].val = a abs(h[r].nxt,h,q) 257

30 Wie verifiziert man Korrektheit? Satz:(Vorwärtssimulation zur Korrektheit) Eine Verfeinerung ADT = (AS, AINIT, {AOP i } i I ) zu CDT = (CS, CINIT, {COP i } i I ) ist korrekt, wenn eine Vorwärtssimulation ABS gefunden werden kann, für die gilt: CINIT(cs) as. ABS(as,cs) AINIT(as) (: Initialisierung :) ABS(as,cs) pre(aop i )(in,as) pre(cop i )(in,cs) (: Anwendbarkeit :) ABS(as,cs) pre(aop i )(in,as) COP i (in,cs,cs,out) as. AOP i (in,as,as,out) ABS(as, cs ) (: Korrektheit :) wobei pre(aop i )(in,as) : as, out. AOP i (in,as,as,out) 258

31 Initialisierung CINIT(cs) as. ABS(as,cs) AINIT(as) besagt: Jeder konkrete Initialzustand cs repräsentiert einen abstrakten Initialzustand as 259

32 Anwendbarkeit ABS(as,cs) pre(aop i )(in,as) pre(cop i )(in,cs) besagt: Wenn der konkrete Zustand cs den abstrakten Zustand as repräsentiert, und die Operation AOP i mit einer Eingabe in anwendbar ist, d.h. die Vorbedingung nicht verletzt ist, dann ist auch die konkrete Operation COP i anwendbar. Oder andersrum: Die Vorbedingung der konkreten Operation darf nur dann verletzt werden, wenn auch die Vorbedingung der abstrakten verletzt ist. ABS in, as in, cs AOP i COP i 260

33 Korrektheit ABS(as,cs) pre(aop i )(in,as) COP i (in,cs,cs,out) as. AOP i (in,as,as,out) ABS(as, cs ) besagt: Wenn der konktete Zustand cs den abstrakten Zustand as repräsentiert, und die Operationen mit einer Eingabe in anwendbar sind, so liefern sie dieselbe Ausgabe und der konkrete Ergebniszustand cs repräsentiert wieder den abstrakten as ABS in, as AOP i as, out ABS in, cs COP i cs, out 261

34 Spezialfall: Programm als konkreter Datentyp Der konkrete Datentyp kann statt als Kontrakte auch gleich als implementierte Prozeduren gegeben sein. Der Kontrakt COP für eine Prozedur COP# kann als wp-formel wiedergegeben werden: COP(i,cs,cs,o ) = COP#(i;cs,o) true COP#(i;cs,o) (cs = cs o = o ) Satz: Sind direkt Prozeduren gegeben, so ergibt sich aus Anwendbarkeit und Korrektheit eine einzige Beweisverpflichtung: ABS(cs,as) pre(aop)(i,as) COP#(i;cs,o) ( as. AOP(i,as,as,o) ABS(cs,as )) besagt: Wenn ABS gilt, und die abstrakte Operation anwendbar ist, muss die konkrete immer terminieren und einen Ergebniszustand liefern, der ein mögliches Ergebnis der abstrakten Operation repräsentiert. 262

35 Korrektheitsbedingungen für die Queue Satz:(Korrektheit der Queue-Implementierung) Die Verfeinerung von Queues zur Implementierung ist korrekt, wenn folgende Sequenzen bewiesen werden können: Initialisierung: r = null q. abs(r,h,q) q = emq Korrektheit für emq#: abs(r,h,q) emq#(;r,h) abs(r,h,emq) Korrektheit für enq#: abs(r,h,q) enq#(a;r,h) abs(r,h,enq(q,a)) Korrektheit für deq# (Fall 1, nichtleeres q): abs(r,h,q), q emq deq#(;r,h, an) (abs(r,h,deq(q)) an = mk(hd(q))) Korrektheit für deq# (Fall 2, leeres q): abs(r,h,emq) deq#(;r,h, an) (abs(r,h,emq) an = none) 263

36 Aufgabe fürs Praktikum Erster Termin: Die Prozeduren emq#, deq# und enq# programmieren: Bitte vorbereiten! Korrektheitsbedingungen nachweisen Zweiter Termin: Alternative Repräsentation mit Pointer r auf den Anfang + Pointer r0 auf die letzte Zelle ABS(r,r0,H,q) überlegen: Bitte vorbereiten! Die Prozeduren emq#, deq# und enq# programmieren: Bitte vorbereiten! Korrektheitsbedingungen nachweisen 264