Nowadays, model transformations languages and engines use a sequential execution model. This is, only one execution thread deals with the whole transformation. However, model transformations dealing with very large models, such as those used in biology or aerospace applications, require concurrent solutions in order to speed up their performance. In this ongoing work we explore the
use of Linda for implementing a set of basic mechanisms to enable concurrent model transformations, and present our initial results.Proyectos TIN2011-23795, TIN2011-15497-E y Andalucía Tech Campus de Excelencia

Burgueño, Loli

Troya, Javier

Vallecillo-Moreno, Antonio Jesus

English

Nowadays, model transformations languages and engines use a sequential
execution model. This is, only one execution thread deals with the whole
transformation. However, model transformations dealing with very large models,
such as those used in biology or aerospace applications, require concurrent solutions
in order to speed up their performance. In this ongoing work we explore the
use of Linda for implementing a set of basic mechanisms to enable concurrent
model transformations, and present our initial results.Ministerio de Ciencia e Innovación TIN2011-23795Ministerio de Economía y Competitividad TIN2011-15497-

Troya Castilla, Javier

Vallecillo Moreno, Antonio

idUS. Depósito de Investigación Universidad de Sevilla

Concurrent Model Transformations with LindaLoli Burguen˜o, Javier Troya, and Antonio VallecilloGISUM/Atenea Research Group. Universidad de Ma´laga (Spain){loli,javiertc,av}@lcc.uma.esAbstract. Nowadays, model transformations languages and engines use a se-quential execution model. This is, only one execution thread deals with the wholetransformation. However, model transformations dealing with very large models,such as those used in biology or aerospace applications, require concurrent solu-tions in order to speed up their performance. In this ongoing work we explore theuse of Linda for implementing a set of basic mechanisms to enable concurrentmodel transformations, and present our initial results.Key words: Model transformation, concurrency, Linda1 IntroductionModel transformations (MTs) are at the heart of model-driven engineering (MDE), andprovide mechanisms for manipulating and transforming models. MTs provide mech-anisms to specify how output models are produced from input models. They can beclassified according to different characteristics [1]: abstraction level of input and outputmodels, type of language (declarative, imperative and hybrid), directionality, type oftarget model, etc.As far as we are concerned, the engine of the transformation languages available inliterature offer a sequential and non-distributed execution model. Only one executionthread deals with the whole transformation. Furthermore, the transformation can onlybe executed locally in a machine. This solution is inadequate for model transformationsthat deal with very large models, such as those used in biology or aerospace applica-tions, because their performance is rather low. If transformation engines made use ofconcurrent execution models, different parts of a very big model, which are independentfrom each other, could be transformed at the same time by different execution threads.Besides, these independent parts could be distributed in different machines, all sharinga common space for building the output model. This would speed up the transformationprocess and would prevent from loading big models at once, which is normally veryinefficient and a well-known scalability problem of current approaches [2].Linda [3] is a model of coordination and communication among several parallelprocesses operating upon objects stored in and retrieved from shared, virtual and asso-ciative memory. By storing (input and output) models in an associative memory, we canapply a concurrent and distributed approach for transforming models. In this ongoingwork we explore the use of a Linda-based language [4] for implementing a set of basicmechanisms to enable concurrent model transformations.329Jornadas de Ingeniería del Software y Bases de Datos (JISBD) Madrid, 17-20 Septiembre 20132742After this introduction, Section 2 presents our proposed initial approach. Then, inSection 3 we apply it on the Families2Persons case study, and present some perfor-mance results. Finally, Section 4 concludes the paper and outlines how we would liketo continue this work.2 Initial ApproachFor implementing our approach, we have used the Java implementation of an in-memorydata grid offered by Gigaspaces Technologies [5]. It is called XAP Elastic Caching Edi-tion (we will refer to it from here on as XAP) and supports the basic Linda operations,such as read and write, as well as a wide range of new features, like fast data access,performance and scalability. Linda, and consequently XAP, allows several machinesto work simultaneously over a tuple space that can be distributed in a user-transparentmanner. Since Gigaspaces XAP deals with Java code, Java objects can be introducedand extracted from tuple spaces. Internally, XAP serializes the objects before introduc-ing them in a tuple space and deserializes them on extraction.The first things needed to define a MT are the metamodels of the source and targetdomains. In our approach, since we are dealing with Java code, metamodels are repre-sented by Java classes. XAP requires these classes to implement the Java Serializableinterface. Also, getter and setter methods have to be defined in order to have accessto attributes afterwards. Our models, consequently, are composed of instances (objects)of these classes. Transformation languages such as ATL [6] or QVT [7] require meta-models to conform to Ecore [8], which are stored in .ecore files. Models conform tothese metamodels and are typically stored in XML Metadata Interchange (XMI) files.Our java representation can be directly obtained from such models and metamodels bymeans of straightforward model-to-text transformations.With XAP, we can define as many distributed tuple spaces as needed. In our ap-proach, we have two of them, one for storing the input model and the other one forthe output model. The global view of the approach is presented in Figure 1. Differentexecution threads, which may come from different machines, can be reading the inputmodel from the first tuple spaces at the same time. Likewise, several threads can becreating the output model together. By having the model transformation implementedin several machines, we can make the most of the processing capacity of all of thembecause they can be creating different parts of the output model at the same time.The model transformation is written in Java. In the implementation, we can specifyhow many execution threads will be concurrently dealing with the transformation. Inthis way, each thread retrieves a set of elements (objects) from the tuple space contain-ing the input model and apply the transformation over them to create new objects andplace them in the tuple space containing the output model. Consequently, the perfor-mance depends on the processing power. The more cores we have, the more threads canbe working at the same time and the higher the performance will be. We also take intoaccount the possible context switching among threads. This is, the fact that the numberof threads overtakes the number of cores is counter-productive, because threads have tochange from one core to another, and this affects the performance.330Jornadas de Ingeniería del Software y Bases de Datos (JISBD) Madrid, 17-20 Septiembre 20132753Fig. 1. Linda-based transformation schema3 Case StudyThe Families2Persons [9] example is rather small but sufficient for having an overviewof the basics of our approach. Figure 2 shows the Ecore representation for the meta-models.Fig. 2. Family and Person Ecore metamodelsThe transformation aims to transform each element of type Member to an elementof kind Person. In particular, to Female type if the Member is mother or daughter, andto Male if it is father or son. The code executed by each thread is as follows:1 Family[] families = gigaSpaceSrc.takeMultiple(new Family(), numFamilies);23 Person[] people = new Person[numMembers]; int k = 0;45 for (int i = 0; i<families.length; i++){6 if (families[i].getMother() != null){7 people[k] = new Female(families[i].getMother().getName() +" "+ families[i].getLastName()); k++;8 }9 if (families[i].getFather() != null){10 people[k] = new Male(families[i].getFather().getName() +" "+ families[i].getLastName()); k++;11 }12 for (Member m : families[i].getDaughters()){331Jornadas de Ingeniería del Software y Bases de Datos (JISBD) Madrid, 17-20 Septiembre 2013276413 people[k] = new Female(m.getName()+" "+families[i].getLastName()); k++;14 }15 for (Member m : families[i].getSons()){16 people[k] = new Male(m.getName()+" "+families[i].getLastName()); k++;17 }18 }19 gigaSpaceTrg.writeMultiple(people);As we can see in line 1, we read a block of families from the input tuple space. Thenwe iterate over the retrieved families in order to transform (lines 5 − 18) and finallystore (line 19) the new objects in the data element people defined in line 3. Reading andwriting from/in the tuple spaces can be a time-consuming task if they are realized overand over again by the same thread. For this reason, XAP provides the readMultiple andwriteMultiple operations, where a set of elements are read and written at the same time.We have made use of these operations to improve the performance. The idea is that, ifwe have for example 1000 elements in the input tuple space and 10 threads, then eachthread deals with the retrieval, transformation and storage of 100 elements (variablenumFamilies in line 1).The same transformation in ATL is as follows [9]:module Families2Persons;create OUT: Persons from IN: Families;helper context Families!Member def: isFemale(): Boolean = ...helper context Families!Member def: familyName: String = ...rule Member2Male {from s: Families!Member (not s.isFemale())to t: Persons!Male (fullName <- s.firstName + ’ ’ + s.familyName )}rule Member2Female {from s: Families!Member (s.isFemale())to t: Persons!Female (fullName <- s.firstName + ’ ’ + s.familyName)}To compare the execution times between the ATL transformation and our Linda-based transformation, we have created several considerably big models with a variablenumber of families composed by 10 members each one. We executed both programs ona machine running Linux with 16 cores, launching that number of execution threads,where each thread deals with the same number of objects. Table 1 presents the results.Table 1. Evaluation resultsNumber of families ATL time Linda time1,000 0.246 s 0.222 s10,000 4.112 s 2.162 s100,000 Exception 9.06 sWe can appreciate that for small models which have around 10,000 members, theexecution times are quite similar. For 100,000 members the execution time has beenhalved. Finally, when we tried to transform 1,000,000 members with the ATL transfor-mation, we obtained the error GC overhead limit exceeded. The problem that caused332Jornadas de Ingeniería del Software y Bases de Datos (JISBD) Madrid, 17-20 Septiembre 20132775this exception is that almost all the time is spent in garbage collection and the ATLprogram is making little or no progress because the Java heap is too small for such aload.4 Conclusions and Future WorkThis paper presents an emergent approach based on Linda for executing model trans-formations concurrently. Due to the distributed nature of Linda, this approach can bealso applied over distributed systems where a model is transformed by several machinessimultaneously, increasing significantly the performance of the transformation process.We have presented a case study where we compare the execution times of our ap-proach with the execution times in ATL. Our approach has proved to be faster for thisparticular example, an does not present the scalability problems that appear in ATL.Nevertheless, this is only the beginning and there are several lines that we still have toexplore.In the first place, we plan to face the task of applying our approach on more complextransformations. For example, we want to implement transformations where internaltraceability links would be needed, and transformations where several output modelsare created from one input model and viceversa. We also want to study how complexOCL expressions and constraints in transformations written in languages such as ATLor QVT would be expressed in our approach.In the second place, we plan to provide a mechanism which transforms persistentmetamodels and models from their original format into Java classes and Java instances.In the same way, after the transformation, the Java instances belonging to the outputmodel will be stored in a file with the corresponding format.Also, and as a more ambitious future line of research, we would like to create ourown concurrent model transformation language. This is, right now we are using Javacode to implement the transformations, but it would be ideal to count on a languagebuilt on top of such implementation. Another possibility is to define a semantic map-ping between some sequential transformation language, such as ATL, and our Linda-based representation, so that transformations written in the former could be executedconcurrently.Acknowledgements. This work is partially funded by Research Projects TIN2011-23795 and TIN2011-15497-E and by Universidad de Ma´laga (Campus de ExcelenciaInternacional Andalucı´a Tech).References1. Czarnecki, K., Helsen, S.: Feature-based survey of model transformation approaches. IBMSyst. J. 45(3) (2006) 621–6452. Jouault, F., Sottet, J.S.: An AmmA/ATL Solution for the GraBaTs 2009 Reverse EngineeringCase Study. In: Fifth International Workshop on Graph-Based Tools - Grabats 2009 (co-located with TOOLS 2009), Zurich, Suisse (2009)333Jornadas de Ingeniería del Software y Bases de Datos (JISBD) Madrid, 17-20 Septiembre 201327863. Wells, G.: Coordination languages: Back to the future with linda. In: Proceedings of WCAT05.(2005) 87–984. Wells, G.C., Chalmers, A.G., Clayton, P.G.: Linda implementations in java for concurrentsystems. Concurrency and Computation: Practice and Experience 16 (2003)5. GigaSpaces Technologies Ltd. Gigaspaces: (2013) http://www.gigaspaces.com/datagrid.6. Jouault, F., Allilaire, F., Be´zivin, J., Kurtev, I.: ATL: A model transformation tool. Science ofComputer Programming 72(1-2) (2008) 31–397. OMG: MOF QVT Final Adopted Specification. Object Management Group. (2005) OMGdoc. ptc/05-11-01.8. Budinsky, F., Merks, E., Steinberg, D.: EMF: Eclipse Modeling Framework (2nd Edition).Addison-Wesley Longman, Amsterdam (2006)9. Eclipse: (2012) http://wiki.eclipse.org/ATL/Tutorials\_-\_Create\_a\_simple\_ATL\_transformation.334Jornadas de Ingeniería del Software y Bases de Datos (JISBD) Madrid, 17-20 Septiembre 2013279

