PROGRAMMING PRE- AND POSTCONDITIONS, INVARIANTS AND METHOD CONTRACTS B MODULE 2: SOFTWARE SYSTEMS 13 NOVEMBER 2013

Week 1 Values, conditions Classes, objects Week 2 Specifications Testing Week 3 Abstraction, inheritance Week 4 Interfaces, abstract classes Arrays Week 5 Collections Generic structures Week 6 Exceptions Stream I/O GUIs Week 7 Concurrency Networking Week 8 Security Week 9/10 Project Software Systems - Programming 2 OVERVIEW PROGRAMMING LINE

 Preconditions, postconditions  Class invariants  Programming via contract Nino & Hosch: Chapter 5 Manual: JML appendix Tool support: OpenJML Software Systems - Programming 3 CONTENTS

Example: usage of class Counter public class TennisPlayer { Counter fh, bh; public void hitForehand() { fh.next(); } public void hitBackhand() {...} public int totalHits() { return fh.getValue() + bh.getValue(); } Software Systems - Programming 4 This is only correct if the result of getValue() always is positive +getValue() +reset() +next() Counter -value POSTCONDITIONS

public class Counter { private int value; public Counter( ) { value = 0; } // always returns a positive value ensures \result >= 0; public int getValue( ) { return value; } // rest of class } Software Systems - Programming 5 POSTCONDITION OF GETVALUE Informal Formal

 Unambiguous He ate the cookies on the couch Eating(p, cookies) /\ Sitting(p, couch) Or Eating(p, cookies) /\ Sitting(cookies, couch)  Can be checked  Clear connection with program code and variables  Often executable Software Systems - Programming 6 ADVANTAGES OF FORMAL SPECIFICATION

 Property that always holds when the method terminates  Caller can rely on this Examples  The result of getValue() is always positive: \result >= 0  After a call to next() the result of getValue() is always equal to the result of getValue() before the call plus 1: getValue() == \old(getValue()) + 1 Software Systems - Programming 7 POSTCONDITION DEFINITION

 Language for writing behaviour specifications of Java programs  Syntax: Java with specification-specific extensions  \result  \old(E)  ==> (implies)  \forall, \exists  Specifications written as special Java comments (start  OpenJML: type checking of specifications  Complete language description: see jmlspecs.org Software Systems - Programming 8 JAVA MODELLING LANGUAGE (JML) Resembles language used in book, but with tool support Conditional expression in Java: ? : ;

ensures getValue() == \old(getValue()) + 1; public void next( ) { value = value + 1; } Requires that getValue does not have side effects pure */ public int getValue() Allows to use getValue() in specification Checks purity separately Software Systems - Programming 9 METHOD CALLS IN SPECIFICATIONS If specifications can have side effects: execution with and without precondition check would have different behaviour

Suppose we add a method setValue(int v) to the Counter requires v >= 0; ensures getValue() == v; public void setValue(int v) {...}  This postcondition can only be guaranteed if v is positive (because specification of getValue() ensures this is always positive)  This is specified as a precondition (keyword: requires ) Software Systems - Programming 10 PRECONDITIONS Also okay: requires v >= 0 */ ensures getValue() == v */ public void setValue(int v) {...}

Class Lock public Lock(int code) public boolean isOpen() public void close() public void enterDigits(int digit) Only functions correctly if:  0 <= code and code <= 999  0 <= digit and digit <= 9 The caller has to ensure this The Lock implementation does not have to check this Software Systems - Programming 11 ANOTHER EXAMPLE Preconditions!

 Condition that should always hold when a method is called  Caller has to ensure this Examples  The value of the code parameter in the Lock constructor should be between 0 en 999 requires 0 <= code && code <= 99;  The reset method can only be called when the counter has reached MAX requires getValue() == Counter.MAX; Software Systems - Programming 12 DEFINITION PRECONDITION

Example: Counter public int getValue() public void setValue(int v) public void next() public void previous() Possible preconditions  setValue(int v) : v >= 0  previous() : getValue() > 0 Why?  Pro: Saves a test in the implementation  Contra: forces the caller to do a call Software Systems - Programming 13 PRECONDITIONS SHOULD NOT BE TOO STRONG 

 Pre- and postconditions are documentation about the behaviour of the class to the outside world  Therefore, they should respect visibility rules of the class  Private fields cannot be used in (public) specifications ensures value == \old(value) + 1; public void next( ) { value = value + 1; } Reason: internal representation might change, but outside behaviour might be unchanged Software Systems - Programming 14 VISIBILITY OF PRE- AND POSTCONDITIONS X

Some properties hold for every internal reachable state of an object Example public invariant getValue() >= 0;  Public invariant: uses only publicly visible methods  Private invariant: about internal state, not visible as documentation of the class, but considers implementation private invariant value >= 0; Software Systems - Programming 15 INVARIANTS

 In general: a property that always holds  In our setting:  A property that holds for all visible reachable states of all class instances  Can refer to internal state of the object (this is the definition of Nino & Hosch)  Can also be public documentation of the behaviour of a class Software Systems - Programming 16 DEFINITION INVARIANT

Basic principle  If caller respects preconditions, the method implementation guarantees postconditions  Class invariant helps to show that implementation ensures postconditions Problem  Can client be trusted?  What if client does not respect the postcondition?  Method will not guarantee postconditions  Next methods are called under wrong conditions  Program does not behave properly Software Systems - Programming 17 PROGRAMMING BY CONTRACT

Assumption Client will always respect preconditions Consequences No special precautions necessary Justified when client and server are developed together. Software Systems - Programming 18 ANSWER 1: TRUST CLIENT

Assumption  Client will not always respect preconditions  When this happens, program should stop, but in controlled manner Consequences  Implementation checks (some) preconditions  assert precondition  stop program when precondition not respected  In particular useful to make sure internal invariants are preserved  Applicable to larger programs Software Systems - Programming 19 ANSWER 2: GENERATE ERROR MESSAGE

Assumptions  Client will make mistake (might even be on purpose)  Program should not fail Consequences  Implementation checks all preconditions  Precondition not respected  choose appropriate emergency solution (for example: default values)  Postcondition and invariant always respected  Useful for critical applications Software Systems - Programming 20 ANSWER 3: DEFENSIVE PROGRAMMING

 Use dedicated tool to insert pre- and postcondition checks during execution  Construct formal proof that  Preconditions hold at every method calls  Postconditions hold at every method exit OpenJML:  RAC – runtime assertion checking  ESC – extended static checking Software Systems - Programming 21 ANSWER 4: CHECK OR VERIFY Out of scope

 Behaviour of methods formally specified  Precondition: what should hold when method is called  Postcondition: what does implementation guarantee when method finishes  Class invariant: property that holds throughout life of object  Specifications can be checked during execution  Insert checks manually (using asserts)  Use dedicated tool support Software Systems - Programming 22 MAIN POINTS