Understanding Configurable Software Systems with Lightweight Feature Slicing

Elton Alves, Sabrina Souto, and Marcelo d’Amorim

Abstract

Dynamic feature interaction is an important abstraction to document highly configurable software systems. Unfortunately, they are to a large extent hidden in the code. This paper proposes a lightweight method to extract these interactions and to identify interesting ones out of those extracted. Our approach is to select a small number of system configurations, to run existing test cases in slicing mode against those configurations, and to process interactions from the many computed slices. Experimental results considering 3 subjects previously used in other studies indicate that there was almost no loss in the set of feature interactions observed when analyzing only the reduced set of configurations, that the cost is substantially lower when using this reduced set, and that both high and low-level abstractions of feature interactions that we used were useful to explain behavior.

Implementation

• Product selection tool
• Feature Slicer

Results

• Raw data and detailed results
• Subjects:
We use subjects from CIDE, check it out: GPL, Prevayler and BerkeleyDB.
• Progress:
The plots below shows results for each subject. The star in the plot marks the run of one test for one product. For example, there are 12 stars in the GPL plot for the reduced suite as there are 12 test runs (2 test sequences and 6 products to analyze). The interaction count considered in the y-axis corresponds to the number of edges in the interaction graph. In this experiment, we considered only the time to run the tests and compute the slices; we ignored the time to build the products and the time to process the slices. Both can significantly make the analysis with the full suite slower relative to the reduced suite.

Progress of feature interactions discovered over time (cumulative).

• Feature Interactions:
We compared the number of distinct feature interactions observed with the full and reduce test suites. We did not consider repeated dependencies or dependencies to/from libraries and test code. Figure below shows results. The stacked bar shows the percentage of different kinds of dependency observed considering a pair of subject and choice of test suite: reduced (*-R) or full (*-F). For example, GPL-R refers to the results for GPL obtained using the reduced test suite. The first bar in the stack shows the number of intra-method dependencies, the second bar shows the number of inter-method dependencies that occur inside the same class and the third bar shows the number of dependencies that cross class boundaries.

Percentages of feature dependencies discovered.


We use graphs as abstraction of the observed feature interactions considering the tests given and products selected. Transitivity is not implied. A dependency from feature a to c does not necessarily follow from the presence of edges a → b and b → c in the graph. Dashed edges indicate transitivity. We use labels in the edges of the graph to indicate the number of distinct dependencies established in different places of the program. Check the feature interaction graphs, we omit the feature interactions with CORE: GPL, Prevayler and BerkeleyDB.