Objektorientierte Verträge. OOPM, Ralf Lämmel

Transkript

1 Objektorientierte Verträge OOPM, Ralf Lämmel

2 2 Verallgemeinerung von Vor- und Nachbedingungen für imperative Programme: OO-Verträge zwischen Dienstleister & -nutzer p ist eine Verpflichtung für den Dienstnutzer (Aufrufer) A, aber ein Gewinn für Dienstleister B. q ist eine Verpflichtung für den Dienstleister (Aufgerufenen) B, aber ein Gewinn für den Dienstnutzer A Vertrag B Aufrufer Aufruf m(x); pre: p post: q Aufgerufener Klasse (Datentyp) B sagt zu A (und allen anderen Anwendern): Wenn Du m aufrufst so dass p gilt, erbringe ich einen finalen Zustand, in welchem q gilt.

3 Vor- und Nachbedingungen für Methoden (C) , Ralf Lämmel, Universität Koblenz-Landau 3

4 4 Push-Operation eines Kellers mit Vertrag public void push(int item) { // Housekeeping for state int oldsize = size(); // Precondition assert true;... IMPLEMENTATION ELIDED... Nachbedingungen sind Bedingungen die nach der Methodenausführung gelten sollen. Nachbedingungen müssen immer durch den Methodenkörper erbracht werden---die zugehörige Vorbedingung zu Beginn vorausgesetzt. // Postcondition assert!isempty() && top() == item && size() - 1 == oldsize;

5 5 Pop-Operation eines Kellers mit Vertrag public void pop() { // Housekeeping for state int oldsize = size(); // Precondition assert!isempty(); Vorbedingungen beschreiben, wann eine Methode anwendbar ist und sinnvoll funktioniert. Vorbedingungen sind verbindlich für alle Methodenaufrufe.... IMPLEMENTATION ELIDED... // Postcondition assert size() + 1 == oldsize;

6 6 Sichtbare Größen in Vor- und Nachbedingungen Argumente der Methoden Lesender Zugriff auf öffentlichen Zustand (Getter) Andere nichtmutierende (öffentliche) Methoden Vorbedingungen sehen nur initialen Zustand. Nachbedingungen sehen (auch) resultierenden Zustand. In Java muss man den initialen Zustand für die Nachbedingungen sichern.

7 Klassen-Invarianten Invarianten sind Bedingungen, die immer gelten sollen. (C) , Ralf Lämmel, Universität Koblenz-Landau 7

8 8 Beispiele für Invarianten Datentyp Konto Der Kontostand ist immer nicht-negativ. Datentyp FloatRange Untere und obere Schranke sind verträglich.

9 9 Ein Konto mit Invariante public class Account { private float balance; private void invariant() { assert balance >= 0; Programmierung der Invariante als (private) Methode // Return balance in account public float getbalance() {... invariant(); return balance; Überprüfung der Invariante

10 10 Einzahlen public void deposit(float amount) { invariant(); // Precondition assert amount >= 0; Brauchen wir diese Überprüfung wirklich? // Housekeeping Überprüfung der Invariante float oldbalance = balance; balance += amount; invariant(); // Postcondition assert balance >= oldbalance && oldbalance + amount == balance;

11 11 Auszahlen public void withdraw(float amount) { // Precondition assert amount >= 0 && balance >= amount; // Housekeeping Überprüfung der Invariante float oldbalance = balance; balance -= amount; invariant(); // Postcondition assert balance <= oldbalance Die Attribute der Klasse sind privat. Damit können nur lokale Methoden die Attribute ändern. Damit genügt das Überprüfen der Invariante am Ende einer jeden Methode. && oldbalance - amount == balance;

12 12 Ein Datentyp FloatRange I/III public class FloatRange { private Float min, max; private void invariant() { assert this.min <= this.max; public FloatRange(Float min, Float max) { // Precondition assert min < max;... this.min = min; this.max = max; invariant(); // Postcondition Überprüfung der Invariante assert getmin() == min && getmax() == max;

13 13 Ein Datentyp FloatRange II/III public Float getmin() { return min; public void setmin(float min) { // Precondition assert min <= getmax(); this.min = min; invariant(); // Postcondition Überprüfung der Invariante assert getmin() == min;

14 14 Ein Datentyp FloatRange III/III public Float getmax() { return max; public void setmax(float max) { // Precondition assert getmin() <= max; this.max = max; invariant(); // Postcondition Überprüfung der Invariante assert getmax() == max;

15 15 Eine Klasseninvariante gilt für alle Instanzen der Klasse. Alle Methoden einer Klasse müssen deren Invariante einhalten. Verlangte Gültigkeit von Vorbedingungen Zu Beginn von Methoden Verlangte Gültigkeit von Nachbedingungen Zum Ende von Methoden Verlangte Gültigkeit von Invarianten: Am Ende von Konstruktoren Zu Beginn und zum Ende von Methoden

16 16 Behandlung von Verträgen in Java Zusammenfassung Vorbedingungen: assert bei Methodeneintritt Nachbedingungen: assert bei Methodenaustritt Sicherung von initialem Zustand in Variablen Invarianten: Extra private Methode mit assert Invariante wird von allen Methoden aufgerufen: vor/nach dem Test der Nachbedingung und (eventuell) vor/nach dem Test der Vorbedingung. Zu teuer für Produktion aber gut für Debugging. Verfolgungswahn

17 17 Vererbung und Verträge Ein Szenario: Gegeben seien Klassen Rectangle und Square. Wir könnten Square als Unterklasse von Rectangle betrachten. Eine Instanz von Square hat gleiche Seitenlängen. Wie verhält sich dieses Szenario mit Vererbung bezüglich von Verträgen? Könnten wir auch Rectangle als Unterklasse von Square betrachten?

18 18 Rechtecke ohne Verträge public class Rectangle { private int width; private int height; public Rectangle(int width, int heigth) { setwidth(width); setheight(height); public int getwidth() { return width; public int getheight() { return height; public void setwidth(int width) { this.width = width; public void setheight(int height) { this.height = height; public int getperimeter() { return (width+height)*2; Was ist ein sinnvoller Vertrag für Rechtecke?

19 19 Rechtecke mit Vertrag I/II package oo.dbc.square; public class Rectangle { private int width; private int height; private boolean invariant() { return getwidth() > 0 && getheight() > 0; public Rectangle(int width, int heigth) { assert width > 0 && height > 0; // Precondition this.width = width; this.height = heigth; assert invariant(); Warum verwenden wir hier nicht die Setter? public int getwidth() { return width; public int getheight() { return height;...

20 20 Rechtecke mit Vertrag II/II... public void setwidth(int width) { assert width > 0; // Precondition this.width = width; assert invariant(); public void setheight(int height) { assert height > 0; // Precondition this.height = height; assert invariant(); public int getperimeter() { return (width+height)*2; Wollen wir hier eine Nachbedingung?

21 21 Nachbedingung mit Bezug auf Resultat public int getperimeter() { return (width+height)*2; Explizites Vormerken des Ergebnisses public int getperimeter() { int result = (width+height)*2; // Postcondition assert result == (width+height)*2; return result; Implementation wäre unmittelbar aus der Nachbedingung abzulesen Nachbedingung kann von Resultat sprechen

22 22 Die Unterklasse für Quadrate public class Square extends Rectangle { protected boolean invariant() { return super.invariant() && getwidth() == getheight(); public Square(int length) { super(length, length); public int getlength() { return getwidth(); public void setwidth(int width) { setlength(width); public void setheight(int height) { setlength(height); public void setlength(int length) { assert length > 0; // Precondition this.width = length; this.height = length; assert invariant(); Wir müssen Rectangle offen lassen (siehe nächste Folie) so dass wir auf Invariante und Attribute zugreifen können.

23 23 Angepasste Klasse für Rechtecke package oo.dbc.square; public class Rectangle { protected int width; protected int height; protected stellt sicher, dass Zugriff nur in Unterklassen zulässig ist. protected boolean invariant() { return getwidth() > 0 && getheight() > 0; public Rectangle(int width, int heigth) { assert width > 0 && height > 0; // Precondition this.width = width; this.height = heigth; assert invariant(); public int getwidth() { return width; public int getheight() { return height;...

24 24 Das Substitutionsprinzip Einfache Formulierung: Ein Untertyp bewahrt (in einem abstrakten Sinne) das Verhalten des Obertyps. Deswegen darf man eine Instanz des Untertyps anstelle einer Instanz des Obertyps verwenden. Veerbung CreditAccount extends ZeroCreditAccount getbalance() -- Verhalten bewahrt. deposit(...) -- Verhalten bewahrt. statement() -- Ausgabe erweitert Was wäre mit der Invariante dass der Kontostand nicht negativ ist? withdraw(...) -- Auszahlung bewahrt bei geeigneter Invariante Erfinder: Barbara Liskov Empfänger des Turing Award

25 25 Substituierbarkeit in Bezug auf Verträge Unterklassen müssen bezüglich der Oberklassen folgende Regeln befolgen: gleiche oder stärkere Invariante, gleiche oder schwächere Vorbedingungen, gleiche oder stärkere Nachbedingungen. Die obigen Forderungen können konstruktiv wie folgt garantiert werden: Die Vorbedingung wird abgeschwächt durch Disjunktion. Die Nachbedingung wird verstärkt durch Konjunktion. Die Invariante wird auch verstärkt durch Konjunktion.

26 26 Invarianten im Konto-Beispiel ZeroCreditAccount balance >= 0 CreditAccount extends ZeroCreditAccount balance >= 0 &&? Wir dürfen die Invariante nur verstärken, aber selbst die ererbte Invariante ist schon nicht realsierbar in der Unterklasse. Frage: Wie können Sie die Invarianten bzw. die Klassen ändern so dass das richtige Verhältnis der Invarianten besteht, aber trotzdem zwei unterschiedliche Klassen ZeroCreditAccount und CreditAccount in Vererbung stehen?

27 27 Praktische Substituierbarkeit im Sinne von Zuweisungs- oder Typkompatibilität Kontenbeispiel: Account a = new CreditAccount(); Formenbeispiel: Shape s = new Circle(...); Diese Kompatibilität ist auch zulässig bei aktuellen Argumenten von Untertypen der formalen Argumenttypen. Man darf auch Instanzen in einen Container einordnen, dessen Elementstyp ein Obertyp des Instanztyps ist. Liskovsche Substituierbarkeit ist eine semantische Eigenschaft, aber wir beschränken uns häufig auf die Komponente der Typsicherheit davon.

28 28 Beispiel für einen schlechten Vertrag Nachbedingung für setwidth Rectangle Nicht wahr für Square! getwidth()==width && oldheight == getheight() Square getwidth()==width && getheight() == width Diese Nachbedingung ist wahr für Square. Es ist aber keine Verstärkung der Nachbedingung von Rectangle!

29 29 Typen vs. Verträge Ein Vergleich: Die Vorbedingung zu einer Methode beschränkt die Methodenargumente. Die Argumenttypen beschränken auch die Methodenargumente. Eine Idee: Typen und Verträge muss man vielleicht gar nicht absolut trennen. Beides kann man übrigens statisch und dynamisch prüfen.

30 30 Java ist nicht Alles! Java s assert bietet nur naive Laufzeittests. Zugriff auf initialen Zustand ist schlecht unterstützt. Andere Technologien beinhalten auch Verifikation. JML (Java-Plattform) Spec# (.NET-Plattform)

31 Einschub: JML requires amount >= 0; Kommentar für Java, Spezifikation für JML. public void deposit(float amount) {... Es gibt entsprechende Verifikationstechnologie so dass JML-Spezifikationen statisch und unter Umständen automatisch als korrekt bewiesen werden können. (C) , Ralf Lämmel, Universität Koblenz-Landau 31

32 JML-Erweiterungen zu Java-Ausdrücken Syntax Meaning \result result of method call a ==> b a implies b a <== b a follows from b (i.e., b implies a) a <==> b a if and only if b a <=!=> b not (a if and only if b) \old(e) value of E in pre-state

33 Zusammenfassung Verträge = Vor- / Nachbedingungen + Invarianten Substitutionsprinzip als Anforderung an Untertypen Aufrufer sind Dienstnutzer / Aufgerufene sind Dienstleister. Ausblick Syntax von Softwaresprachen Ein- und Ausgabe in OO-Programmen Prüfungsvorbereitung