Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Henshin/Critical Pair Analysis
Henshin's critical pair analysis (CPA) feature enables the detection of all potential conflicts and dependencies of a set of transformation rules. The results of the analysis is a set of critical pairs, each reporting on a potential conflict or dependency between two transformation rules. 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.
As the transformations in Henshin for the Eclipse Modeling Framework are formally based on graph transformations, the critical pair analysis is also based on algebraic graph transformations.
Contents
Kinds of conflicts and dependencies
Two kinds of relations among transformation rules can be detected, conflicts and dependencies. In the case of a conflict, the execution of the first rule disables the applicability of the second rule. In the case of a dependency, the execution of the first rule enables the execution of the second rule on the resulting model.
Conflicts
A conflict generally describes a situation in which the two involved rules are both applicable on a minimal model. Applying the first of these rules on the minimal model leads to a changed result model. While the second rule could have been applied on the model in the beginning, it is no more applicable on the result model. In what follows, possible kinds of conflicts are described.
- Delete-use-conflict: The first rule deletes at least one element (an EClass or EReference) of the minimal model, such that the second rule is no more applicable.
- Produce-forbid-conflict: The first rule creates at least one element (EClass or EReference) which is forbidden by the second rule. The second rule becomes inapplicable on the resulting model, accordingly.
- Change-use-conflict: A change-use-conflict describes a similar situation to the delete-use-case, but with the focus on the values of EAttributes: the application of the first rule changes the value of an EAttribute. The second transformation is then no more applicable since it is only applicable when the old value is present.
- Change-forbid-conflict: Change-forbid-conflicts describe the situation where the application of the first rule changes the value of an EAttribute in such a way that it becomes equal to a forbidden value specified in the second rule.
Dependencies
A dependency generally describes a situation in which the application of the second transformation rule becomes enabled by applying the first transformation rule. The minimal model is the result of the application of the first rule and it allows the second rule to be applied. Various situations can be encountered, which are described by the following different kinds of dependencies.
- Produce-use-dependency: A produce-use-dependency describes the situation where the application of the first rule creates a new element (EClass or EReference) which is required by the second rule. Based on the creation of the element the second rule becomes applicable. Note that it is irrelevant how the second rule deals with the created element, that is, if the element is preserved or deleted. The minimal model contains the created element which is required to apply the second rule.
- Delete-forbid-dependency: A delete-forbid-dependency describes the situation where the first rule deletes an element (EClass or EReference) which is forbidden by the second rule. The second rule becomes applicable since its negative application condition (NAC), which forbids the presence of the element, is now fulfilled. The minimal model is the instance after the application of the first rule, such that the second rule becomes applicable on it.
- Change-use-dependency: The change-use-dependency is similar to the produce-use-dependency with the focus on the value of an EAttribute. The dependency describes the situation where the second rule becomes applicable after the application of the first rule. The root cause is the change of the value of an EAttribute such that it fulfills the pattern of the second rule.
- Change-forbid-dependency: The change-forbid-dependency describes the situation where the first rule changes an EAttribute value that is forbidden by the second rule. With the new value, the second rule becomes applicable. The minimal model is the result after applying the first rule.
Features
The CPA for Henshin supports several features of the model transformation language and the Eclipse Modeling Framework. The supported and unsupported functionalities are listed in what follows.
Supported Features
- Basic model transformations involving the actions preserve, create and delete of EClasses and EReferences as well as the change of the values of EAttributes
- Positive application conditions (PAC) and negative application conditions (NAC), limited to the usual situation of AND concatination. In consequence this means application conditions containing OR and XOR ModelElements are not supported.
- Ecore modeling concepts of inheritance and abstract eClasses and eOpposite references.
Unsupported Features
- Model transformations for more than one meta-model, for example outplace model transformations involving more than one Ecore instance. Affected rules are identified by more than one import in their containing module.
- Multi-rules (formally, rules with amalgamtion).
- Transformation units.
Applying the Analysis
The analysis can be invoked either using a wizard or programmatically using an API.
CPA Wizard
The wizard enables the quick and easy usage of the critical pair analysis to find conflicts and dependencies of transformation systems. It can be invoked by a right-click on at least one *.henshin file in the Package Explorer and selecting Henshin→Calculate Critical Pairs. The selection of multiple files is supported, but the user needs to ensure that all included rules are specified for the same meta-model.
To execute the analysis, the transformation rules have to be selected and the user needs to decide if conflicts, dependencies, or both kinds of relationships are to be considered. The required time for the analysis depends on the number of transformation rules and the size of each rule. A large number of selected rules can lead to considerable execution times!
After selecting at least one rule and at least one kind of relationship, the analysis can be started using the Finish button. Alternatively, the Next button leads to the second page Option Setting for advanced configuration.
After the analysis finished all critical pairs, regarding the configuration in the wizard, are listed in the CPA Result View. The critical pairs are grouped by the rule combinations of which they consist. This means that all analysed conflicts and dependencies of a rule combination are listed together and can be viewed by expanding a rule combination. Each single critical pair can be further investigated, double-clicking or pressing the enter button opens the critical pair in the Critical Pair Editor. Each critical pair consists of the first rule on the left side, the second rule on the right side and the minimal model in between. Additionally the results of the analysis are saved in the workspace within a directory tree. To open a critical pair from the workspace right-click on a *.henshinCp file in the Package Explorer and select Henshin→Open Critical Pair.
CPA API
First of all the transformation rules must have been loaded. A description is given in the Henshin Interpreter page.
Depending on the required results one or two lists of the transformation rules to analyse have to be set up. To get all conflicts or dependencies within a set of rules a single list of them is sufficient. When only dependencies or conflicts are required for a dedicated set of rules as first rule or second rule, a list of first rules (r1) and a list of second rules (r2) is required to initiate the analysis. Even though this could be achieved by analysing all transformation rules and filtering the results afterwards you should consider that superfluous analysis might be very time consuming.
Another parameter required for the initialisation of the analysis is a CPAOptions object. It’s easy to obtain by its default constructor and may be adapted by its Setter and Getter methods.
To initialize the analysis first of all Henshins Critical Pair Analysis have to be instantiated by the default constructor of the class CpaByAGG. Using the aforementioned list/s of transformation rules and an CPAOptions object the analysis can be initialized with the suitable init(…)-method. It has to be considered that the init(…)-method might throw an UnsupportedRuleException. The method check(List<Rule> rules) might be used to check rules to analyse before the initialisation.
After successful initialisation the methods runConflictAnalysis() or runDependencyAnalysis() start the analysis. Additionally another version of both methods is available supporting a ProgressMonitor which provides a rough estimation of the analysis progress.