model generation for distributed java programs rabéa boulifa eric madelaine oasis team inria,...

Model Generation for Distributed Java Programs

Rabéa Boulifa Eric Madelaine

Oasis TeamINRIA, Sophia-Antipolis France, I3S, UNSA

Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

Outline

• Distributed Java Applications, the ProActive Library

• Approach• Models: Networks and LTSs• Model Construction• Conclusion

scientiFic engIneering of Distributed Java applIcation Luxembourg, November 28, 2003

Context, ProActive library• 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)


Approach

• Behavioural model (Labelled Transition Systems), built in a compositional (structural) manner : One LTS per active object.

• Synchronisation based on ProActive semantics• Usable for Model-checking finite / small models

MCG

LTS

ProActiveApplication

Control flow analysis

BehaviouralSemantics


!Serv_m• request served (executed and removed)

• response received

!Serv_m

Method Calls : informal diagram

• method call

Current 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


Model: Networks of synchronised LTSs

Finite enumeration active objects Synchro. Networks [Arnold 80]Boxes and links computed by static analysis

Labelled transition systems, LTSs1 LTS per activity = LTS behaviour + LTS queue.

Labels=Requests/Responses (meth. name + finite abstract. of param.)


Ai Qi

serveAj Qj

serveReq(args)

Rep(v)

Behaviour LTS

Queue LTSActive Object i Active Object j

Construction procedure• Finite network: analyse the source code of the

application, by some finite abstraction of parameters. • For each Active Object Class (with all required passive

classes):– build the Method Call Graph, MCG– compute the sequential LTS, using the SOS rules– interleave at each “wait by necessity” points, using the

Future rule (=> asynchronous LTS).– generate the request queue LTS.– combine the asynchronous LTS with the queue LTS.

• Property: For a finite data abstraction Termination guaranteed


Building of Network

Enumeration:• O ={Oi} a finite number of active object classes.

• Dom (Oi) a finite number of instantiations of each class.(use a finite abstraction of creation

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

methods• Outgoing links = remote requests

(use a finite abstraction of message parameters)


Method Call GraphMCG=<id, V, C, T , >

method name nodes call edges transfer edges reference to future nodes {ent(id), call(id), rep(id), seq, ret}

public void getForks(){ ObjectForSynchro lf= Fork[id].take(); ObjectForSynchro lr= Fork[right_ind].take(); waitFor(lf);waitFor(lr);}


Rules: SOS-style

{Premisses}

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

At beginning: <v=ent(runActivity), , , M, [], []>

MCG nodeLTS node

LTS mapping

Continuation stackmethod stack


Local Call

v1 M v1 C v2 v1 T v2' Passive (O) fresh(n’)

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

L_Call

M

We will go and analyse its code, just as if we where inlining it. We shall not develop loops or recursive procedures.


Remote Call

v1 T v2 Active(O) fresh(n')

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

R_Call

!Req_M

O is a remote active object.We simply generate a send message !Req_M encoding the method nameand its (abstracted) parameters.


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

Fut

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

n1n2


Example (Philosopher Diner)public void runActivity(){ while(true){ think(); getForks(); eat(); putForks();}}

public void getForks(){ ObjectForSynchro lf= Fork[id].take(); ObjectForSynchro lr= Fork[right_ind].take(); waitFor(lf);waitFor(lr);}


MCG LTS


5: ent(think)think:runActivity4

5

6: ret

6

runActivity[]

Sc Sm[] []

8: ent(getForks) getForks:runActivity78

2

2: seq[] runActivity

4

3: call(think) 4 runActivity

3

37

runActivity74: call(getForks)

4

9: call(Fork[id].take) 7 runActivity9

9

11: ent(runActivity)

[] runActivity

1

MCG LTSSc Sm


[] []

MCG LTSSc Sm

[]


[]

Conclusion• Behaviour models of ProActive distributed applications

encode asynchronous communication between distributed objects.

• With usual data/structure abstraction, we build finite, hierarchical, models suitable for automatic verification.

• Prototype implementation based on Soot and Bandera tools.

Future directions

• Parameterised models can be finitely instantiated (adapted to each property), or directly fed into specialised tools. They are more compact and more flexible.

• Other ProActive features : group communication, exceptions.• Behaviour specification for distributed components.


Model Generation for Distributed Java Programs

Rabéa Boulifa Eric Madelaine

Oasis TeamINRIA, Sophia-Antipolis France

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

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


Model: Networks of synchronised LTSs(2)

• Labelled transition systems, LTSs1 LTS per activity = LTS behaviour + LTS queue.

• Labels= Requests/Responses (method name + finite abstraction of parameters)

• Construction by SOS rules, based on the Method Call Graph.


MCG LTS


5: ent(think)think:runActivity4

5

6: ret

6

runActivity[]

3: call(think) 4 runActivity

3

43

Sc Sm[] []

8: ent(getForks) getForks:runActivity78

2

2: seq[] runActivity

9: call(Fork[id].take) 7 runActivity

9

9

11: ent(runActivity)

[] runActivity

1

runActivity

4

74: call(getForks)

7

model generation for distributed java programs rabéa boulifa eric madelaine oasis team inria,...

Documents