Explaining Satisfiability Queries for Software Product Lines

TU Braunschweig Master's Thesis Explaining Satisfiability Queries for Software Product Lines Author: Timo Gu¨nther 2017-10-17 Advisors: Prof. Dr.-Ing. Ina Schaefer Institute of Software Engineering and Automotive Informatics Dr.-Ing. Thomas Thum¨ Institute of Software Engineering and Automotive Informatics Gunther,¨ Timo: Explaining Satisfiability Queries for Software Product Lines Master's Thesis, TU Braunschweig, 2017. Abstract Many analyses have been proposed to ensure the correctness of the various models used throughout software product line development. However, these analyses often merely serve to detect such circumstances without providing any means for dealing with them once encountered. To aid the software product line developer in understanding the cause of defects, a new algorithm capable of explaining satisfiability queries in a software product line context is presented in this thesis. This algorithm finds explanations by using SAT solvers to extract minimal unsatisfiable subsets from the propositional formulas that express the defects. The algorithm is applied to feature model defects such as dead features and redundant constraints, automatic truth value propagations in configurations, and preprocessor annotations that are superfluous or cause dead code blocks. Using feature models and configurations from real software product lines of varying sizes, this approach is evaluated against an existing explanation approach based on Boolean constraint propagation. The results show that Boolean constraint propagation occasionally fails to find any explanation at all but is magnitudes faster than using minimal unsatisfiable subset extractors. In response, both algorithms are combined into a single one that is as fast as Boolean constraint propagation for the cases where that finds an explanation, but also finds an explanation for all the other cases. Contents List of Figures viii List of Tables ix List of Code Listings xi 1 Introduction 1 1.1 Goals....................................2 1.2 Structure .................................3 2 Background 5 2.1 Boolean Satisfiability . .5 2.1.1 SATSolving............................6 2.1.2 Minimal Unsatisfiable Subsets . .7 2.2 Software Product Lines . .7 2.2.1 Domain Engineering and Application Engineering . .8 2.2.2 Feature Models . .9 2.2.3 Configurations . 11 2.2.4 Implementation Using Preprocessors . 12 2.3 Software Product Line Analysis . 14 2.3.1 Feature Model Defects . 14 2.3.2 Configuration Analysis . 16 2.3.3 Family-Based Static Analysis of Preprocessor Directives . 18 2.4 Summary ................................. 20 3 Explaining Satisfiability Queries 21 3.1 Finding Explanations . 21 3.1.1 Explaining Using Boolean Constraint Propagation . 23 3.1.2 Explaining Using Minimal Unsatisfiable Subset Extractors . 26 3.2 Explanations for Software Product Lines . 27 3.2.1 Explanations for Feature Model Defects . 28 3.2.2 Explanations for Configurations . 29 3.2.3 Explanations for Preprocessor Directives . 32 3.3 Summary ................................. 34 4 Implementation in FeatureIDE 35 4.1 FeatureIDE . 36 4.2 Generalizing Explanations . 36 vi Contents 4.2.1 Explanations for Feature Model Defects . 40 4.2.2 Explanations for Configurations . 46 4.2.3 Explanations for Preprocessor Directives . 50 4.3 From Formula to Feature Model Using a Trace Model . 52 4.4 Exchanging SAT Solvers Using a Solver Facade . 55 4.5 Visualizing Explanations . 60 4.5.1 Explanations for Feature Model Defects . 60 4.5.2 Explanations for Configurations . 63 4.5.3 Explanations for Preprocessor Directives . 63 4.6 Summary ................................. 64 5 Evaluation 65 5.1 Evaluation Criteria . 65 5.2 Qualitative Analysis . 66 5.3 Quantitative Analysis . 67 5.3.1 Performance . 68 5.3.2 Explanation Lengths . 70 5.3.3 Explanation Availability . 76 5.4 Conclusion................................. 77 6 Related Work 79 7 Conclusion 85 8 Future Work 87 Bibliography 89 List of Figures 2.1 Software product line engineering process . .9 2.2 Feature diagram for a chat client . 10 2.3 Configuration of a chat client . 12 2.4 Minimal examples of feature model defects . 15 2.5 Car feature model containing defects . 15 2.6 Partial configuration of a car . 17 3.1 Feature models with defects showcasing refutation incompleteness . 25 3.2 Void feature model showcasing refutation incompleteness . 25 3.3 Feature models with defects showcasing literal incompleteness . 26 4.1 Class diagram for explanations . 37 4.2 Class diagram for explanations for feature models . 41 4.3 Class diagram for the implementation of explanations for feature models 44 4.4 Class diagram for explanations for configurations . 47 4.5 Class diagram for the implementation of explanations for configurations 49 4.6 Class diagram for explanations for preprocessors . 51 4.7 Class diagram for the implementation of explanations for preprocessors 53 4.8 Class diagram for the SAT solver facade . 56 4.9 Visual explanation for a dead feature . 61 4.10 Visual explanations for feature structures . 62 4.11 Textual explanation for an automatically selected feature . 63 4.12 Textual explanation for a contradiction in a CPP preprocessor directive 64 5.1 Computation time of all explanations for feature model defects . 69 5.2 Computation time of individual explanations for feature model defects 71 viii List of Figures 5.3 Computation time of all explanations for configurations . 72 5.4 Computation time of individual explanations for configurations . 73 5.5 Lengths of explanations for feature model defects . 74 5.6 Lengths of explanations for configurations . 75 List of Tables 3.1 Meaning of each clause of a feature model . 28 3.2 Explanations for feature model defects . 30 3.3 Explanations for automatic configuration selections . 31 3.4 Explanations for invariant presence conditions . 33 5.1 Evaluation models for feature model defects . 67 5.2 Evaluation models for configurations . 68 5.3 Availability of explanations for feature model defects . 76 5.4 Availability of explanations for configurations . 77 List of Code Listings 2.1 Java code for a chat client annotated with Antenna preprocessor directives................................... 13 2.2 Java code containing invariant presence conditions in Antenna preprocessor directives for the car feature model . 19 3.1 Antenna preprocessor directives with invariant presence conditions for the car feature model . 32 xii List of Code Listings 1. Introduction A result of today's industrial economy is the economic imperative to cater to as many customers as possible. At the same time, the diversity of the customer demands can make a one-size-fits-all solution counter-productive. In software engineering, it is possible to accommodate these demands using a software product line [PBvdL05, vdLSR07]. The idea behind software product line engineering is to take into consideration the variability of the software platform in order to enable the de- liberate and structured reuse of software artifacts such as program code. This way, fewer resources are spent on developing the commonalities of the various products more than once. Hence, product line engineering reduces the costs of the development of variable software [ABKS13, PBvdL05, vdLSR07]. In the end, by making customizable software feasible, software product line engineering results in individual needs being met more adequately. However, with software development being difficult enough as is, adding variability to the engineering process requires additional engineering techniques [BCH15, PBvdL05, vdLSR07]. Variable software platforms need to be modeled [BRN+13, CGR+12], implemented [LAL+10], and tested [ER11] differently from single-system software. This in turn entails various analyses aimed towards making software product line engineering more robust [TAK+14]. For example, the variability of software product lines is usually modeled using feature models [KCH+90, ABKS13]. However, given the sheer complexity of larger software platforms, creating and maintaining feature models is not a trivial task. To ensure the correctness of a feature model, a wide variety of analyses may be used [BSRC10, SKT+16]. To this end, the feature model is typically transformed into a propositional formula [Bat05] which can be used to reason over the feature model [Man02, Men09]. In particular, the feature model formula can be used in a satisfiability query deciding some property of the feature model such as whether it is even possible to configure the software product line in such a way that any valid product can be obtained [BSRC10, KAT16, SKT+16]. Such satisfiability queries can be used to detect all sorts of circumstances that require some form of intervention, be it automatic or 2 1. Introduction manual, not just for feature models but for any artifact used throughout the software product line engineering process [TAK+14]. Still, detecting such a circumstance only tells the developer that a certain circumstance takes place but not why. However, figuring out the cause of the circumstance is crucial to understand why an automatic intervention had to happen or which steps need to be taken to do so manually. To assist the developer in this regard, automatically finding explanations of the circumstance can save time and effort when trying to solve an issue with the model. This is particularly important for large models as their complexity can easily be overwhelming. By pointing out which elements of the model are involved in causing the circumstance, precise explanations reduce the number of elements that need to

Load more