Formal Specification and Verification of Distributed Component Systems

1. Formal Specification and Verification of Distributed Component Systems Tomás Barros November 25, 2005 U. Nice, INRIA

2. Introduction • OASIS Goals Fundamental principles, techniques and tools for the building, analysis, validation and maintenance of reliable distributed applications • VERCORS focus • Provide methods and tools for verifying behaviour of such applications U. Nice, INRIA

3. Agenda • Target distributed components • Behaviour descriptions • Distributed components models construction • Verifying correctness • Tools • Conclusions and future work U. Nice, INRIA

4. Contribution • New format for behavioural specifications • Automatic construction of components behaviour • Properties verification illustration • Related tools U. Nice, INRIA

5. Distributed Hierarchical Components U. Nice, INRIA

6. Fractive’s components • FRACTAL : Component* model specification, implemented using • ProActive : Java library for distributed applications = Fractive • Features: • Hierarchical Component Model • Separation of functionality / control • ADL description (Fractal’s XML Schema/DTD) • Distributed components (from distributed objects) • Asynchronous method calls (non-blocking) • Strong Formal Semantics (ASP) => properties and guarantees *Component : self-contained entity, with well-defined interfaces, composable (hierarchically) U. Nice, INRIA

7. Fractal’s Components LIFE CYCLE BINDING CONTENT ATTRIBUTE Content U. Nice, INRIA

8. Method: RunActive { Statements; Polices to select and serve methods (non-preemptive scheduler) } Unique Thread Responses (future update) Queue Methods Calls ProActive’s Active Objects • Distributed “active” Java objects with asynchronous (non-blocking) method calls U. Nice, INRIA

9. Active Objects communications U. Nice, INRIA

10. Active Objects communications U. Nice, INRIA

11. Active Objects communications U. Nice, INRIA

12. Active Objects communications U. Nice, INRIA

13. Fractive implementation • Active object => primitive component • Composite => sub-components + membrane (active object) U. Nice, INRIA

14. Describing the behaviours U. Nice, INRIA

15. Behavioural description’s requirements(intermediate format for our framework) • Action base (process algebra) • Compromise between expressiveness and calculability • Usable by the tools (state space generators and model checking) • Expressive enough • Compositional descriptions (hierarchical) • Remote references (future references) • Dynamic changes • Output of data source analysis (automatic decision procedures) U. Nice, INRIA

16. ?foo A !foo other  B Next set of vectors other callFoo !foo !foo ?foo Label Synchronisation constraint other other  B A callFoo callFoo !foo ?foo  Networks of communicating automata • Labelled Transition Systems (LTS) : <S,s0,L,  > • Synchronisation Network (Net) : • operator over transition systems (finite arity, arguments with sorts) • synchronisation vectors : Ag <- [*, *, a3, *, a4, a5, *] -> i • dynamic synchronisation : transducers • Synchronisation product : builds a global LTS from a Net of arity n, and n argument LTSs. • Arnold 1992 : synchronisation networks • Lakas 1996 : Lotos open expressions U. Nice, INRIA

17. Need to extend the formalism Previous work in the team(first semester 2003) • On going Rabea Boulifa’s thesis work: • Behavioural model generation of ProActive applications (active objects) • *.java -> MCGs + Topology -> LTSs + Net • Drawbacks of the descriptions • No value or reference passing, finite static topology • Only finite systems, no recursive calls • Fixed queue depth U. Nice, INRIA

18. Parameterized networks of communicating automata • Parameterized LTS (pLTS) & Synchronisation Network (pNet) • Parameters for value passing and indexed processes • Extension of Lin’s symbolic graphs with assignments and Arnold’s synchronisation networks. • Simple Types : Integers, Intervals, Enumerations, Records. • Barros, Boulifa, Madelaine : Parameterized Models for Distributed Java Objects, Forte'2004 U. Nice, INRIA

19. ?foo ?foo(x) n+x !foo !foo(x) 0 k callFoo(x) callFoo !foo(x) !foo ?foo(x) ?foo Parameterized Transition Systems A [x>0]!foo(x) other n B B • Barros, Boulifa, Madelaine : Parameterized Models for Distributed Java Objects, Forte'2004 U. Nice, INRIA

20. ?A.foo(x) n+x Parameterized Transition Systems A [x>0]!B[i].foo(x) other 0 n k callFoo(i,x) B !B[i].foo(x) ?A.foo(x) • Barros, Boulifa, Madelaine : Parameterized Models for Distributed Java Objects, Forte'2004 U. Nice, INRIA

