A Behavioral Semantics for Object-Oriented Components

1. A Behavioral Semanticsfor Object-Oriented Components Arnd Poetzsch-Heffter joint work with Jan Schäfer Software Technology Group University of Kaiserslautern

2. 1. Introduction: Motivation by Modular Verification public class C { int a; void setA( int i ) { a= i; } } public class Point { spec_public private int x, y; public int getX() { return x; } public void setX( int nx ) { x=nx; } ... } C someC; Point p; ... assume someC.a == 7; p.getX(); assert someC.a == 7; public class DPoint extends Point { private C myC; public int getX() { myC. setA(0); return super.getX(); } void setMyC( C nc ) { myC=nc; } } • Modularity aspects: • Point might not know C or DPoint • Fragment might not know DPoint • Isn‘t DPoint a behavioral subtype • of Point?

3. 1. Introduction: Problems & Approach • Problems: • Frame aspects difficult to handle • Unit of verification above class level is unclear • Semantics only given for complete/closed programs • General Approach: „Box-Model“ • Hierarchical runtime components (boxes) based on OO-model • Structuring based on ownership • Clear relation between software component and „its“ runtime components • Representation- and environment-independent behavioral semantics

4. owner boundary object box environment box boundary 1. Introduction: Box Visualization

5. 1. Introduction: Design decisions • Design decisions: • Components are programmer defined: Programmer distinguishes between box classes and normal classes • Component structure given by „semantics-based“ ownership: • Components create objects locally: • - Objects of box classes are owners • - Created normal objects belong to the box of their creator • - Created box objects have their owner outside their box • Software component is the relevant code: • Use the code base of a box class C: • „smallest declaration complete set of classes containing C“

6. 1. Introduction: Goals & Extensions • Goals: • Behavioral semantics that • - is founded in an operational semantics • - abstracts from the box state • - abstracts from the environment • Semantics-based notion of behavioral substitutability that • - works for software components (code base) • - is defined without a coupling relation • Extensions: • Creational messages • Box and object transfer • Concurrency • Realistic module system

7. 1. Introduction: Overview • Operational semantics • Behavioral semantics • Exploitation: Substitutability & Most-general clients • Conclusions

8. 2. Operational Semantics: Syntax Program P ::= L Class L ::= [ box ] class C extends C { C f;M} MethodM ::= C m( C f ) {e } Exp e ::= x | null | (C)e | new C () | e. f | e. f =e | let x ==e in e | e. m(e)

9. Exec state ES ::= r Object store OS ::= j  O Inner boxes IB ::= j  B Reduction exp e ::= ... | result | o Method exec r ::= o  o‘ .m{ e } Message n ::= o  o‘ .m( v ) // invoke: address(n) = o‘ | o  o‘ .m: v // return: address(n) = o Term t ::= r | n 2. Operational Semantics: Static Semantics Box b ::= o | globox Object o ::= < j,b, C > Value v ::= o | null Object state O ::= v Box state B ::= < ES, OS, IB>

10. Big-step semantics for the behavior at box interfaces: b |-- (B,n)  (B‘,n‘) address(n)  b Reduction semantics for the internal behavior of Boxes: b : B, t b : B‘, t‘ 2. Operational Semantics: Judgements Semantics expressing the message traces of a box: q0  r0 q1  r1 q2  r2 q3 Notice: Environment of B not mentioned!

11. address(n)  b‘ owner(b‘) = b b‘ |- ( IB(b‘),n )  (B‘,n‘) b :ES,OS,IB, n b : ES,OS,IB[ b‘B‘ ], n‘ box(o‘) = b class(o‘) = C method(C,m) = _ m(_ x){ e } b : B; (oo‘.m( v ) ) b : B; oo‘.m{ [ o‘/ this, v/ x ] e } 2. Operational Semantics: Selected Rules (1) + address(n‘)  b b : B, n b : B‘, n‘ b |- (B,n)  (B‘,n‘)

