p. 1

1
Formal Specification and Verification of
Distributed Component Systems

• Tomás Barros
• November 25, 2005

2
Introduction

• OASIS Goals
• 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

3
Agenda

• Target distributed components
• Behaviour descriptions
• Distributed components models construction
• Verifying correctness
• Tools
• Conclusions and future work

4
Contribution

• New format for behavioural specifications
• Automatic construction of components behaviour
• Properties verification illustration
• Related tools

5
Distributed Hierarchical Components
6
Fractives components

• FRACTAL Component model specification,
  implemented using
• ProActive Java library for distributed
  applications
• Fractive

• Features
• Hierarchical Component Model
• Separation of functionality / control
• ADL description (Fractals XML Schema/DTD)
• Distributed components (from distributed objects)
• Asynchronous method calls (non-blocking)
• Strong Formal Semantics (ASP) gt properties and
  guarantees

Component self-contained entity, with
well-defined interfaces, composable
(hierarchically)
7
Fractals Components
ATTRIBUTE
BINDING
LIFE CYCLE
CONTENT
Content
8
ProActives Active Objects

• Distributed active Java objects with
  asynchronous (non-blocking) method calls

9
Active Objects communications
10
Active Objects communications
11
Active Objects communications
12
Active Objects communications
13
Fractive implementation

• Active object gt primitive component
• Composite gt sub-components membrane (active
  object)

14
Describing the behaviours
15
Behavioural descriptions requirements(intermedia
te 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)

16
Networks of communicating automata

• Labelled Transition Systems (LTS) ltS,s0,L, ? gt
• Synchronisation Network (Net)
• operator over transition systems (finite arity,
  arguments with sorts)
• synchronisation vectors Ag lt- , , a3, ,
  a4, a5, -gt 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

17
Previous work in the team(first semester 2003)

• On going Rabea Boulifas thesis work
• Behavioural model generation of ProActive
  applications (active objects)
• .java -gt MCGs Topology -gt LTSs Net
• Drawbacks of the descriptions
• No value or reference passing, finite static
  topology
• Only finite systems, no recursive calls
• Fixed queue depth

18
Parameterized networks of communicating automata

• Parameterized LTS (pLTS) Synchronisation
  Network (pNet)
• Parameters for value passing and indexed
  processes
• Extension of Lins symbolic graphs with
  assignments and Arnolds synchronisation
  networks.
• Simple Types Integers, Intervals, Enumerations,
  Records.

• Barros, Boulifa, Madelaine Parameterized
  Models for Distributed Java Objects, Forte'2004

19
Parameterized Transition Systems
A
xgt0!foo(x)
other
n
B
B

• Barros, Boulifa, Madelaine Parameterized
  Models for Distributed Java Objects, Forte'2004

20
Parameterized Transition Systems
A
xgt0!Bi.foo(x)
other
0
n
k
callFoo(i,x)
B
!Bi.foo(x)
?A.foo(x)

• Barros, Boulifa, Madelaine Parameterized
  Models for Distributed Java Objects, Forte'2004

21
Abstractions and Correctness

• (1) Program semantics gt Behaviour Model
  (parameterized)
• 
  user-specified abstract interpretation
