1 Flexible Subtyping Relations for Component- Oriented Formalisms and their Verification David Hurzeler PhD Examination, 9/11/2004

2 Plan of the presentation Introduction Introduction The component-oriented formalism The component-oriented formalism Subtyping Subtyping Verification Verification Conclusion and future work Conclusion and future work

3 Introduction The problems: « In a given system specified with the Concurrent Object-Oriented Petri Nets formalism, can we safely replace a component ? » « In a given system specified with the Concurrent Object-Oriented Petri Nets formalism, can we safely replace a component ? » Can we generalize our work to other formalisms ? Can we generalize our work to other formalisms ?

4 Introduction  Subtyping: Which existing definition(s) do we need ? Which existing definition(s) do we need ? Do we need to extend these ? Do we need to extend these ?  Verification: How can we guarantee this safety ? How can we guarantee this safety ? Safesubstitutability Safesubstitutability Safesubstitutability

5 Introduction Generality of our work:  If we define new subtype definitions, can we make them applicable to other formalisms ?  Can we find an abstract and high-level component-oriented formalism on which we can define our notion of subtyping, and which is still compatible with a large set of formalisms ?

6 Plan of the presentation Introduction Introduction The component-oriented formalism The component-oriented formalism Subtyping Subtyping Verification Verification Conclusion and future work Conclusion and future work

7 The component oriented formalism Aim:  Give the basic definitions and concepts on which we can develop notions of subtyping and verification.  Define a formalism, not a concrete language. What we want is a meta-language giving the pre-requisites for the core of our work.

8 The component oriented formalism A component is a tuple:, where:, where: c is the component name, c is the component name, B is the set of attributes, B is the set of attributes, I is the interface, containing both methods (provided services) and gates (required services), and I is the interface, containing both methods (provided services) and gates (required services), and Trans is the transition system, Trans is the transition system, Trans States × Events × States Trans States × Events × States m1 g1 c

9 Main features of the formalism  Concurrency inside and outside components,  Non-determinism,  Modularity: Component orientation with strict encapsulation,  Component interaction: Synchronization between components,  Component composition,  Component mobility.

10 Interaction Synchronizations, both inside and in between components: g1 g2 g3 m1m2m3m4 // m1 with (g1//g2)

11 The buffer example put buffer get failput failget put get get with failget put with failput

12 Interaction Synchronizations, both inside and in between components: g1 g3 m1m2m3m4 // g1 with m3, g2 with m4 g2 g1 with m3

13 Component composition Given:  a set of components,  a synchronization expression, and  a new interface, getput failput failget put get buffer1 failput failget put get buffer2 failput failget {b1.failput with b2.put, b1.failget with b2.get} We can define a new component.

14 Component composition (-,-,e,-) get with failget put get put with failput b1 b2 b1°b2 get get with failget put get put with failput get with failget {b1.failput with b2.put, b1.failget with b2.get}

15 Component composition (-,-,e,-) get with failget put get put with failput b1 b2 b1°b2 get get with failget put get put with failput (-,-,e,-,-,-,e,-) get {b1.failput with b2.put, b1.failget with b2.get}

16 Mobility g3 m3m4 g1 m1m2 g2 m1m2m3 g3 g4 m7m8 g5 m6m5 m3 g3 m3m4 m3

17 Mobility: components  Regular components  Containers:  Containers: c is its name, c is its name, I is its interface, I is its interface, MC is the set of acceptable components, MC is the set of acceptable components, Exp is a set of sync. expressions between all mc in MC, Exp is a set of sync. expressions between all mc in MC, MSyncExp is a set of mobile sync. expressions, MSyncExp is a set of mobile sync. expressions, B is the set of attributes (= union of attributes of mc in MC), B is the set of attributes (= union of attributes of mc in MC), Trans is its transition system. Trans is its transition system.

18 Mobility: Transition system State of a container: If a container contains components c1,c2,...,cn from MC respectively in states s1,s2,...,sn, its state is noted: If component c1 is container containing regular components c11 and c12 in states s11 and s12, this is also: (s1 s2...sn ) c1 c2 cn ((s11 s12 ) s2... sn ) c11 c12 c1 c2 cn

19 Mobility: Transition system ((s1) (s2) ) ((s4) (s5) ) c1 c2 c3 c4 c5 c6 m1 g1 c2 c1 c5 c4 c6 c3 c2 ((s1’) ) ((s4) (s5) (s2’) ) c1c3 c4 c5 c2 c6 Exp: m1 with g1 m1 mwith Send c2 g1 mwith Receive c2 MSyncExp:

