Optimisation of behaviour of component-based distributed systems

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

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

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

Grid Component Model • hierarchy, distribution, one-to-many communications, reconfiguration capabilities; • -deployment, scalability, autonomic behaviour and asynchronous communication (ProActive Parallel library);

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

VCE graphical formalisms Components diagram

VCE formalisms • Diagram of one component

VCE 3.1.12 • Basic environment: Obeo Designer (base: Eclipse, developing graphical VCE formalisms). • Tools: • ADL2N (multiplatform tool in Java, building hierarchical an parametrizedbehaviour 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

SM labelsparametrization • 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

Grammar of SM labels • BNF grammar, behaviour for labels • Java Cup Parser - parser generator that produces a parser written in Java

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

Agenda • Motivation • Background • Integrating Xtext to VCE • Why Xtext • Grammar • Editor • Computing the context • State Machine and pLTS • Current state and contribution • Future work

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

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 “;” Stats Stat = MCall | Assign | Return Assign = Variable := Expr | Variable := MCall Expr = Variable | Constant | Expr Bop Expr | “(“Expr”)” Mcall = ”call” Interface “->” Operation “( )” | ”call” Interface “->” Operation “( “ Args” )” | ”call” Operation “( )” | ”call” Operation “( “ Args” )” Interface = ID”.”ID Operation = ID”.”ID Bop = && | || | + | - | * | / | == | >= | <=|!=

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

Computing the context • Cross-reference is one of the main features in Xtext • The ability to refer to the objects that are defined elsewhere

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

Current State and Contribution • Learning the subject. Learning Xtext. • Xtext was integrated in VCE • Availability to refer to VCE formalisms has been implemented (OleksandraKulankhina, SCALE) • Integrating tools for VCE formalisms (BartlomeijSzejna, Galyna Zholtkevych, SCALE) • Part of the real Xtext grammar has been created to give Xtext an attempt (BartlomeijSzejna, Galyna Zholtkevych, SCALE) • Part of the computing the context has been implemented (Galyna Zholtkevych, SCALE). • Xtext Editor has been implemented (BartlomeijSzejna, Galyna Zholtkevych, SCALE). Getting the context from the diagrams. Modifying code • Saving model to the file has been implemented (BartlomeijSzejna, SCALE) • Latest prototype of VCE has been tested (Galyna Zholtkevych, SCALE)

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

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

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

Thank you for the attention! • References: • Verifying Safety o Fault-Tolerant Distributed Components, RabéaAmeur-Boulifa, RalucaHalalai, LudovicHenrio, 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éaAmeur-Boulifa, RalucaHalalai, LudovicHenrio, 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/

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

Asynchronous communication Example: facebook, mail, mobile , ….

Optimisation of behaviour of component-based distributed systems