Keywords

These keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

1 Introduction

Model transformation is a key enabling technology for Model-Driven Engineering. Algebraic graph transformation is one of the main paradigms in this field, enabling a high-level, declarative specification based on graph rewriting rules [1]. Non-trivial graph transformation systems often contain rules that are substantially similar to each other. Such rules may share a large bulk of intended actions, while differing only marginally, leading to a large amount of pattern duplications.

Several approaches can be used to capture such families of rules while avoiding pattern duplication. Many of these approaches embody a composition-based paradigm: rule variants are assembled from fragmentary building blocks. In the case of rule inheritance [2], the implementation of a rule family comprises a hierarchy of a base rule with sub-rules. Rule refinement [3] extends this concept by supporting multiple base rules and the capability to modify super-rules. While these approaches clearly avoid pattern duplication, they may entail managing a large number of interrelated fragments. Their semantics are often intricate; a scheduling mechanism may be required to handle conflicts during composition.

Inspired by product line engineering approaches [4], we propose variability-based (VB) rules, an annotative approach to managing families of rules. The key idea is to encode a family of rules as one VB rule. Portions of this VB rule are annotated with presence conditions to assign them to a subset of the encoded rules. The portion common to all rules, called the base rule, is not annotated.

Example. Consider a family of three in-place transformation rules. The rules, shown in Fig. 1, express variants of the 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.

Fig. 1.
figure 1

Three variants of the move method refactoring.

Full size image
Fig. 2.
figure 2

Variability-based rule expressing the same three variants.

Full size image

These three rule variants can be expressed using the VB rule shown in Fig. 2. Several elements are annotated with presence conditions over the literals wrapper and deprecate. The variants are obtained by configuring the rule, i.e., binding these literals 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 Fig. 1. 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 variability model, shown in the title bar, requiring wrapper to be true if deprecate is true.

This example highlights several maintainability benefits of VB rules: (i) During maintenance, all included variants are viewed and edited at once. While evidently convenient, this editing style may also be less error-prone: Fixing the same bug in multiple rules manually may lead to residual bugs not being considered. (ii) The representation is more compact, in terms of the number of rules, the total number of rule elements and the used amount of space. While compactness does not necessarily equal better readability, it is still an explicit goal of compositional approaches [3]. (iii) In contrast to compositional approaches, no additional mechanism is needed to glue fragments together, adding to the compactness of the specification. The structure of each variant is directly present; maintainers are not required to obtain a mental representation by assembling fragments.

Conversely, the example also illustrates a set of drawbacks of VB rules. (i) The use of presence conditions creates a “noisy” or “cluttered” impression, impairing readability. To make matters worse, these presence conditions are required to be edited manually, a tedious and potentially error-prone process. (ii) The rule size in terms of average number of elements per rule is greater. A detrimental effect of diagram size on readability is reported in [5]. (iii) To understand individual rule variants, developers are required to identify and focus on selected portions, posing a high cognitive effort. While color-coding would be helpful to mitigate this issue, it is at least complicated if not unavailable due to existing color-coding.

In this work, we address the following research question: How can the efficient viewing and editing of variability-based rules be facilitated? Our key idea is to provide dynamic representations suitable to the task at hand rather than one static representation – an idea inspired by the paradigms of filtered editing [6] and virtual separation of concerns [7]. We propose a tool environment that offers views on rule variants selected by the user. These views are helpful to mitigate the identified drawbacks by (i) removing the need to read and edit presence conditions, (ii) being smaller in size, and (iii) reducing the cognitive effort in deriving mental representations. In addition, we provide support for converting a legacy rule set into a VB rule with little manual effort. The basic concepts of VB rules and their automatic creation have been introduced elsewhere [8–10].

We have implemented our tool environment on top of Henshin [11], a model transformation language based on algebraic graph transformations. Lifting the concepts proposed in this work to other languages and paradigms is desirable, but left to future work. The tool and a description of its use can be found at https://www.uni-marburg.de/fb12/swt/forschung/software/varhenshin/.

2 Variability-Based Rules

In this section, we briefly revisit the main concepts of variability-based rules. We assume the reader to be familiar with double-pushout graph transformation rules, such as those shown in Fig. 1. The underlying graph kind may include typing and attributes since these concepts are orthogonal to variability. We further use the concept of subrule, a rule that can be embedded into a larger rule in an injective manner. A detailed account of these concepts is given in [10].

Definition 1

(Variability-based (VB) rule). Given a set of atomic terms V, called variability points, a VB rule \(\check{r} = (r, S, vm, pc)\) consists of a rule r, a set S of subrules of r, a propositional term \(vm \in \mathcal {L}_V\) and a function \(pc: S \cup \{ r \} \rightarrow \mathcal {L}_V\), where \(\mathcal {L}_V\) is the set of propositional terms over V. Term vm is called variability model. Function pc defines presence conditions for subrules s.t. pc(r) is true and \(\forall s \subseteq s': pc(s') \implies pc(s)\). The base rule is the intersection of all subrules.

