Software Product Line Variability: A Systematic Mapping Study Shahid Mujtaba1,2 , Kai Petersen1,2 , Robert Feldt1 , Michael Mattsson1 1 School of Engineering, Blekinge Institute of Technology Box 520 SE-372 25 Ronneby, Sweden {shahid.mujtaba | kai.petersen | robert.feldt | michael.mattsson}@bth.se 2 Ericsson AB, Box 518 SE-371 23 Karlskrona, Sweden {shahid.mujtaba | kai.petersen}@ericsson.se

Abstract Software product line engineering (SPLE) enables software mass customization and allows development costs to be cut, lead delivery times to be reduced and throughput to be optimized. The concept of variability is central in SPLE methodologies and for success when adopting a software product line approach. Even though much research has been done on this topic there is no clear view of the current state of knowledge. In this study, we used a systematic method to develop a software product line variability map and classified relevant literature. The resulting map gives an overview of the existing work on software product line variability and makes it possible to identify gaps and plan and position future research.

ing a map of product line variability research in order to identify 1) which areas in software product line research have been emphasized, 2) which areas are not well covered and thus require further research, and to classify 3) which types of research have been conducted and 4) which types of contributions in terms of method, process, tools etc. have been made. Secondly, we provide one example of how to adapt systematic mapping studies to the software engineering domain. So far, only one short paper has been published that piloted systematic mapping in software engineering [7]. This is beneficial as future variability research can be easily positioned within the map and relevant related work is easily identified. Furthermore, the research method is described in detail, allowing researchers to update the map with very little effort and to conduct mapping studies of other software product line or software engineering research areas.

1. Introduction Software product lines is a development paradigm which allows software companies to build customized software and get a shorter time to market and higher quality through systematic reuse [16]. In order to achieve systematic reuse, product line engineering relies on two core concepts, namely domain engineering and application engineering [89]. In domain engineering, a product line platform is created, which then becomes the base from which an actual product can be developed. In application engineering, the actual derivation of the products of the product line takes place. A core concept for both domain and application engineering is software product line variability. So far, no comprehensive birds eye view on existing research focusing specifically on product line variability literature has been published. To address this, we have conducted a systematic mapping study of existing research in product line variability. In particular, following contributions are made in this paper: Firstly, we apply a systematic approach for creat-

2. Research Methodology The research methodology used is a Systematic Mapping Study. We have provided a detailed description of the mapping process, outlined the methodology and compared systematic maps with systematic reviews in another study [63]. In this study, we present the results of applying systematic mapping to software product line engineering domain. We aim to answer the following research questions: RQ1: What areas in software product line variability have been addressed and how many articles cover the different areas? RQ2: What types of papers are published in the area and in particular what type of evaluation and novelty do they constitute?

2.1

Search Strategy and Screening

The search string used to identify literature for the mapping study is defined through which population of papers

we target and the intervention they concern. The population comprises the software domain, product lines, product families and system families. The intervention is concerned with variability and variation handling in product lines. The resulting search string is: Software AND (Product Line OR Product Family OR System Family) AND (Variability OR Variation) We applied the search string on all Software Product Line Conferences (SPLC) and Product Family Engineering Workshops (PFE) published between (2000-2007). To further strengthen results we included top international, peerreviewed journals published in the last ten years (19972007). The databases, we searched were Inspec and Compendex, ACM Digital Library and IEEE Xplore [22]. In total, 153 papers were identified. The inclusion and exclusion criteria were pilot-tested by three of the authors on a random sample of 20 papers and a high agreement was achieved. After the pilot, two of the authors screened the remaining papers by skimming through the abstracts and marked them as included, excluded or uncertain. In the end, the authors reviewed all disagreements by looking at the abstracts together and conflicts were resolved through discussion. After the screening process a total of 91 relevant papers remained.

2.2

Establishing a Classification Scheme

A few classifications of variability have been done in the past. However, they are not based on an overview of the literature, but on industrial case studies (e.g., [77, 92]). As these classifications are not based on a broad sample of product line literature, there is a risk that some important categories are missing. Thus, we followed a keywording strategy to develop our own classification scheme. The Keywording process is shown in Figure 1. It is done in two steps. First, the reviewers read abstracts and looked for keywords and concepts that reflect the contribution of the paper. While doing so the reviewer also identified the context of the research. When this is done, the set of keywords from different papers were clustered and combined together to develop a high level understanding about the nature and contribution of the research and to form the categories for the map. This helped the reviewers to come up with a set of categories which is representative of the underlying population. The resulting classification scheme is presented in Section 3. The abstracts which were of too poor quality to allow meaningful keywords to be extracted, reviewers choose to study the introduction or conclusion sections of the paper.

