=Paper=
{{Paper
|id=None
|storemode=property
|title=Unifying Software, Product Configuration: A Research Roadmap
|pdfUrl=https://ceur-ws.org/Vol-958/paper6.pdf
|volume=Vol-958
|dblpUrl=https://dblp.org/rec/conf/confws/HubauxJDMMCHNZ12
}}
==Unifying Software, Product Configuration: A Research Roadmap==
https://ceur-ws.org/Vol-958/paper6.pdf
Unifying Software and Product Configuration:
A Research Roadmap
Arnaud Hubaux1 and Dietmar Jannach2 and Conrad Drescher3 and
Leonardo Murta4 and Tomi Männistö5 and Krzysztof Czarnecki6 and
Patrick Heymans7 and Tien Nguyen8 and Markus Zanker9
Abstract. Compared to the long history of computer-supported
For more than 30 years, knowledge-based product configu- configuration of products, research on the configuration of
ration systems have been successfully applied in many indus- parametrizable software is rather new. Product configuration
trial domains. Correspondingly, a large number of advanced (PC) is the umbrella activity of assembling and customizing
techniques and algorithms have been developed in academia physical artefacts (e.g. technical equipment, cars or muesli)
and industry to support different aspects of configuration rea- or services. Historically, PC has been a subfield of artificial
soning. While traditional research in the field focused on the intelligence (AI), focusing on knowledge representation and
configuration of physical artefacts, recognition of the business reasoning techniques to support configuration. Mostly inde-
value of customizable software products led to the emergence pendent of PC, the field of software product line engineer-
of software product line engineering. Despite the significant ing (SPLE) emerged in the software engineering community.
overlap in research interests, the two fields mainly evolved in SPLE deals with the design and implementation of software
isolation. Only limited attempts were made at combining the components that can be adapted and parametrized accord-
approaches developed in the different fields. In this paper, we ing to customer requirements and business or technical con-
first aim to give an overview of commonalities and differences straints [47]. As in PC approaches, the goal is to save costs
between software product line engineering and product config- by assembling individualized systems from reusable compo-
uration. We then identify opportunities for cross-fertilization nents [41]. Typical application domains for SPLE include em-
between these fields and finally develop a research agenda to bedded systems, device drivers, and operating systems.
combine their respective techniques. Ultimately, this should Interestingly, research in these two fields has been car-
lead to a unified configuration approach. ried out so far mostly independently. Except in rare cases
(e.g. [28, 5]), researchers in both fields are often unaware of
1 Introduction approaches that have been developed in the other commu-
nity. Further, even though a lot of PC work has focused on
Customizable products are an integral part of most B2B and configuring technical equipment, such equipment increasingly
B2C markets. Mass-customization strategies have been ap- contains software. At the same time, SPLE increasingly tar-
plied to tangible products (e.g., cars and mobile phones) as gets software-intensive systems that also include computing
well as intangible products like software (e.g., operating sys- and other types of equipment. Based on these observations,
tems and ERPs) and services (e.g., insurance). To this end, our hypothesis is that both the PC and SPLE communities
companies use software configurators that provide automated have produced results that are applicable in the other domain.
support to tailor products to the requirements of specific cus- The remainder of this paper explores further the opportu-
tomers or market segments. nity for cross-fertilization (Section 2) and proposes a research
1 PReCISE Research Center, University of Namur, Belgium,
roadmap (Section 3) to systematically compare the two do-
ahu@info.fundp.ac.be mains and foster efforts towards unifying both fields. In par-
2 Department of Computer Science, TU Dortmund, Germany, ticular, we hope to find innovative approaches to questions
dietmar.jannach@tu-dortmund.de that are largely open in one or the other community such
3 Computing Laboratory, University of Oxford, UK,
Conrad.Drescher@comlab.ox.ac.uk
as the reconfiguration of deployed systems, better interactive
4 Fluminense Federal University, Niterói, Brazil, configuration support (e.g., in case of unsatisfiable require-
leomurta@ic.uff.br ments), methods for full lifecycle support and the evolution
5 Aalto University School of Science, Finland, of models and knowledge bases. For this last question, we
Tomi.Mannisto@aalto.fi will also explore how techniques from software configuration
6 Generative Software Development Lab, University of Waterloo,
Canada, kczarnec@gsd.uwaterloo.ca management (CM) can be integrated.
7 PReCISE Research Center, University of Namur, Belgium,
phe@info.fundp.ac.be
8 Electrical and Computer Engineering Department, Iowa State 2 Motivation
University, USA, tien@iastate.edu
9 Alpen-Adria-Universität Klagenfurt, Austria, Questions of knowledge acquisition, knowledge representation
markus.zanker@aau.at as well as different types of reasoning support have been in-
vestigated for many years in PC and SPLE. We highlight partial configurations, or supporting interactive configuration
some key results in both fields to show their commonalities processes). In contrast, the SPLE community only started re-
and differences. These preliminary observations motivate our cently to develop a formal foundation of FMs (e.g. [9, 49])
endeavour to study, compare, and eventually unify research and their analyses (e.g. [5, 43, 33, 59]). Based on precise
on configuration. We split the introduction of our motivations formal problem characterizations, additional automations for
along five dimensions. For each dimension, we also formulate SPLE become feasible. An example is the automated analysis
the research questions whose answers should expose opportu- of FMs; see [10] for an overview. Furthermore, Benavides et
nities for cross-fertilization. al. [11] propose to translate FMs into a Constraint Satisfac-
tion Problem (CSP) and apply Reiter’s model-based diagno-
sis (MBD) approach to detect problems in the models. Xiong
2.1 Knowledge acquisition and modelling et al. [59] combine MBD and Satisfiability Modulo Theory
Research on PC has used a wide range of knowledge modeling (SMT) solvers to generate range fixes in software configura-
approaches (based, e.g., on UML [22] or description logic [40]), tion. Mendonca et al. [43] report on experiments with a SAT-
involving different types of logics and constraints. While a few encoding of FMs. Finally, Bagheri et al. [7], support hard and
SPLE approaches also used UML to capture aspects of config- soft requirements in the configuration process.
uration knowledge (e.g. [60, 25]), most results build upon the The SPLE community sometimes reinvents techniques
seminal work on feature-oriented domain analysis (FODA) which have been developed previously in PC. Encoding config-
initiated in 1990 by Kang et al. [37], which today is converg- uration problems in some logic or as CSPs has a long history
ing with decision models [17]. The cornerstone of FODA are in the AI community [34]. The PC community was also the
feature models (FMs), a graphical notation to capture and ex- first to apply SAT solvers to configuration problems [51]. New
press the commonalities and variabilities of a product family. CSP representations such as Dynamic, Composite or Genera-
FMs are menu-like hierarchies of mandatory, optional, and tive CSPs [45, 48, 54, 32] as well as logics [26, 4] were partially
alternative features, with cross-hierarchy relationships to ex- inspired by the challenges observed in PC. This latter pool of
press dependencies and incompatibilities. This initial FM no- techniques addresses the problem of conditionally including
tation has been gradually extended to support, for example, multiple instances of a certain component type. The PC com-
multiple instances [18, 44] or the configuration process [29]. munity was also first to use MBD for configuration, e.g., for
Compared to configuration modelling ontologies used in PC detecting problems in configuration knowledge bases [23]. Re-
(e.g., [22] or [53]), the expressiveness of FMs (even extended garding soft constraints and preferences, there is abundant lit-
ones) appears too limited compared to more complex PC on- erature in constraint programming (e.g. [36, 46]). Finally, bi-
tologies. Examples of advanced PC problems include connect- nary decision diagrams (BDDs) have also been used for build-
ing components via ports (i.e., inferring complex topologies), ing fast interactive configurators (trading time vs space from
finding optimal or at least good configurations, integrating a complexity point of view) [3]. That latter approach has been
iteratively new components, and distributing knowledge over explored in SPLE as well (e.g. [42]), but it turned intractable
different agents or business entities [32]. Some work exists in on large FMs.
SPLE on component connection and integration (e.g. [5]) and Opportunities for cross-fertilization: In contrast to
optimization (e.g. [58]). This motivated the creation of more physical components, software components are represented
expressive languages (e.g., [8]). PC appears to offer a richer completely as computer artifacts. While physical components
body of work in this area, though. need to be specified explicitly in the computer to check cross-
Opportunities for cross-fertilization: Some authors component compatibility, software configuration can analyze
have already acknowledged the bond between configuration in variability models and the actual configurable artifacts at the
PC and in SPLE through feature-based configuration. Günter same time. This opens up new possibilities for configuration,
et al. [27] recognize concept hierarchies (similar to FMs) as where the compatibility of components can be checked on
a fundamental concept in their survey of knowledge-based the fly during configuration without going back to the de-
configuration methods. According to Junker’s classification sign phase and modifying configuration knowledge. To iden-
of known configuration problems [34], feature-based configu- tify overlaps and differences between SPLE and PC, we in-
ration falls in the option selection or shopping list problems. clude the questions:
To systematically identify such synergies, our research agenda
RQ3 What automated tasks are supported (e.g., completion,
should answer the following questions:
repair, and optimization of configurations)?
RQ1 What classes of configuration problems exist? RQ4 How are these automated tasks implemented?
RQ2 How are these problems modelled?
2.3 Complexity
2.2 Automated reasoning
The computational complexity is an indicator of the amount
Generally, with respect to modeling and knowledge represen- of resources needed to solve a given problem. In PC, reason-
tation, the AI-rooted PC community is usually interested in ing is usually achieved by encoding the problem in formalisms
“executable” models that can be directly translated into a such as CSP, SAT, answer set programming or description
representation processable by a reasoning engine. The for- logics, all of which are being supported by mature reason-
mal basis of most knowledge modelling languages lays the ers. Both SAT and CSP are well-known to be NP complete
foundation for advanced configuration reasoning techniques [15, 38]. Some extensions of CSPs (dynamic, composite) poly-
(e.g., checking for consistency of configurations, completing nomially reduce to classical CSP [56] whereas the decidability
of Generative CSP has yet to be established. Ground answer Opportunities for cross-fertilization. To better pin-
set programs are NP complete (Σp2 complete in the case of op- point overlaps, we split the problem into three questions:
timization); if programs contain uninstantiated variables we
obtain NEXPTIME completeness [50, 19]. Description log- RQ7 What are the configuration tasks?
ics are typically decidable fragments of first order logic [6]; RQ8 How is a configurable product engineered?
the DLs used in PC range from polynomial over PSPACE RQ9 How is a configurator engineered?
complete to undecidable [35, 40, 12]. Let us emphasize that
the aforementioned complexity results are only upper bounds: 2.5 Knowledge evolution
Precise complexity results for classes of configuration prob-
lems are still too rare (e.g., [52]). The main concern of the software configuration management
The same symptom can be observed in SPLE where only a (CM) discipline is controlling and tracking the evolution of
tiny fraction of the papers study complexity aspects (e.g. [49]). products in response to changes. To do so, it introduces the
While some experimental results exist, e.g., [43], theoretical concept of versions that represent instances of products and
results are largely missing. its parts over time. In CM, there are two main types of
Opportunities for cross-fertilization. Although to a versions [14]: revisions and variants. Revisions are versions
different extent, both PC and SPLE do not fully cover ques- that supersede other versions due to bug fixes or addition of
tions related to the complexity of the automated tasks they new functionalities. Variants are versions intended to coexist
support for different classes of configuration problems. To fol- through time to satisfy different user or platform needs. Vari-
low up on RQ1 and RQ3, we propose these new questions ants are well known in the PC and SPLE fields. However, the
that study their complexities: management of revisions and the interaction of both is still
a weakness of PC and SPLE, especially when the product
RQ5 What is the complexity of automated tasks for relevant and its parts evolve frequently. The need to deploy change
classes of configuration problems? management techniques in SPLE is recognized [13, 47], and
RQ6 What reasoning frameworks can be used to build scal- some researchers have started working in this direction (e.g.
able tools for each class of configuration problems? [2, 57]). Although promising, these results are still incomplete,
and need to be extended and consolidated.
2.4 Life cycle coverage Problems related to the evolution of the configuration
knowledge and system (e.g. knowledge base, database, and
SPLE suffers from a certain lack of homogeneity across the product instances) are also known in PC [21]. PC research
modelling artefacts used throughout the engineering life cy- has addressed some of these evolution-related aspects in the
cle. From requirements engineering down to code generation, context of reconfiguration problems (e.g. [55, 24]), which con-
a myriad of alternative techniques exist which are used and sist in changing an already existing or deployed configuration
combined differently depending on the application domain to accommodate new or changed customer requirements or
and project context. Therefore, there is no standard view constraints in the knowledge base. Männistö et al. [39] dis-
on how they should be integrated. As for PC, configuration cuss the issue of the evolution of configuration knowledge and
tasks can range from bill-of-material configuration over ce- instances, proposing a framework to address it. The key idea
ment factory design to t-shirt customization. These tasks call is to accept the independence of these evolutions, capture the
for very different methods and techniques whose applications evolution in the models, and then do reconfiguration. Prob-
have been insufficiently studied. Additionally, the creation of lems similar to reconfiguration have been addressed in the
feedback loops from productive use back to variability de- software domain: given a component-based software installa-
sign decisions is rather explored in the more business- or tion (e.g. Linux, Eclipse), the component dependencies and
management-centric literature without transfer to PC. an (un-)install request, compute a best new installation [1].
Configurator engineering is a more mature discipline in PC Another practical challenge both in PC and SPLE is the
than in SPLE, aiming at the co-design of the configurator and constantly growing number of components that can be part
the configurable artefact. According to Hvam et al. [30], the of a configuration, be they semi-conductors, switches, or soft-
creation, implementation and operation of a configurator is ware plug-ins. The corresponding knowledge bases soon be-
a seven-phase procedure. The first phase identifies the prod- come hard to manage because they describe how older compo-
uct specification process, used for analyzing customer needs, nents have to be replaced by newer ones or which component
creating a customized product, and prescribing other related versions are compatible.
activities, such as purchasing, delivery, servicing, and recy- In CM, some have tried to provide a unified model for soft-
cling. The specification process also defines the configuration ware CM and product data management (e.g. [20, 16]). Those
system that supports the activities composing it. The sec- models stop at the conceptual level without providing opera-
ond phase deals with the definition of the product portfolio. tional solutions, however.
Phases three to six deal with the modelling and implementa- Opportunities for cross-fertilization. Since the 1970s,
tion of the configuration system. The seventh phase focuses research in CM focused on change management. Mature so-
on maintenance. lutions are now available and could be applicable to PC. Fur-
Finally, the commercial side of configuration is also impor- thermore, researchers in SPLE and PC could join forces to de-
tant. PC has to deal typically with sales, consumer goods, velop scalable techniques to address the explosion of the num-
and engineers, wheras SPLE is more geared towards software ber of components and their evolution. Those results could
engineers and other technical experts. Although stakeholder then be contributed back to CM. The resulting questions are:
profiles vary from one case to the other, some configuration
tasks overlap and techniques could be shared. RQ10 How can CM techniques be applied to PC and SPLE?
RQ11 How to scale up with growing revision knowledge? 4 Conclusion
Configuration, both of software and other types of products,
3 Research Roadmap continues to be a timely business strategy as customers consis-
The first step of our project was the composition of an hetero- tently strive for affordable tailor-made products. Yet, research
geneous panel of experts from the different communities and in product and software configuration progresses on different
the creation of a knowledge exchange portal. Once populated and rarely intersecting paths. This paper (1) motivated the
with our initial results, our intention is to open this shared need for bridging the current gap between these two domains,
portal to a wider community and invite collaborations. Our and (2) presented a roadmap to build such a bridge and set
research roadmap has five phases. cross-fertilization in motion.
Our initial observations show that the contribution of the
1. Literature survey. The first phase focuses on a litera- research in product configuration to software product config-
ture survey that should answer RQ1-9. The part of the uration is rather glaring. The inverse is, however, less obvi-
survey related to RQ1-4 is already underway. The body ous. As possible contributions, we see methodological aspects
of knowledge gathered during this initial phase will be the as well as modelling techniques. Once laid upon more for-
foundation upon which the panel will start its unification mal foundations, some of these models could further improve
endeavour. product configuration.
2. Domain understanding and classification. The sec- Finally, the evolution problem is still under-explored in
ond phase paves the road toward a unified theory of config- both software and product configuration. They both have a
uration. Its objective is to analyze the material collected in lot to gain from the techniques promoted in configuration
the first phase, to classify the application domains, study management. Conversely, the formal treatment of configura-
their differences and commonalities, and to identify the pos- tion problems and automated reasoning could enhance exist-
sible bridges between these domains. ing work in configuration management.
3. Unified theory definition. The foundation for this the-
ory will be a mathematical model of the classes of con-
figuration problems and their properties. These classes of REFERENCES
configuration problems will be characterized by the expres- [1] P. Abate, R. Di Cosmo, R. Treinen, and S. Zacchiroli, ‘De-
siveness needed to solve the problems. Analogous to the pendency solving: a separate concern in component evolution
classification of description logics [6], this will enable the management’, Systems and Software, (2012). To appear.
study of the theoretical complexity of the associated com- [2] M. Anastasopoulos, D. Muthig, T. H. B. de Oliveira, E. S.
putational problems. Problem frames [31] could be used as Almeida, and S. R. de Lemos Meira, ‘Evolving a software
product line reuse infrastructure: A configuration manage-
the macro-structure for this classification. ment solution’, in Proc. VaMoS’09, Sevilla, (2009).
4. Unified theory operationalization. Upon this defini- [3] H. R. Andersen, T. Hadzic, and D. Pisinger, ‘Interactive cost
tion, we will build two layers: modelling languages and rea- configuration over decision diagrams’, Artificial Intelligence
soning techniques. In the modelling layer, we will first sort Research (JAIR), 37, 99–139, (2010).
[4] M. Aschinger, C. Drescher, and H. Vollmer, ‘LoCo - A Logic
existing languages according to the configuration problems for Configuration Problems’, in Proceedings of the 20th Eu-
they address. We will then work toward their unification, ropean Conference on Artificial Intelligence (ECAI), Mont-
possibly by mapping into a common core language. The pellier, France, (2012).
reasoning layer will gather the configuration tasks (e.g., [5] T. Asikainen, T. Soininen, and T. Männistö, ‘A Koala-based
consistency check, repair, and completion) identified in the approach for modelling and deploying configurable software
product families’, in Porc PLE’03, Springer LNCS 3014, pp.
previous phases. For each task and a class of configuration 225–249, (2003).
problems captured by a language, we will study alterna- [6] The Description Logic Handbook: Theory, Implementation,
tive reasoning techniques and assess their applicability (see and Applications, eds., F. Baader, D. Calvanese, D. L.
next phase). Finally, we will investigate how version man- McGuinness, D. Nardi, and P. F. Patel-Schneider, Cambridge
University Press, 2003.
agement techniques from CM can be adapted to support [7] E. Bagheri, T. Di Noia, A. Ragone, and D. Gasevic, ‘Con-
configuration evolution. Based on these elements, we will figuring software product line feature models based on stake-
answer RQ6, 10 and 11. holders’ soft and hard requirements’, in SPLC’10, pp. 16–31,
5. Unified theory validation. Configuration can be ap- (2010).
plied in a myriad of application domains to support many [8] K. Bak, K. Czarnecki, and Andrzej W., ‘Feature and meta-
models in clafer: Mixed, specialized, and coupled’, in Proc.
different usage scenarios. Each situation will need its own SLE’10, pp. 102–122, Eindhoven, The Netherlands, (2010).
benchmarks and analyses. The objective of the panel will Springer-Verlag.
be to validate the results of the theory operationalization [9] D. Batory, ‘Feature models, grammars, and propositional for-
on a few industry-size models. In particular, it will seek mulas’, in SPLC’05, pp. 7–20, Rennes, France, (2005).
[10] D. Benavides, S. Segura, and A. Ruiz-Cortes, ‘Automated
to better understand the respective merits and limitations analysis of feature models 20 years later: a literature review’,
of the various reasoning techniques. Benchmarks will be Information Systems, 35(6), 615 – 636, (2010).
needed to assess their applicability and tractability on var- [11] D. Benavides, P. Trinidad, and Ruiz-Cortez A., ‘Automated
ious classes of problems. This pilot validation will be a first reasoning on feature models’, in Proc. CAiSE’05, pp. 491–
step in setting up a framework in which parallel efforts of 503, Porto, Portugal, (2005). Springer.
[12] M. Buchheit, R. Klein, and W. Nutt, ‘Constructive Problem
the community could commence. Solving: A Model Construction Approach towards Configura-
tion’, Technical Report TM-95-01, DFKI, (1995).
This roadmap is not intended to be executed in a waterfall [13] P. Clements and L. Northrop, Software Product Lines: Prac-
fashion: we expect several iterations through phases 2-5. tices and Patterns, Addison-Wesley, 2001.
[14] R. Conradi and B. Westfechtel, ‘Version models for software [38] A. K. Mackworth, ‘Consistency in networks of relations’, Ar-
configuration management’, ACM Computing Surveys, 30, tificial Intelligence, 8, 99–118, (1977).
232–282, (June 1998). [39] T. Männistö, A Conceptual Modelling Approach to Product
[15] S. A. Cook, ‘The complexity of theorem-proving procedures’, Families and Their Evolution, Ph.D. dissertation, Helsinki
in Proceedings of the 3rd Annual ACM Symposium on Theory University of Technology, Finland, 2000.
of Computing, (1971). [40] D. L. McGuinness and J. R. Wright, ‘Conceptual modelling
[16] I. Crnkovic, U. Asklund, and A. P. Dahlqvist, Implementing for configuration: A description logic-based approach’, Artif.
and integrating product data management and software con- Intell. Eng. Des. Anal. Manuf., 12(4), 333–344, (1998).
figuration management, Artech House Publishers, 2003. [41] M. D. McIlroy, ‘Mass produced software components’, in
[17] K. Czarnecki, P. Grunbacher, R. Rabiser, K. Schmid, and Proc. Software Engineering Concepts and Techniques, pp.
A. Wasowski, ‘Cool features and tough decisions: Two decades 138–150. NATO Science Committee, (1968).
of variability modeling’, in Proc. VaMoS’12, Leipzig, Ger- [42] M. Mendonça, Efficient Reasoning Techniques for Large Scale
many, (2012). ACM Press. Feature Models, Ph.D. dissertation, U Waterloo, 2009.
[18] K. Czarnecki, S. Helsen, and U. W. Eisenecker, ‘Staged con- [43] M. Mendonça, A. Wasowski, and K. Czarnecki, ‘SAT-based
figuration through specialization and multi-level configura- analysis of feature models is easy’, in Proc. SPLC’09, pp.
tion of feature models’, Software Process: Improvement and 231–240, San Francisco, (2009). Carnegie Mellon University.
Practice, 10(2), 143–169, (2005). [44] R. Michel, A. Classen, A. Hubaux, and Q. Boucher, ‘A for-
[19] E. Dantsin, T. Eiter, G. Gottlob, and A. Voronkov, ‘Com- mal semantics for feature cardinalities in feature diagrams’,
plexity and expressive power of logic programming’, ACM in Proc. Wks. VaMoS’11, pp. 82–89, Namur, BE, (2011).
Computing Surveys, 33(3), 374–425, (2001). [45] S. Mittal and B. Falkenhainer, ‘Dynamic constraint satisfac-
[20] J. Estublier, J.-M. Favre, and P. Morat, ‘Toward scm / pdm tion problems’, in AAAI’90, pp. 25–32, Boston, (1990).
integration?’, in Proc. SCM’98, pp. 75–94, London, UK, UK, [46] M. Pasanen, Warnings and Pre-selection Packages in a
(1998). Springer-Verlag. Weight Constraint Rule Based Configurator, Master’s thesis,
[21] A. Falkner and A. Haselböck, ‘Challenges of knowledge evolu- Helsinki University of Technology, Department of Computer
tion in practice’, in ECAI 2010 IKBET Wks, pp. 1–5, (2010). Science and Engineering, Finland, 2003.
[22] A. Felfernig, G. Friedrich, and D. Jannach, ‘UML as domain [47] K. Pohl, G. Böckle, and F. J. van der Linden, Software Prod-
specific language for the construction of knowledge-based con- uct Line Engineering: Foundations, Principles and Tech-
figuration systems’, in Proc. SEKE 99, pp. 337–345, Kaiser- niques, Springer, 2005.
slautern, Germany, (1999). [48] D. Sabin and E. C. Freuder, ‘Configuration as Composite
[23] A. Felfernig, G. Friedrich, D. Jannach, and M. Stumpt- Constraint Satisfaction’, in Proceedings of the Artificial In-
ner, ‘Consistency-based diagnosis of configuration knowledge telligence and Manufacturing Research Planning Workshop
bases’, Artificial Intelligence, 152, 213–234, (2004). (AIMRP), Albuquerque, New Mexico, (1996).
[24] G. Friedrich, A. Ryabokon, A. Falkner, A. Haselböck, [49] P-Y. Schobbens, P. Heymans, J-C. Trigaux, and Yves Bon-
G. Schenner, and H. Schreiner, ‘(Re)configuration based on temps, ‘Generic semantics of feature diagrams’, Comput.
model generation’, in Proc. LoCoCo Workshop, EPTCS, pp. Netw., 51(2), 456–479, (2007).
26–35, (2011). [50] P. Simons, I. Niemelä, and T. Soininen, ‘Extending and imple-
[25] H. Gomaa and M. Eonsuk Shin, ‘Multiple-view modelling menting the stable model semantics’, Artificial Intelligence,
and meta-modelling of software product lines’, IET Software, 138(1–2), 181–234, (2002).
2(2), 94–122, (2008). [51] C. Sinz, A. Kaiser, and W. Küchlin, ‘SAT-based consistency
[26] G. Gottlob, G. Greco, and T. Mancini, ‘Conditional Con- checking of automotive electronic product data’, in ECAI
straint Satisfaction: Logical Foundations and Complexity’, in Workshop, (2000).
Proceedings of the 20th International Joint Conference on [52] T. Soininen, An Approach to Knowledge Representation and
Artificial Intelligence (IJCAI), Hyderabad, India, (2007). Reasoning for Product Configuration Tasks, Ph.D. disserta-
[27] A. Günter and C. Kühn, ‘Knowledge-based configuration: tion, 2000.
Survey and future directions’, in Proc. XPS’99, pp. 47–66, [53] T. Soininen, J. Tiihonen, T. Männistö, and R. Sulonen, ‘To-
London, (1999). wards a general ontology of configuration’, AIEDAM, 12,
[28] L. Hotz, K. Wolter, and T. Krebs, Configuration in Industrial 357–372, (1998).
Product Families: The ConIPF Methodology, IOS Press, Inc., [54] M. Stumptner, A. Haselböck, and G. Friedrich, ‘Generative
2006. Constraint-based Configuration of Large Technical Systems’,
[29] A. Hubaux, A. Classen, and P. Heymans, ‘Formal modelling of AI EDAM, 12(4), 307–320, (1998).
feature configuration workflow’, in Proc. SPLC’09, pp. 221– [55] M. Stumptner and F. Wotawa, ‘Model-based reconfiguration’,
230, San Francisco, (2009). in Proc. AID’98, pp. 45–64, (1998).
[30] L. Hvam, N. Henrik Mortensen, and J. Riis, Product Cus- [56] E. Thorstensen, ‘Capturing Configuration’, in Doctoral Pro-
tomization, Springer-Verlag Berlin Heidelberg, 2008. gram at the 16th International Conference on Principles
[31] M. Jackson, Problem frames: analyzing and structuring soft- and Practice of Constraint Programming (CP), St. Andrews,
ware development problems, Addison-Wesley, 2001. Scotland, (2010).
[32] D. Jannach and M. Zanker, ‘Modeling [57] T. Thum, D. Batory, and C. Kastner, ‘Reasoning about edits
and solving distributed configuration prob- to feature models’, in Proc. ICSE’09, pp. 254–264, Washing-
lems: A CSP-based approach’, IEEE TKDE, ton, DC, USA, (2009). IEEE Computer Society.
http://doi.ieeecomputersociety.org/10.1109/TKDE.2011.236. [58] T. T. Tun, Q. Boucher, A. Classen, A. Hubaux, and P. Hey-
[33] M. Janota, ‘Do SAT solvers make good configurators?’, in mans, ‘Relating requirements and feature configurations: A
Proc. ASPL’08, pp. 191–195, Limerick, Ireland, (2008). systematic approach’, in Proc. SPLC’09, pp. 201–210, San
[34] U. Junker, Handbook of Constraint Programming, chapter Francisco, CA, USA, (2009). ACM Press.
Configuration, 837–873, Elsevier, 2006. [59] Y. Xiong, A. Hubaux, and K. Czarnecki, ‘Generating range
[35] U. Junker and D. Mailharro, ‘The logic of ILOG fixes for software configuration’, in Proc. ICSE’12, Zurich,
(J)Configurator: Combining constraint programming with a Switzerland, (2012). IEEE Computer Society.
description logic’, in Proc. IJCAI-03 Configuration Work- [60] T. Ziadi, L. Helouet, and J.-M. Jezequel, ‘Towards a UML
shop, (2003). profile for software product lines’, in Software Product-Family
[36] U. Junker and D. Mailharro, ‘Preference programming: Ad- Engineering, Springer LNCS 3014, 129–139, (2004).
vanced problem solving for configuration’, AIEDAM, 17(1),
13–29, (2003).
[37] K. Kang, S. G. Cohen, J. A. Hess, W. E. Novak, and A. S.
Peterson, ‘Feature-Oriented Domain Analysis (FODA) Feasi-
bility Study’, Technical report, SEI, CMU, (1990).