Difference between revisions of "VIATRA2/Live Transformations"

Revision as of 10:52, 14 July 2010

Installation

In order to execute live transformations, the latest version of the VIATRA2 Release3.1 core components are needed.

Overview

The goal of this live transformation engine, is to provide a convenient and effective solution for model synchronizational problems, mainly in graphical modeling enviroments. These problems include:

• Incremental synchronization between an abstract and concrete syntax representation of domain specific models.
• Incremental on-the-fly evaluation of complex language-specific constraints.
• Incremental code generation, where a textual representation is kept in live accordance with a high-level model.

The basic element of live transformations are the triggers. A trigger has a precondition graph pattern, and an action sequence. Every time the precondition graph pattern is fulfilled in the Viatra2 model space, the live transformation engine executes the action sequence, which can be an arbitrary Viatra2 graph manipulation sequence. The triggers can be formulated in the VTCL code as annotated gtrules, only with certain limitations (the original LHS-RHS representation cannot be used, rather this precondition-action format is used, which has the same expressiveness). The annotations can be the following:

• Priority (integer): If two or more triggers are ready to run at the same time, the trigger with the highest priority will run first. Of the triggers with the same priority one is selected non-deterministically.
• Mode (once | always): The default setting is the always mode, where the trigger runs in the background until it is stopped by the user. The once mode is different, in this setting the trigger will only run once.
• Sensitivity (rise | fall): If the trigger is set to rise sensitivity then the action sequence is executed with every new match of the trigger’s condition pattern, on the other hand if it is set to fall sensitivity then the action sequence is executed with every loss of a previously existing pattern match. The default setting of a trigger is rise sensitivity.
• Startup (active | passive): Active startup means that the action sequence of the trigger will be executed with all pattern substitutions that are present in the model space at the trigger’s startup. Whereas with passive startup all current matches that are present in the model space when the trigger is added to the framework, are discarded. The default setting of a trigger is active startup.
• Execution (forall | iterate): Forall execution means that the action sequence of the trigger will be executed with all pattern substitutions in a pseudo-parallel way. With iterate execution the pattern substitutions are executed in separate steps. Iterate mode is needed when a trigger can modify it’s own pattern matchings (e.g. generates new matches). However this is not the general case, so the default setting of a trigger is forall exection, since it is the faster method.
• AutoStart (true | false): If the autoStart annotation is set to true, than the trigger will start automatically after loading.

The heart of this live transformation engine is the incremental pattern matcher. It stores the matchings (complete or partial) of the predefined graph patterns, so after each user editing action, the new (or lost) matches are available for the live transformation engine instantly.

Further reading

See http://mit.bme.hu/~rath/pub/diploma_okros.pdf

Examples

• Hello World example

• Using ASMfunctions in triggers