21. Abstractions and Correctness Max = 2 n: [0,Max] 2 ?A.foo(0) [0≤x<Max-n]?A.foo(x) n+x ?A.foo(1) ?A.foo(2) 1 ?A.foo(0) 0 n ?A.foo(2) ?A.foo(1) ?A.foo(x) ?A.foo(1) 0 • R. Milner: Communication and Concurrency ?A.foo(0) ?A.foo(0) • (1) Program semantics ==> Behaviour Model (parameterized) user-specified abstract interpretation • (2) Behaviour Model ==> (instantiation) Finite Model Value Passing case :define an abstract representation from a finite partition of the value domains, on a per-formula basis • Preservation of safety and liveness properties [Cleaveland & Riely 93] Families of Processes :no similar generic result (but many results for specific topologies). Instantiation: expand the automata and networks to all the possible values in finite abstract domains of the parameters U. Nice, INRIA

22. Case study: Chilean electronic invoices • Avoiding state explosion • Hiding per-formula • Structural hiding • Grouping by variable • Mixing the three • on-the-fly (evaluator) • 15 parameterized automata • 4 levels of hierarchy Properties • 5 reachability properties • 2 action based CTL Formulas U. Nice, INRIA

23. Distributed Hierarchical Components Behavioural Specifications U. Nice, INRIA

24. Fractive Behavioural model build • Functional behaviour is known • Given by the user • Obtained by static analysis • Non-functional & asynchronous behaviour is automatically added from the component’s ADL • Automata within a synchronisation network, named controller • Component’s behaviour is the controller’s synchronisation product U. Nice, INRIA

25. System example <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... > <definition name="components.System"> <component name="BufferSystem" definition="components.BufferSystem(3)"> <interface name="alarm" role="client" signature="components.AlarmInterface"/> </component> <component name="Alarm"> <interface name="alarm" role="server" signature="components.AlarmInterface"/> <content class="components.Alarm"> <behaviour file="AlarmBehav" format="FC2Param"/> </content> </component> <binding client="BufferSystem.alarm" server="Alarm.alarm"/> </definition> U. Nice, INRIA

26. <component name=“Buffer" BufferSystem <component name=“Consumer" Buffer Consumer <component name=”Producer" Producer Building the Models: Topology <?xml version="1.0" encoding="ISO-8859-1" ?> <!DOCTYPE .... > <definition name="components.BufferSystem"> <interface name=”alarm" role=”client" signature="components.AlmInterface"/> <component name=”Buffer" <interface name=”get" role=”server" signature="components.GetInterface"/> <interface name=”put" role=”server" signature="components.PutInterface"/> <interface name=”alarm" role=”client" signature="components.AlmInterface"/> <content class="components.Alarm"> <behaviour file="AlarmBehav" format="FC2Param"/> </content> </component> <component name=”Consumer" <interface name=”buf" role=”client" signature="components.GetInterface"/> <content class="components.Consumer"> <behaviour file=”ConsBehav" format="FC2Param"/> </content> </component> <component name=”Producer" <interface name=”buf" role=”client" signature="components.PutInterface"/> <content class="components.Consumer"> <behaviour file=”ProdBehav" format="FC2Param"/> </content> </component> <binding client=”Producer.buf” server=”Buffer.put"/> <binding client=”Consumer.buf” server=”Buffer.get”/> <binding client=”Buffer.alarm” erver=”alarm”/> </definition> <definition name="components.BufferSystem"> U. Nice, INRIA

27. BufferSystem Consumer ?Q_get() !Q_alarm() !R_get(x) Producer ?Q_put(y) <component name=”Buffer" <interface name=”get" role=”server" signature="components.GetInterface"/> <interface name=”put" role=”server" signature="components.PutInterface"/> <interface name=”alarm" role=”client" signature="components.AlmInterface"/> <content class="components.Buffer"> <behaviour file=”BufferBehav" format="FC2Param"/> </content> </component> Building the Models: Topology Buffer U. Nice, INRIA

28. BufferSystem Consumer !Q_alarm() Producer ?Q_foo() Building the Models: Topology <definition name="components.BufferSystem"> <interface name=”alarm" role=”client" signature="components.AlmInterface"/> <interface name=”foo" role=”server" signature="components.FooInterface"/> Buffer U. Nice, INRIA

29. ?start/stop ?bind(a,BSI.a) !bind(..) ?bind(f,P.f) Buffer ?unbind(a,BSI.a) bound unbound ?unbind(a,P.f) Producer bound unbound !R_alarm() !Err(unbound,Bf.a) Building the Models: Non-Functional Behaviour !bind/unbind(..) BufferSystem Consumer B.alarm BS.foo ?bind(..) ?start/stop ?Q_foo() !Err(unbound,Bf.a) U. Nice, INRIA

