Parameterized models for
distributed objects
Eric Madelaine, Rabéa Boulifa, Tomás Barros
OASIS
INRIA Sophia-Antipolis, I3S, UNSA
[email protected]
http://www-sop.inria.fr/oasis/Vercors
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.
OASIS
Modocop, Grenoble, 4-12-2003 2
Contents
•
•
•
•
Parameterized model
Graphical syntax
Application to ProActive
Ongoing work
OASIS
Modocop, Grenoble, 4-12-2003 3
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, ...
OASIS
Modocop, Grenoble, 4-12-2003 4
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.
OASIS
Modocop, Grenoble, 4-12-2003 5
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.
OASIS
Modocop, Grenoble, 4-12-2003 6
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.


OASIS
Modocop, Grenoble, 4-12-2003 7
Graphical Syntax
 Networks
P1 (params)
vars
!M (args)
M (abst)
?…
P2 (…)
!…
?…
• Tree structure of boxes with ports, links,
labels…
• Encodes structure, scopes, renamings.
OASIS
Modocop, Grenoble, 4-12-2003 8
Graphical Syntax
 p-LTSs
x, y
y=2*x
x, y
! O[y].Mess (x+1)
If y=0 then
{z=0; goto s1}
else ...
• States, with variables
• Visible transitions (communication events)
• Local transitions (sequential programs)
• Compromise macro-transitions / interleaving
OASIS
s1
x, z
s2
x, z
s3
x, z
Modocop, Grenoble, 4-12-2003 9
Graphical Syntax
 Data

Local variables
Scope = boxes, states, transitions.

Expressions
Variables, operators, structured objects

Types
booleans, integers, intervals
finite enumerations
structured objects
 Communication
Rendez-vous (a la value-passing CCS)
but the model allows for group / multicast communication...

OASIS
Modocop, Grenoble, 4-12-2003 10
Application :
Building models of Distributed Active Objects
ProActive
code
Abstracted
ProActive
code
eXtended
MCG
Static Analysis
Parameterized
Network
Behavioral rules
P-LTS:
behavior, queue
Instantiations,
Checking tools
OASIS
Modocop, Grenoble, 4-12-2003 11
ProActive
Sequential
100% java,
Parallel, Distributed,
Concurrent, Mobile
programming
Distributed
• Transparent distribution, remote object creation, migration of
active objects
• Remote method call -> asynchronous communication
• Futures & wait-by-necessity
OASIS
Modocop, Grenoble, 4-12-2003 12
Remote Method Calls : informal diagram
Local object
Remote object
!Req_m
?Req_m
!Serv_m
• method call
!Req_m
• request arriving in
the queue
?Req_m
!Serv_m
• request served
(executed and removed)
• response sent back
!Rep_m • response received
!Rep_m
?Rep_m
?Rep_m
OASIS
Modocop, Grenoble, 4-12-2003 13
Application :
Building models of Distributed Active Objects
ProActive
code
Abstracted
ProActive
code
eXtended
MCG
Static Analysis
Parameterized
Network
Behavioral rules
P-LTS:
behavior, queue
Instantiations,
Checking tools
OASIS
Modocop, Grenoble, 4-12-2003 14
Extended Method Call Graph
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, M(args) C,
prog T
,
>
Call edges
- Node types :
Transfer edges
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.
OASIS
Modocop, Grenoble, 4-12-2003 15
Application :
Building models of Distributed Active Objects
ProActive
code
Abstracted
ProActive
code
eXtended
MCG
Static Analysis
Parameterized
Network
Behavioral rules
P-LTS:
behavior, queue
Instantiations,
Checking tools
OASIS
Modocop, Grenoble, 4-12-2003 17
Application level:
Network Topology
Eat(p)
!ReqTake(p,f)
Philo(p)
Enumeration:
•
•
?RepTake(p,f)
Think(p)
O ={Oi} a set of active object classes.
?ReqDrop(p,f)
Fork(f)
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)
OASIS
Modocop, Grenoble, 4-12-2003 18
Application :
Building models of Distributed Active Objects
ProActive
code
Abstracted
ProActive
code
eXtended
MCG
Static Analysis
Parameterized
Network
Behavioral rules
P-LTS:
behavior, queue
Instantiations,
Checking tools
OASIS
Modocop, Grenoble, 4-12-2003 19
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)
OASIS
Modocop, Grenoble, 4-12-2003 20
Example : recursive method
int Fact (int y)
{
if y=0 {return 1;}
else
return y*Fact(y-1);
}
OASIS
Modocop, Grenoble, 4-12-2003 21
Example (store)
Each object allocation has a parameterized
representation in the active object store.
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;
}
OASIS
Modocop, Grenoble, 4-12-2003 22
Example (store)
A, thisalloc(i)
OASIS
Modocop, Grenoble, 4-12-2003 23
Rules: SOS-style
For each SCC of the call graph :
{Premisses}
<v=pattern, n, A, M, Sc, Sm>
•
•
•
•
•
•
 <v ’,n ’, A ’, M ’, Sc ’,Sm ’>
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.
OASIS
Modocop, Grenoble, 4-12-2003 24
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...
OASIS
Modocop, Grenoble, 4-12-2003 25
Sequence
Call 0
If b0 then
x0=v0;
if b1 then
x1=v2;
goto C1
else
x1=v3;
goto C2
else
x0=v1; goto C3
Macro-transitions are simple sequential programs:
- no intermediate nodes
- no code duplication
- no mixing with communication events.
OASIS
Call 1
Call 3
Modocop, Grenoble, 4-12-2003 26
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 M n ’), M  {v1  n}, (v3, ):Sc, Sm>
Local calls will be inlined if possible, that is if the called method is not recursive
(part of a SCC of the call graph).
M is an abstract event “!Lcall m(co, o, args)”, generated only if visible. In the next
step, we go and inline the callee code
OASIS
Modocop, Grenoble, 4-12-2003 28
Local Call 2
v1  M
v1 C v2
progT
v1 
v3
<v1=call(O.m, args), n, A, M, Sc, Sm>
!Lcall m(args)
n
n1
Local (O) fresh(n1, n2, n3)

