This paper presents the ATOL solution to the TTC 2023 KMEHR to FHIR case study. The ATOL compiler is an alternative ATL compiler that enables incremental execution of ATL transformations. In this paper, we explain how we used ATOL to make the original KMEHR to FHIR ATL transformation incremental. With incremental model transformation engines, such as ATOL [1], NMF [2] or YAMTL [3], it is possible, after an initial application of the transformation, to de- 2. ATOL overview tect changes on the source model and propagate these changes to afected parts of the target model without ATOL [1] is an experimental ATL compiler that produces re-executing the transformation on the whole source Java code, which in turn uses the Active Operations model. This contrasts with traditional model transforma- Framework to compute expressions incrementally. ATOL tion engines that recompute the whole target model from has previously been showcased on TTC cases such as scratch after each change on the source model. Incremen- the TTC 2018 Social Media Case [5] or the TTC 2021 tal model transformation engines are particularly useful Incremental Workflow Case [6]. when the source model is large, the transformation is Traditional ATL engines execute the whole transforcomplex or the source model is frequently modified. mation at once to produce a target model from a source This case study [4] involves translating between two model. This is referred to as batch execution. With ATOL, medical data formats: from the Belgium KMEHR format, the transformation is first applied to a source model to to the international FHIR format. The reference trans- produce a target model, like with a batch transformation. formation is written in modern ATL with advanced fea- But, unlike with standard ATL engines, ATOL keeps a tures leveraging all features of the EMFTVM engine, such propagation graph in memory. Using this graph, changes as multiple rule inheritance, mapsTo or the improved applied on the source model can be propagated to the matching plan. target without recomputing the whole transformation. The transformation consists of a relatively large trans- This allows for faster updates to the target model at the formation and several helpers. cost of an increased memory footprint. This paper is organized as follows. In Section 2 we ATOL supports a subset of standard ATL. For inquickly present the ATOL compiler. In Section 3 we stance, ATOL natively supports only unique lazy rules, present the process we developed to produce an ATL helpers, declarative ATL, and parts of OCL operations. transformation compatible with ATOL. In Section 4 we Whereas standard rules are implicitly matched and represent the results of our approach. In Section 5 we detail solved, unique lazy rules must be explicitly called to be diferences between the reference ATL transformation applied, and resolved. It also difers from standard ATL on specific points. For instance, ATOL requires target tuTTC'23: 15th Transformation Tool Contest, Part of the Software Tech- ple navigation for called lazy rules (see Listing 1), it also nologies: Applications and Foundations (STAF) federated conferences, supports implicit collect on property navigation on colEds. A. Boronat, A. García-Domínguez, and G. Hinkel, 20 July 2023, lections. In the long run, we aim at aligning ATOL with Leicester, UK. ATL, so that executing ATL transformations increment$hefor.eled-ecraiclv.jaoru@a uimlt@t-aetsleaon.tfirq(uFe..fJrou(Ta.uLlte);Calvar); tally is not significantly more complicated than executing matthew.coyle@imt-atlantique.fr (M. Coyle) ATL transformations in the traditional non-incremental © 2023 Copyright for this paper by its authors. Use permitted under Creative Commons License batch mode. CPWrEooUrckReshdoinpgs IhStpN:/c1e6u1r3-w-0s.o7r3g ACttEribUutRion W4.0oInrtekrnsahtioonpal (PCCroBYce4.0e).dings (CEUR-WS.org)
and our ATOL-compatible ATL transformation. Finally, in Section 6 we give some concluding remarks.
Manual update Simplified ATL
Solution + small adapations Source & Target
Metamodels
Xtend Generator Generated
Java helpers Manually written Xtend helpers Java class
ATL solution. However some changes were made to make it compatible with ATOL. A detailed list is given in Section 5.1. Figure 1 illustrates the compilation pipeline of our ATOL solution.
The reference ATL transformation uses many advanced features of EMFTVM and was not compatible with ATOL. For ATOL to be able to process it, we updated the reference transformation to use simpler ATL constructs supported by ATOL. These changes are done in two steps.
The first step is a manual rewriting of parts of the transformation to make it compatible with ATOL (either by simplifying the transformation or adapting it to ATOL-specific syntaxes). These rewritings are either too small and local to be worth automating (such as adding typing hints where ATOL fails to properly compile) or require understanding of the transformation semantics (such as rewriting rules with multiple inputs to rules with single inputs). Some helpers that cannot be compiled with ATOL are also rewritten with native Xtend code, such as the ATL helpers that used the #native syntax or the lazy rules FhirString, FhirBoolean, FhirPositiveInt and FhirDecimal.
The second step is performed by a Higher Order Transformation (HOT) written in ATL, and applied using a standard ATL engine. This HOT transforms standard matched rules to unique lazy rules without guards, and produces a RESOLVE helper that emulates standard rule resolution using explicit lazy rule calls. Listing 2 shows part of the generated helper. The HOT also adds after each OCL expression an @type comment annotation specifying the expression’s type. This is useful for debugging purposes, and could be disabled to improve readability. However, the HOT’s output is not intended for user consumption. helper context OclAny def: RESOLVE : OclAny = 1 if if self.oclIsKindOf(KMEHR!DocumentRoot) then 2 let cp : KMEHR!DocumentRoot = self.oclAsType(KMEHR 3
!DocumentRoot) in else true false endif then thisModule.DocumentRoot(self.oclAsType(KMEHR!
DocumentRoot)).t else 9 if if self.oclIsKindOf(KMEHR!FolderType) then 10 let cp : KMEHR!FolderType = self.oclAsType 11
(KMEHR!FolderType) in not cp -- @type kmehr!FolderType .patient -- @type kmehr!PersonType .oclIsUndefined() -- @type Boolean -- @type Boolean else else
false endif then thisModule.Folder(self.oclAsType(KMEHR!
FolderType)).t ...
Listing 2: Part of the generated RESOLVE helper
mation is compatible with ATOL, and can be compiled to a Java class. The transformation is applied by calling the now (as a result of the HOT) unique lazy rule DocumentRoot, which transforms the root of the source model. 4. Results now be matched by other rules. When this happens, the old rule application should be removed/disabled, and the result of the new rule application added. However, at the moment, ATOL cannot easily deactivate the bindings of the old rule. Thus, changes are still propagated through the old rule bindings, which can cause crashes because of inconsistent properties. We identified this issue with our TTC 2023 incremental Class to Relational case, and are working on a fix.
The original ATL reference transformation is a batch transformation, thus the case does not provide data to test changes on the source model. To evaluate the correctness of our solution, we compared outputs (with a textual dif) of our solution with outputs of the reference 5. Discussions solution for the three given source models. When doing so, we observed that our solution produces identical In Section 3 we presented an overview of the changes target models when serialized in the FHIR format (ig- we applied to the reference ATL transformation. In this noring attributes that rely on uuid, which are randomly section we discuss, with more details, the kind of changes generated). we made to the reference solution, and why, as well as the
Overall, the structure of the transformation is close to improvements we made to ATOL and the tooling around the reference one. However, compatibility with ATOL it. forces us to rewrite advanced ATL constructs. This can reduce transformation readability and maintainability. 5.1. Diferences with the reference
Figures 2a, 2b and 2c show runtime performance of our proposed solution. We can see that both ATOL and solution reference solutions have similar performances for load We made two kinds of changes, some that simplified and initialization. For the actual application of the trans- the transformation without breaking compatibility with formation, ATOL is a bit slower with models of a smaller EMFTVM, and ATOL-specific changes. size but scales better than the reference solution. We have not investigated this performance diference yet, but it 5.1.1. Simplification may be due to the fact that the Java code generated from ATOL compiles to more eficient bytecode than what the Helper inlining: ATOL currently only supports atEMFTVM just in time compiler produces. tribute helpers in the context of source metamodel types.
However, in Figure 2d we see that ATOL is consuming To circumvent this limitation, several helpers on Strings much more memory than the reference solution. ATOL were inlined (e.g., normalize or toGender). The imuses more memory because, on top of the trace, it stores pact of this change is limited, because most of these the propagation graph, which is needed to compute and helpers were rarely used. propagate updates when the source model changes. One Manual type hints in bindings: sometimes the Java should note that the current version of our solution has code produced by ATOL fails to compile because the Java not been optimized for memory and thus represent a compiler fails to unify the types. In these situations, we worst case scenario. The typical way to optimize mem- added .oclAsType(<type>) operation calls to explicory usage is to make sure the propagation graph does itly type the expression, and fix these errors. not contain duplicate values. This can be performed by Rewriting of matched rules: as mentioned in Secadding attribute helpers, which result will be cached, thus tion 3, ATOL only supports unique lazy rules. In order avoiding duplication. to compile the transformation, we applied a HOT that
Basic incremental updates on the source model (e.g., replaces all matched rules by unique lazy ones, adds a modifying properties of source elements) should work RESOLVE helper that calls the correct rule for its source, without issues. However, we know that null values in and adds calls to that helper when resolving is needed. the source model will most likely cause crashes because This HOT is still a work in progress, and needs more work the original transformation has not been strengthened before it can be released. That is why it is not present against all possible null values. with the ATOL solution. Instead, we provided both its
The current implementation of ATOL also sufers of source, and its target ATL files. a known bug related to the rule matching system we Rewriting rules with multiple inputs to single use. As described in Section 3, we use a HOT to replace input: ATOL supports calling lazy rules with multiple all resolvings with a call to a resolve helper that calls the source elements but the HOT that transforms matched correct rule. However, after the initial transformation rules to unique lazy ones does not. In the KMEHRToFHIR is applied, source elements can mutate, and they could transformation, rules with multiples inputs can easily be Tool atol reference
Tool atol reference rewritten to rules with a single input element, as other unique lazy rules without trouble. For the few ones elements can be recovered using navigation. In older ver- that required the non-unique behavior (namely the sions of ATL, it was a good practice to avoid rules with FhirString, FhirBoolean, FhirPositiveInt and multiple inputs when non-necessary, to avoid the Carte- FhirDecimal) we implemented them as native Xtend sian product matching performance cost. With recent helpers. For Coding and its subrules we added a naive improvements to the matching algorithm of EMFTVM support for non-unique lazy rules to ATOL. Like the pre(since ATL 4.8.0), this old guideline is not that relevant vious change, this is also a good practice to prefer unique anymore. lazy rules instead of lazy rules when possible.
Rewriting some lazy rules to unique lazy rules: Rewriting a call to super rule into several call to unique lazy rules are the only kind supported by ATOL, subrules: in the rule Folder, the original transformabecause in incremental contexts it is important to keep tion computed the union of many elements which are caches and not recreate target elements. Most lazy transformed by matched abstract rules. Because of typrules in the reference transformation were replaced by ing issues with ATOL we instead applied the subrules for each elements before merging them in a single collection.
Rewriting of multiple inheritance in an additional rule: ATOL does not support multiple rule inheritance. Multiple rule inheritance is only used once in the transformation, for the SumEHRTransactionWithAuthorAndCustodian rule. In our solution, we simply duplicated code from both inherited rules into the subrule. • custom join operation; • initial support for non-unique lazy rules • automated conversion between enumeration lit
erals and Strings in our helper generator.
to FHIR TTC 2023 case. This solution is based on the 5.1.2. ATOL-specific changes reference ATL solution but is compiled with ATOL, which Up to now, previous changes were compatible with other makes it incremental. Because ATOL supports only a ATL engines. However, ATOL provides features not sup- subset of ATL, changes to the reference transformation ported by other engines, and also requires some specific (both manual and automated) had to be done. modifications. We showed that runtime performance of the produced
Change to helper type declaration: enumeration code is similar to the reference solution with slightly types are handled as Strings in ATOL, therefore all in- better scaling. We also showed that the generated target stances of enumeration literals types were replaced by models are identical to those generated by the reference Strings. solution.
Navigation into lazy rule target tuple: calling Basic incrementality should be working. We identified a lazy rule with ATOL returns a target tuple, and several propagation bugs due to the way the transfornot just the first element. Therefore, with ATOL, mation is written, or because of known limitations in it is mandatory to sufix all calls to lazy rules with ATOL. the name of the element to be accessed in the target Finally, this case allowed us to improve our HOT and tuple (e.g., thisModule.CompositionBundleEntry ATOL compiler. (s.transaction).be). This is a breaking change because other engines do not support this. Without this change, only the first target element of each rule applica- References tion would be accessible. Because ATOL only supports lazy rules, this is more of a problem than in classical ATL, hence the change.
Replacement of the join helper with a native operation: the standard OCL iterate operation (which corresponds to a left fold) is not supported by ATOL. In this situation, the join helper that used the iterate operation was replaced by an ad hoc join operation written in Xtend.
Property navigation disambiguation is necessary
in some cases, when multiple metamodel properties have
the same name, because of the way the ATOL compiler
works. This is performed by appending a numeric sufix
to the property name, as assigned in the generated
metamodel representation Java class by the @AOFAccessors
annotation processor [
• Maps and mutable sequences;
Applications and Foundations (STAF 2021), Virtual Event, Bergen, Norway, July 17, 2020 and June 25, 2021, 2021. URL: https://ceur-ws.org/Vol-3089/ttc21_ paper10_labflow_Jouault_solution.pdf.