20 Example of formalism: CO-OPN  CO-OPN objects correspond to regular components,  CO-OPN contexts correspond to containers,  Composition is exactly similar in both formalisms,  Concurrency, non-determinism, component interaction and modularity are equivalent.  Mobility is more general in our formalism.

21 Results so far  Composition: From two given components, we know how to build a third component.  Mobility: We are able to give the semantics of a container, and to build a container from a set of components (containers or regular).  This implies a formalisation of the mobility of contexts in CO-OPN.

22 Plan of the presentation Introduction Introduction The component-oriented formalism The component-oriented formalism Subtyping Subtyping Verification Verification Conclusion and future work Conclusion and future work

23 Subtyping « Can we safely replace a component in a given system ? »  Many existing definitions,  Each have their advantages, particular situations where particular situations where they are useful, they are useful,  But sometimes of little use in other situations: Often not very flexible. Often not very flexible. Strength Ease of use

24 Subtyping  A set of properties will be preserved during the substitution.  The substitutability depends on the context. Validation formula Observer component « Can wesafelyreplace a componentin a given system ? » safelyin a given system ? » Subtype relation

25 Subtyping: Definition Component rc is a subtype of component c w.r.t. observer obs and validation formula vf iff: Component rc is a subtype of component c w.r.t. observer obs and validation formula vf iff: (obs °c vf ) (obs °rc vf ) ! This relation is not symetric! ! This relation is not symetric! cc

26 The buffer example produceconsume put get Buffer Capacity 1 Producer Consumer Observer put get gput gget s s’ put with gput get with gget New Buffer put get put get vf ? Verification Tool feedback

27 Results  Substitutability: If s is a subtype of t w.r.t. observer obs and validation formula f, we may safely substitute s for t in the sense that for the kind of interaction depicted by obs, the satisfaction of f is preserved.  Flexibility and generality of our definition of subtyping.

28 Observer conception Problems:  Often impossible to build an optimal observer. Solutions:  Incremental conception from heuristics,  For some class of interaction, conception decidable (for example, for regular languages). Obs for heuristic2 Obs for heuristic3 Obs for heuristic1

29 Plan of the presentation Introduction Introduction The component-oriented formalism The component-oriented formalism Subtyping Subtyping Verification Verification Conclusion and future work Conclusion and future work

30 Verification pp’ ? Transformation f p p ?

31 Verification pp’ ? f(p) f(p)’ ? ??

32 Verification Three axis of research:  Restrict transformations,  Restrict properties to check,  Restrict composition.

33 Verification: Results Properties Existence Containing Contained TIP TCP Quite-strong Strong Including Trace preserving composition Connection preserving ci pi ci pi c1°c2p1p2 c1°c2p1p2 ci pi i f i f (ci)(pi) i f i f (ci)(pi) 1°2 f (c1°c2) 1°2 f (p1 p2) 1°2 f (c1°c2) 1°2 f (p1 p2) 1°2 f (c1°c2) 1°2 f (p1 p2) Strong c1°c2 p1 p2c1°c2 p1 p2 1°2 f (c1°c2) 1°2 f (p1 p2) 1°2 f

34 Verification: The Buffer example We have two buffers of transition system: If we compose these two buffers, can we get a buffer of capacity two which is such that EG is true? put get... put get Including Transformation NO Contained property

35 Plan of the presentation Introduction Introduction The component-oriented formalism The component-oriented formalism Subtyping Subtyping Verification Verification Conclusion and future work Conclusion and future work

36 Conclusions: Contribution  Definition of an abstract component-oriented formalism including composition semantics and mobility semantics.  Complete formalisation of the extension of CO- OPN ot the case of mobile contexts.  Definition of an adaptable notion of subtyping which englobes many existing works.

37 Conclusions: Contributions  Description of a verification technique based on component transformation, which, again, is intended to include many existing techniques. Proof of several results on property satisfaction which depend on the type of transformation, property and composition.  If we have a substitutability problem in a language L which may be seen as an instance of our own formalism, we may apply the subtyping and verification techniques defined in this thesis.  Case study as a means of illustrating our concepts in the COOPN formalism.

38 Future work  Implementation in a tool,  Include active component behavior in our formalism,  Include asynchrony ?  More work on observer conception,  Further development of verification techniques, by exploring other classes of properties, transformations, and composition.  Translation of existing techniques.