1. Design Contracts and Errors A Software Development Strategy
Research by Eivind J. Nordby from Computer Science
Karlstad University

2. Contracts - Preconditions and Postconditions
In module design, the obligations and benefits of the contracts are regulated through preconditions and postconditions
Client
Interface
Supplier
Required
Offered
Obligation:
Assure precondition
Method
Precondition
Benefit:
Assume precondition
Benefit:
Assume postcondition
Obligation:
Assure postcondition
Postcondition
11/1/2019
Contract principles, page

3. Design Contracts: Basic Principles
Client
Supplier
Supplier
Client
Precondition
not met
Precondition
met
Correct
Postcondition
met !
QIQO
Postcondition
not met ?
Correct
GIGO
result undefined
11/1/2019
Contract principles, page

4. Some Details about the Class Stack
Assume that these functions are defined for a stack:
top() returns a reference to the topmost element on the stack
the element itself is unaffected by the operation
the element remains on the stack
size() returns the number of elements currently on the stack
Assume these implementation details about a stack:
the stack is implemented using an array called elements
topIndex is the index of the topmost element on the stack
11/1/2019
Contract principles, page

5. Different Styles of Calling a Function
Obtaining the top element of a stack
defensive programming, with no explicit contract
Implicit precondition for top: true
Client code
...pushes and pops...
try {
anElement = myStack.top(); }
catch(stackEmptyException sEE) {
printErrorMessage();
11/1/2019
Contract principles, page

6. Different Styles of Calling a Function
Obtaining the top element of a stack
offensive programming, with an explicit, strong contract
Precondition for top: !isEmpty()
Client code
...pushes and pops...
if(!myStack.isEmpty())
anElement = myStack.top()
else
printErrorMessage();
11/1/2019
Contract principles, page

7. Different Styles of Implementing a Function
Stack implementation in defensive programming
Object top() throws IndexOutOfBoundsException {
if (size() > 0)
return elements[topIndex];
else
throw(new IndexOutOfBoundsException()); }
Stack implementation in offensive programming
Based on an explicit, strong contract
Object top()
11/1/2019
Contract principles, page

8. Weak vs. Strong Contracts
Weak contract
not qualified
qualified
Qualified input required
Client responsibility
Strong contract
Any input accepted
not OK OK
failure
success
Double responsibility
11/1/2019
Contract principles, page

9. Contract principles, page
Comparison
Weak contracts
Are needed where a correct call cannot be assured
Providing an open-ended exit
Strong contracts
Simplifies the solution by reducing complexity
Simplifies error detection by allocating responsibilities
Strong contracts should be used whenever possible
11/1/2019
Contract principles, page

10. What are Contracts Good for?
???
A moment of reflection:
What are Contracts Good for? ?
???
generate more
paperwork?
11/1/2019
Contract principles, page

11. Benefits from applying contracts
1 Design support tool
Contributes to a better design
2 Documentation tool
The contracts for a module describe the module
3 Maintenance tool
The contracts for a module identify how changes affect clients
Error detection tool – avoid exceptions
When a condition is executable, it may be verified by the software itself
Error detection can avoid error handling
11/1/2019
Contract principles, page

12. Example : Contract Implementation
Assume that the list is implemented using an array of Objects
Declared as Object[] stackArray = new Object[MaxSize]
Create & Implement a contract for the getElement() operation for the stack
getElement(int position) should return the element at the given position of a list
Positions are counted from 1
Precondition:
Informal: position is ok.
Executable: (0 < position) && (position <= size())
Postcondition:
The the object at the given position is returned
11/1/2019
Contract principles, page

13. Contract principles, page
A Solution
Object getElement(int position) {
return stackArray[position - 1]; }
No checking of the boundaries is needed
That is taken care of by the precondition
The precondition states that position should be
0 < position && position <= listSize()
This implies that indexing goes from 1 as seen from the outside
Inside the method, the indexing goes from zero
The index has to be adjusted when passing from the external to the internal view
11/1/2019
Contract principles, page

14. Alternative implementation of getElement
List
Assume that the list is implemented using a linked list
The List class has a reference first to the first node in the list
Each node has a reference next to the next node in the list
Each node has a reference data to the data value of that node
Repeat previous example for this data structure
The data object at the selected position should be returned
first
data
Node
Object
next
Node
Object
next
11/1/2019
Contract principles, page

15. Suggested Solution for Linked List
public Object getElement(int position) {
Node temp = first;
int i = 1; // Index of temp
while(i < position)
temp = temp.getNext();
i++;
// termination guaranteed by pre
// i == position, temp -> sought element
return temp.getData();
} // getElement
11/1/2019
Contract principles, page

16. What Happens if the Precondition is not Satisfied?
Appendix B
What Happens if the Precondition is not Satisfied?

17. Different Strategies for Handling Violated Preconditions
Since the client has not kept its part of the contract, the supplier has no obligations whatsoever
The supplier can do whatever it wants
Two possible strategies
Do nothing special
try to perform the task in the normal way
hope that the system will die :-)
Trap the violation and make the system die
exit (or throw an undocumented runtime exception)
possibly dump an error code to a log file
11/1/2019
Contract principles, page

