Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "VIATRA/Transformation/EVM Adapter Framework"
Line 7: | Line 7: | ||
== High level architecture== | == High level architecture== | ||
− | [[File:VIATRA_adapter_arch.png]] | + | [[File:VIATRA_adapter_arch.png | 1000px]] |
=== Components === | === Components === | ||
Line 15: | Line 15: | ||
* '''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 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 | ||
− | == | + | == Connection with EVM == |
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + | ||
− | + |
Revision as of 08:15, 1 April 2016
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
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