8.4.1.1 Delta language creation

To transform a realization artifact of a particular source language through delta actions, delta modeling requires a respective delta language that supplies suitable delta operations, e.g., DeltaJava [29,47] for Java. One of the core functionalities of DeltaEcore is the generation of a delta language from the metamodel of an arbitrary source language. DeltaEcore provides the majority of a custom delta language through its Common Base Delta Language (CBDL), which contains language constructs to define, reference, and require delta modules, etc., that are independent of the concrete source language. To create a custom delta language, it is necessary to interface with the respective source language. For this purpose, DeltaEcore permits the specification of so-called delta dialects, i.e., specifications of the delta operations that should be provided for transforming a realization artifact of the source language within a delta module. A custom delta language in DeltaEcore consists of the combination of the CBDL with the delta dialect for the source language. Fig. 8.6 shows an excerpt from the delta dialect for Ecore models as used within the EPL running example.

In the configuration part, a delta dialect has to tie to the source language via the keyword metaModel by providing the unique model URI of the source language. Furthermore, it allows to optionally specify an identifierResolver, which is used to transform textual names provided between angle brackets (<...>) within a delta module (see Section 8.4.1.2) to elements of the modified realization artifact that can then be used in delta actions. In the deltaOperations part, a delta dialect allows to provide a list of delta operations that can then be used as delta actions within delta modules to transform a realization artifact. The example of Fig. 8.6 shows delta operations to add and remove a class but also to modify its properties, e.g., by making it abstract or changing its super types.

DeltaEcore offers capacities to analyze and (mostly) automatically create delta languages suitable for a particular source language [39]. For this purpose, the metamodel is traversed for suitable elements and so-called standard delta operations to add, modify, and remove values for these elements are created automatically with predefined semantics, e.g., to set the value for nonconstant attributes. To extend a delta dialect beyond the capabilities of the atomic standard delta operations, it is possible to specify custom delta operations with user-defined semantics, e.g., the delta dialect for Ecore in Fig. 8.6 contains one such method to set the package of a classifier, which is only possible indirectly due to the structure of Ecore.

To facilitate execution of delta actions associated with the respective delta operations from the delta dialect, DeltaEcore generates an interpreter specific to the custom delta language. For standard delta operations, the interpreter contains a full implementation due to their defined standard semantics. For custom delta operations, the interpreter contains stub methods whose body has to be implemented by the creator of the delta language to reflect the semantics of the operation.

Note that delta language creation has to be performed only once for each source language, and in the case of Ecore a suitable delta language already exists, which is delivered with the tool suite.

8.4.1.2 Software product line definition

With a suitable delta language in place, it is possible to specify the artifacts needed by DeltaEcore to create an SPL definition. In particular, these are a set of delta modules, a central mapping model that contains all application conditions, and, optionally, a list of application-order constraints.

A delta module specifies delta actions to transform a particular realization artifact by using a delta language suitable for the source language of the realization artifact. Fig. 8.7 shows the DeltaEcore file for the delta module DAdd from the running example. In its first line, the delta module is given a descriptive name, e.g., “DAdd.” The remaining lines are referred to as a delta block, which consists of a header and a body (within braces {...}).

The header of a delta block, as first entry, specifies which delta language to use. As described in Section 8.4.1.1 only a delta dialect with suitable delta operations is needed to interface with a source language (i.e., Ecore) as the remainder of the delta language is provided by the common base delta language. Hence, using the dialect keyword, it is sufficient to provide the model URI used within an existing suitable delta dialect. With the modifies keyword, the header allows to specify which realization artifact should be transformed within the delta block, in this case, the EPL core model. For more complex scenarios, it would also be possible to provide a list of realization artifacts to be modified, e.g., when moving elements from one artifact to another. Optionally and in between the dialect and modifies keywords, it is also possible to use the requires³ keyword to provide a list of delta modules that have to be applied as prerequisite for the delta module to be applicable.

