November 26, 2007

ATL and AMW

The next talk in our seminar was about ATL, the ATLAS transformation language. The talk took place on November 15, 2007, the same day we already discussed MOF QVT. The main difference between ATL and QVT is, that QVT is just a specification whereas ATL is both a language AND an implementation.



We just recall the essence of model transformation. Say, we want to define a model transformation between two metamodels MMa and MMb (think of them as source and target language). Such a transformation allows us to transform instances Ma of MMa into instances Mb of MMb. Usually the metamodels have to conform to a common metametamodel MMM. Further we usually have a transformation metamodel MMt, i.e. a language our transformation Mt can be defined in.



ATL is based on the Eclipse platform. Here it can, for instance, be used to define transformations between Ecore models. The picture on the left side shows how the picture above (both taken from the ATL Starter Guide) is instantiated by ATL.

We cannot discuss the differences of ATL and QVT here in detail (there is a paper addressing their alignment, see below), however, we can give some reasons why ATL also is important:


  • Model transformation is young. We do not have as many experiences in the field as we should have to define a standard already. Therefore a broader variety of tools and languages is useful.

  • ATL works. It is smoothly integrated into Eclipse, well-documented, has its own IDE (debugger, etc.) and an active community that gladly offers support via the newsgroup, etc. For QVT there are tools already, however, they are not that mature yet.

  • ATL is different. It provides interesting concepts not included in QVT. AMW (ATLAS Model Weaver), for instance, is the ATL way to describe model transformations on a more abstract level. Further ATL offers e.g. rule refinement (copy all elements that are not addressed by a rule) and a model handler abstraction layer, i.e. different model handlers can be used (e.g. for EMF, MDR, etc.).



Note, that a nice thing about model transformation is that you can even transform transformations. There is an ATL usecase QVT2ATLVM that transforms a QVT transformation to an ATL transformation.

Further reading:

  • ATL

  • Atlas Model Weaver (AMW)

  • On the Architectural Alignment of ATL and QVT, Jouault, F., and Kurtev, I., Proceedings of ACM Symposium on Applied Computing (SAC 06)

4 comments:

Miguel Garcia said...

Steffen,

you might want to take a look at the paper "Mapping visual notations to MOF compliant models with QVT Relations" as it addresses that very same topic.

The URL is http://portal.acm.org/citation.cfm?id=1244228


ABSTRACT

Model-centric methodologies rely on the definition of domain-specific modeling languages for being able to create domain-specific models. With MOF the OMG adopted a standard which provides the essential constructs for the definition of semantic language constructs (abstract syntax). However, there are no specifications on how to define the notations (concrete syntax) for abstract syntax elements. Usually, the concrete syntax of MOF compliant languages is described informally.

We propose to define MOF-based metamodels for abstract syntax and concrete syntax and to connect them by model transformations specified with QVT Relations in a flexible, declarative way. Using a QVT based transformation engine one can easily implement a Model View Controller architecture by integrating modeling tools and metadata repositories

Steffen Mazanek said...

Miguel, this paper is quite interesting - unfortunately very brief. Do you know of any extended version?

Miguel Garcia said...

On Dec 11th, Ian Bull
http://www.ianbull.com/
posted a message to the newsgroup eclipse.modeling.m2m saying:

---------- begin quote -----------

The reason I was asking is because I am just finishing my dissertation
on using MDE to create interactive visualizations of information. I
have several MM for for viewers (graphs, charts, heatmaps, etc...) and
using model transformations I can specify how the visualization should
work. I know this works in practice, but I wanted to give some advice
on how well it works in theory (can this always be done, etc...). There
are some cases when I have to use operational (imperative)
transformations, and it usually is a result of needing multiple elements
in the visualizations for a single source.

Thanks for all your help. I did find some good links on this stuff as
well, I will get them organized and post them here in case others have
questions too.

Cheers,
ian

---------- end quote -----------

Miguel Garcia said...
This comment has been removed by a blog administrator.