Implementation Accompanying "Reducing Feature Combinatorics in Product Line Testing"

This page serves as the documentation of the implementation accompanying the paper Reducing Feature Combinatorics in Product Line Testing. The implementation is a prototype and therefore you may run into problems using it. If you have any question or concern, please contact Peter Kim.

IMPORTANT: Please backup your work before using the plugin. Although the plugin makes behavior-preserving transformations to code that it works on, we're not responsible for any lost work.


Installation and launching the plugin

  • Download the implementation, an Eclipse plugin. Put it in eclipse/plugins directory. Please save your work and restart Eclipse in a new workspace dedicated to testing this implementation and with the following command: "eclipse.exe -vmargs -Xmx1024m". The plugin unfortunately requires a great deal of memory.

  • Source code for the implementation is available on request.


Running the plugin on the case studies

Download the following case studies.

For each case study downloaded:

  • Import it into the workspace by selecting "File > Import... > General > Existing Projects Into Workspace > Next > Select archive file > Browse...", then choosing the case study file.

  • Wait until automatic build completes or manually build it.

  • Right-click on a class with a main method (e.g. one of the test classes in "tests" package), select "Determine product line configurations to test". It will take sometime (see the durations reported in the paper), during which the UI will be in thinking-mode (sorry for not implementing a progress bar/window). A dialog pops up when it's done. Note that the plugin finds the configurations to test, but does not actually run the configurations.

  • Right-click on the project and select "Refresh". The file containing results, which has its prefix as the name of the class with the main method, should appear.


Running the plugin on your own product lines

We recommend taking one of the case studies and replacing its content with your own because each product line has components that may be difficult to construct from scratch. Each product line project has the following components:

  • Feature model. Specifies the legal combinations of features. Located in projectRoot/featuremodel.m, where "projectRoot" is the root directory of the product line project.

  • Equation file. Specifies the list of features, which are the leaves of the feature model (the feature model allows intermediate, i.e. non-leaf, features to be defined to allow the actual, i.e. leaf, features to be organized). Located in projectRoot/everything.equation.

  • Source code. Specifies the implementation of the product line. Located in projectRoot/src, excluding projectRoot/src/annotationclasses___. The special package "annotationclasses___" contains classes used to annotate the product line with feature information. Except for "Config___.java", whose fields you should change to reflect the features present in the equation file, the package should not be changed in any way. Your product line code should refer to feature variables defined in Config___.java and annotated using Feature___.java.

You can modify the above components with your own product line. A toy product line may be easier to understand and modify than the case studies. Follow the same instructions as for the case studies to install and analyze it.


Case Study Results

Each case study above comes with the results, but here are the results again in case you want to download just the results:


Limitations

  • Line numbers reported in output may be off by a bit if there are anonymous classes. This is because we insert temporary annotations aginst anonymous classes in order to identify them. The numbers we report are unfortunatey with these anonymous classes present.

  • All class members (classes/methods/fields) should be annotated with a feature. If it is not annotated, the Base___ feature will be assigned to it. In the future, an unannotated member will take the feature of the closest annotated parent.

  • Eclipse must be restarted for each execution of the "Determine product line configurations to test" menu. If you attempt to execute the menu a second time without restarting Eclipse, the menu will return an error message and do nothing. This is due to an implementation limitation caused by a previously developed tool using static fields rather than instance fields.


Jak-To-SysGen Translator

The menu "Transform Jak to SysGen" translates a product line in the Jak representation to SysGen representation. Before executing this menu, the Jak product line has to be structured in a certain way. If you would like to know how to use this functionality, please contact me.


Acknowledgement

This material is based upon work supported by the National Science Foundation under Grant No. CNS-0958231. Any opinions, findings, and conclusions or recommendations expressed in this material are those of the author(s) and do not necessarily reflect the views of the National Science Foundation.