Behavioral Refinement

1. Behavioral Refinement Principles of Object-Oriented Software Development (Chapter 10)

2. Outline • Types as behavior • Verifying behavioral properties • Specifying the behavior of a program • Verifying behavioral consistency • Specifying behavioral compositions

3. Objectives • Present notion of behavioral subtypes • Apply formal program verification techniques to method calls

4. Liskov Substitution Principle • General principle: • If an object of type S can be substituted in all places where an object of type T is expected, then S is a subtype of T • Object-oriented interpretation: • A class S, which inherits from a superclass T, is considered a subtype of T if S can be substituted in all places where T is expected. • Advantage: new subclasses of T can be written without modifying the methods of T. • Specification inheritance follows the Liskov substitution principle. • How can we formally define this substitution principle?

5. Review: Subtype refinement relationsto verify if  is a subtype of  • Sub-range inclusion • Functions • Records • Variants (contravariance)

6. Functions • If  is a subtype of  and  is a subtype of  then The function  is a subtype of the function  (Function notation:  means function taking parameter of type  and return value of type ) Subtype can have looser parameter type and/or tighter return type • Examples: float  float is not a subtype of float  int int  float is not a subtype of float  int int  int is a not subtype of float  int float  char is a subtype of float  int double  int is a subtype of float  int

7. Contravariance rule for function subtyping • Function subtypes can have looser parameter type and/or tighter return type • Intuitively, for a subtype function to be used in place of its supertype: • It must be able to support at least the same set of values as the input parameters of the supertype, and, • It must return no value more than what its supertype returns • A subtype function is a refinement of its supertype, relaxing the restrictions for its calling function, while strengthening its obligations to the calling function.

8. Records • If type i is a subtype of i, for all i = 1..m, then The record defined by a1:1,…,an:n is a subtype of the record defined by a1:1,…,am:m Note that n could be greater than m  the subtype can introduce additional fields not in the supertype • Example: {age:int, speed:int, fuel:int}  {age:int, speed:int} • Locations that use the supertype are not aware of the new fields so they are never used in those contexts.

9. Types as behavior • Previously, we defined types and subtypes in terms of refinement relations. • This gives a syntactic definition for determining what is and is not a subtype. • A subtype can still behave in a manner that is semantically inconsistent with its supertype. • Need a way to define the semantic behavior of a subtype and verify its consistency to its supertype.

10. Questions • How can we extend our notion of types to include a behavioral description? • How can we verify that a subtype respects the behavioral constraints imposed by the supertype?

11. Questions • How can we extend our notion of types to include a behavioral description? • Contracts (invariants and pre- and post-conditions) • How can we verify that a subtype respects the behavioral constraints imposed by the supertype? • Borrow from axiomatic verification techniques • Hoare logic

12. Outline • Types as behavior • Verifying behavioral properties • Specifying the behavior of a program • Verifying behavioral consistency • Specifying behavioral compositions

13. Verifying behavioral properties • Formal verification – mathematically proving that a program satisfies certain assertions about its behavior. • State model • Program execution as a sequence of state transitions • Program state – the collective value of all variables in a program • State:

14. State transformations • Program state is changed whenever a variable value is changed • Substitution: • Actions correspond to state transformations:

15. Verifying state transformations • Correctness formulae (Hoare logic) • {P}S{Q} • P: pre-condition • Q: post-condition • S: program statement • Verification

16. Correctness calculus • Axioms • Assignment: • Composition: • Conditional: • Iteration: • Consequence rules • Procedural abstraction

17. Outline • Types as behavior • Verifying behavioral properties • Specifying the behavior of a program • Verifying behavioral consistency • Specifying behavioral compositions

18. Specifying the operational behavior of a system • Recall that a program is a sequence of state transformations • Need a way to specify the operational behavior of a program – a transition system • We now define a transition system for a simple programming language (also called operational semantics)

19. Simple OO language syntax • Expressions • Elementary statements • Compound statement

20. Transition system rules for simple OO language • Assignment • Object creation • Method call  represents the local context of the object

21. Compound statements • Composition • Conditional

22. Compound statements • Iteration

23. Transition example • Example program • x = new ctr; x.inc(); v = x.n • Transitions • x = new ctr, 1 , 1[x := ctr1] • n := n + 1, 2 →, 2[.n := .n + 1] • x.inc(), 2 , 2[2(x).n := 2(x).n + 1] • v := x.n, 3 →, 3[v := 3(x).n] • Trace •  ’ with  = 1, ’ = 3 and  = ctr1  inc

24. Outline • Types as behavior • Verifying behavioral properties • Specifying the behavior of a program • Verifying behavioral consistency • Specifying behavioral compositions

25. Verifying correctness ofbehavioral refinements • Behavioral refinement • Abstract specification to concrete implementation • Supertype to subtype correspondence • How can we verify that a concrete implementation is consistent with its abstract specification? • Behavioral types – characterize the behavioral properties of objects in terms of modifications of an abstract state. • Need a representation abstraction function to map concrete data structures and operations to abstract counterparts.

26. Abstraction and representation •  – representation abstraction function • Must prove that ’ corresponds to (’)

27. Proof strategy • To prove that an implementation is consistent with its abstract specification • Assume that pre- and post-conditions have been defined for the abstract type • Find representation invariant I relating concrete and abstract representations • Derive pre- and post-conditions P and Q for the concrete implementation • Prove P  I  (P) and (Q)  I  Q

