Xtext is a framework for developing programming languages and domain speci c languages (DSLs). Xtext contains a language infrastructure including parsers, compiler and interpreter. In recent years, it has been applied to develop various DSLs. To bene t from Xtext, in certain cases, it is needed to transform an Extend Backus Naur Form (EBNF) based language to the Xtext grammar. For example, the wellknown UML pro le MARTE has a BNF-based Value Speci cation Language (VSL). It is needed to transform MARTE VSL in EBNF to a MARTE VSL Xtext grammar for the purpose of enabling tool integration. In this paper, as the rst step towards a fully automated transformation from EBNF to Xtext, a number of transformation rules are de ned. The ultimate objective of the project is to provide developers a fully featured and customizable Eclipse-based IDE for developing DSLs using EBNF grammar or enabling tool integration by providing transformation from EBNF to Xtext.
Xtext[
While Model Driven Engineering (MDE)[
Few resources [
The transition method follows certain rules depending on the EBNF grammar pattern. In this proposal, several common patterns are presented and transformed to Xtext grammar sentences. After all Xtext codes are generated, we can use Xtext to get corresponding meta-model and DSL's IDE. As part of the future work, we will automate the transition. 2
Relationship between EBNF and Xtext's Grammar First, the notations used in EBNF can all be translated to corresponding Xtext notations, as shown in Table 1. In EBNF, the terminals are strings quoted by a pair of double quotation marks. While single quotation marks can be used in Xtext, the terminals in Xtext can also be de ned by user using terminal rules.
In addition, Xtext has more notations. The notation `(...)+' can describe the cardinalities one or more. The operator `..' can describe character ranges such as (`0'..`9'), which could de ne the common terminal INT.
Xtext has a special kind of rules that return the enumeration strings: Enum Rules. The same pattern can appear in EBNF, but EBNF does not o er simiar kinds of rules. Thus, when an enumeration pattern is detected in EBNF, it is transferred into Enum Rules in Xtext.
A parser rule is regarded as a tree of non-terminal and terminal tokens. In EBNF, the rules are simply described as the combination of non-terminals, terminals or both. However, Xtext has an even stronger representation that can relate to semantics of a meta-model. In Xtext, we can use the assignment notations `=' and `+=' (multi-valued feature) to assign a feature to a nonterminal object.
Though left recurrences are allowed in EBNF rules, they cannot occur in
the Xtext input since Xtext leverages the ANother Tool for Language
Recognition (ANTLR)[
In summary, for as an arbitrary EBNF rule, there exists a corresponding Xtext format description. Therefore, the transition from EBNF to Xtext is possible. 3
EBNF to Xtext Transition Processes To implement the transition from EBNF to Xtext, certain procedures are required. As shown in Fig. 1, before we get the Xtext description structure, we have to make decisions according to the certain patterns of a EBNF rule and take some actions accordingly as highlighted (yellow boxes) in the gure. In this section, the four di erent actions highlighted in the yellow rectangles are discussed respectively.
For a EBNF pattern with one terminal in every alternation: 1. Add Enum in the left of the de ned nonterminal; 2. Assign new meta-model features to every alternations in Xtext. As shown in Row 2 of Table 2, the nonterminal Operation is changed to Enum Operation, ADD and SUB are two features of the object Operation.
If a left recursion occurs in a EBNF rule: 1. Replace the left recursion by a new nonterminal in corresponding Xtext input; 2. Add the new de ned nonterminal as a new alternation in Xtext rule; 3. Transport alternations that do not have the left recursion in EBFN rule to the new de ned nonterminal.
The left recursion A in Column 1 Row 3 of Table 2 is replaced by AtomA.
For a right recursive EBNF grammar pattern like A=B jBA, if B is not a simple nonterminal or terminal: 1. Extract the common factors B as a new Xtext grammar rule; 2. The original rule is changed to (newid += B)+, where newid is a multivalued feature of object A in meta-model.
In Row 4 of Table 2, the common factors B\:"C can be extracted as a new rule.
As shown in the last row of Table 2, for a general EBNF pattern without recurrence and enumeration, the transition rule is: 1. Change notations to the comparable ones in Xtext as described in the above section; 2. For every nonterminal in the right-hand of the de nition, add an identi er and an assignment notation in the left of the nonterminal to assign a feature to the currently produced object of corresponding meta-model.
Case Study: A Complete Transition Instance
This section illustrates the complete transition from EBNF rules to the
corresponding Xtext rules, as shown in Fig. 2, of a declarative query language named
JIns[
S = "select" RS "from" SP ["for" "all" DS] "where" CE RS = Id":"T|Id":"T RS DS = RS "satisfying" CE T = "interface"|"class"|"method"|"object"|"statement" SP = "repository" STRING CE = CE"&&"CE|CE"||"CE|"("CE")"|"!"CE|ID"."Att"="STRING |ID"."Att"="ID"."Att|ID Rel ID; Att = "name"|"modifier"|"type"|"returnType"|"paramsType" Rel = "extends"|"implements"|"in"|"call"|"use" To better bene t from Xtext, in some contexts, it is needed to transform an Extend Backus Naur Form (EBNF) based language to the Xtext grammar. Therefore, in this paper, we proposed four processes of transition from EBNF to Xtext. As a future work, we will develop a tool to support the automated transition and conduct case studies to evaluate the proposed approach.
Acknowledgement This work is supported by the National Natural Science Foundation of China (No.61472180), and by the Jiangsu Province Research Foundation(BK20141322).