1. Karlstad University Computer Science Design Contracts and Error Management Design Contracts and Errors A Software Development Strategy (anpassad för PUMA) Eivind J. Nordby Software Engineering Research Group Computer Science Karlstad University

2. Computer Science Design Contracts and Error Management Contract principles, page 2 Contracts - Clients and Suppliers A contract is an agreement between two parties A contract has a client and a supplier

3. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 3 The Interpretation of a Contract A contract consists of a precondition and a postcondition When a method is invoked, the precondition should be true –This is the responsibility of the client –The supplier can assume that it is true When a method exits, the postcondition should be true –This is the responsibility of the supplier Only necessary if the precondition was true –The client can assume that it is true Only guaranteed if the precondition was true

4. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 4 Contracts - Allocation of Responsibilities A contract specifies obligations and benefits Client Supplier BenefitObligation PayGet goods Supply goodsGet money The supplier only needs to fulfill his obligations if the client fulfills his

5. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 5 Contracts - Preconditions and Postconditions In module design, the obligations and benefits of the contracts are regulated through preconditions and postconditions Note –There is always a contract, even when not explicitly expressed Method Precondition Postcondition SupplierClient Obligation: Assure precondition Benefit: Assume postcondition Benefit: Assume precondition Obligation: Assure postcondition Interface Offered Required

6. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 6 Design Contracts: Basic Principles SupplierClient Precondition met SupplierClient Precondition not met Correct Postcondition met ! QIQO Postcondition not met ? Correct GIGO result undefined

7. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 7 Applying a contract When invoking (calling) a method –Satisfy the precondition for the method called. –If the precondition was satisfied, then trust the postcondition. When implementing a method –Do not test conditions that are already satisfied according to the precondition –Make sure that the postcondition is satisfied before the method terminates

8. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 8 not OK Weak vs. Strong Contracts Weak contract Any input accepted successfailure OK Double responsibility not qualifiedqualified Qualified input required Client responsibility Strong contract

9. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 9 Reducing the number of faults and saving time Strong contracts should be used whenever possible 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 Comparison

10. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 10 Benefits from Applying Contracts 1Design support tool –Help during design to find and express the module specifications –Useful to design quality into the product An alternative to debugging the errors out if it –This is the most important benefit from contracts 2Documentation tool –The contracts for a module specify the requirements on the module –Useful to both the module user and its programmer

11. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 11 Benefits from Applying Contracts 3Maintenance tool –A modification of an implementation within the definition of the current contract does not affect clients –A modification of a contract to one that is weaker does not affect clients –A modification of a contract to one that is stronger does affect clients. It defines a new function 4Error detection tool –When a condition is executable, it may be verified by the software itself Error detection is not error handling –Requires language support

12. Karlstad University Computer Science Design Contracts and Error Management External and internal errors and their contracts

13. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 13 A system part exposes interfaces –External or internal External and Internal Interfaces System part Supplier Internal interface External interface

14. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 14 Some possible sources of external errors External Interfaces Software Components The System Hardware Components Data Bases Error End Users Other System

15. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 15 Some possible sources of internal errors Internal Interfaces Programmers Error Program Fault Violation Designers Error Design Fault Violation The system

16. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 16 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 External and Internal Errors On a permanent basis, consistent until the software is corrected On a per use basis, varying from case to case

17. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 17 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 Correspondence Contracts  Errors

18. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 18 How do the Users of a Module Benefit from Contracts? The contracts makes it easier to understand the module –The intentions of the module are described –Ambiguities are removed The distribution of responsibility is clear –The user knows what is taken care of by the module and what is not The users of a module knows what the module has done since this is expressed in the postcondition –No need to read the code in order to understand what the module has done. –The code can more easily be distributed in an interface part and an implementation part since the users do not need to read the code.

19. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 19 How do the Programmers of a Module Benefit from Contracts? A contract specifies the precondition for the call –Defines that the the client is responsible for the entrance conditions –The supplier knows that this is not his responsibility The supplier does not need to check a precondition –It should always be true –It would be a violation to the contract not to trust it The supplier programmer can focus on solving the task defined for the function –He does not need to spend time and energy to catch “illegal” cases –His code gets simpler and contains less errors

20. Karlstad University Computer Science Design Contracts and Error Management Contract principles, page 20 Paradox: Guaranteeing More by Checking Less How can quality increase by less testing? –Simplicity is the allied number one for quality Placing conditions on the client allows for a simple implementation –Hence allows for quality Not trusting the client requires testing the conditions –Both client and supplier need to test –Hence complicating the implementation –Hence jeopardizing the quality The key issue is who’s “quality” we are looking for –Microscopic view, just my own module: Lots of tests in the supplier code –Macroscopic view, the system as a whole: Place the responsibility where it belongs