Jump to: navigation, search


Revision as of 12:11, 21 December 2006 by Frederic.jouault.univ-nantes.fr (Talk | contribs) (added FAQ entry about referring to metamodel classes)

< To: ATL

This is the ATL wiki FAQ. The entries of the old ATL FAQ have not been copied here yet.

Metamodels declared in the header (after the create keyword) of transformation models have to be named. What name should be used?

Usually, the name given to a metamodel is used in several places: the name of the file containing its definition (e.g. in XMI or KM3), the name of the main package of the metamodel, and the name given in the header of ATL transformations. This is the simple scenario that should be followed when possible.

In practice, the EMF driver for ATL (emf4atl) does not care about the name given to the metamodel in the header. There is no strong notion of main package. Any name can thus be used.

The MDR driver (mdr4atl), however, does care about this name. A specific package has to be specified to create a model conforming to a metamodel. If the correct package is not selected, the created model usually does not behave as expected. The current version of mdr4atl selects the package having the name specified in the transformation header or any package if there is no match.

How close is ATL navigation language from the OCL 2.0 standard?

When designing ATL, we started from the most recent OCL specification at the time. It is the OMG Final Adopted Specification ptc/03-10-14.

We elaborated from this document to solve the following issues:

  • ATL works with MOF, not UML. The specification only gave some hints on how to do this.
  • We decided to use model element references so that the metamodel is not defined as an extension of the metametamodel. Note that the specification defined it as an extension of UML.
  • We had to resolve some of the ambiguities of the specification. The latest version of OCL 2.0 specification probably solves most of these but ATL predates it.
  • We simplified the metamodel and syntax so that it works with TCS (or more precisely the version of TCS at that time).

The last step (simplification of metamodel and syntax) was necessary but did not impact the result too much in our opinion. It mostly resulted in forbiding some of OCL syntactical shortcuts. For instance, iterators and self must be specified explicitely in ATL whereas this is optional in OCL.

We are confident that ATL is really close to OCL 2.0. Moreover, it is certainly interoperable with any OCL tool having an explicit metamodel. This interoperability can indeed be achieved via model transformation.

How can I refer to metamodel classes located in subpackages, and avoid name collision?

In ATL, classes are always referred to with respect to their metamodel. They are two possibilities to refer to a specific class from a given metamodel: simple name, and full name.

Simple name reference to metamodel classes

Metamodel classes can be referred to by their name, even if they are defined in subpackages:


Let us, for instance, consider the following metamodel defined in file MM.km3:

package P1 {

  class C1 {}

  package P2 {
    class C2 {}

package P3 {
  class C3 {}

ATL code can refer to these classes simply by prefixing their name by the metamodel name (declared in the transformation header), and an exclamation mark (!):


Full name reference to metamodel classes

It is also possible to include the full path using the following scheme:


For instance, using the metamodel excerpt given above, we could write:


In some cases, full name reference is required to avoid ambiguity due to name collision. Let us consider the following metamodel:

-- Note: the following KM3 excerpt is not valid because KM3 does
-- not allow several classes with the same name, even in different
-- packages. However, the structure described here can be found
-- in some pre-existing Ecore or MOF 1.4 metamodels.
package P1 {

  class C1 {}

  package P2 {
    class C1 {}

package P3 {
  class C1 {}

Using MM!C1 is incorrect because it cannot reliably me mapped to a specific class. If you try to do this, a warning will be reported in the ATL console. In this case, it is mandatory to write: