Design Contracts and Errors A Software Development Strategy (anpassad för PUMA)

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

2. Contracts - Clients and Suppliers • A contract is an agreement between two parties • A contract has a client and a supplier Contract principles, page 2

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 Contract principles, page 3

4. A contract specifies obligations and benefits The supplier only needs to fulfill his obligations if the client fulfills his Contracts - Allocation of Responsibilities Obligation Benefit Client Pay Get goods Supplier Supply goods Get money Contract principles, page 4

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 Client Interface Supplier Required Offered Obligation: • Assure precondition Method Precondition Benefit: • Assume precondition Benefit: • Assume postcondition Obligation: • Assure postcondition Postcondition Contract principles, page 5

6. Client Supplier Precondition not met Correct Correct Postcondition not met Postcondition met ! ? QIQO GIGO result undefined Design Contracts: Basic Principles Client Supplier Precondition met Contract principles, page 6

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 Contract principles, page 7

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

9. Comparison • Reducing the number of faults and saving time • 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 Contract principles, page 9

10. Benefits from Applying Contracts 1 Design 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 2 Documentation tool • The contracts for a module specify the requirements on the module • Useful to both the module user and its programmer Contract principles, page 10

11. Benefits from Applying Contracts 3 Maintenance 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 4 Error detection tool • When a condition is executable, it may be verified by the software itself • Error detection is not error handling • Requires language support Contract principles, page 11

12. External and internal errors and their contracts

13. External and Internal Interfaces • A system part exposes interfaces • External or internal System part Externalinterface Internalinterface Supplier Contract principles, page 13

14. Other System Hardware Data Bases Components The System End Users Software Components External Interfaces • Some possible sources of external errors Error Error Error Contract principles, page 14

15. Programmers Designers Internal Interfaces • Some possible sources of internal errors The system Error Error Program Fault Design Fault Violation Violation Contract principles, page 15

16. External and Internal Errors • 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 • On a permanent basis, consistent until the software is corrected • On a per use basis, varying from case to case Contract principles, page 16

17. 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 Contract principles, page 17

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. Contract principles, page 18

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 Contract principles, page 19

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 Contract principles, page 20