1 / 42

Behavioral Refinement

Behavioral Refinement. Principles of Object-Oriented Software Development (Chapter 10). Outline. Types as behavior Verifying behavioral properties Specifying the behavior of a program Verifying behavioral consistency Specifying behavioral compositions. Objectives.

nelly
Download Presentation

Behavioral Refinement

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related