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

Introduction OASIS Goals VERCORS focus 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 November 25, 2005 U. Nice, INRIA

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

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

Distributed Hierarchical Components November 25, 2005 U. Nice, INRIA

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) November 25, 2005 U. Nice, INRIA

Fractal’s Components Content LIFE CYCLE BINDING CONTENT ATTRIBUTE November 25, 2005 U. Nice, INRIA

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

Active Objects communications November 25, 2005 U. Nice, INRIA

Active Objects communications November 25, 2005 U. Nice, INRIA

Active Objects communications November 25, 2005 U. Nice, INRIA

Active Objects communications November 25, 2005 U. Nice, INRIA

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

Describing the behaviours November 25, 2005 U. Nice, INRIA

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) November 25, 2005 U. Nice, INRIA

Networks of communicating automata callFoo !foo other A ?foo B  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 Next set of vectors !foo other Label Synchronisation constraint callFoo A !foo ?foo B other  November 25, 2005 U. Nice, INRIA

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 Need to extend the formalism November 25, 2005 U. Nice, INRIA

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 November 25, 2005 U. Nice, INRIA

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

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

Abstractions and Correctness R. Milner: Communication and Concurrency n [0≤x<Max-n]?A.foo(x) n+x ?A.foo(1) 2 1 ?A.foo(2) ?A.foo(0) ?A.foo(x) Max = 2 n: [0,Max] (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 November 25, 2005 U. Nice, INRIA

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 November 25, 2005 U. Nice, INRIA

Distributed Hierarchical Components Behavioural Specifications November 25, 2005 U. Nice, INRIA

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 November 25, 2005 U. Nice, INRIA

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" <content class="components.Alarm"> <behaviour file="AlarmBehav" format="FC2Param"/> </content> <binding client="BufferSystem.alarm" server="Alarm.alarm"/> </definition> November 25, 2005 U. Nice, INRIA

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"/> <content class="components.Alarm"> <behaviour file="AlarmBehav" format="FC2Param"/> </content> </component> <component name=”Consumer" <interface name=”buf" role=”client" <content class="components.Consumer"> <behaviour file=”ConsBehav" <component name=”Producer" <behaviour file=”ProdBehav" <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"> <component name=“Consumer" <component name=“Buffer" <component name=”Producer" BufferSystem Buffer Consumer Producer November 25, 2005 U. Nice, INRIA

Building the Models: Topology <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> BufferSystem Consumer ?Q_get() !R_get(x) ?Q_put(y) !Q_alarm() Producer Buffer November 25, 2005 U. Nice, INRIA

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

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

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

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 November 25, 2005 U. Nice, INRIA

Verifying Correctness November 25, 2005 U. Nice, INRIA

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

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 November 25, 2005 U. Nice, INRIA

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

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 ) November 25, 2005 U. Nice, INRIA

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

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 ) November 25, 2005 U. Nice, INRIA

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

Related Work Wright Darwin Sofa 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 November 25, 2005 U. Nice, INRIA

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 November 25, 2005 U. Nice, INRIA

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 November 25, 2005 U. Nice, INRIA

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 ? November 25, 2005 U. Nice, INRIA

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 November 25, 2005 U. Nice, INRIA

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

Thank you November 25, 2005 U. Nice, INRIA