=Paper=
{{Paper
|id=Vol-1305/paper9
|storemode=property
|title=Solving the FIXML2Code-case Study with HenshinTGG
|pdfUrl=https://ceur-ws.org/Vol-1305/paper9.pdf
|volume=Vol-1305
|dblpUrl=https://dblp.org/rec/conf/staf/0001NBEG14
}}
==Solving the FIXML2Code-case Study with HenshinTGG==
https://ceur-ws.org/Vol-1305/paper9.pdf
Solving the FIXML2Code-case study with HenshinTGG
Frank Hermann Nico Nachtigall Benjamin Braatz Susann Gottmann
Thomas Engel
Interdisciplinary Centre for Security, Reliability and Trust,
Université du Luxembourg, Luxembourg
firstname.lastname@uni.lu ∗
Triple graph grammars (TGGs) provide a formal framework for bidirectional model transformations.
As in practice, TGGs are primarily used in pure model-to-model transformation scenarios, tools for
text-to-model and model-to-text transformations make them also applicable in text-to-text transfor-
mation contexts. This paper presents a solution for the text-to-text transformation case study of
the Transformation Tool Contest 2014 on translating FIXML (an XML notation for financial trans-
actions) to source code written in Java, C# or C++. The solution uses the HenshinTGG tool for
specifying and executing model-to-model transformations based on the formal concept of TGGs as
well as the Xtext tool for parsing XML content to yield its abstract syntax tree (text-to-model trans-
formation) and serialising abstract syntax trees to source code (model-to-text transformation). The
approach is evaluated concerning a given set of criteria.
1 Introduction
Triple graph grammars (TGGs) provide a formal framework for specifying consistent integrated models
of source and target models in bidirectional model transformations. Correspondences between the ele-
ments of source and target models are defined by triple rules, from which operational rules for forward
and backward transformations are derived automatically [5, 9]. Several tool implementations for TGGs
exist [7]. Numerous case studies have proven the applicability of TGGs in model-to-model (M2M) trans-
formation scenarios [4, 3]. In [6], we presented an approach for applying TGGs in a text-to-text (T2T)
transformation context for translating satellite procedures. We adapt this approach to provide a solution
for the T2T transformation case study of the TTC 2014 [8]. We evaluate the solution based on fixed
criteria: complexity, accuracy, development effort, fault tolerance, execution time, and modularity.
As depicted in Fig. 1, our transformation involves these steps: A text-to-model (T2M) transformation
step parses the the content of a FIXML file and yields its abstract syntax tree (AST). Then, a M2M
transformation is performed based on a given TGG to convert the source AST into the target AST.
Finally, the target AST is serialised back to source code via a model-to-text (M2T) transformation. We
combine Xtext [1] with the HenshinTGG tool to perform the T2M and M2T steps via Xtext and the M2M
step via HenshinTGG. Xtext is a tool for specifying domain specific textual languages and generating
parsers and serialisers for them. The parser checks that the input source code is well-formed and the
serialiser ensures that the generated output source code is well-defined. HenshinTGG is an extension of
the EMF-Henshin tool [2] and is used for specifying and executing M2M transformations based on the
formal concept of TGGs. The solution is available on SHARE1 .
The paper is structured as follows. Sec. 2 describes the TGG tool implementation HenshinTGG,
Sec. 3 presents the details of our solution for the case study, Sec. 4 evaluates the solution concerning the
given criteria and Sec. 5 provides a conclusion and describes potential extensions.
∗ Supported by the Fonds National de la Recherche, Luxembourg (3968135, 4895603).
1 http://is.ieis.tue.nl/staff/pvgorp/share/?page=ConfigureNewSession...
c Hermann et. al.
Submitted to:
This work is licensed under the
TTC 2014
Creative Commons Attribution License.
2 FIXML2Code with HenshinTGG
Figure 1: Main phases for the T2T-translation (Text-To-Text)
2 HenshinTGG
The main part of the solution involves the AST-conversion, i.e., the specification and execution of the
M2M transformation from FIXML ASTs to ASTs of Java, C# or C++ source code. ASTs are specified
by instance graphs that are typed over a meta-model which defines the allowed structure of the instance
graphs. Fig. 2 (right) depicts the meta-model of FIXML ASTs. Each FIXML AST has a root node of
type Model with at most one Header node connected by a header edge and with a number of XMLNodes
connected by edges of type nodes. The Header contains the XML declaration of a FIXML file and each
XMLNode represents a XML empty-element-tag () or a XML start-tag () together
with its matching XML end-tag (). XMLNodes may have several child elements, i.e., plain text
content (attribute entry) or a number of XML subnodes. Each Header and XMLNode may have several
XML Attributes of a specific name and with a certain value. The conversion of FIXML ASTs to
source code ASTs is performed based on the concept of TGGs (cf. App. A).
In order to perform the M2M transformation from FIXML ASTs to source code ASTs, we use the
TGG implementation HenshinTGG for model transformations which is an extension of the plain graph
transformation tool Henshin [2]. HenshinTGG is an Eclipse plugin providing a graphical development
and simulation environment for TGGs allowing the specification of triple graphs and triple rules and
execution of different kinds of TGG operations.
3 Solution
As already introduced in Sec. 1, we applied the general concept for the T2T-translation depicted in Fig. 1.
The presented solution concerns the output language Java only. We are confident that the Xtext grammar
could be generalised to a grammar that is capable to handle also C# and C++.
3.1 Parser for FIXML ASTs and Serialiser for Java ASTs
Fig. 2 (left) depicts the Xtext EBNF grammar of input DSL FIXML. Each rule of the grammar is iden-
tified by a non-terminal symbol separated by a colon from the rule specification body and ends with
a semicolon. E.g., the root rule Model specifies that each FIXML file has one optional XML Header
(line 4) and contains a number of XMLNodes. A Header contains the content of a usual XML header and
a number of Attributes (lines 5-7). For a detailed description of this Xtext grammar see Sec. B.1.
From the grammar, Xtext automatically generates the EMF meta-model in Fig. 2 (right) which serves
as meta-model for FIXML ASTs. Each parser rule becomes a node except for Entry, because Entry has
only unnamed references to terminal rules. Each named reference between two parser rules becomes an
Hermann et. al. 3
1 grammar lu.uni.snt.ttc2014.FIXML
2 with org.eclipse.xtext.common.Terminals
3 generate fIXML "http://www.uni.lu/snt/ttc2014/FIXML"
4 Model : header=Header? nodes+=XMLNode*;
5 Header : {Header} "<" "?" "xml"
6 attributes+=Attribute* "?" ">"
7 ("<" "!" ID* STRING* ">")?;
8 XMLNode : "<" tag=ID attributes+=Attribute*
9 ( ("/" ">") |
10 (">" subnodes+=XMLNode*
11 entry=Entry? "<" "/" end=ID ">")
12 );
13 Attribute : name=ID "=" value=STRING;
14 Entry : (ID|INT|WS|ANY_OTHER|
15 ML_COMMENT|SL_COMMENT|STRING)+;
Figure 2: Xtext grammar for FIXML parser (left) and corresponding FIXML meta-model (right)
Parsing AST-Conver- Serialising
(in ms) sion (in ms) (in ms)
test1.xml 147 500 1204
test2.xml 199 1063 1782
test4.xml 174 1478 3307
test5.xml 1012 5489 1749
test6.xml 2082 11935 596
Figure 4: Execution times on SHARE
Figure 3: Generated FT-rule FT Tag2Class
edge between the corresponding two nodes. Each named reference between a parser and a terminal rule
becomes an attribute of the corresponding node.
Analogously to the parser, the meta-model for Java ASTs (EMF meta-model) and the serialiser from
Java ASTs (EMF model instances) to Java source code are generated from the Xtext grammar for Java
(cf. App. B). Note that we only consider that subset of Java which is relevant for the translation.
3.2 M2M Transformation
As the main part of the solution involves the specification and execution of the M2M transformation
from FIXML ASTs to source code ASTs, we present one forward translation rule FT Tag2Class for
converting parts of FIXML ASTs to parts of Java ASTs in this section. Forward translation rules are
derived automatically from triple rules that we specified with HenshinTGG. The forward translation
rules are applied with HenshinTGG in order to convert the ASTs. The rules include the following design
decisions: FIXML input files may contain lists of XML tags with the same name. In our solution, all
these list elements are visited and all occurring features of these tags are integrated within the class
definition. We have an empty constructor that creates initially empty lists. In our view, any content in
the list created by the empty constructor would be non-intuitive for the user of the generated Java code.
Forward translation rule FT Tag2Class specifies the translation of a XMLNode with a certain tagName
4 FIXML2Code with HenshinTGG
into a class (class def) of the same name and links the created class to the root node Model of the
target AST with edge classes. Furthermore, two constructors (method def nodes having the name
of the class) are created for the class with an empty body each. The rule is only applied if there does
not already exist a class with the same name (NAC ClassNameUnique), i.e., if the FIXML file contains
several XML nodes of the same name, only one of these nodes is translated by this rule.
4 Analysis
The approach is evaluated concerning the following criteria that are fixed for the case study [8].
Complexity The TGG comprises 14 triple rules altogether containing 27 nodes, 14 node attributes
and 12 edges in source graphs, 65 nodes, 40 node attributes and 48 edges in target
graphs as well as 20 nodes in correspondence graphs. Both Xtext grammars comprise
24 parser rules with 58 references between them. In total, this results in a complexity
score of 322.
Accuracy The syntactical correctness of the translation is ensured by its formal definition based
on forward translation rules [5], i.e., each FIXML file that is completely translated
yields source code that is correctly typed over the meta-model of the target pro-
gramming language. The constraints of the target language are expressed by graph
constraints and are translated to application conditions of the triple rules. So, the
translation of FIXML ASTs ensures that target ASTs fulfill the constraints.
Development We spent 8 person-hours for writing and debugging the solution. In detail: 1 hour for
effort the grammar of the parser, 2 hours for the grammar of the serialiser, and 5 hours for
the TGG. The experience level of our developers is: Expert.
Fault Files Test 7 & 8 of the FIXML case study [8] have syntax errors and should be iden-
tolerance tified as invalid by the translation. The fault tolerance of our solution is classified as
High. Invalid FIXML input files that do not correspond to the FIXML Xtext grammar
lead to Xtext parsing errors which are displayed on the console and the translation is
aborted. Test 8 is successfully detected as being invalid because the FIXML grammar
claims that each XML start-tag has a corresponding end-tag.
Syntactical restrictions that cannot be expressed by the grammar are defined by con-
straints in a custom Xtext validator. We defined a constraint claiming that each start-
tag has the name of its corresponding end-tag. Test 7 does not satisfy this constraint
and is classified as being invalid. HenshinTGG GUI visualises those fragments of a
FIXML AST that cannot be translated by marking them red. This allows debugging
and the adaptation of the triple rules to obtain a complete translation.
Execution The execution times of the translation steps for each test are as listed in Fig. 4.
time
Modularity The TGG has a score of -0.5 (21 dependencies between 14 triple rules). The Xtext
parsing grammar for XML has a score of -0.71 (12 references between 7 grammar
rules). The Xtext serialisation grammar for Java has a score of -0.64 (36 references
between 22 grammar rules). In total, this results in a score of -0.62.
Abstraction The abstraction level of the presented specification is classified as High, since, TGGs
level together with EBNF grammars are a declarative approach to specify the T2T trans-
formation.
Hermann et. al. 5
5 Conclusion
The paper provides a T2T transformation solution to the FIXML2Code case study of the TTC 2014 by
using the EMF tools Xtext and HenshinTGG. Xtext is used to parse FIXML content to an AST and to
serialise Java ASTs to Java source code. HenshinTGG is used to perform the main task of translating
FIXML ASTs into Java ASTs based on the formal concept of TGGs. This allowed the use of existing
formal results in order to ensure syntactical correctness of the translation. The approach was evaluated
based on a given set of fixed criteria which enables a comparison with other solutions to the case study.
The following extensions to the solution were proposed by the case study [8]. The presented approach
is flexible enough to cover these extensions.
(1) Selection of appropriate data types: In order to enable a distinction between data types in
FIXML ASTs, parser rule Attribute of the FIXML grammar must be modified with (valueS = STRING|
valueI = INT| . . .) for value = STRING. For each possible XML attribute type, two separate transfor-
mation rules must be defined such that XML attributes are transformed to member variables of correct
types in the source code.
(2) Generic transformation: The solution generates Java classes from FIXML sample files that re-
flect the general structure of FIXML files. A generation of classes based on FIXML schema definitions
is more appropriate in order to obtain a source code representation of the general structure. The pre-
sented approach can be adopted, since, Eclipse supports the automatic generation of EMF meta-models
from XML schemas which serve as meta-models for input ASTs, i.e., no Xtext grammar for parsing is
required. The Xtext grammar for serialisation does not need to be modified but the triple rules need to
be adapted accordingly to the new input EMF meta-model.
References
[1] The Eclipse Foundation (2012): Xtext – Language Development Framework – Version 2.2.1. Available at
http://www.eclipse.org/Xtext/.
[2] The Eclipse Foundation (2013): EMF Henshin – Version 0.9.4. Available at http://www.eclipse.org/
modeling/emft/henshin/.
[3] H. Giese, S. Hildebrandt & S. Neumann (2010): Model Synchronization at Work: Keeping SysML and AU-
TOSAR Models Consistent. In G. Engels, C. Lewerentz, W. Schäfer, A. Schürr & B. Westfechtel, editors:
Graph Transformations and Model-Driven Engineering, LNCS 5765, Springer, pp. 555–579.
[4] J. Greenyer & J. Rieke (2012): Applying Advanced TGG Concepts for a Complex Transformation of Sequence
Diagram Specifications to Timed Game Automata. In A. Schürr, D. Varró & G. Varró, editors: Applications of
Graph Transformations with Industrial Relevance, LNCS 7233, Springer, pp. 222–237.
[5] F. Hermann, H. Ehrig, U. Golas & F. Orejas (2010): Efficient Analysis and Execution of Correct and Complete
Model Transformations Based on Triple Graph Grammars. In: MDI 2010, ACM, pp. 22–31.
[6] F. Hermann, S. Gottmann, N. Nachtigall, H. Ehrig, B. Braatz & T. Engel (2014): Triple Graph Grammars
in the Large for Translating Satellite Procedures. In: Theory and Practice of Model Transformations, LNCS
7909, Springer, pp. 50–51.
[7] S. Hildebrandt, L. Lambers, H. Giese, J. Rieke, J. Greenyer, W. Schäfer, M. Lauder, A. Anjorin & A. Schürr
(2013): A Survey of Triple Graph Grammar Tools. ECEASST 57.
[8] K. Lano, S. Yassipour-Tehrani & K. Maroukian (2014): Case study: FIXML to Java, C# and C++. In: 7th
Transformation Tool Contest (TTC 2014), this volume, WS-CEUR.
[9] A. Schürr & F. Klar (2008): 15 Years of Triple Graph Grammars. In H. Ehrig, R. Heckel, G. Rozenberg &
G. Taentzer, editors: Graph Transformations, LNCS 5214, Springer, pp. 411–425.
6 FIXML2Code with HenshinTGG
A Triple Graph Grammars
We briefly review some basic notations for TGGs. Note that the case study of this paper does not use
the backward transformation (source code to FIXML), but the forward transformation only. However,
TGGs still provide an intuitive framework that supports the designer to keep the transformation concise,
flexible and maintainable.
The correspondences between elements of a FIXML AST and an AST of source code are made
explicit by a triple graph. A triple graph is an integrated model consisting of a source model (FIXML
AST), a target model (AST of source code) and explicit correspondences between them. More precisely,
it consists of three graphs GS , GC , and GT , called source, correspondence, and target graphs, respectively,
together with two mappings (graph morphisms) sG : GC → GS and tG : GC → GT . The two mappings
specify a correspondence relation between elements of GS and elements of GT .
The correspondences between elements of FIXML ASTs and elements of ASTs of source code are
specified by triple rules. A triple rule tr = (trS , trC , trT ) is an inclusion of triple graphs tr : L → R from
sL C tL sR tR
the left-hand side L = LS ← −L −
− → LT to the right-hand side R = RS ← − RC −
− → RT with (tri : Li →
i C S C T
R )i∈{S,C,T } , sR ◦ tr = tr ◦ sL and tR ◦ tr = tr ◦ tL . This implies that triple rules do not delete, which
ensures that the derived operational rules for the translation do not modify the given input. A triple rule
specifies how a given consistent integrated model can be extended simultaneously on all three compo-
nents yielding again a consistent integrated model. Intuitively, a triple rule specifies a fragment of the
source language and its corresponding fragment in the target language together with the links to relevant
context elements. A triple rule tr : L → R is applied to a triple graph G via a match morphism m : L → G
resulting in the triple graph H, where L is replaced by R in G. Technically, the transformation step is
tr,m
defined by a pushout diagram [11] and we denote the step by G ===⇒ H. Moreover, triple rules can be
extended by negative application conditions (NACs) for restricting their application to specific matches
[5, 12]. Thus, NACs can ensure that the rules are only applied in the right contexts. A triple graph
grammar TGG = (TG, SG, TR) consists of a type triple graph TG, a start triple graph SG and a set TR of
triple rules, and generates the triple graph language L(TGG) ⊆ L(TG) containing all consistent integrated
models. In general, we assume the start graph to be empty in model transformations. For the case study,
the type triple graph consists of the type graph for FIXML ASTs (cf. Fig. 2 (right)) as the source graph,
the type graph for ASTs of source code as the target graph and a correspondence graph containing one
node that maps the model elements from source to target.
Example 1 (Triple Rules) An example of a triple rule of the TGG is presented in Fig. 7. The figure
shows an adapted screenshot of the HenshinTGG tool [2] using short notation. Left- and right-hand side
of a rule are depicted in one triple graph and the elements to be created have the label h++i. The three
components of the triple rule are separated by vertical bars, i.e., the source, correspondence and target
graphs are visualised from left to right. The rule creates a XMLNode in the source and its corresponding
class (class def node) in the target that is linked to an existing Model node as context element. The
correspondence is established via the CORR node. The NAC ClassNameUnique ensures that the rule is
only applicable if there does not already exist a class with the same name. In view of the other rules for
this case study, the depicted rule is of average rule size.
The operational forward translation rules (FT-rule) for executing forward model transformations are
derived automatically from the TGG [5]. A forward translation rule trFT and its original triple rule tr
differ only on the source component. Each source element (node, edge or attribute) is extended by a
Boolean valued translation attribute htri. A source element that is created by tr is preserved by trFT and
Hermann et. al. 7
the translation attribute is changed from htri = f alse to htri = true. All preserved source elements in
tr are preserved by trFT and their translation attributes stay unchanged with htri = true.
Example 2 (Operational Translation Rules) Fig. 8 depicts the corresponding forward translation rule
of the triple rule in Fig. 7. The elements to be created are labelled with h++i and translation attributes
that change their values are indicated by label htri.
A forward model transformation is executed by initially marking all elements of the given source
model GS with htri = f alse leading to G0S and applying the forward translation rules as long as possible.
tr∗
Formally, a forward translation sequence (GS , G0 ===⇒ Gn , GT ) is given by an input source model GS ,
FT
tr∗
FT
a transformation sequence G0 === ⇒ Gn obtained by executing the forward translation rules TRFT on
G0 = (G0S ← ∅ → ∅), and the resulting target model GT obtained as restriction to the target component
of triple graph Gn = (GSn ← GCn → GTn ) with GT = GTn . A model transformation based on forward
translation rules MT : L (TGS ) V L (TGT ) consists of all forward translation sequences with TGS and
TGT being the restriction of the triple type graph TG to the source or target component, respectively.
Note that a given source model GS may correspond to different target models GT . In order to ensure
unique results, we presented in [5] how to use the automated conflict analysis engine of AGG [14] for
checking functional behaviour of model transformations.
B Deeper Insights into our Solution
As already introduced in Sec. 1, we applied the general concept for the T2T-translation depicted in
Fig. 1 which is adapted from the approach we presented in [6] for translating satellite procedures. It
consists of the phases parsing, AST-conversion (main phase), and serialisation and is executed using the
Eclipse Modeling Framework (EMF) tools Xtext and HenshinTGG. The Xtext framework supports the
syntax specification of textual domain specific languages (DSLs) and generates an optional formatting
configuration, based on the EBNF (Extended Backus-Naur Form) grammar specification of a DSL. I
addition, the Xtext framework generates the corresponding parser and serialiser. The parser checks that
the input source code is well-formed and the serialiser ensures that the generated output source code
is well-defined. HenshinTGG is an Eclipse plugin supporting the visual specification and execution of
EMF transformation systems, which is used for the main phase (AST conversion). The presented solution
concerns the output language Java only, but the presented solution seems to be flexible enough to enable
a smooth extension of the serialiser to output languages C# and C++.
B.1 Parser for FIXML
In Sec. 3.1, we broached the description of the Xtext EBNF grammar of input DSL FIXML. In this
section, we will complete this explanation.
A XMLNode is an empty-element-tag (hID /i) of name ID and with a number of Attributes (lines 8
& 9) or a start-tag (h< ID >i) of name ID with a number of Attributes together with its corresponding
end-tag (h< /ID >i) (lines 8,10 & 11). IDs are imported by line 2 and allow an arbitrary string as
terminal that starts with a character or an underscore symbol. Note that start-tags and their end-tags
may have different tag names, since, tag and end allow arbitrary IDs. Therefore, we introduce an
additional Xtext constraint that claims that each start-tag has the name of its corresponding end-tag
(xmlnode.tag.equals(xmlnode.end)) Fig. 5.
8 FIXML2Code with HenshinTGG
1 @Check
2 def checkXMLNodeHasStartEndTagsOfSameName(XMLNode xmlnode) {
3 if (xmlnode.end != null && !xmlnode.tag.equals(xmlnode.end)) {
4 error("Start-tag must have the name of its corresponding
5 end-tag.", TTC_XMLPackage.Literals::XML_NODE__END);
6 return;
7 }
8 }
Figure 5: Xtext validator for FIXML syntax - constraint checkXMLNodeHasStartEndTagsOfSameName
XMLNodes may have several child nodes (reference subnodes in line 10) subnodes as well as op-
tional plain text content of type Entry (lines 8-12). An Entry is a terminal that comprises combinations
of the following terminals: IDs, Integers, whitespaces (WS), any character symbol (ANY OTHER), com-
ments and arbitrary STRINGs. An Attribute has a name of type ID and a value of type STRING.
B.2 Serialiser for Java ASTs
1 grammar lu.uni.snt.secan.ttc_java.TTC_Java with org.eclipse.xtext.common.Terminals
2 generate tTC_Java "http://www.uni.lu/snt/secan/ttc_java/TTC_Java"
3
4 Model : imports+=import_* classes+=class_def*;
5 import_ : "import" entry=fully_qualified_name ";";
6 class_def : "class" name=ID "{" initialDeclarations+=stmt*
7 => feature+=feature* "}";
8 feature : stmt | method_def;
9 stmt : (declaration | assignment) ";";
10 declaration : type=ID typeParameter=typeParameter? name=ID
11 "=" defaultValue=exp;
12 typeParameter : ("<" typeP=ID ">");
13 assignment : var=fully_qualified_name "=" exp=exp;
14 fully_qualified_name : (ID ("." ID)*);
15 exp : atom | constructor_call | methodCall;
16 constructor_call : "new" method=methodCall;
17 methodCall : name=ID typeP=typeParameter? "(" ")";
18 method_def : name=ID "(" (args+=argument ("," args+=argument)*)? ")"
19 "{" body=body "}";
20 body : {body} (stmts+=stmt)*;
21 argument : type=ID typeP=typeParameter? name=ID;
22 atom : string_val | int_val | variable_name;
23 variable_name : name=ID;
24 string_val : value=STRING;
25 int_val : value=INT;
Figure 6: Xtext grammar for Java serialiser
Analogously to the parser in Sec. 3.1, the meta-model for Java ASTs (EMF meta-model) and the
serialiser from Java ASTs (EMF model instances) to Java source code are generated from the Xtext
grammar for Java listed in Fig. 6. Note that we only consider that subset of Java which is relevant for
the translation. Java source code may include several imports and class definitions (line 4). A class
contains a name of type ID together with a set of declarations as initialDeclarations and a set
of method definitions (method def) (lines 6 & 7). A declaration contains an ID as type, an optional
generic typeParameter, a variable name of type ID and a defaultValue which can be any expression
(lines 10 & 11). An expression (exp) is either atomic, a constructor call or a method call (line 15). An
Hermann et. al. 9
Figure 7: Triple rule Tag2Class
Figure 8: Triple rule Tag2Class
atomic expression (atom) has a value of type STRING or INT or is the name of a variable (line 22). A
constructor call (constructor call) contains the terminal new together with a method call (line 16).
A method call (methodCall) contains the name of the method and an optional generic typeParameter
(line 17). A method definition (method def) contains a name, a list of arguments and a body (lines 18
& 19). A body is a list of statements (stmt) (line 20). An argument is of a certain type with an optional
generic typeParameter and has a name (line 21).
Adaptations for supporting C# and C++ The distinction which language specific tokens would be
used can be defined in the Xtext formatter specification. Thus, the presented solution seems to be flexible
enough to enable a smooth extension of the serialiser to output languages C# and C++, e.g., in Fig. 6 lines
6 & 7, we can add terminals private : and public : in front of initialDeclarations and feature
to mark the block of variable declarations as private and the block of methods as public in C++.
B.3 M2M Transformation
The main part of the solution involves the specification and execution of the M2M transformation from
FIXML ASTs to source code ASTs. We present core forward translation rules for converting FIXML
ASTs to Java ASTs in this section. Fig. 7 depicts a screenshot of triple rule Tag2Class as specified
in the HenshinTGG tool and Fig. 8 shows the corresponding forward translation rule that is derived
automatically from the triple rule Tag2Class that we specified with HenshinTGG. For all other derived
10 FIXML2Code with HenshinTGG
Figure 9: FT-rule FT Attribute2Attribute
Figure 10: FT-Rule FT Attribute2ExistingAttribute
forward translation rules in this section, the underlying triple rules are not shown explicitly, since, they
can be easily reconstructed from the forward translation rules (cf. Sec. 2).
Forward translation rule FT Tag2Class is already presented in Sec. 3.2.
Rule FT Attribute2Attribute (Fig. 9) takes an XMLNode that is already translated into a class and trans-
lates each XML Attribute with nameXML and valueXML of the XMLNode to a member variable (node of
type declaration) of the class by linking the variable to the class with edge initialDeclarations.
Already translated elements are indicated by labels [tr]. The created member variables name and value
get the same defaultValues (i.e., nameXML and valueXML) as the XML Attribute. The type of
the variable is set to String. Furthermore, the constructor of the class is extended by an argument of
type String having the name of the created member variable. The body of the constructor is extended
by an assignment which assigns the argument to the created member variable (assignment node).
Note that HenshinTGG stores the nodes of graphs in lists accordingly to their mapping numbers, i.e.,
the same constructor (node 6 : method def) will always be matched for extension while the other con-
structor (node 5 : method def) stays unmodified and empty. In combination with rules FT Tag2Class
and FT Tag2ExistingClass, this rule will collect all XML attributes of XMLNodes with a certain name
and will append them to the corresponding class as member variables. The constructor is extended cor-
respondingly. The rule is only applicable if there does not yet exist a member variable of the same
nameXML for the class (NAC AttributeNameUnique).
Due to the NAC, only one of these attributes is translated by rule FT Attribute2Attribute, if the
FIXML file contains several XML tags of the same name that share XML attributes of the same name.
Rule FT Attribute2ExistingAttribute translates the other Attributes by creating correspondences be-
tween the Attributes and the created member variable (node of type declaration) with CORR nodes
only.
Hermann et. al. 11
Adaptations for supporting C# and C++ The String type in Java is written string in C# which
can be accomplished easily by substituting String by string for type in rule FT Attribute2Attribute.
Similarly, the star symbol for pointers can be added to types in C++. For C++ compilers it is necessary to
declare classes before they are used in other classes. A simple syntactical ordering of classes accordingly
to their usage is not sufficient due to possible circular dependencies between classes. A simple solution
would be to add an empty class declaration (class className;) for each class at the beginning of a
C++ file. Rule FT Tag2Class must be modified so that it additionally creates a declaration node for each
class linked to the Model node. Furthermore, the Java Xtext grammar must be extended by a rule for
declarations such that the declarations precede the class definitions syntactically. A separation of class
declarations and implementations into header and implementation files is also realisable without large
efforts. The forward translation rules would maintain a Model − Header node for the header file and a
Model − Impl node for the implementation file of the classes instead of one Model node only, i.e., C++
EMF model instances would contain not one but two ASTs that can be serialised into separate files.
C Some generated outputs
C.1 Generated Java AST (EMF model instance) for test5.xml.txt
Figure 11: Generated output Java AST (EMF model instance) for test5.xml.txt
C.2 Generated Java source code for test5.xml.txt
1 import java.util.Vector;
2
3 class FIXML {
4 PosRpt PosRpt_object = new PosRpt();
5
6 FIXML() {
7 }
8
9 FIXML(PosRpt PosRpt_) {
10 this.PosRpt_object = PosRpt_;
11 }
12 }
13
12 FIXML2Code with HenshinTGG
14 class PosRpt {
15 String RptID = "541386431";
16 String Rslt = "0";
17 String BizDt = "2003-09-10T00:00:00";
18 String Acct = "1";
19 String AcctTyp = "1";
20 String SetPx = "0.00";
21 String SetPxTyp = "1";
22 String PriSetPx = "0.00";
23 String ReqTyp = "0";
24 String Ccy = "USD";
25 Vector Pty_objects = new Vector();
26 Vector Qty_objects = new Vector();
27 Hdr Hdr_object = new Hdr();
28 Amt Amt_object = new Amt();
29 Instrmt Instrmt_object = new Instrmt();
30
31 PosRpt() {
32 }
33
34 PosRpt(String RptID, String Rslt, String BizDt, String Acct,
35 String AcctTyp, String SetPx, String SetPxTyp, String PriSetPx,
36 String ReqTyp, String Ccy, Vector Pty_list,
37 Vector Qty_list, Hdr Hdr_, Amt Amt_, Instrmt Instrmt_) {
38 this.RptID = RptID;
39 this.Rslt = Rslt;
40 this.BizDt = BizDt;
41 this.Acct = Acct;
42 this.AcctTyp = AcctTyp;
43 this.SetPx = SetPx;
44 this.SetPxTyp = SetPxTyp;
45 this.PriSetPx = PriSetPx;
46 this.ReqTyp = ReqTyp;
47 this.Ccy = Ccy;
48 this.Pty_objects = Pty_list;
49 this.Qty_objects = Qty_list;
50 this.Hdr_object = Hdr_;
51 this.Amt_object = Amt_;
52 this.Instrmt_object = Instrmt_;
53 }
54 }
55
56 class Hdr {
57 String Snt = "2001-12-17T09:30:47-05:00";
58 String PosDup = "N";
59 String PosRsnd = "N";
60 String SeqNum = "1002";
61 Sndr Sndr_object = new Sndr();
62 Tgt Tgt_object = new Tgt();
63 OnBhlfOf OnBhlfOf_object = new OnBhlfOf();
64 DlvrTo DlvrTo_object = new DlvrTo();
65
66 Hdr() {
67 }
68
69 Hdr(String Snt, String PosDup, String PosRsnd, String SeqNum, Sndr Sndr_,
70 Tgt Tgt_, OnBhlfOf OnBhlfOf_, DlvrTo DlvrTo_) {
71 this.Snt = Snt;
72 this.PosDup = PosDup;
73 this.PosRsnd = PosRsnd;
74 this.SeqNum = SeqNum;
75 this.Sndr_object = Sndr_;
76 this.Tgt_object = Tgt_;
77 this.OnBhlfOf_object = OnBhlfOf_;
78 this.DlvrTo_object = DlvrTo_;
Hermann et. al. 13
79 }
80 }
81
82 class Pty {
83 String ID = "OCC";
84 String R = "21";
85 Sub Sub_object = new Sub();
86
87 Pty() {
88 }
89
90 Pty(String ID, String R, Sub Sub_) {
91 this.ID = ID;
92 this.R = R;
93 this.Sub_object = Sub_;
94 }
95 }
96
97 class Qty {
98 String Typ = "SOD";
99 String Long = "35";
100 String Short = "0";
101
102 Qty() {
103 }
104
105 Qty(String Typ, String Long, String Short) {
106 this.Typ = Typ;
107 this.Long = Long;
108 this.Short = Short;
109 }
110 }
111
112 class Amt {
113 String Typ = "FMTM";
114 String Amt = "0.00";
115
116 Amt() {
117 }
118
119 Amt(String Typ, String Amt) {
120 this.Typ = Typ;
121 this.Amt = Amt;
122 }
123 }
124
125 class Instrmt {
126 String Sym = "AOL";
127 String ID = "KW";
128 String IDSrc = "J";
129 String CFI = "OCASPS";
130 String MMY = "20031122";
131 String Mat = "2003-11-22T00:00:00";
132 String Strk = "47.50";
133 String StrkCcy = "USD";
134 String Mult = "100";
135
136 Instrmt() {
137 }
138
139 Instrmt(String Sym, String ID, String IDSrc, String CFI, String MMY,
140 String Mat, String Strk, String StrkCcy, String Mult) {
141 this.Sym = Sym;
142 this.ID = ID;
143 this.IDSrc = IDSrc;
14 FIXML2Code with HenshinTGG
144 this.CFI = CFI;
145 this.MMY = MMY;
146 this.Mat = Mat;
147 this.Strk = Strk;
148 this.StrkCcy = StrkCcy;
149 this.Mult = Mult;
150 }
151 }
152
153 class Sndr {
154 String ID = "String";
155 String Sub = "String";
156 String Loc = "String";
157
158 Sndr() {
159 }
160
161 Sndr(String ID, String Sub, String Loc) {
162 this.ID = ID;
163 this.Sub = Sub;
164 this.Loc = Loc;
165 }
166 }
167
168 class Tgt {
169 String ID = "String";
170 String Sub = "String";
171 String Loc = "String";
172
173 Tgt() {
174 }
175
176 Tgt(String ID, String Sub, String Loc) {
177 this.ID = ID;
178 this.Sub = Sub;
179 this.Loc = Loc;
180 }
181 }
182
183 class OnBhlfOf {
184 String ID = "String";
185 String Sub = "String";
186 String Loc = "String";
187
188 OnBhlfOf() {
189 }
190
191 OnBhlfOf(String ID, String Sub, String Loc) {
192 this.ID = ID;
193 this.Sub = Sub;
194 this.Loc = Loc;
195 }
196 }
197
198 class DlvrTo {
199 String ID = "String";
200 String Sub = "String";
201 String Loc = "String";
202
203 DlvrTo() {
204 }
205
206 DlvrTo(String ID, String Sub, String Loc) {
207 this.ID = ID;
208 this.Sub = Sub;
Hermann et. al. 15
209 this.Loc = Loc;
210 }
211 }
212
213 class Sub {
214 String ID = "ZZZ";
215 String Typ = "2";
216
217 Sub() {
218 }
219
220 Sub(String ID, String Typ) {
221 this.ID = ID;
222 this.Typ = Typ;
223 }
224 }
Appendix References
[10] The Eclipse Foundation (2013): EMF Henshin – Version 0.9.4. Available at http://www.eclipse.
org/modeling/emft/henshin/.
[11] H. Ehrig, K. Ehrig, U. Prange & G. Taentzer (2006): Fundamentals of Algebraic Graph Transformation.
EATCS Monographs in Theoretical Computer Science, Springer.
[12] U. Golas, H. Ehrig & F. Hermann (2011): Formal Specification of Model Transformations by Triple Graph
Grammars with Application Conditions. ECEASST.
[13] F. Hermann, H. Ehrig, U. Golas & F. Orejas (2010): Efficient Analysis and Execution of Correct and Complete
Model Transformations Based on Triple Graph Grammars. In: MDI 2010, ACM, pp. 22–31.
[14] TFS-Group, Technical University of Berlin (2014): AGG – Version 2.0.6. Available at http://user.cs.
tu-berlin.de/˜gragra/agg/.