A schematic overview of a synchronization block is depicted in Figure 1. The usage of lenses allows this 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 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# [
The check-only mode has been implemented very recently and the BibTex to DocBook case has been the first actual usage. In this mode, the engine will try to match the given model and report inconsistencies. This direction is compatible with incremental execution. However, one-way change propagation is not supported1 (must be two-way or disabled) and the synchronization is required to be bidirectional.
This flexibility makes it possible to reuse the specification of a transformation in a broad range of different
use cases. Furthermore, the fact that NMF Synchronizations is an internal language means that a wide range of
advantages from mainstream languages, most notably modularity and tool support, can be inherited [
When creating a model transformation with NMF Synchronizations, one has to find correspondences between input and target model elements and how they relate to each other. The first correspondence is usually clear and is the entry point for the synchronization process afterwards: The root of the input model is known to correspond to the root of the output model, in our case the BibTeXFile element should correspond to the DocBook element.
For the isomorphism from a BibTex file to a DocBook, we need to override the creation of target models. If the DocBook element is missing, it should be created with the required sections right from the start. For this, the initialization syntax as depicted in Listing 1 can be used.
To synchronize the contents of a BibTexFile with the contents of a DocBook, we need to specify synchronization blocks accordingly. As an example, the synchronization of the BibTex entries with the paragraphs in the references list is depicted in Figure 2. Because the DocBook does not have a direct reference to the references list, we created a helper method to identify the references list.
1The problem here is that the internal DSL of NMF Synchronizations allows a write-only interface for one-way synchronization blocks. Thus, an incrementally maintained list of inconsistencies can only take changes in the source model into account and could therefore produce misleading results which is why the feature has not been implemented, yet. For a bidirectional transformation, this is not a problem, because the list of inconsistencies can always be kept consistent.
Listing 1: Creating the default output model for the DocBook metamodel
BibT exT oDocBook
DocBook
GetSection(Ref erencesList)
ReferenceT oP ara The implementation for the synchronization blocks from Figure 2 is depicted in Listing 2. In particular, line 1 defines the isomorphism BibT exT oDocBook, lines 3-5 implement the synchronization block from Figure 2.
NMF Synchronizations uses the incrementalization system of NMF Expressions, which allows to incrementalize also more complex queries. However, queries only have a readonly interface, which is why the C# compiler throws an error if we tried to use it for a bidirectional synchronization. To aid this problem, our solution uses a mocked class PseudoCollection that mimics a collection interface on top of a query but throws runtime exceptions if the collection is attempted to be modified. With this trick, the synchronization blocks for the remaining correspondence criteria can be implemented as in Listing 3.
In particular, lines 1-7 specify the synchronization of authors that appear in any of the authored entries with the paragraphs in the authors list. For this, we just iterate over all entries that are authored entries, select all their autors, do a deduplication and sort the result by the author name. Lines 9-13 specify the synchronization of titles in a very similar way. Last, lines 15-21 synchronize the journal names with the paragraphs in the corresponding section.
These synchronization blocks all reference other synchronization blocks responsible for how the paragraphs are laid out exactly. In particular, the synchronization rule ReferenceToPara has an instantiating rule2 for each concrete type in the BibTex model.
Furthermore, the synchronization rules can (and in general should) specify when NMF Synchronizations
should establish a correspondence link between two existing model elements. This is in particular required if a
2NMF Synchronizations – as NMF Transformations – supports a form of transformation rule superimposition. This concept is
called transformation rule inheritance as it is realized through inheritance of the respective transformation rule or synchronization
rule. In contrast, an instantiating rule is a child rule that maps a part of the input space (usually denoted through a subtype of the
input type) to a part of the output space (again, usually denoted through a subtype of the output type), cf. [
Listing 2: Definition of synchronization blocks from Figure 2 in NMF Synchronizations
We noted that the original solution produced different results in batch or incremental mode. The reason for this was that the definition of correspondence between authors and paragraphs being that a correspondence should be established if the content of the paragraph is the name of the author. However, this is sensitive to changes that modify the contents of the paragraph. While the incremental execution is aware that the paragraph
Listing 5: Running the synchronization in batch mode corresponds to the author and therefore reports a single inconsistency (that the content of the paragraph no longer matches the name of the author), the batch execution reports two inconsistencies: One that a paragraph has no corresponding author and another that an author has no corresponding paragraph. The reason for this is that the batch mode does not have the history and is not aware that the paragraph was corresponding to the author before.
This behavior can be easily fixed by actually using the unique identifiers that happen to exist in the metamodel in question as they can be used to identify the same paragraph even though its contents have changed. Doing so, also the batch execution detects that the contents of the paragraph have changed. The default behavior for matching elements is currently not taking identifiers into account, because NMF Synchronizations is independent of the model representation of NMF.
random1000.bibtex−triple, Function: Run 1e+05 )10000 s m ( e 1000 m i T 100 10 ● ● ● ● ● ●
● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●
● ● ● ●
● ●
● ● ● ● ● ● ● ● ● ●
● ● ● ● ● ● ● ● ● ● ● ● 1 2 3 4 5 6 7 8 9 1011121314151617181920212223242526272829303132333435363738394041424344454647484950
● AOF
Epsilon
NMF NMF−Batch
Xtend XtendEVL
YAMTL
YAMTL.full
Figure 3 shows the performance results of the solutions submitted to the TTC 2019 for the largest input model provided with triple changes. These results were produced through a Google Cloud Compute Engine c1-standard4 machine with 16GiB of RAM and 30GB SSDs, using a Docker image produced through the Dockerfile in the root of the benchmark repository. For NMF, two versions are depicted. The NMF version uses the incremental change propagation of inconsistencies. In contrast, the NMF Batch solution runs a complete consistency check on the source model and modified target model, reflecting a scenario where a description of changes is not available.
The results show that the batch version is significantly slower than competing solutions, which is clear, given that the entire modified target model has to be considered and correspondence relations have to be established. The incremental solution, however, is among the fastest solutions, indicating that it is about as fast as solutions that basically analyze the target model changes manually.
At the TTC 2019, the NMF solution was the only solution that was able to entirely use the same consistency specification for transforming the source model to the target model and to identify inconsistencies afterwards. Further, the NMF solution has won the best integration award and the first place in the audience award. We think that the NMF solution highlights the advantages model transformations based on synchronization blocks can offer in terms of flexibility. A single specification of consistency relationships between the BibTex model and the DocBook model suffices to transform an existing BibTex model to a DocBook model or identify inconsistencies between an existing source and an existing target model. Furthermore, both the transformation and the consistency check can be run incrementally, i.e. the synchronization engine attaches to the source (or target) model and reports or resolves inconsistencies as they occur.