QVTR-XSLT is a tool for design and execution of transformations based on the graphical notation of QVT Relation. In this paper, we present a solution to the ”FIXML to Java, C# and C++” case study of the Transformation Tool Contest (TTC) 2014 using the QVTR-XSLT tool. The ”FIXML to Java, C# and C++” case study of the Transformation Tool Contest (TTC) 2014 addresses the problem of automatically synthesizing program code from financial messages expressed in FIX (Financial Information eXchange) format. The problem can be broken down into three tasks: 1) generating FIX model from FIX text file, 2) producing a model of the program language from the FIX model, and 3) converting the program model to program code of Java, C# or C++. In this paper, the transformation tasks are tackled with QVTR-XSLT [1], a tool that supports editing and execution of the graphical notation of QVT Relations (QVT-R) language [3]. As part of the model transformation standard proposed by the Object Management Group (OMG), QVT-R is a high-level, declarative transformation language. Its graphical notation provides a concise, intuitive, and yet powerful way to define model transformations. In QVT-R, a transformation is defined as a set of relations (rules) between source and target metamodels, where a relation specifies how two object diagrams, called domain patterns, relate to each other. Optionally, a relation may have a pair of when- and where-clauses specified with an extended subset of Object Constraint Language (OCL) to define the pre- and postconditions of the relation, respectively. A transformation may also include queries and functions. Transformations are driven by a single, designated top-level relation. QVTR-XSLT supports the graphical notation of QVT-R and the execution of a subset of QVT-R by means of XSLT [4]. The tool supports unidirectional non-incremental enforcement model-to-model transformations of QVT-R. Features supported include transformation inheritance through rule overriding, traceability of transformation executions, multiple input and output models, and in-place transformations. In addition, we extend QVT-R with additional transformation parameter, conditional relation call and graphical model query [2]. The tool provides a graphical editor in which metamodels and transformations can be specified using the graphical syntax, and a code generator that automatically generates executable XSLT stylesheets for the transformations. A transformation runner is also developed to execute a single or a chain of generated XSLT transformations by invoking a Saxon XSLT processor. It can display the execution time and generate the execution trace if required. The rest of the paper is structured as follows: Section 2 introduces the design of a solution for the case study. We discuss the experimental result and evaluation of the solution against the criteria given in the case specification in Section 3.
Using the graphical editor of QVTR-XSLT, the solution for the case study is designed as a QVT-R transformation model FIXtoLang whose outline is shown in Fig. 1. It consists of 4 metamodels and 4 transformations. Among the metamodels, FIXmodel specifies the structures of both FIX text model and FIX model, OOmodel defines the abstract model for the OO program languages, and the LanguageModel provides the concrete syntax features for each language.
To complete the tasks of the case study, transformation TextToFIX reads a FIX text file and transforms it to a FIX model (task 1, see Section 2.1), which is subsequently converted into an abstract program model by the FIXtoOO transformation (task 2, see Section 2.2). In case of C++, the classes defined in the program model need to be sorted to ensure a class is declared before being called. Transformation SortOO is dedicated to this purpose. For the next task, as QVTR-XSLT is mainly designed for modelto-model transformations, the program model, along with the language concrete feature model, are first transformed to program code represented as an HTML model that conforms to the HtmlMetaModel of Fig. 1. Then, a pre-defined XSLT stylesheet generates a plain text file of the program code from the HTML model (see Section 2.3). This transformation process, the various artifacts and their relation to each other, are shown in Fig. 2. 2.1
XMLNode name : String XMLAttribute name : String value : String
FIXML
ABSNode +attributes 0..*
ABSAttribute 0..* +subnodes <<Relation>>
FIXtoFIX {where=nds=node(); NodeToNode(nds,t);}
{isTopLevel} <<Domain>> : FIXML <<Domain>> t : FIXML
The very first transformation TextToFIX takes as input an XML text file and outputs a model of FIX format. As shown in Fig. 3, we define a single metamodel FIXmodel for both the source and target models. QVTR-XSLT uses simple UML class diagrams to define metamodels, and requires that a model has a unique root element, such as the FIXML shown in the Fig. 3. In the metamodel, two elements, ABSNode and ABSAttribute, specify the structure of the source text model. Their sub-classes, XMLNode and XMLAttribute, defines the metamodel of the target FIX model. Slightly different from the metamodel given in the case specification, we use name property instead of tag to specify the tag of a FIX node.
The transformation itself is simple and straightforward. It starts from the top relation FIXtoFIX (Fig. 4), which matches the FIXML element (the root of the source text model) in its left-hand part, and constructs the root FIXML element of the target model in its right-hand part. In the where clause, function node() is used to obtain all direct subnodes owned by the root of the source model, and another relation NodeToNode is invoked to subsequently map these subnodes. The mapping is mostly one-to-one. 2.2
FIX model to program model transformation
+type
Object order : String
Package
Class Property
Primitive type : Type value : String
OOElement name : String <<enumeration>>
Type String Double
<<Relation>>
AttToProperty
{where=regexp=’[-+]?[
Fig. 5 illustrates the metamodel of the program model, which serves as the target metamodel of the transformation FIXtoOO. The three programming languages share the same abstract syntax definitions. In the metamodel, we define a root element Package that contains a set of Classes. A class owns Properties which could be either of a Primitive type (e.g., String or Double) or an Object of class type. The order property in Object elements indicates the order of an object if there are multiple objects with the same name.
The challenge of the transformation is that in the source model there may be multiple nodes with the same tag name. These nodes are distributed throughout the model, and each of them may have a different set of subnodes. We have to search the whole model to collect all occurrences of this node, union all of their subnodes to obtain a largest set, and convert the set to the properties of corresponding class in the target model. As multiple subnodes with the same tag name may exist within the same node, a function is used to count the order of the subnodes, and store the order in the order property of the Object element.
We tackle the task of Extensions 3.1 (selecting appropriate data types) in the relation that transforms attribute nodes of the source model into primitive properties of target model, as shown in Fig. 6. In the where clause, a regular expression regexp is used in the matches function to decide if the value v is of type Double, otherwise it is of type String. 2.3
Program model to program code transformation This task is comprised of three steps: 1) sorting class declarations of the program model; 2) transforming the program model into an HTML model of a particular programming language; 3) rendering the HTML model to a text file. Sorting program model. For C++, the class declarations should be ordered so that classes are always declared before they are used. We design transformation SortOO for that purpose. It takes OOmodel as the source- and the target metamodel. The transformation adopts a typical bubble sort algorithm. The following function is defined for comparison of the pair of adjacent classes: function Compare(c1:Class, c2:Class) {
result=if c2.#Object.type→includes(c1.name) then c1→union(c2) else c2→union(c1) endif; } where the input parameter c1 is located before c2 in the source model. However, if class c2 does not include any object of type c1, we consider c2 is “smaller” than c1 and swap them.
Program model to HTML model. This transformation OOtoLang takes as input a program model and a feature model, and generates an HTML model for the code of the particular programming language. It calls the sorting function defined in SortOO if needed. The feature model, which conforms to the metamodel LanguageModel, defines the concrete syntax features for each language: <LanguageDef> <LangDef name="Java" this="this." String="String" Double="Double" iniVar="true" nul=’null’ orderClass="false" .../> <LangDef name="C#" this="this." String="string" Double="double" iniVar="true" nul=’null’ orderClass="false" .../> <LangDef name="C++" this="" String="string" Double="double" iniVar="false" nul=’NIL’ orderClass="true" .../> </LanguageDef> In addition, a parameter file is used for the transformation to indicate which language is currently wanted and the file name of the feature model: <parameterRoot> <currentLang>C++</currentLang> <sourceTypedModel name="languageSpec" file="LanguageDef.xml"/> </parameterRoot> HTML model to plain text. A pre-defined simple XSLT stylesheet of about 20 lines of XSLT code is used to convert the HTML model of the program code into a plain text file. 3
Using the QVTR-XSLT code generator, we load the QVT-R transformation model and generate for each transformation a XSLT stylesheet. Some measures of the transformations, such as lines of generated XSLT code, development efforts, and model modularity, are shown in Table 1.
With the transformation runner, we load and execute a batch file that chains all the transformations, as well as individual XSLT transformations, on the examples provided by the case study in a laptop of Intel M330 2.13 GHz CPU, 3 GB memory, and running Windows 7 Home. The sizes of examples and the execution times for generating C++ code are shown in Table 2. The execution time includes loading and saving model files from/to disk. The DTD definition (second line) of test4.xml has to be removed first. Examples test7 and test8 are rejected because they are invalid XML files.
Example
Size (kb) 0.65 0.92 0.56 0.83 5.0 12.4
The generated programs are syntactically correct by checked in the IDEs of corresponding languages. For test1 and test2, comparing the generated programs with the program text files provided by the case study shows equivalent structure. We also manually verify the generated program code with the original XML examples. So there is a high confidence that the transformations produce semantics preserving results. As we can see from Table 2, the solution works well, but the transformation algorithm also needs to be optimized to convert larger models more efficiently.
We presented a solution for the ”FIXML to Java, C# and C++” case study of TTC 2014. Our solution is founded on the standards introduced by OMG and W3C, and makes use of well-known and commonly adopted CASE tools and languages. We hope the case study will help to demonstrate that the graphical notation of QVT-R, a combination of UML object diagrams and essential OCL expressions, as well as the QVTR-XSLT tool, can be efficiently applied to model transformations in practice.