Henshin/Conflict and Dependency Analysis

Fig. 1: Execute MultiCDA on the Henshin file or on the associated diagram file

Fig. 2: First page of the MultiCDA wizard: selecting the rules to be analysed.

Henshin's conflict and dependency analysis feature enables the detection of potential conflicts and dependencies of a set of rules. The feature is called MultiCDA in short, since it supports multiple different depths of calculation (granularities), which can be selected by the user.

There are four types of granularity:

• Binary granularity lists all rule pairs that are in conflict or dependency
• Coarse granularity shows minimal conflict/dependency reasons for each conflicting/dependent pair of rules
• Fine granularity shows all conflict/dependency reasons for each conflicting/dependent pair of rules (which are obtained by different combinations of minimal ones)
• Very Fine Granularity is equivalent to critical pairs, as obtained from Critical Pair Analysis (CPA). Under the hood, MultiCDA uses an existing CPA implementation.

Each granularity comes with a certain type of analysis result: Binary granularity just gives a list of conflicting/dependent rules. Coarse and Fine granularity come with a list of conflict/dependency reasons for each rule pair, displaying only elements directly involved in a conflict or dependency. Very fine granularity leads to the reporting of critical pairs, each describing a minimal conflict or dependency situation, consisting of the first rule and the second rule as well as a minimal model affected by the conflict or dependency. Fine and Very Fine granularity are almost identical, except for certain variations in critical pairs that are not important for most applications.

Starting and configuring the analysis

You can execute the MultiCDA from both .henshin and .henshin_diagram files by right-clicking on it and clicking Conflict and dependency analysis beneath Henshin option, as shown in Fig. 1.

In the first page of the wizard, shows in Fig. 2, you can select first and second rules that should be analysed. There is a option to select the same rules for the right side as selected on the left side. If the Henshin file has only one rule, it is automatically selected for both sides. You can move to the next step if you choose at least one rule on each side and at least one of the kinds of the Analysis: conflict and dependency. Each rule from the left side will be analysed with each rule from the right side.

Fig. 3: Second page of the MultiCDA wizard: choosing a granularity

In the next step the analysis depth has to be set. In Fig. 3 you can see several options to do that. The top three; Binary, coarse and fine granularity levels are provided by the MultiCDA. The fourth granularity Very Fine uses the CPA to calculate the conflicts and dependencies. This is divided into three types of calculation. The first one (initial \ref{lcp}s) returns the same amount of Conflicts as the fine granularity. The second kind (essential \ref{lcp}s) also contains critical pairs with boundary nodes. The last kind calculates all possible combinations of mappings of the graph elements that lead to a conflict or dependency.

In the right pane, for the first three granularities, you can choose to export the results in an HTML table. There is normal and abstract way of presenting the results. The normal table is shown in the figure 4. On the left there are the rules that run first and above the ones that run second. In addition to the conflict types, the number of conflicts is displayed. The abstract table (figure 5) is showing the results between the types of rules. A kind is set with respect to the actions that exist in a rule. Each action is assigned an ID, which is explained in the legend below the table. For example, Rule d3 (Figure \ref{f:rules}) assigns d3 as it consists of both preserve and delete elements. The abstract table is well suited for the rough overview because the rules are strongly summarized and there are no empty rows or columns. The number on the right side of each conflict kind indicates the number of existing conflicts. Reason kinds without number mean, that only one conflict of this kind was created by the given pair of rules.

Fig. 4: Full table of all rules from the dataset displayed in figure X

File:Henshin MultiCDA doc html.pngA

Fig. 5: Abstract table of all rules from the dataset displayed in figure X

The execution of the analysis can be done by both MultiCDA and CPA analysis features. The process can be abort at any time by clicking the red rectangle on the right side of the progress bar presented in figure 6. After an abort has been made, it can only be executed after the processing of the current rule pair. To provide the abort functionality, the rule pairs had to be passed to the CPA and MultiCDA individually and not at ones as in the past. This leads to a degradation of the performance of the CPA method but not MultiCDA. Since the CPA has previously worked with bad runtimes, it was decided to accept the deterioration of the runtime due to the abort function.

File:Henshin MultiCDA doc 3.png1

Fig. 6: Execution of the MultiCDA analysis

The display shows the remaining time in addition to the percentage. Also both the rule pair currently being analyzed and the type of analysis being performed are displayed.

Fig. 7: Representation of the result. Left is a delete-delete conflict reason and right the same critical pair are displayed

Inspecting results

After calculation is completed, the results are listed in the d3 window. The upper level is the granularity kind. These contain the rule pairs that are in conflict to each other. With the granularity Very fine, there is a further division into the three analysis types before the rule pairs are displayed. Each rule pair contains a set of conflicts that can be viewed by double-clicking. Figure 7 illustrates two equal conflicts, one calculated with MultiCDA and the other with CPA. At this point, it is easy to see that the result of the MultiCDA is clearer, since only the conflict elements are shown there. Whereas CPA represents the minimum graph necessary for the execution of both rules. For this reason, the result can be confusing with complicated rules.

Figure 8 shows how the data in the project tree view is stored. In the folder containing the Henshin file that was used for the analysis, the result folder will be created. The new folders name is the date and time the analysis took place. Unlike the d3 view, this folder contains all the Reasons and atoms together in a rule pair folder. The html tables are saved in the new folder and can be simply clicked on. The a behind the granularity name means it is an abstract representation of the results.

Figure 9 shows the representation of the conflicting attributes. Since an attribute has the property to change the value, it was decided to show both the value of \ref{llhs} and \ref{lrhs}. The change is represented by an arrow ->. For example, the representation true->false means that the value of d3 has changed to d3. The value of the attribute from the first rule is separated from the second rule by an underscore, just as in the case of nodes. The x represents the nonexistent value of attribute.

Fig. 8: Storage of results and tables

Fig. 9: Representation of conflicts on attributes