model generation for distributed java programs
Download
Skip this Video
Download Presentation
Model Generation for Distributed Java Programs

Loading in 2 Seconds...

play fullscreen
1 / 21

Model Generation for Distributed Java Programs - PowerPoint PPT Presentation


  • 370 Views
  • Uploaded on

Model Generation for Distributed Java Programs. Rabéa Boulifa Eric Madelaine Oasis Team INRIA, Sophia-Antipolis France, I3S, UNSA. scientiFic engIneering of Distributed Java applIcation. Luxembourg, November 28, 2003. Outline. Distributed Java Applications, the ProActive Library Approach

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Model Generation for Distributed Java Programs' - victoria


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
model generation for distributed java programs

Model Generation for Distributed Java Programs

Rabéa Boulifa

Eric Madelaine

Oasis Team

INRIA, Sophia-Antipolis France, I3S, UNSA

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

outline
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
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)

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

approach
Approach

Control flow

analysis

ProActive

Application

MCG

Behavioural

Semantics

LTS

  • 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

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

method calls informal diagram
Method Calls : informal diagram

Current object

Remote object

!Req_m

!Req_m

  • method call

?Req_m

  • request arriving in
  • the queue

?Req_m

!Serv_m

  • request served
  • (executed and removed)

!Serv_m

!Rep_m

  • response sent back

!Rep_m

  • response received

?Rep_m

?Rep_m

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

model networks of synchronised ltss
Active Object j

Active Object i

Queue LTS

Req(args)

Qj

Aj

serve

Behaviour LTS

serve

Ai

Qi

Rep(v)

Model: Networks of synchronised LTSs

Finite enumeration active objects  Synchro. Networks [Arnold 80]

Boxes and links computed by static analysis

Labelled transition systems, LTSs

1 LTS per activity = LTS behaviour + LTS queue.

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

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

construction procedure
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

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

building of network
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)

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

method call graph
Method Call Graph

MCG=

method namenodescall edgestransfer edgesreference to future

nodes  {ent(id), call(id), rep(id), seq, ret}

public voidgetForks(){

ObjectForSynchro lf=

Fork[id].take();

ObjectForSynchro lr=

Fork[right_ind].take();

waitFor(lf);

waitFor(lr);}

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

rules sos style
Rules: SOS-style

{Premisses}

MCG node

method stack

LTS node

Continuation stack

LTS

mapping

At beginning:

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

local call
v1  M v1C v2 v1 Tv2' Passive (O) fresh(n’)

L_Call

M

Local Call

We will go and analyse its code, just as if we where inlining it.

We shall not develop loops or recursive procedures.

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

remote call
Remote Call

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

R_Call

!Req_M

O is a remote active object.

We simply generate a send message !Req_M encoding the method name

and its (abstracted) parameters.

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

futures
n1

n2

Futures

?Rep_M

(v1)=v2 n1=M(v1) n2=M(v2) A’ = (A )

Fut

 A ’

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

V v = O.m1(x);

xxx;

yyy;

v.f();

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

example philosopher diner
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);}

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

mcg lts
1: ent(runActivity)

[]

runActivity

5

1

2: seq

[]

runActivity

3: call(think)

6

4

runActivity

2

5: ent(think)

4

think:runActivity

6: ret

[]

runActivity

4: call(getForks)

8

3

7

runActivity

8: ent(getForks)

7

getForks:runActivity

9: call(Fork[id].take)

9

7

runActivity

4

1

3

7

4

9

MCG  LTS

Sc

Sm

[]

[]

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

mcg lts16
MCG  LTS

ScSm

[]

[]

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

mcg lts17
MCG  LTS

ScSm

[]

[]

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

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

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

model generation for distributed java programs19

Model Generation for Distributed Java Programs

Rabéa Boulifa

Eric Madelaine

Oasis Team

INRIA, Sophia-Antipolis France

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

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

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

model networks of synchronised ltss 2
Model: Networks of synchronised LTSs(2)
  • Labelled transition systems, LTSs

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

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

mcg lts21
1: ent(runActivity)

[]

runActivity

5

1

2: seq

[]

runActivity

3: call(think)

6

4

runActivity

2

5: ent(think)

4

think:runActivity

6: ret

[]

runActivity

4: call(getForks)

8

3

7

runActivity

8: ent(getForks)

7

getForks:runActivity

9: call(Fork[id].take)

9

7

runActivity

4

1

3

7

4

9

MCG  LTS

Sc

Sm

[]

[]

scientiFic engIneering of Distributed Java applIcation

Luxembourg, November 28, 2003

ad