Figure 2 shows a VB rule over variability points {wrapper, deprecate}. The rule is shown in a compact representation where subrules are not shown explicitly, but denoted using element presence conditions. Rule r is the entire rule, ignoring annotations. S comprises a subrule for each propositional term over V. Each subrule contains those elements whose presence conditions are implied by its own presence condition. For instance, subrule s with \(pc(s)=wrapper \wedge \lnot deprecate\) contains all elements annotated with wrapper and without annotations, but not those annotated with deprecate. The variability model is deprecate \(\rightarrow \) wrapper.

Definition 2

(Configuration). Let a VB rule \(\check{r} = (r, S, vm, pc)\) over V be given. A configuration is a total function \( \textit{c} : V \rightarrow \{\textit{true}, \textit{false}\}\). A configuration \(\textit{c}\) satisfies a term \(t \in \mathcal {L}_V\) if t evaluates to \(\textit{true}\) when each variable v in t is substituted by \(\textit{c}(v)\). A configuration \(\textit{c}\) is valid if \(\textit{c}\) satisfies vm.

In the example, {wrapper=true; deprecate=false} is a valid configuration, satisfying the presence condition wrapper, but not the presence condition deprecate.

Definition 3

(Rule variant). For a valid configuration c, there exists a unique set of subrules \(S_c \subseteq S\) s.t. \(\forall s \in S:\) \(s \in S_c\) iff c satisfies pc(s). Gluing together all elements contained in one of these subrules yields a rule \(r_c\), called rule variant induced by c.

The example VB rule can be used to produce three variants; details are provided in the previous description of the example. Categorically, the gluing can be expressed as a consecutive multi-pullback and multi-pushout construction [10].

There are two main application scenarios for VB rules. First, a specific user intention may lead to the selection and application of one particular rule variant. For instance, in the example, the user may configure the rule so that it produces a wrapper method. Such an external configuration process leads to an individual rule being applied in the classic way. Second, all rules in a rule set may be applied simultaneously. Such rule sets are found in batch transformation scenarios, such as translation or migration suites. In this case, configurations can be set internally by the transformation engine. This approach allows to consider the base rule of all variants at once, leading to considerable performance savings [8].

3 Main Features

In this section, we present the main features of our tool environment. The design of these features is informed by Cognitive Dimension [12] (CD), a framework of usability dimensions for visual programming environments. First, we give an overview of the features, relating each to the CD framework. Second, we exemplify the use of these features from the user perspective.

  • View specific rule variants: Each variant expressed in a VB rule corresponds to a configuration, a binding of all variability points to true or false. To view specific variants, we provide a live configuration feature: The user performs a partial or total binding of variability points, leading to immediate feedback. Irrelevant rule elements can be either turned invisible or toned down. The former option helps the user during the comprehension of individual variants. The latter one facilitates the comparison of variants.

    This feature addresses several cognitive dimensions: The visibility of rule variants is increased. The need for hard mental operations is reduced by shielding users from the cognitive effort of deriving variants. Notational diffuseness is reduced as fewer different symbols are needed to capture variability.

  • Edit rule variants: A crucial issue of editing VB rules is the requirement to have users edit presence conditions, a tedious and error-prone process. We provide features to mitigate this issue: When creating a new element, a presence condition corresponding to the currently selected configuration is assigned automatically. We also support the reassigning of elements to different variants by moving them to a more general or specific configuration (i.e., one where more or less variability points are unbound).

    By lifting the abstraction level from editing presence conditions to moving elements between variants, we aim to reduce error-proneness. The capability to move multiple elements also reduces viscosity, the resistance to change.

  • Explore relationships between rule variants: We provide multiple features to support exploring multiple variants and their interrelations. First, a favorites feature allows rapid switching between variants. Second, a quick access feature provides instant access to distinguished variants such as the base rule and the maximum rule. Third, an auto-completion feature reduces the configuration effort of by inferring certain open bindings automatically. These features are key to increasing role-expressiveness, the ease of understanding “how each component [...] relates to the whole” [12].

  • Manage variability points: We provide a dedicated viewer component for the management of variability points. Using this viewer, variability points can be created and deleted. To ensure consistency, presence conditions referring to the deleted variability point can be updated automatically.

    This dedicated component inceases the visibility of variability management.

  • Sanitize legacy rule sets: Legacy rule sets may exhibit a high degree of pattern duplication, notably, if they were devised in a copy-and-paste manner. To sanitize such rule sets, we provide clone detection and merge refactoring features. Clone detection allows identifying cloned portions in a set of rules. These portions may serve as input to merge refactoring, a feature that creates VB rules automatically, including an optimization to preserve layout information from the input rules. We present this technique in [9].

    This feature shields from premature commitment: VB rules do not have to be devised from scratch. Users may develop rules in an ad-hoc manner and decide to use VB rules later, while retaining key layout information.

