Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 1 Behavioral Refinement Principles of Object-Oriented Software Development (Chapter 10)

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 2 Outline l Types as behavior l Verifying behavioral properties l Specifying the behavior of a program l Verifying behavioral consistency l Specifying behavioral compositions

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 3 Objectives l Present notion of behavioral subtypes l Apply formal program verification techniques to method calls

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 4 Liskov Substitution Principle l 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 l 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. l How can we formally define this substitution principle?

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 5 Review: Subtype refinement relations to verify if  is a subtype of  l Sub-range inclusion l Functions l Records l Variants (contravariance)

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 6 Functions l 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 l 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

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 7 Contravariance rule for function subtyping l Function subtypes can have looser parameter type and/or tighter return type l 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 l A subtype function is a refinement of its supertype, relaxing the restrictions for its calling function, while strengthening its obligations to the calling function.

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

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 9 Types as behavior l Previously, we defined types and subtypes in terms of refinement relations. l This gives a syntactic definition for determining what is and is not a subtype. l 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.

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 10 Questions l How can we extend our notion of types to include a behavioral description? l How can we verify that a subtype respects the behavioral constraints imposed by the supertype?

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 11 Questions l How can we extend our notion of types to include a behavioral description? Contracts (invariants and pre- and post-conditions) l How can we verify that a subtype respects the behavioral constraints imposed by the supertype? Borrow from axiomatic verification techniques Hoare logic

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 12 Outline l Types as behavior l Verifying behavioral properties l Specifying the behavior of a program l Verifying behavioral consistency l Specifying behavioral compositions

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 13 l Formal verification – mathematically proving that a program satisfies certain assertions about its behavior. l State model Program execution as a sequence of state transitions Program state – the collective value of all variables in a program State: Verifying behavioral properties

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 14 State transformations l Program state is changed whenever a variable value is changed l Substitution: l Actions correspond to state transformations:

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 15 Verifying state transformations l Correctness formulae (Hoare logic) {P}S{Q} P: pre-condition Q: post-condition S: program statement l Verification

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 16 l Axioms Assignment: Composition: Conditional: Iteration: l Consequence rules l Procedural abstraction Correctness calculus

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 17 Outline l Types as behavior l Verifying behavioral properties l Specifying the behavior of a program l Verifying behavioral consistency l Specifying behavioral compositions

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 18 Specifying the operational behavior of a system l Recall that a program is a sequence of state transformations l Need a way to specify the operational behavior of a program – a transition system l We now define a transition system for a simple programming language (also called operational semantics)

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 19 Simple OO language syntax l Expressions l Elementary statements l Compound statement

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 20 Transition system rules for simple OO language l Assignment l Object creation l Method call  represents the local context of the object

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 21 Compound statements l Composition l Conditional

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 22 Compound statements l Iteration

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 23 Transition example l Example program x = new ctr; x.inc(); v = x.n l Transitions  x = new ctr,  1  ,  1 [x := ctr 1 ]   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]  l Trace   ’ with  =  1,  ’ =  3 and = ctr1  inc 

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 24 Outline l Types as behavior l Verifying behavioral properties l Specifying the behavior of a program l Verifying behavioral consistency l Specifying behavioral compositions

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 25 Verifying correctness of behavioral refinements l Behavioral refinement Abstract specification to concrete implementation Supertype to subtype correspondence l How can we verify that a concrete implementation is consistent with its abstract specification? l Behavioral types – characterize the behavioral properties of objects in terms of modifications of an abstract state. l Need a representation abstraction function to map concrete data structures and operations to abstract counterparts.

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 26 Abstraction and representation l  – representation abstraction function l Must prove that  ’ corresponds to  (  ’)

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 27 Proof strategy l 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

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 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 

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 29 A stack realization template 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; };

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 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] 

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 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

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 32 Verifying subtype correspondence l How can we verify that a type is a behavioral subtype of another type? l 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

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 33 Behavioral subtyping constraints l If  is a subtype of  l Signature dom(m  )  dom(m  ) range(m  )  range(m  ) l Behavior pre(m  )[x  :=  (x  )]  pre(m  ) post(m  )  post(m  ) [x  :=  (x  )] invariant(  )  invariant(  ) [x  :=  (x  )] l Satisfy correspondence mapping

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

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 35 Object hierarchies l 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 l Constrained subtypes Subtypes are subsets of supertype’s behavior Methods must satisfy the function subtyping rules

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 36 Outline l Types as behavior l Verifying behavioral properties l Specifying the behavior of a program l Verifying behavioral consistency l Specifying behavioral compositions

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 37 The need for global invariants l Verification of object behavior is inherently a local verification activity l Some inconsistencies cannot be detected locally l May be caused by actions that do not involve the object directly

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 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

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 39 Formalisms for specifying interactions l Behavioral contracts – behavior of compositions Formalisms for specification, refinement, conformance, declarations Characterize the behavioral of compositions of objects l 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 l 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? l 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

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 40 Joint action systems - example action service() by client c; server s is when c.requesting && s.free do

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 41 contract model-view { 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 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(); } The Model-View contract

Harvey SiyPrinciples of Object-Oriented Software Development by Eliens Slide 42 Summary l We extended the notion of subtyping to include behavioral properties l Reviewed a correctness calculus for verifying behavioral properties l Defined a set of state transformations corresponding to programming language constructs l Defined mappings to reason about correspondence between abstract and concrete types and between subtypes and supertypes l Presented an overview of formalisms for specifying global interactions between objects