agarciadom
commented
1 year ago The solution clearly identifies the benefits and disadvantages of ETL versus ATL for coding the transformation, but the discussion could be expanded.
The lack of a mapsTo mechanism and the consequent need to filter r-values (Section 2.1) may result in more complex coding in ETL compared to ATL. LOC is not necessarily a useful measure here, because ETL tends to be more syntactically dense than ATL - so the syntactic complexity (or token count) of the ETL solution may not be very different to that of the ATL.
That's true, but unfortunately the case description does not provide a definitive metric for this. I guess the audience will decide based on their impressions.
The use of eContainer to access secondary input variables of a rule (Section 2.2) is simpler than the ATL approach, but types for these variables should be declared, to aid understanding.
Sure, we can do that for the post-proceedings version. The types would be entirely optional, though.
Section 2.4: clarify the difference in semantics between ATL and ETL rule inheritance. With ATL the super and subrule behaviours are combined when both are applicable. The coding of this in ETL (listing 4) avoids using inheritance, which may be more concise, but could increase maintenance costs. Is there a way to simulate ATL inheritance using ETL inheritance?
Unfortunately, not as far as I am aware. ETL and ATL inheritance work very differently: if R1 is non-abstract and R2 extends it, R1 and R2 will produce different model elements. My impression is that rule inheritance in ETL is designed to be used with abstract super-rules.
Section 2.5: the ATL syntax is simpler, but this relies upon being able to infer the correct enumerated type of a literal from the context. In general the more explicit Type#literal notation avoids the risk of ambiguity.
That's true - we will add it to the post-proceedings version of the paper. For things like the enum-to-enum maps, however, the Type#literal notation was quite repetitive.
Section 3.3: Visualisation should be very useful in this case, because of the high complexity of the transformation mapping. Perhaps include the visualisation which identified orphan objects?
The orphan objects were actually identified from the tree on the left side. Basically, the folder that contains the target object elements had 5 direct children (i.e. roots of the target model), instead of the expected one. We could add a screenshot of that for the post-proceedings version.
Section 4: perhaps include more detailed analysis of where the main computation costs occur in the ETL solution? It appears that the ETL solution has a lower computational growth rate compared to the ATL solution (Figure 5).
I will take a closer look with a profiler for the post-proceedings version and see where that time is going. It may also be worth trying to run the transformation with bigger model sizes (e.g. 2000/5000/10000) and see if there is a point in which ETL does end up being faster than ATL.
There is a minor typo: Section 2.3 'transforamtion'
Thanks for the catch - I've fixed this already, before I forget :-).
The solution clearly identifies the benefits and disadvantages of ETL versus ATL for coding the transformation, but the discussion could be expanded.
The lack of a mapsTo mechanism and the consequent need to filter r-values (Section 2.1) may result in more complex coding in ETL compared to ATL. LOC is not necessarily a useful measure here, because ETL tends to be more syntactically dense than ATL - so the syntactic complexity (or token count) of the ETL solution may not be very different to that of the ATL.
The use of eContainer to access secondary input variables of a rule (Section 2.2) is simpler than the ATL approach, but types for these variables should be declared, to aid understanding.
Section 2.4: clarify the difference in semantics between ATL and ETL rule inheritance. With ATL the super and subrule behaviours are combined when both are applicable. The coding of this in ETL (listing 4) avoids using inheritance, which may be more concise, but could increase maintenance costs. Is there a way to simulate ATL inheritance using ETL inheritance?
Section 2.5: the ATL syntax is simpler, but this relies upon being able to infer the correct enumerated type of a literal from the context. In general the more explicit Type#literal notation avoids the risk of ambiguity.
Section 3.3: Visualisation should be very useful in this case, because of the high complexity of the transformation mapping.
Perhaps include the visualisation which identified orphan objects?
Section 4: perhaps include more detailed analysis of where the main computation costs occur in the ETL solution? It appears that the ETL solution has a lower computational growth rate compared to the ATL solution (Figure 5).
There is a minor typo: Section 2.3 'transforamtion'