Abstract
Variability raises new challenges for establishing correctness or any kind of functional or nonfunctional guarantees about programs. Traditional testing, type checking, static analysis, verification, or software and performance measurement are well-established for individual systems, but they do not scale to product lines when analyzing ever product in isolation, due to the huge configuration space. In this chapter, we discuss a broad range of strategies and methods to analyze a whole product line, explicitly considering variability in the analysis (hence the name variability-aware analysis). We cover basic analyses of feature models, analyses of mappings between features and implementations, and analyses of entire product-line implementations.
This is a preview of subscription content, log in via an institution to check access.
Access this chapter
Tax calculation will be finalised at checkout
Purchases are for personal use only
Notes
- 1.
There are estimated \({\mathtt{{7B}}}\approx {\mathtt{{2}}}^{{\mathtt{{33}}}}\) people on earth and \({\mathtt{{1O}}}^{{\mathtt{{8O}}}} \approx {{\mathtt{{2}}}}^{{\mathtt{{265}}}}\) atoms in the universe.
- 2.
A model is a solution (that is, a true/false assignment to each feature variable) that satisfies \(\phi \).
- 3.
For more information on the open-source tool FeatureIDE, see Appendix A.
- 4.
Typically, SAT solvers require formulas to be in conjunctive normal form, but these details should be hidden by feature-modeling tools.
- 5.
Rice’s theorem says in the general result no static analysis can prove a non-trivial property for any programs in a finite time. Of course, by restricting the domain of programs, by requiring certain structures or properties of these programs, a non-trivial property can be proven. This is analogous to the Halting Problem—for straight-line programs, the Halting Problem is solvable.
- 6.
We do know of cases of “product line” development where this is not so. The situation arises when different versions of a common system are produced in version control by branching code bases that are never merged. We strongly recommend against this practice.
- 7.
Here, we assume a fixed order of feature modules. A lookup is performed only in previous feature modules. If we want to type check feature modules with a flexible composition order, we need a more sophisticated encoding that reasons about the composition order as well.
- 8.
- 9.
- 10.
- 11.
- 12.
- 13.
- 14.
- 15.
- 16.
- 17.
- 18.
- 19.
- 20.
Author information
Authors and Affiliations
Corresponding author
Rights and permissions
Copyright information
© 2013 Springer-Verlag Berlin Heidelberg
About this chapter
Cite this chapter
Apel, S., Batory, D., Kästner, C., Saake, G. (2013). Analysis of Software Product Lines. In: Feature-Oriented Software Product Lines. Springer, Berlin, Heidelberg. https://doi.org/10.1007/978-3-642-37521-7_10
Download citation
DOI: https://doi.org/10.1007/978-3-642-37521-7_10
Published:
Publisher Name: Springer, Berlin, Heidelberg
Print ISBN: 978-3-642-37520-0
Online ISBN: 978-3-642-37521-7
eBook Packages: Computer ScienceComputer Science (R0)