2.3

Mapping of Studies and Analysis

In this phase each included article was mapped to a particular intersection set within the scheme. The process was

Update Scheme Abstract Abstract Abstract

Keywording

Article Article Article

Classification Scheme

Sort Article Into Scheme

Systematic Map

Figure 1. Keywording and Classification driven by the definitions of the categories identified during the development of the classification scheme described in Section 3. The map produced a clear picture of how past research is scattered across multiple facets. It helped us to purposefully analyse the results while focusing on the frequencies of publications, thereby determining the coverage of the research field. Different facets of the scheme were combined to answer specific research questions.

3. Classification Scheme Papers are classified based on three different facets. Each facet consists of a set of categories to which the papers can be mapped. The facets are variability context, contribution type and research type. Tables 1, 2 and 3 detail the classification categories we have used. Variability context: Which type of activity in software development variability does the paper focus on? Through the keywording process, we identified the categories requirements, architecture, implementation, verification and validation, management, and orthogonal variability. Contribution type: What was developed in order to achieve advances in the focus area? Possible contributions are processes, methods, models, metric and tool. Those categories were also developed during the key-wording process. Research type: What is the novelty level and how the research is characterized? Based on an existing classification proposed by Wieringa et al. [90] we categorize the papers into validation research, evaluation research, solution proposal, philosophical papers, opinion papers, and experience papers.

4. Mapping This section describes the result of our mapping within the variability context facet and we exemplify typical papers for each category. Then we describe the combinations of the variability context facet with the contribution type facet and research type facet. The complete map of software product line variability is shown in Figure 2. The mapping of papers

Table 1. Variability Context Categories Category

Description

Requirements

In this category, variability in requirements is discussed. Furthermore, binding of variability on the requirements level is included.

Architecture

This category includes articles considering variability in software architecture construction and modeling. This includes binding of architecture variability. This category is concerned with literature on how to incorporate variability within the implementation (source code). This includes binding in implementation. This category includes quality assurance methods considering variability. This includes testing as well as formal verification and consistency checking techniques.

Implementation Verification Management Orthogonal Variability

This area is mainly concerned with managing requirements and dependencies at all abstraction levels keeping track of versions (configuration management, variability in time), managing traceability and architecture evolution Orthogonal variability is a concept that considers variability independently of any development artifacts. This implies that a seperate model for variability is maintained, and its variants and variation ponits are traced to all other development artifacts.

Table 2. Contribution Type Facet Category

Description

Process Method

A process describes activities or actions and their work flow. A method describes rules of how things should be done, for example rules for how to built a model or to elicit variable requirements. In this category, algorithms are considered as well. A model is a description of the real world omitting details. In order to be considered in this category, the model should have a higher degree of formality, that means it should have semantics and notations (for example semi-formal models like UML)

Model Tool Metric

A software tool is developed to support different aspects of software variability. Metrics and measurements for variability relate to this category.

to the facet Variability context shows that a clear majority of variability research is concerned with requirements and architecture. Requirements: For the requirement part, a large amount of literature was concerned with modeling variability in the form of feature models, which represents the main requirements artifact in software product line engineering [18]. Furthermore, research focused on classifying dependencies and binding features in a consistent way, i.e., considering dependencies between features so that only consistent combinats of product features are selected [87, 53]. Architecture: On the architecture level, product line research produced results regarding processes for architecture creation. For example, [79] proposed a design process for preparation, modeling and evaluating architectures. Furthermore, the modeling of architecture has to consider variability, which for example was addressed by [95] who extended UML models for architecture development. Besides this, several architecture papers described architecture patterns [49, 31]. In order to make the complexity of architecture manageable and to tailor the description of architectures to specific stakeholders, different architecture views are proposed in [1]. In addition to that, the variability on architecture level has to be bound in order to derive a product architecture from the product line platform (as is the case on

the feature level). In order to achieve this, [32] for instance provided mechanism for binding on architecture level. Implementation: When looking at the implementation, [60] proposes transforming models into text representing source code, for example by transforming different associations for class diagrams into text). Furthermore, they describe how high-order transformation can be used to resolve variability and generate code for domain artifacts. In addition to code generation, aspect orientation and feature oriented analysis are combined to capture crosscutting concerns in the implementation [46]. Furthermore, generative programming is an important concept when implementing product lines allowing to generate source code for specific products, for example by using compiler flags [54]. Verification and Validation (V&V): V&V is done for requirements, architecture and implementation. For example, [86] discuss to derive test cases from use cases containing variability to verify the actual implementation. Requirements verification for feature models is for example done by checking if selected features fulfill logical expressions representing feature models [52, 53]. Furthermore, tool support (RequiLine) is provided which allows to check whether variation point resolutions in feature models are free of conflict [86]. On the architecture, we discovered no verification techniques for product line architectures.

