Systematic reuse of software artifacts can be achieved with software product lines, which represent a family of similar software systems. A variability model, e.g., feature model, describes their commonalities and variabilities and serves as a basis for a product con guration, i.e., the selection of features according to constraints de ned in the model. These variability models can contain additional information, such as attributes, which enrich features with typed values for various purposes (e.g., optimization, simpli ed readability). Typically, these attributes are not directly reusable in code artifacts as the variability model is only used to assemble or change code artifacts according to a product conguration. Furthermore, there are many languages for implementing software product lines such as DeltaJ which do not support the direct propagation of feature attributes to the associated code artifacts. In this paper, we present parametric DeltaJ, an adaptation of the programming language DeltaJ for delta-oriented software product lines in Java. parametric DeltaJ allows the propagation of typed attributes from an attributed feature model to Java code artifacts. We perform a case study to show that introducing parameters reduces the number of variables, delta modules and lines of code for delta-oriented software product lines.
The concept of (hardware) product lines from industries such as automotive, avionics, or mobile phones were
adapted to software product line engineering (SPLE) [
Submission to: 8. Arbeitstagung Programmiersprachen, Dresden, Germany, 18-Mar-2015, to appear at http://ceur-ws.org this paper, we propose and present an approach to propagate feature attributes of AFMs into the solution space of an SPL based on Delta-Oriented Programming (DOP).
DOP is a exible programming paradigm to implement SPLs [
If the SPL uses an AFM to describe possible products, attributes may have other types than Boolean. Hence, attribute values cannot be used directly for con guration and can also not be propagated to the implementation artifacts which are con gured. As a workaround, the AFM could be transformed into an FM. However, this leads to an explosion in the number of features and possible delta modules, i.e., possibly one for each attribute value. For instance, transforming a single integer attribute with a range of 1000 possible domain values leads to 1000 features and according number of delta modules.
To remedy this problem, in this paper, we introduce an extension of the language DeltaJ called parametric DeltaJ, to integrate attributes of AFMs such that attribute values can be used for con guration as well as propagated as parameters to implementation artifacts. We enhance delta modules with parameters, similar to methods in Java. These parameters are assigned values of feature attributes to manipulate the source code. This increases the capabilities of delta modules regarding reuse for AFM. With this approach, we demonstrate a solution for systematic reuse of feature attributes in the software artifacts of an SPL.
Section 2 shows the details of AFM based SPLs and gives a recap of DeltaJ 1.5. Section 3 presents our extension of DeltaJ and introduces necessary extensions to the product line declaration and delta modules. Section 4 presents the challenges of implementation the extension of DeltaJ 1.5. Section 5 contains our case study. Section 6 revisits other approaches for implementing SPLs as related work. Section 7 concludes the paper and presents further ideas to extend DeltaJ. 2
A software product line (SPL) can be divided into three parts, the problem space, the con guration space and
the solution space [
Features describe con gurable elements in an SPL. Dependencies between features are expressed in a FM, where
features are structured in form of a tree. The tree structure consist of optional and mandatory features as well as
of feature groups like alternative and or-groups. Additional constraints can be expressed in from of propositional
formulas, so called cross-tree constraints (CTCs). Usually, CTCs are require and exclude constraints between two
features, but also more complex CTCs are possible up to general Boolean formulas over features. In AFMs [
require
exp:int degree:int base:Bases
min:int max:int
Mandatory Optional Alternative
Or-Group Require CTC Exclude CTC Plus as the simplest mathematical operation that all our derivable calculators support NumBlock the number block as input for numbers NumberSystem with its child feature Decimal to de ne the number system, which we are using for all calculators Mandatory features are indicated by a lled circle at the top of the feature. Optional features are indicated by an empty circle, for example, the other mathematical operations Minus, Multiply and Divide. We further restrict the feature Divide by a CTC to include the feature Multiply if Divide is selected. The additional mathematical operations are combined below the feature Scientific in an or-group, where at least one of the mathematical operations Power, Root, Log must be selected if the parent feature Scientific is selected. The features Power and Root each have one attribute of the type int. For the feature Power, the attribute exp is used to con gure the exponent of the operation. The same for the attribute degree of feature Root. For the feature Log, we use an attribute with the enum type Bases to distinguish the base for the operation. The enum contains the values fTen, Two, Eg as common bases. Additional CTCs in a textual representation de ne the range of attributes and other constraints, such as that the di erence between the minimal decimal number and the maximal decimal number is greater than 100. 2.2
DOP is a transformational approach for implementing software product lines [
DOP for Java is realized in the programming language DeltaJ. An SPL in DeltaJ consists of two parts, rst, a product line declaration and, second, set of delta modules. The DeltaJ product line declaration le speci es the used delta modules, the partial order of the delta modules and the mapping of features to delta modules. It further describes which products of the SPL are to be generated. For this purpose, it needs the FM as a basis to ensure that no constraint of the FM is violated for product con guration. The structure of a product line declaration le is displayed in Listing 1. It contains clauses for features, delta modules, constraints, partitions and products. The hierarchy and CTCs of the FM are described as a propositional formula in the Constraints clause. The Partitions clause introduces a partial order of delta modules for the product generation process where the when clause maps delta modules to features by specifying the application condition. The generate keyword of the Products clause marks the concrete product de nitions for the generation process.
A delta module declaration starts with the keyword delta followed by the name of the delta module. It contains operations to add, modify or remove classes. Modifying a class can contain further operations to add, modify or remove elds and methods of the class. In case of modifying a method, the keyword original is introduced to reuse earlier versions of the method.
Listing 1: Structure of a product line declaration le 1 delta dNumberSystem{ 2 adds { 3 package calc; 4 public class Number { 5 private int number; 6 public void set(int i) { 7 number = i; 8 } 9 public void plus(int i){ 10 number += i; 11 12 13 14 } 15 } 16 } 17 } } public void print(){ System.out.print(number); 1 delta dDecimalMin0{ 2 modifies calc.Number { 3 modifies set(int i) { 4 if(i >= 0)) { 5 original(i); 6 7 8 9 10 11 } 12 } 13 } 14 } } } modifies plus(int i) { if((number + i) >= 0) { original(i); Listing 3: Delta Module with modi es operation Listing 2: Delta Module with adds operation
The delta module dNumberSystem in Listing 2 adds the class Number. The class contains a setter method to store the value in the object and the plus method for the mandatory arithmetic operation. Assume that the Calculator SPL contained a feature DecimalMin0 that requires that no numbers lower than 0 can be used. The according delta module dDecimalMin0 to implement this requirement is shown in Listing 3 and applied if the feature DecimalMin0 is selected. The delta module modi es each input method, veri es the input and calls the original version of the method with the original keyword. Operations to remove classes or methods use the keyword removes and work similar to the modifies operation. 2.3
In the existing version of DeltaJ, feature attributes can only handled by encoding all attribute values as features. An example of such a Features clause with encoded attribute values is shown in Listing 4, which shows the set of features for the calculator SPL. Features displayed here are simple literals. As DeltaJ does not support attributes in features, we transformed every domain value of every attribute to a literal which demonstrates the shortcomings of DeltaJ regarding attributes. One of the rst things to be noticed is that the String attribute of the root feature calculator can not be transformed into a set of features. Only nite domains can be transformed into a feature by this encoding for every domain value. This transformation results in many features that are otherwise easily expressed in the AFM. This can be seen in Listing 4 in line 5, where we express every integer value as a feature. To reduce the number of features we decreased the range of the variables DecimalMax and DecimalMin.
Listing 4: Product line declaration le features
The Deltas clause for the calculator SPL is shown in Listing 5. Here, delta modules are represented by their names. In this case, we need as many delta modules as features to capture the impact of the feature on the implementation artifacts, which also leads to an explosion of the number delta modules most of which are very similar. We also have an explosion of constraints when we transform the CTCs for the attributes in order to require that only one value for an attribute can be selected. This phenomenon can be observed in Listing 6. A constraint is represented by a Boolean formula over features and ends by a semicolon. All constraints must be satis ed in a product con guration, otherwise no product can be generated. We put the single domain values for every attribute into an XOR relation of the feature comprising the attribute is selected (if not full mandatory). Transforming the constraint max min < 100 in Boolean logic is possible but a lot of constraints are necessary to express it. 1 ... 2 Deltas { 3 dCalculator, dNumberSystem, dMinus, dMultiply, dDivide, dPower, dRoot, dLog, 4 dReal, dDecimalMin-N, ... dDecimalMinN, dDecimalMax-N, ... dDecimalMaxN, 5 dPowerExp1, ... , dPowerExpN, dRootDegree1, ... , dRootDegreeN, 6 dRealDigits1, ... , dRealDigits10, dLogBaseTen, dLogBaseTwo, dLogBaseE 7 } 8 ...
Listing 5: Product line declaration le deltas 1 ... 2 Constraints { 3 MathOperations & ...; 4 DecimalMin-N ˆ ... ˆ DecimalMinN; DecimalMax-N ˆ ... ˆ DecimalMaxN; 5 DecimalMin-N => !(DecimalMax-N | ... | DecimalMax100); ... 6 DecimalMin1 => !(DecimalMax-N | ... | DecimalMax101); ... 7 DecimalMinN => !(DecimalMax-N | ... | DecimalMax2_147_483_547); 8 //Decimal.max - Decimal.min > 100; 9 Power => (PowerExp1 ˆ ... ˆ PowerExpN); //Power.exp; 10 Root => (RootDegree1 ˆ ... ˆ RootDegreeN); //Root.degree; 11 Real => (RealDigits1 ˆ ... ˆ RealDigits10);//Real.digits; 12 Log => (LogBaseTen | LogBaseTwo | LogBaseE); 13 } 14 ...
Listing 6: Product line declaration le constraints 3
In this section, we present an extension to DeltaJ to incorporate feature attribute as parameters. The following steps have to be performed towards the extension of DeltaJ which are either addressed in the product line declaration or in the delta modules.
1. Introduce features attributes to the product line declaration. This includes access in constraints, partitions, delta modules and product de nition. 2. Introduce parameters to delta modules, so that they can be used in classes and methods. 3. Update the validation of the attributed feature model and the de nied products.
4. Include feature attributes and parameters of delta modules in the product generation process. 3.1
For the product line declaration, we rst extend the syntax of DeltaJ for feature attributes. For this purpose, our feature declaration now contains an optional Formal Parameter Declaration (FPD) after the feature name to specify feature attributes. Syntactically, this declaration is similar to the FPD of a regular Java method parameter declaration. 1 SPL Calculator { 2 enum Bases {Ten, Two, E}; 3 Features { 4 Calculator(String name), MathOperations, NumBlock, NumberSystem, 5 Plus, Minus, Scientific, Divide, Decimal(int min, int max), Multiply, 6 Power(int exp), Root(int degree), Log(Bases base), Real(int digits) 7 } 8 ... 9 }
Listing 7: Features with attributes in the product line declaration le of the Calculator SPL The adapted example from Listing 4 is shown in Listing 7. The number of de ned literals for features in parametric DeltaJ is signi cantly smaller as no attributes have to be transformed into simple features anymore. As parameter types, we provide Java primitive types, the java.lang.String type and Java-like Enumeration types, which can be de ned in the product line declaration. With the type String we also support in nite domains. Listing 7 also shows the de nition of the enum type Bases for the feature Log. The enums are de ned before the Features clause. In the product generation process, each de ned enum is generated as a Java enumeration type, which is used in the implementation if needed.
Parameters of delta module declarations use the same syntax as attributes declared for features. With these parameters, we reduce the number of necessary delta modules signi cantly as it is no longer needed to write one delta module for every feature attribute domain value. Listing 8 shows the parametric DeltaJ variant of Listing 5 with delta module parameters. 1 ... 2 Deltas { 3 dCalculator(String name), 4 dNumberSystem(int min, int max), 5 dMinus, dMultiply, dDivide, 6 dPower(int exp), dRoot(int degree), 7 dLog(Bases base), dReal(int digits) 8 } 9 ...
For the constraints, we extended the possible operations by basic equality (=), basic inequality (>,<, , ,6=) and arithmetic (+, , ,=) operations. The syntax extension allows expressing constraints such as \any min and max value is positive and its range is at least 100", but doesn't allow expressing constraints such as \a string must not contain any spaces and has to start with an upper case character". This is because constraints are validated using a CSP Solver, but we do not validate them by executing Java code contained in expressions. A more detailed description is presented in Section 4. The updated example of Listing 6 is shown in Listing 9 where we use the basic inequality and arithmetic operations to set the minimal range for our decimal numbers and constrain the range of our scienti c operations.
Listing 9: Constraints in the product line declaration le for the Calculator SPL
We extend the partition declaration to allow delta module selection to also consider attributes in the when clause. This is because a delta module can occur multiple times in any partition, but it can only be applied once for a product, which is ensured by the when clause. As the when clause de nes the connection of features and delta modules, we extend the delta module to be able to receive a delta parameter list. An argument value for a parameter can either be a type-compatible parameter of a corresponding feature, a type-compatible literal (constant value) or an expression over those values. Listing 10 shows the partitions for the Calculator SPL. 1 ... 2 Partitions { 3 {dNumberSystem (Decimal.min, Decimal.max)}, 4 {dCalculator(Calculator.name)}; 5 ... 6 {dPower(Power.exp)} when (Power); 7 {dRoot(Root.degree)} when (Root); 8 {dLog(Log.base)} when (Log); 9 {dReal(Real.digits)} when (Real); 10 } 11 ...
Listing 10: Partitions of delta modules in the product line declaration le 1 ... 2 Products { 3 ... 4 Scientific = {Calculator("Scientific Calculator"), MathOperations, NumBlock, 5 NumberSystem, Plus, Minus, Multiply, Divide, Real(9), Scientific, 6 Decimal(-100_000_000, 1_000_000_000), Power(2), Root(2), Log(Two)}; 7 } 8 }
Listing 11: Product de nition in the product line declaration le
Products can be de ned in the products block. Within the feature selection of a product, concrete values are de ned for a feature attributes. In Listing 11, we de ne a set of products in the Calculator SPL. 3.2
In this section, we present the changes to the syntax for de ning delta modules. As in the product line declaration le, we extended the signature of delta modules with parameters. The concrete value of each parameter is propagated from the con guration to each delta module by the product line declaration (see Listing 10). In Listing 12, we show how parameters are used in delta modules. The listing displays the code for the delta module dNumberSystem with its two parameters min and max as range for the decimal numbers used by our calculator. To reference a delta parameter, the name of the parameter is used. As Java allows name overloading, a parameter can be shadowed by either a class eld or a local variable.
To be able to qualify a parameter, we introduce a new keyword dm (for \delta module"), which can be used to build a parameters quali ed name. Listing 12 demonstrates how to reference parameters.
In line 7, the delta parameter min is referenced by its simple name and parameter max is referenced with its quali ed name in lines 13 and 16. 3.3
Checking Con guration Validity Listing 12: Delta module dNumberSystem To make sure that the de ned products in the product clause only contain valid con gurations of the FM, in DeltaJ, this problem was modeled internally as satis ability problem. The satis ability problem is checked by a SAT solver, that validates, that no constraint of the feature model is violated by the feature con guration of the product.
With introducing feature attributes, the complexity of validating the selected feature and feature attribute
con guration for product generation against the AFM is increased. Because a valid parameter type in
parametric DeltaJ is not necessarily Boolean, the problem evolves from SAT to a general constraint satisfaction
problem (CSP) problem [
For a particular product, the de ned concrete values for the selected feature attributes must be propagated into the product's generated source code. To this end, multiple possibilities exist: 1. Place the attribute value as a (local) constant directly into the particular locations, where the attribute is required, e.g., into a method body. 2. Encapsulate all attribute values that are relevant for a particular class as constant elds within that class. 3. Encapsulate all existing attribute values as constants within one additionally generated class or interface.
We decided for the third strategy of using one additional interface for all existing attribute values as it has two major advantages above the other strategies: prohibiting code scattering and avoiding name clashes. As a delta module can introduce or modify multiple classes and methods, both the rst strategy (i.e., a local creation of constants) as well as the second strategy (i.e., creating constant elds in each relevant class) could lead to the same constant being created multiple times across the product. This would prohibit the possibility of tracing the attribute values within the generated source code. Moreover, with both strategies, name clashes with existing variables and constants could occur. The third strategy (i.e., encapsulating all attribute values within one interface) avoids these problems. Each attribute value is created once as a static constant within this uni ed interface, which allows tracing the feature attributes within the generated source code. Moreover, name clashes are prohibited because a static reference to this interface is necessary to reference the attribute value. 4
In this section, we describe relevant implementation decisions of parametric DeltaJ as an extension to our
previous work on DeltaJ 1.5 [
In the following, we provide implementation details on the necessary syntactic extensions to DeltaJ to incorporate feature attributes in the product line declaration as well as in the delta modules. As DeltaJ is developed using Xtext, there are grammar les de ning the syntax of both the product line declaration as well as the delta modules. 4.1.1
In the product line declaration, multiple extensions to incorporate feature attributes and propagating these into particular products are required:
Features declarations and delta module declarations need to allow de ning attributes as parameters (see Listing 7 and Listing 8).
Constrains need to be extended by enabling expressions (e.g., equals, greater than) on feature attributes rather than only supporting propositional logic (see Listing 9).
The when clauses in the partitions require a mapping of feature attributes to corresponding delta module parameters (see Listing 10).
For product de nitions, concrete values need to be provided as arguments of the selected features (see Listing 11).
Enumeration declarations need to be integrated into the product line declaration to allow for using custom enumeration types as parameters (see Listing 7).
In the following, we brie y explain the steps taken to integrate the described extensions into the product line declaration, categorized by the clause in the product line declaration, which is extended.
Features & Deltas. To integrate parameters into feature declarations and delta module declarations, the grammar of the product line declaration is extended by adding a parameter rule, whose syntax is similar to Java method parameters. The grammar is illustrated in 2. The rules for feature declaration and delta module declaration both use an optional rule to de ne attributes or parameters.
Constraints. The constraints in DeltaJ are de ned by propositional formulas over feature names. To incorporate constraints for feature attributes, complex expressions over booleans, integers and strings are required within the constraints clause (see Listing 6).
Partitions. The delta application constraints, which now also de ne the mapping of feature attributes to delta module parameters, are extended. By propagating feature parameter names to delta modules as an argument (see Listing 10) within the partitions clauses, a mapping is established. Such arguments are de ned as a non-empty list of expressions that is surrounded by parentheses. Using a list of expressions allows combining several feature arguments to a single argument of a corresponding delta module (e.g., dDelta(Feature.a + Feature.b) for integer attributes a and b).
2http://tu-braunschweig.de/isf/research/deltas 3http://eclipse.org/Xtext FC FD DC DD PD PT ED ::= ::= ::= ::= ::= ::= ::=
Features f FD g F j F (PD) Deltas f DD g D j D (PD) PT P j E P int j boolean j . . . enum E f L g
features clause feature declaration
deltas clause delta module declaration parameter declaration
primitive type enum declaration
Products. The product de nitions need to allow giving concrete values for feature attributes. To this end, we extend the grammar for product de nitions by allowing to specify concrete values for feature attributes as arguments (see Listing 11). Arguments are de ned as a non-empty list of expressions that is surrounded by parentheses.
Enumerations. To integrate enumeration declarations (see Listing 7) into the product line declaration, we extend the grammar by adding an enumeration declaration which is syntactically similar to Java enum type declarations. In the following, we provide implementation details on the necessary semantic extensions to DeltaJ to incorporate feature attributes in the con guration validation as well as in the product generation. 4.2.1
The CSP solver we selected for validating product selections [
Most Java primitive types can be modeled with the integer domain as they utilize a smaller domain. However, long and double cannot be modeled without losing information. To handle this shortcoming, a warning informs the user that these values are treated as int and float values, respectively. Expressions are modeled using the constraint API of the CSP solver. To check whether a product is valid, the chosen feature selection is captured by allocating the associated CSP variables with true, the feature attribute allocation is represented by encoding their value and allocating the associated CSP variables. I the CSP Solver is able to nd an allocation of all variables, the product is valid. 4.2.2
As we add FPD to delta modules, all statements referencing a delta parameter have to be modi ed in the generated Java source code. To provide the delta parameter instantiation in the product's source code, we rst generate an additional Java interface containing a constant for each delta parameter, with the name DELTA PARAM. An example is shown in Listing 13. Afterwards, each reference to a delta parameter is replaced by a reference to the corresponding constant. 1 package spl.product; 2 public interface Parameters { 3 public static final String 4 CALCULATOR_NAME = "Adder"; 5 public static final int DECIMAL_MIN = 0; 6 public static final int 7 DECIMAL_MAX = 1000000; 8 }
Listing 13: Generated parmeter interface of product Adder (cf. Listing 11). 5
In this section, we present our case study, which is based on the BattleOfTanks4 software product line (SPL). The BattleOfTanks SPL is a two player game. Each player controls a tank in a variable environment (obstacles, power ups, sound, color, . . . ). With this case study we want to show the feasibility of our language extension and show that it is possible to reduce redundant code artifacts. For our case study, we require a reference for comparison with parametric DeltaJ regarding potential improvements. Hence, for comparison the subject of the case study must be written in plain DeltaJ and as an SPL with an attributed feature model (AFM) in parametric DeltaJ. Unfortunately, no such case studies exist, as DeltaJ 1.5 is quite recent and existing Java based SPL case studies only rely on Boolean FMs. Therefore, we chose BattleOfTanks, one of the biggest (w.r.t. number of features) Java based SPLs with a Boolean FM freely available and adapted the FM towards an AFM. The SPL consists of 144 features, 1975 lines of code (LOC), 11 classes and 2206 possible products. The original SPL is implemented in plain Java using Antenna5, a preprocessor for the Java programming language, to implement variability.
Since we introduced constructs to eliminate the state explosion in parametric DeltaJ, we need less redundant code to implement the case study than in plain DeltaJ. Hence, in the case study, we measure the number of necessary delta modules and LOC for the SPL realized with DeltaJ and with our extension parametric DeltaJ. We compare these values to quantify the e ciency of our improvement compared to plain DeltaJ. 5.1
The DeltaJ version of BattleOfTanks has the same number of features as the original Antenna implementation. It contains 124 delta modules with 2484 LOC. The di erence in the number of features to the number of delta modules is due to the fact that not all features from the original Antenna version are implemented. In consequence, the resulting number of delta modules is less than the number of features from the feature module. We had ve delta modules that were related to feature combinations (a.k.a. feature interactions). As the preprocessor allowed a more ne grained code manipulation (on statement level), we had to introduce many new methods to the original implementation to encapsulate the product speci c variability in the source code base of DeltaJ. Using these new methods, we were able to de ne the DOP modify operations to implement variability of the SPL. Hence, we were able to implement the alternative features. To implement the di erent combinations of the PowerUp features, which are organized in an or group, we used the original call to extend the method according to the di erent feature selections. In this case, we were able to mimic code manipulation on statement level. 5.2
The transformed FM of the BattleOfTanks SPL contains 51 features, 3 distinct enumerations for the shape of the tanks, for the background color and for the sound. With overall 33 enumeration literals, we were able to reduce the number of features to 89. Each enumeration literal represents a media le that can be used several times (e.g., shape of tanks for player 1 and player 2). They are now modeled with seven feature attributes. But not all alternative feature groups can be transformed to enum attributes as they di er signi cantly in their implementation. For instance, the alternative feature group containing the move operations of a tank, could not be improved by using an enumeration. The parametric DeltaJ version of the BattleOfTanks SPL contains 43 delta modules and a total of 1927 LOC. All seven feature attributes belong to mandatory features that are present in all possible products of the SPL. This made it possible to introduce these seven attributes to a single delta module and decreased the total number of delta modules to 81. We introduced one new delta module, which contains only one class, that maps the product line enumeration literals to String values that represent the used media les. With this delta module, we modularized the input les. We showed that by construction in case of parametric DeltaJ, the number of necessary delta modules and LOC are signi cantly smaller than in plain DeltaJ, if we consider an AFM used in the SPL. The fewer number of necessary delta module is possible, because an AFM is by design more concise than an equivalent boolean FM. This suggests that parametric DeltaJ has a similar level of reduction to DeltaJ as an AFM to an FM. If we count the features needed in plain DeltaJ and parametric DeltaJ including the literals of the enumerations, we arrive at a di erence of 60 features. That is a reduction alone in the literals for the AFM of 41.66%. If we compare the number of delta modules, we come to a reduction of 65.32%. For LOC, we arrive at a reduction of 22.42%.
Comparing the LOC of the original Antenna implementation, with the parametric DeltaJ implementation, there is no signi cant improvement.
We also discovered a use case to allow a delta module to be used multiple times for one con guration. The PowerUp feature group could be implemented with only one delta module with parameters. That delta module would extend the method to handle the PowerUps by using the original clause based on the parameter value from the con guration. For this case, it is theoretically possible to apply the delta module multiple times. We only showed one case study were we came to the results that parametric DeltaJ is capable of directly supporting feature attributes compared to DeltaJ. parametric DeltaJ is designed to eliminate the feature explosion if we consider AFMs in DeltaJ, which we show in this case study. For plain Boolean FMs parametric DeltaJ is as capable as DeltaJ, since it contains the complete grammar of DeltaJ.
The case study has the drawback, that we adapted the original Antenna implementation to DeltaJ ourselves. The Antenna implementation uses a Boolean FM as source, which we only needed to adapt for the parametric DeltaJ implementation. Fortunately, the example used boolean features for colors, shapes and sound, which we could easily design as enum typed feature attributes for the parametric DeltaJ implementation. For the implementation we used a minimized number of delta modules in the DeltaJ and parametric DeltaJ implementation for the rest of the optional boolean features. This strategy minimized the delta modules needed in the DeltaJ implementation except for delta modules that implemented the feature interactions, which only occur if a combination of features results in code adaption operations. This was helpful for the DeltaJ implementation, since it simpli es the transformation to DeltaJ. 6
There are other approaches to implement software product lines (SPLs). For example, preprocessors such as
the C processor CPP, which activates code fragments enclosed by #ifdef and #endif, and approaches such
as Feature-Oriented Programming (FOP) [
Preprocessors use commands to implement variability at compile-time. A well known preprocessor is the C
processor CPP [
FeatureHouse [
The AOP implementation AspectJ weaves additional code in form of aspects into a program. An extension
for AOP on AspectJ was proposed by Alvarez [
CaesarJ [
Hyper/J [
Clarke et al. [
Component-based development o ers similar characteristics for software development as parametric
DeltaJ, i.e., reuse, composability and explicit component dependencies [
In this paper, we extended the SPL programming language DeltaJ with parameters and called the language extension parametric DeltaJ. Namely, we extended the DeltaJ product line declaration language and DeltaJ delta modules to deal with feature attributes and formal parameter declarations. With these, we were able to propagate feature attribute values from the feature model (FM) via product con guration directly into the Java source code. To express also constraints on the feature attribute values, we also extended the expression language of the DeltaJ product line declaration language. We showed in a case study that we can signi cantly reduce the number of necessary delta modules by using parameters.
In future work, we would like to extend our method to interoperate with other extensions of FMs, such as
feature cardinalities and group cardinalities or multiple instances of the same feature (cloned features). Our case
study has shown that it might be useful to allow application of delta modules multiple times, but we need to nd
restrictions that have to be observed to guarantee well-formed products with multiple applied delta modules.
We will evaluate this idea by analyzing di erent use cases and scenarios. We also intend to increase the range of
parameter types for delta modules to further increase the reuse potential. Another interesting direction of future
work is to extend parametric DeltaJ to support the realization of multi SPLs [
The authors would like to thank the anonymous reviewers for their valuable comments and suggestions to improve the quality of the paper. This work was partially supported by the DFG (German Research Foundation) under grant SCHA1635/2-2 and by the European Commission within the project HyVar (grant agreement H2020644298).