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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and 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
Correspondence Contracts Errors
ECBS '02 Lund 2002-04-08, page 13
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
Architecture of the Case Study
ECBS '02 Lund 2002-04-08, page 19
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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 betweenDesign Contracts and Errors
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
ECBS '02 Lund 2002-04-08, page 28
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts 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)
ECBS '02 Lund 2002-04-08, page 30
Karlstad UniversityComputer Science
On the Relation betweenDesign Contracts and Errors
• 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
Top Related