Table 3. Research Type Facet Category

Description

Validation Research

Techniques investigated are novel and have not yet been implemented in practice. Techniques used are for example experiments, i.e., work done in the lab. Techniques are implemented in practice and an evaluation of the technique is conducted i.e. it is shown how the technique is implemented in practice (solution implementation) and what are the consequences of the implementation in terms of benefits and drawbacks (implementation evaluation). This also includes to identify problems in industry. A solution for a problem is proposed, the solution can be either novel or significant extension of an existing technique. The potential benefits and the applicability of the solution is shown by an example or a good line of argumentation.

Evaluation Research

Solution Proposal Philosophical Papers Opinion Papers Experience Papers

These papers sketch a new way of looking at existing things by structuring the field in form of a taxonomy or conceptual framework. These papers express the personal opinion of somebody whether a certain technique is good or bad, or how things should been done. They do not rely on related work and research methodologies. What and how something has been done in practice. It has to be the personal experience of the author.

Management: Management is concerned with keeping track of versions (configuration management) and traceability. The traceability aspect is discussed in [10] where traces between solution space (architecture, design and implementation) and problem space (requirements and domain analysis) are recorded. Furthermore, the requirements management tool RequLine allows to manage version of requirements, support prioritization and achieve pre-traceability. Furthermore, features can be linked to other requirements types. After having provided an isolated overview of the variability context facet, we combine the different facets with each other, resulting in a map which for example shows how much evaluation research has been done in comparison to validation research. Figure 2 shows an overview of the Software Product Line Variability Map (SPL-V Map). The bubbles show how many publications are identified for each interaction set of the variability context facet with evaluation facet and contribution facet. Also, it is important to note that the total number of papers on either side of the map are not equal to each other. This is because few papers are mapped to multiple categories in a single facet i.e. a paper concerning with requirements variability context could present a model as well as the tool support to build that model. The map shows that solution proposals (56 papers) and evaluation research (50 papers) are the most dominant types in the research type with no validation research done in the area so far. We will further discuss the reasons for this in Section 5. The solution proposals are mainly concerned with methods and models. A large amount of literature is devised on domain analysis techniques and methodologies to handle product line variations using feature modeling [5, 20] which include literature on staged configurations [17, 18, 19], feature binding [14, 43] and meta-modeling [26]. There are some proposed mechanisms to create architectures that support dynamic instantiation and configuration of product line components [29, 44, 82]. Similarly,

the research which constitutes evaluations mainly assessed methods and tools with relatively less work addressing implementation or other variability categories. Despite the notion that a considerable amount of research is characterized as empirical mainly because of their industrial context, a close look reveals that the evaluations are largely based on industrial examples and may not be truly recognized as techniques which are actually practiced in the industry. Several such papers reported case studies such as [31, 69, 85] which lack solid research design and validation.

5. Discussion Evaluation, Validation and Empirical Evidence: The second largest set of articles relates to evaluation research (39.06%). As discussed in the previous section, it indicates that a high volume of research is claimed to be implemented and evaluated in industrial practice. For example, [3] implemented a multi-view architectural modeling approach and illustrated it by showing models from the medical domain. Other articles followed the same pattern of illustrating their industrial solution implementation while varying strongly in detail. A very detailed illustration of a solution of how to arrive at domain requirements is illustrated in [57]. As pointed out by Wieringa et al. [90] an important part of evaluation research is to apply sound research methods. In order to judge this, a detailed description of the research methodology is required. We only identified one paper that clearly described the data collection process and threats to validity [65]. In order to be able to establish the current state of evidence for product line variability research, we emphasize the importance of improving on the use empirical research methods and reporting procedures in product line variability research. Besides evaluation research, the highest amount of papers uses solution proposals and works with examples as proof of concepts (43.75%). We identified varying degrees of detail in the examples, ranging from very