12. b = box(o‘) b :  (o‘‘o.m{e})::ES,OS,IB; oo‘.m‘:v b :ES,OS,IB; (o‘‘o.m{ [v/result] e } b : B; oo‘.m{ v } b : B; oo‘.m:v 2. Operational Semantics: Selected Rules (2) b  box(o‘) b :ES,OS,IB; (o‘‘o.m{ [o‘.m‘( v )] } b :  (o‘‘o.m{ [result] })::ES,OS,IB; oo‘.m‘( v )

13. 2. Operational Semantics: Discussions • Operational semantics: • box local heap / rules never refer to locations outside the box • big step judgment at box boundary: b |-- (B,n)  (B‘,n‘) • dependency on environment only caused by object identifiers • makes invocations on outside objects explicit

14. 3. Behavioral Semantics: Overview Development steps: • Interface semantics: • - describes replies to ingoing concrete messages • - depending on box state • History semantics: • - describes replies to ingoing concrete messages • - depending on concrete message histories • Behavioral semantics: • - describes replies to ingoing abstract messages • - depending on abstract histories depends on instances, i.e. object ids does not depend on instances

15. 3. Behavioral Semantics: Interface semantics Interface semantics: (B‘,n‘) if b |-- (B,n)  (B‘,n‘) ABORT if getStuck(b,B,n) DIVERGE else isem(b,B,n) =

16. 3. Behavioral Semantics: History semantics History semantics: A history H of a box b is a „admissible“ sequence of ingoing messages for b, such that each message gets a reply. A history H of b is an abstract representation of states of b: state(b,empty) =  , ,   state(b, n n ) = B‘ if isem(b,state(b,n),n) = (B‘,n‘) state(b, n n ) = undefined otherwise n‘ if n admissible for H && oc = (B‘,n‘) oc if n admissible for H && oc (B‘,n‘) undefined otherwise hsem(b,H,n) = where oc = isem(b,state(b,H),n)

17. absMsg(n,H) absHis(H) absOutcome(n‘,H,n) 3. Behavioral Semantics: Abstraction Abstraction: • Abstraction of concrete message: • object representations  numbers • method names  typed method names • forget sender objects in incoming calls • forget sender and receiver in incoming returns • Abstraction and normalization of concrete message sequences: • concrete messages  abstract messages • normalize numbering

18. 3. Behavioral Semantics: Abstraction Lemma Abstraction Lemma: Let C be a box class with code base K, P1, P2 be two programs containing K, b1, b2 be boxes of C in executions of P1 and P2 resp., H1, H2 be concrete histories for b1 and b2 resp., such that absHis(H1) = absHis(H2). If n1, n2 are admissible for H1, H2 with absMsg(n1,H1) = absMsg(n2,H2), then: absOutcome(hsem(H1,n1),H1,n1) = absOutcome(hsem(H2,n2),H2,n2)

19. 3. Behavioral Semantics: Definition A sequence of abstract messages G is an abstract history for b iff there is a concrete history H for b with G = absHis(H) Behavioral semantics: ~ • Let n be an admissible abstract message for G, and let • H be some concrete history for b with absHis(H)=G and • n be some admissible message for H with absMsg(n,H) = n : ~ ~ bsem(C,G,n) = absOutcome( hsem(b,H,n), H,n) Lemma: bsem is well-defined

20. 4. Exploitation: Substitutability Definition: • Let C1, C2 be two box classes with code bases K1 and K2 resp. and • C2 be a subclass of C1. C2 is a behavioral substitute of C1, iff • every abstract history G of C1 is an abstract history of C2 • bsem(C1,G,n) = bsem(C2,G,n) for all n admissible for an • abstract history G of C1 ~ ~ ~ Substution Lemma: If C2 is a behavioral substitute of C1, P is a program using C1 and P‘ is program where uses of C1 are substituted by C2, then P and P‘ are behavioral equivalent.

21. violates behavioral semantics 4. Exploitation: Frame specification Distinction of local and external: • Can be used as semantics for interface specs. • Can be used to handle frame aspects. box interface Point { int getX() // no invocations void setX(int nx) // no invocations } public class C { int a; void setA( int i ) { a= i; } } public class DPoint extends Point { private C myC; public int getX() { myC.setA(0); return super.getX(); } void setMyC( C nc ) { myC=nc;} } C someC; Point p; assume someC.a == 7; p.getX(); assert someC.a == 7;

22. 4. Exploitation: Discussion substitutability Discussion: Notion of subsitutability - defines substitution in a more general sense than Banerjee/Naumann [TOPLAS 2005] - is specification independent in contrast to notions of „behavioral subtyping“ - could be used to define „most-general clients“

23. 4. Exploitation: Specification of invariants Treatment of invariants: • Invariants may only depend on the fields of the box. • Invariants have to hold whenever execution is outside the box. • Type states can be used to make this more flexible. • Implicit unpack/pack mechanism whenever box boundary is crossed.

24. 5. Summary & Discussion • Semantics for encapsulated modules: • - relation between modules and runtime instance (related work?) • Smoothly integrates with OO-programming • Provides complete interface abstraction • Semantic-based approach to ownership: • - generalizes owners-as-dominators/modifiers (ownership domains) • - methods called on boundary objects may modify the box state • - objects can be confined in one box, but not necessarily in its own • - ownership type system can be used on top • Distinctions between local and external references: • - field access only through local references • - restricted downcasts on external references • Distinct treatment of local and outgoing calls

25. 5. Now You Thanks for your attention ! Questions?