11 Design by Contract

Transkript

1 11 Design by Contract 1. Das Konzept des DBC 2. Zwei Beispiele in C 3. Ein Beispiel in Eiffel 4. Ein Ada-Beispiel 5. Zusammenfassung Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.1/30

2 1. Das Konzept des DBC Software: Kunde (Client) und Anbieter (Server). Vertrag = Genaue Schnittstellenspezifikation Eingeführt von Berntrand Meyer, Entwickler von Eiffel. Kernkonzepte: Vorbedingungen, die der Aufrufer eines Unterprogramms / einer Methode einzuhalten hat. Nachbedingungen, die dem Aufrufer garantiert werden. Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.2/30

3 Kunde Anbieter Verpflichtung 30 Min. vor Abflug am Schalter Gepäck nicht zu schwer Gepäck nicht zu gross Ticket bezahlt Kunden pünktlich zum Ziel bringen Nutzen/Recht Ein Vertrag pünktlich am Ziel Passagiere abweisen, die zu spät kommen, zu grosses bzw. schweres Gepäck dabei haben oder nicht zahlen Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.3/30

4 Software-Schnittstelle als Vertrag Element in eine Tabelle eintragen. Tabelle ist durch Integer-Werte indiziert. Kunde Anbieter Verpflichtung Garantiere: Tabelle nicht voll Schlüssel > 0 Geg. Element unter dem Schlüssel in Tabelle eintragen Nutzen/Recht Geänderte Tabelle mit neu eingetragenem Element und passendem Schlüssel Wenn Tabelle voll oder Schlüssel 0: Keine Verpflichtung! Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.4/30

5 Der Vertrag in Eiffel put (x: Element; key: INTEGER) is -- x eintragen -- spaeterer Zugriff ueber key require -- PRE-condition count <= capacity; key > 0 do... Einfuege-Algorithmus... ensure -- POST-condition has(x); item(key) = x; count = old count + 1 end Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.5/30

6 Grundprinzipien von DBC No Hidden Clause: Vom Kunden darf nichts verlangt werden, was nicht ausdrücklich in den Vorbedingungen spezifiziert ist! Überprüfbarkeit: Nach-, vor allem aber Vorbedingungen müssen mit Methoden (bzw. Unterprogrammen) spezifiziert werden, die der Kunde kennt! Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.6/30

7 Wann werden die Bedingungen überprüft? Gar nicht (DBC zur Spezifikation) Zur Laufzeit (Eiffel) (DBC für Spezifikation und Test) Nur beim Testen im Produktivsystem abgeschaltet Immer Statisch (SPARK) (DBC zur Spezifikation und zum Nachweis der Korrektheit) Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.7/30

8 DBC und Vererbung Erbende Klasse als Subcontractor : Vorbedingung: gleich oder schwächer Nachbedingung: Gleich oder stärker Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.8/30

9 2. Zwei Beispiel in C Aus dem Lehrbuch (Ausschnitt aus einem pratischen Projekt) Aus der C-Standard-Bibliothek Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.9/30

10 Ein Beispiel aus dem Lehrbuch Name: dectonum Specification: This function scans the string str, beginning at the byte position given by first, for the character representation of a decimal value. This value, converted to numeric, is returned as the value of the function, and last is set to indicate the next character in str after the value that was found. If any scanning or conversion errors are found, converror is set to true. The maximum length value to be scanned is 4 decimal digits. Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.10/30

11 int dectonum(char *str, int first, int *last, BOOLEAN *converror){ int n, i; BOOLEAN scanning; n = 0; i = 0; scanning = true; *converror = false; while (scanning) { Quelltext des Beispiels if (str[first+i]>= 0 && str[first+i]<= 9 ) n = n * 10 + str[first+i] - 0 ; else if (str[first+i] == ) scanning = false; else { *converror = true; scanning = false; } i++; if (i > first + 3) scanning = false; } *last = first = first + i; return n; } Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.11/30

12 Ein Fehler! if (i > first + 3) scanning = false; This expression will fail when first!= 0. It should have been (i > 3). Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.12/30

13 Weitere Defekte (1) The signature of the routine: Input argument str should be declared const since it is read-only. Argument first is not really necessary (str + first) would suffice in the call. Names and formatting are poor. Argument converorr has non-standard type, name, and is unnecessary. Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.13/30

14 Weitere Defekte (2) The specification is too vague: Does not specify whether or not signed integers are valid. E.g., -2, +3. (the implementation indicates that they are not.) Does not specify what whitespace characters are valid. I.e., blanks, tabs, newlines and how many of each. Contains an unnecessary arbitrary limit of only 4 digits to be accepted. The entire routine is not needed (error of mission) since there already exists a routine, strtol(), in the Standard C Library that provides this functionality. Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.14/30

15 Beispiel: strcat Man betrachte die Standard-C-Routine strcat. Was leistet dieses Programm? #include <stdio.h> /* For printf(). */ #include <string.h> /* For strcat(). */ int main( void ) { char s[ 11 ] = hello ; strcat( s, s ); /* What happens here? */ printf( %s, s ); return 0; } Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.15/30

16 Verhalten von strcat Auf verschiedenen Plattformen erhält man einen Programmabsturz wegen Segmentation Fault, wegen eines nicht abgefangenen Signals, wegen eines arithmetischen Fehlers (!), läuft in eine Endlosschleife, bzw. gibt hellohello aus. Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.16/30

17 Wen strcat mit DBC spezifiziert wäre 1. Entweder stärkere Vorbedingung: char* strcat( char* d, const char* s ) { PRE( d, s, d!= s ) const old_d_length = strlen( d );... POST( strlen( d ) == old_d_length + strlen( s ) ) } 2. Oder Implementation muss auch den Fall d=s immer korrekt behandeln ( no hidden clause ) in unserem Fall also hellohello. Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.17/30