Variability Context Facet

2.54%

3.39%

5.08%

1

12.71% 11

0.85%

14.41%

4

1

1.69%

1

1.69%

4 0.85%

4 (3.39%)

Tool

2.54%

1 1.69%

Metric

3 2.54%

Model

Architecture Variability

Implementation Variability

Variability Management

Orthogonal Variability

0.85%

Method

Requirements Variability

Verification and Validation

5.93%

3 3.39%

2

Contribution Facet 118 (100%)

0.85%

3.39%

7

2

2

6.78%

12.71%

6.78%

0.85%

8

15 9.32%

8

1

4

17

15

6

3

Process

10 (8.48%) 42 (35.59%) 46 (38.98%) 16 (13.56%)

21

13

2

10.16%

17

19

4

3

6

3.91%

14.84%

6.25%

3

5

13.28% 9

1.56%

16.41%

2.34%

1 0.78%

3.31%

2.34%

4 3.31%

2.34%

3

2

7 2.34%

2

2 1.56%

4 1.56%

5.47%

3.31%

1 1.56%

0.78%

Evaluation Validation Solution Philosophical Experience Research Proposal Paper Report Research 50 (39.06%) 0 (0%) 56 (43.75%) 14(10.95%) 8 (6.25%)

Opinion Paper 0 (0%)

Research Facet 128 (100%)

Figure 2. SPL-V Map superficial to more detailed ones. One possible reason for the high number of solution proposals is that introducing a product line is a costly decision which affects large parts of a company. That is, without the proper industrial setup new solution proposals cannot be evaluated properly. Furthermore, it is conspicious that no validation research has been done at all, one reason being that it is hard to scale software product line problems to the lab. The map also shows that the highest amount of evaluation research and solution proposals is related to requirements and architecture. However, this is due to that those categories comprise the highest amount of articles. Emphasis on Models and Methods: The map shows that there is a clear emphasis on models (35.59%) and methods (38.98%) to support product line variability. For example, on the requirements level the highest amount of papers discuss of models (14,41%). The models that are most frequently referred to are feature models. An industry evaluation of feature models has shown that there is still some improvement needed [33]. The major improvement needed from an industrial perspective is the improvement of cross-referencing and dependency modeling between features. Furthermore, features are essential during product derivation (binding). Methods relate to feature modeling in the way that they propose methods of how to derive products specific models from domain models (like feature models), see for example [17]. From the coverage perspective, we see that architecture variability is covered by process support. When looking at the areas of the map that are covered by a very small number of papers, it becomes apparent that there is a lack of research on tools and metrics. Few Philosophical Papers and Experience Reports: The map shows relatively few philosophical papers (10.9 %) and experience reports (6.25 %). It is important for the product line community to urge people to share more knowledge

and experience. Both philosophical and experience papers tend to make important contributions to the field through providing conceptual basis or highlighting key issues. Few papers tried to discuss and categorize product line variability taking into account various perspectives. For instance, classification of product families [92], realization and modeling techniques [77, 72] and variant binding [37].

6. Conclusions Our systematic map shows that the majority of research has been on requirements and architectural variability and with a focus on developing models and methods. There is relatively few papers on processes, tools and metrics and relating to other variability contexts than requirements and architecture. The main type of research has been solution proposals, closely followed by evaluation research involving a practical evaluation of the proposed, or existing, contribution. However, only one evaluation paper clearly describe the data collection process and validity threats. Based on our map there seems to be a relative lack of research on how to support SPL variability in implementation and management as well as how to verify and validate it. This can be a fruitful future area for more research. We also see a need for better empirical research methods, using case study methodology and experiments on isolated parts of SPL variability solutions. The way empirical research is reported also needs to be strengthened. The classification scheme we have developed can help in this regard.

References [1] P. America, D. K. Hammer, M. T. Ionita, J. H. Obbink, and E. Rommes. Scenario-based decision making for architectural variability in product families. In Proc. of the Third

[2]

[3]

[4]

[5]

[6]

[7]

[8]

[9]

[10]

[11]

[12]

[13]

[14]

