=Paper= {{Paper |id=Vol-1305/paper1 |storemode=property |title=Case study: FIXML to Java, C# and C++ |pdfUrl=https://ceur-ws.org/Vol-1305/paper1.pdf |volume=Vol-1305 }} ==Case study: FIXML to Java, C# and C++== https://ceur-ws.org/Vol-1305/paper1.pdf

Case study: FIXML to Java, C# and C++

K. Lano, S. Yassipour-Tehrani, K. Maroukian
Dept. of Informatics, King’s College London, Strand, London, UK

This case study is a transformation from financial transaction data expressed in FIXML XML format,
into class definitions in Java, C# and C++. It is based on an industrial application of MDD in finance,
and aims to support rapid upgrading of user software when new or extended FIXML definitions
become available. The transformation involves text-to-model, model-to-model and model-to-text
subtransformations.

1 Introduction
Financial transactions can be electronically expressed using formats such as the FIX (Financial Infor-
mation eXchange) format. New custom variants/extensions of such message formats can be introduced,
which leads to problems in the maintainance of end-user software: the user software, written in various
programming languages, which generates and processes financial transaction messages will need to be
updated to the latest version of the format each time it changes. In [2] the authors proposed to address
this problem by automatically synthesising program code representing the transaction messages from a
single XML definition of the message format, so that users would always have the latest code definitions
available. For this case study we will restrict attention to generating Java, C# and C++ class declarations
from messages in FIXML 4.4 format, as defined at http://fixwiki.org/fixwiki/FPL:FIXML Syntax, and
http://www.fixtradingcommunity.org.
The solution transformation should take as input a text file of a message in XML FIXML 4.4 Schema
format, and produce as output corresponding Java, C# and C++ text files representing this data.

2 Core problem
The solution transformation should be broken down into the following subtransformations:
1. XML text to model of XML metamodel (Figure 1)
2. model of XML metamodel to a model of a suitable metamodel for the programming language/languages
under consideration
3. program model to program text.
By using a chain of transformations, greater flexibility and extensibility is supported: language mapping
issues at the abstract syntax level can be separated from concrete syntax mapping, and generation of
text in an additional programming language may involve only the definition of a new model to text
transformation, and possibly the definition of a new/enhanced programming language metamodel and
model-to-model transformation. The XML text to XML model transformation does not need to change.
We have found that a single programming language metamodel and model-to-model transformation is
sufficient for Java, C# and C++.

To appear in EPTCS.
2 Case study: FIXML translation

Figure 1: XML metamodel

Solutions to the case study can devise their own metamodel(s) for the abstract syntax of the target
programming languages. Solutions may use external software for the XML parsing step and/or for the
code generation step, and may use different transformation languages for the 3 subtransformations.
The informal transformation rules mapping from XML to a programming language (eg., Java) are
the following, in terms of concrete syntax:
• (Rule 1): An XML tag is translated to a Java Class:

becomes
class tag1 { .... }
• (Rule 2): XML attributes are mapped to Java attributes:

becomes
class tag1
{ String att1 = "val1"; String att2 = "val2"; }
etc.
• (Rule 3): Nested XML tags become Java member objects:

becomes
class tag1
{ ....
tag2 tag2_object = new tag2();
tag3 tag3_object = new tag3();
}
K. Lano, S. Yassipour-Tehrani, K. Maroukian 3

This rule should also take that case into account where multiple subnodes of the same node with
the same tag name exist: these subnodes may be represented by distinct attributes with the same
tag object type, initialised by specific constructors, or by an array/list of such objects.
In order to improve the utility of the generated program code, constructors should be provided for the
generated classes, which permit initialising of all their features. A default no-argument constructor
should also be provided.

2.1 Test cases
The solutions should be tested on the test cases test1.xml to test8.xml provided. Test cases 1 to
4 represent typical FIXML messages. Tests 5 and 6 are tests of solution efficiency on large messages.
Tests 7 and 8 are examples of invalid XML files which should be rejected by the transformation.
The first test is a simple example of an Order message:

The second test is a more complex example of a Position Report message, which features multiple
subnodes with the same tagname:

4 Case study: FIXML translation

If there are multiple nodes with the same tag, the class representing the tag will have the union of the
instance variables derived from the attributes and subnodes of all these occurrences. For example, Qty is
represented by
class Qty
{ String Type = "SOD";
String Long = "35";
String Short = "0";
...
}
Other sample FIXML messages can be found at http://fixwiki.org/fixwiki/FPL:FIXML Syntax.

3 Extensions
The following enhancements of the transformation can be considered.

3.1 Selection of appropriate data types
In cases where attribute values are integers or doubles, the attributes should be mapped to programming
language instance variables of these types. For example, Strk="47.50" would be mapped to double
Strk = 47.50;.

3.2 Extension to additional languages
Identify how the transformation can be extended to generate C code instead of object-oriented language
code. Implement a version of the transformation which generates C code declarations.

3.3 Generic transformation
The transformation could also be extended to define a generic transformation which maps the FIXMLSchema
definition (http://fixwiki.org/fixwiki/FPL:FIXML Syntax) or DTD (http://www.fixtradingcommunity.org/pg/
structure/tech-specs/fix-version/44) into Java, C# and C++. This mapping would support the comprehen-
sive representation of arbitrary valid FIXML messages as program objects.

References
[1] Botella, P., Burgués, X., Carvallo, J. P., Franch, X., Grau, G., Marco, J., Quer, C., ISO/IEC 9126 in practice:
what do we need to know?, Software Measurement European Forum (SMEF 2004).
[2] M. B. Nakicenovic, An Agile Driven Architecture Modernization to a Model-Driven Development Solution,
International Journal on Advances in Software, vol 5, nos. 3, 4, 2012, pp. 308–322.
K. Lano, S. Yassipour-Tehrani, K. Maroukian 5

A Evaluation criteria
Relevant characteristics and subcharacteristics for evaluation of model transformations can be selected from the
ISO/IEC 9126-1 framework [1]. These characteristics and subcharacteristics can then be further decomposed into
measurable attributes. Table 1 summarizes the chosen characteristics, subcharacteristics and their corresponding
measurable attributes. One attribute may be related to more than one quality factor.

Characteristic Subcharacteristic Attribute
Functionality Suitability Abstraction level
Complexity
Development effort
Execution time
Accuracy Syntactic correctness
Semantic preservation
Reliability Fault tolerance Detection/processing of invalid models
Maintainability Changeability Complexity
Modularity

Table 1: Selected quality characteristics for the evaluation of model transformation approaches

The following are the specific measures which should be evaluated for each solution to this case study:
• Complexity: sum of number of operator occurrences and feature and entity type name references in the
specification expressions
• Accuracy: that the resulting programs are valid in their languages (syntactic correctness), and that they
correctly represent the source XML data structure and elements (semantic preservation). In particular, the
programming language constraint that distinct instance variables of the same class must have distinct names
must be ensured (syntactic correctness).
• Development effort: developer time in person-hours spent in writing and debugging the specification
• Fault tolerance: High if transformation is able to detect invalid input XML and produce accurate error
messages; Medium if erroneous files produce a failed execution with an indication that some error occurred;
Low if such files are processed and output produced without warnings being issued
• Execution time: milliseconds for execution of each of the three stages
• Modularity: 1 − dr where d is the number of dependencies between rules (implicit or explicit calls, ordering
dependencies, inheritance or other forms of control or data dependence) and r is the number of rules.
Abstraction level is classified as High for primarily declarative solutions, Medium for declarative-imperative
solutions, and Low for primarily imperative solutions.
Execution time of the subtransformation implementations includes the loading of models and printing of output
code from the transformation tool(s).