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?
From: henshin-user-bounces@xxxxxxxxxxx <henshin-user-bounces@xxxxxxxxxxx>
On Behalf Of Daniel Strüber
Sent: 08 April 2019 16:13
Subject: Re: [henshin-user] CDA vs CPA
we have documentation at
Note that the old CPA stuff is still around, but has been renamed to
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 ). Occasionally, there will be fewer fine conflicts than
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 .
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.
 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.
 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.
On 08.04.2019 15:09, Zschaler, Steffen wrote:
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 ;-) ).
henshin-user mailing list
To change your delivery options, retrieve your password, or unsubscribe from this list, visit