Solving the FIXML Case Study Using Epsilon and Java

ion Level. Our solution combines imperative code in Java and declarative scripts in ETL and EGL. As a result, according to the evaluation criteria [2], the abstraction level of (a) the Java code to launch transformations is low, (b) XML to XML-model transformation is low, (c) XML-model to Object-model transformation is high, (d) Object-model to code transformation is high, and (e) the overall solution is medium Complexity. For the Java code used to take the XML file and create an XML-model, we measure the complexity c as the sum of e, the number of expressions and instructions involved in processing the XML tags and create the corresponding model; rc, the number of references to meta-classes and rp, the number of references to meta-class properties. The corresponding values: a) 18 for e, b) 2 for rc, and c) 8 for rp, provide a complexity of 28 for the first transformation step. For the transformation scripts in ETL and EGL, we measure the complexity c as the sum of e, the number of EOL expressions and functions; rc, the number of references to meta-classes and rp, the number of references to meta-class properties. As a result, the complexity to take the XML-model and create an Object-model was 66 (e = 35, rc = 8, rp = 23), and to take this model in order to create the java code was 76 (e = 24, rc = 3, rp = 49), the C# code was 71 (e = 22, rc = 3, rp = 46), and the C++ code was 112 (e = 41, rc = 6, rp = 64). Finally, the sum of all complexities provides the overall complexity which is 353. Accuracy. According to the evaluation criteria, we consider our solution accurate after performing a set of testing procedures that includes processing the set of FIXML messages provided in the case description and compiling the resulting code using the JDK compiler5 for the Java code, the Mono compiler6 for the .NET code and GCC/MingW7 for the C++ code. Fault tolerance. According to the evaluation criteria [2], our solution is High: it detects erroneous XML files and present information about the error. 5https://jdk7.java.net/download.html 6http://www.mono-project.com/CSharp_Compiler 7http://www.mingw.org/ H. Hoyos, J. Chavarriga & P. Gomez 5 Modularity. Modularity m is measured as m = 1− (d/r), 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. For the XML to XML-model transformation, the Java code consists of a class with event-handler methods, i.e., a class with methods that are invoked during the processing of an XML document. We measure the number of rules as the number of event-handler methods (i.e., r = 4). And, because these methods does not invoke one to the other, we consider that there is not dependencies among these rules (i.e., d = 0). Thus, the modularity corresponds to 1. In ETL, each rule uses an equivalents method to obtain the model elements produced by other rules. We measure the dependencies d as the number of times that the equivalents method is used in all the rules. For instance, the XML-model to Object-model transformation uses only three rules (i.e., r = 3) but all these rules uses the equivalents method four times (i.e., d = 4). Thus, the modularity is −0.33. In EGL, an operation is a reusable text template that can be included as a part of any other template. Thus, we measure r as the number of operations, including the main template, and d as the number of times that an operation invokes another operation. For instance, the Object-model to Java code transformation includes a main template and three operations (i.e., r = 4) and all these operations invoke other operations five times (i.e., d = 5). That means that the modularity corresponds to −0.25. The following table details the measures for modularity of our solution. Element r d Modularity XML to XML-model 4 0 1 XML-model to Object-model 3 4 −0.33 Object-model to code Java 4 5 -0.25 C# 4 5 -0.25 C++ 8 10 -0.25 Table 2: Modularity of each transformation step of the solution Development effort. The effort of developing each element, measured in person-hours, was : 4h for the XML to XML-model transformation, 2h for the XML-model to Object-model step, 2h for the code generation in java, 1h for the generation in c#, and 4h for the code in C++. We must clarify that the first transformation we create was the Object-Model to Java transformation, and we later use that transformation as a foundation to create the transformations for the other languages.