1. Behavioural Models for Distributed Hierarchical Components
Tomás Barros, Ludovic Henrio and Eric Madelaine
INRIA Sophia Antipolis
OASIS project
Monday, September 26th, 2005
FIACRE Grenoble

2. Plan Components/Fractal Fractive Behavioural models
ProActive based Fractal
Behavioural models
Properties verification
Monday, September 26th, 2005
FIACRE Grenoble

3. Component base programming
Component = software unit, deployment unit
Industrial acceptance : EJBs, CCM, COM …
3 key concepts :
1. Encapsulation
Black boxes, offered and required services, configuration
2. Composition
Design of complex systems
Hierarchical organization into sub-systems
3. Separate administration
ADL
Tools
HIGH ABSTRACTION LEVEL
COMPLEXITY HANDLING
REUSABILITY
CUSTOMIZATION
Monday, September 26th, 2005
FIACRE Grenoble

4. Fractal’s Components Primitive/Composite
LIFE CYCLE
BINDING
CONTENT
ATTRIBUTE
Content
Primitive/Composite
Optional non-functional interfaces
Membrane, internal and external interfaces
Fractal semantics (e.g binding only when stopped)
Monday, September 26th, 2005
FIACRE Grenoble

5. Component Behaviour Temporal Phases
Deployment
Definition of its content and initial binds
Usually defined in an ADL
Running
Only functional operations
Reconfiguration
Structural and non-structural changes
Monday, September 26th, 2005
FIACRE Grenoble

6. Fractal 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>
Monday, September 26th, 2005
FIACRE Grenoble

7. Fractive’s components
Fractal Implementation using ProActive
Fractal features:
Hierarchical components
ADL description (Fractal’s XML Schema/DTD)
Proactive features:
Distributed components (from distributed objects)
Asynchronous communication
Monday, September 26th, 2005
FIACRE Grenoble

8. ProActive’s middleware
Provides active and passive (standard) Java objects
Remote (transparent) references to active objects
Deep copy of parameters in method’s calls and responses. No shared objects
Only Active objects may be references
Monday, September 26th, 2005
FIACRE Grenoble

9. Active Objects Have their own and unique thread
Have request queue, where method’s calls are dropped (rendez-vous phase)
User define policies for serving methods from the queue by overloading the method RunActive (default FIFO)
Non blocking responses by giving a “future” reference. Synchronisation wait-by-necessity
Monday, September 26th, 2005
FIACRE Grenoble

10. Active Objects communications
Monday, September 26th, 2005
FIACRE Grenoble

11. Active Objects communications
Blocking of access f
Monday, September 26th, 2005
FIACRE Grenoble

12. Active Objects communications
Monday, September 26th, 2005
FIACRE Grenoble

13. Active Objects communications
Monday, September 26th, 2005
FIACRE Grenoble

14. Fractive implementation
Primitive component => Active object
Composite membrane => Active object
Primitive’s active object are reify
Forwarder for functional calls
Monday, September 26th, 2005
FIACRE Grenoble

15. Fractive’s implementation choices
Hierarchical start/stop
While stopped only non-functional request are served.
No path between functional and non-functional interfaces
Monday, September 26th, 2005
FIACRE Grenoble

16. Behaviour: Parameterized Networks
Parameterized LTS (pLTS) & Synchronisation Network (pNet)
Guarded actions with parameters
Parameters encoding value and process reference passing
Parameters encoding family of processes
parameterized synchronisation vectors
pAg <- [*, *, a3(k3), *, a4(k4), *]
Instantiation : for a finite abstraction of the parameters domains Dv
Finite Network
pLTS x Dv  LTS
pNet x Dv  Net
T. Barros, R. Boulifa, E. Madelaine: Parameterized Models for Distributed Java Objects,
Forte'2004 Conference, Madrid, Sep. 2004, LNCS 3235, © Springer-Verlag
Monday, September 26th, 2005
FIACRE Grenoble

