Open review for UML-RSDS solution

[TheoLeCalvar]

Description

The UML-RSDS solution to the TTC 2023 KMEHR to FIHR case consists in two transformations: a forward one in ttc23.km3 (from KMEHR to FIHR), and an inverse one in fihr2kmehr.km3 (from FIHR to KMEHR). These two files describe mappings and operations in a declarative constraint-like form. There is also a huge (around 8500 lines of code) kmehr.km3 file containing both source and target metamodels. The solution compiles, and seems to work without error, although we have not checked the results.

Positive points

• The solution is easy to compile and run, even though no build script is provided (users are expected to manually run javac).
• Transformation execution seems fast, but we lack proper metrics to verify the claims from the paper.
• The transformation is rather clear, thanks to its declarative nature.
• An inverse transformation is present.
• The paper gives rather interesting explanations on how the inverse transformation can be written from the forward one.

Negative points

• The transformation does not produce XMI files, which makes it rather hard for us to compare its output to the expected results in order to check correctness.
• The solution is not integrated to the benchmarking framework, which also makes it harder to verify the runtime figures given in the article.
• Some files look fully generated, others partially (presence of commented lines). It would be helpful to indicate clearly which files were generated, and whether some generated files were manually updated or not. Manual modifications in large generated files is arguably a bad smell, which makes future transformation evolutions harder.
• We noticed several variations between the original target metamodel and the one used in the transformation. For instance:
  • All data types seem to be mapped to Strings, which seems to indicate that proper date & time conversions are probably not handled.
  • FhirString is handled as a value type (with no duplicates with the same value). However, it is a class in the metamodel, and it is used in container references. This means that the absence of duplicates would lead to child stealing with the original metamodel.

Questions to authors

• Which files are generated, and what is written manually?
  • How much of kmehr.km3 (~8500 LOC) was modified after generation?
    • Should it be counted as an artifact to be maintained?
• Does the UML-RSDS code automatically translated from ATL actually work?
  • The submitted solution seems to have been re-expressed manually to improve quality.
• How much of the inversion is automatic, or could be automated?

Open questions

• What about using EMFTVM as a backend for UML-RSDS?

[kevinlano]

About 50 lines of kmehr.km3 were manually modified (to remove feature names that clash with OCL type names, in particular). But this step could be automated within the ecore to KM3 mapping. Currently however it would need to be maintained.

The UML-RSDS from ATL works for regular ATL, but doesn't fully handle the ATL version used in the case.

Much of the inversion process can be automated, but as I explain in the paper, sometimes customised inverse functions need to be created (eg., to extract address items from an address line).