Int. Conf. on Software Product Lines (SPLC 2004), pages 284–303, 2004. P. America, D. K. Hammer, M. T. Ionita, J. H. Obbink, and E. Rommes. Scenario-based decision making for architectural variability in product families. Software Process: Improvement and Practice, 10(2):171–187, 2005. P. America, E. Rommes, and J. H. Obbink. Multi-view variation modeling for scenario analysis. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 44–65, 2003. J. Andersson and J. Bosch. Development and use of dynamic product-line architectures. IEE Proceedings Software, 152(1):13–26, 2005. T. Asikainen, T. M¨annist¨o, and T. Soininen. A unified conceptual foundation for feature modelling. In Proc. of the 10th Int. Conf. on Software Product Lines (SPLC 2006), pages 31–40, 2006. F. Bachmann, M. Goedicke, J. C. S. do Prado Leite, R. L. Nord, K. Pohl, B. Ramesh, and A. Vilbig. A metamodel for representing variability in product family development. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 66– 80, 2003. J. Bailey, D. Budgen, M. Turner, B. Kitchenham, P. Brereton, and S. Linkman. Evidence relating to object-oriented software design: A survey. In Proc. of the First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007), pages 482–484, 2007. L. J. Bass, F. Bachmann, and M. Klein. Making variability decisions during architecture design. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 454–465, 2003. M. Becker, L. Geyer, A. Gilbert, and K. Becker. Comprehensive variability modelling to facilitate efficient variability treatment. In Proc. of the 4th International Workshop on Software Product-Family Engineering (PFE 2001), pages 294–303, 2001. K. Berg, J. Bishop, and D. Muthig. Tracing software product line variability: from problem to solution space. In Proc. of the 2005 annual research conference of the South African institute of computer scientists and information technologists on IT research in developing countries (SAICSIT ’05), pages 182–191, , Republic of South Africa, 2005. South African Institute for Computer Scientists and Information Technologists. D. Beuche, H. Papajewski, and W. Schr¨oder-Preikschat. Variability management with feature models. Sci. Comput. Program., 53(3):333–352, 2004. J. Bosch, G. Florijn, D. Greefhorst, J. Kuusela, J. H. Obbink, and K. Pohl. Variability issues in software product lines. In Proc. of the 4th International Workshop on Software Product-Family Engineering (PFE 2001), pages 13– 21, 2001. A. Braganc¸a and R. J. Machado. Extending uml 2.0 metamodel for complementary usages of the. In Proc. of the 10th Int. Conf. on Software Product Lines (SPLC 2006), pages 123–130, 2006. T. J. Brown, R. Gawley, R. Bashroush, I. T. A. Spence, P. Kilpatrick, and C. Gillan. Weaving behavior into feature

[15]

[16]

[17]

[18]

[19]

[20]

[21]

[22]

[23]

[24]

[25]

[26]

[27]

[28]

[29]

models for embedded system families. In Proc. of the 10th Int. Conf. on Software Product Lines (SPLC 2006), pages 52–64, 2006. R. Capilla and J. C. Due˜nas. Modelling variability with features in distributed architectures. In Proc. of the 4th International Workshop on Software Product-Family Engineering (PFE 2001), pages 319–329, 2001. P. Clements and L. Northrop. Software Product Lines: Practices and Patterns (The SEI Series in Software Engineering). Addison-Wesley Professional, 2001. K. Czarnecki, S. Helsen, and U. W. Eisenecker. Staged configuration using feature models. In Proc. of the Third Int. Conf. on Software Product Lines (SPLC 2004), pages 266– 283, 2004. K. Czarnecki, S. Helsen, and U. W. Eisenecker. Formalizing cardinality-based feature models and their specialization. Software Process: Improvement and Practice, 10(1):7– 29, 2005. K. Czarnecki, S. Helsen, and U. W. Eisenecker. Staged configuration through specialization and multilevel configuration of feature models. Software Process: Improvement and Practice, 10(2):143–169, 2005. K. Czarnecki and A. Wasowski. Feature diagrams and logics: There and back again. In Proc. of the 11th Int. Conf. on Software Product Lines (SPLC 2007), pages 23–34, 2007. S. Deelstra, M. Sinnema, and J. Bosch. Product derivation in software product families: a case study. Journal of Systems and Software, 74(2):173–194, 2005. T. Dyb˚a, T. Dingsøyr, and G. K. Hanssen. Applying systematic reviews to diverse study types: An experience report. In Proc. of the First International Symposium on Empirical Software Engineering and Measurement (ESEM 2007), pages 225–234, 2007. M. Eriksson, J. B¨orstler, and K. Borg. Software product line modeling made practical. Commun. ACM, 49(12):49–54, 2006. A. Fantechi, S. Gnesi, I. John, G. Lami, and J. D¨orr. Elicitation of use cases for product lines. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 152–167, 2003. A. Fantechi, S. Gnesi, G. Lami, and E. Nesti. A methodology for the derivation and verification of use cases for product lines. In Proc. of the Third Int. Conf. on Software Product Lines (SPLC 2004), pages 255–265, 2004. D. Fey, R. Fajta, and A. Boros. Feature modeling: A metamodel to enhance usability and usefulness. In Proc. of the Second Int. Conf. on Software Product Lines (SPLC 2002), pages 198–216, 2002. C. Fritsch and B. Renz. Four mechanisms for adaptable systems: a meta-level approach to building a software product line. Software Process: Improvement and Practice, 10(2):103–124, 2005. L. Geyer and M. Becker. On the influence of variabilities on the application-engineering process of a product family. In Proc. of the Second Int. Conf. on Software Product Lines (SPLC 2002), pages 1–14, 2002. M. Goedicke, C. K¨ollmann, and U. Zdun. Designing runtime variation points in product line architectures: three cases. Sci. Comput. Program., 53(3):353–380, 2004.