17. Fractive Behavioural Models
Functional behaviour is known
Given by the user
Obtained by static analysis
Non functional 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
Monday, September 26th, 2005
FIACRE Grenoble

18. Fractive Behavioural Models
Visible actions and errors
Monday, September 26th, 2005
FIACRE Grenoble

19. Previous work: ProActive behavioural models (presented at Forte 2002)
T. Barros, R. Boulifa, E. Madelaine: Parameterized Models for Distributed Java Objects,
Forte'2004 Conference, Madrid, Sep. 2004, LNCS 3235, © Springer-Verlag
Monday, September 26th, 2005
FIACRE Grenoble

20. Fractive primitives Body is the functional behaviour
Monday, September 26th, 2005
FIACRE Grenoble

21. Fractive composites Automatically generated Future update in chain
Monday, September 26th, 2005
FIACRE Grenoble

22. Static Automaton Deployment Automaton
Static is also the sub-component’s behaviour for the next level of the hierarchy
Static = ( Controller || Deployment )
+ hiding & minimisation
Monday, September 26th, 2005
FIACRE Grenoble

23. Behaviour correctness (from the user point of view)
Initial Composition
Requirements expressed as temporal formulas
Respect a SPEC
Reconfiguration
New properties (features)
Preservation
Monday, September 26th, 2005
FIACRE Grenoble

24. Properties Verification (ACTL)
Deployment (on controller||deployment with successful synchronisation visible)
The deployment is always successful
Error absence during deployment
e.g. to start Buffer without linking alarm
Monday, September 26th, 2005
FIACRE Grenoble

25. Properties Verification (regular -calculus)
Effective start (due to asynchronisms)
[ true*.Sig(start(System))] true 
[ true*. Sig(start(BufferSystem))] true 
[ true*.Sig(start(Alarm))] true 
[ true*.Sig(start(Buffer))] true 
[ true*.Sig(start(Consumer))] true 
[ true*.Sig(start(Producer))] true
Monday, September 26th, 2005
FIACRE Grenoble

26. Properties Verification (regular -calculus)
Funtional behaviour (on the static automaton)
Get from the buffer eventually gives an answer
[ true*.get_req() ] X. (< true > true  [get_rep() ] X )
Monday, September 26th, 2005
FIACRE Grenoble

27. Properties Verification (regular -calculus)
Functional under reconfiguration
reconfiguration actions are allowed after deployment
Monday, September 26th, 2005
FIACRE Grenoble

28. Properties Verification (regular -calculus)
Functional under reconfiguration
Future update (once the method served) independent of life-cicle or bindins reconfigurations
E.g:
Enabling:
[ true*.get_req() ] X. (< true > true  [get_rep() ] X )
Monday, September 26th, 2005
FIACRE Grenoble

29. Structural Transformations
Controller of the new structure
Action mapping
Identify states in the original controller where transformation is possible (set T)
“Connect” both controllers from T through the transformation  (T’ is the image of )
The new behaviour is the reachable parts from T’ (using the action mapping)
Monday, September 26th, 2005
FIACRE Grenoble

30. Synchronous former exampleB2
Structural transformations
No errors during functional phase
Monday, September 26th, 2005
FIACRE Grenoble

31. Conclusions
Automatic construction of behaviour for distributed hierarchical models (including errors)
Taking into account functional and no-functional aspects
Reconfigurations and asynchronism
Verification of properties in different phases
Implementation of a prototype tool (Java) for model construction. CADP toolset for composition and verification of properties
Monday, September 26th, 2005
FIACRE Grenoble

32. Related Work Wright Darwin Sofa Behavioural Contracts (Carrez et al.)
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
Behavioural Contracts (Carrez et al.)
Behavioural typing (CSP like specification)
Interface behavioural-type compatibility (decidable) and components contract compliance (non decidable).
Monday, September 26th, 2005
FIACRE Grenoble