3.2 Modellierende Spezifikation von ADT

Transkript

1 3.2 Modellierende Spezifikation von ADT Wie kann ich das Verhalten der Operationen eines ADO spezifizieren, wenn ich mich wegen der Datenabstraktion nicht auf seine Daten beziehen kann? 2 Alternativen: Modellierende Spezifikation (model-based specification): ein abstraktes Datenmodell wird zugrunde gelegt Algebraische Spezifikation (algebraic specification) ( 3.3): die Operationen werden zueinander in Beziehung gesetzt alp

2 Eine modellierende Spezifikation formuliert zu vorgegebener Syntax - Schnittstellenbeschreibung wie z.b. Java interface - eine aus 3 Teilen bestehende Semantik: ein abstraktes Modell für den konkreten Objektzustand, eine abstrakte Invariante, d.i. ein Prädikat auf den Modellwerten, das die tatsächlich zulässigen Werte charakterisiert, Spezifikationen für die Operationen, bezogen auf das Modell. alp

3 Beispiel: die bekannte Schlange: Modell: T* Z zu beliebigem, aber festem Elementtyp T interface Queue<T> { // model: ([t], Int)... } Invariante: q hat höchstens die Länge m: interface Queue<T> { // model: (q,m) :: ([t], Int) // inv: length q <= m... } Beachte: 1. Dies impliziert 0<=m. 2. Dass m konstant ist wird nicht gefordert! Spezifikationen für die Operationen: alp

4 3.2.1 Funktionale Spezifikation Spezifikation der Operationen als Funktionen über einem Modell: -- model type Queue t = ([t],int) -- invariant inv(q,m) = length q <= m -- initial "operation" emptyq :: Int -> Queue t emptyq m = ([],m) -- operations... alp

5 -- operations append :: (t, Queue t) -> Queue t append(x,(q,m)) length q == m = error "QueueOverflow" otherwise = (q',m) where q' = q++[x] remove :: Queue t -> (t, Queue t) remove(q,m) null q = error "QueueUnderflow" otherwise = (x,(q',m)) where x:q' = q Funktionales Programm = Ausführbare Spezifikation (natürlich nur möglich bei vollständiger Spezifikation) alp

6 3.2.2 Prädikative Spezifikation der Operationen Spezifikation der Operationen mit Voraussetzungen/Effekten: interface Queue<T> { // model: (q,max) :: ([t], Int) // inv: length q <= max void append(t x) throws QueueOverflow; // pre: length q < max -- else QueueOverflow // post: q == q++[x] && max == max T remove() throws QueueUnderflow; // pre: not(null q) -- else QueueUnderflow // post: result:q == q && max == max void init(int m); // pre: m>0 -- else? // post: null q && max == m... } oder ausführlicher gemäß Javadoc-Konventionen alp

7 Bemerkungen: Der hier verwendete Pseudo-Haskell-Text ignoriert den Bruch zwischen den Typsystemen von Haskell und Java! Die Schlange besteht aus Objektverweisen, und x ist ebenfalls ein Objektverweis! Dieser Bruch wird noch deutlicher bei boolean equals(object o); // pre: der dynamische Typ von o ist Queue // post: result == (q==o.q && max==o.max) "und keine Änderungen"!! (Aber dies ist weder Haskell noch Java!) Pragmatisches Resümee: Halbformale Sprache verwenden Pseudo-Haskell: grüner Code ist nicht korrektes Haskell alp

8 ! Nie vergessen, dass jeder Effekt erlaubt ist, den die Effektbeschreibung nicht explizit verbietet. Wenn daher z.b. auf S. 6 max == max vergessen würde, wäre nicht garantiert, dass max unverändert bleibt. Häufig wird aber die folgende Konvention praktiziert: was in der Effektbeschreibung nicht erwähnt wird, bleibt unverändert. Die Spezifikation sagt nichts über den Anfangszustand einer frisch erzeugten Schlange aus. Per Konvention kann man festlegen, dass eine Operation wie init einem Konstruktor entspricht und/oder als normale Operation zur Verfügung steht. alp

9 Komplexeres Beispiel (vgl , S. 13 ) interface Map<Key,Data> {... } z.b. für class SortedMap<K extends Comparable<K>, D> implements Map<K,D> {... } interface Map<Key,Data> { // model: m :: Key -> Data; size :: Int int max = 100; // inv: size <= max && // size == domain m void init(); // pre: -- // post: size == 0... alp

10 void enter(key k, Data d) throws KeyClash, Overflow; // pre: not(k `elem` domain m) && -- else KeyClash // size < max -- else Overflow // post: m k == d && // all(\x -> x/=k `implies` m x == 'm x)key Data lookup(key k) throws NoSuchKey; // pre: k `elem` domain m -- else NoSuchKey // post: result == m k && m == 'm } Vergleich von Funktionen! Was bedeutet das? Im Definitionsbereich von m gibt es ein x derart, dass k=x Was bedeutet k=x? k.equals(x) gemäß dem equals für den aktuellen Key-Typ. (Ein solches equals gibt es immer!) alp

11 Zum Vergleich: Java-Dokumentation: alp

12 alp

13 3.2.3 Korrektheit einer Spezifikation Beachte: Zu einer in sich fehlerhaften Spezifikation kann es keine korrekte Implementierung geben! Die Invariante spielt eine wesentliche Rolle. Sie gilt stets als impliziter Bestandteil aller Voraussetzungen. Bezüglich der Effekte: 2 alternative Interpretationen der Invariante: alle Effekte (einschließlich des Anfangszustands) sollten die Invariante implizieren - daraus ergibt sich eine Beweisverpflichtung; die Invariante gilt als impliziter Bestandteil aller Voraussetzungen und Effekte. alp

14 Interpretation ist gebräuchlicher und wurde auch oben benutzt: inv: I pre: pre, post: post tatsächliche Voraussetzung ist P = I pre tatsächlicher Effekt ist Q = I post Mit dieser Interpretation lautet die Korrektheitsbedingung für Spezifikationen von ADT: Spezifikationen aller Operationen - einschließlich der Initialisierungen - müssen konsistent sein. alp

15 Gegenbeispiel: interface Queue<T> { // model: (q,max) :: ([t], Int) // inv: length q <= max void append(t x); // pre: True // post: q == q++[x] && max == max...} Die schwächste Voraussetzung für Q = I post = length q <= max && q == q++[x] && max == max ist length q < max. Es gilt aber P = I pre = length q <= max && True length q <= max, was schwächer ist! alp