Assertions

1. Assertions Prasun Dewan Comp 114

2. Assertions • Declare some property of the program • Potentially useful for • specification • testing • formal correctness • documentation

3. Compile time vs. runtime properties • Some assertions language supported • Compile time • String s = nextElement() • Runtime • ((String) nextElement()) • Asserting type properties of object. • Assertions describe runtime properties

4. Application-independent vs. dependent • Language can provide us with fixed number of application-independent assertions. • Cannot handle • First character of String is a letter. • Letter concept not burnt into language. • Class Character defines it • Innumerable assertions about letters possible • Second elements of string is letter. • Third element of string is letter. • Need mechanism to express arbitrary assertions

5. Assertions vs. Exceptions • Wrong assertion results in exception. • Wrong class cast leads to class cast exception.

6. Reasons for exceptions • User error • Programmer cannot prevent it • Internal error • Programmer can prevent • Assertions catch internal errors.

7. Reasons for assertions • Why catch internal errors via assertions? • Alternative: Make test runs and look at output.

8. Finite test runs • Some errors not exhibited in test runs. • Inconsistent string not printed because of user option.

9. Late detection • Output produced much after the cause • Storing an inconsistent string causes erroneous output when the string is matched not when it is stored.

10. Complex output • May not know what the output is, but know the relationship between input and output • (123.345 * 789.123 ) / 123.345 == 789.123 • Number is divisible by a prime factor

11. No manifestation in output • Some errors have to do with efficiency. • Storing duplicate items in a set. • Not exhibited in output

12. Our own mathematical syntax to be mapped to Java later Example Assertion { y = 10/x; z = 5} assert (y == 10/x) & (z == 5)

13. Definition • Example { y = 10/x; z = 5} assert (y == 10/x) & (z == 5) • Statement regarding • State of program (variable values) • Program counter (currently executing statement) • PC implicit by putting assertion next to a statement • Specifies Boolean expression involving selected program variables • Assertion fails if boolean expression false • Not all program variables named • X unnamed above • Does not care about unnamed variables

14. Role of Assertions • Debugging • Exception thrown if assertion fails • Documentation // detailed prime factor computation code …. assert (number % prime) == 0 • Specification • Assertion defined desired result of the code to be implemented • Formal correctness • Can prove if assertion met by code. • Need assertions regarding language constructs

15. Recording Variables {X = X + 1} assert ??? • Cannot say: {X = X + 1} assert X == X + 1; • Introduce recording variable {oldX = X; X = X + 1} assert X = oldX + 1 • Special variables needed to make assertions sometimes

16. assert (x !=0) { y = 10/x; z = 5} assert (y == 10/x) & (z == 5) Precondition What is expected before statement(block) execution Postcondition What is guaranteed after statement(block) if precondition met Together define a contract Preconditions and Postconditions

17. pre (x !=0) post (y == 10/x) & (z == 5) { y = 10/x; z = 5} Both conditions placed before statement block. Alternative syntax

18. x = 0; pre (x !=0) post (y == 10/x) & (z == 5) { y = 10/x; z = 5} Precondition may not be satisfied by previous incorrect statement. Yet it is a correct precondition Incorrect precondition?

19. pre (x > 0) post (y == 10/x) & (z == 5) { y = 10/x; z = 5} Some assertions imply others x > 0  x !=0 Implied assertion is considered weaker. Can always replace precondition with a stronger one. Prefer weakest precondition Requires fewest assumptions. Statement can be used in more contexts Better documentation Alternative precondition

20. pre (x != 0) post (z == 5) { y = 10/x; z = 5} Some assertions imply others y == 10/x & (z == 5) => z == 5 Can always replace postcondition with a weaker one Prefer strongest postcondition More detailed documentation Can be used in more contexts Can be followed by statements with stronger preconditions. Alternative postcondition

21. pre arrays, loops, procedures {Take Comp 114} post objects, inheritance, trees, recursion, assertions, composite, iterator, visitor pattern pre arrays, loops, procedures, objects, inheritance {Take Comp 114} post recursion Too strong Too weak Comp 114

22. Course Analogy • Preconditions • Declared course prerequisite • Post conditions • Advertised objectives • Stronger precondition • Does not allow some students to enroll • Weaker post conditions • Does not allow enrollment in future courses

23. pre (x !=0) post (y == 10/x) & (z == 5) { y = 10/x; z = 5} Says nothing about x. Strongest Postcondition?

24. pre (x !=0) post (y == 10/x) & (z == 5) & (x != 0) { y = 10/x; z = 5} Strongest post condition given the precondition The stronger the pre condition, stronger the post condition. Strongest Postcondition

25. pre (x > 0) post (y == 10/x) & (z == 5) & (x > 0) & (y > 0) { y = 10/x; z = 5} Stronger precondition Stronger postcondition Alternative weakest/strongest pair

