Design by Contract using Jose

1
Design by Contractusing Jose

• Ohad Barzilay

2
Design by Contract

• Design by contract is a practical methodology for
  evolving code together with its specification.
• The contract is expressed as a set of class
  invariants and method pre- and postconditions.
• These assertions have important methodological
  implications on the client-supplier and
  inheritance relationships between classes.

3
Design by Contract

• The design by contract methodology is used to
  distribute responsibility between a class and its
  users.
• Contracts describe an agreement between the
  writer of a class and the user of the class by
  means of assertions.
• Clients may only call methods when their
  preconditions are satisfied
• Precondition violations indicate client bugs.

4
Design by Contract

• Conversely, it is the suppliers responsibility
  to make sure that postconditions are satisfied on
  exit from a method.
• Invariants define correct states for objects
  belonging to the class
• it is the suppliers responsibility to maintain
  the invariants.

5
Stack with Assertions (1)

• public class Stack1
• public int count()
• return elements.size()
• /
• _at_pre !empty(), "Not Empty"
• /
• public Object item()
• return elements.firstElement()
• protected Vector elements null

6
Stack with Assertions (2)

• public boolean empty()
• return count() 0
• public boolean full()
• return elements.capacity() count()

7
Stack with Assertions (3)

• /
• _at_pre !full(), "Not Full"
• _at_post !empty(), "Not Empty"
• _at_post item() x, "item() equals x"
• _at_post count() prev(count())1,
• "count() incremented"
• /
• public void put(Object x)
• elements.add(0,x)

8
Stack with Assertions (4)

• /
• _at_pre !empty(), "Not Empty"
• _at_post !full(), "Not Full"
• _at_post count() prev(count())-1,
• "count() decremented"
• /
• public void remove()
• elements.remove(0)

9
Class level Assertions (5)

• /
• _at_invariant count() gt 0,
• "non negative size"
• /
• public class Stack1
• ...

10
Jose keywords

• Precondition
• _at_ precondition
• _at_ pre
• _at_ require
• Postcondition
• _at_ postcondition
• _at_ post
• _at_ ensure
• Invarinat
• _at_ invarinat
• _at_ inv

11
Jose keywords

• Return value
• ret
• Old value
• prev(ltexprgt)
• prev(lttypegtltexprgt)

12
A polymorphic reference
13
For this to work we need

• ? is weaker than a (a ? ?)
• d stronger than ß (d ? ß)
• ? stronger than f (? ? f)
• This can be achieved using (implicit) logical
  operations

14
Subcontracting

• Invariants
• The invariant of a class is the conjunction (AND)
  of its own invariant and the invariants of all
  its ancestors.
• The invariants of all the ancestors of a class
  apply to the class itself.

15
Subcontracting

• Preconditions
• The precondition of an overridden method must be
  weaker than the precondition in the ancestors.
• Precondition are disjuncted (OR) over
  redefinitions.
• The new version must accept all calls that were
  acceptable to the original.

16
Subcontracting

• Postconditions
• The postcondition of an overridden method must be
  stronger than the precondition in the ancestors.
• Postconditions are conjuncted (AND) over
  redefinitions.
• The new version must guarantee at least as much
  as the original.

17
Using abstract precondition

• Try to think about examples with real classes
• When Car extends Vehicle what is the precondition
  for drive() ?
• When BoundedStack extends Stack what is the
  precondition for put() ?
• How can we avoid from making the precondition
  stronger?