The body of the delta block consists of a sequence of delta actions, i.e., calls to delta operations defined in the delta dialect with arguments to transform the targeted realization artifact(s). In the example, first, the class Add is added. Then, both its left and right references are created. Finally, its method print() is added with a suitable implementation. To target existing elements, DeltaEcore uses references, which are enclosed within angle brackets (<...>) and are resolved to suitable elements for the delta actions, e.g., <Exp> is resolved to the interface Exp using either a generated basic reference resolver or a specialized one explicitly specified in the delta dialect (see Section 8.4.1.1).

Note that a delta module may, in principle, specify multiple delta blocks. This is sensible if a logically coherent set of transformations (e.g., to realize one particular feature) affects multiple realization artifacts of different source languages (e.g., if there also was a model specifying the concrete syntax of the EPL that would have to be subjected to variability according to the same features).

The mapping model relates (combinations of) features with a set of delta modules and, thus, constitutes a centralized model of application conditions for delta modules. Fig. 8.8 shows the DeltaEcore mapping model for the running example. In the general case, an entry to the mapping model consists of a left-hand side referencing a feature and a right-hand side giving a delta module within angle brackets (<...>), e.g., Add:<deltas/DAdd.decore>. However, more complex entries are possible. For one, the left-hand side may contain a complex expression over features comprising logical operators for negation (!), conjunction (&&), and disjunction (||), e.g., Add && Eval. Furthermore, the right-hand side may define a set of delta modules as comma-separated list (to be applied in an arbitrary order) if multiple delta modules are associated with the same expression over features.

Application-order constraints prescribe a partial order on delta modules to enforce constraints on their application sequence when deriving a variant from the SPL. In our running example, it has to be assured that the class Add was created and the method eval() added to its super class, i.e., the interface Exp, before adding the implementation of the method eval() to the class Add. However, this order only has to be obeyed if the selected configuration contains both features Add and Eval. Hence, the DeltaEcore delta modules DAdd, DEval, and DAddEval have to obey that (partial) order if they are selected together. Fig. 8.9 shows the respective application-order constraints file of DeltaEcore to enforce this partial order. Within brackets ([...]), DeltaEcore permits the definition of a constrained group containing arbitrarily many delta modules. Within a constrained group, the order of delta modules may be changed arbitrarily. However, the order of constrained groups themselves is maintained during variant derivation. Hence, a constrained group constitutes one level of a partial order specification. Note that it is also possible to nest constrained groups to realize more complex (partial) orders.

Also note that all the artifacts used in the definition of a DeltaEcore SPL are entirely model-based as they are founded in Ecore metamodels themselves. This means that DeltaEcore artifacts integrate seamlessly into an MBSPL scenario, e.g., delta modules could be generated through model transformation similar as we did in some of our work on reverse engineering SPLs [48] and pattern-based SPL development [41,42].

With the definition of delta modules, the mapping for application conditions, and the optional application-order constraints, a basic DeltaEcore SPL definition is complete and it is possible to derive variants as described in Section 8.4.1.4.

8.4.1.3 Software product line evolution

For the EPL running example, the changes for making the feature Print optional can be realized by delta modules that remove the respective elements from the core model. Similarly, making the feature Eval mandatory does not require any changes to the delta modules as the existing ones can still be applied.

However, creating a new version of a feature implementation, such as with the feature Eval, poses greater challenges: Not all users of an SPL may want to migrate to a new version of an SPL and its features immediately or completely, e.g., due to a dependency on an old version of a particular feature. In consequence, it may be necessary to include existing versions of features in the configuration process to be able to maintain them and combine them with other features, potentially in newer versions.