Fig. 3.
figure 3

Our tool environment from the user perspective.

Full size image

User Perspective. Our tool environment is integrated with the default user interface of Henshin. The main components of this user interface, a graphical editor and its attached properties view, are shown in the left of Fig. 3. As custom components, we provide the variability and sanitizing views, shown in the right. The variability view comprises features for the definition and configuration of variability points. The variant produced from the current configuration is displayed in the editor. The sanitizing view can be used to sanitize legacy transformations.

Variability view. The variability view allows variability points in a rule to be created and deleted. To view and edit variants individually, the user configures the rule by setting the bindings for these variability points. Three literals are supported: true, false, and unbound. Per default, each variability point is unbound, yielding the maximal rule, all elements regardless of their annotations. Configurations are validated against the given variability model, deprecate \(\rightarrow \) wrapper in this case. Invalid configurations and rules lead to error messages being displayed.

Fig. 4.
figure 4

Variability view with favorites menu.

Full size image

To navigate variants efficiently, frequently used configurations can be saved as favorites using the button in the toolbar. The star appears in yellow if a favored configuration is currently active. Each configuration has a user-specified name. In Fig. 4, the user has created two favorites, WrapperWithDeprecate and WrapperWithoutDeprecate, the latter one being active. Upon selection, the configuration is loaded and shown in the table at the bottom of the view.

A view mode feature allows to access distinguished variants rapidly. In the maximum rule mode, represented by the icon, all elements included in the rule are shown regardless of the configuration. In the variant mode elements absent in the current configuration are concealed. In the base rule mode elements with a non-empty presence condition are concealed.

To further improve the handling of variability, the view allows the users to choose a concealing strategy, depicted in Fig. 5. First, elements can be turned invisible. This avoids a cluttered representation of the rule and lets users focus on the variant at hand. On the other hand, to allow the comparison of a variant with the full rule, users may choose to have the elements toned down instead.

Fig. 5.
figure 5

Concealing strategies.

Full size image

Using the button, users can select an editing mode to define which variants are affected by edits to the rule. The supported options are: all variants, variants included in the selected configuration, or variants associated to the current view mode. In particular, the editing mode determines which presence condition is assigned during the addition or deletion of elements to a rule.

Sanitizing view. The sanitizing view, shown in the lower right of Fig. 6, supports two operations for sanitizing legacy rule sets: clone detection and merging. Clone detection allows the identification of duplications in the rule set. The result is a list of clone groups. To display the most relevant clone groups prominently, the clone groups are ordered by their size, i.e., the number of common elements. Users can inspect the duplication interactively; when a rule is selected, the affected portions in the rule are focused and highlighted. Internally, clone detection aims to identify isomorphic sub-graphs, a computationally expensive problem in general. To ensure reasonable response times, our approach uses a heuristics provided by ConQAT [13], a clone detection technique originally introduced for Simulink models. We discuss our adaptation of this technique elsewhere [14].

Fig. 6.
figure 6

Sanitizing view.

Full size image

The merge button enables the merge refactoring feature. An algorithm is executed to construct a semantically equivalent variability-based rule automatically, using the identified duplication as base rule and annotating the variant-specific parts with their rule names [9]. The user can inspect and post-process the refactoring result using the viewing and editing features. In case that the result is not satisfactory, the process can be undone.

Context menus. Additional context menu entries allow to manage variability at the level of individual elements. Multiple nodes, edges and attributes can be selected and moved to a different configuration simultaneously.

4 Architecture and Implementation

In this section, we describe the architecture of our tool and our design principles during the implementation.

Fig. 7.
figure 7

Architecture.

Full size image

We give an overview of the architecture in Fig. 7. The novel features presented in this work are encapsulated by Variability UI, an integrating layer on top of the UI, Clone Detection, Merging and Variability extensions for the Henshin language core. To combine the Henshin UI with the variability implementation first introduced in [8], the Variability UI provides the variability view and its editor integration. Clone detection and merging are made available to users in the Sanitizing View. The merging component acts as a bridge between the clone detection and variability extensions: It enables the conversion of rules affected by cloning to variability-based rules. GMF, GEF, EMF and Eclipse are featured as underlying frameworks. The Henshin language is based on an EMF meta-model. The Henshin UI comprises a GMF-based editor to enable the visual viewing and editing of transformations.