18 3. Ein Beispiel in Eiffel Man betrachte eine Merge-Prozedur, die zwei sortierte Sequenzen zu einer sortieren Sequenz zusammensetzt: Kunde Anbieter Verpflichtung beide Eingaben sind sortiert Sortiere die beiden Eingaben zu einer sortierten Ausgabe Nutzen/Recht Ausgabe ist sortiert Eingaben sind sortiert; das braucht nicht überprüft zu werden Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.18/30

19 Eiffel-Code (1) merge (a, b: SEQUENCE [G]): SEQUENCE [G] is -- Merge already sorted a and b -- to sorted result require -- PRE-condition a_already_sorted: sorted (a) b_already_sorted: sorted (b) deferred -- abstrakte Methode Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.19/30

20 Eiffel-Code (2) ensure -- POST-condition result_is_sorted: sorted (Result) result_is_right_size: Result.count = (a.count + b.count) -- result_has_all_of_a: -- For all i in [1, a.count] -- Result.has (a.item (i)) -- result_has_all_of_b: -- For all i in [1, b.count] -- Result.has (b.item (i)) -- result_has_nothing_more: -- For all i in 1..Result.count -- a.has (Result.item (i)) or -- b.has (Result.item (i)) end Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.20/30

21 Grenzen von DBC (1) Sei a = (1,2,2) und b = (2,3,3). Die Vorbedingungen für den Aufruf von merge(a,b) sind damit erfüllt. Wir erwarten, dass merge(a,b) = (1,2,2,2,3,3) ist. Gibt es andere korrekte Lösungen? Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.21/30

22 Grenzen von DBC (2) Praktisch einsetzbare DBC-Mechanismen (wie in Eiffel) erlauben es (bisher?) nicht, bewährte Mechanismen Logik (z.b. Quantoren aus der Prädikatenlogik) zu verwenden. Manchmal, aber nicht immer (!), kann man durch Hilfsfunktionen doch Nachbedingugnen angeben, deren Gültigkeit der Klient im Prinzip zur Laufzeit überprüfen kann. Selbst wenn das möglich ist ( nächste Folie) muss man im Einzelfall entscheiden, ob eine derartige Spezifikation sinnvoll und wünschenswert ist. Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.22/30

23 Nachbedingungen mit Hilfsfunktionen ensure -- POST-condition result_is_sorted: sorted (Result) result_is_right_size: Result.count = (a.count + b.count) result_has_all_of_a: Result.has_each (a) result_has_all_of_b: Result.has_each (b) result_has_nothing_more: Result.has_only (a, b) end Für die Hilfsfunktionen geben wir dann keine eigenen Nachbedingungen an... Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.23/30

24 4. Ein Ada-Beispiel Aus SL.Containers.Bounded (bereits wohlbekannt): Prozedur Put Prozedur Get Unsere DBC-Spezifikationen sind hier nur Kommentare Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.24/30

25 DBC in Ada (Beispiel: Put) procedure Put (The_Container: in out Container; Item : in Element); - Put one additional Item into The_Container - pre not Is_Full (The_Container) - else raise Sl.Containers.Overflow - post (1) count(the_container) - = count(the_container )+1 - (2) iterating through The_Container - yields all elements that iterating - through The_Container would have - yielded plus one additional occurance - of Item, but no other elements Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.25/30

26 DBC in Ada (Beispiel: Get) procedure Get (The_Container: in out Container; Item : out Element); - Take one element from The_Container - pre not Is_Empty (The_Container) - else raise Sl.Containers.Underflow - post (1) count(the_container) - = count(the_container )-1 - (2) iterating through The_Container - yields all elements that iterating - through The_Container would have - yielded except for one occurance of Item Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.26/30

27 Non-Redundancy Regel bei DBC: Ein Unterprogramm soll das Einhalten seiner Vorbedingungen nicht testen. Das Put/Get Beispiel verletzt (mit Absicht) diese Regel (else raise...). Wenn man schon die Vorbedingung testet, sollte man aber angeben, dass man dies tut und wie man auf eine derartige Verletzung reagiert (else raise Sl.Containers.Underflow). Verleiche mit (nicht-software) Verträgen: Konventionalstrafen,... Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.27/30

28 Hidden Clauses in Nachbedingungen Beispiel: Für unsere Containerklassen haben wir die Reihenfolge, in der beim Lesen von Elementen aus dem Container diese geliefert werden, nicht spezifiziert. Trotzdem kann ein z.b. ein Kunde von SL.Containers.Bounded durch Tests oder Betrachten der Implementation herauszufinden, in welcher Reihenfolge das Lesen geschieht, und bei der Implementation seiner Software diese Reihenfolge als gegeben voraussetzen. Nichts ist idiotensicher. Idioten sind zu erfinderisch! Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.28/30

29 DBC und Programmierspachen prinzipiell für alle Programmiersprachen geeignet, Eiffel als Muttersprache des DBC In Ada: nicht direkt unterstützt (wohl aber in SPARK... ) Ada (Unter)-Typen Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.29/30

30 5.Zusammenfassung Spezifikation von Schnittstellen zur Laufzeit überprüfbar (manchmal auch statisch) in der Lücke zwischen formalen Korrektheitsbeweisen auf dem Papier und dem praktischen Schreiben von Programm-Quelltext kein Ersatz für Tests (kann aber hilfreich sein) eine möglichst exakte und vollständige Spezifikation wird angestrebt, ist aber nicht immer sinnvoll oder möglich dient der Korrektheit von Software; i.d.r. aber nicht ihrer Robustheit Stefan Lucks, Software-Entwicklung für Sichere Systeme SS 04, Kapitel 11 p.30/30