To address this challenge, DeltaEcore provides evolution delta modules. Evolution delta modules have the express intent of realizing versions of a feature's implementation. A version is perceived as resulting in an incremental change to the state of the realization of the previous version, i.e., further transformation. Hence, on the implementation level, evolution delta modules are similar to the delta modules that enable or disable a feature's functionality – which we refer to as configuration delta modules for disambiguation. However, conceptually, the two types of delta modules have different intents, which is relevant, e.g., in their application order where a feature has to be enabled before it can be migrated to a newer version. Fig. 8.10 shows an evolution delta module of the running example that migrates the implementation of the eval() method of the class Add to the new version of the feature Eval. Note that the delta module is introduced by the evolution keyword to signal to DeltaEcore that it is an evolution delta module.⁴ In the example, the delta actions within the evolution delta module make use of the same delta operations from the delta dialect as within configuration delta modules. However, it is possible to restrict the usage of some delta operations in a delta dialect to evolution delta modules by prepending their definition with an evolution keyword, e.g., especially invasive operations, such as refactorings, that should not be used for configuration.

To associate the evolution delta module with the new version of the feature Eval, the mapping model has to be updated. In Fig. 8.11, an excerpt from the revised mapping model shows how the new version of the feature Eval is used in a condition on when to apply the evolution delta module to update the implementation of the eval() method of the class Add.

When selecting a configuration that contains the feature Eval in the new version, the mapping model provides the appropriate evolution delta module⁵ to trigger version migration of the feature.

8.4.1.4 Variant derivation

DeltaEcore provides multiple ways to select which variant should be generated: selecting a set of delta modules to be applied, defining a configuration, and, when interfacing with an explicit feature model [40], employing a graphical configurator. Fig. 8.12 shows an example of a DeltaEcore configuration for the EPL running example.

With the prior option, the initial set of delta modules is explicit. With the latter two options, the selection of features within the configuration is used in conjunction with the mapping model of application conditions to resolve the left-hand side of mapping entries and, if satisfied, to include the delta modules on the right-hand side in the initial set of delta modules. For the example of Fig. 8.12, the initial set of delta modules would be {DAdd, DEval, DAddEval}.

With either of these options, the determined initial set of delta modules is completed by transitively including those delta modules that are explicitly required from the header of the contained delta block(s) (see Section 8.4.1.2), which is not necessary within the running example.

With the full set of delta modules to be applied for one particular variant, DeltaEcore determines a valid application sequence. For this purpose, application-order constraints specified explicitly in the respective model and those defined implicitly by the requires relation of delta modules are considered when building a dependency graph of delta modules. Subsequently, this dependency graph is sorted topologically and, from the resulting partial order, one permissible total order is chosen as application sequence. For the example of Fig. 8.12, valid application sequences would be [DAdd, DEval, DAddEval] or [DEval, DAdd, DAddEval] due to the application-order constraints of Fig. 8.9 prohibiting DAddEval to be applied first.

For the actual variant derivation, DeltaEcore copies the core model of the SPL and then applies the relevant delta modules in the determined application sequence. For the application of delta modules, each delta block in each delta module has its delta dialect resolved so that the delta actions within the delta block body can be executed via the interpreter for the delta language (see Section 8.4.1.2). The result of variant derivation is the realization artifacts containing appropriate functionality for the selected features and, when using evolution delta modules, respective versions thereof.

8.4.1.5 Experiences

The implementation of the running example was performed by a user familiar with DeltaEcore and, with a previously existing feature and core model, consumed approximately 45 minutes of effective working time.

In larger-scale use, DeltaEcore has been applied as a corner stone technology within the EU Project HyVar⁶ as part of a cloud-based reconfiguration infrastructure for variable automotive software. Furthermore, DeltaEcore has been applied in various evaluation scenarios, e.g., the TurtleBot driver software [34], a metamodel family for role-based modeling and programming languages [18], and an SPL of feature modeling notations [43]. Finally, DeltaEcore has been incorporated into multiple other tool suites, e.g., as part of reverse engineering for the generation of delta modules [48], as variant generation mechanism for context-aware SPLs [22,23], or as back-end for the new version of DeltaJava.⁷

