Indeed, multi-rules and NACs and PACs in general are still future
work for our new CDA. If you need support for these, please just
continue using CPA.
For clarity, both instances of "pullback" in my original mail should
be replaced by "pushout" (although the diagram can also be read as a
pullback, but that's not what happens here).
Best regards,
Daniel
On 08.04.2019 17:51, Zschaler, Steffen
wrote:
Thanks,
Daniel. Very nicely explained. I will delve into the
details, then. Can I just check to see that this still
doesn’t cover multi-rules and only covers some types of
NACs/PACs?
Thanks,
Steffen
Hi Steffen,
we have documentation at
https://github.com/dstrueber/multicda
Note that the old CPA stuff is still around, but has been
renamed to
org.eclipse.emf.henshin.multicda.cpa.*
Generally, the new CDA (multi-CDA) now has three levels of
granularity (binary / coarse / fine), where the "fine" level
is almost the same as essential critical pairs.
I say "almost":
First, the "fine" granularity level is based on an improvement
to ess. CPs, called "initial conflicts", that avoids some
weird edges of ess. CPs which one would not actually consider
essential (see [1]). Occasionally, there will be fewer fine
conflicts than ess. CPs.
Second, the point of using the abbreviation "CDA" (conflict
and dependency analysis) is that we don't report critical
pairs anymore, but conflict reasons. Critical pairs are the
"lower" span in the pullback, or, in other words, the graph
arising from overlapping the left-hand sides. Conflict reasons
are the "upper" span in the pullback, or, in other words, the
intersection of both graphs. More rationale for this is found
in the running example section in [2].
For the interpretation of the results, this means that the
mappings go from the graph into the rules' left hand-sides,
and not the other way around.
[1] Initial
Conflicts and Dependencies: Critical Pairs Revisited
Leen Lambers, Kristopher Born, Fernando
Orejas, Daniel Strüber and Gabriele Taentzer. In:
Graph
Transformation, Specifications, and Nets. In Memory of
Hartmut Ehrig. Springer. pp. 105-123.
http://danielstrueber.de/publications/LBOST17.pdf
[2] Multi-Granular
Conflict and Dependency Analysis in Software Engineering
based on Graph Transformation
Leen Lambers, Daniel Strüber, Gabriele Taentzer, Kristopher
Born, Jevgenij Hübert. In:
ICSE
2018: International Conference on Software Engineering.
IEEE/ACM. pp. 716-727.
https://www.uni-marburg.de/fb12/arbeitsgruppen/swt/forschung/publikationen/2018/LSTBH18.pdf
Best regards,
Daniel
On 08.04.2019 15:09, Zschaler, Steffen
wrote:
Hi,
I notice that in v1.5,
which is what the nightly build currently seems to be
producing, the old critical-pair analysis stuff has been
replaced with a new version, which prefers the
abbreviation CDA.
It looks like this works
pretty much the same way as before, but that matches are
shown as actual EPackages. Would it be possible to
obtain some more detailed documentation on how this new
approach works? In particular, how does one interpret
the resulting matches? Are they meant to represent
essential critical pairs? If so, are they basically the
pushout of the pair span? How does one figure out the
connection to the specific rule left-hand sides?
I've tried understanding
this from the code, but didn't get very far with it, to
be honest. Any pointers to any documentation would be
much appreciated (ideally not an entire PhD thesis ;-)
).
Many thanks,
Steffen
_______________________________________________
henshin-user mailing list
henshin-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.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://www.eclipse.org/mailman/listinfo/henshin-user
|