30. ?Requests Body !Response !start/stop Proxy(fut) Body Queue ?Serve start/stop Call(M,…) ?Serve(M,fut,args) ?Serve(M,…) !bind/unbind !fut.call(M,args) ?Serve bind/unbind Consumer LF !Request !bind/unbind !start/stop ?Response Buffer Producer Building the Models: asynchronous behaviour Component’s Controller BufferSystem !bind/unbind !start/stop U. Nice, INRIA

31. Static Automaton • Deployment Automaton <binding client=”Producer.buf” server=”Buffer.put"/> <binding client=”Consumer.buf” server=”Buffer.get”/> <binding client=”Buffer.alarm” server=”alarm”/> Static automaton = ( Controller || Deployment ) + hiding & minimisation U. Nice, INRIA

32. Verifying Correctness U. Nice, INRIA

33. Behaviour correctness • Initial Composition • Requirements expressed as temporal formulas • Respect a SPEC • Reconfiguration • New properties (features) • Preservation U. Nice, INRIA

34. Properties Verification(regular -calculus*) • Effective start (due to asynchronisms) X. (< true > true  [ Sig(start(System)) ] X )  X. (< true > true  [ Sig(start(BufferSystem)) ] X )  X. (< true > true  [ Sig(start(Alarm)) ] X )  X. (< true > true  [ Sig(start(Buffer)) ] X )  X. (< true > true  [ Sig(start(Producer)) ] X )  X. (< true > true  [ Sig(start(Consumer)) ] X ) *Mateescu, Sighireanu: Efficient on-the-fly model-checking for regular alternation-free -calculus, FMICS'2000 U. Nice, INRIA

35. Properties Verification(ACTL) • Error absence e.g. to start Buffer without linking alarm U. Nice, INRIA

36. Properties Verification(regular -calculus) • Functional behaviour (on the static automaton) • Get from the buffer eventually gives an answer [ true*.get_req() ] X. (< true > true  [get_rep() ] X ) U. Nice, INRIA

37. Properties Verification(regular -calculus) • Functional under reconfiguration • reconfiguration actions are allowed after deployment U. Nice, INRIA

38. Properties Verification(regular -calculus) Avoiding state explosion Distributed model generation (distributor, CADP) Reduced controllers based on deployment On-the-fly mixed with compositional hiding and minimisation • Functional under reconfiguration • Future update (once the method served) independent of life-cycle or bindings reconfigurations • E.g: • Enabling: [ true*.get_req() ] X. (< true > true  [get_rep() ] X ) U. Nice, INRIA

39. on going done Vercors Platform • Tool set : • Code analysis (prototype, partial) • Model generation (prototype, soon available) • Interactions with model-checking and verification tools (available) Supported by FIACRE An ACI-Security action of the French research ministry U. Nice, INRIA

40. Related Work • Wright • Connectors specified using CSP • Compatibility relation (modify CSP refinement) • Darwin • LTS specifications, construction by parallel composition, hiding and weak bisimulation reduction • Properties expressed through LTS and Büchi automata • Sofa • Frame (spec) vs.. Architecture (implementation) compliance relation based on traces • Hierarchical construction through parallel composition • detection of errors: bad activity, no activity and divergence To our knowledge, no other work includes control behaviour U. Nice, INRIA

41. Conclusions (1) • Introduced a new format (FC2Parameterized) for behavioural description • Networks of communicating automata (Arnold & Nivat) • Symbolic graph with assignment (Lin & Hennessy) • Compromise between expressiveness & practical use • Abstractions and Instantiations • Development of supporting tool: FC2Instantiate U. Nice, INRIA

42. Conclusions (2) • Behavioural models for distributed hierarchical components • Including control behaviour • Automatic constructions • Control parts • Asynchronous aspects • Verification of Temporal Properties • In three phases: deployment, pure-functional, reconfigurations • Expressing control related requirements • Generic and component specific properties • Basis for tool: ADL2NET U. Nice, INRIA

43. Future Work • Component compliance (compositional replacement of components) • Bisimulation equivalences are too restrictive • Sofa’s approach, the new component should: • provide the services in the way the environment expect it • do not require more from the environment • Trace inclusion -> process equivalences • Non-functional aspects ? U. Nice, INRIA

44. Future Work • Property patterns • Complex property notations • Bandera’s approach • Property patterns close to natural language • Extend patterns for distributed components • AfterDeployment, FutureUpdate • Errors, ControlActions U. Nice, INRIA

45. Future Work • Other Fractive features • Collection Interfaces • Group Communications • Collective Interfaces (under specification) • Multicast • Gathercast U. Nice, INRIA

46. Thank you U. Nice, INRIA