8.4.2.1 Delta language creation

A distinguishing characteristic of SiPL is to derive delta modules from a model difference [26]. Therefore, SiPL is integrated with the model differencing framework SiLift [16], which provides advanced differencing and patching facilities based on graph transformation concepts. This way, the difference between an origin model and a changed version may be described as an asymmetric difference (also known as edit script) [17].

An excerpt of the conceptual structure of such a difference is illustrated in Fig. 8.13. An asymmetric difference consists of a set of operation invocations which, when applied onto the origin model, yield the changed model. Each operation invocation calls a parameterized graph transformation rule by providing actual parameter bindings and mappings of output to input parameters. A partial order is induced by the dependencies between the operation invocations. In the context of SiPL, an operation invocation corresponds to a delta action and a graph transformation rule to a delta operation, respectively.

That means, a delta language actually consists of a set of graph transformation rules which must be specified for the respective source language. Fig. 8.14 shows an excerpt of the set of graph-based delta operations which are typed over the Ecore metamodel. The left- and right-hand sides of a rule are merged into a single graph, following the visual syntax of the model transformation language Henshin [1,31]. The left-hand side of a rule comprises all model elements stereotyped by delete and preserve. The right-hand side contains all model elements annotated by preserve and create. The operations on top create/delete an EClass, the lower ones add/remove a superTypes relation between two EClasses. The remaining operation sets the value of the EAttribute called abstract of an EClass.

A basic set of operations can be automatically derived from the metamodel of the respective modeling language using the approach and supporting tool presented in [20] and [19,28], respectively. A specific capability of these operations is that they preserve elementary consistency constraints defined by the given language metamodel, e.g., multiplicities of references.

More complex delta operations can be manually specified using the Henshin editor or derived from examples following the concept of model transformation by-example [13]. Fig. 8.15 shows a delta operation creating an EAttribute and setting its type. Please note that the type is not declared to be mandatory by the Ecore metamodel but by a separate consistency constraint.

8.4.2.2 Software product line definition

To create an SPL definition in SiPL, we have to create a new delta modeling project by providing a variability model and a set of delta operations. The variability model is assumed to be a propositional formula over the set of features. However, SiPL can be extended by arbitrary variability adapters which convert a proprietary variability model into a propositional formula.

A respective adapter for converting a feature diagram expressed in FeatureIDE is already available.

Fig. 8.16 gives an overview of the overall project structure. A delta modeling project consists of several folders for the core model, delta modules, and generated model variants (referred to as products of an MBSPL in Fig. 8.16). In a first step, we have to specify the core model of our running example, which can be done by creating a new model in the respective folder or by importing an existing one. Furthermore, the respective configuration must be assigned to the core model. This information is stored in a so-called deltamodel which manages the overall solution space, i.e., the core model, delta modules including their interrelations, and the mapping of the problem space onto the solution space. Furthermore, a delta module encapsulates an asymmetric difference, has a name, and is equipped with an application condition, i.e., a propositional formula over features defined by the feature model.

In order to create a new delta module, an origin model is generated by passing a valid feature configuration. If no configuration is given, the core model is used. An empty delta module is added to the deltamodel and the origin model is copied into the origin and modified folder of the respective delta module folder of the project. After that, a delta module can be implemented by editing the model in the modified folder and by comparing the original model with its modified version. Fig. 8.17 illustrates the derivation of the delta module DAddEval. Therefore, the origin model is generated by passing a configuration including the features Eval and Add.

Subsequently, we edit the model in the modified folder by adding the operation eval to the class Add and an annotation specifying its implementation. Next, an asymmetric difference is derived between the origin and modified model using SiLift. Therefore, SiLift must be configured by the respective delta operations specified as Henshin transformation rules. The asymmetric difference includes all delta actions as partially ordered set of operation invocations, according to the conceptual structure shown in Fig. 8.13. Finally, the asymmetric difference is added to the deltamodel by referencing the asymmetric difference from the respective delta module.

