Difference between revisions of "Henshin/Conflict and Dependency Analysis"

Revision as of 09:32, 3 January 2020

Conflict and dependency analysis

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
• Coarse granularity shows the minimum conflict causes for each conflicting pair of rules
• Fine granularity extends coarse granularity by listing possible combinations of minimal conflicts
• Very Fine Granularity is equivalent to critical pairs, as obtained from Critical Pair Analysis (CPA).

In this way, two types of conflicts and dependencies are accommodated in one feature: Reasons and Critical Pairs. Reason display only the elements that are conflicting with each other. A critical pair describes 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.

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

You can execute the MultiCDA from both henshin and diagram files by right-clicking on it and clicking Conflict and dependency analysis beneath Henshin option.

Fig. 2: First page of the MultiCDA wizard. All rules containing in the selected Henshin File will be displayed on both sides

In the first page of the wizard 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. Choose the granularity of the Analysis

In the next step the analysis depth has to be set. In the figure 3 you can see several options to do that. The top three; Binary, coarse and fine granularities are provided by the LCDA. The fourth granularity Very Fine uses the LCPA 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

The execution of the analysis can be done by both LCDA and LCPA 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 LCPA and LCDA individually and not at ones as in the past. This leads to a degradation of the performance of the LCPA method but not LCDA. Since the LCPA has previously worked with bad runtimes, it was decided to accept the deterioration of the runtime due to the abort function.

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

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 LCDA and the other with LCPA. At this point, it is easy to see that the result of the LCDA is clearer, since only the conflict elements are shown there. Whereas LCPA 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