1. Formal Specification and Verification of Distributed Component Systems
Tomás Barros
November 25, 2005
November 25, 2005
U. Nice, INRIA

2. Introduction OASIS Goals VERCORS focus
Fundamental principles, techniques and tools for the building, analysis, validation and maintenance of reliable distributed applications
VERCORS focus
Provide methods and tools for verifying behaviour of such applications
November 25, 2005
U. Nice, INRIA

3. Agenda Target distributed components Behaviour descriptions
Distributed components models construction
Verifying correctness
Tools
Conclusions and future work
November 25, 2005
U. Nice, INRIA

4. Contribution New format for behavioural specifications
Automatic construction of components behaviour
Properties verification illustration
Related tools
November 25, 2005
U. Nice, INRIA

5. Distributed Hierarchical Components
November 25, 2005
U. Nice, INRIA

6. Fractive’s components
FRACTAL : Component* model specification, implemented using
ProActive : Java library for distributed applications
= Fractive
Features:
Hierarchical Component Model
Separation of functionality / control
ADL description (Fractal’s XML Schema/DTD)
Distributed components (from distributed objects)
Asynchronous method calls (non-blocking)
Strong Formal Semantics (ASP) => properties and guarantees
*Component :
self-contained entity, with well-defined interfaces, composable (hierarchically)
November 25, 2005
U. Nice, INRIA

7. Fractal’s Components Content LIFE CYCLE BINDING CONTENT ATTRIBUTE
November 25, 2005
U. Nice, INRIA

8. ProActive’s Active Objects
Distributed “active” Java objects with asynchronous (non-blocking) method calls
Method: RunActive {
Statements;
Polices to select and
serve methods
(non-preemptive scheduler) }
Unique Thread
Responses
(future update)
Queue
Methods Calls
November 25, 2005
U. Nice, INRIA

9. Active Objects communications
November 25, 2005
U. Nice, INRIA

10. Active Objects communications
November 25, 2005
U. Nice, INRIA

11. Active Objects communications
November 25, 2005
U. Nice, INRIA

12. Active Objects communications
November 25, 2005
U. Nice, INRIA

13. Fractive implementation
Active object => primitive component
Composite => sub-components + membrane (active object)
November 25, 2005
U. Nice, INRIA

14. Describing the behaviours
November 25, 2005
U. Nice, INRIA

15. Behavioural description’s requirements (intermediate format for our framework)
Action base (process algebra)
Compromise between expressiveness and calculability
Usable by the tools (state space generators and model checking)
Expressive enough
Compositional descriptions (hierarchical)
Remote references (future references)
Dynamic changes
Output of data source analysis (automatic decision procedures)
November 25, 2005
U. Nice, INRIA

16. Networks of communicating automata
callFoo
!foo
other A
?foo B 
Labelled Transition Systems (LTS) : <S,s0,L,  >
Synchronisation Network (Net) :
operator over transition systems (finite arity, arguments with sorts)
synchronisation vectors : Ag <- [*, *, a3, *, a4, a5, *] -> i
dynamic synchronisation : transducers
Synchronisation product :
builds a global LTS from a Net of arity n, and n argument LTSs.
Arnold 1992 : synchronisation networks
Lakas 1996 : Lotos open expressions
Next set
of vectors
!foo
other
Label
Synchronisation
constraint
callFoo A
!foo
?foo B
other 
November 25, 2005
U. Nice, INRIA

17. Previous work in the team (first semester 2003)
On going Rabea Boulifa’s thesis work:
Behavioural model generation of ProActive applications (active objects)
*.java -> MCGs + Topology -> LTSs + Net
Drawbacks of the descriptions
No value or reference passing, finite static topology
Only finite systems, no recursive calls
Fixed queue depth
Need to extend the formalism
November 25, 2005
U. Nice, INRIA

18. Parameterized networks of communicating automata
Parameterized LTS (pLTS) & Synchronisation Network (pNet)
Parameters for value passing and indexed processes
Extension of Lin’s symbolic graphs with assignments and Arnold’s synchronisation networks.
Simple Types : Integers, Intervals, Enumerations, Records.
Barros, Boulifa, Madelaine : Parameterized Models for Distributed Java Objects, Forte'2004
November 25, 2005
U. Nice, INRIA

19. Parameterized Transition Systemsk
!foo
callFoo
?foo
!foo(x)
?foo(x)
callFoo(x)
n+x
[x>0]!foo(x)
other n B B
Barros, Boulifa, Madelaine : Parameterized Models for Distributed Java Objects, Forte'2004
November 25, 2005
U. Nice, INRIA

20. Parameterized Transition Systems
?A.foo(x) n+x
[x>0]!B[i].foo(x)
other n k
callFoo(i,x) B
!B[i].foo(x)
?A.foo(x)
Barros, Boulifa, Madelaine : Parameterized Models for Distributed Java Objects, Forte'2004
November 25, 2005
U. Nice, INRIA

