Tolerating inconsistencies is well accepted in design modeling because it is often neither obvious how to fix an inconsistency nor important to do so right away. However, there are technical reasons why inconsistencies are not tolerated in many areas of software engineering. The most obvious being that common reasoning engines are rendered (partially) useless in the presence of inconsistencies. This paper investigates automated strategies for tolerating inconsistencies during decision-making in product line engineering, based on isolating parts from reasoning that cause inconsistencies. We compare trade offs concerning incorrect and incomplete reasoning and demonstrate that it is even possible to fully eliminate incorrect reasoning in the presence of inconsistencies at the expense of marginally less complete reasoning. Our evaluation is based on seven medium-to-large size software product line case studies. It is important to note that our mechanism for tolerating inconsistencies can be applied to arbitrary SAT problems and thus the basic principles of this approach are applicable to other domains also.

State-of-the-art modeling tools can help detect inconsistencies in software models. Some can even generate fixing actions for these inconsistencies. However such approaches handle inconsistencies individually, assuming that each single inconsistency is a manifestation of an individual defect. We believe that inconsistencies are merely expressions of defects. That is, inconsistencies highlight situations under which defects are observable. However, a single defect in a software model may result in many inconsistencies and a single inconsistency may be the result of multiple defects. Inconsistencies may thus be related to other inconsistencies and we believe that during fixing, one should consider clusters of such related inconsistencies. This paper provides first evidence and emerging results that several inconsistencies can be linked to a single defect and show that with such knowledge only a subset of fixes need to be considered during inconsistency resolution.

The configuration of a product from a product line is a decision-making process that requires humans to answer questions. However, questions and their choices tend to affect one another (e. g., one feature depending on another) and decisions on how questions are answered may render other questions obsolete or reduce their choices. There is thus an ideal order in which questions should be answered to minimize the number of questions that need answering to completely configure a product. Unfortunately, this ideal order differs depending on the product -- which cannot be known a priori. Decision-making is thus characterized by either imposing a predefined order on how questions must be answered (usually done manually by product line engineers) or not imposing any order. Both situations have downsides and this paper thus proposes an alternative: an incremental algorithm and tool-support for automatically optimizing the order of questions with every answer. We evaluated our approach on six models, the largest with over 280 questions, and found that the approach is 78-99% optimal and significantly reduces the number of questions that need to be answered manually. For the creators of product line models, this implies savings in not having to predefine the optimal order which is exponentially complex. For the configurator (decision maker) this implies more freedom in the order in which to answer questions while still benefiting from guidance.

Decision models are widely used in software engineering to describe and restrict decision-making (e.g., deriving a product from a product-line). Since decisions are typically interdependent, conflicts during decision-making are inevitably reached when invalid combinations of decisions are made. Unfortunately, the current state-of-the-art provides little support for dealing with such conflicts. On the one hand, some conflicts can be avoided by providing more freedom in which order decisions are made (i.e., most important decisions first). On the other hand, conflicts are unavoidable at times and living with conflicts may be preferable over forcing the user to fix them right away - particularly, because fixing conflicts becomes easier the more is known about an user's intentions. This paper introduces the C2O (Configurator 2.0) tool for guided decision-making. The tool allows the user to answer questions in an arbitrary order - with and without the presence of conflicts. While giving users those freedoms, it still supports and guides them by 1) rearranging the order of questions according to their potential to minimize user input, 2) providing guidance to avoid follow-on conflicts, and 3) supporting users in fixing conflicts at a later time.