The anatlyzer plug-in for Eclipse works as an extension of the regular ATL editor provided by the Eclipse modelling distribution. To enhance the ATL editor with anatlyzer just do the following:
Every ATL file in the project will be statically analysed every time it is saved, and errors will be reported in the problem view.
It is highly recommended to use the anATLyzer view, which provides more information about the problems in the active transformation, including actions to run the constraint solver, quick fix problems and visualization. To do so, Window -> Show View -> anATLyzer -> Analysis View.
The anatlyzer requires the source and target meta-models to be able to work propertly. In ATL this is done by adding the path or URI or the meta-model at the beginning of the transformation file (as described here). For example, the two following lines declare the the WF workflow meta-model (using its project relative path), and the PN petri nets meta-model using its URI. It is important to be aware that then you need to register the meta-model.
-- @path WF=/anatlyzer.example.workflow2pn/metamodels/workflow.ecore -- @nsURI PN=http://anatlyzer/example/petri_nets
If you get many "Invalid meta-model" errors, then you probably have some error in the @path or @nsURI declarations (e.g., an erroneous path or URI, or if you are using the URI you may need to register the meta-model).
By default the analyser reports all errors and warnings that it can find. Sometimes one is not interested in getting reports about certain types of errors. To disable report by error type or even error category, there is a special syntax that can be put at the beginning of the transformation file.
The following example disables "missing binding for compulsory feature" errors and every style warning.
-- @disable MissingBinding, style
The complete list of error names and error categories will be added here soon...
Some errors signalled by the analyser are just "potential problems" which needs to be confirmed or discarded by running a constraint solver. The basic idea is to ask the constraint solver to find a model that will make the transformation control flow reach the problematic statement. Such model is called "a witness model", and if its found it confirms the problem. If not, the problem can be discarded.
Note: unfortunately the tool does not provide (yet) any way to distinguish whether the problem must be confirmed by the constraint solver, you need to figure out
To try to find a witness model, just go to the problematic statement, press CTRL + 1 to show the quickfixes, and select generate witness.
The first time the constraint solver is caller for a given project, a folder called temp and file called transml.properties are created. The temp folder contains some intermediate files and the generated witness models (under folder models). Each time a new XMI file is generated with a new identifier, so you could find m0.model, m1.model, etc.
It is likely that you need to register the source meta-models before opening the witness models.
No witness model can be foundmessage is shown.
If you have any trouble installing or using Bentō, you can contact
jesus dot sanchez dot cuadrado at uam dot es