Tracing SPLs precisely and efficiently

Abstract

International audienceIn a Software Product Line (SPL) comprising specifications (feature sets), implementations (component sets) and traceability between them, the definition of product is quite subtle. Intuitively, a strong relation of implementability should be established between implementations and specifications due to traceability. Various notions of traceability has been proposed in the literature : [13], [17], [8], [9]; but we found in our experience that they do not capture all situations that arise in practice. One example is the case where, an implementation, due to packaging reasons, contains additional components not required for a particular product specification. We have defined a general notion of traceability in order to cover such situations. Moreover, state-of-the-art satisfiability based notions lead to products where the implementability relation does not exist. Therefore, in this paper, we propose a simple, set-theoretic formalism to express the notions of traceability and implementability in a formal manner. The subsequent definition of SPL products is used to introduce a set of analysis problems that are either refinements of known problems, or are completely novel. Last but not the least, we propose encoding the analysis problems as Quantified Boolean Formula (QBF) constraints and use Quantified SAT (QSAT) solvers to solve these problems efficiently. To the best of our knowledge, the QBF encoding is novel; we prove the correctness of our encoding and demonstrate its practical feasibility through our prototype implementation Software Product Line Engine (SPLE)

Traceability Analyses between Features and Assets in Software Product Lines

“…The TPL, MPPL, and ESPL models were taken from the SPLOT repository [41]. More details of the ECPL models can be found at [26]. Table 4 gives the number of features, components in each SPL model, and the execution time taken by various analysis operations on SPLAnE reasoner: CirQit.…”

“…For the fourth model, i.e., universe Debian model, FaMa reasoners was not able to solve any of the analysis operations. Whereas QSAT reasoners against completeness and soundness operations, was able to solve first three Debian models (main, restricted, multiverse), but was not able to solve the huge universe Debian model (26,338 features) in the given timeout (two hours). Overall, for the operations where both approaches scale up, QSAT is faster than SAT.…”

“…An early version of this work was published [26]. The proposed method has been implemented in a tool that is integrated with the FaMa framework [27].…”

Recovering Traceability Links between Requirements and Source Code Using the Configuration Management Log

“…In the extractive approach to develop core assets, we need to analyze the commonality and variability of existing products. Furthermore, SPLE requires relationships between those core assets (e.g., traceability links between features and code elements) to reuse them efficiently [6]- [8].…”

Generation, composition, and verification of families of human-intensive systems

“…Some techniques focus on placing restrictions on the creation of new variants, thus impeding generation, but providing well-formedness assurances for all variants that can be generated (e.g., [16,30,32]). Others focus on the traceability of features to subsets of components from the core assets and can reason about those relationships using QSAT (a SAT solver modified to handle quantified Boolean formulae) [24], or, for more sophisticated analysis capabilities the system can first be modeled in product line CCS and then checked against multi-valued modal Kripke structures to determine legal configurations that satisfy the requirements [14]. Although the goals of such approaches are consistent with the goals of our analyses, their analyses usually address only well-formedness constraints, and not other types of properties, such as safety, performance or robustness properties.…”