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 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: Defines a set of callback methods that can be used to listen to certain EVM-based events, and react to them accordingly. However these callback methods cannot manipulate the EVM rule execution sequence in any way.
  • public void initializeListener/disposeListener: These callback methods are called once, as the EVM program is being initialized and disposed.
  • public void beforeFiring(final Activation<?> activation): This callback method is called from the Adaptable Executor, before each Activation firing.
  • public void afterFiring(final Activation<?> activation): This callback method is called from the Adaptable Executor, after each Activation firing.
  • public void startTransaction(String transactionID): This callback method is called from the Adaptable Executor, before each Execution sequence. This means that if an executor is about to fire a set of activations, this method is called first.
  • public void endTransaction(String transactionID): This method is called after the execution sequence is undertaken.
  • public void activationChanged/Created/Removed: Called by the AdaptableActivationNotificationListener class, these callback methods can be used for reacting to the changes in the EVM activation lifecycle states.
  • public void addedRule/removedRule: Called by the AdaptableRulebase, these methods allow listening to the addition and removal of rule Specifications.
• AdaptableRulebase: The Adaptable RuleBase extends the EVM Rulebase. It has a reference to an AdaptableEVM object, through this it can notify adapters about the addition and removal of EVM rule Specifications.
• AdaptableExecutor: The Adaptable Executor as the same responsibilities as the EVM Executor, however, it can also notify EVM listeners about the starting/ending transactions and activations firings. It also enables adapters to alter the set of Activations the executor is assigned to fire.
• AdaptableActivationNotificationListener: Delegates a default EVM activation notification listener. apart from calling the respective methods of the delegated activation change listener, it also notifies EVM listeners about activation state changes.
• AdaptableConflictResolver: The adaptable conflict resolver allows EVM adapters to override or alter the conflict set created by a delegated conflict resolver instance, in order to modify the execution sequence of an EVM-based program.