[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [henshin-user] delete node problem

If that is the case, then wouldn't the 'Second' rule work as it aims to delete these references with the use of multi-nodes ?


Thank you,

Kinga


From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> on behalf of Daniel Strüber <strueber@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sent: 23 June 2017 18:31:56
To: henshin-user@xxxxxxxxxxx
Subject: Re: [henshin-user] delete node problem
 
OK, thanks Kinga for trying out the version without the multi-nodes.

Some new insights: I was able to apply the "First" rule to the behavior model, after I turned off the dangling-edges check by disabling the "checkDangling" attribute of the rule.

This implies there are some references in the input graph that become dangling if the "EReference" node is deleted. To check if this is the case, I inspected server3.behavior and noticed that it indeed has many references to EReferences from the server2.ecore file.

So, it's indeed a feature rather than a bug: please see the explanation regarding dangling edges in my very first e-mail.

Best regards,
Daniel

Am 23.06.2017 um 19:17 schrieb Bojarczuk, Kinga:
I've sent a simplified version of the rule we were working on to Daniel and the multi nodes are not doing anything there, I should have deleted them as well. The rule does not work after deleting them either so in this case they are definitely not the problem and the problem is in that delete EReference node somewhere.

From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> on behalf of Daniel Strüber <strueber@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sent: 23 June 2017 17:58:35
To: Henshin Project user discussions
Subject: Re: [henshin-user] delete node problem
 
Hi Steffen,

based on the information that the "First" rule cannot be matched while the "Third" rule can, my feeling is that the multi-nodes are not the root cause of the problem: If the LHS of the kernel rule (the part without the multi-elements) can be matched, then there is a match for the entire rule as well, since matching the multi-rule is optional.

Of course, there is a simple way to be sure it's indeed not the multi-nodes: you could remove them from the rule and see if the problem still occurs.

BTW, I'm not sure about the actual purpose of the multi-nodes in the "First" and "Third" rule. Since the multi-rules of these rules don't specify any changes, they shouldn't have any effect on rule applications anyways.

Best regards,
Daniel

Am 23.06.2017 um 17:53 schrieb Steffen Zschaler:

Hi Daniel,


Thanks for your comments on Kinga's question. Can I just clarify your thoughts on the following question:


We were unsure whether this was something to do with us misunderstanding something about how Henshin works (in particular, in relation to multi-nodes, which were present in the rules where the problem first occurred) or whether this might actually be a bug in Henshin. What is your view on this?


Many thanks,


Steffen


On 23/06/2017 13:09, Bojarczuk, Kinga wrote:

This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing Feedback

Yes that's correct and I was thinking the same that it seems odd. I can use rule 'Third' but I'd still like to know why the other one doesn't work so if you come up with anything please let me know.


Thank you,

Kinga


From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> on behalf of Daniel Strüber <strueber@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sent: 23 June 2017 13:03:49
To: henshin-user@xxxxxxxxxxx
Subject: Re: [henshin-user] delete node problem
 
So your rule "Third" works on set-up (2), while rule "First" does not - OK, that's really odd, and I don't have any further ideas for the moment.

For all practical purposes, I can encourage you to simply use rule "Third" instead "First": Removing an object from its container object basically has the same effect as deleting it altogether. (One needs to be careful with other elements referencing the element-to-deleted, though.)

Best regards,
Daniel

Am 23.06.2017 um 13:48 schrieb Bojarczuk, Kinga:

Yes you are correct but again as I said if you run the 'Third' rule on the behavior file it accepts it/finds a match so it does accept two layers of cross-referencing in the interpreter wizard. And I have applied the rule programmatically(as I said in the previous email) and it doesn't work either but I am 100% sure the set up is correct because I have been working on other rules that work and they run just fine in both the wizard and through Java -> as does rule 'Third'.


From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> on behalf of Daniel Strüber <strueber@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sent: 23 June 2017 12:42:28
To: Henshin Project user discussions
Subject: Re: [henshin-user] delete node problem
 
Hi Kinga,

to summarize, there are two different model set-ups:

(1) server2.gcs -> server2.ecore
(2) server3.behavior -> server2.gcs -> server2.ecore

Using the interpreter wizard, your rule works when apply it to (1), and does not work when you apply it to (2). Right?

Then it could still be an issue with the interpreter wizard, but a more subtle one: the wizard can deal with one layer of cross-referencing, but not with two or more ones.

Can you try the following: Apply the rule programmatically to set-up (2). But before you apply the rule, make sure to load all three models and add them to the same input EGraph.

Best regards,
Daniel


Am 23.06.2017 um 13:29 schrieb Bojarczuk, Kinga:
I'm sorry I think I'm just very bad at explaining and wasn't precise enough. I've been running a few other examples already and I run it through a Java class as you said but the transformation wizard still accepts them as there is a match so it just doesn't change anything after it runs. I didn't include it because the output doesn't matter for me it's just finding a match that matters so the transformation wizard is enough. And the java class doesn't find a match either because if it was there then 'apply transformation' would work instead of giving an error, it just wouldn't change anything as it only makes changes in the behavior file.
So my problem is that the rule is correct but for some reason running it from the behavior file doesn't  find a match (neither in editor nor the Java class) but it should because it exists and the connections ( :Behavior -> :MetamodelGD -> :PackageGD) are correct because as I said the 'Third' rule works. So my problem is why doesn't it find  a match for the 'First' rule -> deleting :EReference node when running it on the behavior file while it finds it when running on the ecore/gcs files (through both transformation wizard and java).
I've enclosed a screenshot which shows a rule that runs on server2.gcs(which references server2.ecore) file and finds a match. But after adding :Behavior node at the front and running it on server3.behavior  it doesn't find it anymore -> which is my problem from the beginning as it should find that match as it does the same it just references it through the behavior file so I don't understand why it doesn't.
Thank you,
Kinga

From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> on behalf of Daniel Strüber <strueber@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sent: 23 June 2017 12:09:24
To: Henshin Project user discussions
Subject: Re: [henshin-user] delete node problem
 
Hi Kinga,

Am 23.06.2017 um 12:39 schrieb Bojarczuk, Kinga:

Sorry bad-wording by the code I just meant running the transformation just by 'apply transformation' on the files. I just want it to find a match.

Ah, I see. Then the actual issue is as follows: The transformation wizard (which is executed by "apply transformation") currently does not account for references between models. In other works, it only supports "self-contained" models which do not depend on other models. This could be considered a bug, so I will create a corresponding entry in our BugZilla.

In the meantime, you can run the transformation programmatically by using the API (see [1] for an example). There, dealing with references between models is simple: Just add all involved models to the same input EGraph.

[1] http://git.eclipse.org/c/henshin/org.eclipse.emft.henshin.git/tree/plugins/org.eclipse.emf.henshin.examples/src/org/eclipse/emf/henshin/examples/bank/BankExample.java


I cannot anyhow specify that containment edge between EReference and EPackage in the Henshin editor, it doesnt let me connect them. And if that was the problem then why does it find a match in the ecore file but not in the behavior file?

Indeed, I now notice that my earlier interpretation was wrong: EReferences are contained in EClasses (and not in than EPackages). So the rule as it is should be correct.

Because my main problem is that it works/finds a match when run on the server2.ecore file but when adding  a 'top layer' to run it on server3.behavior :Behavior -> :MetamodelGD - > :PackageGD it doesn't find  a match anymore  but these only provide the reference to the ecore file so it doesn't make any sense.


Best regards,
Daniel



Thank you,

Kinga



From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx> on behalf of Daniel Strüber <strueber@xxxxxxxxxxxxxxxxxxxxxxxxx>
Sent: 23 June 2017 11:26:31
To: Henshin Project user discussions
Subject: Re: [henshin-user] delete node problem
 
Hello Kina,

Am 23.06.2017 um 12:06 schrieb Bojarczuk, Kinga:

Hello,


I'm working on this project on e-motions files so basically there's a .behavior file which is linked to .gcs which is linked to .ecore file and together they represent a graph transformation system. So what I'm trying to do is to delete EReference from .ecore file between the object that has some subclasses and another object. (First rule in my henshin file) This should find a match as it exists in a server2.ecore file however for some reason it doesn't.

To understand why the rule cannot be applied, it's crucial to know that Henshin aims to ensure that output models of a transformation are well-formed: in particular, it aims to ensure that rule applications never leave behind "dangling edges". In your example rule, since you do not specify the deletion of the containment edge between the :EPackage and the :EReference, this edge would be left behind as dangling, so Henshin won't apply the rule.

To make the rule applicable, it should be sufficient to specify the deletion of the aforementioned containment edge. (Another option is to the set the "checkDangling" attribute in the rule to "false", however, in this case, you may lose well-formedness guarantees.)


When I run the code straight on the server2.ecore (by starting with EPackage in my rule) file or server2.gcs (by starting with MetamodelGD in my rule) file it works and finds a match but when running on server3.behavior file something suddenly prevents it from finding a match which is really weird as .behavior file just provides a reference to the other files so since it works when run straight on them it should work on the the behavior file as well.

I can't find the code you mention in these statements. The zip file only contains the models and Henshin files.


Best regards,
Daniel

The Second rule shows the solution that we thought might work as Links in .behavior file are linked to EReferences so we thought this might prevent deleting EReferences but it doesn't work either.

The Third rule shows something that works but is a rather 'unclean solution' as it only deletes all the edges and doesn't actually delete the node.

So any idea why running my rule on .behavior file suddenly prevents it from finding a match? It seems really weird so I'd appreciate some help. I've included a zip file with my project.


Thank you,

Kinga



_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user



_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user



_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user



_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user



_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://emea01.safelinks.protection.outlook.com/?url="">

-- 
Dr. rer. nat. Steffen Zschaler AHEA
Senior Lecturer

King's College London
Department of Informatics

Email szschaler@xxxxxxx
Phone +44 (020) 7848 1513
WWW   http://www.steffen-zschaler.de/


_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user



_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/henshin-user