Review of YAMTL

[fjouault]

This solution showcases a hybrid transformation written in YAMTL. It combines declarative rules to generate the target model and imperative Xtend code to compute the BDD structure. It demonstrates the flexibility of YAMTL, which can incorporate arbitrary Xtend code in declarative rules.

The transformation is done in two steps: First, the truth table is transformed into DNF clauses. Then, these clauses are used to generate the BDD.

The declarative part of the transformation is easy to understand. The imperative Xtend part is not as simple but is explained in the paper.

Unfortunately, most of the logic of the transformation is written in Xtend (namely the conversion to clauses and the building of the tree).

The transformation both outperforms the ATL transformation (original and improved) in execution time, and in compactness of the obtained BDD. It can process all provided models without any timeout.

After installing Java 11, and modifying the solution.ini we were able to run the solution. The provided solution.ini does not automatically build the solution with gradle, we had to copy the lines from the provided EMFSolutionATL, and edit the build.gradle file. Apart from this minor inconvenience, the solution uses the provided benchmark structure.

PartialExecutionTimeResults.pdf

[arturboronat]

Thank you for the review, for the chart, and for reporting the minor issues in the Gradle build file - these will be fixed.

In response to:

Unfortunately, most of the logic of the transformation is written in Xtend (namely the conversion to clauses and the building of the tree).

YAMTL is an internal DSL of Xtend, so one could argue that the whole solution is written in Xtend.

One has to take into account that:

1. In the first part of the transformation - the conversion to clauses that maps the truth table to a boolean expression, - is done using transformation rules in YAMTL:
   • This means that Xtend logic is augmented with pattern matching, declarative rules, traceability links and reference resolution via the operator fetch, etc. For example, traceability links are generated for each row and stored internally, keeping an open door for incremental propagation of changes [Bor19]. Incremental synchronization has not been exploited in the solution though.
   • This part is also the most computationally intensive, as all of the rows in the table have to be processed. This is done by processing matches that are scheduled by the YAMTL transformation engine, and not simply by Xtend.
   • Transformation rules have side effects, since the boolean expression is stored using a standard Java collection.
2. The second part relies on helpers written in plain Xtend indeed. Xtend provides appropriate expressiveness/conciseness for specifying transformations using standard Java libraries. Therefore, apart from the use of standard Java libraries, there is not much difference - from an expressiveness point of view - from using an ATL helper and OCL for writing model queries/transformations. Furthermore, to analyse the conciseness of the solutions imports, line breaks and line with comments have been removed from the ATLEMFTVMImproved solution and from the YAMTL solution The first one has 176 LOCs, whereas the second one has 136 LOCs. The reuse of Xtend for writing helpers avoids having to build a dedicated external DSL, which leads to maintenance/interoperability issues, so the use of Xtend should be regarded as a positive aspect, in my opinion.