Title: Behavioral Contracts and Behavioral Subtyping
1Behavioral Contracts and Behavioral Subtyping
R. B. Findler, M. Latendresse, M.
Felleisen Proc. of ACM conference, Found. Of SE,
2001
2Contents
- Introduction
- Behavioral subtyping condition
- Problems with prior work
- Properly monitoring contracts
- Related work
- Conclusion future works
3Introduction (1/2)
- Reusable S/W components (McIlroy, 1969)
- Produced with well specified interfaces
- Adapted with wrapper
- Component must not break its promises
-
- Components contracts (Beugnard et al)
- Synthetic contracts
- ? Type
- Behavioral contracts
- ? pre, post condition and invariants
- Sequencing contracts
- ? threading, timing constraints
- Quality of service contracts
- ? time, space guarantees
4Introduction (2/2)
- Motivation
- The flaws of existing tools (Extended Static
Checking group) - verification is not possible if contracts are
not violated - neither complete nor sound
- computationally expensive
- Contracts in Procedural, successful but,
- in OOP, entirely missing blame for
violations - Contribution
- Demonstrates how to integrate contracts properly
- according to the notion of behavioral subtyping
- into a contract monitoring tool for java
- Based on that of America, Liskov, Wing, Meyer
5Behavioral Subtyping Condition (1/4)
- Basic Idea
- Covariance / Contravariance
- Since B is an A, if code 1 is ok then code 2
must be ok
interface A R foo(in P) interface B A
S foo(in Q) x A.foo(y) -------code 1
x B.foo(y) -------code 2
Contravariance S must be sub of R Covariance
P must be sub of Q
6Behavioral Subtyping Condition (2/4)
- Basic Idea
- Covariance / Contravariance
- Violation examples
Pfloat, Qint (violation of co..)
A.foo(2.1) --- ok B.foo(2.1) --- wrong
Sfloat, Rint (violation of contra..) B b
A a b 2.1 b.foo(y) -- ok 2.1 a.foo(y)
-- wrong
interface A R foo(in P) interface B A
S foo(in Q) x A.foo(y) ------code 1
x B.foo(y) ------code 2
7Behavioral Subtyping Condition (3/4)
8Behavioral Subtyping Condition (4/4)
- The condition (multiple inheritance)
9Problems with prior work (1/3)
- Eiffel style contracts for Java
- iContract, JMSAssert, jContractor, HandShake
- Evaluating pre, post conditions
The basic mechanism If precondition fail ?
blame the calling code If postcondition fail ?
blame the method itself
10Problem with prior work (2/3)
- Eiffel style contracts for Java
- Contract checking for Inheritance
11Problem with prior work (3/3)
- Eiffel style contracts for Java
- Erroneous contract example
- (agt0) (agt10)
Delayed, Incorrect Explanation for Contract
Violation blaming wrong part, making
the problem difficult to understand
12Properly Monitoring Contracts (1/6)
Blame must be assigned to Cathy Cathy does
not violate the pre/post condition, but the
two preconditions have wrong relationship
13Properly Monitoring Contracts (2/6)
Contract Compiler
Pre and Post conditions
Wrapper methods
Wrapper check the contracts and call the
corresponding original method
14Properly Monitoring Contracts (3/6)
15Properly Monitoring Contracts (4/6)
Blames caller Blames class
16Properly Monitoring Contracts (5/6)
- An interface and
- its implementation
- Hierarchy
Four possibilities for precondition C and I 1.
both are true 2. both are false ----------
caller blamed 3. in C false, in I true--- C is
blamed 4. in C true, in I false--- no violation
signals - if instance of I --- caller is
blamed - if instance of C --- no error The
case of postcondition is similar
17Hierarchy checking methods are generated for each
interface and class method
18Related Work
- Karaorman, Holzle, Bruno
- A reflective Java library to support design by
contract - does not check the hierarchy property
-
- Edwards et al
- create a parallel object to each original object
- no guarantee that if created object satisfy then
original too - Dhara, Leavens
- disjunction of preconditions, conjunction of
postconditions - the same problems mentioned previous slide
- (agt0) (agt10)
19Conclusion and Futurework
- Existing contract tools are incorrect for certain
violations - This paper suggests implementation idea for
contract - handles three kind of errors (pre/postcondition
and hierarchy) -
- Future work
- Extends the translator to explicitly specify that
a derived class is not behavioral subtype -