[30] A. Gruler, A. Harhurin, and J. Hartman. Development and configuration of service-based product lines. In Proc. of the 11th Int. Conf. on Software Product Lines (SPLC 2007), pages 107–116, 2007. [31] S. O. Hallsteinsen, T. E. Fægri, and M. Syrstad. Patterns in product family architecture design. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 261–268, 2003. [32] S. O. Hallsteinsen, E. Stav, A. Solberg, and J. Floch. Using product line techniques to build adaptive systems. In Proc. of the 10th Int. Conf. on Software Product Lines (SPLC 2006), pages 141–150, 2006. [33] A. Hein, M. Schlick, and R. Vinga-Martins. Applying feature models in industrial settings. In Proc. of the First Int. Conf. on Software Product Lines (SPLC 2000), pages 47–70, 2000. [34] A. Jansen, R. Smedinga, J. van Gurp, and J. Bosch. First class feature abstractions for product derivation. IEE Proceedings - Software, 151(4):187–198, 2004. [35] M. Jaring and J. Bosch. Representing variability in software product lines: A case study. In Proc. of the Second Int. Conf. on Software Product Lines (SPLC 2002), pages 15–36, 2002. [36] M. Jaring and J. Bosch. Variability dependencies in product family engineering. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 81–97, 2003. [37] M. Jaring, R. L. Krikhaar, and J. Bosch. Representing variability in a family of mri scanners. Softw., Pract. Exper., 34(1):69–100, 2004. [38] E. Kamsties, K. Pohl, S. Reis, and A. Reuys. Testing variabilities in use case models. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 6–18, 2003. [39] B. Keepence and M. Mannion. Using patterns to model variability in product families. IEEE Software, 16(4):102–108, 1999. [40] T. Kishi and N. Noda. Formal verification and software product lines. Commun. ACM, 49(12):73–77, 2006. [41] T. Kishi, N. Noda, and T. Katayama. Design verification for product line development. In Proc. of the 9th Int. Conf. on Software Product Lines (SPLC 2005), pages 150–161, 2005. [42] C. W. Krueger. Variation management for software production lines. In Proc. of the Second Int. Conf. on Software Product Lines (SPLC 2002), pages 37–48, 2002. [43] J. Lee and K. C. Kang. Feature binding analysis for product line component development. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 250–260, 2003. [44] J. Lee and K. C. Kang. A feature-oriented approach to developing dynamically reconfigurable products in product line engineering. In Proc. of the 10th Int. Conf. on Software Product Lines (SPLC 2006), pages 131–140, 2006. [45] J. Lee and D. Muthig. Feature-oriented variability management in product line engineering. Commun. ACM, 49(12):55–59, 2006. [46] K. Lee, K. C. Kang, M. Kim, and S. Park. Combining feature-oriented analysis and aspect-oriented programming for product line asset development. In Proc. of the 10th Int. Conf. on Software Product Lines (SPLC 2006), pages 103– 112, 2006.

