1

Optimisation of behaviour of component-based distributed

systems

INRIA - I3S - CNRS – University of Nice Sophia-Antipolis

EPC SCALE

Galyna Zholtkevych

Internship Supervisor: Eric Madelaine

Sophia Antipolis, July 2014

2

Motivation-component-oriented programming - defining the distributed component-based application

-safety behaviour - robust software for verifying fault-tolerance and valid behaviour of the components

-specification needs hierarchical components structure, asynchronous communication with futures between components

3

Agenda

• Motivation• Background– Base: Grid Component Model– Robust software: Vercors Components Editor– Robust software: graphical formalisms– Behaviour specification: Grammar SM labels

• Xtext• Current state and contribution • Future work

4

Grid Component Model

• hierarchy, distribution, one-to-many communications, reconfiguration capabilities;

• -deployment, scalability, autonomic behaviour and asynchronous communication (ProActive Parallel library);

5

Vercors Components Environment• maintain implementation of the valid behaviour:

– precise denition of interfaces– hierarchical and modular design– VCE is based on GCM approach– for specifying behaviour of components VCE uses UML approach– maintain default vce types

6

VCE graphical formalisms

Components diagram

7

VCE formalisms

• Diagram of one component

8

VCE 3.1.12

• Basic environment: Obeo Designer (base: Eclipse, developing graphical VCE formalisms).

• Tools: – ADL2N (multiplatform tool in Java, building hierarchical an parametrized

behaviour model represented in pNETs from the specification of architecture and behaviour)

– Xtext 2.4.1 (integrated to VCE, parsing the grammar for behaviour specification)

• VCE Wizard (integrated application creating models for specifying VCE graphical formalisms (VCE components model, UML model, model for VCE types))

• Prototype version is used for teaching in the LIAMA summer school in Shanghai

9

SM labels parametrization• Behaviour models are parametrized.

pLTS (parametrized labeled transition system [1]) describe:– Primitive internal behaviour– Semantic-level process generated from

GCM architecture by ADL

Example of Primitive internal behaviour

10

Grammar of SM labels

• BNF grammar, behaviour for labels

• Java Cup Parser - parser generator that produces a parser written in Java

11

Internship Subject

• New alternative: Xtext instead of Java Cup implemented before

• Validation rules for the state machines: checking the correspondances between the built grammar and the valid behaviour

• Semantic translation of the state machine to pLTS has not been done

12

Agenda

• Motivation• Background• Integrating Xtext to VCE– Why Xtext– Grammar– Editor– Computing the context

• State Machine and pLTS• Current state and contribution • Future work

13

Why Xtext

• Autocomplete• The ability to refer to the VCE formalisms

(compatible with Ecore models)• The ability to refer to the UML formalisms

(cross-reference)• Compatible with Eclipse• Code generation

14

Xtext Grammar

• Part of the grammar for the labels of State Machine that was implemented and after extended • Behaviour model is

saved in the file as a String. • For dealing with the

real Model the objects with type EObjects are used.

Transition_label = “[“ Guard_Expr “]” “/” Stats “.” | “[“ Guard_Expr “]” “.” | “/” Stats “.”Stats = Stat | Stat “;” StatsStat = MCall | Assign | Return Assign = Variable := Expr | Variable := MCallExpr = Variable | Constant | Expr Bop Expr | “(“Expr”)”Mcall = ”call” Interface “->” Operation “( )” |

”call” Interface “->” Operation “( “ Args” )” |

”call” Operation “( )” | ”call” Operation “( “ Args” )”

Interface = ID”.”IDOperation = ID”.”IDBop = && | || | + | - | * | / | == | >= | <=|!=

15

Xtext Editor

All the behaviour model creating by Xtext grammar appears in Xtext Editor

16

Computing the context

• Cross-reference is one of the main features in Xtext

• The ability to refer to the objects that are defined elsewhere

17

Agenda• Motivation• Background• Xtext• Current state• Future work• State Machine and pLTS• Millestones for the future work

18

Current State and Contribution• Learning the subject. Learning Xtext.• Xtext was integrated in VCE

– Availability to refer to VCE formalisms has been implemented (Oleksandra Kulankhina, SCALE)

– Integrating tools for VCE formalisms (Bartlomeij Szejna, Galyna Zholtkevych, SCALE)

– Part of the real Xtext grammar has been created to give Xtext an attempt (Bartlomeij Szejna, Galyna Zholtkevych, SCALE)

– Part of the computing the context has been implemented (Galyna Zholtkevych, SCALE).

– Xtext Editor has been implemented (Bartlomeij Szejna, Galyna Zholtkevych, SCALE). Getting the context from the diagrams. Modifying code

– Saving model to the file has been implemented (Bartlomeij Szejna, SCALE)

• Latest prototype of VCE has been tested (Galyna Zholtkevych, SCALE)

19

Agenda

• Motivation• Background• Xtext• Current state and contribution• Future work• Semantic translation SM to pLTS• Millestones for the future work

20

Semantic translation SM to pLTS

• Semantic translation from the State Machine to pLTS has to be done– Validation rules:• State Machine’s labels behaviour• Diagram validation: static semantics verification; type

checking - verifying fully typed programs, compatibility of operands and operations

21

Millestones for the future work

• Filtering methods called from the transition label as a part for user’s tools• Validation rules • Translation the State Machine to

pLTS

22

Thank you for the attention!• References:• Verifying Safety o Fault-Tolerant Distributed Components,

Rabéa Ameur-Boulifa, Raluca Halalai, Ludovic Henrio, Eric Madelaine: http://hal.inria.fr/view_by_stamp.php?label=INRIA-RRRT&langue=fr&action_todo=view&id=inria-00621264

• Behavioural Semantics for Asynchronous Components, Rabéa Ameur-Boulifa, Raluca Halalai, Ludovic Henrio, Eric Madelaine: http://hal.inria.fr/hal-00761073

• Vercors platform: http://www-sop.inria.fr/oasis/index.php?page=vercors

• Xtext Language Development http://www.eclipse.org/Xtext/• Obeo Designer homepage http://www.obeodesigner.com/

23

Future proxies

• Specifying asynchronous communication between 2 active objects.

• So needs of future proxy– To perform remote call by

component– Waiting for the response value –

future value got by the Get_value method

24

Asynchronous communication

Example: facebook, mail, mobile , ….