Post on 10-Jan-2016
description
transcript
Error Management with Design Contracts
Karlstad UniversityComputer Science
Error Management with Design Contracts
Eivind J. Nordby, Martin Blom, Anna Brunstrom
Computer Science, Karlstad University
Presented at SERP '01 Ronneby
SERP '01 Ronneby 2Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 3Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 4Karlstad UniversityComputer Science
Error Management with Design Contracts
• A system part exposes interfaces– external or internal
External and internal interfaces
System part
Supplier Internalinterface
Externalinterface
SERP '01 Ronneby 5Karlstad UniversityComputer Science
Error Management with Design Contracts
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
SERP '01 Ronneby 6Karlstad UniversityComputer Science
Error Management with Design Contracts
Design contracts: Basic principles
SupplierClient
Preconditionmet
SupplierClient
Preconditionnot met
Correct
Postconditionmet
!QIQO
Postconditionnot met
?
Correct
GIGOresult undefined
SERP '01 Ronneby 7Karlstad UniversityComputer Science
Error Management with Design Contracts
not OK
Weak vs. strong contractsWeak contract
Any input accepted
successfailure
OK
Double responsibility
not qualified qualified
Qualified input
required
Client responsibility
Strong contract
SERP '01 Ronneby 8Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 9Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 10Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 11Karlstad UniversityComputer Science
Error Management with Design Contracts
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
SERP '01 Ronneby 12Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 13Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 14Karlstad UniversityComputer Science
Error Management with Design 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
SERP '01 Ronneby 15Karlstad UniversityComputer Science
Error Management with Design Contracts
Architecture of the Case Study
SERP '01 Ronneby 16Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 17Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 18Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 19Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 20Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 21Karlstad UniversityComputer Science
Error Management with Design 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
SERP '01 Ronneby 22Karlstad UniversityComputer Science
Error Management with Design 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
SERP '01 Ronneby 23Karlstad UniversityComputer Science
Error Management with Design 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
Error Management with Design Contracts
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
SERP '01 Ronneby 25Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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
SERP '01 Ronneby 26Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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)
SERP '01 Ronneby 27Karlstad UniversityComputer Science
Error Management with Design Contracts
• 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