Difference between revisions of "Henshin/Critical Pair Analysis"
m (replaced "execution " by "applicability") |
|||
Line 73: | Line 73: | ||
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. | 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. | ||
+ | |||
+ | [[Category:Henshin]] |
Revision as of 09:27, 25 May 2016
The critical pair analysis (CPA) enables to find all potential conflicts and dependencies of a set of transformation rules. The results of the analyses are critical pairs, of which each report on a potential conflict or dependency between two transformation rules. A critical pair describes a minimal 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
The CPA is able to analyze two kinds of relations among transformation rules, conflicts and dependencies. Conflicts reveal the relationship among two rules that the execution of the first transformation rule disables the applicability of the second transformation rule. Dependencies on the other hand reveal the relationship among two transformation rules that 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 the minimal model. Applying the first rule of the two involved rules on the minimal model leads to changed result model. While the second rule could have been applied on the minimal model of the beginning, it’s no more applicable on the result model. Various situations can be encountered, which are described by the following different kinds of conflicts.
- 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 in consequence of the missing element.
- 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 minimal model, accordingly.
- Change-use-conflict: A change-use-conflict describes a similar situation to the delete-use-case with the focus on the values of EAttributes. A change-use-conflict describes a situation in which the application of the first transformation rule changes the value of an EAttribute. The second transformation is then no more applicable since it requires the EAttribute with the value before it had been changed.
- Change-forbid-conflict: Change-forbid-conflicts describe the situation where the application of the first transformation rule changes the value of an EAttribute in such a way, that it equals to the forbidden value specified in the second transformation rule. The second transformation rule becomes inapplicable since it requires that the EAttribute has any value except the one that has been set by the first transformation 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 transformation and is suitable to apply the second transformation on it. 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 transformation rule. Based on the creation of the element the second rule becomes applicable. It doesn’t matter how the second transformation rule deals with the created element, if it preserves it, requires it by a positive application condition (PAC) or deletes it. The minimal model contains the created element which is required to apply the second transformation rule.
- Delete-forbid-dependency: A delete-forbid-dependency describes the situation of the two involved transformation rules, that the first rule deletes an element (EClass or EReference) which is forbidden by the second rule. The second transformation rule becomes applicable by fulfilling its negative application condition (NAC) which forbids the presence of the before deleted element. The minimal model is the instance after the application of the first transformation rule, such that the second transformation 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 that the second transformation rule becomes applicable by the application of the first transformation rule before. The root cause is the change of the value of an EAttribute such that it fulfils the pattern of the second transformation rule.
- Change-forbid-dependency: The change-forbid-dependency describes the situation that the first transformation rule changes the value of an EAttribute which is forbidden by the second transformation rule. Before the application of the first transformation rule the value of the EAttribute is exactly the one which is forbidden by the second transformation rule. The minimal model is the result after applying the first transformation 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 hereinafter.
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 domain model, for example outplace model transformations involving more than one Ecore instance. Affected transformation rules are identified by more than one import in den Henshin Module.
- Model transformations 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 or for example in the process of developing them. It can be invoked by a right-click on at least one *.henshin file in the Package Explorer and selecting Henshin→Calculate Critical Pairs. Even the selection of multiple files is supported but the user have to be aware that those are specified for a common Ecore model.
To execute the analysis first of all the transformation rules have to be selected and the user have to decide if he is interested in conflicts, dependencies or both. Be carefull with the number of selected transformation rules! The required time for the analysis depends on the number of transformation rules and the size of each transformation rule.
After selecting at least one transformation rule and at least on kind of relationship to analyse the analysis can be started by hitting the Finish button. Alternative 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.