Design By Contract in Java Seminarbericht WS06 ... - Dominik Gruntz

Design By Contract in JavaSeminarbericht WS06/07Fachhochschule NordwestschweizHochschule für TechnikStudiengang InformatikSeminarbericht vonMatthias HausherrBetreuender DozentProf. Dr. Dominik GruntzWindisch, 15. November 2006

Design By Contract in JavaAbstractDie Idee von Design By Contract (DBC) ist, so exakt wie möglich zu definieren, was einSoftwaremodul tun soll. Die Bedeutung einer ausführlichen Spezifikation für Software kannkaum stark genug betont werden. Wartungskosten machen einen grossen Teil der Kosten imLebenszyklus einer Software aus und präzise Spezifikation und Dokumentation hilft mit,diese Kosten zu senken. Design By Contract treibt diese Idee auf die Spitze: Es wird soexakt wie möglich definiert, was das Softwaremodul tun soll. Die Firma Eiffel, quasi dieErfinder von Design By Contract, beschreibt ihre Motivation unter anderem mit folgendemSatz:“If we don't state what a module should do, there is little likelihood that it will do it.”- Eiffel.comIm ersten Teil dieses Berichtes wird erläutert wie Design By Contract funktioniert und welcheZiele damit verfolgt werden. Im zweiten Teil werden die Assertions, die seit JDK 1.4 von Javaangeboten werden, näher betrachtet. Anschliessend wird in einem Kapitel Refinementeingeführt, welches erläutert, wie Vererbung und Design By Contract zusammenspielen. AlsKernstück des Berichtes werden zwei verschiedene Design By Contract Implementationenfür Java vorgestellt und kleine Codesnippets präsentiert. Abschliessend wird eineEmpfehlung zum Einsatz von Design By Contract in Java abgegeben.Matthias Hausherr Seite 2 / 22

Design By Contract in JavaInhaltsverzeichnis1. Der Ansatz Design By Contract...................................................................................... 41.1. Definition................................................................................................................ 41.2. Entstehung............................................................................................................. 41.3. Idee und DBC-Begriffe........................................................................................... 41.4. Hauptziele.............................................................................................................. 51.4.1. Steigerung der Qualität .................................................................................. 51.4.2. Contracts als Dokumentation ......................................................................... 51.4.3. Debugging und Testing Hilfe .......................................................................... 52. Java Assertions.............................................................................................................. 62.1. Das Assert Statement ............................................................................................ 62.2. Verwendungszweck ............................................................................................... 62.3. Assertions und DBC............................................................................................... 63. Refinement (Contract Inheritance in DBC)...................................................................... 73.1. Regeln ................................................................................................................... 73.2. Beispiel .................................................................................................................. 74. Erweiterte Assertion Support Implementationen............................................................. 84.1. Erläuterung zu den Codebeispielen ....................................................................... 84.2. Erläuterung zu den Refinement Codebeispielen .................................................... 94.3. Jass ......................................................................................................................104.3.1. Facts .............................................................................................................104.3.2. Beschreibung ................................................................................................104.3.3. Syntaktische Elemente..................................................................................114.3.4. JavaDoc Erweiterung ....................................................................................134.3.5. Refinement....................................................................................................134.3.6. Codebeispiel .................................................................................................144.3.7. Refinement Codebeispiel ..............................................................................154.4. C4J .......................................................................................................................164.4.1. Facts .............................................................................................................164.4.2. Beschreibung ................................................................................................164.4.3. Framework Elemente ....................................................................................174.4.4. Refinement....................................................................................................174.4.5. Codebeispiel .................................................................................................184.4.6. Refinement Codebeispiel ..............................................................................205. Empfehlung...................................................................................................................216. Quellenangaben............................................................................................................22Matthias Hausherr Seite 3 / 22

Design By Contract in Java1. Der Ansatz Design By Contract1.1. DefinitionDesign By Contract, abgekürzt DBC, oder Programming By Contract ist ein Ansatz umSoftware zu entwerfen.Der Ansatz beschreibt, dass der Software Engineer formale und messbare Conditions anSchnittstellen anknüpft, im Sinne eines Vertrages zwischen Client und Server. DieseConditions werden zusätzlich zu den von der Programmiersprache verwendetenSicherungsmethoden (z.B. Typenkontrolle) verwendet und ermöglichen eine semantischePrüfung und damit sehr präzis definierte Schnittstellen.1.2. EntstehungDer geistige Vater des DBC ist Bertrand Meyer (geborenim Jahre 1950 in Frankreich). Prof. Meyer ist vor allemdeshalb vielen Informatikern ein Begriff, weil er um 1985die Sprache Eiffel entwickelt hat, die DBC konsequentverwendet. Prof. Meyer legt den Fokus auf Qualität undgeht davon aus, dass darauf automatisch auch eine hoheProduktivität folgt.Bertrand Meyer hat seinen Bachelor in Engineering ander École Polytechnique in Paris, seinen Master inStandford und den Ph. D. an der Université de Nancyabsolviert.Heute arbeitet Meyer an der ETHZ im Bereich SoftwareEngineering. Diplom- und Bachelorabgänger derFachhochschule Nordwestschweiz, die den Mastermachen möchten, haben also die Möglichkeit, bei HerrMeyer im Rahmen eines Masterstudiums diverseSoftware Engineering Kurse zu besuchen und somit DBCaus erster Hand zu lernen.Prof. Bertrand Meyer1.3. Idee und DBC-BegriffeDie Idee des Contracts zwischen Client und Server stammt aus dem Geschäftsleben: Zuersterklärt sich der Kunde bereit, dem Dienstleister eine gewisse Summe zu zahlen (entsprichtObligation des Clients). Der Dienstleister wiederum verpflichtet sich dem Kunden dafür etwasBestimmtes zu liefern (entspricht Obligation des Servers). Dieses Schema wird nun auf denSoftware Engineering Prozess übertragen.Der Server (z.B. eine Methode oder ein Modul) bestimmt sogenannte Preconditions. Diesestellen Bedingungen bzw. Obligationen dar, die der Client des Servers erfüllen muss undjeweils vor Ausführung des Server Codes geprüft werden. Der Vorteil für den Server liegtdarin, dass er sich nicht mit Fällen ausserhalb der Precondition befassen muss. Eindenkbares Beispiel hierfür wäre ein gültiger Wertebereich für eine Integer Variable.Im Gegensatz zu den Preconditions werden die Postconditions jeweils nach der Ausführungdes Server Codes geprüft und müssen vom Server selber erfüllt werden. Sie stellenBedingungen bzw. Obligationen dar, die der Server erfüllen muss und garantieren demAufrufer, dass gewisse Arbeiten verrichtet wurden. Oft greifen Postconditions dabei aufWerte zu, die vor der Ausführung der Methode galten.Matthias Hausherr Seite 4 / 22

