3.1.7 Korrektheit von Objekten Voraussetzung für die Diskussion der Korrektheit von nichtsequentiell benutzten abstrakten Objekten: Modellbasierte Spezifikation:

Präsentation zum Thema: "3.1.7 Korrektheit von Objekten Voraussetzung für die Diskussion der Korrektheit von nichtsequentiell benutzten abstrakten Objekten: Modellbasierte Spezifikation:"—  Präsentation transkript:

1 3.1.7 Korrektheit von Objekten Voraussetzung für die Diskussion der Korrektheit von nichtsequentiell benutzten abstrakten Objekten: Modellbasierte Spezifikation: Z = abstrakte Zustandsmenge eines Objekts { P } op(...) { Q } = auf Z bezogene Spezifikation, für jede Operation op Voraussetzung Effekt (precondition) (postcondition)

2 Szenario: Abläufe, an denen ein Objekt sowie mehrere nebenläufige Prozesse beteiligt sind, deren Aktionen Ausführungen von Operationen auf dem Objekt sind. Das Ergebnis eines Ablaufs besteht aus - dem abstrakten Endzustand des Objekts - und den Folgen der Aufrufergebnisse für die beteiligten Prozesse.

3 Beispiel mit 2 Prozessen: P: s.push('1'); x = s.pop(); Q: s.push('a'); s.push('b'); y = s.pop(); Mögliche Abläufe mit möglichem Ergebnis: P: push pop x == 'a' Q: push push pop y == 'b' s == "1" P: push pop x == '1' Q: push push pop y == 'b' s == ""

4 Ein Ablauf ohne Überlappungen von Aktionen heißt seriell. Mögliche serielle Abläufe mit Ergebnis: P: push pop x == 'a' Q: push push pop y == 'b' s == "1" P: push popx == '1' Q: push push popy == 'b' s == "a"

5 Def. 1:Zwei Abläufe heißen äquivalent, wenn ihre Ergebnisse gleich sind. Beispiel:Von den Abläufen sind nur und äquivalent. Def. 2:Ein Objekt heißt serialisierbar, wenn es zu jedem möglichen Ablauf A einen äquivalenten seriellen Ablauf (Serialisierung von A) gibt. Beispiel:Zu gibt es den äquivalenten seriellen Ablauf. Zu gibt es aber keinen – also ist das Objekt nicht serialisierbar.

6 Standard-Forderung für Korrektheit in nichtsequentiellen Umgebungen: (seq.) Korrektheit + Serialisierbarkeit Bemerkungen:Monitore (der bisher betrachteten Art) sind serialisierbar (weil es a priori nur serielle Abläufe gibt). Serialisierbarkeit kann u.U. auch mit schwächerer Synchronisation erreicht werden (3.1.6 ).3.1.6

7 Außerdem:Mitunter verzichtet man auf die Serialisierbarkeit, d.h. man läßt zu, daß ein Ablauf mit Überlappungen ein Ergebnis haben kann, das durch keine Serialisierung des Ablaufs erzielt werden kann. Konsequenz: Spezifikation muß explizit die zusätzlichen Effekte angeben (und eingrenzen!), die bei Überlappungen auftreten können.

8 Beispiel: interface SortedSet { // s :: Set // initially empty boolean add(Object x); // pre: - // post: s == union 's {x} boolean replace(Object old, Object new); // pre: contains s old // post: s == union(diff 's {old}) {new} void iterate(Operation op); // pre: all(\x->pre op x)s // post: all(\x->post op x)s && s=='s }

9 1. Realisierung als Monitor wäre zu restriktiv – angesichts des u.U. langwierigen iterate ! 2. Dennoch Serialisierbarkeit zu fordern könnte die Implementierung sehr schwierig machen (?). 3. Es könnte für die Anwendung akzeptabel sein, daß ein Ersetzen ( replace(old,new) ) während einer Traversierung ( iterate ) dazu führen könnte, daß die Traversierung sowohl old als auch new berührt – oder auch keines von beiden. Beispiel: Ausdrucken einer aktuellen Teilnehmerliste, an der laufend Veränderungen durchgeführt werden. 4. Die Spezifikation muß entsprechend erweitert werden.