Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

VIATRA/Transformation/EVM Adapter Framework

Motivation

The development and debugging of reactive event-driven model transformations is not a trivial exercise, the basic concepts of software debugging however can be mapped to the field of model transformations. Debuggers can be used for detecting bugs, as well as better understanding the structure and behavior of programs. Direct control over a program allows the programmer to follow the flow of execution or stop the program at any desired point. Then it is possible to inspect its current state and verify the correctness of the software. These properties are very desirable in the field of model transformations as well. The VIATRA framework possesses a solution for implementing transformation debugging related functionalities.


A full featured transformation debugger requires a software solution that is able to observe and control VIATRA-based model transformations. Such an extension is able to insert additional functionality into certain points during model transformations. The transformation adapter framework allows the definition of additional functionalities that are executed at certain points in event-driven model transformations, without altering the behavior of the original transformation itself. The previously described debug functionalities are implemented using the transformation adapter framework.

High level architecture

VIATRA adapter arch.png

Components

  • Adapter Interface: The Adapter Interface defines a set of callback methods that are executed at certain points during the transformation execution. A number of Adapters can implement this interface, in order to define additional functionality that should be undertaken at certain points in the transformation.
  • Adaptable Executor: VIATRA Executors are responsible for executing model transformation rule actions provided by rule activations. The adaptable executor extends these default executors, and allows the transformation developer to register a number of adapter in-stances and calls the appropriate callback method of each adapter at certain points during execution. These Adaptable Executor instances are added to VIATRA event-driven trans-formations, which only utilizes their EVM Executor interface. This means, that this adapter-based implementation is completely transparent towards the transformation code, and the internal VIATRA components as well.
  • Adaptable Executor Factory: Responsible for creating adaptable executors
  • Adapter Configuration: The adapter configurations serve multiple purposes. They can either define dependency relations between adapter implementations, or specify complex use cases which requires more than one adapter to function properly

Adapter implementations

The VIATRA transformation adapter framework contains a number of default adapter implementations, that realize model transformation debugging use cases. the default set of adapters consist of the following:

Debug adapter

The debug adapter implements a breakpoint based debugging approach (similar to JDT). It contains the logic for stopping the transformation execution if a breakpoint condition matches, and ordering the UI to display the program context.To support various debugging use cases, the debugger can be configured with different user interface and breakpoint implementations.

Debug adapter.png

  • Debugger UI: Responsible for displaying the internal state of the event-driven model transformation in progress, and it allows the transformation developer to manipulate the execution sequence. Using this component enables the transformation debugger component to remain UI independent, and support the definition of custom user interface implementations.
    • Console Debugger UI: This default UI implementation uses the standard input and output in order to communicate with the transformation developer.
    • VIATRA Viewers Debugger UI: In this case the VIATRA Viewers framework is utilized to visualize the target and source model state via using annotated VIATRA queries.
  • Breakpoints: Each breakpoint realization compares a given activation to a set of constraints. If the constraints match, the debugger is informed that it should halt the execution of the transformation, and wait for a response from the transformation developer.
    • Rule Activation Breakpoints: Contains references to a transformation rule, a lifecycle state, and a set of source model elements that have triggered the activation. This way the debugger can check if the activation being fired has a breakpoint attached to it or not.
  • Conditional Breakpoints: These breakpoints are able to define global constraints that are not only affected by the current activation. A similar concept is available in the Eclipse Java Development Tools (JDT). The constraints are defined by using the VIATRA query language.

Manual conflict resolver adapter

This adapter allows the transformation developer to manually override the execution order of transformation rule activations. Particularly useful during debugging, as allows the easy reproduction of bugs, which require a certain firing order. It uses the similar interchangeable Debugger UI component as the Debug adapter.

Mc adapter.png

Trace coder Adapter

The transformation debug adapter implements a transformation debugger that follows the breakpoint-based approach. However, the execution sequence of VIATRA-based event-driven model transformations is typically non-deterministic. The trace coder adapter is responsible for logging the transformation execution sequence (i.e.: order of transformation rule activation firings). This *transformation trace* can later be analyzed or used during re-execution of the transformation.

Transformation traces are hierarchical object structures aiming at storing transformation execution sequences. Transformation traces consist of activation and rule parameter traces. Activation traces identify the fired rule, and rule parameter traces specify which elements have triggered the execution of the given rule. Based on this information, the transformation can be re-executed for further evaluation, or erroneous rules can be detected during post-mortem analysis.

Similar to the previously introduced adapters, the trace coder adapter utilizes interchangeable sub-components:

Coder adapter.png

  • Activation coder: Creates Activation Trace objects, using the parameters extracted from the activation object.
  • Trace model serializer: Responsible for saving and loading trace models

Trace Executor adapter

This adapter is responsible for re-executing a transformation sequence recorded by the trace coder adapter. Particularly useful during debugging, as it allows the determinization of the otherwise random execution sequence of VIATRA event-driven transformations. It operates the following way: as the transformation is being executed, the activation at hand is compared to the upcoming entry in a previously loaded transformation trace. If the activation matches the trace record, it is executed, if not the executor finds the matching one.


Executor adapter.png


As seen here, the trace executor component utilizes the same sub-components as the trace coder.

Noteable information regarding the trace executor:

  • The usage of this adapter has a heavy effect on transformation performance, it is only advised to use it on small scale test models.
  • Also keep in mind that the trace executor needs an already existing transformation trace, hence it should not be used simultaneously with the trace coder.

Usage Examples TODO

Back to the top