1 / 18

Arnd Poetzsch-Heffter Univ. of Kaiserslautern

Equivalence of Object-oriented Program Components. Arnd Poetzsch-Heffter Univ. of Kaiserslautern. Motivation Object-oriented program components Component equivalence Verifying equivalence. Work in Progress. Motivation. Motivation:

ganit
Download Presentation

Arnd Poetzsch-Heffter Univ. of Kaiserslautern

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. Equivalence of Object-oriented Program Components Arnd Poetzsch-Heffter Univ. of Kaiserslautern • Motivation • Object-oriented program components • Component equivalence • Verifying equivalence Work in Progress

  2. Motivation • Motivation: • Program components: achieve modularity and scalability • Behavioral semantics as foundation of specification languages • Notions of semantics-based behavioral subtyping • Aspects treated in the following: • What is an object-oriented program component? • What does equivalence of components mean? • How do we verify equivalence? • Approach: • Take the OO encapsulation promise seriously. • Abstract from heaps before looking at equivalence. 2

  3. public interface IObserver { void notify( int info ); } public class Subject { private int state = 0; private List<IObserver> myObservers; Subject( List<IObserver> obs ) { myObservers = new ArrayList<IObserver>(obs); } public int getState() { return state; } public void update( int newState ) { state = newState; for( IObserver o : myObservers ){ o.notify( state ); } } } Motivation Problem: 3

  4. public interface IObserver { void notify( int info ); } public class Subject { private int state = 0; private List<IObserver> myObservers; Subject( List<IObserver> obs ) { myObservers = new ArrayList<IObserver>(obs); } public int getState() { return state; } public void update( int newState ) { state = newState; for( IObserver o : myObservers ){ o.notify(getState()); } } } public interface IObserver { void notify( int info ); } public class Subject { private int state = 0; private List<IObserver> myObservers; Subject( List<IObserver> obs ) { myObservers = new ArrayList<IObserver>(obs); } public int getState() { return state; } public void update( int newState ) { state = newState; for( IObserver o : myObservers ){ o.notify( newState); } } } Motivation Problem: 4

  5. Motivation Motivation Motivation • Related work: • Banerjee, Naumann: Ownership confinement ensures representation • independence for object-oriented programs [JACM 20005] • Jeffrey, Rathke: Java Jr.: Fully abstract trace semantics for a core • Java Language [ESOP 2005] • Koutavas, Wand: Reasoning about class behavior [FOOL/WOOD 2007] • Poetzsch-Heffter, Schäfer: A representation-independent behavioral • semantics for object-oriented components [FMOODS 2007]

  6. Object-oriented program components • General approach: • Structure the heaps into so-called boxes with clear boundaries s.t.: • Implementation of a box consists of fixed set of classes • Types of references crossing box-boundaries are known • An object belongs to exactly one box (but boxes can be nested) Relation to ownership techniques: • Ownership contexts with multiple ingoing references • Similar to ownership domains • Control of outgoing references • Used as a structuring mechanism, not a type-checking feature 6

  7. Object-oriented program components Flat instance box model: • Components are given by • dedicated creation class K • minimal declaration-closed set CB of class and interface declarations with K is in CB • At runtime: • Creating a K-object X creates a component/box instance • Box instance comprises all object directly or indirectly created by X :Main :Subject :Observer1 :ArrayList :Observer2 :IObserver[] 7

  8. Object-oriented program components Meassage behavior at component boundary: :Main :Subject update(42) :ArrayList :Observer1 notify(42) :IObserver[] :Observer2 update(0) notify(0) notify(0) notify(0) 8

  9. Object-oriented program components • Behavioral semantics: • Messages: method calls, returns from calls • Message names at component boundary are statically known • Component behavior: Reply to a message after a history of messages • Results from component model and operational semantics Example Subject: data IncMsg = CUpdate IObjId Int | CGetState IObjId | RNotify data OutgMsg = RUpdate | RGetState Int | CNotify EObjId Int admSubject: [IncMsg] -> IncMsg -> Bool semSubject: [IncMsg] -> IncMsg -> Maybe OutgMsg 9

  10. Component equivalence • Remarks: • Heap operations are encapsulated within the component • Abstract treatment of object identifiers • Approach: • Definition of equivalence based on operational semantics • Behavioral semantics as foundation for verification 10

  11. Component equivalence • Definition: (IO-equivalent, k-context, k-compatible, k-equivalent) • Let • P1, P2 programs (executable), • Q, R program components, • PC a set of class and interface declarations. P1 ≈ P2, if P1 and P2 have the same input /output behavior. k(PC,Q), if PC U Q is a program and PC has property k . Q and R are called k-compatible, if for all PC: k(PC,Q) ↔k(PC,R) Q and R are called k-equivalent, denoted by Q ~ R, if: • Q and R are k-compatible • for all PC: k(PC,Q) → (PC U Q) ≈ (PC U R) k 11

  12. Component equivalence Theorem: Let k be the property that „no class inherits from creation class within PC“. Then, the following holds for the sketched behavioral semantics: semQ = semR→Q ~ R k • Remarks: • fragile relationship between component model and behavioral semantics • restriction to k properties simplify behavioral semantics 12

  13. public interface IObserver { void notify( int info ); } public class Subject { private int state = 0; private List<IObserver> myObservers; Subject( List<IObserver> obs ) { myObservers = new ArrayList<IObserver>(obs); } public int getState() { return state; } public void update( int newState ) { state = newState; for( IObserver o : myObservers ){ o.notify( state ); } } } Component equivalence Restriction in theorem is necessary: 13

  14. public interface IObserver { void notify( int info ); } public class Subject { private int state = 0; private List<IObserver> myObservers; Subject( List<IObserver> obs ) { myObservers = new ArrayList<IObserver>(obs); } public int getState() { return state; } public void update( int newState ) { state = newState; for( IObserver o : myObservers ){ o.notify(getState()); } } } Component equivalence Restriction in theorem is necessary: 14

  15. Verifying equivalence • Verification technique: • Goal: semQ = semR • Problem: semQ , semR have complex representation based on operational semantics • Approach: Look for simpler representation of the denotation StateRep with is  StateRep adma :: StateRep IncMsg Bool semr :: StateRep IncMsg Maybe (OutgMsg) sems:: StateRep IncMsg Maybe (StateRep) such that sem iml im = semr (toSRep iml) im for iml, im with adm iml im where toSRep :: [IncMsg] StateRep toSRep [] = is toSRep (im:iml) = ns if sems (toSRep iml) im = Just ns 15

  16. Verifying equivalence Denotation representation for Subject: type StateRep = (Int, [EObjId], [Int]) adma :: StateRep -> IncMsg -> Bool adma (_,ol,[]) RNotify = False adma _ _ = True semr:: StateRep -> IncMsg -> Maybe (OutgMsg) sems:: StateRep -> IncMsg -> Maybe (StateRep) semrs:: StateRep -> IncMsg -> Maybe (OutgMsg,StateRep) semrs st im = if adma st im then Just(semrs' st im) else Nothing semrs' :: StateRep -> IncMsg -> (OutgMsg,StateRep) semrs' (_,[],ixl) (CUpdate o ss) = (RUpdate,(ss,[],ixl)) semrs' (_,o:ol,ixl) (CUpdate o ss) = (CNotify o ss,(ss,o:ol,1:ixl)) semrs' (x,ol,ixl) (CGetState o ) = (RGetState x,(x,ol,ixl)) semrs' (x,ol,ix:ixl) RNotify = if ix == length ol then (RUpdate, (x,ol,ixl)) else (CNotify (ol!!ix) x,(x,ol,(ix+1):ixl)) 16

  17. Verifying equivalence Component correctness w.r.t. specification Equivalenceproof: semQiml im = semrQ (toSRepQiml) im = semrR (toSRepRiml) im = semRiml im Equality of recursive function defs • Discussion: • One state representation is often sufficient • Technique can treat call backs • Generic and flexible approach to find simulation relation • Behavioral semantics can be used as foundation for more abstract component specification techniques 17

  18. Summary • Final remarks: • Explicit component notion for OO with call backs • Shades of denotations that abstract from the heap • Concise treatment of object identifiers • Foundation for component specification • Open issues: • Generation of simplified state representations? • Programming logic? Questions || Comments ? 18

More Related