Concurrent Model Transformations with Linda

Burgueño-Caballero, Lola

Troya-Castilla, Javier

Vallecillo-Moreno, Antonio Jesús

Repositorio Institucional Universidad de Málaga

Concurrent Model Transformations with LindaLoli Burguen˜o, Javier Troya, and Antonio VallecilloGISUM/Atenea Research Group. Universidad de Ma´laga (Spain){loli,javiertc,av}@lcc.uma.esAbstract. Nowadays, model transformations languages and engines use a se-quential execution model. This is, only one execution thread deals with the wholetransformation. However, model transformations dealing with very large models,such as those used in biology or aerospace applications, require concurrent solu-tions in order to speed up their performance. In this ongoing work we explore theuse of Linda for implementing a set of basic mechanisms to enable concurrentmodel transformations, and present our initial results.Key words: Model transformation, concurrency, Linda1 IntroductionModel transformations (MTs) are at the heart of model-driven engineering (MDE), andprovide mechanisms for manipulating and transforming models. MTs provide mech-anisms to specify how output models are produced from input models. They can beclassified according to different characteristics [1]: abstraction level of input and outputmodels, type of language (declarative, imperative and hybrid), directionality, type oftarget model, etc.As far as we are concerned, the engine of the transformation languages available inliterature offer a sequential and non-distributed execution model. Only one executionthread deals with the whole transformation. Furthermore, the transformation can onlybe executed locally in a machine. This solution is inadequate for model transformationsthat deal with very large models, such as those used in biology or aerospace applica-tions, because their performance is rather low. If transformation engines made use ofconcurrent execution models, different parts of a very big model, which are independentfrom each other, could be transformed at the same time by different execution threads.Besides, these independent parts could be distributed in different machines, all sharinga common space for building the output model. This would speed up the transformationprocess and would prevent from loading big models at once, which is normally veryinefficient and a well-known scalability problem of current approaches [2].Linda [3] is a model of coordination and communication among several parallelprocesses operating upon objects stored in and retrieved from shared, virtual and asso-ciative memory. By storing (input and output) models in an associative memory, we canapply a concurrent and distributed approach for transforming models. In this ongoingwork we explore the use of a Linda-based language [4] for implementing a set of basicmechanisms to enable concurrent model transformations.2After this introduction, Section 2 presents our proposed initial approach. Then, inSection 3 we apply it on the Families2Persons case study, and present some perfor-mance results. Finally, Section 4 concludes the paper and outlines how we would liketo continue this work.2 Initial ApproachFor implementing our approach, we have used the Java implementation of an in-memorydata grid offered by Gigaspaces Technologies [5]. It is called XAP Elastic Caching Edi-tion (we will refer to it from here on as XAP) and supports the basic Linda operations,such as read and write, as well as a wide range of new features, like fast data access,performance and scalability. Linda, and consequently XAP, allows several machinesto work simultaneously over a tuple space that can be distributed in a user-transparentmanner. Since Gigaspaces XAP deals with Java code, Java objects can be introducedand extracted from tuple spaces. Internally, XAP serializes the objects before introduc-ing them in a tuple space and deserializes them on extraction.The first things needed to define a MT are the metamodels of the source and targetdomains. In our approach, since we are dealing with Java code, metamodels are repre-sented by Java classes. XAP requires these classes to implement the Java Serializableinterface. Also, getter and setter methods have to be defined in order to have accessto attributes afterwards. Our models, consequently, are composed of instances (objects)of these classes. Transformation languages such as ATL [6] or QVT [7] require meta-models to conform to Ecore [8], which are stored in .ecore files. Models conform tothese metamodels and are typically stored in XML Metadata Interchange (XMI) files.Our java representation can be directly obtained from such models and metamodels bymeans of straightforward model-to-text transformations.With XAP, we can define as many distributed tuple spaces as needed. In our ap-proach, we have two of them, one for storing the input model and the other one forthe output model. The global view of the approach is presented in Figure 1. Differentexecution threads, which may come from different machines, can be reading the inputmodel from the first tuple spaces at the same time. Likewise, several threads can becreating the output model together. By having the model transformation implementedin several machines, we can make the most of the processing capacity of all of thembecause they can be creating different parts of the output model at the same time.The model transformation is written in Java. In the implementation, we can specifyhow many execution threads will be concurrently dealing with the transformation. Inthis way, each thread retrieves a set of elements (objects) from the tuple space contain-ing the input model and apply the transformation over them to create new objects andplace them in the tuple space containing the output model. Consequently, the perfor-mance depends on the processing power. The more cores we have, the more threads canbe working at the same time and the higher the performance will be. We also take intoaccount the possible context switching among threads. This is, the fact that the numberof threads overtakes the number of cores is counter-productive, because threads have tochange from one core to another, and this affects the performance.3Fig. 1. Linda-based transformation schema3 Case StudyThe Families2Persons [9] example is rather small but sufficient for having an overviewof the basics of our approach. Figure 2 shows the Ecore representation for the meta-models.Fig. 2. Family and Person Ecore metamodelsThe transformation aims to transform each element of type Member to an elementof kind Person. In particular, to Female type if the Member is mother or daughter, andto Male if it is father or son. The code executed by each thread is as follows:1 Family[] families = gigaSpaceSrc.takeMultiple(new Family(), numFamilies);23 Person[] people = new Person[numMembers]; int k = 0;45 for (int i = 0; i<families.length; i++){6 if (families[i].getMother() != null){7 people[k] = new Female(families[i].getMother().getName() +" "+ families[i].getLastName()); k++;8 }9 if (families[i].getFather() != null){10 people[k] = new Male(families[i].getFather().getName() +" "+ families[i].getLastName()); k++;11 }12 for (Member m : families[i].getDaughters()){413 people[k] = new Female(m.getName()+" "+families[i].getLastName()); k++;14 }15 for (Member m : families[i].getSons()){16 people[k] = new Male(m.getName()+" "+families[i].getLastName()); k++;17 }18 }19 gigaSpaceTrg.writeMultiple(people);As we can see in line 1, we read a block of families from the input tuple space. Thenwe iterate over the retrieved families in order to transform (lines 5 − 18) and finallystore (line 19) the new objects in the data element people defined in line 3. Reading andwriting from/in the tuple spaces can be a time-consuming task if they are realized overand over again by the same thread. For this reason, XAP provides the readMultiple andwriteMultiple operations, where a set of elements are read and written at the same time.We have made use of these operations to improve the performance. The idea is that, ifwe have for example 1000 elements in the input tuple space and 10 threads, then eachthread deals with the retrieval, transformation and storage of 100 elements (variablenumFamilies in line 1).The same transformation in ATL is as follows [9]:module Families2Persons;create OUT: Persons from IN: Families;helper context Families!Member def: isFemale(): Boolean = ...helper context Families!Member def: familyName: String = ...rule Member2Male {from s: Families!Member (not s.isFemale())to t: Persons!Male (fullName <- s.firstName + ’ ’ + s.familyName )}rule Member2Female {from s: Families!Member (s.isFemale())to t: Persons!Female (fullName <- s.firstName + ’ ’ + s.familyName)}To compare the execution times between the ATL transformation and our Linda-based transformation, we have created several considerably big models with a variablenumber of families composed by 10 members each one. We executed both programs ona machine running Linux with 16 cores, launching that number of execution threads,where each thread deals with the same number of objects. Table 1 presents the results.Table 1. Evaluation resultsNumber of families ATL time Linda time1,000 0.246 s 0.222 s10,000 4.112 s 2.162 s100,000 Exception 9.06 sWe can appreciate that for small models which have around 10,000 members, theexecution times are quite similar. For 100,000 members the execution time has beenhalved. Finally, when we tried to transform 1,000,000 members with the ATL transfor-mation, we obtained the error GC overhead limit exceeded. The problem that caused5this exception is that almost all the time is spent in garbage collection and the ATLprogram is making little or no progress because the Java heap is too small for such aload.4 Conclusions and Future WorkThis paper presents an emergent approach based on Linda for executing model trans-formations concurrently. Due to the distributed nature of Linda, this approach can bealso applied over distributed systems where a model is transformed by several machinessimultaneously, increasing significantly the performance of the transformation process.We have presented a case study where we compare the execution times of our ap-proach with the execution times in ATL. Our approach has proved to be faster for thisparticular example, an does not present the scalability problems that appear in ATL.Nevertheless, this is only the beginning and there are several lines that we still have toexplore.In the first place, we plan to face the task of applying our approach on more complextransformations. For example, we want to implement transformations where internaltraceability links would be needed, and transformations where several output modelsare created from one input model and viceversa. We also want to study how complexOCL expressions and constraints in transformations written in languages such as ATLor QVT would be expressed in our approach.In the second place, we plan to provide a mechanism which transforms persistentmetamodels and models from their original format into Java classes and Java instances.In the same way, after the transformation, the Java instances belonging to the outputmodel will be stored in a file with the corresponding format.Also, and as a more ambitious future line of research, we would like to create ourown concurrent model transformation language. This is, right now we are using Javacode to implement the transformations, but it would be ideal to count on a languagebuilt on top of such implementation. Another possibility is to define a semantic map-ping between some sequential transformation language, such as ATL, and our Linda-based representation, so that transformations written in the former could be executedconcurrently.Acknowledgements. This work is partially funded by Research Projects TIN2011-23795 and TIN2011-15497-E and by Universidad de Ma´laga (Campus de ExcelenciaInternacional Andalucı´a Tech).References1. Czarnecki, K., Helsen, S.: Feature-based survey of model transformation approaches. IBMSyst. J. 45(3) (2006) 621–6452. Jouault, F., Sottet, J.S.: An AmmA/ATL Solution for the GraBaTs 2009 Reverse EngineeringCase Study. In: Fifth International Workshop on Graph-Based Tools - Grabats 2009 (co-located with TOOLS 2009), Zurich, Suisse (2009)63. Wells, G.: Coordination languages: Back to the future with linda. In: Proceedings of WCAT05.(2005) 87–984. Wells, G.C., Chalmers, A.G., Clayton, P.G.: Linda implementations in java for concurrentsystems. Concurrency and Computation: Practice and Experience 16 (2003)5. GigaSpaces Technologies Ltd. Gigaspaces: (2013) http://www.gigaspaces.com/datagrid.6. Jouault, F., Allilaire, F., Be´zivin, J., Kurtev, I.: ATL: A model transformation tool. Science ofComputer Programming 72(1-2) (2008) 31–397. OMG: MOF QVT Final Adopted Specification. Object Management Group. (2005) OMGdoc. ptc/05-11-01.8. Budinsky, F., Merks, E., Steinberg, D.: EMF: Eclipse Modeling Framework (2nd Edition).Addison-Wesley Longman, Amsterdam (2006)9. Eclipse: (2012) http://wiki.eclipse.org/ATL/Tutorials\_-\_Create\_a\_simple\_ATL\_transformation.

https://idus.us.es/xmlui/bitstream/handle/11441/73761/JISBD13Linda.pdf?sequence=1&isAllowed=y

Concurrent Model Transformations with Linda

Abstract

Similar works

Full text

Available Versions

idUS. Depósito de Investigación Universidad de Sevilla

Repositorio Institucional Universidad de Málaga