In this paper, we present a solution to the TTC'20 ofline case Round-trip migration of object-oriented data model instances [1]. This case involves the application of maintenance tasks to web APIs that are associated with domain models so that updates are backward compatible. The solution presented in this article features the EMF-Syncer [2], a synchronization tool for bridging MDE-agnostic programs and MDE-aware programs, which may have some similarities in their object-oriented data models at run time. EMF-Syncer provides a generic synchronization strategy that exploits such similarities automatically and is, therefore, a suitable candidate for solving the proposed problems, since each problem relies on a small change and there is a large overlap between two versions of the same data model. In the paper, we used the case benchmark framework to justify that our solution exhibits a good balance between specification conciseness and performance.
assumes that MDE-agnostic programs are implemented
in a JVM language and that MDE-aware programs
repreThe Round-trip migration of object-oriented data model sent their data model using EMF-generated code.
instances case [
The solution presented in this article features the EMF- synchronization is established, changes that have been
Syncer [
0000-0©002032-12C0op2y4rig-h1t7fo3r 6thi(sApa.peBrboyriotsnauathto)rs. Use permitted under Creative • Renaming of feature types: such renamings may
CPWrEooUrckReshdoinpgs 1IhStpWN:/c1e6u1r3-w-0s.o7r3ge rCCeoEmfemUroRntsoLWictehonsereskAestthrdiboaupttioanPm4r.0ooIncdteeerenladstiioannsagl s(dCoC(CmBYEa4U.i0n)R.m-WoSd.eolrsgi)n [
The solutions to the diferent tasks of the It is important to note that the bidirectional
transforcase are explained below and are available at mation between both data models is completely inferred
https://github.com/emf-syncer/ttc20-roundtrip. The by the EMF-Syncer automatically in this task. In the
solution has been implemented using the language back migration, as the age feature does not exist in the
Xtend [
2.1. Task 1: create/delete field Task1_M2_M1_M2 is achieved by inverting the direction in which the EMF-Syncer is applied to the data In this task, a new feature age is added to the class models, as seen in the listing below. In this case, the data Person in the modified data model 2 and when a model M2 is regarded as the Java program and the data Person instance is migrated, its feature value is set to model M1 as the EMF program. In this case, the value -1. When the instance is migrated back, this information of the age feature of a Person class is preserved on is lost. the back migration because this feature does not exist
The solution Task1_M1_M2_M1, shown in the listing in M1 and, therefore, no changes can be applied to the below, illustrates the pattern used in all of the solutions. feature age. In the following subsections, solutions to The EMF-Syncer is used by instantiating the class symmetric problems are achieved by flipping, as for this EMFSyncer between a source Java package name list task, the direction in which the EMF-Syncer is applied #[’scenario1_v1’] and a target Ecore model in the and are not included in the paper.
18 ] 19 ) 20 21 new (EPackage model1, EPackage model2) { 22 super(model1, model2); 23 syncer = new EMFSyncer(#[’scenario2_v1’], model2,
newArrayList(mapping)) syncer.syncingStrategy = SyncingStrategy.EAGER 24 25 } 26 27 override migrate(EObject instance) { 28 val person_v1 = instance as Person 29 return syncer.syncForward(person_v1) as scenario2_v2.Person 30 } 31 32 override migrateBack(EObject instance) { 33 val person_v2 = instance as scenario2_v2.Person 34 return syncer.syncBack(person_v2) as Person 35 } 36 37 override modify(EObject instance) { } 38 } gets a Person instance from the source data model and returns the ybirth value. When the EMF-Syncer applies the transformation syncForward, the feature value In this task, the feature age of the class Person is re2.3. Task 3: declare field named to ybirth, and its semantics is changed by repreoptional/mandatory senting the age and the year of birth, respectively. This renaming involves domain-specific semantics that is not In this task, the multiplicity of a feature type is modiefid present in the Ecore model, requiring a mapping spec- so that the feature is mandatory in one data model and ification so that the EMF-Syncer can perform the data optional in the modified version. This task exposes a transformation correctly. diference between a MDE-agnostic program, where it
A mapping specification consists of a collection of is not possible to know whether a feature is optional in mappings between feature types by name, ’Person’, plain Java, and a MDE-aware one, where this informa’age’, /* <–> */ ’Person’, ’ybirth’, and by tion is encoded in the Ecore model. As the EMF-Syncer adding optional feature value transformations as lambda treats the source program as a plain Java program, it disreexpressions. For example, in the solution, the lambda gards the information contained in the Ecore model, and expression the logic to transform null values in to empty Strings 1 val person_v1 = it as scenario2_v1.Person needs to be provided in a custom mapping. The ex2 Integer.valueOf(Calendar.getInstance().get(Calendar.YEAR) - pression person_v2.name ?: "" returns an empty person_v1.age) as Object
for Person::ybirth will be obtained by applying this expression. The rest of the solution follows the same structure as the solution explained in §2.1. 1 class Task_2_M1_M2_M1 extends AbstractTask { 2 val EMFSyncer syncer 3 4 // custom mapping strategy: M1 <--> M2 5 val public static mapping = new EMFSyncerMapping( 6 ’Person’, ’age’, /* <--> */ ’Person’, ’ybirth’, 7 // source to target feature value transformation 8 [ 9 10 val person_v1 = it as scenario2_v1.Person Integer.valueOf(Calendar.getInstance().get(Calendar.YEAR) person_v1.age) as Object // target to source feature value transformation [ val person_v2 = it as scenario2_v2.Person 1 class Task_3_M1_M2_M1 extends AbstractTask { 2 val EMFSyncer syncer 3 4 // custom mapping strategy: M1 <--> M2 5 val public static mapping = new EMFSyncerMapping( 6 ’Person’, ’name’, /* <--> */ ’Person’, ’name’, 7 null, 8 // target to source feature value transformation 9 [ 10 val person_v2 = it as scenario3_v2.Person 11 person_v2.name ?: "" 12 ] 13 ) 14 15 new (EPackage model1, EPackage model2) { 16 super(model1, model2); 17 syncer = new EMFSyncer(#[’scenario3_v1’], model2, 18 newArrayList(mapping)) 19 syncer.syncingStrategy = SyncingStrategy.EAGER 20 } 21 22 override migrate(EObject instance) { 23 val person_v1 = instance as scenario3_v1.Person 24 return syncer.syncForward(person_v1) as Person 25 } 26 27 override migrateBack(EObject instance) { 28 val person_v2 = instance as Person 29 syncer.syncBack(person_v2) as scenario3_v1.Person 30 } 31 32 override modify(EObject instance) { 33 val person_v2 = instance as Person 34 syncer.track[ person_v2.name = null ] 35 return person_v2 36 } 37 }
This solution also contains an example of how to track changes performed in the target instance, in the modify method, that need to be migrated back. This change is encoded in the corresponding test case in the original test framework. 2.4. Task 4: multiple edits framework has been adapted in order to work with code generated from Ecore models via EMF, which is required by EMF-Syncer . The main properties (namely, name, nsPrefix and nsUri) of the EPackage in each Ecore model were updated in order to generate disjoint namespaces. In test cases, loading resources for each Ecore model was modified in order to use the corresponding generated factory for each model instance. Model instances, used as input/output data, were modified to refer to the corresponding nsUri. In some cases, the test case also performs a change in the target instance, as in
instance. Such modifications have been encoded in the task itself, in the method modify, as the EMF-Syncer needs to track those changes. Such changes refer to implementation details and do not alter the correctness properties checked2 by the test suite.
and all of them pass the correctness check.
of analysing reuse mechanisms that can be employed. 3.2. Comprehensibility
Task_1, as it is handled by the EMF-Syncer automati- Task solutions have been implemented using Xtend. cally, and it reuses the mapping specification of Task_2, However, the EMF-Syncer can be used from Java prowhich is defined as a static field. The rest of the solution is grams as well. Given that the transformation in most as in §2.1, after renaming the corresponding namespaces. of the solutions is inferred automatically and that so1 class Task_4_M1_M2_M1 extends AbstractTask { lutions use generated code, instead of using the EMF 2 val EMFSyncer syncer reflection API for accessing/mutating values, we argue 43 new (EPackage model1, EPackage model2) { that solutions are likely to be more comprehensible than 5 super(model1, model2); the reference ones. 76 synnecweArrr=anyeLwisEtM(TFaSsykn_c2e_r(M#1_[’Ms2c_eMn1a.mraipop4i_nvg1’)]), model2, When custom mappings are required, e.g. in Task_2 8 syncer.syncingStrategy = SyncingStrategy.EAGER and in Task_4, these are defined by instantiating the 109 } class EMFSyncerMapping, where feature value transfor11 override migrate(EObject instance) { mations are defined as Xtend lambda expressions. Such 1123 rveatlucronnstyaninceerr._svy1nc=Fionrswtaarnd(cceonatsasicneenra_rvi1)o4a_sv1s.Ccoennatraiion4e_rv2. mapping expressions could have been defined similarly
Container in Java as well. 14 } 15 16 override migrateBack(EObject instance) { 17 val container_v2 = instance as scenario4_v2.Container 18 syncer.syncBack(container_v2) as scenario4_v1.Container 19 } 20 21 override modify(EObject instance) { } 22 }
In the solution for most of the tasks, the EMF-Syncer infers both transformations to be applied, syncForward and syncBack, automatically. In such cases, the programmer does not need to provide a transformation specification and a bidirectional data transformation is being used internally so that Java instances can be migrated to an EMF program, and back again, at run time. A custom mapping specification containing only feature type renamings is fully bidirectional. Feature value transformation expressions are unidirectional though.
rectional transformations by default for all of the solutions and accommodates special cases with unidirectional
der to check that the name was migrated back correctly. Comprehensibility
Bidirectionality
Re-usability
ring transformations automatically. That is, when a user does not need to provide a mapping specification, the transformation logic in the EMF-Syncer is reused for any data model change. For example, reuse of the logic transformation in Task_1 falls under this category.
programmer can rely on reuse mechanisms provided by the JVM language of choice. For example, reuse of the transformation logic in Task_2 falls under this category. The mapping specification defined for Task_2 is reused by calling a static field and by using a common interface for the class Person, which has been implemented using inheritance in Task_4.
in the section above, the results are summarized in Ta3.5. Performance ble 1, where the score out of is expressed as ( ).
We have run the performance tests both for the refer- in achieving a competitive trade-of between data migraence solution and for the EMF-Syncer solution on a tion specification and performance. On the one hand, the MacBookPro11,5 Core i7 2.5 GHz, with four cores and automatic inference of data transformations between dif16 GB of RAM. The runtime results (in ms.) obtained ferent object-oriented data models reduces the need for are displayed in Fig. 1. The EMF-Syncer solution ex- specifying data transformations. When these have to be hibits a linear growth with respect to the number of specified, a programmer can rely on their programming iterations, as instructed in the case benchmark. However, skills, using a JVM programming language, for reusing the EMF-Syncer solution is more eficient than the refer- transformation logic. On the other hand, EMF-Syncer ence one thanks to its support for incremental migration can be used as an eficient data migration service at run of changes. While the reference solution takes about 31 s. time. For example, the EMF-Syncer solution is faster for 2 million iterations, the EMF-Syncer solution takes than the reference solution developed in raw Java. EMFabout 9 s, with an improvement factor of 70%. The in- Syncer can be used for building more scalable solutions, cremental propagation relies on a traceability model that involving very large models, by using the pull-based caches relevant data at run time. An analysis of memory model for propagating changes in syncForward only consumption is left for future work as it was not part of when they are required in the target program. the case benchmark.