error management with design contracts

Error Management with Design Contracts

Karlstad UniversityComputer Science


Eivind J. Nordby, Martin Blom, Anna Brunstrom

Computer Science, Karlstad University

Presented at SERP '01 Ronneby

SERP '01 Ronneby 2Karlstad UniversityComputer Science


• 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



• 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



• A system part exposes interfaces– external or internal

External and internal interfaces

System part

Supplier Internalinterface

Externalinterface



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



Design contracts: Basic principles

SupplierClient

Preconditionmet

SupplierClient

Preconditionnot met

Correct

Postconditionmet

!QIQO

Postconditionnot met

?

Correct

GIGOresult undefined



not OK

Weak vs. strong contractsWeak contract

Any input accepted

successfailure

OK

Double responsibility

not qualified qualified

Qualified input

required

Client responsibility

Strong contract



• 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

• reducing the number of faults and saving time

• Strong contracts should be used whenever possible



• 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



• If– for all o1

– there exists an o2

– when P depends on T

– o1 can replace o2

– behavior of P is unchanged

• Then– S is a subtype of T

Liskov's Substitution Principle (LSP)

o1:S

o2:T

:P

defined in terms of

o1 replaces o2



Meyer's Assertion Redeclaration Rule (ARR)

T::f()preT postT

S::f()preS postS

expects assuresassures expects

preT postT

Needed:preT preS

Needed:postS postT



• 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



• 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



• 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



Architecture of the Case Study



• 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



• 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



• 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



• In class Menuloop from first itemcompare current item with parameter

until parameter item foundreturn 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



• 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



• 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



• 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



• 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


Karlstad UniversityComputer Science

Thank you for your attention!Are there any questions?

Eivind J. Nordby, Martin Blom, Anna Brunstrom

Karlstad University, Computer Science,

651 88 Karlstad{Martin.Blom, Eivind.Nordby, Anna.Brunstrom}@kau.se



• 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



• 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– preS preW: qualified input true

– preS : postW postS: postW and success = postS

Liskov (LSP) and Meyer (ARR)



• 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

error management with design contracts

Documents