The main design goal in our architectural design was non-intrusiveness: Changing the Henshin core and UI should be avoided where possible. The rationale for this design goal was to keep the Henshin language core, its UI and analysis functionality as simple as possible. Variability is deployed as a drop-in language extension, orthogonal to additional extensions, such as the existing support for Triple Graph Grammars [15] or possible future support for uncertainty [16]. Including multiple of these extensions might lead to feature interactions that need to be addressed explicitly by the designers of the extensions.

To define language extensions in a non-intrusive way, the Henshin meta-model provides a flexible annotation mechanism. Any element contained in a transformation may be annotated with key-value pairs of strings. The language extension at hand is responsible for processing these annotations. This concept allowed us to implement variability-based rules in the variability extension alone, without modifying the language core.

5 Related Work

Model Transformation Reuse. There are two groups of reuse approaches for model transformations. The first group focuses on intra-transformation reuse [17], the reuse of artifacts within the same transformation. In this group, many approaches are composition-based: Rule refinement, the modularization of a rule into a set of fragmentary rules, has been implemented in the eMoflon tool [18]. The modularization of a graph transformation rules into multiple aspects is another compositional approach [19]. A feature-based composition approach for the reuse of ATL transformations has been proposed by Sijtema [20]. Many of these approaches do not provide an automated tool to split a legacy rule into a set of composition fragments, an issue that might be addressed by applying a general-purpose splitting tool [21, 22]. An important annotative approach is rule amalgamation. While this approach allows the specification of mandatory and optional parts in a rule, in contrast to VB rules, the optional parts are matched and applied as often as possible. VB rules provide the capability to assign one element to multiple variants, which is not supported in amalgamation. Amalgamation has been implemented in the AToM3 meta-modeling tool [23] and the eMoflon Triple Graph Grammar tool [24].

The second group focuses on inter-transformation reuse [17], the reuse of artifacts across multiple transformations. VCT [25] is a comprehensive toolkit that allows to accommodate variability in a chain of multiple transformations and to compose larger transformations from smaller ones. Cuadrado et al. [26] have introduced a component model to orchestrate the reuse of model transformations across multiple different modeling languages. Their Bentō [27] tool provides support for generic rules for ATL transformations. These generic rules are typed over concepts, abstract meta-models. To consider a new scenario, concepts are instantiated by binding them to the types of the required meta-model. To increase the flexibility of this approach, de Lara et al. propose an extension that accounts for heterogeneity between concepts and meta-models [28]. Criado et al. [29] propose to reuse existing transformations by annotating them. These works are orthogonal to ours as they address a different reuse scenario.

Implementation Approaches to Software Product Lines. We adopted the distinction of annotative and composition-based mechanisms from software product line (SPL) engineering [4], where it refers to different approaches to implementing a SPL. An important composition-based approach is Feature-Oriented Programming [30], in which a SPL is developed by dividing its specification into features and implementing each feature as a separate module. The AHEAD [31] tool made this approach applicable for Java. An example for an annotative approach are #ifdef directives: Portions of the source code are annotated with variability conditions and optionally removed during compilation. Virtual separation of concerns (VSoC) is a paradigm aiming to combine the benefits of both approaches by means of tool support [7]. In the CIDE tool [4], users are provided custom views, visual representations, and variability-aware type checks. Based on the VSoC paradigm, Walkingshaw et al. [32] propose an editing model for variational software based on an isolation principle: Edits to a view shall only affect the variants associated with this view. We adopt this principle in one of the editing modes of our tool. In a related work of Schwägerl et al. [33], the scope of variants affected by an edit is set using a separate configuration.

The FeatureIDE [34] framework integrates many of these approaches and makes them available during the entire development cycle. Its aim is to establish a uniformity principle of managing variability consistently in all design, implementation, and documentation artifacts. The integration of our approach into this framework is a promising avenue for future work.

Usability-oriented Model Transformation. As we aim to improve the maintainability of complex rules, our work is related to usability-oriented model transformation, a field of research addressed in [35]. Based on the premise that users may prefer mature model editors to experimental transformation tools, the authors provide a new modeling language that can be instantiated in any given model editor and mapped back to a host transformation language. This work is complementary to ours since we aim to contribute to the maturity of model transformation tools instead of replacing them.

6 Future Work and Additional Improvement

The most important task left to future work is a user study to validate the claim that our tool environment improves usability during editing. Such a study would substantiate our anecdotic evidence that the development of rule families without a dedicated reuse concept is a highly inconvenient and error-prone task. Furthermore, we are eliciting future usability improvements. First, the visibility of distinguished variants, such as the base rule, can be further increased by providing a “hot corner” feature. Implementing such a feature proves to be challenging due to limitations of the underlying editor framework. Second, relationships between variability points are currently expressed using a logical formula. In product line engineering, dedicated formalism have emerged to capture variability, the most important one being feature models [36]. Combining feature models with VB rules seems a promising avenue for future work.