You can also instruct EMF to use named references, i.e. ''ref=n''. Here, ''n'' is the value of an attribute of the referenced Ecore class and has the EMF option ''ID'' set to ''true''. So you get something like (''n''=14):

The ''@ID'' comment ''should'' instruct the KM3 parser to set the EMF ''ID'' option to ''true'' (doesn't work on my setup: EMF 2.3.0.v20070626, ATL 2.0.0rc2). You can also set the option manually in the EMF editor.

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:

<MetamodelName>!<ClassName>

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

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 (!):

MM!C1
MM!C2
MM!C3

Full name reference to metamodel classes

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

<Package1Name>::<Package2Name>::<ClassifierName>

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

MM!P1::C1
MM!P1::P2::C2
MM!P3::C3

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:

MM!P1::C1
MM!P1::P2::C1
MM!P3::C1

I can use KM3 to create metamodels, but what about models?

There are several possibilities to create models:

Using a visual tool. This is very convenient for languages with visual syntaxes (e.g. UML).

Using EMF "Sample Reflective Ecore Model Editor".

Using an injector: a tool to transform from one Technical Space to the Model Engineering Technical Space. For instance, the AM3 plugins provide an XML injector that transforms XML documents into models conforming to an XML metamodel. If no generic injector already exists for your metamodel you may consider building one.

By transforming a source model into a target model. For instance, to get a model conforming to a SimpleClassDiagram metamodel one can write a UML2SimpleClassDiagram transformation. Then, a standard UML tool can be used to create SimpleClassDiagram metamodels.

By combining injection and tranformation. For instance: XML injection followed by XML2MyMetamodel transformation. You can find an example in the Book2Publication transformation (see XML2Book.atl).

What's this ATL feature called "superimposition"?

Superimposition allows you to load an ATL transformation module on top of another in your "Run..." configuration. It allows for the superimposing module to import and override matched rules from the module it is superimposed upon. See also the ATL Superimposition wiki page, the corrresponding bug report and some example transformations.

Q:I read in the corresponding bug report that it is now possible to use a feature called superimposition. Is a superimposed module aware of the module it is superimposing? Or more concretely, is it possible to access rules of the root module from a superimposed module? How can this be done? - Markus Herrmannsdoerfer

A: Modules are not at all aware of any superimposition going on. Superimposition is done at load-time. Access includes invocation of called rules and helper methods, as well as helper attributes.

You can actually access any module in the same run, whether it is superimposing or superimposed upon. It is of course bad practice to introduce references from the root module to any of the superimposed modules, so you'll probably want to reference downward only.

The safest (and original) use of superimposition is to mask matched rules from the root module. Any matched rule in a superimposed module with the same _name_ as a matched rule in the root module will replace it (it masks the old rule).

Q:Do I have to use the "uses" statement in order to be able to access a
rule from another module? - Markus Herrmannsdoerfer

A: No, this is not strictly necessary. It is recommendable in case of explicit references to another rule, however. It adds more clarity and may even become a future requirement.

If you only mask a rule from a lower transformation module, no explicit reference to the masked rule is made. Hence, no explicit "uses" statement should be used for this case.

Q:Assume I have the following rules in the root module:

rule A {
...
}
rule B extends A {
...
}

1. Is it possible to mask B in another module and still extending A from the root module? - Markus Herrmannsdoerfer

A: No, this is not possible. The "extends" statement is a compile-time construction. At compile-time (i.e. .atl to .asm), only single modules are considered. Superimposition is a load-time costruction, that links the .asm files just before running them.

Q:2. If I mask A in another module, will B in the root module then extend the new A? - Markus Herrmannsdoerfer

A: No, the "extends" statement is compiled in such a way that rule "A" is simply in-lined in rule "B". No relationship between "A" and "B" exists in the .asm file.

If "A" were a called rule, it would be masked by any newly defined called rule "A". Rule "B" then indeed invokes the new rule "A".

You can also instruct EMF to use named references, i.e. ref=n. Here, n is the value of an attribute of the referenced Ecore class and has the EMF option ID set to true. So you get something like (n=14):