28. An abstract stack specification type stack T { s: seq T; axioms: {true} push(t:T) {s’ = s  t} {s  } pop() {s = s’  result} }; where:  = empty sequence x1,…,xn  y1,…,ym = x1,…,xn,y1,…,ym

29. A stack realization template<class T> class as { int t; T a[MAX]; public: as() { t = 0;} void push(T e) { require(t<MAX-1); a[t++] = e; } T pop(){ require(t>0); return a[--t];} invariant: 0 <= t && t < MAX; };

30. Verify push() function Abstract: push(e:T) Pre-condition: true Post-condition: s’ = s  e Concrete: push(T e) Pre-condition: t < MAX – 1 Post-condition: t’ = t + 1 ^ a’[t’-1] = e Invariant: I(a,t,s)  t=length(s) ^ t>=0 ^ s=(a,t) where (a,t)= a[0],…,a[t-1]

31. Verify push() function Pre-condition: t < MAX – 1 ^ I(a,t,s)  true Pre-condition of concrete implies that of abstract Post-condition: s’ = s  e ^ I(a’,t’,s’)  t’ = t + 1 ^ a’[t’-1] = e I(a’,t’,s’)  t’=length(s’) ^ t’>=0 ^ s=(a’,t’) (a’,t’)= a’[0],…,a’[t’-1] s’ = s  e  length(s’) = length(s) + 1  t’ = t + 1 s’ = s  e  a[0],…,a[t-1]  e = a’[0],…,a’[t-1],e = a’[0],…,a’[t’-2],e  (a’,t’) a[0],…,a[t’-2],e  a’[t’-1] = e Post-condition of abstract implies that of concrete

32. Verifying subtype correspondence • How can we verify that a type is a behavioral subtype of another type? • Subtype correspondence mapping • Need to define three sets of maps •  - abstraction function – maps  values to  values •  - renaming rule – maps subtype to supertype methods •  - extension map – explains effects of extra methods

33. Behavioral subtyping constraints • If  is a subtype of  • Signature • dom(m)  dom(m) • range(m)  range(m) • Behavior • pre(m)[x := (x)]  pre(m) • post(m)  post(m) [x := (x)] • invariant()  invariant() [x := (x)] • Satisfy correspondence mapping

34. Extension maps • Extension map must be defined such that each method call for object x of type , x.m(a), is mapped to a program m • (x.m(a)) = m • m – only calls methods shared by  and its supertype  or external functions and methods • Diamond rule:

35. Object hierarchies • Extension subtypes • Subtypes add more “state” and methods • One-to-one abstraction map: if more methods but same “state” • Additional methods must have well-defined extension map • Many-to-one abstraction map: if more “state” • Methods that change attributes not present in the supertype are safe • Usual methods, such as equality, must be defined in terms of the supertype’s state • Constrained subtypes • Subtypes are subsets of supertype’s behavior • Methods must satisfy the function subtyping rules

36. Outline • Types as behavior • Verifying behavioral properties • Specifying the behavior of a program • Verifying behavioral consistency • Specifying behavioral compositions

37. The need for global invariants • Verification of object behavior is inherently a local verification activity • Some inconsistencies cannot be detected locally • May be caused by actions that do not involve the object directly

38. Example class A { public: A() { forward = 0; } attach(B* b) { forward = b; b->attach(this); } bool invariant() { return !forward || forward->backward == this; } private: B* forward; }; class B { public: B() { backward = 0; } attach(A* a) { backward = a; } bool invariant() { return !backward || backward->forward == this; } private: A* backward; }; A a1, a2; B b; a1.attach(b); a2.attach(b); // violates invariant a1

39. Formalisms for specifying interactions • Behavioral contracts – behavior of compositions • Formalisms for specification, refinement, conformance, declarations • Characterize the behavioral of compositions of objects • Scripts – cooperation by enrollment • Defines formalisms for roles, initialization/termination policies, critical role set • Specify behavior as a set of roles and the interaction between objects as subscribing/enrolling to a role • Critical role set – minimal set of participants required for successful computation • Multiparty interactions – communication primitive • Communication primitive allows multiple objects to interact simultaneously • Frozen state – invariant during the interaction • Useful in specification of fault tolerant systems • Can assumption of synchrony be weakened in favor of efficiency? • Joint action systems – action-oriented • Assumes there exists some global decision procedure that decides which actions (and interactions) are appropriate • Object behaviors specified by state charts • Implications on inheritance, and refinement by superposition

40. Joint action systems - example actionservice()by client c; server s is when c.requesting && s.free do <body>

41. The Model-View contract contract model-view<V> { subject: model supports [ state: V; value(val:V) [state = val]; notify(); notify() v  views  v.update(); attach()(v:view) v  views; detach()(v:view) v  views; ] views: set<view> where view suppports [ update() [view reflects state]; subject(m:model) subject = m; ] invariant: v  views  [v reflects subject.state] instantiation: v  views  subject.attach(v) & v.subject(subject); subject.notify(); }

42. Summary • We extended the notion of subtyping to include behavioral properties • Reviewed a correctness calculus for verifying behavioral properties • Defined a set of state transformations corresponding to programming language constructs • Defined mappings to reason about correspondence between abstract and concrete types and between subtypes and supertypes • Presented an overview of formalisms for specifying global interactions between objects