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>

Actually the ATL Parser doesn't deal well with "::" so we need to surround the path using ".

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:

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

How to create a terminal model?

A terminal model is a model such that its reference model is a metamodel, i.e. it conforms to its reference metamodel. It is a representation of a "real world" system.

If you design your own DSL from scratch, you should first define the abstract syntaxt of this DSL i.e. the metamodel. To create your metamodel, you can use KM3.

Definition

A metamodel is a model that defines the concepts and relationships that may be created in a model. A model always conforms to a metamodel. This relation is called conformance. The conformance relation has a different nature than the representation relation between a model and its system. A metamodel does not represent a model (that could be considered a system), but only the concepts and relationships that may be created. A metamodel conforms to a metametamodel.

With your metamodel, you are now ready to create your terminal model.

NB: If you are a UML user, your favorite UML modeler may already provides you a XMI-serialization for your UML diagrams. You can use these XMI files directly in a model transformation.

There are several possibilities to create terminal models conform to your metamodel:

Using EMF "Sample Reflective Ecore Model Editor".

Creating a graphical editor by using Eclipse/GMF project. This is very convenient for languages with visual syntaxes.

Creating a textual editor by using Eclipse/TCS. This is very convenient for languages with textual syntaxes.

Using a XML-to-model tool that can parse XML documents into a model.

Transforming a source model into a target model by combining one previously quoted solution and a model tranformation.

Using EMF Generated Editor

If you want to create terminal models, an easy way would be to use the EMF generated editors. From your Ecore metamodel, you can create an EMF model (New > Other... Eclipse Modeling Framework> EMF Model). A genmodel file is generated, and when you open it you see a tree editor (almost the same as with your ecore metamodel). On the context menu, you should be able to generate model file, edit and editor. Click on each of them and you will have a set of plugins that will add a specific editor (on .author files as default). This editor is a tree like editor, as in ecore. It is a very simple editor, but it should be enough to run some tests with ATL.

By this way you create terminal models that conform to your metamodel. If you feel like customizing a little your editor, check the properties of the genmodel items. You can set some interesting options, although you don't need to change most of them.

This solution is adapted for a simple test but in most of the case the creation of an advanced editor could be cost-effective.

Creating a Graphical Editor for a visual syntax

If your DSL already has a visual syntax or if you want to have one, there are some powerful editor generators to do it. With a project like GMF, you can generate a graphical editor from your metamodel. GMF (Graphical Modeling Framework) provides a generative component and runtime infrastructure for developing graphical editors based on EMF and GEF. A tutorial is available at: http://wiki.eclipse.org/index.php/GMF_Tutorial.

Creating a Textual Editor for a textual syntax

If your DSL already has a textual syntax or if you want to have one, with TCS you can generate a textual editor from your metamodel. TCS (Textual Concrete Syntax) enables the specification of textual concrete syntaxes for Domain-Specific Languages (DSLs) by attaching syntactic information to metamodels. With TCS, it is possible to parse (text-to-model) and pretty-print (model-to-text) DSL sentences. Moreover, TCS provides an Eclipse editor, which features: syntax highlighting, an outline, hyperlinks, and hovers for every DSL which syntax is represented in TCS. TCS examples are available at: http://wiki.eclipse.org/TCS/Zoo.

Starting with XML documents

If you start from XML documents, you can use the AM3 XML tool to create terminal models. This tool transforms your xml file into a model conforms to the XML metamodel. Then you can create a model transformation from the XML metamodel to your metamodel. This transformation generates terminal models conform to your metamodel. You can find an example using this mechanism in the RSS to ATOM use case (see XML2RSS.atl or XML2ATOM.atl transformations available from the ATL Transformation Zoo).

Transforming a source model into a target model

The idea is to reuse a tool that creates terminal models and then a transformation can be created to your metamodel. For instance, to get a model conforming to a SimpleClassDiagram metamodel one can write a UML to SimpleClassDiagram transformation. Then, a standard UML tool can be used to create SimpleClassDiagram metamodels.

Advanced concepts

An injection is a transformation from another Technical Space (e.g., XML, Grammarware) to the Model Engineering Technical Space.

An injector is a tool implementing an injection.

An extraction is a transformation to another Technical Space (e.g., XML, Grammarware) from the Model Engineering Technical Space.

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 which has the EMF option ID set to true. So you get something like (n=14):

The @ID comment instructs the KM3 compiler to set the EMF option ID to true. It is not yet implemented (EMF 2.3.0.v20070626, ATL 2.0.0rc2), for now you'll have to edit the generated Ecore file to set the option manually.