ATL FAQ

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.