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 1

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 2

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 3

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

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 5

6. VCE graphical formalisms Components diagram 6

7. VCE formalisms Diagram of one component 7

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 8

9. SM labels parametrization Behaviour models are parametrized. pLTS (parametrized labeled transition system [1]) describe:[1] – Primitive internal behaviour – Semantic-level process generated from GCM architecture by ADL Example of Primitive internal behaviour 9

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

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 11

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 12

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 13

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 “;” 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 = && | || | + | - | * | / | == | >= | <=|!= 14

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

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 16

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

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) 18

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

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 20

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 21

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 http://hal.inria.fr/hal-00761073 Vercors platform: http://www- sop.inria.fr/oasis/index.php?page=vercorshttp://www- sop.inria.fr/oasis/index.php?page=vercors Xtext Language Development http://www.eclipse.org/Xtext/http://www.eclipse.org/Xtext/ Obeo Designer homepage http://www.obeodesigner.com/ 22

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 23

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