No abstract

No abstract

No abstract

No abstract

We study the problem of model checking software product line (SPL) behaviours against temporal properties. This is more difficult than for single systems because an SPL with n features yields up to 2 n individual systems to verify. As each individual verification suffers from state explosion, it is crucial to propose efficient formalisms and heuristics.We recently proposed featured transition systems (FTS), a compact representation for SPL behaviour, and defined algorithms for model checking FTS against linear temporal properties. Although they showed to outperform individual system verifications, they still face a state explosion problem as they enumerate and visit system states one by one.In this paper, we tackle this latter problem by using symbolic representations of the state space. This lead us to consider computation tree logic (CTL) which is supported by the industry-strength symbolic model checker NuSMV. We first lay the foundations for symbolic SPL model checking by defining a feature-oriented version of CTL and its dedicated algorithms. We then describe an implementation that adapts the NuSMV language and tool infrastructure. Finally, we propose theoretical and empirical evaluations of our results. The benchmarks show that for certain properties, our algorithm is over a hundred times faster than model checking each system with the standard algorithm.

Feature diagrams are a popular means for documenting variability in software product line engineering. When examining feature diagrams in the literature and from industry, we observed that the same modelling concepts are used for documenting two different kinds of variability: (1) product line variability, which reflects decisions of product management on how the systems that belong to the product line should vary, and (2) software variability, which reflects the ability of the reusable product line artefacts to be customized or configured. To disambiguate the documentation of variability, we follow previous suggestions to relate orthogonal variability models (OVMs) to feature diagrams. This paper reuses an existing formalization of feature diagrams, but introduces a formalization of OVMs. Then, the relationships between the two kinds of models are formalized as well. Besides a precise definition of the languages and the links, the important benefit of this formalization is that it serves as a foundation for a tool supporting automated reasoning on variability. This tool can, e.g., analyse whether the product line artefacts are flexible enough to build all the systems that should belong to the product line. MotivationMany industry sectors face the challenge of how to satisfy the increasing demand for individualized software systems and software-intensive systems. The software product line (PL) engineering paradigm (SPLE, see [24]) has proven to empower organizations to develop a diversity of similar systems at lower cost, in shorter time, and with higher quality when compared with the development of single systems [24].Key to SPLE is to exploit the commonalities of the systems that belong to the PL and to handle the variation (i.e., the differences) between those systems. Commonalities are properties and qualities that are shared by all systems of the PL [14]; e.g., all mobile phones let users make calls. Two Kinds of VariabilityIn SPLE, two kinds of variability can be distinguished: Software variability and PL variability.Software variability refers to the "ability of a software system or artefact to be efficiently extended, changed, customized or configured for use in a particular context" [31]. This kind of variability is well known from the development of single systems. As examples, an abstract Java super-class allows different specializations to be used where the superclass is used; an interface allows different implementations to be chosen.PL variability [14,24,21] is specific to SPLE and describes the variation between the systems that belong to a PL in terms of properties and qualities, like features that are provided or requirements that are fulfilled. It is important to understand that defining PL variability, i.e., determining what should vary between the systems in a PL and what should not, is an explicit decision of product management (see [21,24]). As an example, product management might have decided that the mobile phones of their PL should either offer the GSM or the UMTS protocol.A chal...

No abstract

No abstract