Analogously to DeltaEcore, SiPL also supports a textual representation from which an asymmetric difference can be derived and vice versa. Fig. 8.18 shows the textual representation of the delta module DAddEval.

In the first line, the name of the delta module and its application condition are specified. The delta block consists of the specification of the source language and a set of delta actions. A delta action calls the graph-based implementation of the corresponding delta operation that is identified by its signature (cf. Fig. 8.14). The delta action creates the operation eval in the class Add, followed by a delta action setting the return type of the created EOperation. The other operations create the annotation and its body specifying the implementation of the EOperation. Value parameters are defined by the keyword value and must be passed in quotation marks. Object parameters are defined by the keyword object and are passed using their qualified name. If several objects have the same qualified name, XMI-IDs are attached to uniquely identify the respective elements in the overall deltamodel. Created elements can be further assigned to local variables. Please note that in Henshin return values are also specified by parameters in the operation's signature. These need not to be unique in the overall set of operations. However, to uniquely identify created elements an alias can be declared using the keyword as.

As mentioned in Section 8.3.2, the delta module DAddEval depends on the delta module DAdd. While in DeltaEcore this relation must be managed manually as application-order constraint (cf. Fig. 8.9 in Section 8.4.1.2), SiPL automatically detects such relations and manages them in the deltamodel.

8.4.2.3 Software product line evolution

As we will illustrate later in this section, relations such as dependency relations between delta modules can be effectively utilized to support the evolution of an MBSPL. In addition to dependencies, SiPL also supports the detection of conflicts, duplicates, and transient effects between delta actions and thus between delta modules. Table 8.1 summarizes our definition of the mentioned kinds of relations. SiPL exploits the fact that delta operations invoked by delta actions are implemented as declarative rules based on graph transformation concepts. This allows to statically reason about relations between delta actions by extending concepts presented in [17]. Relations between delta actions are further aggregated to relations between delta modules and can be validated against the feature model.

The right part of Fig. 8.19 shows the relation graph of the deltamodel for the evolution scenario of our running example. Delta modules are represented as nodes and relations as arrows. Blue arrows (dark gray in print version) represent dependencies between the connected delta modules. A delta action of the source module depends on a delta action of the target module. The red arrows (mid gray in print version) represent conflicts between the connected delta modules, i.e., the execution of a delta action of the source module would prevent the execution of a delta action of the target module. Transient effects are illustrated by yellow arrows (light gray in print version). The source module contains a delta action that removes the effect of a delta action of the target module. For getting more details about a relation, we can inspect the deltamodel shown in the left part of Fig. 8.19. It consists of an expandable list of delta modules and their relations.

For instance, to inspect the transient effect relation from the delta module DAddNotPrint to DAdd we can expand the item of the former and further expand the item holding the outgoing transient effects. Each transient effect item offers information about the kind of the transient effect and the involved delta actions. In this case, the operation print is created by one delta module and deleted by another one.

As mentioned above, the dependencies between delta modules specify the application ordering of delta modules during variant derivation. However, conflicts, duplicates, and transient effects may be a hint for a mismatch between the problem and solution space. For instance, when two features are compatible in the solution space but their delta modules are in conflict, the variant cannot be derived as expected. In our example, the detected conflicts are automatically resolved by applying the involved delta modules according to the application order defined by the dependency relation which is indicated by the red dashed arrow. However, some conflicts can only be resolved by extracting the conflicting delta actions from one of both delta modules into a new delta module which is equipped with an application condition which prevents the application of the conflicting delta actions.

Transient effects may be a hint for an inadequate variability design in the solution space. For instance, the transient effect between DAddNotPrint and DAdd is due to the evolution described in Section 8.3.3. Fig. 8.20 shows all occurring relations between both delta modules.

The feature Print has become an optional one and its implementation should be separated from the implementation of the features Add and Neg in order to correspond to the problem space.