Design By Contract in JavaZusätzlich zu Pre- und Postconditions spielen Invariants eine Rolle. Invariants sorgen dafür,dass bei Eintritts- und Austrittspunkten des Server Codes gewisse Conditions erfüllt bzw.Zustände gewahrt sind. Invariants sind in gewisser Weise also Pre- und Postconditions.Pre- und Postconditions sowie Invariants bilden einen Contract zwischen Client und Server.Der Contract selber ist die Formalisierung der Conditions die beide Seiten erfüllen müssen.Der Entwickler, der den Contract entwirft, muss sich sehr genau Gedanken machen, was derServer erwartet (Preconditions), was er liefert bzw. garantiert (Postconditions) und was derServer unterhaltet (Invariants). Die Contracts stellen auch ein Teil der Dokumentation dar,sie dokumentieren nämlich das Verhalten der einzelnen Software Komponenten.Durch Einsatz von DBC entsteht eine Kette von Verträgen, die schlussendlich für robustereSoftware sorgt. Wenn jedes einzelne Element der Kette garantieren kann, die Postconditionzu erfüllen sofern die Precondition eingehalten wurde, so entstehen weniger Fehler durchfalsche Annahmen seitens der Entwickler.Ein Prinzip des DBC ist es, ein Programm bei Nichteinhaltung eines Contracts sofort zuterminieren. Die Idee dahinter ist es, das die Probleme sofort angegangen werden und nichtauf die lange Bank geschoben werden. Somit kann es nicht passieren, dass ein Bug, dessenBehebung man auf später verschoben hat, vergessen wird und somit als Bug im Endproduktlandet. Während des Deployment selber werden die Contracts oft ausgeschaltet. Einerseitsmöchte man unter Umständen ein Programmabbruch im Problemfall verhindern undandererseits lässt sich damit die Performance erhöhen.1.4. Hauptziele1.4.1. Steigerung der QualitätUm die Reliability der Software zu verbessern sollte man Schnittstellen sehr genaudefinieren. DBC zwingt den Software Engineer dies schon früh im Design Prozess zu tun.Durch diese exakten Spezifikationen, welche Aufgaben ein Softwaremodul hat und welchePreconditions es stellt, erhöht sich auch die Wahrscheinlichkeit, dass es diesenAnforderungen später auch gerecht wird. Die Umkehrung dieser Überlegung ist ebenfallseinleuchtend: Wenn wir nicht genau spezifizieren was ein Modul tun soll, so wird es kaumdas Richtige tun.1.4.2. Contracts als DokumentationDas API eines Softwaremoduls entspricht einem Contract zwischen Client und Server. AlleObligationen und Rechte müssen öffentlich ersichtlich sein.Um Inkonsistenzen zwischen Source und Dokumentation zu vermeiden ist es zudem wichtig,dass das API direkt aus dem Source generiert wird. Ähnlich wie Java dieses Prinzip mitJavaDoc umsetzt, sollen auch die Contracts durch generierte Dokumentation beschriebenwerden. Bereits Eiffel hatte hierfür ein entsprechendes Tool, das aus dem Sourceautomatisch eine entsprechende Dokumentation inklusive Contracts generiert. Ziel ist es,den Fokus der Entwickler auf die Schnittstellen zu lenken.1.4.3. Debugging und Testing HilfeDank Contracts können potentielle Fehler früh aufgedeckt werden. Wird ein Contractgebrochen, wird das Programm sofort mit einer Exception terminiert und der Fehler für denEntwickler schnell ersichtlich. Durch DBC lassen sich viele abnormale Fälle in einer Artbehandeln, die Exception Handling vereinfachen und Fehlerquellen eliminieren.Matthias Hausherr Seite 5 / 22