21. Abstractions and Correctness
R. Milner: Communication and Concurrency n
[0≤x<Max-n]?A.foo(x)
n+x
?A.foo(1) 2 1
?A.foo(2)
?A.foo(0)
?A.foo(x)
Max = 2
n: [0,Max]
(1) Program semantics ==> Behaviour Model (parameterized)
user-specified abstract interpretation
(2) Behaviour Model ==> (instantiation) Finite Model
Value Passing case : define an abstract representation from a finite partition of the value domains, on a per-formula basis
Preservation of safety and liveness properties [Cleaveland & Riely 93]
Families of Processes : no similar generic result (but many results for specific topologies).
Instantiation: expand the automata and networks to all the possible values in finite
abstract domains of the parameters
November 25, 2005
U. Nice, INRIA

22. Case study: Chilean electronic invoices
Avoiding state explosion
Hiding per-formula
Structural hiding
Grouping by variable
Mixing the three
on-the-fly (evaluator)
15 parameterized automata
4 levels of hierarchy
Properties
5 reachability properties
2 action based CTL Formulas
November 25, 2005
U. Nice, INRIA

23. Distributed Hierarchical Components Behavioural Specifications
November 25, 2005
U. Nice, INRIA

24. Fractive Behavioural model build
Functional behaviour is known
Given by the user
Obtained by static analysis
Non-functional & asynchronous behaviour is automatically added from the component’s ADL
Automata within a synchronisation network, named controller
Component’s behaviour is the controller’s synchronisation product
November 25, 2005
U. Nice, INRIA

25. System example <?xml version="1.0" encoding="ISO-8859-1" ?>
<!DOCTYPE .... >
<definition name="components.System">
<component name="BufferSystem"
definition="components.BufferSystem(3)">
<interface name="alarm" role="client"
signature="components.AlarmInterface"/>
</component>
<component name="Alarm">
<interface name="alarm" role="server"
<content class="components.Alarm">
<behaviour file="AlarmBehav"
format="FC2Param"/>
</content>
<binding client="BufferSystem.alarm"
server="Alarm.alarm"/>
</definition>
November 25, 2005
U. Nice, INRIA

26. Building the Models: Topology
<?xml version="1.0" encoding="ISO " ?>
<!DOCTYPE .... >
<definition name="components.BufferSystem">
<interface name=”alarm" role=”client"
signature="components.AlmInterface"/>
<component name=”Buffer"
<interface name=”get" role=”server"
signature="components.GetInterface"/>
<interface name=”put" role=”server"
signature="components.PutInterface"/>
<content class="components.Alarm">
<behaviour file="AlarmBehav"
format="FC2Param"/>
</content>
</component>
<component name=”Consumer"
<interface name=”buf" role=”client"
<content class="components.Consumer">
<behaviour file=”ConsBehav"
<component name=”Producer"
<behaviour file=”ProdBehav"
<binding client=”Producer.buf” server=”Buffer.put"/>
<binding client=”Consumer.buf” server=”Buffer.get”/>
<binding client=”Buffer.alarm” erver=”alarm”/>
</definition>
<definition name="components.BufferSystem">
<component name=“Consumer"
<component name=“Buffer"
<component name=”Producer"
BufferSystem
Buffer
Consumer
Producer
November 25, 2005
U. Nice, INRIA

27. Building the Models: Topology
<component name=”Buffer"
<interface name=”get" role=”server"
signature="components.GetInterface"/>
<interface name=”put" role=”server"
signature="components.PutInterface"/>
<interface name=”alarm" role=”client"
signature="components.AlmInterface"/>
<content class="components.Buffer">
<behaviour file=”BufferBehav"
format="FC2Param"/>
</content>
</component>
BufferSystem
Consumer
?Q_get()
!R_get(x)
?Q_put(y)
!Q_alarm()
Producer
Buffer
November 25, 2005
U. Nice, INRIA

28. Building the Models: Topology
<definition name="components.BufferSystem">
<interface name=”alarm" role=”client"
signature="components.AlmInterface"/>
<interface name=”foo" role=”server"
signature="components.FooInterface"/>
BufferSystem
Consumer
Buffer
Producer
!Q_alarm()
?Q_foo()
November 25, 2005
U. Nice, INRIA

29. Building the Models: Non-Functional Behaviour
?start/stop
!bind/unbind(..)
BufferSystem
Consumer
B.alarm
BS.foo
?bind(..)
?bind(f,P.f)
?unbind(a,P.f)
unbound
bound
!Err(unbound,Bf.a)
?bind(a,BSI.a)
?unbind(a,BSI.a)
unbound
bound
!bind(..)
!R_alarm()
Buffer
?start/stop
Producer
?Q_foo()
!Err(unbound,Bf.a)
November 25, 2005
U. Nice, INRIA

