This paper introduces an approach to establishing software product lines from a set of existing products based on a reversed Lee Kang design feature based approach to deriving program code from features, Van den Broek's feature model merging combined with partial feature models, and aspect-oriented refactoring strategies cataloged by Monteiro and Fernandes for implementing the features as modules that can be plugged in or out as needed. The approach interlinks the feature model merging cases with the actual implementation of features and specic aspect-oriented refactoring strategies used for this. The approach was successfully applied to JForum, establishing a product line from three existing products prepared out of the original, publicly available JForum code.
21:2
The rest of the paper is organized as follows. Section 2 presents the overall approach. Section 3 explains how product feature models are recovered. Section 4 explains the process of merging product feature models into a product line feature model. Section 5 describes the feature module implementation strategy. Section 6 discusses the evaluation. Section 7 compares the approach proposed in this paper with related work. Section 8 concludes the paper.
The overall approach to establishing software product lines from existing products is depicted in Figure 1. As can be seen from the figure, the input to the approach are existing software products, including their documentation, if available. After a series of activities, the approach produces its final outputs: the feature model of a newly established software product line and feature modules, the modules that implement features [Apel et al. 2008].
Existing Products
Feature Analysis
Recovering Product Feature
Models Feature Modules
The approach is iterative and incremental in its nature, which is indicated by a circular flow between its main activities. This means that the individual steps should be treated within a reasonable time frame and proceed to the next steps as soon as possible rather than refining them indefinitely. The next steps will quickly confirm or refute the assumptions from previous steps forcing a re-iteration if necessary.
The approach will be explained on a study performed on JForum, an open source discussion forum implemented in Java [The JForum Team 2018]. Out of the original version, which will be referred to as JForum Original, two other versions were created denoted JForum Simple and JForum Different Base. JForum Simple offers only elementary features, mimicking a situation when this is explicitly required by a customer or when a company wants to offer a simpler and cheaper version. Uncoordinated, these two versions will continue to be developed separately. At some point, their merge extended by some further features might be created. This is what the third product denoted as JForum Different Base represents.
Constructing a product line feature model as a common feature model of a set of related products is a complex task. Here, it consists of recovering feature models out of individual products, discussed in this section, followed by merging them together, discussed in Section 4.
The most important and relevant artifact for recovering a feature model out of a given product is its source code. Models and documentation may be consulted, but should be used with caution, as they rarely fully correspond to code.
Since features in feature modeling, which should be both comprehensible and usable for configuration purposes, tend to be at a higher level of abstraction than code, it’s convenient to first create their approximation closer to the actual code modules and then make appropriate abstraction out of this initial design feature model. This is exactly how the Lee–Kang design feature based approach to deriving program code from features [Lee and Kang 2013] works. Here, for the purposes of recovering feature models from software products, the Lee–Kang method has been reversed within the process of creating partial feature models [Menkyna and Vranic´ 2012], which will be explained on an example.
Consider JForum Simple. Figure 2 shows selected features of its initial partial feature model. The basic Czarnecki–Eisenecker feature modeling notation [Czarnecki and Eisenecker 2000] is used. The root node represents the JForum Simple system as such. Within the first iteration, the identified design features are attached directly to the concept node (the root) as optional features (indicated by an empty circle) without trying to determine precise feature relationships. The square brackets around the feature name mean that the feature is open, i.e., further subfeatures are expected.
Afterwards, the work goes towards organizing the discovered features and correcting their variability and also towards discovering further features, some of which are abstract (indicated by a lighter background), i.e., no feature modules correspond to them. Figure 3 shows selected features of the resulting JForum Simple feature model.
Figure 4 shows the feature model constructed for JForum Original. The JForum Different Base feature model is very similar: it only lacks the Cache feature (and, consequently, its subfeature, TopicCache), as well as the additional restriction. Additional restrictions are textually defined relationships between features. They are typically used to express relationships whose inclusion would compromise the tree structure of a feature diagram. Logical operators are used to form additional constraints [Vranic´ 2005].
In general, the approach proposed here focuses on variable features, which are essential to defining a software product line, and does not capture thoroughly all the common (mandatory) features.
The overall feature model reflecting the contemporary state of the software product line is obtained by merging feature models of individual products. Feature model merging is performed using Van den Broek’s approach [van den Broek 2012]. This approach operates upon a set and predicate logic representation of feature models, such as this one of JForum Simple: PC(JForumSimple, RecentTopicsAction) = {{RecentTopics}} RE(JForumSimple) a EX(FM2) = {}
AF(JForumSimple) = {JForum, User History, Recent Topics} Here, JForumSimple is a name of a feature model. The rest of the identifiers represent features. The feature model is defined using the predicates for retrieving the set of the features (FE), concept1 (RO), feature parent (PA), possible sets of feature children in feature model configurations (PC), require constraints (RE), and mutual exclusion constraints (EX). An additional predicate has been introduced to indicate retrieving of abstract features (AF).
Feature models are merged one by one, gradually accumulating the features of the individual products in the product line feature model. Van den Broek’s feature model merging is based on making an intersection of the two feature models to be merged after enriching each one of them with the differentiating features occurring in the other one. These features are added as optional features. The feature models being merged are assumed to fulfill so-called parent compatibility, which means that equal features have equal parent features [van den Broek 2012].
With respect to the application of Van den Broek’s approach within the approach proposed in this paper, several distinctive cases have been identified. These cases, presented in the following paragraphs, also affect the implementation of the corresponding feature module, which should be considered along.
A feature occurring in a product feature model, but not in the product line feature model should be added to the product line feature model. In implementation, this mostly requires just refactoring the code that corresponds to this feature.
A feature missing in a product feature model, but mandatory in the product line feature model should be transformed into a variable feature. In implementation, aspect-oriented refactoring of the corresponding common base code may be performed.
A feature with varying implementation in different products poses a non-trivial problem. If it’s caused by varying behavior being required, it may be resolved by introducing alternative design features. If the behavior is essentially one and variance in the implementation is only accidental, this may be resolved by refactoring. If this fails, the solution should be resorted to introducing alternative design features. The variance might as well be caused by an additional functionality present in one of the products. This functionality may be treated as a new optional feature or it may be incorporated as mandatory to all the products.
A feature with equal implementation in all products indicates a mistake in feature identification, as such a feature should have been identified as mandatory and probably not even introduced into product feature models (recall from Section 3 that the approach proposed here tends to omit mandatory features focusing on variability).
A feature with different names in different products might be tricky to discover during feature model merging as its consequences become apparent only during feature module implementation. Of course, the solution is to name all such features equally.
Figure 5 shows selected features of the merged feature model reconstructed from its set and predicate logic representation.
In order to keep features pluggable, the corresponding feature modules are implemented using aspectoriented programming. With an object-oriented code base, aspect-oriented refactoring is required. 1denoted by Van den Broek as the root feature 21:6
Aspect-oriented refactoring strategies cataloged by Monteiro and Fernandes are applied [Monteiro and Fernandes 2005; Monteiro 2004], putting them into the context of product lines. Among these, the Move Field from Class to Inter-Type Declaration and Move Method from Class to Inter-Type Declaration strategies are in particular useful to implement the features occurring in a product feature model, but not in the product line feature model and features missing in a product feature model, but mandatory in the product line feature model.
The Partition Constructor Signature strategy is also applicable to the features occurring in a product feature model, but not in the product line feature model.
The Extract Advice strategy is the most versatile refactoring. It can be used to implement the features with varying implementation in different products. It can also be used to implement the features occurring in a product feature model, but not in the product line feature model when Move Field from Class to Inter-Type Declaration and Move Method from Class to Inter-Type Declaration are not applicable due to the necessity of preserving the corresponding attributes or methods in their original place.
As it was indicated in the previous section, these refactoring strategies affect the product line feature model as well.
As it was explained in Section 2, the approach proposed here was applied to JForum, creating a product line out of three existing products prepared out of the original, publicly available JForum code [The JForum Team 2018]. For aspect-oriented code, AspectJ was used. Table I indicates the size of the study. As expected, JForum Different Base caused the biggest number of merging conflicts.
Number of Abstract Features Design Features Merging Conflicts
In merging, features occurring in a product feature model, but not in the product line feature model occurred most frequently. This indicates the extent of the variability among the products.
Features with varying implementation in different products also occurred frequently. It was caused by how JForum Different Base differed from the other two products.
The other three merging cases mentioned in Section 4 have not been observed probably because of a thorough initial analysis. Moreover, the study was of a modest size and constructed with product lines in mind.
Liu et al. proposed an approach to feature oriented refactoring [Liu et al. 2006]. However, they do not deal explicitly with feature model merging.
Yoshimura et al. proposed an approach to assess the merging of existing systems into a product line and a method to identify the commonality among them [Yoshimura et al. 2006]. Instead on commonality, the approach proposed in this paper focuses on variability as a driving force in product lines making it fully operational on both feature modeling and code level.
Shatnawi et al. proposed an approach to recovering software product line architecture of a family of object-oriented product variants [Shatnawi et al. 2016]. Similarly as in the approach proposed in this paper, they focus on variability. However, they do not target a complete implementation, but remain on the architecture level.
This paper introduces an approach to establishing software product lines from a set of existing products based on a reversed Lee–Kang design feature based approach to deriving program code from features [Lee and Kang 2013], Van den Broek’s feature model merging [van den Broek 2012] combined with partial feature models [Menkyna and Vranic´ 2012], and aspect-oriented refactoring strategies cataloged by Monteiro and Fernandes [Monteiro and Fernandes 2005; Monteiro 2004] for implementing the features as modules that can be plugged in or out as needed. The approach interlinks the feature model merging cases with the actual implementation of features and specific aspect-oriented refactoring strategies used for this. The approach approach was successfully applied to JForum, creating a product line out of three existing products prepared out of the original, publicly available JForum code.
Apart from the implementation, the approach is independent of the programming language being used. The implementation part relies on AspectJ style of aspect-oriented programming since this is the basis the aspect-oriented refactoring strategies employed in the approach work on. However, there are indications that some programming languages not explicitly developed as aspect-oriented exhibit aspect-oriented features [Bálik and Vranic´ 2012]. Aspect-oriented frameworks, which are available for many programming languages, may be used, too. The problem is that these frameworks are often obsolete with respect to the underlying programming language due to the lack maintenance support.
The next steps may lead towards improving the maintenance of the interconnection of features and feature modules, partial automation of feature identification and feature model merging (possibly with an application of design pattern detection techniques [Polášek et al. 2012]) and semi-automatic aspect-oriented refactoring [Pipík and Polášek 2013], and a deeper examination of the approach on larger studies. In the long run, dynamic code structuring [Nosál’ and Porubän 2012; Nosál’ et al. 2013; Porubän and Nosál’ 2014] may be considered as an alternative to the fixed code representation. Also, layered 3D visualization of software models [Ferenc et al. 2017; Gregorovicˇ and Polášek 2015; Gregorovicˇ et al. 2015] possibly with virtual reality [Vincúr et al. 2017b; Vincúr et al. 2017a] could be applied to make simultaneous work with several feature models and code easier and more transparent.