Design By Contract in Java2. Java AssertionsSchon früh gab es Entwickler die DBC Support im JDK forderten. Dieser Wunsch stand anzweiter Stelle auf der Request For Enhancement Liste auf bugs.sun.com. Mit Java 1.4 wurdeschliesslich das assert Statement zur Verfügung gestellt und der Request geschlossen.Dieser Abschnitt beleuchtet Java Assertions und weshalb diese keine Implementation vonDesign By Contract darstellen.2.1. Das Assert StatementAssert Statements prüfen gewisse Conditions und sind entweder true oder false. Wird z.B.die Prüfung einer Inputvariable vergessen, so kann es unter Umständen passieren, dass dasProgramm vorerst weiterläuft, dann aber an einem späteren Punkt zur Runtime abstürzt. Umdies zu verhindern kann man mit einem assert Statement früh eine gewünschte Conditionprüfen. Ein mögliches Beispiel einer Prüfung eines Inputparameters:public int temp(double t) {assert(-273.15 >= t): "Temperature must be greater than -273.15";// Weiterführender Code …}Resultiert ein false aus der Assertion, so bricht das Programm mit einemjava.lang.AssertionError ab.2.2. VerwendungszweckAssertions sind in erster Linie ein Mittel zur frühen Detektion von Fehlern während derSoftware Entwicklung. Assertions sind syntaktisch einfach gestrickt und erlauben demEntwickler deshalb zügig und ohne grossen Overhead seine Annahmen als Conditions zucodieren. Was auf den ersten Blick nicht allzuwichtig erscheint, stellt eine wesentliche Hilfebei der frühen Lokalisation von Bugs dar.Ein Vorteil von Assertions gegenüber üblichen if-Anweisungen ist die Möglichkeit Assertionszu deaktiveren. Bei deaktivierten Assertions werden die assert Anweisungen nichtausgewertet und es entsteht keine Effizienzeinbusse.AssertionErrors haben etwa die gleiche Bedeutung wie RuntimeExceptions. Es ist wichtig zuunterscheiden zwischen den unchecked AssertionErrors bzw. RuntimeExceptions und denchecked Exceptions die deklariert und behandelt werden müssen. Assertions sind per defaultin JDK 1.5 disabled. Mit den VM tag –ea oder –enableassertions kann man diese aktivieren.Da man Assertions einfach deaktivieren kann eignen sie sich nicht für produktiven Code.Ein Vorteil von Exceptions gegenüber Assertions ist die Möglichkeit, ein Exception Handlingzu definieren für abnormale Fälle, von denen man weiss, dass sie eintreten und behandeltwerden können.2.3. Assertions und DBCWie man leicht erkennen kann, sind Assertions in Java sehr eingeschränkt. Preconditions,Postconditions und Invariants werden als solche nicht unterstützt und lassen sich mit demassert Statement allenfalls etwas leichter abbilden. Wer DBC in Java verwenden möchte istgezwungen, auf andere Lösungen zurückzugreifen.Wer möchte, dass Sun DBC in Java integriert wird, kann an der Diskussion des Bug mit ID4449383 und Subjekt „Support For Design by Contract, beyond a simple assertion facility“auf bugs.sun.com teilnehmen und mehr dazu erfahren (Link siehe Quellenangaben).Matthias Hausherr Seite 6 / 22

Design By Contract in Java3. Refinement (Contract Inheritance in DBC)3.1. RegelnIst eine Basisklasse an einen Contract gebunden, wird der Contract automatisch an alleSubklassen vererbt. Die Subklasse kann fakultativ zusätzliche Contracts definieren.Für die Vererbung von Contracts gelten einige Regeln und Überlegungen:1. Die Precondition der Subklasse darf nicht strenger sein als die Precondition derBasisklasse (entspricht einer logischen OR Verknüpfung). Damit wird sichergestellt,dass ein Zustand der die Precondition der Basisklasse erfüllt auch die Preconditionder Subklasse erfüllt.2. Die Postcondition der Subklasse darf nicht schwächer sein als die Postcondition derBasisklasse (entspricht einer logischen AND Verknüpfung). Damit wird sichergestellt,dass ein Zustand der die Postcondition der Subklasse erfüllt auch die Postconditionder Basisklasse erfüllt.3. Eine Subklasse übernimmt den Invariant der Basisklasse und hat diese zu erfüllen.Diese Regeln sorgen dafür, dass eine Subklasse den Contract der Basisklasse einhält undvielleicht sogar verbessert (mehr dazu im Folgeabschnitt Beispiel). Wie vom Liskov’schenSubstitutionsprinzip vorgeschrieben darf überall wo eine Basisklasse erwartet wird auch eineSubklasse deren eingesetzt werden. Die obigen Regeln ermöglichen eine Handhabung wiees sich Java Entwickler gewohnt sind, z.B. mit dem Statement BaseClass myBaseClass= new SubClass( );3.2. BeispielDas folgende Beispiel zeigt auf, dass es sinnvoll sein kann die Precondition in der Subklassegegenüber jener der Basisklasse zu schwächen. In diesem Beispiel kann mit der MethodeaddElement der Klasse Buffer ein Objekt einem limitierten Buffer hinzugefügt werden. DieMethode kann nur aufgerufen werden, sofern der Buffer nicht bereits voll ist und dashinzufügende Objekt keine null Referenz ist:public void addElement (Object o) {/** Precondition !isFull(); o != null; **/buffer[in % buffer.length] = o;in++;/** Postcondition … **/}Eine denkbare Subklasse könnte nun mit null Referenzen umgehen, indem es anstelle vonnull ein Defaultobjekt erzeugt und dem Buffer hinzufügt:public void addElement (Object o) {/** Precondition !isFull(); **/if (o==null)buffer[in % buffer.length] = new Default();elsebuffer[in % buffer.length] = o;in++;/** Postcondition … **/}Für die Spezialisierung gilt gemäss den Regeln für Refinement die verknüpfte Precondition(!isFull() AND o != null) OR !isFull(), die vereinfacht werden kann zu !isFull().Matthias Hausherr Seite 7 / 22

Design By Contract in Java4. Erweiterte Assertion Support Implementationen4.1. Erläuterung zu den CodebeispielenIn diesem Kapitel werden zwei verschiedene DBC Implementationen für Java vorgestellt. Fürjede näher vorgestellte Implementation wird ein Codebeispiel mitgeliefert. Die Idee ist, einensimplen Buffer mit Pre- und Postconditions sowie einem Invariant zu sichern und dem Lesereinen Eindruck zu geben wie der Code aussieht. Die Codebeispiele basieren auf einemBeispiel von der Jass Website.Die noch ungesicherte Klasse, von der jeweils ausgegangen wird, sieht wie folgt aus:package standardtest;public class Buffer {protected int in, out;private Object[] buf;public Buffer (int capacity) {// Preconditionbuf = new Object[capacity];// Postcondition}public boolean empty() {return in - out == 0;// Postcondition}public boolean full() {return in - out == buf.length;// Postcondition}public void add(Object o) {// Preconditionbuf[in % buf.length] = o;in++;// Postcondition}public Object remove() {// PreconditionObject o = buf[out % buf.length];out++;return o;// Postcondition}// Invariant}Buffer.javaLegende für alle Codebeispiele:// Precondition: Wird bei Methodeneintritt geprüft.// Postcondition: Wird bei Methodenaustritt geprüft.// Invariant: Wird vor und nach der Ausführung der Methode geprüft.Matthias Hausherr Seite 8 / 22

Design By Contract in Java4.2. Erläuterung zu den Refinement CodebeispielenFür jede näher dargestellte Implementation wird zudem ein Beispiel eines RefinedBuffervorgestellt. Diese Subklasse erweitert die Klasse Buffer und erweitert die Basisklasse umfolgende drei Punkte:• Die Methode contains(Object o) prüft, ob ein Objekt bereits im Buffer vorhanden ist.• Die Methode add(Object o) soll neu null Parameter erlauben und damit diePrecondition der Basisklasse schwächen. Wird ein null Parameter detektiert wird mitnew Object() ein Object erzeugt und in den Buffer eingefügt.• Die Postcondition der Methode add wird um eine Prüfung erweitert und damitgestärkt. Diese prüft ob das Object tatsächlich eingefügt wurde. Hierfür wird dieMethode contains(Object o) des RefinedBuffer verwendet.Die noch ungesicherte Klasse, von der jeweils ausgegangen wird, sieht wie folgt aus:package refinementtest;public class RefinedBuffer extends Buffer {public RefinedBuffer(int capacity) {super(capacity);}public void add(Object o) {// Preconditionif (o == null) {o = new Object();}super.add(o);// Postcondition}public boolean contains(Object o) {// Preconditionfor (int i = 0; i < in % buf.length; i++) {if (buf[i].equals(o)) {return true;}}return false;}}RefinedBuffer.javaLegende für alle Codebeispiele:// Precondition: Wird bei Methodeneintritt geprüft.// Postcondition: Wird bei Methodenaustritt geprüft.// Invariant: Wird vor und nach der Ausführung der Methode geprüft.Matthias Hausherr Seite 9 / 22

Design By Contract in Java4.3. Jass4.3.1. FactsErster Release: 1999Aktuelle Version: 2.0.14Entwicklungsstatus: Production/StableNext Release Date: Jass 3.0 / Datum unbekanntKosten:FreewareWebsite:http://csd.informatik.uni-oldenburg.de/~jass/4.3.2. BeschreibungJass benutzt für die Definition der DBC Elemente eine eigene Inputsprache, die jedoch fürjeden Javaentwickler leicht zu erlernen ist, da die Syntax simpel ist und die Anzahl derkeywords gering. An dieser Stelle sei darauf hingewiesen, dass die kommende Jass Version3.0 über keine eigene Inputsprache mehr verfügen wird sondern JML hierfür verwendenwird.Um die eigene Inputsprache zu verarbeiten und in reguläre Java Befehle umzuwandeln,benutzt Jass einen Precompiler der komplett in Java programmiert ist. Der Entwicklerergänzt seinen Javacode mit Jass Input und stellt dem Precompiler ein File wie z.B.sample.jass zur Verfügung. Dabei muss der Programmierer Preconditions am Anfang derMethode und Postconditions am Schluss der Methode platzieren. Invariants werden amSchluss des Klassensources platziert. Nach dem Preprocessorstep liegt ein kompiliertessample.java File vor. Dieses kann wie gewohnt mit den üblichen Java Tools kompiliert undausgeführt werden.Das Kompilat des Precompilers ersetzt die Inputsprache durch verschiedene Elemente. FürInvariants wird zu Beginn und beim Ende der Methode jeweils ein Aufruf der Jass MethodeJassCheckInvariant(String errorLocation) eingefügt und als Parameter eineKurzbeschreibung mitgegeben, wo die Invariant Prüfung ausgelöst wurde. Diese Methodesowie weitere von Jass intern benötigte Methoden stehen in einem vom Precompilergenerierten Abschnitt am Schluss des Sourcecodes.Wird bei der Postcondition auf die sogenannte Old Variable zugegriffen, welche den Zustanddes Objektes bei Methodeneintritt speichert, wird zu Beginn der Methode das Objekt cloned.Aus diesem Grund müssen Klassen, deren Postconditions auf die Variable Old zugreifen,auch das Interface cloneable implementieren. Es müssen dabei nur jene Variablen effektivkopiert werden, die auch tatsächlich mit Old referenziert werden.Die Pre- bzw. Postconditions werden vom Precompiler in if Statements umgewandelt, diesofern sie false returnen, Exceptions werfen. Namentlich handelt es sich um die(jass.runtime.) PreconditionException, PostconditionException und die InvariantException.Bei ihrer Erzeugung per Konstruktor wird der Auftretensort des Fehlers sowie eine kurzeFehlermeldung mitgegeben. Zusätzlich ist es möglich, Conditions mit einem Label zuversehen, das beim Werfen der Exception angezeigt wird.Bei der Definition von Preconditions dürfen nur öffentlich einsehbare Variablen undMethoden verwendet werden. Dies entspricht der availability Regel, die Bertrand Meyereingeführt hat und es dem Client der Klasse erleichtern soll zu verstehen, unter welchenBedingungen die Methode aufgerufen werden kann.Auf der Jass Website gibt es viele kleine Beispiele und Tutorials. Eine ausführlicheDokumentation gibt es nicht. Die von Jass mitgelieferten Beispiele sind ansehnlich underleichtern den Einstieg, gehen aber nicht über einfache Examples hinaus.Matthias Hausherr Seite 10 / 22

Design By Contract in Java4.3.3. Syntaktische ElementeIn diesem Abschnitt werden verschiedene syntaktische Elemente der Jass Inputsprache kurzerklärt mit dem Ziel, dem Leser die Arbeit mit Jass näherzubringen. Die Codebeispiele indiesem Abschnitt stammen von der offiziellen Jass Website.Für präzisere Beschreibungen der Inputsprache und dessen Anwendung möge sich dergeneigte Leser auf der offiziellen Jass Website informieren.requirePreconditions müssen am Beginn einer Methode platziert werden und werden durch daskeyword require gekennzeichnet. Require Statements prüfen die angegebenen Conditionsund werfen eine entsprechende Exception, falls diese nicht eingehalten werden.public void addElement (Object o) {/** require !isFull(); o != null; **/...}ensurePostconditions müssen am Schluss einer Methode platziert und durch das keyword ensuregekennzeichnet werden. Ensure ist identisch zu require, ausser dass es Post- und nichtPreconditions kennzeichnet. In einer Postcondition kann mit dem keyword Result auf denReturnwert der Methode zugegriffen werden.public void addElement (Object o) {.../** ensure !isEmpty() && contains(o); **/}OldMit der speziellen Variable Old kann auf den Zustand des Objektes vor Methodenausführungzugegriffen werden. Um auf Old zugreifen zu können, muss die Klasse der Postconditionzwingend das Interface Cloneable implementieren. Es müssen dabei nur jene Variableneffektiv kopiert werden, die auch tatsächlich mit Old referenziert werden.public void addElement (Object o) {.../** ensure !isEmpty() && contains(o); count == Old.count+1; **/}changeonlyMit dem Konstrukt changeonly{…} können Attribute spezifiziert werden, die sich veränderthaben dürfen. Attribute, die nicht in changeonly aufgelistet sind, dürfen keinen verändertenWert aufweisen. Ein changeonly mit einer leeren Liste steht entsprechend dafür, dass keineder Variablen ihren Wert verändert haben darf. Damit lässt sich einfach immutabilitysicherstellen analog den const Methoden aus C++. Für den Gebrauch dieses Konstruktesmuss das Interface Cloneable in der Klasse der Postcondition implementiert werden.public void addElement (Object o) {.../** ensure !isEmpty() && contains(o); Old.count == count-1;changeonly{count,buffer}; **/}Matthias Hausherr Seite 11 / 22

Design By Contract in JavainvariantEin Invariant muss am Ende der Klasse spezifiziert werden und wird durch das keywordinvariant gekennzeichnet.public class Buffer {.../** invariant 0

Design By Contract in Javaforall und existsMit den Ausdrücken forall und exists können Conditions überprüft werden, die auf einebestimmte Menge von Objekten zutreffen müssen.(forall i : {out%buf.length .. in%buf.length-1} # buf[i] != null);4.3.4. JavaDoc ErweiterungEin Highlight von Jass besteht in der Erweiterung von JavaDoc durch eigene Tags. Wie vonDBC verlangt ist es mit Jass möglich, direkt aus den jass Files eine JavaDoc zu erstellen, diemit DBC Informationen angereichert ist.Für die Methoden add und remove des Beispiels im Abschnitt Codebeispiel sieht dasErgebnis (die Methodenbeschreibungen ausgenommen) wie folgt aus:4.3.5. RefinementJass überlässt dem Entwickler die Entscheidung, ob er die Vererbungsregeln für Contractseinhalten möchte. Falls er dies tut so muss er in der Subklasse das Interfacejass.runtime.Refinement implementieren. Das Interface selber hat keine Methoden sondernlöst zur Runtime Überprüfungen aus, die im Falle eines Regelbruches einejass.runtime.RefinementExecption werfen. Eine solche Exception bedeutet im Klartext, dassetwas mit dem Design nicht in Ordnung ist.Leider musste ich feststellen, dass der eben beschriebene Mechanismus nur mangelhaftimplementiert wurde. Designfehler bei der Definition der Conditions werfen nur dannRefinementExceptions, falls diese zur Runtime einen Einfluss haben. Eine in der Subklasseverstärkte Precondition wird zum Beispiel nur entdeckt, falls diese nicht erfüllt wird und somitden Methodenaufruf verhindert. Analog dazu ist es ist zum Beispiel möglich einePostcondition zu entfernen, während sie in der Basisklasse vorhanden ist, und dieRefinementchecks weisen den Entwickler unter Umständen nicht darauf hin.Für die die Prüfung, ob die Regeln der Contract Inheritance eingehalten werden verwendetJass eine sogenannte Abstraction Function. Diese projeziert einen konkreten Zustand derSubklasse auf ein Objekt ihrer Superklasse. Die Abstraction Function muss in Form derMethode jassGetSuperState definiert werden, die eine Referenz auf ein Objekt des Typender Basisklasse zurückgibt. Dieses Objekt muss sich im selben Zustand befinden wie auchdas Objekt des Typs Subklasse. Für einen Buffer bedeutet dies z.B. dass das Objekt derBasisklasse dieselben Elemente hat wie das Objekt der Subklasse. In einigen Fällen ist dieAbstraction Function trivial (siehe Refinement Codebeispiel), in anderen Fällen kann dieMatthias Hausherr Seite 13 / 22

Design By Contract in JavaSuche einer Abstraction Function ein ziemlich mühsamer und zeitraubender Prozess sein.Auch die Tatsache, dass Conditions teilweise redundant in Basis- und Subklasseimplementiert sein müssen hinterlässt einen zwiespältigen Eindruck.4.3.6. Codebeispielpackage standardtest;public class Buffer implements Cloneable {protected int in, out;private Object[] buf;public Buffer() {buf = new Object[0];/** ensure buf.length == 0; **/}public Buffer (int capacity) {buf = new Object[capacity];/** ensure buf.length == capacity; **/}public boolean empty() {return in - out == 0;/** ensure changeonly{}; **/}public boolean full() {return in - out == buf.length;/** ensure changeonly{}; **/}public void add(Object o) {/** require [buffer_not_full] !full(); [valid_object] o != null; **/buf[in % buf.length] = o;in++;/** ensure changeonly{in,buf}; Old.in == in - 1; **/}public Object remove() {/** require [buffer_not_empty] !empty(); **/Object o = buf[out % buf.length];out++;return o;/** ensure changeonly{out}; Old.out == out - 1;[valid_object] Result != null; **/}protected Object clone() {Object b = null; // This is sufficient because Oldtry { // only accesses the members in and outb = super.clone();} catch (CloneNotSupportedException e){}return b;}/** invariant [range] 0

Design By Contract in Java4.3.7. Refinement Codebeispielpackage refinementtest2;public class RefinedBuffer extends Bufferimplements jass.runtime.Refinement {public RefinedBuffer(int capacity) {super(capacity);/** ensure buf.length == capacity; **/}public void add(Object o) {/** require [buffer_not_full] !full(); **/if (o == null) {o = new Object();}super.add(o);/** ensure changeonly{in,buf}; Old.in == in - 1;[contains_object] contains(o); **/}public boolean contains(Object o) {/** require [Valid_object] o != null; **/for (int i = 0; i < in % buf.length; i++) {if (buf[i].equals(o)) {return true;}}return false;/** ensure changeonly{}; **/}// Abstraction Functionprivate Buffer jassGetSuperState() {return (Buffer) this;}/** invariant [range] 0

Design By Contract in Java4.4. C4J4.4.1. FactsErster Release: UnbekanntAktuelle Version: 2.5.2.Entwicklungsstatus: Production/StableNext Release: C4J 3 RC 1 / Dezember 06Kosten:FreewareWebsite:http://c4j.sourceforge.net/4.4.2. BeschreibungC4J sieht vor, dass für jedes Java File, das gesichert werden soll, ein separates Java Fileprogrammiert wird, das den zum File zugehörigen Contract implementiert. Der Contract wirdzur Kompilierzeit mittels einer Annotation im Java Source File mit dem Contract Fileverknüpft. Das Resultat ist eine saubere Trennung von Sourcecode und Contract. DerContract selber wird in Java implementiert.Die Verknüpfung von Source und Contract File wird mit dem in JDK 5.0 eingeführtenjavaagent implementiert. Diese erlaubt es zur Runtime die Verträge an die Source zu linken,indem der Agent den Ladeprozess einer Klasse beobachtet und Methodenaufrufe in dieagent library auslöst, die den Bytecode verändern. C4J beinhaltet eine sogenannteInstrumentor Klasse, die den Bytecode aller Sources verändert (sogenannt instrumentiert),die über eine ContractReference Annotation mit einem Vertrag verknüpft sind.Für jede Methode lassen sich im Contract File zwei Methoden schreiben, die jeweils die Preunddie Postcondition darstellen. Der Invariant wird in der speziellen Methode ClassInvariantimplementiert. Innerhalb dieser Methoden können Conditions mit assert Statements geprüftwerden. Diese Methoden werden zu den für Pre- und Postconditions bzw. Invariantsüblichen Stellen zur Runtime aufgerufen. Wird ein Contract nicht eingehalten, resultiert einjava.lang.AssertionError.Contract Implementationen haben eine Referenz auf das Objekt, das sie verifizieren. Diesermöglicht bequemen Zugriff auf Variablen und Methoden des Objekts. Um die availabilityRegel von Bertrand Meyer nicht zu verletzen, darf bei der Definition von Preconditionsjedoch ausschliesslich auf öffentlich sichtbare Elemente zugegriffen werden.C4J arbeitet für die Prüfung der einzelnen Conditions mit Java Assertions, die erst seit JDK1.4 verfügbar und per default deaktiviert sind. Aus diesem Grund muss das Programm, dasDBC mit C4J implementiert, auch mit dem tag –enableassertions gestartet werden.Eine Schwachstelle von C4J ist das Fehlen einer einfachen Möglichkeit des Zugriffs auf denObjektzustand vor Methodenausführung innerhalb von Postconditions. Während Jass hierfürbequeme Konstrukte bietet, ist dies in C4J nur relativ umständlich möglich. Besserung fürdieses Problem verspricht der nächste C4J Release, die Version 3.0. Diese wird es demEntwickler erlauben mit den keywords old und current auf den früheren respektive denaktuellen Inhalt der Variable zuzugreifen.Leider gibt es keine ausführliche Dokumentation und die C4J Website bietet nureingeschränkte Tutorials und Erläuterungen. Die mitgelieferten Examples sind kaumbrauchbar. C4J ist einfach zu lernen und die Einarbeitungszeit gering. Es gibt nur wenigegewöhnungsbedürftige Konstrukte und auch diese sind schnell begriffen.Matthias Hausherr Seite 16 / 22

Design By Contract in Java4.4.3. Framework ElementeDer Contract kann, sofern er eine Erweiterung der Klasse ContractBase darstellt und imKonstruktor die target Referenz an super übergibt mit der Referenz m_target, auf dieVariablen und Methoden des zu verifizierenden Objekts zugreifen.Möchte man den Zustand eines Objektes vor Methodenausführung in einer Postconditionprüfen, so muss dieser Wert innerhalb einer Precondition mit einem Aufruf der MethodesetPreconditionValue(„key“, m_target.myVariable) gespeichert werden. Die mit dieserMethode gespeicherten Objekte müssen Cloneable nicht zwingend implementieren. Es wirdlediglich die Referenz auf das Objekt abgespeichert, keine Kopie des Objektes. Um auf dieVariablenwerte vor Methodenausführung zugreifen zu können, muss man deshalb manuelleine Kopie des Elementes erzeugen und mit setPreconditionValue abspeichern. PrimitiveDatentypen können ohne die Erstellung einer solchen Kopie direkt gespeichert werden, dadiese keine Objekte darstellen und deshalb wie in Java üblich automatisch kopiert werden.Das Objekt kann anschliessend in der Postcondition mit einem Aufruf der MethodegetPreconditionValue(„key“) abgefragt und für Conditions benutzt werden.Mit der Methode getTargetField(„key“) kann auf private Variablen des zu prüfenden Objekteszugegriffen werden.Diese Framework Elemente sind ziemlich umständlich und werden im C4J ReleaseCandidate 3.0 durch einfachere Konstrukte ersetzt.4.4.4. RefinementIm Gegensatz zu Jass setzt C4J die Refinement Regeln konsequent um. Verträge werdenan ihre Subklassen mitvererbt und sind an diese gebunden. Eine Subklasse kann zusätzlichan einen eigenen Contract gebunden werden. In solch einem Fall wird zuerst diePrecondition der Basisklasse geprüft und anschliessend die der Subklasse. NachMethodenausführung wird zuerst die Postcondition der Subklasse geprüft und dann die derBasisklasse. Bei den Invariants wird immer zuerst der Invariant der Basisklasse und dannjener der Subklasse ausgeführt.Bei der Erarbeitung des Refinement Codebeispiels bin ich auf einen merkwürdigen Fehlergestossen. Eine Postcondition einer Subklasse, deren Methode einen supercall beinhaltete,warf Exceptions, obwohl diese zweifelsfrei richtig implementiert wurde. Nach Recherche desProblems im C4J Forum stellte sich heraus, dass es sich hierbei um einen Bug handelte. Füreine Beschreibung des Bugs und einen Workaround siehe Quellenangaben.Leider war es mir entgegen meinen Erwartungen nicht möglich, eine Precondition in einerSubklasse zu schwächen. C4J prüft in jedem Fall zur Runtime zuerst die Precondition derBasisklasse zuerst und anschliessend die der Subklasse. Dies führt aufgrund der strengerenConditions der Basisklasse zu einem Fehler.Der Grund dafür ist, dass C4J bei der Prüfung der Conditions nicht die üblichen RefinementRegeln verwendet, sondern einen eigenen Weg geht, der in einer eigenen Reihenfolge derContractverifizierung mündet. Als Konsequenz muss in jedem Fall sowohl der Contract derBasisklasse als auch jener der Subklasse eingehalten werden.Dieses Verhalten kann in Szenarien in denen eine Klasse mehrere Interfaces implementiert,die jeweils dieselbe Methode mit unterschiedlicher Precondition definieren, Vorteileaufweisen. In einem solchen Fall kann eine OR Verknüpfung der Preconditions unterUmständen nicht ausreichend sein und zu irrtümlicherweise erfüllten Preconditions führen.Matthias Hausherr Seite 17 / 22

Design By Contract in JavaDie Auseinandersetzung mit diesem Mechanismus ist wichtig, möchte man C4J in einemgrösseren Projekt nutzen. Leider ist dieses Verhalten nur mangelhaft dokumentiert. Diebeste verfügbare Quelle zu diesem Thema besteht in einem Forumthread des offiziellenForums. Für mehr Informationen über dieses Thema ist der Link in den Quellenangaben zukonsultieren.Um ein Verständnis für den Refinement Mechanismus von C4J zu entwickeln, muss mansich zuerst mit der Materie auseinandersetzen. Grundsätzlich ist das Refinement in C4J gutimplementiert: Conditions müssen nicht redundant in Basisklasse und Subklasseimplementiert werden so wie dies z.B. bei Jass der Fall ist. Da für jedes Source File einContract File besteht, geht die Übersicht auch bei komplexeren Sourcestrukturen nichtverloren.4.4.5. Codebeispielpackage standardtest;import net.sourceforge.c4j.ContractReference;@ContractReference(contractClassName = "standardtest.BufferContract")public class Buffer {// Klassencode ...}Buffer.javapackage refinementtest2;import net.sourceforge.c4j.ContractBase;public class BufferContract extends ContractBase {public BufferContract(Buffer target) {super(target);}public void pre_Buffer(int capacity) {assert capacity > 0;}public void pre_add(Object o) {assert o != null;assert !m_target.full();for (int i = 0; i < m_target.buf.length; i++) {if (m_target.buf[i] != null) {setPreconditionValue("in"+i, m_target.buf[i]);}}}setPreconditionValue("in", m_target.in);Matthias Hausherr Seite 18 / 22

Design By Contract in Javapublic void post_add(Object o) {int bufLen = m_target.buf.length;for (int i = 0; i < bufLen; i++) {if (m_target.buf[i] != null && i != m_target.in-1 % bufLen) {Object preIn = ((Object) getPreconditionValue("in"+i));assert preIn.equals(m_target.buf[i]);}}assert m_target.buf[m_target.in-1 % bufLen].equals(o);}int preIn = ((Integer) getPreconditionValue("in"));assert preIn == m_target.in - 1;public void pre_remove() {assert !m_target.empty();setPreconditionValue("out", m_target.out);}public void post_remove() {int preOut = ((Integer) getPreconditionValue("out"));assert preOut == m_target.out - 1;assert getReturnValue() != null;}public void classInvariant() {assert 0

Design By Contract in Java4.4.6. Refinement Codebeispielpackage refinementtest2;import net.sourceforge.c4j.ContractReference;@ContractReference(contractClassName ="refinementtest2.RefinedBufferContract")public class RefinedBuffer extends Buffer {// Klassencode ...}RefinedBuffer.javapackage refinementtest2;public class RefinedBufferContract {private RefinedBuffer target = null;public RefinedBufferContract(RefinedBuffer target) {this.target = target;}public void pre_add(Object o) {// Abschwächen der Precondition nicht möglich! Die// Precondition der Basisklasse bleibt in jedem Fall// bestehen und wird vor Aufruf dieser Methode ausgeführt.// Siehe Kapitel C4J >> Refinement für mehr Information.}public void post_add(Object o) {assert target.contains(o);}public void pre_contains(Object o) {assert o != null;}}RefinedBufferContract.javaMatthias Hausherr Seite 20 / 22

Design By Contract in Java5. EmpfehlungSowohl Jass als auch C4J weisen völlig verschiedene Implementationsansätze auf. C4Jvermag mich mehr zu überzeugen als Jass. Besonders die strikte Trennung von Source undContract erweist sich als elegante Lösung. Die Schwächen wie die teilweise umständlichenKonstrukte von C4J, werden vorraussichtlich mit dem nächsten Release Candidate von C4Jaddressiert und verbessert.Das etwas gewöhnungsbedürftige Refinement und die mangelnde Dokumentation sindSchwachstellen. Wer sich überlegt C4J für grössere Projekte einzusetzen, soll sich zuerstvertieft mit dem Refinement Verhalten von C4J auseinandersetzen um das nötigeGrundwissen zu erarbeiten.Matthias Hausherr Seite 21 / 22

Design By Contract in Java6. QuellenangabenDesign By ContractEinführung zu DBC von Eiffel Softwarehttp://archive.eiffel.com/doc/manuals/technology/contract/Prof. Bertrand Meyers ETH Homepagehttp://se.ethz.ch/~meyer/Verschiedene Wikipedia Artikelhttp://en.wikipedia.org/wiki/Design_by_contracthttp://de.wikipedia.org/wiki/Design_By_Contracthttp://en.wikipedia.org/wiki/Bertrand_MeyerDer DBC ‘Request For Enhancement’ – ‘Support For Design by Contract' auf bugs.sun.comhttp://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4449383Java AssertionsBehandlung der Themen Assertions und Exceptionshttp://www.javaforce.com/content/view/119/66/http://leepoint.net/notes-java/flow/assertions/assertions.htmlJassJass Website und Quelle für Codebeispielehttp://csd.informatik.uni-oldenburg.de/~jass/C4JC4J Homepagehttp://c4j.sourceforge.net/Erläuterungen zum Java Agent welcher von C4J verwendet wirdhttp://javahowto.blogspot.com/2006/07/javaagent-option.htmlhttp://www.javalobby.org/java/forums/t19309.htmlBugreport und Workaround sowie Information zu der Abarbeitungsreihenfolge der Conditionshttp://sourceforge.net/forum/forum.php?thread_id=1607817&forum_id=547819Matthias Hausherr Seite 22 / 22