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. Many 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. In 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 challenging task in SPLE is to map the PL variability to software variability. This means that the reusable artefacts from which the systems of the PL are built (called the core assets, which constitute the PL platform [24]) should be constructed flexibly enough to allow for efficiently and effectively building those systems [18, 26] . This problem can be seen as an instance, in the SPLE context, of the problem of relating requirements to design. The decisions to be 15th IEEE International Requirements Engineering Conference
REF proposed a formalization of Orthogonal Variability Models (OVMs) and also followed the SAT approach to analyze OVMs automatically.
Disambiguating the Documentation of Variability in Software Product Lines: A Separation of Concerns, Formalization and Automated Analysis
15th IEEE International Requirements Engineering Conference (RE 2007)
15th IEEE International Requirements Engineering Conference (RE 2007)
Computer Science