ATL Investigations
From DaVinci
Contents |
Purpose
After an initial glance at the Sprint 1 implementation goal, it was determined that one could either
- Manually traverse the model and identify the port candidates by an algorithm explicitly expressed in Java.
- Make use of ADT plug-ins in Eclipse and express the port candidate identification and collapsing in ATL rules.
In order to parallelize the efforts Carl Wang looked into the first option, whereas Harry Gunnarsson investigated the ATL usability.
ATL Introduction
ATL is a part of Eclipse GMT project (see http://www.eclipse.org/gmt ) and stands for ATLAS Transformation Language. The purpose is to enable model transformations by writing rules in the ATL language that specify the exact transformations. For instance, assuming that one has access to meta-models describing the Java and C++ language, one could define a transformation from Java to C++ and vice versa, and use the transformation system to automatically regenerate a C++ implementation to Java.
Required Tools
In order to explore the ATL examples found on the GMT web page, the following tools are required.
- Java SDK 1.4.10
- Eclipse 3.1.1
- EMF 2.1.1
- Omondo UML 2.1.0
- ADT (ATL Development Toolkit) 20051102
- OSATE 1.1
It is suggested to install everything the following way
- Install the ATL enabled Eclipse 3.1 provided by Peter (http://www.aadl.info/xfer/ATL-eclipse-3.1.1-win32.zip )
- Install the latest OSATE front-end plugin (osate-frontend-1.1-11182005.zip)
- Install the Omondo jar-file (eclipseUML_E310_studioEdition_2.1.0.beta.20050927.jar), plus the academic license provided by Lutz
Importance to Project
It is believed that in the long run, most of the transformations the team attempts to implement are preferably implemented in ATL. Therefore an early understanding regarding the capabilities is beneficial for the project.
Findings
The following list shows the findings, thoughts and ideas that are considered of interest for the project
- The GMT website usually talks about the generic case when there is one input meta-model and one (possibly completely different) output meta-model. This generic case does not necessarily pertain to team DaVinci’s efforts. For the port-collapsing implementation, and probably all AADL related transformations and refactorings, the input model and the output meta-model is the same; namely the AADL meta-model itself. Lutz and Peter explicitly discouraged the team from making changes to the AADL meta-model, and currently there are no compelling reasons to ever do this.
- On the GMT page there is an abundance of ATL examples, which are useful when exploring what the ATL language is capable of doing. Naturally, most of the examples are of the generic kind, when the input and the output meta-models differ. But there is one example of particular interest, which shows a transformation example with the same input and output meta-model, namely; Monitor2Semaphore. The meta-model, upon which the ATL transformation is working, is a pseudo-like programming language defined in Ecore. This example shows how to create one model as the result from a transformation from another model, both derived from the same meta-model definition.
- In addition to transformations, it should be possible to use ATL for other purposes, such as traversing a model and counting the number of ports and similar simple tasks. In this case the output meta-model needs to be defined, but in this simple case it could just be a class holding the statistics and other information the implementer is interested in.
- One question that still is unanswered is if it is possible to define an ATL specification for a transformation for only a subset of the meta-model constructs. In the case of port-collapsing, it might be of interest to keep the model exactly as it is, except for moving out some ports into separate port groups. If so possible, the actual ATL definition might not need to span over constructs of no transformation interest, and thus could be kept relatively small and simple.
Conclusions
ATL should be very useful for team DaVinci when attempting various transformations. Let’s break down the advantages and the drawbacks with ATL
- Expressive language, which enables transformation implementation by defining rules.
- ADT has graphical wizard, which allows for rule definition without typing it in ATL syntax.
- No handwritten Java is necessary in an ATL transformation
And now the drawbacks
- Yet another plug-in to learn. The implementer needs to learn not only ADT and ATL language, but probably also KM3 (kernel meta-meta model) to some extent.
- Dependency on plug-ins and their reliability
- ATL language constraints, which probably restrict the implementer somewhat compared to hand-coded Java.