1 / 21

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. Distributed Java Applications, the ProActive Library Approach

brac
Télécharger la présentation

Model Generation for Distributed Java Programs

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

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

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

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

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

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

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

  9. Method Call Graph MCG=<id, V, C, T , > 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

  10. Rules: SOS-style {Premisses} <v=pattern, n, A, M, Sc, Sm>  <v', n', A’, M', Sc’, Sm’> MCG node method stack LTS node Continuation stack LTS mapping At beginning: <v=ent(runActivity), , , M, [], []> scientiFic engIneering of Distributed Java applIcation Luxembourg, November 28, 2003

  11. v1  M v1C v2 v1 Tv2' Passive (O) fresh(n’) L_Call <v1=call(O.m), n, A, M, Sc, Sm> <v2, n', A(n n'), M {v1  n}, v2':Sc,Sm> 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

  12. Remote Call v1T v2 Active(O) fresh(n') R_Call <v1=call(O.m), n, A, M, Sc, Sm> <v2, n', A(n   n ’), M  {v1  n'}, Sc,Sm> !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

  13. n1 n2 Futures ?Rep_M (v1)=v2 n1=M(v1) n2=M(v2) A’ = (A ) Fut <v1, A> 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

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

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

  16. MCG  LTS ScSm [] [] scientiFic engIneering of Distributed Java applIcation Luxembourg, November 28, 2003

  17. MCG  LTS ScSm [] [] scientiFic engIneering of Distributed Java applIcation Luxembourg, November 28, 2003

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

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

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

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

More Related