?Ret m(val)
n2
prog
n3
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.
OASIS
Modocop, Grenoble, 4-12-2003 29
Remote Request
v1 T v2
Remote(O)
<v1=call(O.m,args), n, A, M, _, _>
<v2, n ’, A‹(n
fresh(n ’)

!Req_M
n ’), M  {v1  n ’}, _, _>
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.
OASIS
Modocop, Grenoble, 4-12-2003 30
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]).
Local O[i] => !Lcall m(args)
i
Remote O[i] =>
!Req O[i].m(args)
i
?Ret m(val)
i
i
OASIS
Modocop, Grenoble, 4-12-2003 31
Futures
(v1)=v2
n1=M(v1) n2=M(v2)
<v1, A>
n1
A ’ = (A n2 

?Rep_M(val))
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();
OASIS
Modocop, Grenoble, 4-12-2003 32
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.
OASIS
Modocop, Grenoble, 4-12-2003 33
Example : Optimised Fork model
Eat(p)
!ReqTake(p,f)
Philo(p)
?RepTake(p,f)
Two small queues +
One behaviour LTS
Think(p)
?ReqDrop(p,f)
OASIS
Fork(f)
Modocop, Grenoble, 4-12-2003 34
Application :
Building models of Distributed Active Objects
ProActive
code
Abstracted
ProActive
code
eXtended
MCG
Static Analysis
Parameterized
Network
Behavioral rules
P-LTS:
behavior, queue
Instantiations,
Checking tools
OASIS
Modocop, Grenoble, 4-12-2003 35
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.
OASIS
Modocop, Grenoble, 4-12-2003 36
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}
OASIS
Modocop, Grenoble, 4-12-2003 37
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, ...
OASIS
Modocop, Grenoble, 4-12-2003 38
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.
OASIS
Modocop, Grenoble, 4-12-2003 41
Ongoing work
• 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, …)
http://www-sop.inria.fr/oasis/Vercors
http://www-sop.inria.fr/oasis/ProActive
OASIS
Modocop, Grenoble, 4-12-2003 42