30. Building the Models: asynchronous behaviour
Component’s
Controller
Body LF
Proxy(fut)
Queue
?Serve(M,…)
Call(M,…)
?Requests
!Response
?Response
!Request
Body
?Serve
start/stop
bind/unbind
?Serve(M,fut,args)
!fut.call(M,args)
!bind/unbind
!start/stop
BufferSystem
!bind/unbind
!start/stop
Consumer
Buffer
Producer
November 25, 2005
U. Nice, INRIA

31. Static Automaton Deployment Automaton
<binding client=”Producer.buf” server=”Buffer.put"/>
<binding client=”Consumer.buf” server=”Buffer.get”/>
<binding client=”Buffer.alarm” server=”alarm”/>
Static automaton = ( Controller || Deployment )
+ hiding & minimisation
November 25, 2005
U. Nice, INRIA

32. Verifying Correctness
November 25, 2005
U. Nice, INRIA

33. Behaviour correctness
Initial Composition
Requirements expressed as temporal formulas
Respect a SPEC
Reconfiguration
New properties (features)
Preservation
November 25, 2005
U. Nice, INRIA

34. Properties Verification (regular -calculus*)
Effective start (due to asynchronisms)
X. (< true > true  [ Sig(start(System)) ] X ) 
X. (< true > true  [ Sig(start(BufferSystem)) ] X ) 
X. (< true > true  [ Sig(start(Alarm)) ] X ) 
X. (< true > true  [ Sig(start(Buffer)) ] X ) 
X. (< true > true  [ Sig(start(Producer)) ] X ) 
X. (< true > true  [ Sig(start(Consumer)) ] X )
*Mateescu, Sighireanu: Efficient on-the-fly model-checking for regular alternation-free
-calculus, FMICS'2000
November 25, 2005
U. Nice, INRIA

35. Properties Verification (ACTL)
Error absence
e.g. to start Buffer without linking alarm
November 25, 2005
U. Nice, INRIA

36. Properties Verification (regular -calculus)
Functional behaviour (on the static automaton)
Get from the buffer eventually gives an answer
[ true*.get_req() ] X. (< true > true  [get_rep() ] X )
November 25, 2005
U. Nice, INRIA

37. Properties Verification (regular -calculus)
Functional under reconfiguration
reconfiguration actions are allowed after deployment
November 25, 2005
U. Nice, INRIA

38. Properties Verification (regular -calculus)
Avoiding state explosion
Distributed model generation (distributor, CADP)
Reduced controllers based on deployment
On-the-fly mixed with compositional hiding and minimisation
Functional under reconfiguration
Future update (once the method served) independent of life-cycle or bindings reconfigurations
E.g:
Enabling:
[ true*.get_req() ] X. (< true > true  [get_rep() ] X )
November 25, 2005
U. Nice, INRIA

39. Vercors Platform on going done Tool set :
Code analysis (prototype, partial)
Model generation (prototype, soon available)
Interactions with model-checking and verification tools (available)
done
Supported by FIACRE
An ACI-Security action of the French research ministry
November 25, 2005
U. Nice, INRIA

40. Related Work Wright Darwin Sofa
Connectors specified using CSP
Compatibility relation (modify CSP refinement)
Darwin
LTS specifications, construction by parallel composition, hiding and weak bisimulation reduction
Properties expressed through LTS and Büchi automata
Sofa
Frame (spec) vs.. Architecture (implementation) compliance relation based on traces
Hierarchical construction through parallel composition
detection of errors: bad activity, no activity and divergence
To our knowledge, no other work includes control behaviour
November 25, 2005
U. Nice, INRIA

41. Conclusions (1)
Introduced a new format (FC2Parameterized) for behavioural description
Networks of communicating automata (Arnold & Nivat)
Symbolic graph with assignment (Lin & Hennessy)
Compromise between expressiveness & practical use
Abstractions and Instantiations
Development of supporting tool: FC2Instantiate
November 25, 2005
U. Nice, INRIA

42. Conclusions (2)
Behavioural models for distributed hierarchical components
Including control behaviour
Automatic constructions
Control parts
Asynchronous aspects
Verification of Temporal Properties
In three phases: deployment, pure-functional, reconfigurations
Expressing control related requirements
Generic and component specific properties
Basis for tool: ADL2NET
November 25, 2005
U. Nice, INRIA

43. Future Work
Component compliance (compositional replacement of components)
Bisimulation equivalences are too restrictive
Sofa’s approach, the new component should:
provide the services in the way the environment expect it
do not require more from the environment
Trace inclusion -> process equivalences
Non-functional aspects ?
November 25, 2005
U. Nice, INRIA

44. Future Work Property patterns Complex property notations
Bandera’s approach
Property patterns close to natural language
Extend patterns for distributed components
AfterDeployment, FutureUpdate
Errors, ControlActions
November 25, 2005
U. Nice, INRIA

45. Future Work Other Fractive features Collection Interfaces
Group Communications
Collective Interfaces (under specification)
Multicast
Gathercast
November 25, 2005
U. Nice, INRIA

46. Thank you
November 25, 2005
U. Nice, INRIA