Home » Modeling » VIATRA » Determinism in event-driven transformation(How to add determinism in event-driven transformation?)
| Determinism in event-driven transformation [message #1854608] |
Mon, 29 August 2022 14:55  |
 Rakshit Mittal
Messages: 3
Registered: August 2022 |
Junior Member |
|
|
Hi,
I am constructing an AADL model transformation tool using VIATRA.
I am comparing the resultant final model (after the transformation) with a pre-stored model, to check if they are equivalent, to verify the transformation.
From observation, I can see that the model is correct, but the order of model elements is non-deterministic. Can you please advise how I can make it determinstic, the order of elements. Basically, this involves ordering the activations.
I checked the conflict resolvers class, and am already using the fixedPriorityConflictResolver to order the priority of the transformation rules. But how to order the model elements, i.e. make the transformation order completely deterministic is the problem.
Thank you.
My project is available at gitlab.telecom-paris.fr/mbe-tools/osate-dim
|
|
|
| Re: Determinism in event-driven transformation [message #1854615 is a reply to message #1854608] |
Tue, 30 August 2022 07:50  |
Zoltan Ujhelyi
Messages: 392
Registered: July 2015 |
Senior Member |
|
|
Hi Rakshit,
in general, VIATRA provides no guarantees on the order the results are processed. This is extremely important for reactive scenarios (where the code needs to react to model changes), but in case you need a completely deterministic transformation, you can use conflict resolvers.
The built-in conflict resolver implementations (e.g. FixedPriorityConflictResolver) don't aim to fix this issue, they operate on the rule-level to define the priorities, but you can write a conflict resolver (with a model-specific ordering of activations). Note that in the addActivation/removeActivation methods of the ChangeableConflictSet interface, you get access to all the activations (that reference Match objects as event atoms).
Hope this helps. If not, feel free to ask for clarification.
Best regards,
Zoltán
|
|
|
| Re: Determinism in event-driven transformation [message #1854621 is a reply to message #1854615] |
Tue, 30 August 2022 16:17 |
Abel Hegedus
Messages: 197
Registered: September 2015 |
Senior Member |
|
|
To extend on what Zoltán wrote:
Conflict resolvers are used when you ask the transformation engine to execute one or more arbitrary activations (both in batch and event-driven mode). There are the following options that I can see that would help you resolves ordering non-determinism:
1. Use the batch transformation statements that accept a filter, which can completely define an activation and you could use queries or simple EMF APIs to order the filters/activations that you execute. In this case, you provide deterministic ordering by executing rules in a specific order.
2. Check order of source elements in the action part of the rule and ensure that the order of target elements become also correct (by inserting into the collection at the correct place), you would probably use EMF or VIATRA traversal API to read from the model. In this case, you provide deterministic ordering by always correcting the order in the actions.
3. Instead of always fixing ordering at the time of creating/mapping an element the first time, it may make sense to identify the parts of the target that should be ordered at the end of the process and add a post-processing step (potentially driven partially by VIATRA queries and by reading the model, where ordering is accessible) after the main transformation.
4. Similarly, you could create a pre-processing step that goes through the model, extracts the ordering information in a way that makes it easily and efficiently accessible during the transformation and use that static information (since the input model doesn't change) instead of computing on every action/firing.
If you are using event-driven mode and would like to implement a synchronization in one direction (source changes trigger changes in the target), then your options are more limited to 2., but with rule priorities, you could still separate the creation/deletion from the order fixing.
I assume you are not planning to reach complete bi-directional event-driven synchronization, where both ends of the transformation could change and the other should follow. This is an extremely complicated setup as VIATRA is not really suited for this case, but using two sets of rules and some clever flagging on traceability, you could probably set up something that works for some use cases (since you would see in the rule activation where the change happened). But this is probably too far-fetched.
In any case, since VIATRA transformations and queries are all an internal DSL to Java (JVM), you have a lot of freedom in how you set up your process.
|
|
| |
| Re: Determinism in event-driven transformation [message #1854639 is a reply to message #1854621] |
Wed, 31 August 2022 14:47 |
Rakshit Mittal
Messages: 3
Registered: August 2022 |
Junior Member |
|
|
Hi Abel,
Thank you for your quick reply!
I hadn't thought of all of these options! Thank you!
As you rightly suspect, I am using an event-driven transformation, and hence, am mostly limited to option 2.
However, within my use-case, the ordering on the left (original) and right (generated/transformed) model elements is not one-to-one. This is because there can be an arbitrary number of right-model elements associated with a single left-model element. Calculating in this case, the exact position of the right model element corresponding to the position of the left-model element is then virtually impossible.
I only need this ordering to validate my approach (because of a not-very-great comparison tool), and not as a feature of the approach itself, i.e. the ordering is not necessary for the general tool-use, just for the validation tests.
The best and most logical solution for my use-case seems to be implementation of a ConflictResolver. I will keep you updated if I encounter any problems.
Thank you once again!
|
|
|
| Re: Determinism in event-driven transformation [message #1854657 is a reply to message #1854639] |
Thu, 01 September 2022 09:17 |
Abel Hegedus
Messages: 197
Registered: September 2015 |
Senior Member |
|
|
Rakshit Mittal wrote on Wed, 31 August 2022 14:47
I only need this ordering to validate my approach (because of a not-very-great comparison tool), and not as a feature of the approach itself, i.e. the ordering is not necessary for the general tool-use, just for the validation tests.
If the ordering is only relevant for validating the results, I guess it would also be possible to modify your validation: instead of making the transformation order deterministic, make the validation order-independent.
One way how VIATRA could help here is by building the validation by checking VIATRA query results against the target model. I would imagine this in a way that you use a set of queries to extract the information required for cross-checking and you assert on the results either by extracting the same from the intended result or just storing the information, instead of the gold model itself.
If you are even braver, we have testing utilities, which work by saving query result snapshots in persistent form and checking the snapshots against actual matches of queries. Since these utilities work on the query level, they don't care about order and they can also test complex structures with facilities to ensure result sets are identical.
While talking about out-of-the-box solutions, another option would be to use EMF DiffMerge to do a two-way comparison between the intended and the actual result, then check the comparison if there is anything else then order difference in the same collection.
|
|
|
Goto Forum:
Current Time: Sat Nov 11 05:57:03 GMT 2023
Powered by FUDForum. Page generated in 0.02090 seconds |
] 
Search
Help
Register
Login
Home
