Skip to main content
Jump to: navigation, search


< Henshin
Revision as of 08:15, 27 September 2019 by (Talk | contribs) (Created page)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Variability in Henshin rules allows to express families of rules that are substantially similar to each other in a compact representation. This compact representation enables the convenient editing of multiple rule variants at once, as well as their efficient execution.


Consider a family of three refactoringrules. The rules, shown in the left image below, express variants of the \textit{move method} refactoring for class models. The first rule specifies the relocation of a method between two classes. The second one additionally creates a wrapper method of the same name in the~source class. The third one adds an annotation to mark the wrapper method as~deprecated.

  • Three similar rules
  • One rule with variability

These three rule variants can be expressed using one rule with variability, shown in the right figure. Several elements are annotated with presence conditions over the features wrapper and deprecate. The variants are obtained by configuring the rule, i.e., binding the features to true or false and removing elements whose presence condition evaluates to false. Configuration {wrapper=false; deprecate=false} yields the base rule, a rule isomorphic to rule moveMethod in the Figure above. The rules induced by the configurations {wrapper=true; deprecate=false} and {wrapper=true; deprecate=true} produce the additional variants. To avoid the illegal configuration {wrapper=false; deprecate=true}, the rule has a constraint called feature model, shown in the title bar, requiring wrapper to be true if deprecate is true.

Back to the top