Models for the Verification of Distributed Java Objects

1. Models for the Verification of Distributed Java Objects Eric Madelaine work with Tomás Barros, Rabéa Boulifa, Christophe Massol OASIS Project, INRIA Sophia Antipolis June 2004

2. Goals • Analysis and verification software platform for behavioural properties of distributed applications. • Long term goal: full language, usable by non-specialists • Automatic tools = static analysis, model-checkers, equivalence / preorder checkers. Graphical / Logical Specifications Automatic tools, diagnostics, etc. Code analysis Model

3. Plan • Distributed objects in ProActive • Parameterized hierarchical models • Extracting models • Compositional verification • Components

4. ProActive : distributed activities • Active objects communicate by Remote Method Invocation. • Each active object: • has a request queue (always accepting incoming requests) • has a body specifying its behaviour (local state and computation, service of requests, submission of requests) • manages the « wait by necessity » of responses (futures)

5. ProActive : High level semantics • Independence wrt. distribution • Guarantee and Synchrony of delivery : • RdV mechanism ensures the delivery of requests, and of responses. • Determinism / Confluence : • Asynchronous communication and processing do not change the final result of computation. ASP Calculus: D. Caromel, L. Henrio, B. Serpette, “Asynchronous and Deterministic Objects”, POPL’2004

6. Correctness of the implementation (preorder) Architecture (parameterized) Properties (parameterized) Validate the model Architecture (parameterized) Instantiations (abstractions) Correctness of the implementation (model-checking) Static Analysis Abstract Source Code Source Code Data Abstraction Methodology : Snapshot Informal Requirements Model Checker

7. Model (1) :Synchronisation Networks • Labelled Transition Systems (LTS) <S,s0,L,  > • Synchronisation Network (Net) <AG,In,T> with T=<TT,t0,LT,  > with vLT, v=[lt,1,…, n], i  Ii idle,, lt  AG • 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 • => Boulifa 2003, Model generation for distributed Java programs, Fidji’03

8. (2) Parameterized Networks • Parameterized actions (with typed variables) pA • Parameterized LTS (pLTS) <K,S,s0,L,  > with state variables vs, and labels l=(b, (x), e) • Synchronisation Network (Net) <pAG,Hn,pT> with pT =<KG,TT,t0,LT,  > with Hn = {(pIi,Ki)}i a finite set of holes vLT, v=[lt,1k1,…, nkn], iki pIi idle, ki  Ki, lt  AG • Instantiation : for a finite abstract domain Dv pLTS x Dv  LTS pNet x Dv  Net • Barros, Boulifa, Madelaine “Parameterized Models for Distributed Java Objects”, Forte 2004, Madrid. Finite Network

9. Graphical Models

10. Large case-study:Electronic Invoices in Chile

11. Electronic Invoices in Chile Barros, Madelaine “Formalisation and Verification of the Chilean electronic invoice system”, INRIA report RR-5217, june 2004. • 15 parameterized automata / 4 levels of hierarchy • state explosion: grouping, hiding, reduction by bisimulation : • instantiating 7 parameters yields > millions of states...

12. True/False + diagnostic Parameterized Properties • Logical parameterized LTS • Parameterized temporal logics

13. Extracting models by static analysis

14. serve Aj Qj use Req Pj Model generation : key points • Static topology : finite number of parameterized activities. • For each Active Object Class : • parameterized network of LTSs (one for each method) • method calls = synchronisation messages • remote calls : “wait by necessity” using proxy processes • requests queue : the main potential blow-up…! • Property : starting from source code with abstracted data (simple types), we have a procedure that builds a finite parameterized model.

15. Consumer Network

16. Buffer Network Buf.Body get put Buf.Queue

17. Distributed Components

18. Component Identity Content Controller Lifecycle Controller Binding Controller Fractal hierarchical model :composites encapsulate primitives, which encapsulates Java code Controller Content

19. 1. Primitive component Java + Legacy D C 2. Composite component 3. Parallel and composite component Fractal + ProActiveComponents for the GRID An activity, a process, … potentially in its own JVM Composite: Hierarchical, and Distributed over machines Parallel: Composite + Broadcast (group)

20. Controller Content Components : correct composition • Behaviour is an essential part of a component specification. • Model of components : • primitive = pLTS • composite = pNet • state-less component = static pNet • controller = transducer • Correctness of composition : • implementation preorder ?

21. Conclusions • Parameterized, hierarchical model. • Graphical language. • Validated with a realistic case-study. • Ongoing development : instantiation tool, graphical editor, generation of model from ProActive source code. • Incorporation within a verification platform (ACI-SIFiacre : INRIA-Oasis, INRIA-Vasy, ENST-Paris, SVF)

22. Perspectives • Refine the graphical language, extend to other ProActive features, formalize the abstractions. • (Direct) parameterized verification. • Behavioural specifications of components, correct compositions. http://www-sop.inria.fr/oasis/Vercors