1. Assertions
References: internet notes; Bertrand Meyer, Object-Oriented Software Construction;
4/25/2019

2. Assertions Statements about input to a routine or state of a class
Have two primary roles
As documentation, they express valid ways of using a routine or class
When implemented, help to isolate runtime errors
4/25/2019

3. Assertions - Example public class SimpleStack {
//Assertion: this method should only be called when the stack is not empty
public int pop() {
if (size() <= 0) {
throw new Stackexception(“pop() called on an empty stack”); }
return data[--top];
//Assertion: this method returns the number of elements on the stack
public int size() {
return top; …
Implements the
assertion
Documents the routine
4/25/2019

4. Assertions
Assertions are an unambiguous way to document a routine; thus, assertions can be checked at runtime
Originally part of Java (then called Oak), but omitted from spec in order to meet deadline
Popularized by Bertrand Meyer(1992) and directly supported by the language Eiffel.
Boolean expressions attached to methods
Test the state of an object at various points during execution, ensuring that certain conditions are satisfied
Automatically inherited and enforced by subclasses even when actual methods are overridden
4/25/2019

5. Assertions Meyer proposed idea of Design by Contract
assertions form a contract between client and service provider
software contracts are specified by pre- and post-conditions and class invariants
Failure to meet the contract terms indicates a bug (fault)
4/25/2019

6. Design by Contract
Violation of a pre-condition means the contract was broken by the client
The “contractor” does not have to fulfill its part of the contract, but may raise an exception to signal the fault
Violation of a post-condition indicates the presence of a bug in the implementation of the routine
4/25/2019

7. Preconditions A condition that must be true before a method executes
Documents the assumptions of the author of the routine
Clients of the method are responsible for ensuring the preconditions are met on entrance to the method; if they are not, then the method behavior is undefined
Must be verifiable by the client using the public interface of the class that contains the method
Client should be able to verify the preconditions from the current state of the object
4/25/2019

8. Preconditions public class BankAccount {
public void deposit (float amount) {
. . . }
//Pre-condition: amount <= current balance
public void withdraw (float amount) {
Precondition is invalid: no way of
verifying the precondition from the
current state of the object
This assumes that there is no method to return current balance.
4/25/2019

9. Postconditions Condition that will be true after a method executes
Author of the method is responsible for ensuring the method’s post-conditions are met
Author of the method must only ensure the post-conditions of a method are true when the pre-conditions of the method have been met
4/25/2019

10. Postconditions
May be expressed in terms of the public interface and/or the private implementation
Post-condition expressed in terms of the public interface is of interest to clients
Post-condition expressed in terms of the private interface is of interest to programmers maintaining the routine
4/25/2019

11. Invariants
An invariant is an expression about an object that must be true when the object is in a stable state.
An object is in a stable state after construction and between public method calls.
Notice that pre- and post-conditions are statements about the behavior of a method, while invariants are statements about the state of an object.
Because invariants are true after construction and between public method calls, the class is responsible for maintaining invariants.
4/25/2019

12. Invariants
Invariants are also expressed in terms of the public interface and/or the private implementation
Invariants are true for the current public methods of a class and any new methods that are added in the future
If a new public routine is allowed to violate an invariant, it may leave the object in an unstable state for another public method.
4/25/2019

13. Example // Invariant: 0 <= size() <= capacity()
public class SimpleStack {
// Pre-condition: The stack is not
// empty
// Post-condition: The last integer
// pushed onto the stack is
// returned. The stack size
// is reduced by one
// element.
public int pop() {
return data[--top]; }
// Pre-condition: <none>
// Post-condition: The number of
// elements in the stack are returned
public int size() {
return top; }
// Post-condition: The capacity of
// the stack is returned
public int capacity() {
return capacity;
...
Example showing a pre-condition, post-condition, and invariant. None of the assertions are checked at runtime.
4/25/2019

14. Pre- and Post-condition strength
The strength of a pre- or post-condition is a measure of its restrictiveness.
A strong pre- or post-condition is more restrictive than a weaker one.
For example, a function that only accepts integers is more restrictive (has a stronger pre-condition) than one that accepts any real number.
The weakest pre- or post-condition is no pre- or post-condition at all.
4/25/2019

15. Example 1: Binary Search
public class Arrays {
. . .
// Pre-condition: the array 'a' is sorted in ascending
//order
// Post-condition: Returns the index of the first element in
// array 'a' equal to 'key' if one exists, otherwise returns
// -1 as an indication that the parameter 'key' is not an
// element of the array.
public static int binarySearch(int[] a, int key); }
Duplicates allowed
4/25/2019

16. Example 2: Binary Search
A stronger pre-condition is one that is more restrictive or narrows the range of acceptable inputs.
The original definition of the binary search method allowed duplicate elements. The following is a stronger pre-condition:
// Pre-condition: the array 'a' is sorted in
// ascending order, and doesn't contain any
// duplicate elements
4/25/2019

17. Example 3 : Binary Search
We could weaken the post-condition of the original definition by allowing the routine to return any negative number if the key is not found:
// Post-condition: Returns the index of the first
// element in array 'a' equal to 'key' if one exists,
// otherwise returns any negative number as an
// indication that the parameter 'key' is not an
// element of the array.
This post-condition is weaker because there is a greater number of outputs that are valid.
4/25/2019

18. Strength of Assertions
Reason for making the pre-condition stronger or the post-condition weaker than what the routine would suggest: Flexibility.
A stronger pre-condition and a weaker post-condition give you the flexibility to change the implementation in the future without changing the interface and possibly breaking clients.
Flexibility comes at the expense of the client. The client now has to work harder to maintain the pre-condition and to be prepared for the post-condition.
4/25/2019

19. Strength of Assertions
When defining the pre- and post-conditions for a routine, need balance.
Consider how much implementation flexibility is needed in the routine and how much additional burden it is for the client for a given amount of flexibility.
Pre-conditions should be strong enough and post-conditions should be weak enough to allow flexibility, but not too strong or too weak that it places an unreasonable burden on the client.
4/25/2019

20. Benefits of Assertion Checking
Assertion checking at runtime is a debugging aid.
The primary purpose of assertion checking at runtime is to identify and isolate runtime errors.
Finding a runtime error in a large software system is difficult. The difficulty grows more than linearly with the size of the system.
For example, if the size of a system doubles it will be more than twice as hard to find a runtime error.
4/25/2019

21. Benefits of Assertion Checking
Part of the problem is that the fault (such as a wrong number on a report) is often a long distance from the defect (such as not reading the last record during the input loop).
distance can be the number of instructions executed at runtime or physical distance between static instructions in the written program.
The greater the distance between a fault and the defect the harder it will be to find a defect that caused a specific fault.
The traditional way of debugging a problem is to start at the fault and work your way back to the defect. Because of conditional branching in code, as you work backwards the number of source branches you need to consider grows exponentially.
4/25/2019

22. Benefits of Assertion Checking
In this conceptual image, there are 10 potential source paths for the visible fault.
Assertion checking helps to identify errors early, closer to the defect that caused them.
Assertion checking may identify errors that would have otherwise gone undetected.
4/25/2019