• (2) Behaviour Model gt (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
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

23
Distributed Hierarchical Components Behavioural
Specifications
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 components ADL
• Automata within a synchronisation network, named
  controller
• Components behaviour is the controllers
  synchronisation product

25
System example
lt?xml version"1.0" encoding"ISO-8859-1"
?gt lt!DOCTYPE .... gt ltdefinition
name"components.System"gt ltcomponent
name"BufferSystem" definition"components.Bu
fferSystem(3)"gt ltinterface name"alarm"
role"client" signature"components.AlarmInt
erface"/gt lt/componentgt ltcomponent
name"Alarm"gt ltinterface name"alarm"
role"server" signature"components.AlarmInte
rface"/gt ltcontent class"components.Alarm"gt
ltbehaviour file"AlarmBehav"
format"FC2Param"/gt lt/contentgt lt/componentgt
ltbinding client"BufferSystem.alarm"
server"Alarm.alarm"/gt lt/definitiongt
26
Building the Models Topology
lt?xml version"1.0" encoding"ISO-8859-1"
?gt lt!DOCTYPE .... gt ltdefinition
name"components.BufferSystem"gt ltinterface
namealarm" roleclient"
signature"components.AlmInterface"/gt
ltcomponent nameBuffer" ltinterface nameget"
roleserver" signature"components.GetInter
face"/gt ltinterface nameput" roleserver"
signature"components.PutInterface"/gt
ltinterface namealarm" roleclient"
signature"components.AlmInterface"/gt ltcontent
class"components.Alarm"gt ltbehaviour
file"AlarmBehav" format"FC2Param"/gt
lt/contentgt lt/componentgt ltcomponent
nameConsumer" ltinterface namebuf"
roleclient" signature"components.GetInter
face"/gt ltcontent class"components.Consumer"gt
ltbehaviour fileConsBehav"
format"FC2Param"/gt lt/contentgt lt/componentgt
ltcomponent nameProducer" ltinterface namebuf"
roleclient" signature"components.PutInter
face"/gt ltcontent class"components.Consumer"gt
ltbehaviour fileProdBehav"
format"FC2Param"/gt lt/contentgt
lt/componentgt ltbinding clientProducer.buf
serverBuffer.put"/gt ltbinding clientConsumer.bu
f serverBuffer.get/gt ltbinding
clientBuffer.alarm erveralarm/gt lt/definition
gt
ltdefinition name"components.BufferSystem"gt
27
Building the Models Topology
ltcomponent nameBuffer" ltinterface nameget"
roleserver" signature"components.GetInter
face"/gt ltinterface nameput" roleserver"
signature"components.PutInterface"/gt ltinterface
namealarm" roleclient"
signature"components.AlmInterface"/gt ltcontent
class"components.Buffer"gt ltbehaviour
fileBufferBehav" format"FC2Param"/gt
lt/contentgt lt/componentgt
Buffer
28
Building the Models Topology
ltdefinition name"components.BufferSystem"gt
ltinterface namealarm" roleclient"
signature"components.AlmInterface"/gt ltinterface
namefoo" roleserver" signature"componen
ts.FooInterface"/gt
Buffer
29
Building the Models Non-Functional Behaviour
!bind/unbind(..)
BufferSystem
Consumer
B.alarm
?bind(..)
BS.foo
?start/stop
?Q_foo()
!Err(unbound,Bf.a)
30
Building the Models asynchronous behaviour
Components Controller
BufferSystem
!bind/unbind
!start/stop
31
Static Automaton

• Deployment
• Automaton

ltbinding clientProducer.buf serverBuffer.put"
/gt ltbinding clientConsumer.buf
serverBuffer.get/gt ltbinding clientBuffer.alar
m serveralarm/gt
Static automaton ( Controller Deployment )
hiding minimisation
32
Verifying Correctness
33
Behaviour correctness

• Initial Composition
• Requirements expressed as temporal formulas
• Respect a SPEC
• Reconfiguration
• New properties (features)
• Preservation

34
Properties Verification(regular ?-calculus)

• Effective start (due to asynchronisms)

?X. (lt true gt true ? ? Sig(start(System)) X )
? ?X. (lt true gt true ? ? Sig(start(BufferSystem))
X ) ? ?X. (lt true gt true ? ?
Sig(start(Alarm)) X ) ? ?X. (lt true gt true ? ?
Sig(start(Buffer)) X ) ? ?X. (lt true gt true ?
? Sig(start(Producer)) X ) ? ?X. (lt true gt
true ? ? Sig(start(Consumer)) X )
Mateescu, Sighireanu Efficient on-the-fly
model-checking for regular alternation-free
?-calculus,
FMICS'2000
35
Properties Verification(ACTL)

• Error absence

e.g. to start Buffer without linking alarm
36
Properties Verification(regular ?-calculus)

• Functional behaviour (on the static automaton)
• Get from the buffer eventually gives an answer

true.get_req() ?X. (lt true gt true ?
?get_rep() X )
37
Properties Verification(regular ?-calculus)

• Functional under reconfiguration
• reconfiguration actions are allowed after
  deployment

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. (lt true gt true ?
?get_rep() X )
39
Vercors Platform

• Tool set
• Code analysis (prototype, partial)
• Model generation (prototype, soon available)
• Interactions with model-checking and verification
  tools (available)

Supported by FIACRE An ACI-Security action of the
French research ministry
40
Related Work

• Wright
• 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

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

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

43
Future Work

• Component compliance (compositional replacement
  of components)
• Bisimulation equivalences are too restrictive
• Sofas approach, the new component should
• provide the services in the way the environment
  expect it
• do not require more from the environment
• Trace inclusion -gt process equivalences
• Non-functional aspects ?

44
Future Work

• Property patterns
• Complex property notations
• Banderas approach
• Property patterns close to natural language
• Extend patterns for distributed components
• AfterDeployment, FutureUpdate
• Errors, ControlActions

45
Future Work

• Other Fractive features
• Collection Interfaces
• Group Communications
• Collective Interfaces (under specification)
• Multicast
• Gathercast

46
Thank you