After deactivating its dangling-edges check, the "Second" rule can
be matched as well.
What this really means is that the "Second" rule is a very
interesting edge case: When considering the kernel rule on its own,
the dangling check should indeed fail. But when we consider the
multi-rule as well, we can find a match, since the multi-rule
specifies the necessary deletions of the adjacent edges.
I would say this is actually a bug of the Henshin interpreter, since
it shouldn't check the dangling condition of the kernel rule before
it considers the multi-rules. I'll look more detailedly into this
issue and hopefully fix it with the next Henshin release. For now, I
hope you can live with deactivating the dangling-edges check.
Best regards,
Daniel
Am 23.06.2017 um 19:46 schrieb
Bojarczuk, Kinga:
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
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.
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
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'.
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
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
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
_______________________________________________
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
|
