Model Generation for Distributed Java Programs Rabéa Boulifa Eric Madelaine Oasis Team INRIA, 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 applIcationLuxembourg, 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) Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

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 ProActive Application Control flow analysis Behavioural Semantics scientiFic engIneering of Distributed Java applIcationLuxembourg, November 28, 2003

!Serv_m request served (executed and removed) response received !Serv_m Method Calls : informal diagram method call Current objectRemote 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 Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

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.) Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation AiAi QiQi serve AjAj QjQj Req(args) Rep(v) Behaviour LTS Queue LTS Active 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 Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

Building of Network Enumeration: O ={O i } a finite number of active object classes. Dom ( O i ) 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) Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

Method Call Graph MCG= 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);} Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

Rules: SOS-style {Premisses}  At beginning : MCG node LTS node LTSmapping Continuation stack method stack Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

Local Call v1  M v1  C v2 v1  T v2' Passive (O) fresh(n’)  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. Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

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. Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

Futures V v = O.m1(x); xxx; yyy; v.f();  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 n1 n2 scientiFic engIneering of Distributed Java applIcationLuxembourg, November 28, 2003

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);} Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

MCG  LTS Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation 5: ent(think) think:runActivity4 5 6: ret 6 runActivity[] ScSm [] 8: ent(getForks) getForks:runActivity : seq []runActivity 4 3: call(think) 4runActivity : call(getForks) 4 9: call(Fork[id].take) 7runActivity : ent(runActivity) []runActivity 1

MCG  LTS Sc Sm Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation []

MCG  LTS Sc Sm [] Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation []

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. Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

Properties Check properties: deadlocks, livelock, temporal logic formulas Check equivalence with Luxembourg, November 28,2003scientiFic engIneering of Distributed Java applIcation

Model Generation for Distributed Java Programs Rabéa Boulifa Eric Madelaine Oasis Team INRIA, Sophia-Antipolis France Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

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. Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation

MCG  LTS Luxembourg, November 28, 2003scientiFic engIneering of Distributed Java applIcation 5: ent(think) think:runActivity4 5 6: ret 6 runActivity[] 3: call(think) 4runActivity ScSm [] 8: ent(getForks) getForks:runActivity : seq []runActivity 9: call(Fork[id].take) 7runActivity : ent(runActivity) []runActivity : call(getForks) 7