OSMOSE -- WP2 -- Prague June 2004

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 communication
Current object
Remote object

• method call

!Q_m(args)
!Q_m(args)
?Q_m(args)

• request arriving in
• the queue

?Q_m(args)

• request served
• (executed and removed)

!S_m(args)
!S_m(args)

• response sent back

!R_m(val)
!R_m(val)

• response received

?R_m(val)
?R_m(val)
6
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, POPL2004

7
Methodology Challenges

• Specification language
• usable by non-specialists
• Automatic verification
• construction of models from source code
• integrated software
• Standard, state-of-the-art model checkers
• finite state models,
• hierarchical models, compositional construction

8
Methodology Snapshot
Informal Requirements
Model Checker
9
Model (1) Synchronisation Networks

• Labelled Transition Systems (LTS) ltS,s0,L, ? gt
• Synchronisation Network (Net)
• ltAG,In,Tgt with
  TltTT,t0,LT, ? gt
• with ?v?LT, vlt,?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
• gt Boulifa 2003, Model generation for
  distributed Java programs, Fidji03

10
(2) Parameterized Networks

• Parameterized actions (with typed variables) pA
• Parameterized LTS (pLTS) ltK,S,s0,L, ? gt
• with state variables vs, and labels l(b,
  ?(x), e)
• Synchronisation Network (Net)
• ltpAG,Hn,pTgt with pT
  ltKG,TT,t0,LT, ? gt
• with Hn (pIi,Ki)i a finite set of holes
• ?v?LT, vlt,?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
11
Graphical Models
12
Large case-studyElectronic Invoices in Chile
13
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 gt millions
  of states...

14
Parameterized Properties

• Logical parameterized LTS

• Parameterized temporal logics

15
Extracting models by static analysis
16
Extended Call Graphs

• Encodes both the usual control flow usual in MCG
  (resolution of class analysis and method calls),
• and the data flow relative to interesting
  parameters (pieces of bytecode instructions)
• identifies ProActive objets (activities, remote
  calls, futures).

• Complex static analysis
• class analysis
• alias analysis
• object topology

17
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.

18
Consumer Network
19
Buffer Network
Buf.Body
get
put
Buf.Queue
20
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

21
Distributed Components
22
Fractal hierarchical model composites
encapsulate primitives, which encapsulates Java
code
Controller
Content
23
Fractal ProActive Components for the GRID
An activity, a process, potentially in its own
JVM
Composite Hierarchical, and Distributed
over machines
Parallel Composite Broadcast (group)
24
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 ?

25
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-SI Fiacre INRIA-Oasis, INRIA-Vasy,
  ENST-Paris, SVF)

26
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

27
Algorithm rules
28
Call rule

• If o is remote, we simply generate a send message
  !o.Q_m(this, f, args) encoding the method name,
  its status and its (abstracted) param. with
  future var.
• else the message !o.Call_m(args) is sent to the
  method proccess and according to the return value
  is void or no the response is awaited or no.