Error Management with Design Contracts Karlstad University Computer Science Error Management with Design Contracts Eivind J. Nordby, Martin Blom, Anna Brunstrom Computer Science, Karlstad University Presented at SERP '01 Ronneby

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 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 Distinguish between different kinds of errors Reduce error management where it is not needed

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 3 We present 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 Error Management with Design Contracts SERP '01 Ronneby 4 A system part exposes interfaces –external or internal External and internal interfaces System part Supplier Internal interface External interface

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 5 External and internal errors on a per use basis, varying from case to case on a permanent basis, consistent until the software is corrected External errors –commited by end users or external systems – –cause violation of external interfaces Internal errors –committed by developers –result in faults in the software –cause violation of internal interfaces

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 6 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 Error Management with Design Contracts SERP '01 Ronneby 7 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 Error Management with Design Contracts SERP '01 Ronneby 8 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 Error Management with Design Contracts SERP '01 Ronneby 9 External errors –wrong input should be tolerated –the user should be informed –handled by weak contracts Internal errors –faults resulting from internal errors should be detected –the fault should be corrected before proceeding –handled by strong contracts Correspondence contracts  errors

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 10 If –for all o 1 –there exists an o 2 –when P depends on T –o 1 can replace o 2 –behavior of P is 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 Error Management with Design Contracts SERP '01 Ronneby 11 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 Error Management with Design Contracts SERP '01 Ronneby 12 When a routine is redefined in a subclass: if the redefined –precondition is weaker than or equal to –postcondition is stronger than or equal to the original one then –the clients of the class are not affected  the subclass is a Liskov subtype Liskov (LSP) and Meyer (ARR) combined

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 13 Definition –a redefined contract is weaker than the original one if it satisfied the Assertion Redeclaration Rule Consequence –weakening a contract defines a Liskov subtype of the module Generalization –not only for classes –for modules in general Weak and strong contracts

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 14 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 Error Management with Design Contracts SERP '01 Ronneby 15 Architecture of the Case Study

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 16 System access from wap or web browser End users maintain dynamic, personalized menus –Most common telecom services or Internet links Editing options –Move, delete, edit menu options –Create, delete, link menus Operation options –Normal hyperlink operation Functionality of the Case Study

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 17 Whole system –10 persons, 6 months –16,000 lines of code, including comments and blank lines Business logic module –2 persons –6,000 lines of code –17 classes, 70 operations including internal support operations Size of the Case Study

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 18 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 Error Management with Design Contracts SERP '01 Ronneby 19 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 Error Management with Design Contracts SERP '01 Ronneby 20 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 –Fault were detected early, no late surprises Experiences from using Strong Contracts

Karlstad University Computer Science Error Management with Design Contracts SERP '01 Ronneby 21 Some operations were subject to illegal calls –An URL with function parameters could be edited manually on the web browser The contracts of 16 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 Error Management with Design Contracts SERP '01 Ronneby 22 Modification in the Business Logic –was 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 Error Management with Design Contracts SERP '01 Ronneby 23 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

Error Management with Design Contracts 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 Error Management with Design Contracts SERP '01 Ronneby 25 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 Error Management with Design Contracts SERP '01 Ronneby 26 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 Error Management with Design Contracts SERP '01 Ronneby 27 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