Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
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 Go to next message
Rakshit Mittal is currently offline Rakshit MittalFriend
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 Go to previous messageGo to next message
Zoltan Ujhelyi is currently offline Zoltan UjhelyiFriend
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 Go to previous messageGo to next message
Abel Hegedus is currently offline Abel HegedusFriend
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 #1854638 is a reply to message #1854615] Wed, 31 August 2022 14:40 Go to previous messageGo to next message
Rakshit Mittal is currently offline Rakshit MittalFriend
Messages: 3
Registered: August 2022
Junior Member
Hi Zoltan,

Thank you for your quick reply!

Indeed, I have been looking at implementing a conflict resolver specific to the model (i.e. AADL) that I am transforming.
I found information on ConflictResolvers in VIATRA through an old bug report discussion (https://bugs.eclipse.org/bugs/show_bug.cgi?id=403825)

I will implement my own conflict resolver, and let you guys know if I face any problems there. I want to use a simple element-name based ordering.

Thanks again!

Re: Determinism in event-driven transformation [message #1854639 is a reply to message #1854621] Wed, 31 August 2022 14:47 Go to previous messageGo to next message
Rakshit Mittal is currently offline Rakshit MittalFriend
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 Go to previous message
Abel Hegedus is currently offline Abel HegedusFriend
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.
Previous Topic:How can I monitor my application using EMF and VIATRA query language?
Goto Forum:
  


Current Time: Mon Dec 02 12:07:25 GMT 2024

Powered by FUDForum. Page generated in 0.03147 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top