In this paper, we propose a solution based upon Umple for data transformation of Financial Information eXchange protocol (FIXML). The proposed solution includes syntactic and semantic analysis and automatic code generation. We discuss our solution based on development effort, modularity, complexity, accuracy, fault tolerance, and execution time factors. We have applied our technique to a set of FIXML test cases and evaluated the results in terms of error detection and execution time. Results reveal that Umple is suitable for the transformation of FIXML data to object-oriented languages.
Accuracy of information elicited via financial data processing is crucial to decision makers and portfolio
managers in financial domains [
Hence, this paper provides a transformation solution to financial transactions expressed in a FIXML
format. Our transformation approach reverse engineers FIXML data into Umple model which is
translated later into targeted object-oriented languages. In our transformation, Umple is seen as M1 level in
which Umple classes representing the FIXML schema. Umple [
The rest of this paper is organized as follows. In Section 2, we present why Umple has been chosen
for this transformation. Section 3 describes our solution based upon parsing, analysis, and code
generation. We will focus on the evaluation of our work and results in Section 4. Finally, we will present the
conclusions in Section 5.
Umple [
To address the challenge, we added an extension to Umple to parse FIXML documents and to process them such that they become instances of Umples own internal metamodel. We use Umples mixin capability to inject the algorithm for analysis of the FIXML input into Umple. The mixin capability helps us not to alter base Umple code but to create the FIXML extension as a separate concern. The Umple mixin mechanism automatically adds the algorithm to the core of Umple.
The first step in our process is to create a valid model from a FIXML document. To achieve this, we need to perform a syntactic and sematic validation of FIXML documents. We validated FIXML documents in two phases. In the first phase, our parser verifies that we have a syntactically valid FIXML document. Then, it produces an internal syntax tree but does not cover semantic checking yet. In the second phase, we do semantic checking for FIXML documents. This validates that we have the same opening and ending tag names. In the second step of having a valid model, Umple meta-model which adds semantic constraints guarantees that we have a valid model and also generates completely valid code for target programming languages.
For syntactic validation, we have defined a set of grammars to parse FIXML documents. The FIXML
grammar can be accessed at [
In our solution, we consider tag attributes to be Umple attributes for the model. In the process of
analysis, we detect the type of attributes (Integer, Double, and String) and use the correct Umple types for
these attributes. On the other hand, whenever we are unable to detect correct types, we assigned a String
type. With this we are able to have a correct and robust model and code generation. We also are able to
detect the errors in the values of attributes. Moreover, we automatically create related set and get methods
for those attributes. We defined attributes with private visibility and generated automatically related set
and get methods so as to support data encapsulation. For example, Listing 1 shows a FIXML document
in which there is a tag with three attributes. According to the values of attributes, we have two integer
attributes and a float attribute. The generated code for the FIXML document in Listing 1 is represented
in Listing 2. We removed here set and get methods and other codes (such as constructors, delete, toString
etc.) due to space limitation. All generated code can be obtained online through UmpleOnline [
1 class Order { 2 private int ClOrdID , Side ; 3 private double Px ; 4 // The rest of code }
In [
Listing 3: A sample FIXML document 1 class PosRpt { 2 Pty Pty_object_1 = new Pty (" OCC " ," 21 " ); 3 Pty Pty_object_2 = new Pty (" 99999 " ,"4" ); 4 Pty Pty_object_2 = new Pty ("C" ," 38 " ); 5 PosRpt ( Pty Pty_1 , Pty Pty_2 , Pty Pty_3 ){ 6 this . Pty_object_1 = Pty_1 ; 7 this . Pty_object_2 = Pty_2 ; 8 this . Pty_object_3 = Pty_3 ; 9 } 10 PosRpt (){ } }
We have addressed this with the concept of association in the model and arrays as inputs for those same objects in the implementation. Listing 5 shows our generated code in which we have just an instance variable and a constructor with a parameter. With this, we resolved the limitation related to the number of parameters in programming languages. In the same vein, we have just an instance variable which helps us not to lose the model-driven meaning of associations even in the code level. It means that we have an instance variable for each association without worries about multiplicity.
Pty_Object = new ArrayList <Pty >(); boolean didAddPty_Object = setPty_Object ( allPty_Object );
4
In this section, we present the results and evaluation of our implementation. The code generated from any given FIXML documents conforms to their native syntax and semantics. We achieved syntactic conformance by invoking static analyzer embedded in Umple compiler. With this approach, we were able to uncover errors and modify our implementation to ensure syntactic correctness of the generated code. In the same vein, we have adopted the concept of associations in order to preserve semantics as expected. With Umple, creation of links by associations ensures that unique names are created for every instance variables of the same class and preserves the underlying semantics.
We raised the level of abstraction, and minimized development time as well as complexity for future changes. We achieved this with the aid of Umple, which is a level higher than general purpose programming languages, for developing our solution. We performed model-driven development and automatic code generation for the solution. This has been achieved with the minimum effort and belief that future extension or modification will require minimum effort too. The approximate development effort for implementation, testing and debugging is 5 man-hour.
The solution is robust and detected malformed FIXML documents provided as test cases [
We have instrumented our compiler with a Timer to measure the time taken to process an input file and produce the target code. Specifically, the Timer measures the time in ms (System.currentTimeMillis()) taken to 1) parses an input file 2) to analyze and build an instance of the Umple metamodel 3) to generate source codes. Table 1 summarizes the executions times in milliseconds, for each of the eight FIXML test cases. It shows that our technique gives good performance results even for larger inputs, as is the case 5
for the test #8. The tests were executed on a machine exhibiting the following characteristics: Intel Core i5-2400 CPU @ 3.10GHz, RAM: 8.00 GB, Win 8 - 64 bits, JRE 7.
In this paper, we proposed and implemented a solution for automatic object-oriented code generation for financial data representation expressed in FIXML. In order to achieve this, we utilized Umple which includes mechanisms for parsing, analysis, and automatic code generation. Extending Umple grammar to support FIXML satisfied the requirement for accurate syntactic and semantic processing of FIXML documents and provision of a flexible way for ongoing modification. Furthermore, the solution provides a real-time visualization for FIXML documents without code generation.