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. Financial transactions can be electronically expressed using formats such as the FIX (Financial Information 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.
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: <tag1 .... /> becomes class tag1 { .... } (Rule 2): XML attributes are mapped to Java attributes: <tag1 att1="val1" att2="val2" /> becomes etc. <tag1 .... > <tag2 ... /> <tag3 ... /> </tag1> becomes class tag1 { String att1 = "val1"; String att2 = "val2"; } (Rule 3): Nested XML tags become Java member objects: class tag1 { ....
tag2 tag2_object = new tag2(); tag3 tag3_object = new tag3(); } 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
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: <?xml version="1.0" encoding="ASCII"?> <FIXML> <Order ClOrdID="123456" Side="2"
TransactTm="2001-09-11T09:30:47-05:00" OrdTyp="2"
Px="93.25" Acct="26522154"> <Hdr Snt="2001-09-11T09:30:47-05:00"
PosDup="N" PosRsnd="N" SeqNum="521"> <Sndr ID="AFUNDMGR"/> <Tgt ID="ABROKER"/> </Hdr> <Instrmt Sym="IBM" ID="459200101" IDSrc="1"/> <OrdQty Qty="1000"/> </Order> </FIXML>
The second test is a more complex example of a Position Report message, which features multiple subnodes with the same tagname: class Qty { String Type = "SOD";
String Long = "35"; String Short = "0"; ... } <Instrmt Sym="AOL" ID="KW" IDSrc="J" CFI="OCASPS" MMY="20031122"
Mat="2003-11-22T00:00:00" Strk="47.50" StrkCcy="USD" Mult="100"/> 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
Other sample FIXML messages can be found at http://fixwiki.org/fixwiki/FPL:FIXML Syntax.
The following enhancements of the transformation can be considered.
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
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
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 comprehensive representation of arbitrary valid FIXML messages as program objects. A
Relevant characteristics and subcharacteristics for evaluation of model transformations can be selected from the
ISO/IEC 9126-1 framework [
Fault tolerance Changeability 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).