This paper provides a solution to the TTC 2014 FIXML study case. The case requires the implementation of a straightforward mapping from XML messages in the FIXML format to a set of source files implementing the schema of such a message and, optionally, an instantiation with the data from the message. There is a requirement for producing code in a range of programming languages. The biggest challenge for transformation design in this study case is that the same tag may occur in multiple places in the FIXML message, but with a different set of attributes. The generator must merge all of these occurrences into a single representation in the generated code. We demonstrate how the use of symmetric, language-aware code generators relieves the transformation developer almost entirely from considering this requirement. As a result, the transformation specifications we have written are extremely straightforward and simple. We present generation to Java and C#.
1. We use symmetric language-aware aspects [
Our implementation is based on Epsilon [
...
Save to file Generate
Weave Generate
Register
In [
Figure 1 shows an overview of the infrastructure for code generation with symmetric aspects. Crucially, results from the interpretation of code-generation templates are not directly written to a file, but are centrally registered against the name of the file they are meant to produce. Later, all texts registered against the same file name are merged before they are finally written to disk.
For the merging step, we use an implementation of superimposition; specifically, FEATUREHOUSE
[
As a result, more than one code-generation template can contribute to a given file. If each template
is written to be computationally complete, they can be swapped in or out of a transformation workflow
completely independently of each other, giving great flexibility for transformation reuse, but also for
debugging. Because the templates are standard generation templates (written in EGL [
Symmetric language-aware aspects for code generation have been implemented as an extension to EGL and are available from EpsilonLabs.1
1EpsilonLabs is available at http://epsilonlabs.googlecode.com/. The update site for the symmetric aspects for code-generation plugins is http://epsilonlabs.googlecode.com/svn/trunk/org.eclipse.epsilon.egl. symmetric_ao.updatesite.
XML Model :XEMTLLToClass
Class Model :CElaGsLsTSyomJ-aAOv-aCG
Code : Java <<instance-of>> XML MetaModel : Ecore
<<instance-of>>
Class MetaModel : Ecore
We first describe the complete solution for generating Java code, before discussing the changes needed
for generating C# code.
The case specification provided a meta-model for XML documents and to be used as an intermediary
storage format for the FIXML message to be processed. We have encoded the given meta-model in Ecore
and have written a simple EOL [
XMLToClass As a next step, we need to extract the message schema from the concrete message given. In our implementation, this amounts to a very straightforward copying of the XML model into a model of classes and their attributes, differentiating between string-typed and class-typed attributes.2 The resulting model does not describe a schema, but represents the object structure of the message given. The only change made at this step is for the transformation to ensure that attribute names are unique within an object (although not necessarily between different objects of the same class). This will work together with name-based merging to ensure generation of minimal code. Additionally, we also keep track of the top-level element in the object structure.
This transformation is written in ETL [
2Here we would also do any type analysis if we were providing a solution for that additional requirement.
1 topClass
* attributes vnaalmuee :: SSttrriinngg
Type type name : String 1
Note that the transformation does not merge different occurrences of the a tag of the same name into one class definition in the class model. As a result, the model produced may contain multiple classes of the same name. Their definitions will be merged automatically once code has been generated. 3.1.3
ClassToJava The final step of the transformation chain produces Java code from the class model. The template is written in EGL and is extremely straightforward. It consists of a controller template (cf. Listing 4) that instantiates a second template for every class in the model. That second template (cf. Listing 5) simply generates a class skeleton including all attributes and references as well as a default constructor and a constructor for the attributes and references found.
Note that the name of the file to generate is derived from the name of the class in Listing 4. This may lead to multiple versions of the same file being generated. However, the build workflow shown in Listing 6 invokes the template using eglRegister rather than egl, thus registering all generated code in the central registry. Only the call to eglMerge combines all code produced for a particular class. Because elements of the same name are unified in the merging process, the requirement of the study case is implicitly satisfied.
Our code-generation platform is highly customisable. We have implemented a custom merge strategy for attributes in Java code which can merge occurrences of an attribute of type X with occurrences of an attribute of the same name of type List<X>. This has enabled us to support the generation of collectiontyped attributes where multiple attributes / children of the same name are used in a FIXML message.
We also show a modular definition of an additional feature, namely the generation of a main method instantiating the new classes with data from the FIXML message from which they were generated. To this end, we defined two separate code-generation templates: the first (cf. Listing 7) is a controller template identifying the top class in a given class model and invoking the second template for this class. The second template (cf. Listing 8) then generates an empty class body with only a main method with a recursively constructed constructor call in it. Note that because of a limitation in Java we are not generating custom constructors when there are more than 200 attributes in a class. This is to avoid compilation errors, because there is a maximum number of parameters that can be passed to a constructor. 3.2
Transformation to C# C# and Java are quite similar programming languages. The syntax of both languages is based on C/C++. They are both object-oriented and strongly typed languages. In general, the overall structure of C# and Java are almost identical for this FIXML transformation. The only real difference is the need to use ‘using System;’ at the beginning of each file to allow for the use of upper-case ‘String’ as a type name.
Because neither the class model nor the XML model contain any information specific to the target
language, the early transformations can be kept unchanged. Only the final code-generation needs to be
adjusted by 1) using the C#-specific template and 2) changing the language handler for the invocation
of eglMerge to csharp. Language handlers encapsulate language-specific information like the
featurestructure grammar and semantic merge-operators for unparsed blocks. A C# language handler did not
exist in the original version of symmetric aspects for code generation as presented in [
We have presented a solution to the TTC 2014 FIXML case using symmetric aspects for code generation. The key feature of our solution is that our implementation could be largely built language independently and with almost no concern for schema derivation issues. We have not implemented the generator for C++. However, this could be easily realised following the same ideas by adding an appropriate set of code-generator templates.
Tables 1 and 2 show the results for the various metrics requested in the case specification.
Listing 1: LoadXML implementation in EOL generateFor ( XMLDoc . root ); operation generateFor (e : Element ) : XML ! XMLNode { var node : XML ! XMLNode = new XML ! XMLNode ; node . tag = e. tagName ; if (e. getAttributes (). length > 0) { for ( idx in Sequence {1.. e. getAttributes (). length }) { var attr = e. getAttributes (). item ( idx - 1); var xmlAttr : XML ! XMLAttribute = new XML ! XMLAttribute ; node . attributes = node . attributes -> including ( xmlAttr ); xmlAttr . name = attr . nodeName ; xmlAttr . value = attr . nodeValue ; }
} return node ; for ( elt in e. children ) { node . subnodes = node . subnodes
-> including ( generateFor ( elt ));
Listing 2: XMLtoClass implementation in ETL pre { var STRING_TYPE : Classes ! DataType = new Classes ! DataType ; STRING_TYPE . name = " String "; } }
} rule NodeToClass transform s : XML ! XMLNode to t : Classes ! Class { t. name = s. tag ; var uniqueID = new Map ; for ( attr in s. attributes ) { var newAttr = attr . equivalent (); newAttr . name = newAttr . name . getUniqueVersion ( uniqueID ); t. attributes = t. attributes -> including ( newAttr ); for ( elt in s. subnodes ) { var attr : Classes ! Attribute = new Classes ! Attribute ; t. attributes = t. attributes -> including ( attr ); attr . name = elt . tag . getUniqueVersion ( uniqueID ); attr . type ::= elt ; rule AttrToAttr transform s : XML ! XMLAttribute to t : Classes ! Attribute { t. name = s. name ; t. value = s. value ; t. type = STRING_TYPE ; post { var mdl : Classes ! Model = new Classes ! Model ; mdl . topClass ::= getTopNode (); return resultSet . random (); } else {
uniqueID . put (self , 1); } return self + result ;
Listing 3: XMLtoClass implementation in ETL (ctd.) operation getTopNode () : XML ! XMLNode { var resultSet = XML ! XMLNode . all ; for ( node in XML ! XMLNode . all ) {
resultSet = resultSet -> excludingAll ( node . subnodes ); operation String getUniqueVersion ( uniqueID ) : String { var result : Integer = 0; if ( uniqueID . containsKey ( self )) { result = uniqueID . get ( self ); uniqueID . put (self , result + 1);
Listing 4: ClassToJava controller template [% for (cl in Model ! Class . all ()) { var t := TemplateFactory . load (' JavaOneClass . egl '); t. populate (' currentClass ', cl ); t. generate ( tgtdir + cl. name + '. java ');
Listing 5: ClassToJava per-class template package [%= pck %]; public class [%= currentClass . name %] { [% for ( prop : Model ! Attribute in currentClass . attributes ) { %] private [%= prop . type . name %] [%= prop . name %] = [% if ( prop . type . isKindOf ( Model ! DataType )) { %] " [%= prop . value %]" [% } else { %] new [%= prop . type . name %] ()[%}%]; %] }
[% public [%= currentClass . name %]() {} [% if (( not currentClass . attributes -> isEmpty ()) and // Java is not happy with too many parameters ( currentClass . attributes -> size () <= 200)) {%] public [%= currentClass . name %]([% var first = true ; for ( prop : Model ! Attribute in currentClass . attributes ) { if ( not first ) {%] , [%} else { first = false ;} %][%= prop . type . name %] [%= prop . name %][% }%]) { [% for ( prop : Model ! Attribute in
currentClass . attributes ) { %] this .[%= prop . name %] = [%= prop . name %]; [%}%]
Listing 6: Build workflow <target name =" generate - java " depends =" generate - general "> < epsilon . eglRegister
src =" transformations / java / GenerateMain . egl "> <model ref =" classes " as=" Model "/> < parameter name =" tgtdir " value ="${ generate - tgt }/ java /"/> < parameter name =" pck " value ="${ tgtsubdir }. java "/> </ epsilon . eglRegister > < epsilon . eglRegister
src =" transformations / java / ToJava . egl "> <model ref =" classes " as=" Model "/> < parameter name =" tgtdir " value ="${ generate - tgt }/ java /"/> < parameter name =" pck " value ="${ tgtsubdir }. java "/> </ epsilon . eglRegister > < epsilon . eglMerge > <file > < include name ="${ generate - tgt }/ java /*. java " /> < superimpose artifactHandler =" java15 " /> </ file > </ epsilon . eglMerge > </ target >
Listing 7: Java main method controller template for ( mdl in Model ! Model ) { var t := TemplateFactory . load (' JavaMainMethod . egl '); t. populate (' currentClass ', mdl . topClass ); t. generate ( tgtdir + mdl . topClass . name + '. java ');
Listing 8: Java main method template package [%= pck %]; public class [%= currentClass . name %] { public static void main ( String [] args ) { [%= currentClass . name %] top
= [%= currentClass . generateConstructorCall ()%]; operation Model ! Class generateConstructorCall () : String { var result : String = " new " + self . name + " ("; // Java doesn 't like too many parameters if ( self . attributes -> size () <= 200) { var first = true ; for ( attr in self . attributes ) { if ( not first ) {
result = result + ", "; result = result + ")"; return result ;
Complexity Execution time Abstraction level
It is not entirely clear what is meant by an operator or an entity/feature reference in this context, so the below values are approximations: LoadXML – 35 XMLToClass – 61 ClassToJava – 12 (controller template) + 34 (perclass template) + 11 (main-method controller template) + 29 (main-method generation) = 86 ClassToCS – 12 (controller template) + 31 (per-class template) + 11 (main-method controller template) + 26 (main-method generation) = 80 The following times (in milliseconds) were measured when running all test cases on a TravelMate laptop with i5 CPU running at 2.4GHz and 4GB of main memory.
Stage Minimum Average Maximum LoadXML 78 299 1062 XMLToClass 31 304 1451 ClassToCSharp 63 1929 7317
ClassToJava 218 1713 5647 It should be noted that the times shown can vary substantially between runs of the experiment set. The code-generation stage takes the most time, which is in line with the fact that the main processing happens here. Further breakdown of the timing for Java generation reveals the following for the same run as above:
Stage Minimum Average Maximum RegisterJava 109 819 2636
MergeJava 109 894 3011 Medium as this is a declarative-imperative solution. Accuracy Syntactic correctness (cf. Table 3) and semantic preservation are achieved. Uniqueness of attribute names is guaranteed by XMLToClass.
Development effort Approx. 3.5 person hours for Java; approx. 0.5 additional person hours for C#; approx. 1 person hour for a generalised build script (optional).
Fault tolerance High – the transformation accurately reports errors in the XML files.
Modularity Below are approximate values making assumptions about the meaning of ’rule’: LoadXML – 1 1=1 = 0 TestCase 3: [epsilon.xml.loadModel] [Fatal Error] test3.xml:25:3: The element type "Order" must be terminated by the matching end-tag "</Order>".
TestCase 7: [epsilon.xml.loadModel] [Fatal Error] test7.xml:14:12: The element type "Sndr" must be terminated by the matching end-tag "</Sndr>".
TestCase 8: [epsilon.xml.loadModel] [Fatal Error] test8.xml:19:10: The element type "Hdr" must be terminated by the matching end-tag "</Hdr>".