ATL has now a new refining execution mode!.

The refining execution mode has been introduced in ATL to ease the programming of refining (or refactoring) transformations. The main characteristic of a refining transformation is that the output model is very similar to the input one. A typical scenario is when the transformation implements some kind of refactoring on the input model.

With the refining mode, ATL developers can focus on the ATL code dedicated to the generation of the target elements that change from the input model. Other model elements are implicitly processed by the ATL engine.

This mode is selected in the ATL language by simply replacing the from keyword by the refining keyword in the transformation header. Obviously, refining mode may only be used for endogenous transformations, i.e. when source and target model share the same metamodel. Listing below shows how the header of a refactoring transformation on a ClassDiagram metamodel may look like.

module refiningSample;
create OUT : ClassDiagram refining IN : ClassDiagram;

The ATL2010 compiler implements an in-place strategy, e.g., the changes are directly performed on the source model without making any copy of the elements. The rules in the transformation only need to specify the values that have changed whereas all the other elements just remain untouched. Transformations in this mode are performed in two steps. In the first step, the transformation engine executes the rules which, as a result, produce a set of changes that are temporally stored. In the second step, this set changes are applied directly on the source model.

This compiler enhances the refining capabilities provided by the 2006 compiler, that also implemented an in-place strategy. First of all, it addresses the lacking of deletion support by providing the user an explicit way to specify in the transformation that a matched element has to be removed.

To support the deletion feature, some modifications have been introduced in the concrete and abstract syntax of the language to provide a new keyword: DROP . The listing below shows and ATL 2010 refining transformation that reverses the prior introduced change in attributes visibility using the new drop keyword.

 
rule PrivateAttribute {
  from
      s : ClassDiagram!Attribute (s.isPrivate and
          s.owner.op->exists(o|o.name = 'GET' +
          s.name.toUpperCase() and o.returnType = s.type)
          )
  to
      t : ClassDiagram ! Attribute (
          isPrivate <- false
      )
} 
rule DeleteOperation {
  from
      s : ClassDiagram!Operation (s.owner.attr
          ->exists(a|a.name = s.name.toUpperCase().substring(3, s.name->size())
              and a.isPrivate))
  to
      drop
}

From the semantic point of view, note that a delete can easily generate a conflict with another modification. This happens because we chose to provide delete with a cascade-delete semantics for composition associations (i.e. the deletion of a container triggers the deletion of the contained elements). For this reason, the second step in the transformation, in charge of applying the changes, is implemented by first applying all the creation changes, then all the modification changes, and finally all the deletion changes.

Some ATL standard mode advanced features are not supported in Refining Mode. Concretely, the following elements are not supported: Action blocks, Lazy rules, multiple input elements and Iterative output patterns. Covering this advances features as well as providing new refining features (like cloning) are in the future plans.

Refining Mode support in previous compilers :

Refining transformations were also possible in previous versions of the ATL compiler though the implementations followed alternative strategies to support refining transformations. ATL users can choose the refinement implementation strategy that best fits their scenario.

ATL 2004 :
The 2004 compiler implements a copy strategy. The ATL transformation performs as if there were implicit copy rules that would match every element unmatched by explicit (i.e., programmer-written) rules. Such a copy rule creates a target element of the same type as the source element. Then, it initializes all the properties of the new element by copying the values of the properties of the source element. However, not all the elements are copied. To be copied the elements must satisfy at least one of these conditions: 1) they are matched by an explicit rule, or 2) they are contained in a copied element, or 3) they are referenced (non-containment) by a copied element.

This conditions allows the deletion of parts of the model just by removing any reference to them.

The listing below shows a refining transformation in ATL 2004 compiler that change the visibility of attributes and adds the corresponding getters.

rule PublicAttribute {
  from
      s : ClassDiagram!Attribute (
          not s.isPrivate and
          not s.owner.op->exists(o | o.name = 'GET' +
            s.name.toUpperCase() and o.returnType = s.type)
      )
  to
      t : ClassDiagram!Attribute (
          name <- s.name,
          owner <- s.owner,
          isPrivate <- true,
          type <- s.type
      ),
      getter : ClassDiagram!Operation (
          name <- 'GET' + s.name.toUpperCase(),
          owner <- s.owner,
          isPrivate <- false,
          returnType <- s.type
      )
}

ATL 2006 :
Partially implements an in-place strategy. This implementation works in the same way the ATL2010 does, but does not provide support for the deletion of elements. Using reverse binding for the first output pattern element is also not supported.

Remember that to select between the different compilers the first line of the transformation must consist of a comment with the @atlcompiler tag followed by the name of the compiler (by example, -- @atlcompiler atl2010)