[47] J. Liu, J. Dehlinger, and R. R. Lutz. Safety analysis of software product lines using state-based modeling. Journal of Systems and Software, 80(11):1879–1892, 2007. [48] F. Loesch and E. Ploedereder. Optimization of variability in software product lines. In Proc. of the 11th Int. Conf. on Software Product Lines (SPLC 2007), pages 151–162, 2007. [49] R. R. Lutz. Extending the product family approach to support safe reuse. Journal of Systems and Software, 53(3):207– 217, 2000. [50] A. Maccari and A. Heie. Managing infinite variability in mobile terminal software. Softw., Pract. Exper., 35(6):513– 537, 2005. [51] A. Maccari and C. Riva. Architectural evolution of legacy product families. In Proc. of the 4th International Workshop on Software Product-Family Engineering (PFE 2001), pages 64–69, 2001. [52] M. Mannion. Using first-order logic for product line model validation. In Proc. of the Second Int. Conf. on Software Product Lines (SPLC 2002), pages 176–187, 2002. [53] M. Mannion and J. Camara. Theorem proving for product line model verification. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 211–224, 2003. [54] I. McRitchie, T. J. Brown, and I. T. A. Spence. Managing component variability within embedded software product lines via transformational code generation. In Proc. of the 5th International Workshop on Software Product-family Engineering (PFE 2003), pages 98–110, 2003. [55] K. Mohan and B. Ramesh. Tracing variations in software product families. Commun. ACM, 50(12):68–73, 2007. [56] M. Moon and Y. Keunhyuk. An approach to develop requirement as a core asset in product-line. IEICE transactions on information and systems, 87(12):2744–2753, 2004. [57] M. Moon, K. Yeom, and H. S. Chae. An approach to developing domain requirements as a core asset based on commonality and variability analysis in a product line. IEEE Trans. Software Eng., 31(7):551–569, 2005. [58] H. Muccini and A. van der Hoek. Towards testing product line architectures. Electr. Notes Theor. Comput. Sci., 82(6), 2003. [59] A. Oberweis, V. Pankratius, and W. Stucky. Product lines for digital information products. Inf. Syst., 32(6):909–939, 2007. [60] J. Oldevik and O. Haugen. Higher-order transformations for product lines. In Proc. of the 11th Int. Conf. on Software Product Lines (SPLC 2007), pages 243–254, 2007. [61] F. G. Olumofin and V. B. Misic. A holistic architecture assessment method for software product lines. Information & Software Technology, 49(4):309–323, 2007. [62] J. P´erez, M. A. Laguna, Y. C. Gonz´alez-Carvajal, and B. Gonz´alez-Baixauli. Requirements variability support through mdatm and graph transformation. Electr. Notes Theor. Comput. Sci., 152:161–173, 2006. [63] K. Petersen, R. Feldt, S. Mujtaba, and M. Mattsson. Systematic mapping studies in software engineering. In Proc. of the 2008 annual research conference on Evaluation and Assessment in Software Engineering (Accepted).

[64] M. Pinzger, H. Gall, J.-F. Girard, J. Knodel, C. Riva, W. Pasman, C. Broerse, and J. G. Wijnstra. Architecture recovery for product families. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 332–351, 2003. [65] M. Raatikainen, T. Soininen, T. M¨annist¨o, and A. Mattila. A case study of two configurable software product families. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 403–421, 2003. [66] M. Raatikainen, T. Soininen, T. M¨annist¨o, and A. Mattila. Characterizing configurable software product families and their derivation. Software Process: Improvement and Practice, 10(1):41–60, 2005. [67] R. Rabiser, P. Grunbacher, and D. Dhungana. Supporting product derivation by adapting and augmenting variability models. In Proc. of the 11th Int. Conf. on Software Product Lines (SPLC 2007), pages 141–150, 2007. [68] M. O. Reiser and M. Weber. Multi-level feature trees: a pragmatic approach to managing highly complex product families. Requir. Eng., 12(2):57–75, 2007. [69] S. Salicki and N. Farcet. Expression and usage of the variability in the software product lines. In Proc. of the 4th International Workshop on Software Product-Family Engineering (PFE 2001), pages 304–318, 2001. [70] K. Schmid and I. John. A customizable approach to full lifecycle variability management. Sci. Comput. Program., 53(3):259–284, 2004. [71] R. W. Schwanke and R. R. Lutz. Experience with the architectural design of a modest product family. Softw., Pract. Exper., 34(13):1273–1296, 2004. [72] M. Sinnema and S. Deelstra. Classifying variability modeling techniques. Information & Software Technology, 49(7):717–739, 2007. [73] M. Sinnema, S. Deelstra, J. Nijhuis, and J. Bosch. Covamof: A framework for modeling variability in software product families. In Proc. of the Third Int. Conf. on Software Product Lines (SPLC 2004), pages 197–213, 2004. [74] C. Sinz, A. Haag, N. Narodytska, T. Walsh, E. Gelle, M. Sabin, U. Junker, B. O’Sullivan, R. Rabiser, D. Dhungana, P. Grnbacher, K. Lehner, C. Federspiel, and D. Naus. Product configuration support for nontechnicians: Customer-centered software product-line engineering. IEEE Intelligent Systems, 22(1):78–90, 2007. [75] J. Snyder, H. Lai, S. Reddy, and J. Wan. Software product line support in coremetrics oa2004. In Proc. of the Third Int. Conf. on Software Product Lines (SPLC 2004), pages 18–33, 2004. [76] S. D. K. Soo Ho Chang. A variability modeling method for adaptable services in service-oriented computing. In Proc. of the 11th Int. Conf. on Software Product Lines (SPLC 2007), pages 261–268, 2007. [77] M. Svahnberg, J. van Gurp, and J. Bosch. A taxonomy of variability realization techniques. Softw., Pract. Exper., 35(8):705–754, 2005. [78] P. Tessier, S. G´erard, F. Terrier, and J.-M. Geib. Using variation propagation for model-driven management of a system family. In Proc. of the 9th Int. Conf. on Software Product Lines (SPLC 2005), pages 222–233, 2005.

[79] S. Thiel. On the definition of a framework for an architecting process supporting product family development. In Proc. of the 4th International Workshop on Software Product-Family Engineering (PFE 2001), pages 125–142, 2001. [80] S. Thiel and A. Hein. Modeling and using product line variability in automotive systems. IEEE Software, 19(4):66–72, 2002. [81] J.-P. Tolvanen and S. Kelly. Defining domain-specific modeling languages to automate product derivation: Collected experiences. In Proc. of the 9th Int. Conf. on Software Product Lines (SPLC 2005), pages 198–209, 2005. [82] A. van der Hoek. Design-time product line architectures for any-time variability. Sci. Comput. Program., 53(3):285–304, 2004. [83] A. van Deursen, M. de Jonge, and T. Kuipers. Feature-based product line instantiation using source-level packages. In Proc. of the Second Int. Conf. on Software Product Lines (SPLC 2002), pages 217–234, 2002. [84] J. van Gurp and J. Savolainen. Service grid variability realization. In Proc. of the 10th Int. Conf. on Software Product Lines (SPLC 2006), pages 85–94, 2006. [85] M. Voelter and I. Grohner. Product line implementation using aspect-oriented and model-driven software development. In Proc. of the 11th Int. Conf. on Software Product Lines (SPLC 2007), pages 233–242, 2007. [86] T. von der Maßen and H. Lichter. Requiline: A requirements engineering tool for software product lines. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 168–180, 2003. [87] T. von der Maßen and H. Lichter. Determining the variation degree of feature models. In Proc. of the 9th Int. Conf. on Software Product Lines (SPLC 2005), pages 82–88, 2005. [88] D. L. Webber and H. Gomaa. Modeling variability in software product lines with the variation point model. Sci. Comput. Program., 53(3):305–331, 2004. [89] D. M. Weiss and R. Lai, editors. Software Product Line Engineering: A Family-Based Software Development Process. Addison-Wesley, 1999. [90] R. Wieringa, N. A. M. Maiden, N. R. Mead, and C. Rolland. Requirements engineering paper classification and evaluation criteria: a proposal and a discussion. Requir. Eng., 11(1):102–107, 2006. [91] J. G. Wijnstra. Evolving a product family in a changing context. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 111–128, 2003. [92] J. G. Wijnstra. Classifying product families using platform coverage and variation mechanisms. Softw., Pract. Exper., 35(5):413–444, 2005. [93] H. Ye and H. Liu. Approach to modelling feature variability and dependencies in software product lines. IEE Proceedings - Software, 152(3):101–109, 2005. [94] H. Zhang and S. Jarzabek. Xvcl: a mechanism for handling variants in software product lines. Sci. Comput. Program., 53(3):381–407, 2004. [95] T. Ziadi, L. H´elou¨et, and J.-M. J´ez´equel. Towards a uml profile for software product lines. In Proc. of the 5th International Workshop on Software Product-Family Engineering (PFE 2003), pages 129–139, 2003.