This paper presents a solution to the Roundtrip Engineering case at the Transformation Tool Contest (TTC) 2020. I demonstrate how synchronization blocks can be easily used to specify the relationships in a bidirectional manner. Through a superimposition concept, the migrations can concentrate on those parts of the metamodel that have actually changed. The performance results on the provided model shows that the solution has a very good performance on the provided input models, although these are very small.
The first condition is a direct translation of the original PutGet law. Meanwhile, the second line is a bit weaker than the original GetPut because the global state may have changed. In particular, we allow the Put function to change the global state.
A (single-valued) synchronization block is an octuple (, , , , Φ − , Φ − , , ) that declares a synchronization action given a pair (, ) ∈ Φ − : ∼= of corresponding elements in a base isomorphism Φ − . For each such a tuple in states (, ), the synchronization block specifies that the elements ( (, ), ↗ (, )) ∈ × gained by the lenses and are isomorphic with regard to Φ − .
A schematic overview of a synchronization block is depicted in Figure 1. The usage of lenses allows these declarations to be enforced automatically and in both directions. The engine simply computes the value that the right selector should have and enforces it using the Put operation. Similarly, a multi-valued synchronization block is a synchronization block where the lenses and are typed with collections of and , for example : ˓→ * and : ˓→ * where stars denote Kleene closures.
Synchronization blocks have been implemented in
NMF Synchronizations, an internal DSL hosted by C#
[
Our solution consists of two parts: At first, I describe the solutions to all four of the scenarios using vanilla NMF Synchronizations, that is, using explicit coding. Afterwards, I explain the necessary steps to turn this into a generic solution.
Φ−
The idea of synchronization blocks is to specify the semantic overlap between two metamodels, not their difference. For scenario 1, this overlap consists of the name, which is still the same, and the overlap that the age can be computed from the year of birth or vice versa. This is depicted in Listing 1.
In particular, both aspects of the semantic overlap can be specified with just one line of code each. Here, the calculation of the age from the year of birth (and vice versa which NMF is able to automatically infer) is very simple because the inversion of a subtraction is already built into NMF. However, NMF also allows to specify a custom conversion operation and an appropriate lens to put back the value, in case a metamodel evolution requires more sophisticated adaptions.
As a very simple example, such a conversion is used in scenario 3, because the coalescing operator is not reversible in NMF by default. The implementation of the custom conversion is shown in Listing 2. 3.2. Generic solution The biggest problem that I see with the specific solution is that the identical parts of the metamodel have to be specified over and over again. While of course not a problem for very small metamodels such as the ones in the benchmark, this can become a problem once the idea is applied to big metamodels with hundreds of classes as variable and put the migrated Person model element. for the diference between null values and empty strings one has to create a separate synchronization rule for each rules to house the generated synchronization blocks. For metaclass and a synchronization block for every feature. this, we simply iterate over the classes of the metamodel
The code for generating such synchronization blocks and check whether there is a corresponding class in the for single-valued attributes and references is depicted in new metamodel.
Listing 4. For brevity, we do not handle inheritance, multivalued attributes or references and only check whether an attribute or reference with the same name exists and whether the lower bound is the same (in order to account in scenario 3).
foreach (var oldClass in oldModel.Descendants().OfType<
IClass>()) { var newClass = newModel.Descendants().OfType<IClass>().
FirstOrDefault(c => c.Name == oldClass.Name); if (newClass != null) { var oldMapping = oldClass.GetExtension<MappedType>(); var newMapping = newClass.GetExtension<MappedType>(); if (oldMapping?.SystemType != null && newMapping?.
SystemType != null) { var rule = (SynchronizationRuleBase)Activator.
CreateInstance(typeof(MigrationRule<,>).
MakeGenericType(oldMapping.SystemType, newMapping.SystemType)); yield return rule; } } }
Listing 5: Generating synchronization rules What we need to do is to generate synchronization
Scenario Scenario1Backward Scenario1Forward Scenario2Backward Scenario2Forward Scenario3Backward Scenario3Forward Scenario4Backward Scenario4Forward
1000
Repetitions 1 10 100
With these two artifacts, we get a model synchronization that automatically synchronizes all classes and fea- Figure 2: Performance results for running the Transformatures that have not changed (meaning that a feature with tion step of the solution multiple times. the same name exists), but we still need to specify the semantic overlap that is contained in diferent attributes such as the corespondence between age and year of birth. 5. Conclusion
To do that, we use the superimposition concept that is available in NMF Synchronizations, depicted in List- I think that the NMF solution highlights the advantages ing 6. That is, we inherit from our new migration class model transformations based on synchronization blocks that spawns the synchronization rules to synchronize can ofer in terms of flexibility. A single specification of the unchanged bits and then superimpose this rule by consistency relationships between the evolution steps a more detailed rule that inherits the synchronization of a metamodel sufices to transform instances forwards of unchanged attributes and references (line 5) and add and backwards. Boilerplate rules can be calculated authe synchronization of the age with the year of birth by tomatically while the essential diferences between two subtracting from 2020. evolution steps (the actual migration) is specified manually with the full flexibility. 4. Evaluation One may think that the generic solution and the reflection it performs must lead to a slow solution. However, this is not true because NMF uses the .NET expression compiler under the hood to compile the expressions that are built through reflection. Therefore, the reflection only afects the initialization of such a transformation, the runtime is completely identical.
I ran performance measurements of the solution on a Intel Core i7-8550U CPU on a system with 8GB RAM running Windows 10. The results are depicted in Figure 2. The ifgure shows the required time to synchronize the model changes forward and backward. The sufix indicates the direction that is executed first, i.e. Scenario1Backward means that the V2 version of scenario 1 is migrated back to V1 and then migrated to V2 again, Scenario1Forward means that the V1 version of scenario 1 is migrated to V2 and back to V1 again.
As the figure shows, the solution is generally very fast. If the synchronization is only called once, the effects of just-in-time compilation and assembly loading cause an average of little more than 10ms but if the synchronization is repeated often, the runtime anneals to roughly 10ns per iteration. However, the input model size is also trivially small and therefore, the results are hardly meaningful. A thourough performance evaluation would require larger models that the benchmark did not provide.