Preference-based Conflict Resolution for Collaborative Configuration of
Product Lines
Sabrine Edded
, Sihem Ben Sassi
, Raul Mazo
, Camille Salinesi
and Henda Ben Ghezala
Centre de Recherche en Informatique (CRI), Universit
e Panth
eon Sorbonne, Paris, France
RIADI Lab., National School of Computer Sciences, Manouba University, Tunisia
MIS Department - CBA, University of Taibah, P.O. Box 344, Al-Madinah, Saudi Arabia
Lab-STICC, ENSTA Bretagne, Brest, France
Product Lines, Collaborative Configuration, Conflict Resolution, Minimal Correction Subsets.
In the context of Product lines, the collaborative configuration process gets complicated when the configura-
tion decisions of involved stakeholders are contradictory, which may lead to conflicting situations. Although
considerable research has been devoted to collaborative configuration, little attention has been paid to conflict
resolution. Moreover, most of existing approaches rely on a systematic process which constraint decisions
of some stakeholders. In this paper, we propose a new collaborative configuration approach which allows
conflict resolution based on stakeholders preferences expressed through a set of substitution rules. Based on
such preferences, we delete the minimal set of conflicting configuration decisions which are identified using
the Minimal Correction Subsets (MCSs) computing algorithm. An illustrating example and a tool prototype
are presented to evaluate the applicability of our approach.
The configuration process is a crucial step in Software
Product Line Engineering (SPLE) that refers to fea-
ture selection from a product line model (Clements
and Northrop, 2001). The larger the product line
model, the more configurations can be created. On
industrial scale product line models, it cannot be ex-
pected that configuration activities are handled by sin-
gle user solely responsible of all configuration deci-
sions (Mendonca et al., 2008). This is not only be-
cause of the number of decisions to make, but also
because of the multidisciplinary nature of product line
models (engineering, marketing, etc). Sharing config-
uration decisions between stakeholders is highly de-
sirable in order to cope with the issues of the config-
uration process which is referred to as collaborative
configuration process.
Real life product lines models can contain up to
10,000 features (Batory et al., 2006). In such a case,
the configuration becomes an arduous and error prone
task. Ensuring compromise between all stakehold-
ers configuration decisions during conflict resolution
presents a critical issue. Potentially, the more there
are constraints, the higher the effort is to resolve con-
flicts. Moreover, resolving such situations can not be
considered effective if it does not take into account
the configuration decisions of stakeholders.
To cope with conflict resolution issues, several
proposals such as those proposed by (Czarnecki et al.,
2005),(Mendonca et al., 2007),(Mendonca et al.,
2008), (Rabiser et al., 2009) and (Hubaux et al., 2010)
adopted a staged configuration principle where con-
figuration decisions are refined on multiple steps by
different stakeholders and arranged by a workflow.
The workflow approach has a significant disadvan-
tage; namely the configuration process lacks flexibil-
ity. Such a method poses several obstacles for inter-
active negotiation of the different requirements and
in many cases, choices made in earlier stages over-
lay those in later phases. In addition, activities of
some stakeholders would have side effects on those
performed by other stakeholders, sometimes through
propagation that can be hard to anticipate and solve
The resulting lack of flexibility is likely to be
a limitation when resolving conflicts as the adopted
conflict resolution strategy will not ensure the satis-
faction of all stakeholders and consider their prefer-
We thus in this paper, propose a new product line
collaborative configuration approach to improve the
Edded, S., Ben Sassi, S., Mazo, R., Salinesi, C. and Ben Ghezala, H.
Preference-based Conflict Resolution for Collaborative Configuration of Product Lines.
DOI: 10.5220/0009346102970304
In Proceedings of the 15th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2020), pages 297-304
ISBN: 978-989-758-421-3
2020 by SCITEPRESS – Science and Technology Publications, Lda. All rights reserved
conflict resolution process, by allowing stakeholders
to express preferences through a set of subsitution
rules and then deleting the minimal set of conflict-
ing configuration decisions according to these pref-
erences. Major collaborative configuration issues are
discussed such as the lack of configuration process
flexibility and the systematic strategy of conflict res-
olution. Finally, evidence of the feasibility of the pro-
posed approach is shown through an illustrative ex-
ample and by introducing a support tool.
The remainder of this paper is organized as fol-
lows. Section 2 provides preliminaries. Section 3
is devoted to the proposed collaborative configuration
approach. Section 4 illustrates the approach using an
example on the web portal domain. Section 5 covers
related work and Section 6 concludes the paper.
To understand our approach, the knowledge about
conflict within collaborative configuration of product
lines and Minimal Correction Subsets (MCSs) is im-
portant. They are briefly discussed in this section.
2.1 Conflict Definition
In the context of product line collaborative configu-
ration, conflict management is of paramount impor-
tance. According to (Mendonca et al., 2007), conflict
occurs when two or more features contain explicit or
implicit dependencies rely on each other’s decision
state. Likewise, (Osman et al., 2009) outlined that a
conflict occurs when two or more configuration deci-
sions assigned to different stakeholders cannot be true
at the same time.
Formally a conflict can be defined as follows:
Definition. For a configuration Co composed of a set
of configuration decisions {Cd
}, a subset Cflt Co
is a conflict, if Co is unsatisfiable and Cd
} is satisfiable.
2.2 Conflict Types
Conflicts can be categorized into two different types
as illustrated in Table 1.
Explicit Conflict: represents the case where the
configuration decisions about the same feature
made by two or more stakeholders are contradic-
tory (feature selected by a stakeholder and unde-
sired by another).
Implicit Conflict: represents the case where the
configuration decisions of different stakeholders
Table 1: Conflict Types in Collaborative Configuration.
Conflict type Illustration
Stakeholder 1
Stakeholder 2
Stakeholder 2
Stakeholder 1
Stakeholder 1 Stakeholder 2
Stakeholder 1
Stakeholder 2
do not respect the constraints of the model / do-
main of the product line. Here, three situations
are distinguished:
Situation 1: conflict occurs when a feature A
selected by a stakeholder 1 requires a feature B
which undesirable by stakeholder 2.
Situation 2: conflict occurs when a feature A
excludes feature B and both are selected by two
Situation 3: conflict occurs when two or more
features are alternative and all are selected by
different stakeholders.
2.3 Minimal Correction Subsets
In the proposed approach we make use of MCSs com-
puting algorithm to identify the minimal set of con-
flicting configuration decisions to be deleted.
According to (Liffiton and Sakallah, 2008), a MCS
is an irreducible subset of constraints whose removal
makes satisfiable a constraint program.
Formally an MCS can be defined as follows:
Definition. A subset of constraints M C is a MCS,
if C\M is satisfiable and C
}) is un-
Computing MCSs has been the subject of several
research works in the fields of Boolean satisfiabil-
ity and constraint satisfaction problems. The goal is
ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering
to find minimal sets of clauses whose removal ren-
ders given unsatisfiable Conjunctive Normal Formula
(CNF) satisfiable.
Different approaches have been proposed over the
years for computing MCSs such as those proposed by
(Bailey and Stuckey, 2005), (Liffiton and Sakallah,
2008) and (Marques-Silva et al., 2013). Most of
these approaches consist on making iterative calls to a
SAT solver to check the satisfiability of different sub-
formulas. Generally, these algorithms handle a triplet
{S, U, C} of F, where S is a satisfiable sub-formula,
C contains clauses which are inconsistent with S (i.e.
c C, S {c} |= ), and U contains the remain-
ing clauses of F. For a first call, the solver computes
a complete assignment µ satisfying F
in order to
initialize S (resp. U) containing the satisfied clauses
(resp. unsatisfied) by µ, and C as the empty set. Note
S. In the end, S (C) will be an MCS of F and U
will become empty.
MaxSAT (Liffiton and Sakallah, 2008), represents
the most widely adopted approach for computing
MCSs that consists of finding an assignment that sat-
isfies the maximum number of clauses of an unsatisfi-
able formula (Marques-Silva et al., 2013). Therefore,
finding MCSs is related to the MaxSAT (or MaxCSP)
problem, which consists in finding a minimal subset
of assignment satisfying the different clauses of un-
satisfiable CNF. This represents an optimal solution
to MaxSAT.
In this paper, we will make use of (Liffiton and
Sakallah, 2008) approach to compute MCSs for con-
flict resolution within collaborative configuration of
Product lines.
To cope with collaborative configuration issues, we
propose a new configuration approach where stake-
holders freely express their configuration decisions
and conflicts are resolved based on their preferences.
A summary of the proposed approach is depicted
in Figure 1. The approach encompasses four main
steps: (1) the substitution rules selection, (2) collabo-
rative configuration, (3) configuration verification and
(4) conflict resolution.
3.1 Substitution Rules Selection
Substitution rules represent a recovery plan that per-
mit stakeholders to express their preferences if one or
more of their configuration decisions could not be re-
tained in case of conflict.
Figure 1: Overview of the Proposed Approach.
The proposed list is composed of ve substitution
rules described as follows :
SR1. Most complete Product: includes the max-
imum as possible of features selected by the dif-
ferent stakeholders.
SR2. Simplest Product: includes the minimum
as possible of features selected by the different
SR3. Product Similar to a Past Configuration:
previous configuration that contains the same fea-
tures selected by the current stakeholder.
SR4. Product Configured by a Similar Pro-
file: two profiles are similar when two stakehold-
ers share the same concern (engineers, project
managers, managers, marketing, sales, customers,
users, etc.). Therefore, the configuration deci-
sions made by the current stakeholder will be
aligned with those made by the stakeholder with
the same profile.
SR5. Prioritize my Explicit Decisions: consid-
ering configuration decisions explicitly expressed
through feature selection.
During the first step of the proposed approach, each
stakeholder selects the set of desired substitution
rules. Each rule refers to the removal of a specific
MCS as presented in Table 2. In the context of the
proposed approach, a MCS represents the set of con-
figuration decisions whose removal makes satisfiable
the current configuration.
In case of conflict, the selected rules are applied
on the list of computed MCSs to identify the res-
olution MCS which is the one common among all
these rules. Moreover, a priority order is also assigned
by the product manager to the different stakeholders
which serves as a secondary MCS selection criterion
if the selected rules do not return any common MCS.
Preference-based Conflict Resolution for Collaborative Configuration of Product Lines
Table 2: List of Substitution Rules and the Corresponding MCS.
Substitution rule Corresponding MCS
SR1 most complete product MCS that eliminates the minimum of features
SR2 simplest product MCS that eliminates the maximum of features
SR3 product similar to a past configuration MCS that respects features present in a similar past configuration
SR4 product configured by a similar profile MCS that respects configuration decisions of similar profile
SR5 prioritize my explicit decisions MCS that respects explicit configuration decisions of the stakeholder
3.2 Collaborative Configuration
During the configuration process, the different stake-
holders freely express their configuration decisions
towards the desired product without being constrained
to the configuration decisions made by the other
In the context of the proposed approach, a con-
figuration decision permits stakeholders to explicitly
express both, the list of desired features and the list of
undesired features. Formally a configuration decision
(Cd) can be defined as follows:
Cd {F, ¬ F}, Cd= F, if the feature is desired by the
stakeholders, Cd= ¬ F, if the feature is undesired by
the stakeholder.
The final configuration encompasses all the
mandatory features that any derived product should
contain and all the partial configurations made by the
different stakeholders.
Formally a partial configuration of a given feature
model (fm) can be defined as follows:
c f = hfm , {Cd
}i, where {Cd
} represents the
set of the decisions made by a stakeholder (Sh). The
consistency of each partial configuration is ensured
through an automatic propagation of constraints.
The final configuration, can be formally defined as
follows: Cf
= hfm, {Sh c f }i, where {Sh c f } repre-
sents the set of all the partial configurations.
3.3 Configuration Verification
During the verification step, the partial configurations
of all stakeholders are merged and checked against the
list of conflict types described in Section 2.
The configuration verification is ensured by a SAT
solver. Therefore, the configuration is formulated as
CNF where each configuration decision is represented
as single clause. In case of conflict detection, the
MAXSAT algorithm of (Liffiton and Sakallah, 2008)
is used to compute the list of all the possible MCSs
for a given unsatisfiable configuration.
Considering the set of substitution rules selected
by stakeholders, the MCS that better meets these rules
is then chosen to resolve the detected conflict(s).
3.4 Conflict Resolution
To resolve conflicts, we propose an algorithm that per-
mits identifying the resolution MCS that better sat-
isfies stakeholders preferences expressed through se-
lected substitution rules.
We have chosen to compute MCSs as they permit
finding minimal sets of conflicting configuration de-
cisions whose removal renders the configuration sat-
isfiable. Thus, we can ensure in part the satisfaction
of stakeholders by removing the minimal set of their
inconsistent choices.
The inputs of the proposed algorithm (Algo-
rithm 1) are the list of rules selected by stakeholders
(S_rules), list of computed MCSs (MCS_list). As
output, the algorithm delivers the MCS of conflict res-
olution (R_MCS) according to the set of substitution
rules selected by stakeholders.
The algorithm applies at first the list of selected
rules (S_rules) on the list of computed MCSs
(MCS_list) according to the correspondence list pre-
sented in Table 2. A substitution rule may return
none or many MCSs. Therefore, (Result_list)
contains the different lists of MCSs returned by each
rule. In such a case, it is possible that (Result_list)
contains common MCS(es) between all the result-
ing MCSs lists. Then, the Boolean function (has-
Common) checks the commonality between all the
returned lists present in (Result_list). If there is
commonality (hasCommon(Result list)= True), then
the function (ComputeCommonList(Result list)) re-
turns the list of common MCSs (Com_list).
If there is one common MCS (Size(Com list)=1),
this one is returned as solution(R_MCS). If more than
one MCS are common (Size(Com list)>1), the func-
tion (Get Priority Based) is applied on the set of
common MCSs (Com_list) to select a MCS that bet-
ter respects the configuration decisions of the priori-
tized stakeholder.
In the case where there is no common MCSs
(hasCommon(Result list)= False), the function
(Get Priority Based) is applied on the initial set of
resulting MCSs (Result_list) to select a MCS
that better respects the configuration decisions of the
prioritized stakeholder.
ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering
Algorithm 1: Conflict Resolution Algorithm.
S rules: list of rules selected by stakeholders.
MCS list: list of computed MCSs.
R MCS: conflict resolution’s MCS.
for each (Rule S rules) do
Result apply(Rule, MCS list)
Result list Result list Result
end for
if (hasCommon(Result list) == True ) then
Com list ComputeCommonList(Result list)
if ( Size(Com List) == 1 ) then
R MCS Com list
else if (Size(Com list) > 1 ) then
R MCS Get Priority Based(Com list)
end if
R MCS Get Priority Based(Result list)
end if
Return(R MCS)
In the previous section, we introduced our collabora-
tive configuration approach. In this section, we de-
scribe a simple example that illustrates the proposed
approach namely how conflicts can be resolved dur-
ing product line collaborative configuration using our
algorithm. This example involves the configuration of
a website product line (Figure 2) based on an adapted
version of the website feature model proposed by
(Mendonca et al., 2008). We pick one configuration
scenario from this domain which is described in Table
3. Considering that three stakeholders are sharing the
configuration of the website model. First, a priority
order is assigned to the different stakeholders. After-
ward, each stakeholder selected the desired substitu-
tion rules, stakeholder one (Sh1) chose SR2 represent-
ing the simplest product, stakeholder two (Sh2) didn’t
choose any rule, stakeholder three (Sh3) chose SR5
that permits prioritizing his/her explicit decisions.
In the next step, stakeholders start configuring the
desired web site. Therefore, each stakeholder express
his configuration decisions by specifying the list of
desired features and the list of undesired features.
The consistency of each partial configuration is en-
sured by the automatic propagation of constraints. For
example, when (Sh1) selected the feature ”Https”, the
feature ”Ms” is automatically discarded because of
the constraint exclude between these two features as
depicted in Figure 2.
As illustrated in last row of Table 3, in addition
to the mandatory features (Webserver, Content and
Static), the total configuration encompasses all the
partial configuration made by stakeholders.
Afterward, the total configuration consistency is
checked against the feature model dependency con-
straints depicted in Figure 2.
After the verification of the obtained configura-
tion, three conflicting situations detected are respec-
tively presented in Table 4. The first conflict occurs
because ”Https” excludes ”Ms” where Sh1 explicitly
selected ”Https” ({Https}) and implicitly (through
constraint) discarded ”Ms” ( Ms}) and Sh3 ex-
plicitly selected ”Ms” ({Ms})and implicitly discarded
”Https” ( Https}). The same for the second and
third conflict where ”XML” and ”Ms” are respec-
tively alternative features (XOR) with ”Database” and
To resolve these conflicts, MCSs are computed.
The whole list is presented in Table 5 which repre-
sents all the possible combinations of conflicting con-
figuration decisions whose removal resolves all the
detected conflicts.
The rules selected by stakeholders are then ap-
plied on the MCSs list to decide which MCS to
choose. As presented in Table 6, (Sh1) chose SR2-
simplest product which corresponds to MCS that
eliminates the maximum of features i.e {Https, Ms,
XML, Database, Sec }. (Sh3) chose SR5 which
prioritizes his explicit choices which are ”Ms” and
”Database”. Therefore, the MCS that respects these
choices is the one who keeps these two features which
is: {Https, ¬ Ms, XML, ¬ Database, Sec} .
The obtained results are different, according to the
proposed algorithm, the resolution MCS is selected
based on the priority order assigned to stakeholders.
As shown in Table 3, (Sh3) is the prioritized stake-
holder, therefore, {Https, ¬ Ms, XML, ¬ Database,
Sec} is selected as the resolution MCS and the con-
figuration decisions contained in this MCS are then
removed from the current configuration.
Here, stakeholders are aware of the MCS that has
been selected to resolve conflicts and could be satis-
fied in the sense that the resolution relies on the sub-
stitution rules they selected whatever the eliminated
configuration decisions.
To evalute the feasibility of the proposed ap-
proach, a tool called Colla-Config tool is imple-
mented using micro-service based web application ar-
chitecture where the front end is implemented using
Vue.js framework and the backend in java.
The tool offers two different user access. (1) for
stakeholders where they can select the desired subsi-
Preference-based Conflict Resolution for Collaborative Configuration of Product Lines
Figure 2: Web Portal Feature Model.
Table 3: Configuration Scenario.
Stakeholder Priority Selected Configuration decisions
order rule
Sh1 2 SR2 ¬Active, Protocols, Https, ¬Ms
Sh2 3 None ¬Active,Persistence, XML,¬Database, Performance, Sec,¬Ms , ¬Min
Sh3 1 SR5 ¬Active,Persistence, Database, ¬XML, Performance, Ms, ¬Sec , ¬Min, ¬Htt ps
Total configuration WebServer Content Static ∧¬Active Security Datatransfer Protocols
Https ¬Htt ps ¬Ms Persistence XML ∧¬Database Performance
Sec ∧¬Min Database ∧¬X ML Ms ∧¬Sec
Table 4: Detected Conflicts.
Violated Constraint Detected Conflict
1) Https VS Ms {Https, ¬Htt ps}
{Ms, ¬Ms}
2) XML VS Database {XML,¬XML }
{Database, ¬Database}
3) Ms VS Sec {Ms, ¬Ms}
{Sec, ¬Sec}
tution rules and make configuration decisions as de-
picted in Figure 3. (2) for product manager where
he handles participating stakeholders (see Figure 4)
through assigning priority order, checking the consis-
tency of the total configuration, running the conflict
resolution and delivery of the final validation config-
uration to stakeholders as depicted in Figure 5.
The example presented above was run under the
implemented tool where computing MCSs and selec-
tion of resolution MCS costs 3659ms. This initial
experiment was undertaken in the following environ-
ment: Laptop with MacOS MOjave Ultimate of 64
bits, processor Intel Core i7, CPU 2.2 GHz, and RAM
memory of 8,00 GB.
According to a recent Systematic Mapping Study car-
ried by (Edded et al., 2019), 41 primary studies ad-
Figure 3: Stakeholders Configuration Interface.
dress the collaborative configuration of product lines.
Collaborative configuration approaches proposed by
these studies can be categorized as follows:
Approaches Relying on Predefined Process. also
called workflow-based. In these approaches, configu-
ration activities are coordinated and assigned to stake-
holders where each of them is in charge of configuring
a specific module of the feature model. Some of these
ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering
Table 5: List of Computed MCSs.
{Https, Ms, XML, Database, Sec},{Https, Ms, XML, Database, ¬Sec}, {Https, Ms, XML, ¬Database, Sec}
{Https, Ms, XML, ¬Database, ¬Sec}, {Https, Ms, ¬XML , Database, Sec}, {Https, Ms, ¬XML, Database, ¬Sec}
{Https, ¬Ms, XML, Database, Sec}, {Https, ¬Ms, XML,¬Database, Sec}, {Https, ¬Ms, ¬X ML, Database, Sec}
Htt ps, Ms, XML, Database, Sec}, Htt ps, Ms, XML, Database, ¬Sec}, Htt ps, Ms, XML, ¬Database, Sec}
Htt ps, Ms, XML, ¬Database, ¬Sec}, Htt ps, Ms, ¬XML, Database, Sec}, Htt ps, Ms, ¬XML, Database, ¬Sec}
Table 6: Substitution Rules Application.
Stakeholder Rule Result Common MCS
Sh1 SR2 {Https, Ms, XML, Database, Sec }
Sh2 None - No
Sh3 SR5 {Https, ¬ Ms, XML, ¬ Database, Sec}
Figure 4: Product Manager Interface Part 1.
Figure 5: Product Manager Interface Part 2.
approaches, systematically resolve conflicts by prior-
itizing configuration decisions made at earlier stage
such as the approaches proposed by (Czarnecki et al.,
2005) and (Mendonca et al., 2008) where configura-
tion decisions of some stakeholders govern the selec-
tion of other stakeholders and influence which fea-
tures are still available. These approaches proposed
also negotiation session as resolution method when
the conflicting decisions are shared between many
Some other approaches such as the one proposed
by (Mendonca et al., 2007) anticipates conflicts and
identify two basic priority schemes: role-based and
decision-set-based. In the first scheme, decision pri-
ority is given to the highest ranked decision role. In
the second one, priorities are given to decision sets
based on the importance of their contained features
to the process. Moreover, we find other collabora-
tive configuration approaches such as (Rabiser et al.,
2009), (Hubaux et al., 2010) and (Xiong et al., 2012)
who resolve conflicts by directly suggesting to stake-
holders a set of correction values called Range Fixes.
Approaches Relying on Free Order Process. In this
category of approaches, stakeholders freely express
their configuration decisions without imposing a se-
lection order on them. Few of these approaches pro-
vide information about conflict management such as
the approach proposed by (Junior et al., 2011) where
personal assistance provided by software agents pro-
pose a conflict resolution plans and the stakeholders
are free to accept anyone of the offered suggestions.
(J.Stein et al., 2014) also proposed a free order config-
uration approach where conflicts are resolved based
on stakeholders preferences expressed through hard
and soft constraints. The conflict resolution scenario
consists in relaxing conflicting hard constraint to a
soft one and deciding about the maintained decision
through the higher expressed preference degree.
We also find the approach proposed by (Ochoa
et al., 2015) that uses language-based criteria to find
a non-conflicting set of solution configurations that
are aligned to stakeholders preferences expressed in
terms of non-functional properties.
However, many other approaches their main fo-
cus is on the configuration process and do not pro-
vide any information about conflict resolution process
such as approaches proposed by (R.Dou et al., 2016)
and (Pereira et al., 2018).
Our approach offers flexible configuration process
where stakeholders freely express their choices. To
the best of our knowledge, our approach is the first
to allow expressing undesired features unlike exist-
ing approaches which only consider decisions about
desired features. Moreover, our approach is one of
the rare approaches which provide explicit informa-
tion about conflict and its possible types. We believe
the approach represents a considerable improvement
Preference-based Conflict Resolution for Collaborative Configuration of Product Lines
over current conflict resolution policies by proposing
a full preference-based solution .
Current research carried in the field showed that
the most of existing collaborative configuration ap-
proaches rely on a pre-designed processes where ac-
tivities of some stakeholders would have side effects
on those performed by other stakeholders.
The resulting lack of flexibility is likely to be
a limitation when resolving conflicts as the adopted
resolution strategies do not consider the preferences
of stakleholders thus do not ensure their satisfaction.
Therefore, we presented in this paper a novel ap-
proach of collaborative configuration capable of re-
solving conflicts according to preferences of stake-
The experiments carried on were made to evalu-
ate the feasibilty of the approach. We consider that
in the future several controlled experiments must be
conducted to assert the usefulness of this work.
This work was financially supported by the REVAMP
EOTP R5L220003801 project.
Bailey, J. and Stuckey, P. J. (2005). Discovery of mini-
mal unsatisfiable subsets of constraints using hitting
set dualization. In Proceedings of the 7th Interna-
tional Conference on Practical Aspects of Declarative
Languages, PADL’05, pages 174–186, Berlin, Heidel-
berg. Springer-Verlag.
Batory, D., Benavides, D., and Ruiz-Cortes, A. (2006). Au-
tomated analysis of feature models: Challenges ahead.
Commun. ACM, 49(12):45–47.
Clements, P. and Northrop, L. (2001). Software Product
Lines: Practices and Patterns. Longman Publishing.
Czarnecki, K., Helsen, S., and Eisenecker, U. W. (2005).
Staged configuration through specialization and mul-
tilevel configuration of feature models. In Software
Process: Improvement and Practice.
Edded, S., BenSassi, S., Mazo, R., Salinesi, C., and
BenGhezala, H. (2019). Collaborative configuration
approaches in software product lines engineering: A
systematic mapping study. Journal of Systems and
Software, 158:110422.
Hubaux, A., Heymans, P., Schobbens, P.-Y., and Deridder,
D. (2010). Towards multi-view feature-based con-
figuration. In Proceedings of the 16th International
Working Conference on Requirements Engineer-
ing:Foundation for Software Quality (REFSQ’10),
pages 106–112, Essen, Germany. Springer-Verlag.
J.Stein, I.Nunes, and E.Cirilo (2014). Preference-based fea-
ture model configuration with multiple stakeholders.
In 18th International Software Product Line Confer-
ence, pages 132–141, New York, NY, USA. ACM.
Junior, C. R. M., Cirilo, E. J., and de Lucena, C. J. (2011).
Assisted user-guidance in collaborative and dynamic
software product line configuration. In Proceedings
of the 14th Ibero-American Conference on Software
Engineering, pages 143–156.
Liffiton, M. H. and Sakallah, K. A. (2008). Algorithms
for computing minimal unsatisfiable subsets of con-
straints. J. Autom. Reason., 40(1):1–33.
Marques-Silva, J., Heras, F., Janota, M., Previti, A., and
Belov, A. (2013). On computing minimal correction
subsets. In Proceedings of the Twenty-Third Interna-
tional Joint Conference on Artificial Intelligence, IJ-
CAI ’13, pages 615–622. AAAI Press.
Mendonca, M., Bartolomei, T., and Cowan, D. (2008).
Decision-making coordination in collaborative prod-
uct configuration. In ACM symposium on applied
computing, pages 108–113, New York, NY, USA.
Mendonca, M., Cowan, D., and Oliveira, T. (2007).
Process-centric approach for coordinating product
configuration decisions. In Proceedings of the 40th
Hawaii International Conference on System Sciences
(HICSS’07), pages 1–10, Washington, DC, USA.
IEEE Computer Society.
Ochoa, L., Gonz
A¡lez-Rojas, O., and Th
AŒm, T. (2015).
Using decision rules for solving conflicts in extended
feature models. In Software Language Engineering,
the 2015 ACM SIGPLAN International Conference,
pages 149–160, New York, NY, USA. ACM.
Osman, A., Somnuk, E., Phon-Amnuaisuk, and Ho, C. K.
(2009). Investigating Inconsistency Detection as a
Validation Operation in Software Product Line, pages
159–168. Springer Berlin Heidelberg, Berlin, Heidel-
Pereira, J. A., P.Matuszyk, S.Krieter, M.Spiliopoulou, and
G.Saake (2018). Personalized recommender systems
for product-line configuration processes. Computer
Languages, Systems & Structures, 54:451–471.
Rabiser, R., Wolfinger, R., and Grunbacher, P. (2009).
Three-level customization of software products us-
ing a product line approach. In Proceedings of the
42nd IEEE Annual Hawaii International Conference
on System Sciences, pages 1–10.
R.Dou, Y.Zhang, and G.Nan (2016). Customer-oriented
product collaborative customization based on design
iteration for tablet personal computer configuration.
Computers & Industrial Engineering, 99:474–486.
Xiong, Y., Hubaux, A., She, S., and Czarnecki, K. (2012).
Generating range fixes for software configuration.
In Proceedings of the 34th International Conference
on Software Engineering (ICSE’12), pages 58–68,
Zurich, Switzerland. IEEE Computer Society.
ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering