ion power of models. As models, metamodels and model transformations are the heart of MDE, they play a vital role. Nevertheless, existing transformation languages and accompanying tools cannot deal with large models such those used in the elds of astronomy, genetics, etc. The main problems are related to the storage of very large models, the unreasonable time needed to execute the transformation and the impossibility of transforming distributed or streaming models. We tackle this problem by means of incorporating the concurrent and distributed mechanisms that Linda (a mature coordination language for parallel processes) provides into model transformation approaches.
MDE is a relatively new paradigm which has grown in popularity in the last
decade. So to speak, model transformations (MTs) are, together with models
and metamodels, the key of MDE, allowing to systematically manipulate models.
MTs can be classified according to different characteristics [
Because of this increasing variety of MTs scenarios, there exists a wide range
of different languages for developing MTs, each of them comprises different
characteristics [
Lately, the MDE paradigm is being embraced by companies, thus, MTs are
extensively used and the problems being addressed are increasingly complex.
The main reason for its use is that there are scenarios where MDE is the most
appropriate option to solve their problems or necessities. For instance, generating
code or migrating the architecture/software/data is very appropriate for using
MTs. However, state-of-the-art tools and languages have several limitations [
Concurrency They do not support concurrent transformations. Although the machines of nowadays count on several cores, they are not taking advantage of the full IT infrastructure.
Distribution They are not able to deal with models distributed among different machines. Nowadays, and given the trend to move towards Cloud Computing, distribution is really needed for ensuring dynamic scalability.
Streaming They need to read the complete model into memory before starting the transformation and do not allow that the model is a data flow.
The research question we address is “Can the performance of MTs be improved so that MTs are used for industrial practices? ” which leads to the following: (1) Can MTs be executed in parallel? and (2) Can models be distributed and/or stored in the cloud? 2
The scalability problems of loading large models represented by XMI documents
into memory have been already recognized several years ago. One of the first
solutions for EMF models is the Connected Data Objects (CDO)1 model
repository which allows to store models in all kinds of database back-ends such as
traditional relational databases or emerging NoSQL databases. CDO supports
the ability to store and access large-sized models due to the transparent
loading single objects on demand and caching them. If objects are no longer
referenced, they are automatically garbage collected. There are also several emerging
projects that are considering to store very large EMF models, like MongoEMF2
and Morsa [
So far, we are reusing the storage of Gigaspaces Technologies [
Several lines of work consider the transformation of large models. We plan
that our work is focused on out-place model transformations, i.e., loading input
model and producing the output model from scratch by applying all matching
1 http://projects.eclipse.org/projects/modeling.emf.cdo
2 http://code.google.com/a/eclipselabs.org/p/mongo-emf
transformation rules. However, to deal with large models, orthogonal techniques
may be applied. Especially, two scenarios have been discussed in the past that
benefit from alternative execution strategies. First, if an output model already
exists from a previous transformation run for a given input model, only the
changes in the input model are propagated to the output model. Second, if only
a part of the output model is needed by a consumer, only this part is produced
while other elements are produced just-in-time. For the former scenario,
incremental transformations [
Another interesting line of research for executing transformations in parallel
is the work on critical pair analysis [
The performance of model transformations is now considered as an integral
research challenge in MDE. For instance, Amstel et al. [
Our goal is to provide model transformations with concurrency and distribution, addressing the problems of storing and handling large models, distributed models and models which are available as a infinite stream of elements.
Instead of starting from scratch dealing with the partitioning of models into
model slides and its physical location in the set of available machines, we propose
to make use of Linda [
Then we plan to create a model transformation process according to the schema that Figure 1 shows. In the figure we can see two layers, one in the top and another in the bottom, separated by a dotted line. To the user’s only the top layer is visible and he/she will only need to provide the model transformation, the input and output metamodels involved and the input models. The model transformation will be required either in a well-known language such as ATL or QVT or in a new language that we plan to build. The input models may be given as an XMI file, a set of XMI files, a data flow, several data flows, etc. and can be located in a single machine or can be distributed over a set connected machines.
Internally, the system will transform the model transformation given by the user, which is written in what we call a high level model transformation language, to a low level transformation language that supports distribution and concurrency and that makes use of Linda. This low level language as well as the Linda implementation can be, for example, Java code.
Furthermore, the system will translate the input models to the model representation required by the low level transformation and the concrete Linda implementation, i.e., the objects belonging to the models will be transformed into tuples and stored in the input tuple space. This model representation and low level model transformation language will be designed taking into account characteristics as, for example, readability and semantic, but most importantly efficiency.
Once there is data available in the input tuple space and the transformation has been transformed to the low level transformation language the transformation process will start. For it, several threads will be launched and concurrently each thread will execute the following steps: (1) read objects (model elements) from the input tuple space, which can be distributed or not, (2) transform the objects (create the output objects from the input ones), (3) store the output objects in the output tuple space, (4) go back to 1. if there are more objects in the input tuple space. 4
The first step in order to implement model transformations over Linda is to
count on a Linda implementation. So far, we have used the Java implementation
of an in-memory data grid offered by GigaSpaces Technologies [
Our work is still in an early state but so far we have taken several design
decisions. For instance, how to represent models and metamodels as tuples, how
many independent tuples spaces are required, how the elements are distributed
among those tuples spaces, how the transformation rules are executed in parallel,
study the need of encode and store trace links, etc. Some of these points were
presented in [
First of all, as the Linda implementation is in Java, the models and metamodels are represented in Java too. The metamodels are represented by means of Java classes where each meta-class is represented by a Java class and each attribute or reference is a Java field. The inheritance between classes is also represented by Java inheritance. Regarding the models, they are composed of class instances, i.e. Java objects. Furthermore, in order to support EMF, we are working on a code generator that provides the translation from Ecore-based metamodels to the Java classes.
We have decided that our concurrent and distributed model transformation will be an out-place transformation language and for it we consider two different tuples spaces, one of them containing the input models and another containing the output models. The previously mentioned low level transformation language is written in Java too. Nevertheless, we consider to experiment with Scala in addition due to its support for concurrent and functional programming.
As the transformation is executed concurrently, the dependencies among the objects in the models need to be solved. In order to achieve that, we have given to each input object a string attribute with an identifier (ID) which makes it unique. Then, for each relationship between two objects, an attribute with the target object ID is stored in the source object. We also have built a function, F, similar to the resolve methods in current transformation languages, that is able to compute the identifier of the output element given the identifier of the input element. In case of dependencies when transforming an object, counting on F, it is not necessary to wait until the dependent object has been transformed because we can know its ID beforehand and, thus, create the relationship in the output model.
Finally, the last thing to be defined is how to assign the code to execute by
each thread and the objects to transform. So far we have applied the process
farm approach where all the threads execute the same code. Then, every object
to transform is filtered and the corresponding rule (piece of code) is executed.
The problem is that there exist rules which take longer to finish their execution.
Let us suppose the hypothetical situation where our machine has two cores, and
we have a transformation with two rules. If all the objects assigned to the first
thread need to be executed by the heaviest rule and all the objects assigned to
the second thread are executed by the lightest rule, the first core will end very
soon in comparison with the second thread, thus, the performance will not be
the most efficient. The execution time could improve changing the assignment of
objects to the threads. For that we have to work on several points, establishing
metrics to measure the weight of the rules, i.e., the time their execution takes
and creating an algorithm to do the optimal assignment. For the metrics, we
plan to extend the work on the complexity of the OCL expressions [
So far, we have analyzed the existing implementations of Linda and we have adopted the option that best fits our needs. We have also created a metamodel and model representation according to that implementation. Nevertheless, after some experiments, we have realized that, for concrete cases, small variations of this representation might improve the performance. For that, we plan to analyze carefully each scenario and take it into account when translating the models and metamodels given by the user to our representation. Furthermore, we do not discard to change the whole Linda implementation and, thus, the model and metamodels representation in the future if we find some deficiencies that make it an unsatisfactory solution for our requirements or if we find another one more efficient. We neither discard to create our own Linda implementation.
The parallelization of the model transformation execution is in an early stage. As we presented in Section 4, the performance depends on several parameters and we still have to find the optimal configuration for them in order to finish the model transformation execution as quickly as possible.
Until now, we have not worked in the top layer reflected in Figure 1. As next
step, we are developing Higher-order Transformations (HOTs) [
To sum up, we have just reached the first steps but, at the end of this work, we expect to count on a concurrent and distributed model transformation engine.
We plan to make a comparison between our approach and the most well-known
and extended languages (such as ATL, QVT relations, etc.) by mean of executing
the same model transformation over the same set of input models and evaluating
the time they take. Nevertheless, when the input models are big enough to be
transformed by the existing languages, we will have missed the reference to break.
Then, our aim will be to finish the transformation in the shortest possible time.
Some preliminary results of our work can be found in [
We will need a methodology for assessing the quality of model
transformations. With that methodology we will be able to measure the speedup of
transformations, the best and the worst execution times and the kind of runtime
complexities that current model transformations have, i.e., we will know the
complexity class (linear, polynomial, exponential, etc.) with respect to certain
elements such as the model size. One work in this direction is [
An additional problem is that we will need to create or, preferably, to count on big and distributed models to run the transformation. For that, we plan to make use of model repositories such as the case studies used in TTC (Transformation Tool Contest) 3
Another important issue is to check the correctness of the parallel
transformations, i.e., the transformations must be deterministic and the output models
must be the same as in the sequential execution. For this, we plan to use the
Tracts approach [
Acknowledgments This work is funded by Research Project TIN201123795 and by the Universidad de M´alaga (Campus de Excelencia Internacional Andaluc´ıa Tech). I would like to thank to my supervisors, Antonio Vallecillo and Manuel Wimmer, for guiding me throughout this work. 3 http://planet-sl.org/ttc2013