Parameterized models for distributed objects

Parameterized models for distributed objects

Eric Madelaine, Rabéa Boulifa, Tomás Barros

OASISINRIA Sophia-Antipolis, I3S, UNSA

[email protected]://www-sop.inria.fr/oasis/Vercors

OASIS Modocop, Grenoble, 4-12-2003 2

Aims

• Models for analysis of distributed applications:

– specification : compositional, graphical, intuitive

– automatic derivation from code

• Checking behavioral properties:

– branching time, action-based logics

– bisimulation-based models (compositional reduction)

• In the context of the Vercors, our verification platform for distributed communicating components.


Contents

• Parameterized model

• Graphical syntax

• Application to ProActive

• Ongoing work


Behavioral Models • Starting point = Finite models :

Networks of communicating Labelled Transition Systems

Process Algebras (under syntactic conditions for finiteness)

Format for automatic tools (FC2 format, Concur tools)

• Parametric models :Compact representation for (families of) finite models

• Closer to code structure

• Automatic construction

• Automatic instantiations

Other approaches : IF, NTIF, Promela, BIR, Estelle, ...


Finite Model Rabea Boulifa : “Model generation for Distributed Java Programs”,

FIDJI’03

Networks of LTSs as finite abstractions of distributed systems:Actions are communication events (e.g. remote method calls)

Data abstraction :Finite set of process parameters

(static analysis, or user provided, or deployment descriptor)

Finite set of messages

(e.g. method names only, or finite sets of values)

Method :Static analysis : class analysis, MCG construction, pointer analysis (for

keeping track of active objects)

SOS rules crossing the MCG, building the corresponding LTS.

Interleaving of the remote responses.


Finite Model Results :• Given a finite data abstraction, the construction procedure terminates,

and produces a finite LTS.

(even with recursive local or remote method calls)

• Optimisation of the request queue model.

Difficulties :Precision, and cost, of static analysis (cannot be modular).Size of the network (one process per active object) => crucial importance

of compositional reduction techniques.


Parameterized Model

• Finite representation of data parameterized states with variables message arguments

Instances of dynamic / generic networks parameterized processes evolving communication links

More compact, closer to the code structure easier for model generation one model => many (instantiated) proofs.


Graphical Syntax

Networks

!M (args)

P1 (params)

vars

• Tree structure of boxes with ports, links, labels…• Encodes structure, scopes, renamings.

P2 (…)

!…

?…

?…M (abst)


Graphical Syntax

p-LTSs

• States, with variables• Visible transitions (communication events)• Local transitions (sequential programs)• Compromise macro-transitions / interleaving

x, y

x, y

y=2*x

If y=0 then

{z=0; goto s1}

else ...

x, zx, z x, z

! O[y].Mess (x+1)

s1s2 s3


Graphical Syntax Data

Local variablesScope = boxes, states, transitions.

ExpressionsVariables, operators, structured objects

Typesbooleans, integers, intervals

finite enumerations

structured objects

Communication Rendez-vous (a la value-passing CCS)

but the model allows for group / multicast communication...


Application :Building models of Distributed Active Objects

ProActive code Abstracted

ProActive code

ParameterizedNetwork

eXtendedMCG

Static Analysis

P-LTS:behavior, queue

Behavioral rules

Instantiations,

Checking tools


ProActive 100% java,Parallel, Distributed, Concurrent, Mobileprogramming

Sequential Distributed

• Transparent distribution, remote object creation, migration of active objects• Remote method call -> asynchronous communication• Futures & wait-by-necessity


!Serv_m• request served (executed and removed)

• response received

!Serv_m

Remote Method Calls : informal diagram

• method call

Local object Remote object

• request arriving in the queue

!Req_m?Req_m

!Rep_m

?Rep_m

!Req_m

?Req_m

?Rep_m

• response sent back !Rep_m




ProActive code


eXtendedMCG

Static Analysis


Behavioral rules

Instantiations,

Checking tools


It encodes both the usual control flow usual in MCG (resolution of class analysis and of method calls), and the data flow relative to interesting parameters.

MCG=<V, C, T , >

- Node types :

ent(id,args), seq, ret(val), call(id,args),

resp(id,val), serve(id,args)

- Loc (M) and Loc(V) sets of variables local to a method or to a node.

- : V V , function mapping a future use-point to its definition.

Extended Method Call Graph

M(args) prog

Call edgesTransfer edges




ProActive code


eXtendedMCG

Static Analysis


Behavioral rules

Instantiations,

Checking tools


Application level:Network Topology

Enumeration:

• O ={Oi} a set of active object classes.

• Dom (Oi) a set of instantiations of each class.

(use the abstraction of creation parameters)

• Incoming ports (available services) = set of public methods

(with abstracted parameters)

• Outgoing links = remote requests

(use the abstraction of message name and parameters)

Philo(p)

Fork(f)

!ReqTake(p,f)

?RepTake(p,f)

?ReqDrop(p,f)

Eat(p)

Think(p)




ProActive code


eXtendedMCG

Static Analysis


Behavioral rules

Instantiations,

Checking tools


Active Object Model

ProActive structure :

- One activity = one request queue

+ one behavior + one local store.

- Queues = at any time, accept a set of values (mess+args)

Specialised generation procedure, factorisation possible.

Synchronised with the behavior through “Serve” messages.

- Behavior = parameterized LTS, or network.

One process (box) for each SCC of the method call graph

(or even one box for each method)


Example : recursive method

