On the Relation between Design Contracts and Errors Karlstad University Computer Science On the Relation Between Design Contracts and Errors A Software

On the Relation betweenDesign Contracts and Errors

Karlstad UniversityComputer Science

On the Relation BetweenDesign Contracts and Errors

A Software Development Strategy

Eivind J. Nordby, Martin Blom, Anna Brunstrom

Computer Science, Karlstad University

Presented at ECBS ’02, Lund, Sweden

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, page 4



• A system part exposes interfaces– External or internal

External and Internal Interfaces

System part

Supplier Internalinterface

Externalinterface

ECBS '02 Lund 2002-04-08, page 5



• Some possible sources of external errors

External Interfaces

SoftwareComponents

The System

HardwareComponents

Data Bases

Error

Error

Error

End Users

OtherSystem

ECBS '02 Lund 2002-04-08, page 6



• Some possible sources of internal errors

Internal Interfaces

Programmers

Error Program Fault

Violation

Designers

ErrorDesign Fault

Violation

The system

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, page 8



Design Contracts: Basic Principles

SupplierClient

Preconditionmet

SupplierClient

Preconditionnot met

Correct

Postconditionmet

!QIQO

Postconditionnot met

?

Correct

GIGOresult undefined

ECBS '02 Lund 2002-04-08, page 9



not OK

Weak vs. Strong ContractsWeak contract

Any input accepted

successfailure

OK

Double responsibility

not qualified qualified

Qualified input

required

Client responsibility

Strong contract

ECBS '02 Lund 2002-04-08, page 10



Example Contracts for Stack top

• A weak contractPre: true

Post: if not empty@prethen result = top elementelse EmptyException thrown

• A strong contractPre: not empty

Post: result = top element

ECBS '02 Lund 2002-04-08, 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

• Reducing the number of faults and saving time

• Strong contracts should be used whenever possible

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, page 13



• If– for all o1

– there exists an o2

– when P depends on T

– o1 can replace o2

– with behavior of P 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

ECBS '02 Lund 2002-04-08, page 14



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

ECBS '02 Lund 2002-04-08, page 15



Meyer’s ARR is too restricted

• The postcondition of the contractPreS: true

PostS:if not empty@prethen result = top elementelse EmptyException thrown

• Does not imply the original postconditionPreT: not empty

PostT:result = top element

• The rule needed ispostS postT

in the domain of preT

ECBS '02 Lund 2002-04-08, 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 postconditionin 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)

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, page 18



Architecture of the Case Study

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, page 22



• 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

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, 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



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

ECBS '02 Lund 2002-04-08, 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

ECBS '02 Lund 2002-04-08, 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– pres preW: qualified input true

– pres : postW posts: postW and success = posts

Liskov (LSP) and Meyer (ARR)

ECBS '02 Lund 2002-04-08, 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

Documents

On the Relation between Design Contracts and Errors Karlstad University Computer Science On the Relation Between Design Contracts and Errors A Software