SiPL offers a set of fundamental restructuring operations. All of them create one new delta module which is derived from existing delta modules; an overview of the available restructurings is given in Table 8.2.

Each restructuring operation defines a precondition which must be fulfilled, otherwise the application of the operation fails. For instance, the arguments of the operation merge must not be in conflict or the conflict must be resolved by the application order induced by the dependency. Common refactorings for delta-based SPLs as introduced by Schulze et al. [37] can be easily implemented by combining the basic restructuring operations offered by SiPL.

For instance, to eliminate the transient effects between the delta modules DAdd and DAddNotPrint of our running example, we can concatenate the operations $merge$ and $minus$ as illustrated in Fig. 8.21. First, we apply the operation $merge(DAdd,DAddNotPrint)$, which leads to the delta module DMerge with the manually adjusted application condition $Add|Add\mathrm{\&}not(Print)$ (see Fig. 8.21A). This delta module contains all delta actions of DAdd and DAddNotPrint without those delta actions leading to a transient effect. The new delta module overlaps with the delta module DAdd. To eliminate the duplicates we apply the operation $minus(DAdd,DMerge)$, leading to the new delta module DMinus with the manually adjusted application condition $Add\mathrm{\&}Print$ (see Fig. 8.21B). The delta modules DAdd and DAddNotPrint are not needed anymore and can be deleted. Now, the resulting delta module set does not contain any transient effects or duplicates. In order to perfectly correspond to the problem space, we can further merge the delta modules DMerge and DAddEval.

In general, however, finding an appropriate refactoring may be challenging. Therefore, SiPL further offers a range of metrics in order to assess the quality of the overall solution space and to recommend refactorings [27]. A metric is defined by a name, a computation function, an indicator which defines whether a high value is better or worse than a low value. For example, the relational complexity of a delta module measures the average number of occurrences of delta actions in relations to other delta modules. A lower value is preferable and indicates that the delta module is more easily understandable and maintainable because relations with other delta modules are less complex. The redundancy relates the number of duplicate delta actions and all delta actions of a nonempty delta module. A lower value indicates better reusability. Further metrics are presented in [27]. Whenever a refactoring is successfully applicable, the affected metric values are computed before and after the refactoring and presented to the developer. Regarding our running example, the initial relational complexity is about 2.2 (see lower left part of Fig. 8.19). After the elimination of the transient effects it decreases to 1.0.

8.4.2.4 Variant derivation

A variant can be derived by interactively selecting features or by creating a configuration file which is a simple list of features. In a first step the configuration can be validated against the variability model, i.e., the feature model. Next, for all delta modules whose application condition is evaluated to $true$ an application order is determined according to the dependency relations. The execution of the delta operations of a delta module is performed by the patching engine of SiLift, which resolves the actual parameter bindings and delegates the actual rule invocation to the Henshin interpreter. If the application of a delta module fails due to unresolved conflicts, we can start the application again in a kind of debug mode reusing the interactive patching tool of SiLift. In this mode each delta action can be interactively applied onto the core model. Conflicting delta actions can be skipped or the patched model can be edited after each successfully applied delta action in order to resolve remaining conflicts manually.

8.4.2.5 Experiences

The implementation of the running example with SiPL was performed by a user familiar with the framework and, analogously to the implementation using DeltaEcore, with a previously existing feature and core model. It consumed approximately 80 minutes of effective working time.

In addition to the implementation of the running example, SiPL has already been demonstrated using an SPL, called Smart Home, which serves as a standard example domain in the SPL community [24,45], and an SPL extracted from a case study for embedded software in industrial automation, the Pick and Place Unit (PPU) [46], which serves as a standard case study within the German Priority Programme “SPP 1593 Design For Future – Managed Software Evolution”.⁸ Furthermore, to evaluate the larger-scale use of SiPL, we will use the bCMS-SPL, a case study having over 50,000 variants, which is used to evaluate and compare different modeling approaches [7,6].