Empirical analysis of the tool support for software product lines

Abstract

For the last ten years, software product line (SPL) tool developers have been facing the implementation of different variability requirements and the support of SPL engineering activities demanded by emergent domains. Despite systematic literature reviews identifying the main characteristics of existing tools and the SPL activities they support, these reviews do not always help to understand if such tools provide what complex variability projects demand. This paper presents an empirical research in which we evaluate the degree of maturity of existing SPL tools focusing on their support of variability modeling characteristics and SPL engineering activities required by current application domains. We first identify the characteristics and activities that are essential for the development of SPLs by analyzing a selected sample of case studies chosen from application domains with high variability. Second, we conduct an exploratory study to analyze whether the existing tools support those characteristics and activities. We conclude that, with the current tool support, it is possible to develop a basic SPL approach. But we have also found out that these tools present several limitations when dealing with complex variability requirements demanded by emergent application domains, such as non-Boolean features or large configuration spaces. Additionally, we identify the necessity for an integrated approach with appropriate tool support to completely cover all the activities and phases of SPL engineering. To mitigate this problem, we propose different road map using the existing tools to partially or entirely support SPL engineering activities, from variability modeling to product derivation.

Variability in data visualization

“…We may also show individual values as points without connecting them with a line only if the time-series values were not collected at regular intervals of time (e.g., every year). SPL phases covered (a) Scenario 2: A pie chart (taken from [25]) is not recommended to represent a relationship between a part and a whole (the tool support for the SPL processes in this case) because differences in the size of the angles are difficult to be perceived, requiring labels to display the values.…”

“…Scenario 2. The pie chart in Figure 10a represents a part-towhole relationship about the tool support for the different SPL processes [25]. We use the quantitative data available in [25], and create the configurations that result in the visualization of Figure 11.…”

“…The pie chart in Figure 10a represents a part-towhole relationship about the tool support for the different SPL processes [25]. We use the quantitative data available in [25], and create the configurations that result in the visualization of Figure 11. The recommended display for a part-to-whole relationship is a bar graph; or a line graph, in case of showing how parts of a whole 0 0.5 1 1.5 2 2.5 have changed over time, which is not the case.…”

Enhancing Secure Development in Globally Distributed Software Product Lines: A Machine Learning-Powered Framework for Cyber-Resilient Ecosystems

“…Processes for developing software have lately undergone a radical transformation. There is a growing need for quick development and adaptability due to the increasingly rapid speed of varying requirements on the way to meet market needs as well as to be compliant with evolving norms and standards [1,2,20]. Thus, a contemporary problem that many firms must face is continuous software improvement of software processes.…”

Acapulco

“…features is large (usually the case for industrial configurable systems), when only partial knowledge of the features is available (it is difficult that stakeholders are experts in all features), when there exist complex cross-tree constraints [6] (i.e., arbitrary relationships in propositional logic), or when it is accepted that feature interactions can make error-prone a manual estimation of the fitness of the configurations. Although several tools exist to address the optimization challenge to some extent [3] such as SATIBEA [2], MODAGAME [10], SPL Conqueror [13], ClaferMoo [9], and SPL Config [11], some of them tend to generate invalid configurations that need to be repaired during the optimization process, others have limitations regarding extensibility of the objective functions, or cannot be seamlessly integrated with other SPL-focused tools.…”