18. An Example of Handling Precondition Violations
getElement method in a list
The precondition states that position should be ok
If the position is not ok, the system will still survive as long as position is within the array boundaries.
One approach is to trap the violation and make the system die to notify the developer to correct the error in the client code
// Pre: positionOK(position)
// Post: the selected element is returned from the list
Object getElement(int position) {
if(Compilation.ASSERT_IS_ON)
Assert.isTrue(positionOK(position));
return elements[position]; }
11/1/2019
Contract principles, page

19. Do Not Try to Handle the Error
Do not handle errors and allow the system to go on
The client should not be aware of any exceptions that might be thrown. It could be tempted to catch it and thereby allow the error to live on
Documenting an error exception would implement a different contract than the one specified for the method
The client is not aware of the test
From the client’s point of view, there is no “security net”
The test can be removed without affecting the contract since it is not part of the contract
There is no recovery from the error
The only measure taken if the precondition is violated is to exit the system
It is an error trap, not an error handling
11/1/2019
Contract principles, page

20. Rules for Precondition Violation Traps
The trap should be completely transparent to the client
No return value to test or exception to catch
A trap causes the program to die when it detects an error
The user should develop the client code without resorting to the traps
The traps may be disabled or enabled without his knowledge
The supplier code should produce the same result with a trap as without it
The program may be run with traps enabled or disabled
The trap should not affect the behavior of the system in any way
In particular, the trap should not change any variables
11/1/2019
Contract principles, page

21. External and internal errors and their contracts
Appendix C
External and internal errors and their contracts

22. External and Internal Interfaces
A system part exposes interfaces
External or internal
System part
External interface
Internal interface
Supplier
11/1/2019
Contract principles, page

23. Contract principles, page
External Interfaces
Some possible sources of external errors
Software
Components
Hardware
Components
Other
System
Error
Data Bases
The System
End Users
Error
Error
11/1/2019
Contract principles, page

24. Contract principles, page
Internal Interfaces
Some possible sources of internal errors
The system
Designers
Programmers
Error
Design Fault
Program Fault
Error
Violation
Violation
11/1/2019
Contract principles, page

25. External and Internal Errors
On a permanent basis, consistent until the software is corrected
On a per use basis, varying from case to case
External errors
Committed by end users or external systems
Databases, external components, hardware
Cause violation of external interfaces
Internal errors
Committed by developers
Result in faults in the software
Cause violation of internal interfaces
11/1/2019
Contract principles, page

26. Correspondence Contracts  Errors
External errors
Correct input cannot be assured
wrong input should be handled and the user informed
Best managed by weak contracts
Internal errors
Correct input can be assures
System faults should be detected
And corrected by the responsible author
Best managed by strong contracts
11/1/2019
Contract principles, page