int Fact (int y) { if y=0 {return

1;} else return y*Fact(y-

1);}


public int m1() { int $val, y; y = 2; this.[TStore.x:int] = 1; virtualinvoke this.[TStore.m2(int):void](y); $val = this.[TStore.x:int]; return $val; }

Example (store)Each object allocation has a parameterized representation in the active object store.


Example (store)

A, thisalloc(i)


Rules: SOS-style

• v = pattern, the current MCG node analyzed,

• n, the last LTS node created,

• A, the LTS under construction,

• M, the mapping between MCG nodes and LTS nodes,

• Sc, the continuations stack,

• Sm, the method calls stack.

{Premisses}

<v=pattern, n, A, M, Sc, Sm> <v ’,n ’, A ’, M ’, Sc ’,Sm ’>

For each SCC of the call graph :


Method Entry

v1 M v1 T v2

<v1=ent(m,args), _, _, M, Sc, Sm> <v2, _, _, M {v1 n}, Sc, (m,args):Sm>

Push the new method m on the calls stack, and starts its processing.

The process produced encodes calls of m for any values of the parameters. This is carried by the guards/assignments of its transitions...


Sequence

If b0 then x0=v0; if b1 then x1=v2; goto C1 else x1=v3; goto C2elsex0=v1; goto C3

Call 3Call 1

Call 0

Macro-transitions are simple sequential programs:

- no intermediate nodes

- no code duplication

- no mixing with communication events.


Local calls will be inlined if possible, that is if the called method is not recursive (part of a SCC of the call graph).

MM is an abstract event “!Lcall m(co, o, args)”, generated only if visible. In the next step, we go and inline the callee code

Local Call 1

v1 M v1 C v2 v1 T v3 Local (O) fresh(n ’)

<v1=call(O.m, args), n, A, M, Sc, Sm> <v2, n ’, A‹(n n ’), M {v1 n}, (v3, ):Sc, Sm>

MM


Local Call 2

v1 M v1 C v2 v1 T v3 Local (O) fresh(n1, n2, n3)

<v1=call(O.m, args), n, A, M, Sc, Sm>

If the called method is recursive, its model is a boxed process, we generated a (parameterized) local call to this process, immediately followed by the corresponding return transition.

n n1!Lcall m(args)

n2 n3

prog

prog?Ret m(val)


Remote Request

O is a remote active object.

We simply generate a send message !Req_m (Oc, O, args) encoding the method name and its (abstracted) parameters.

v1 T v2 Remote(O) fresh(n ’)

<v1=call(O.m,args), n, A, M, _, _> <v2, n ’, A‹(n n ’), M {v1 n ’}, _, _>

!Req_M


Mixed Call

<v1=call(O[i].m (args)), _, _, _, _, _>

Difficulty: distinguish the local object amongst the other instances of the same class (Philo[n] = Philo[n+1]).

i i

i

Local O[i] => !Lcall m(args)

Remote O[i] => !Req O[i].m(args)

i

?Ret m(val)


Futures

V v = O.m1(x);xxx;yyy;v.f();

<v1, A> A ’

(v1)=v2 n1=M(v1) n2=M(v2) A ’ = (A ) ?Rep_M(val)

Where M is the phantom of M, i.e. the union of all Ms during the construction procedure

n1n2


Server Side : models for the queues • General case :

– Infinite structure (unbounded queue)– In practice the implementation uses bounded data structures– Approximation : (small) bounded queues– Operations : Add, Remove, Choose (filter on method name and args)

Generic Queue model

• Optimisation : – Most programs filter on method names : partition the queue.– Use specific (temporal) properties to minimise the queue model.


Example : Optimised Fork model

Two small queues +

One behaviour LTSPhilo(p)

Fork(f)

!ReqTake(p,f)

?RepTake(p,f)

?ReqDrop(p,f)

Eat(p)

Think(p)




ProActive code


eXtendedMCG

Static Analysis


Behavioral rules

Instantiations,

Checking tools


Verification : Tools

1) Formats :Graphical: we are building the tool…

experience from a large realistic case study.

Textual: conservative extension of the FC2 format, but we need more experience, and will certainly redesign it.

2) Instantiation :Work already done, tools by Toufik and Tomas.Direct (on-the-fly) interface to be worked on with CADP.


Imprecision

• Abstract Interpretation (data domains).

• Static Analysis (class analysis, pointer analysis); production of the extended MCG.

• Instantiation = abstraction of finite or integer domains to abstract “range” domains:

typically Nat -> {0, 1, …, k, more}


Other Formats• Promela (SPIN) :

– State-based versus action-based

– No hierarchical models

– Bounded generation (user control)

• NTIF :– Lotos communication (agreement)

– No parallelism

– No guarantee of finiteness

• Estelle, IF2.0, IC, CRL, ...


Conclusion• Graphical and textual Intermediate Format for parameterized and compositional transition systems, capturing value-passing communication within distributed applications.

• Compact representation for families of finite instantiations.

• Close to the source code structure.

• Automatic generation from static analysis of source code, starting with a simple abstraction of parameter domains.


Ongoing work

http://www-sop.inria.fr/oasis/Vercors

http://www-sop.inria.fr/oasis/ProActive

• Parameterized properties and their instantiations.

• Implementation of the generation tool.

• Bridges with verification tools: on the fly interface (evaluator), LTS operation at parameterized level (minimisation, product…).

• Specialised tools for infinite systems (Trex, Bebop, …)

Parameterized models for distributed objects

Documents

Transcript of Parameterized models for distributed objects