460 likes | 805 Views
Formal Specification and Verification of Distributed Component Systems. Tom ás Barros November 25, 2005. Introduction. OASIS Goals Fundamental principles, techniques and tools for the building, analysis, validation and maintenance of reliable distributed applications. VERCORS focus
E N D
Formal Specification and Verification of Distributed Component Systems Tomás Barros November 25, 2005 U. Nice, INRIA
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
Agenda • Target distributed components • Behaviour descriptions • Distributed components models construction • Verifying correctness • Tools • Conclusions and future work U. Nice, INRIA
Contribution • New format for behavioural specifications • Automatic construction of components behaviour • Properties verification illustration • Related tools U. Nice, INRIA
Distributed Hierarchical Components 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) U. Nice, INRIA
Fractal’s Components LIFE CYCLE BINDING CONTENT ATTRIBUTE Content U. Nice, INRIA
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
Active Objects communications U. Nice, INRIA
Active Objects communications U. Nice, INRIA
Active Objects communications U. Nice, INRIA
Active Objects communications U. Nice, INRIA
Fractive implementation • Active object => primitive component • Composite => sub-components + membrane (active object) U. Nice, INRIA
Describing the behaviours 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) U. Nice, INRIA
?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
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
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
?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
?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
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
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
Distributed Hierarchical Components Behavioural Specifications 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 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" 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
<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
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
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
?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
?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
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
Verifying Correctness U. Nice, INRIA
Behaviour correctness • Initial Composition • Requirements expressed as temporal formulas • Respect a SPEC • Reconfiguration • New properties (features) • Preservation 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 U. Nice, INRIA
Properties Verification(ACTL) • Error absence e.g. to start Buffer without linking alarm 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 ) U. Nice, INRIA
Properties Verification(regular -calculus) • Functional under reconfiguration • reconfiguration actions are allowed after deployment 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 ) U. Nice, INRIA
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
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
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
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
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
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
Future Work • Other Fractive features • Collection Interfaces • Group Communications • Collective Interfaces (under specification) • Multicast • Gathercast U. Nice, INRIA
Thank you U. Nice, INRIA