From DaVinci

Contents 1 ATL Report 1.1 Tools 1.2 Sprint Goal 1.3 Current Status 1.4 Problems Encountered

ATL Report

Tools

The experiments were based on the following tool version

• OSATE 1.2.3 complete zip
• ADT 20060113
• Antlr 2.7.5
• Latest MDR standalone distribution
• AM3 20060117

In previous ATL environment tested, there were problems getting the KM3 to Ecore translation to work and other weird problems. Luckily, no such problems were experienced in this OSATE 1.2.3-based system.

Sprint Goal

The goal for this sprint was to have a very simple ATL translation working on the AADL meta-model. More specifically the goals were

• The ATL translation dialog wizard runs the translation
• The input model would be based on the AADL meta-model. So is the output model.
• The ATL translation would do something simple, such as changing some string attribute, variable name or similar.

Current Status

We still don’t have a working ATL translation on the AADL meta-model, due to some unforeseen problems. Instead we went back to the basics and created some sample ATL projects where the input and output models are based on the same meta-model. This was done in order to verify the feasibility of such translations, since typically the example ATL sample projects seen make use of separate meta-models for the input and output systems.

Problems Encountered

The failure to produce an ATL project, as stated in the above goal, was due to the following problems.

• The current ATL plug-in does not seem to support the ‘refines’ feature of the ATL language. This feature, if it worked, would probably prove very useful for many translations we might want to attempt. Only the regular ‘from’ ATL specification seems to be supported.
• It is notoriously difficult to use the ATL translation dialog wizard due to the following reasons.
  • The tool does check simple syntactic violations of the ATL spec, which is all good. At run-time, there are many features left to be desired though; the tool doesn’t seem to emit any kind of error message regarding mismatches between the ATL, the meta-model and the input instance model. The only indication that something went wrong is that the output ecore file is empty (with the exception of a XML header). One could actually set up a project with meta-model and ATL spec in total conflict with each other and still the output would be an empty XML file, without any kind of hint from the tool what went wrong.
  • The dialog does not seem to check that the input and output models are actually based on the meta-models configured. It is yet again only validated in run-time by the tool, with no particular feedback regarding user errors.
• The sample projects from the ATL site usually have a reasonably comprehensible meta-models implemented in one single ecore file. The AADL meta-model is far more complex and it is spread out over seven .ecore files (correct, right?) Currently, it is a bit unclear how to cope with this in the ATL dialog, since it allows only for one entry, i.e. ecore file, for the meta-model. The two snapshots below show the situation.

Figure 1: Snapshot over AADL-based ADT project

Figure 2: Snapshot over ADT translation dialog

• The attempted ATL translation spec does seem to bail out early, since no breakpoints are triggered at all when running the translation in the ATL debugger. Therefore this would indicate something fundamentally wrong with the ATL spec, but it is hard to know due to the absence of error messages at all. Below follows one incarnation of the simple ATL spec. Many tweaks have been attempted, but so far nothing has worked

module ATLTest; -- Module Template
create OUT : AadlSpec from IN : AadlSpec;

rule ATLTest {

from

inm : core!AadlSpec

to

outm : core!AadlSpec (

aadlPackage <- inm.aadlPackage->collect( f | f.aadlPublic ).asSequence()

)

}

• Due to time constraints there haven’t been an opportunity to try a programmatic approach to trigger a transformation. The assumption is that one could trigger an ATL transformation from a Java API.