eclipse-viatra-bot
commented
6 months ago By Zoltan Ujhelyi on Jan 29, 2016 17:46
Just two additional concerns:
- I don't know if it helps, but we are planning to move the Adaptable concepts directly into EVM. The current AdaptableExecutor was created as a demonstrator; and is not the final implementation.
- If you see anything that would be beneficial in the Adaptor framework to be implemented in a different way; or provide a bit different callbacks, make sure to discuss it. The current implementation was not released, etc. so we can change it quite easily if necessary.
| --- | --- | | Bugzilla Link | 486802 | | Status | NEW | | Importance | P3 normal | | Reported | Jan 29, 2016 05:31 EDT | | Modified | Aug 02, 2016 05:02 EDT | | Version | 0.9.0 | | Depends on | 488783 | | Reporter | Andras Szabolcs Nagy |
Description
Recently a debugger for VIATRA transformations has been contributed: it would be nice to integrate it with the DSE framework.
However, the current DSE implementation uses only a RuleEngine without custom ConflictResolver, ConflictSet or Executor and fires activations on its own behalf, which leaves the AdaptableExecutor unusable.
Based on my investigations, there are five solutions:
1) Exploration strategies are defined through a ConflictSet and the (Adaptable)Executor is settable through the main API.
My main concern about this solution is that it requires the strategy API to use "pull" like behavior - like overriding getNextActivation(). Previously, the strategy API was constructed in a similar way that made complex strategies hard to write, understand, optimize and debug. Hence, I've started to change the Strategy API to a "push" like architecture where the strategy has maximal control, which has made strategies easier to write, understand, optimize and debug.
2) If a DSEConflictSet.getNextActivation() could call the strategy asynchronously it would allow the "push" like strategy API. But this needs an extra thread for each exploration thread, which may impact performance.
3) The main idea in the new debug framework is the ITransforamtionAdapter (listener) interface. This could be easily integrated into the DSE component.
However, DSE is a bit more than a model transformation, a debugger needs adapters for backtracking, calculating objectives/global constraints, storing solutions, optionally strategy specific events and may be more considering the multi-threaded strategies.
4) Like solution 3) but using an interface derived from ITransforamtionAdapter with more funcionality.
5) Completely DSE specific adapters could be an option too. ITransforamtionAdapter may be still reused.
In my opinion, solution 4) and 5) are the best options.