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"
< VIATRA | Transformation
(→Connection with EVM) |
|||
| Line 9: | Line 9: | ||
=== Components === | === Components === | ||
| − | * | + | * '''Adapter Interface''': The Adapter Interface defines a set of callback methods that are executed at certain points during the transformation execution. These actions are capable of altering the execution sequence of transformation rules. A number of Adapters can implement this interface, in order to define additional functionality that should be undertaken at certain points in the transformation. |
| − | + | * '''Listener Interface''': The Listener Interface defines a set of callback methods that are executed at certain points during the transformation execution. The actions defined in these methods can have no effect on the transformation itself, purely aim at providing a solution to listening to certain transformation-related events. 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 EVM''': The Adaptable EVM is responsible aggregating the used Adapter and Listener instances and delegates the callback method calls from the internal VIATRA objects towards the appropriate callback method of each adapter or listener at certain points during execution. The Adaptable EVM is also responsible for setting up VIATRA transformation to utilize adapters. |
| − | + | * '''Adapter Configuration''': The adapter configurations serve multiple purposes. They can either define dependency relations between adapter imple-mentations, or specify complex use cases which requires more than one adapter to func-tion properly | |
| − | + | ||
| − | + | The Adapter Framework provides a generic, easy-to-use technique for creating user defined adapter and listener implementations. The Adapter Framework is utilized in order to implement a set of debugging-related use cases. | |
| − | + | ||
| − | + | ||
| − | + | ||
== Connection with EVM == | == Connection with EVM == | ||
Revision as of 11:05, 1 April 2016
Contents
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 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. The previously described debug functionalities are implemented using the EVM 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. These actions are capable of altering the execution sequence of transformation rules. A number of Adapters can implement this interface, in order to define additional functionality that should be undertaken at certain points in the transformation.
- Listener Interface: The Listener Interface defines a set of callback methods that are executed at certain points during the transformation execution. The actions defined in these methods can have no effect on the transformation itself, purely aim at providing a solution to listening to certain transformation-related events. 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 EVM: The Adaptable EVM is responsible aggregating the used Adapter and Listener instances and delegates the callback method calls from the internal VIATRA objects towards the appropriate callback method of each adapter or listener at certain points during execution. The Adaptable EVM is also responsible for setting up VIATRA transformation to utilize adapters.
- Adapter Configuration: The adapter configurations serve multiple purposes. They can either define dependency relations between adapter imple-mentations, or specify complex use cases which requires more than one adapter to func-tion properly
The Adapter Framework provides a generic, easy-to-use technique for creating user defined adapter and listener implementations. The Adapter Framework is utilized in order to implement a set of debugging-related use cases.
Connection with EVM
TODO
The class diagram below depicts the relations between the internal EVM elements and members of the EVM adapter framework.
Legend:
- Green: API classes through which the user can define EVM based programs.
- Blue: Internal EVM classes and interfaces.
- Yellow: Adaptable EVM classes
- AdaptableEVM:
- Aggregates listeners and adapters
- Assembles an adapter supporting EVM instance
- ExecutionSchema
- RuleEngine
- IEVMAdapter: Callback methods for manipulation the set of EVM Activations to be executed
- public Iterator<Activation<?>> getExecutableActivations(Iterator<Activation<?>> iterator): Wraps a handed Iterator with one defined by the adapter implementation --> manipulate the Activations handed to the executor
- public ChangeableConflictSet getConflictSet(ChangeableConflictSet set): Wraps a handed ChangeableConflictSet with one defined by the adapter implementation --> Activations returned by the conflict set can be manipulated.
- IEVMListener:
- public void initializeListener()
- public void beforeFiring(final Activation<?> activation):
- public void afterFiring(final Activation<?> activation):
- public void startTransaction(String transactionID):
- public void endTransaction(String transactionID):
- public void activationChanged(Activation<?> activation, ActivationState oldState, EventType event):
- public void activationCreated(Activation<?> activation, ActivationState inactiveState):
- public void activationRemoved(Activation<?> activation, ActivationState oldState):
- public void addedRule(final RuleSpecification<?> specification):
- public void removedRule(final RuleSpecification<?> specification):
- public void disposeListener():
- AdaptableRulebase:
- AdaptableExecutor:
- AdaptableActivationNotificationListener:
- AdaptableConflictResolver: