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

• *Transformation Debug Listener*: Repsonsible for displaying the state of the VIATRA transformation using a specific Debugger UI.
• *Transformation Debug Adapter*: Responsible for halting the execution of the transformation if a breakpoint is reached. Once the breakpoint is encountered, it allows the user to select the next action to be taken via the Debugger UI.
• *Debugger UI*: Responsible for displaying the internal state of the 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.

• *Transformation Debugger Configuration*: This configuration binds the transformation debug adapter and listenercomponents together and allows a more straightforward usage.

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: