On the Relation between Design Contracts and Errors Karlstad University Computer Science On the Relation Between Design Contracts and Errors A Software Development Strategy Eivind J. Nordby, Martin Blom, Anna Brunstrom Computer Science, Karlstad University Presented at ECBS ’02, Lund, Sweden

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 2 How can code complexity be reduced? –There is a paranoia to handle all kinds of errors in all possible situations Referred to as defensive programming –A lot of code complexity is due to error management Q & A Reduce the amount of error management –Distinguish between different kinds of errors –Include error management only where it is needed

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 3 A development strategy and a case study –Based on design contracts –For error management –In software development External and internal errors Weak and strong contracts Liskov (LSP) and Meyer (ARR) The strategy The case study Disposition

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 4 A system part exposes interfaces –External or internal External and Internal Interfaces System part Supplier Internal interface External interface

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 5 Some possible sources of external errors External Interfaces Software Components The System Hardware Components Data Bases Error End Users Other System

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 6 Some possible sources of internal errors Internal Interfaces Programmers Error Program Fault Violation Designers Error Design Fault Violation The system

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 7 External and Internal Errors On a permanent basis, consistent until the software is corrected 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 per use basis, varying from case to case

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 8 Design Contracts: Basic Principles SupplierClient Precondition met SupplierClient Precondition not met Correct Postcondition met ! QIQO Postcondition not met ? Correct GIGO result undefined

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 9 not OK Weak vs. Strong Contracts Weak contract Any input accepted successfailure OK Double responsibility not qualifiedqualified Qualified input required Client responsibility Strong contract

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 10 Example Contracts for Stack top A weak contract Pre:true Post:if not then result = top element else EmptyException thrown A strong contract Pre:not empty Post:result = top element

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 11 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 Reducing the number of faults and saving time Strong contracts should be used whenever possible

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 12 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

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 13 If –for all o 1 –there exists an o 2 –when P depends on T –o 1 can replace o 2 –with behavior of P unchanged Then –S is a subtype of T Liskov's Substitution Principle (LSP) o 1 :S o 2 :T :P defined in terms of o 1 replaces o 2

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 14 Meyer's Assertion Redeclaration Rule (ARR) T::f() pre T post T S::f() pre S post S expectsassures expects pre T post T Needed: pre T  pre S Needed: post S  post T

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 15 Meyer’s ARR is too restricted The postcondition of the contract Pre S :true Post S :if not then result = top element else EmptyException thrown Does not imply the original postcondition Pre T :not empty Post T :result = top element The rule needed is post S  post T in the domain of pre T

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 16 A redefined contract is weaker than the original one if its –Precondition is weaker than or equal to the original precondition –Postcondition is stronger than or equal to the original postcondition in the domain of the original precondition When a contract is weakened –The clients of the module are not affected  Liskov’s substitution principle is satisfied Liskov (LSP) and Generalized Meyer (ARR)

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 17 Start with strong contracts –Reduce internal errors Change to weak contracts when error free –Accommodate external errors Add handling in the client –Of the added postconditions in the weakened contract The Strategy

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 18 Architecture of the Case Study

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 19 System access from wap or web browser End users maintain dynamic, personalized menus –Of most common telecom services or internet links Editing options –Move, delete, edit menu options –Create, delete, link menus Operation options –Normal hyperlinks in the browser Functionality of the Case Study

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 20 Whole system –10 persons, 6 months Business logic module –2 persons –6,000 lines of Java code –17 classes, 70 operations Including internal support operations Size of the Case Study

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 21 Strong contracts were applied in the Business Logic interface Example from class Menu –MenuItem getItem(itemId) –Called from a user menu display –Precondition: the item exists in the menu –Postcondition: the details about the menu item are returned Contracts of the Case Study

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 22 In class Menu loop from first item compare current item with parameter until parameter item found return the details of the current item Exploiting the strong contracts –Precondition  loop runs at least once –Precondition  item found before end of list Implementation of getItem(itemId) Contract violation detection –Java’s built-in runtime control –“Index out of bounds”, “Null pointer” exceptions

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 23 Implementation of business logic module –Focus on design and correctness No development time spent on handling illegal calls –Quick and virtually error free implementation Programmers not used to strong contracts –Initial contract violations and crashes –Subsequent disciplined use and –Few faults in the business logic communication Stable failure profile –Faults were detected early, no late surprises Experiences From Using Strong Contracts

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 24 Some operations were subject to illegal calls –An URL with function parameters could be edited manually on the web browser The contracts of 16 out of 70 operations were weakened –MenuItem getItem(itemId) –Precondition: true –Postcondition: if the item exists in the menu, then the details about the menu item has been returned, else an exception has been thrown Weakening the Contracts

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 25 Modifications in the business logic module –Were easy –Caused no new faults Adaptation in the client software –To take advantage of the weaker contracts for robustness –Was easy –Caused few new faults Experiences From Weakening the Contracts

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 26 Starting out with strong contracts –Allows initial focus on correctness –Improves fault characteristics –Allows later weakening without affecting client code Passing to weak contracts –On selected operations exposed to external errors –Adds system robustness as a separate concern –Is easy and cost effective Conclusions

On the Relation between Design Contracts and Errors Karlstad University Computer Science Thank You for Your Attention! Are There Any Questions? Eivind J. Nordby, Martin Blom, Anna Brunstrom Karlstad University, Computer Science, Karlstad {Martin.Blom, Eivind.Nordby,

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 28 Failure = the product behaving incorrectly Fault = defect in the product –May result in a failure during execution Error = wrong human behavior –Error from a developer Should be avoided May produce faults in the software –Error from the end user Must be tolerated and taken care of The software should protect the system integrity Failures, Faults and Errors

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 29 Liskov only requires this to be true in the cases covered by the original routine –That is when the original precondition is satisfied Strong vs. Weak contracts –pre s  pre W : qualified input  true –pre s : post W  post s : post W and success = post s Liskov (LSP) and Meyer (ARR)

Karlstad University Computer Science On the Relation between Design Contracts and Errors ECBS '02 Lund , page 30 Strong contracts are suited for detecting faults resulting from internal errors –Promote fault free software A strong contract may be LSP substituted by a weaker one –Will not affect client software Weak contracts are suited for tolerating external errors –Promote robust external interfaces Summary of the Principles