This paper presents a solution to the Families to Persons case at the Transformation Tool Contest (TTC) 2017 using the .NET Modeling Framework (NMF). The goal of this case was to bidirectionally synchronize a simple model of family relationships with a simple person register. We propose a solution based on the bidirectional and incremental model transformation language NMF Synchronizations.
f
A C B D Synchronization blocks are a formal tool to run model transformations in a bidirectional way [HB17]. They combine a slightly modified notion of lenses [FGM+07] with incrementalization systems. Model properties and methods are considered morphisms between objects of a category that are set-theoretic products of a type (a set of instances) and a global state space .
A (well-behaved) in-model lens l : A ,! B between types A and B consists of a side-effect free Get morphism l %2 M or(A; B) (that does not change the global state) and a morphism l &2 M or(A B; A) called the Put function that satisfy the following conditions for all a 2 A; b 2 B and ! 2 :
l & (a; l % (a)) = (a; !) l % (l & (a; b; !)) = (b; !~) for some !~ 2 :
The first condition is a direct translation of the original PutGet law [FGM+07]. 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 S is an octuple (A; B; C; D; A C ; B D; f; g) that declares a synchronization action given a pair (a; c) 2 A C : A = C of corresponding elements in a base isomorphism A C . For each such a tuple in states (!L; !R), the synchronization block specifies that the elements (f % (a; !L); g % (b; !R)) 2 B D gained by the lenses are in the dependent isomorphism B D.
A schematic overview of a synchronization block is depicted in Figure 1. The usage of lenses allows these declarations to be enforced automatically in both directions. The engine simply computes the value that for example the right selector should have and enforces it using the Put operation. An unidirectional specification is also possible where f is no longer required to be a lens. More details can be found in previous publications [HB17].
A multi-valued synchronization block is a synchronization block where the lenses f and g are typed with collections of B and D, for example f : A ,! B and g : C ,! D where stars denote Kleene closures.
Synchronization Blocks have been implemented in NMF Synchronizations, an internal DSL hosted by C# [HB17, Hin15]. 3
To solve the FamiliesToPersons case, we see two correspondencies that need to be synchronized: 1. All family members contained in a family need to be synchronized with the people in the Persons model and 2. The full name of family members that consists of the name of the family and the name of the family member needs to be synchronized with the full name of the corresponding person.
Using synchronization blocks, these correspondences can be formulated in the diagrams of Figure 2. In the internal DSL of NMF Synchronizations, the implementation is depicted in Listing 1.
1http://github.com/georghinkel/benchmarx
F amilyRegisterT oP ersonRegister
MemberT oMember (a) Synchronization block to synchronize family members with person elements
MemberT oMember
:GetF ullN ame()
:N ame string
Idstring
string (b) Synchronization block to synchronize names
In particular, the definition of the synchronization blocks in Listing 1 are implemented in a call to the methods Synchronize and SynchronizeMany. The types and the base isomorphisms FamilyRegisterToPersonRegister and MemberToMember used in the synchronization block can be inferred from the context and the explicitly specified dependent synchronization rule MemberToMember. In the second synchronization block, the identity on strings is used as isomorphism.
While NMF is able to convert the simple member accesses for the persons into lenses, this does not hold for the helpers FamilyMemberCollection and GetFullName that we used in this implementation. Therefore, we have to explicitly provide an implementation of Put for these two items.
For the GetFullName-method, the Put operation needs to be specified through an annotation. In addition, because NMF does not parse the contents of a method (only of lambda expressions), we need to specify an explicitly incrementalized version of the given helper method. To do this, we can reuse the implicit incrementalized lambda expression and also use that for the batch implementation to avoid code duplication. A sketched implementation is depicted in Listing 2. 1 private static ObservingFunc < IFamilyMember , string > fullName = 2 new ObservingFunc < IFamilyMember , string >( m => 3 m. Name == null ? null : (( IFamily )m. Parent ). Name + " ,␣" + m. Name ); 4 5 [ LensPut ( typeof ( Helpers ) , " SetFullName ")] 6 [ ObservableProxy ( typeof ( Helpers ) , " GetFullNameInc ")] 7 public static string GetFullName ( this IFamilyMember member ) { 8 return fullName . Evaluate ( member ); 9 } 10 public static INotifyValue < string > GetFullNameInc ( this IFamilyMember member ) { 11 return fullName . Observe ( member ); 12 } 13 public static void SetFullName ( this IFamilyMember member , string newName ) { 14 ... 15 }
Listing 2: Implementation of the GetFullName lens
In the case of FamilyMemberCollection which as the name implies is a collection, we only have to provide the formula how the results of this collection are obtained and implement the methods Add, Remove and Clear. A schematic implementation is depicted in Listing 3. 1 private class FamilyMemberCollection : CustomCollection < IFamilyMember > { 2 public FamilyRegister Register { get ; private set ; } 3 public FamilyMemberCollection ( FamilyRegister register ) 4 : base ( register . Families . SelectMany ( fam => fam . Children . OfType < IFamilyMember >() )) 5 { Register = register ; } 6
However, to add a family member to a family, the Add method has to know the family name of a person as well as its gender – information that is encoded using the containment hierarchy in the Families model and therefore unavailable before the element is added to a family. Therefore, we carry this information over from the corresponding element of the Person metamodel using a temporary stereotype: In NMF, all model elements are allowed to carry extensions. We use this to add an extension that specifies the last name and whether the given element is male. The stereotype is deleted as soon as a family member is added to a family.
Furthermore, the fact that different genders are modeled through different classes in the Persons model, the synchronization rule MemberToMember needs to be refined to allow NMF Synchronizations to decide whether to create a Male or Female output element. This can be done in NMF Synchronizations through an instantiating rule.
The implementation of both of these concepts is depicted in Listing 4.
The actual transformation consists of 196 lines of which 73 are either empty or consist only of a single brace and whitespaces. We therefore think that our solution is very concise.
The solution passes all batch test cases defined in the test suite. For the incremental test cases, there are still some failures, but these are not due to the inabilities of the transformation but rather due to inaccurate change models: A move for example is transcribed as a deletion and an addition. However, for a new family member, NMF Synchronization will not reuse the Person element for the deleted member and thus, the information on the birthday is lost. Unfortunately, detecting a move and distinguishing it from deleting an element and inserting a new one is more complex and so far, we did not implement such a case distinction for the TTC.2
Due to the fact that the NMF solutions does not use EMF and does not use Java, there is a large serialization overhead attached to it. Depending on the test case, this overhead can outweigh the change propagation by multiple orders of magnitude. Thus, we adjusted the time measurement for our solution to eliminate this overhead.
The results for the incremental scalability test cases for NMF and the fastest reference solutions eMoflon and BXtend recorded on an Intel i7-4710MQ clocked at 2.50Ghz in a system with 16GB RAM is depicted in Figure 3. The plot shows the time to add a family member or a person in a model of the given number of families (each consisting of five members). Both axes are logarithmic. We only depicted the times for the fastest reference solutions as other provided reference solutions were much slower.
In the results for the Incremental Forward scenario, we can see that the resulting curve for the NMF solution is flat meanwhile the curve for eMoflon and BXtend is not. This indicates that unlike the other two, the NMF solution is the only fully incremental solution as the time to add a new family member does not depend on the size of the model. Furthermore, even for the smallest model with only 10 families, the incremental update 2Even without this case distinction, the class to convert EMF notifications to model changes in the NMF format is already more complex than the entire model synchronization. (a) Incremental Forward
(b) Incremental Backward is faster than recomputing the Persons model from scratch. For the largest size, this leads to a speedup of more than three orders of magnitude.
The results for the Incremental Backward benchmark in the opposite direction are depicted in Figure 3b. Unlike the incremental forward where the scalability tests inserts a new family member and the propagation simply adds the corresponding person which can be done in amortized O(1), the incremental backward test has to look for a suitable family, which implies a (n) complexity. Therefore, the speedups in this case do not grow equally with the size. Instead, a saturation happens at a speedup of slightly more than one order of magnitude. 5
In this paper, we applied the bidirectional and incremental model transformation language NMF Synchronizations to the Families to Persons synchronization example. The solution demonstrates the easy adaptation of NMF Synchronizations by providing custom lens implementations.
Our solution is a live transformation that runs on the .NET platform, not on a JVM, and therefore requires a serialization and deserialization overhead to communicate with the benchmark driver. After eliminating this overhead, the results show that our solution is fully incremental and is faster than BXtend and eMoflon in the incremental scalability tests by multiple orders of magnitude. [ABW17]
Anthony Anjorin, Thomas Buchmann, and Bernhard Westfechtel. The Families to Persons Case. In Antonio Garcia-Dominguez, Georg Hinkel, and Filip Krikava, editors, Proceedings of the 10th Transformation Tool Contest, a part of the Software Technologies: Applications and Foundations (STAF 2017) federation of conferences, CEUR Workshop Proceedings. CEUR-WS.org, July 2017. [HB17] [Hin15]
Georg Hinkel and Erik Burger. Change Propagation and Bidirectionality in Internal Transformation DSLs. Software & Systems Modeling, 2017.
Georg Hinkel. Change Propagation in an Internal Model Transformation Language. In Dimitris Kolovos and Manuel Wimmer, editors, Theory and Practice of Model Transformations: 8th International Conference, ICMT 2015, Held as Part of STAF 2015, L’Aquila, Italy, July 20-21, 2015. Proceedings, pages 3–17, Cham, 2015. Springer International Publishing.
Georg Hinkel. NMF: A Modeling Framework for the .NET Platform. Technical report, Karlsruhe Institute of Technology, Karlsruhe, 2016.
David Hearnden, Michael Lawley, and Kerry Raymond. Incremental model transformation for the evolution of model-driven systems. In International Conference on Model Driven Engineering Languages and Systems, pages 321–335. Springer, 2006.