Difference between revisions of "Henshin/Critical Pair Analysis"
(Created page with "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 pair...") |
|||
Line 10: | Line 10: | ||
=== Conflicts === | === 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. | 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 | + | |
− | * Produce-forbid-conflict | + | * '''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. |
− | * Change-use-conflict | + | |
− | * Change-forbid-conflict | + | * '''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 === | === 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 == | == 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 === | === 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 === | === 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. | ||
== CPA Wizard == | == CPA Wizard == | ||
− | == CPA API== | + | A Wizard supports |
+ | |||
+ | To support | ||
+ | |||
+ | |||
+ | == CPA API == |
Revision as of 11:42, 22 March 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 execution 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.
CPA Wizard
A Wizard supports
To support