Tool and Results Accompanying "Reducing Configurations to Monitor in a Software Product Line" (RV 2010)

This page serves as the documentation of the tool and results accompanying the paper Reducing Configurations to Monitor in a Software Product Line. 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.


Case Studies

Download and extract the following case studies.

Each product line has two folders, "src" and "output". "output" is largely a blank directory that you can use to put the .class files that will be generated by our tool (except for notepad, which also has the "images" directory in there). Contents of "src" requires more explanation:

  • Feature model (featuremodel.m). Specifies the legal combinations of features. Our tool's objective is to extend this feature model to specify the configurations for which a monitor (expressed as a tracematch for example) has to be inserted.

  • Equation file (everything.equation) 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).

  • Source code (smashed, annotationclasses___). "smashed" package contains the product line's source code. The special package "annotationclasses___" contains classes used to annotate the product line with feature information. Except for "Config___.java", whose fields should reflect the features present in the equation file, the package should not be changed in any way. The product line code refers to feature variables defined in Config___.java and is annotated using Feature___.java.

  • Monitors (monitors). "monitors" package contains the monitors (tracematches) that check for safety properties of the product line. Our tool currently reports the configurations for which a monitor of interest has to be inserted. For our paper, we reported numbers for each monitor by running the tool with only one active monitor at a time. Therefore, only one monitor has the proper extension (".aj" or ".java"). An inactive monitor just has to be given an extension that is not recognizable by our tool (e.g. ".inactive"). If multiple monitors are active, the tool will report the configurations for which all of them have to be inserted (note that there may not be any configuration that requires both of the monitors to be present, but there may be a configuration that requires one of them to be present). If no monitor is active, the tool will report all the configurations of the product line.


Running the Tool

  • Download the implementation, a Java jar file. Usage:
    java -Xmx1024m -jar splmonitor.jar -sourceroots sourceDirectory -d outputDirectory -main-class fullyQualifiedMainClass

    "sourceDirectory" and "outputDirectory" can be absolute or relative to the working directory (i.e. the directory from which the tool is run). For running the tool on the case studies, "src" and "output" (relative or absolute) directories should be the "sourceDirectory" and "outputDirectory", respectively. For Running Example, "fullyQualifiedMainClass" is "Program". For GPL, it's "smashed.Main". For Notepad, it's "smashed.Notepad".

  • The tool generates a feature model that describes the configurations on which the active monitor(s) have to be inserted, rather than the bi-partition of both the configurations that must be monitored and that need not be monitored. If you want the feature model describing the bi-partition, all you need to do is look for "activeMonitor;" (e.g. "ReadPrint;") in the constraints section "%%" of the feature model and remove them. We generate the feature model of the configurations with the active monitor, rather than the bi-partitioning, for reporting purposes. For more information, please contact me.

  • Source code for the implementation is available on request.


Case Study Results

You can run the tool on the case studies to obtain the results yourself, which should be identical to the following results. Each zip file has 4 text files. "caseStudy.txt" reports the configurations of the product line. Without our technique, each monitor would have to inserted on each of these configurations. "caseStudy-monitorName.txt" reports the configurations for which the corresponding monitor has to be inserted.


Running the Tool 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.


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.