26. Multiple valid pairs • Weakest precondition relative to post condition. • Strongest post condition relative to pre condition. • A statement not associated with a unique pair that is best. • Strengthening the precondition strengthens the post condition • What is the “right pair?”

27. Two approaches • Start with a precondition • Find the strongest postcondition we can prove. • Start with a post condition • Find the weakest precondtion for it.

28. Theoretical specification point of view • Specify the result needed as a post condition. • Identify the weakest precondition needed to obtain the result. • Write a program that satisfies the pair.

29. Reality specification point of view • Based on what you can assume you change your expectations. • Iterative process.

30. Debugging/specification/ documentation point of view • Precondition of a statement should be weakest one necessary for “correct” operation of program. • Correct means no exception. • A statement that is not equivalent should not have the same pre and post condition

31. pre (x >0) post (y == 10/x) & (z == 5) & (x > 0) { y = 10/x; z = 5} Debugging/specification/ documentation point of view Statements are not equivalent pre (x >0) post (y == 10/x) & (z == 5) & (x > 0) { y = 10/x; z = 5; x = abs(x) + 1}

32. pre (x !=0) post (y == 10/x) & (z == 5) & (x != 0) { y = 10/x; z = 5} Debugging/ specification/ documentation point of view Best pre and post conditions

33. Proving programs correct point of view • Precondition can be stronger than one that is the best one for the statement from debugging/specification/documentation point of view • Allows us to derive pre and post conditions of containing statement/program

34. pre post (x == 1) {x = 1} pre (x == 1) post (y == 10/x) & (z == 5) & (x == 1) { y = 10/x; z = 5} Program correctness proof

35. pre post (y == 10/x) & (z == 5) & (x == 1) {x = 1; y = 10/x; x= 5} Program correctness proof

36. Changeable assertions • What we assert about a statement (to prove program correct) may depend on what is executed before it. • Need facilities to change assertions easily. • Proxies explained later address this.

37. Weakest possible condition • Implied by anything • true • p  true • If p is true then true is true. • But true is always true. • So p can be any boolean expression.

38. Strongest possible condition • Implies anything • false • false  p • If false is true then p is true • But false is never true. • So any p is implied. • “I will give you a million dollars when hell freezes over”

39. Important equivalence • P  Q  !P | Q • P  true  !P | true  true • false  Q  !false | Q  true

40. Unreachable statement Asserting false • switch c { • case ‘a’: … • case ‘b’: … • default: assertfalse • }

41. pre (x !=0) post (y == 10/x) & (z == 5) & (x != 0) { y = 10/x; z = 5} True before and after statement Invariant

42. inv (x !=0) post (y == 10/x) & (z == 5) { y = 10/x; z = 5} List invariant separately Separately declared

43. Invariants for debugging purposes • Should never be false • False strongest invariant of all statements. • But not best for a reachable statement as it does not convey useful information • Never assert it for reachable statements if assertion not done for program proofs. • Should never involve recording variables • recording variables describe how program variables change • invariants describe how these variables do not change

44. sum = 0; j = 0; while (j < n) { j++; sum = sum + j; } Holds true before and after each loop iteration, that is, before and after each execution of loop body. Loop Invariant

45. inv (sum = 0j k) & (j <= n ) & (j >= 0) sum = 0; j = 0; while (j < n) { j++; sum = sum + j; } Holds true before and after each loop iteration, that is, before and after each execution of loop body. Loop Invariant

46. invariant x != 0 post (y == 10/x) & (z == 5) & (x != 0) void m () { y = 10/x; z = 5; } Preconditions, postconditions, invariants associated with method body Method assertions

47. publicclass C { int x =0; int y = 1; publicvoid incrementXAndY () { incrementX(); incrementY(); } publicint getX() { return x;} publicint getY() { return y;} incrementX() { x++;} incrementY() { y++;} } Preconditions, postconditions, invariants shared by all public methods of class Class assertions

48. invy == x + 1 publicclass C { int x =0; int y = 1; publicvoid incrementXAndY () { incrementX(); incrementY(); } publicint getX() { return x;} publicint getY() { return y;} incrementX() { x++;} incrementY() { y++;} } Preconditions, postconditions, invariants shared by all public methods of class Class assertions

49. Expressing Assertions • Natural language • All array elements are not odd. • All array elements are either odd or positive. • Easy to read but ambiguous. • Programming language • Library or language constructs • Executable, unambiguous but language-dependent and awkward • Useful for debugging • Specification cannot be done before language decided. • Mathematical language • Uambiguous, time tested, convenient but not executable

50. Propositional Calculus • Logic operators • not, and, or • We will use Java syntax. • Quantifiers • Universal ( ) • Existential ( ) • Propositional variables • Program • Others: Recording, Quantifier • Propositions • Boolean expressions involving operators, variables, and quantifiers • Simple/quantified propositions • Do not use/use quantifiers