Preference-based Conﬂict Resolution for Collaborative Conﬁguration of

Product Lines

Sabrine Edded

1,2

, Sihem Ben Sassi

2,3

, Raul Mazo

1,4

, 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

Keywords:

Product Lines, Collaborative Conﬁguration, Conﬂict Resolution, Minimal Correction Subsets.

Abstract:

In the context of Product lines, the collaborative conﬁguration process gets complicated when the conﬁgura-

tion decisions of involved stakeholders are contradictory, which may lead to conﬂicting situations. Although

considerable research has been devoted to collaborative conﬁguration, little attention has been paid to conﬂict

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 conﬁguration approach which allows

conﬂict resolution based on stakeholders preferences expressed through a set of substitution rules. Based on

such preferences, we delete the minimal set of conﬂicting conﬁguration decisions which are identiﬁed using

the Minimal Correction Subsets (MCSs) computing algorithm. An illustrating example and a tool prototype

are presented to evaluate the applicability of our approach.

1 INTRODUCTION

The conﬁguration 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 conﬁgurations can be created. On

industrial scale product line models, it cannot be ex-

pected that conﬁguration activities are handled by sin-

gle user solely responsible of all conﬁguration 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 conﬁg-

uration decisions between stakeholders is highly de-

sirable in order to cope with the issues of the conﬁg-

uration process which is referred to as collaborative

conﬁguration process.

Real life product lines models can contain up to

10,000 features (Batory et al., 2006). In such a case,

the conﬁguration becomes an arduous and error prone

task. Ensuring compromise between all stakehold-

ers conﬁguration decisions during conﬂict resolution

presents a critical issue. Potentially, the more there

are constraints, the higher the effort is to resolve con-

ﬂicts. Moreover, resolving such situations can not be

considered effective if it does not take into account

the conﬁguration decisions of stakeholders.

To cope with conﬂict 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 conﬁguration principle where con-

ﬁguration decisions are reﬁned on multiple steps by

different stakeholders and arranged by a workﬂow.

The workﬂow approach has a signiﬁcant disadvan-

tage; namely the conﬁguration process lacks ﬂexibil-

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

beforehand.

The resulting lack of ﬂexibility is likely to be

a limitation when resolving conﬂicts as the adopted

conﬂict resolution strategy will not ensure the satis-

faction of all stakeholders and consider their prefer-

ences.

We thus in this paper, propose a new product line

collaborative conﬁguration approach to improve the

Edded, S., Ben Sassi, S., Mazo, R., Salinesi, C. and Ben Ghezala, H.

Preference-based Conﬂict Resolution for Collaborative Conﬁguration 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

297

conﬂict resolution process, by allowing stakeholders

to express preferences through a set of subsitution

rules and then deleting the minimal set of conﬂict-

ing conﬁguration decisions according to these pref-

erences. Major collaborative conﬁguration issues are

discussed such as the lack of conﬁguration process

ﬂexibility and the systematic strategy of conﬂict 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 conﬁguration

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.

2 PRELIMINARIES

To understand our approach, the knowledge about

conﬂict within collaborative conﬁguration of product

lines and Minimal Correction Subsets (MCSs) is im-

portant. They are brieﬂy discussed in this section.

2.1 Conﬂict Deﬁnition

In the context of product line collaborative conﬁgu-

ration, conﬂict management is of paramount impor-

tance. According to (Mendonca et al., 2007), conﬂict

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

conﬂict occurs when two or more conﬁguration deci-

sions assigned to different stakeholders cannot be true

at the same time.

Formally a conﬂict can be deﬁned as follows:

Deﬁnition. For a conﬁguration Co composed of a set

of conﬁguration decisions {Cd

}, a subset Cﬂt ⊆ Co

is a conﬂict, if Co is unsatisﬁable and ∀ Cd

∈ Cﬂt,

Co\{Cd

} is satisﬁable.

2.2 Conﬂict Types

Conﬂicts can be categorized into two different types

as illustrated in Table 1.

• Explicit Conﬂict: represents the case where the

conﬁguration 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 Conﬂict: represents the case where the

conﬁguration decisions of different stakeholders

Table 1: Conﬂict Types in Collaborative Conﬁguration.

Conﬂict type Illustration

Explicit

A A

Stakeholder 1

Stakeholder 2

Implicit

Stakeholder 2

A B

Requires

Stakeholder 1

Implicit

A B

Excludes

Stakeholder 1 Stakeholder 2

Implicit

XOR

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: conﬂict occurs when a feature A

selected by a stakeholder 1 requires a feature B

which undesirable by stakeholder 2.

– Situation 2: conﬂict occurs when a feature A

excludes feature B and both are selected by two

stakeholders

– Situation 3: conﬂict 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-

ﬂicting conﬁguration decisions to be deleted.

According to (Lifﬁton and Sakallah, 2008), a MCS

is an irreducible subset of constraints whose removal

makes satisﬁable a constraint program.

Formally an MCS can be deﬁned as follows:

Deﬁnition. A subset of constraints M ⊆ C is a MCS,

if C\M is satisﬁable and ∀ C

∈ M,C\(M\{C

}) is un-

satisﬁable.

Computing MCSs has been the subject of several

research works in the ﬁelds of Boolean satisﬁabil-

ity and constraint satisfaction problems. The goal is

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

298

to ﬁnd minimal sets of clauses whose removal ren-

ders given unsatisﬁable Conjunctive Normal Formula

(CNF) satisﬁable.

Different approaches have been proposed over the

years for computing MCSs such as those proposed by

(Bailey and Stuckey, 2005), (Lifﬁton 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 satisﬁability of different sub-

formulas. Generally, these algorithms handle a triplet

{S, U, C} of F, where S is a satisﬁable 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 ﬁrst call, the solver computes

a complete assignment µ satisfying F

in order to

initialize S (resp. U) containing the satisﬁed clauses

(resp. unsatisﬁed) 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 (Lifﬁton and Sakallah, 2008), represents

the most widely adopted approach for computing

MCSs that consists of ﬁnding an assignment that sat-

isﬁes the maximum number of clauses of an unsatisﬁ-

able formula (Marques-Silva et al., 2013). Therefore,

ﬁnding MCSs is related to the MaxSAT (or MaxCSP)

problem, which consists in ﬁnding a minimal subset

of assignment satisfying the different clauses of un-

satisﬁable CNF. This represents an optimal solution

to MaxSAT.

In this paper, we will make use of (Lifﬁton and

Sakallah, 2008) approach to compute MCSs for con-

ﬂict resolution within collaborative conﬁguration of

Product lines.

3 PROPOSED APPROACH

To cope with collaborative conﬁguration issues, we

propose a new conﬁguration approach where stake-

holders freely express their conﬁguration decisions

and conﬂicts 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 conﬁguration, (3) conﬁguration veriﬁcation and

(4) conﬂict 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 conﬁguration decisions could not be re-

tained in case of conﬂict.

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

stakeholders.

• SR3. Product Similar to a Past Conﬁguration:

previous conﬁguration that contains the same fea-

tures selected by the current stakeholder.

• SR4. Product Conﬁgured by a Similar Pro-

ﬁle: two proﬁles are similar when two stakehold-

ers share the same concern (engineers, project

managers, managers, marketing, sales, customers,

users, etc.). Therefore, the conﬁguration deci-

sions made by the current stakeholder will be

aligned with those made by the stakeholder with

the same proﬁle.

• SR5. Prioritize my Explicit Decisions: consid-

ering conﬁguration decisions explicitly expressed

through feature selection.

During the ﬁrst step of the proposed approach, each

stakeholder selects the set of desired substitution

rules. Each rule refers to the removal of a speciﬁc

MCS as presented in Table 2. In the context of the

proposed approach, a MCS represents the set of con-

ﬁguration decisions whose removal makes satisﬁable

the current conﬁguration.

In case of conﬂict, 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 Conﬂict Resolution for Collaborative Conﬁguration of Product Lines

299

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 conﬁguration MCS that respects features present in a similar past conﬁguration

SR4 product conﬁgured by a similar proﬁle MCS that respects conﬁguration decisions of similar proﬁle

SR5 prioritize my explicit decisions MCS that respects explicit conﬁguration decisions of the stakeholder

3.2 Collaborative Conﬁguration

During the conﬁguration process, the different stake-

holders freely express their conﬁguration decisions

towards the desired product without being constrained

to the conﬁguration decisions made by the other

stakeholders.

In the context of the proposed approach, a con-

ﬁguration decision permits stakeholders to explicitly

express both, the list of desired features and the list of

undesired features. Formally a conﬁguration decision

(Cd) can be deﬁned 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 ﬁnal conﬁguration encompasses all the

mandatory features that any derived product should

contain and all the partial conﬁgurations made by the

different stakeholders.

Formally a partial conﬁguration of a given feature

model (fm) can be deﬁned 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 conﬁguration is ensured

through an automatic propagation of constraints.

The ﬁnal conﬁguration, can be formally deﬁned as

follows: Cf

tot

= hfm, {Sh c f }i, where {Sh c f } repre-

sents the set of all the partial conﬁgurations.

3.3 Conﬁguration Veriﬁcation

During the veriﬁcation step, the partial conﬁgurations

of all stakeholders are merged and checked against the

list of conﬂict types described in Section 2.

The conﬁguration veriﬁcation is ensured by a SAT

solver. Therefore, the conﬁguration is formulated as

CNF where each conﬁguration decision is represented

as single clause. In case of conﬂict detection, the

MAXSAT algorithm of (Lifﬁton and Sakallah, 2008)

is used to compute the list of all the possible MCSs

for a given unsatisﬁable conﬁguration.

Considering the set of substitution rules selected

by stakeholders, the MCS that better meets these rules

is then chosen to resolve the detected conﬂict(s).

3.4 Conﬂict Resolution

To resolve conﬂicts, we propose an algorithm that per-

mits identifying the resolution MCS that better sat-

isﬁes stakeholders preferences expressed through se-

lected substitution rules.

We have chosen to compute MCSs as they permit

ﬁnding minimal sets of conﬂicting conﬁguration de-

cisions whose removal renders the conﬁguration sat-

isﬁable. 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 conﬂict res-

olution (R_MCS) according to the set of substitution

rules selected by stakeholders.

The algorithm applies at ﬁrst 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 conﬁguration 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 conﬁguration decisions of the

prioritized stakeholder.

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

300

Algorithm 1: Conﬂict Resolution Algorithm.

Require:

S rules: list of rules selected by stakeholders.

MCS list: list of computed MCSs.

Ensure:

R MCS: conﬂict 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

else

R MCS ← Get Priority Based(Result list)

end if

Return(R MCS)

4 ILLUSTRATIVE EXAMPLE

In the previous section, we introduced our collabora-

tive conﬁguration approach. In this section, we de-

scribe a simple example that illustrates the proposed

approach namely how conﬂicts can be resolved dur-

ing product line collaborative conﬁguration using our

algorithm. This example involves the conﬁguration 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 conﬁguration

scenario from this domain which is described in Table

3. Considering that three stakeholders are sharing the

conﬁguration 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 conﬁguring the

desired web site. Therefore, each stakeholder express

his conﬁguration decisions by specifying the list of

desired features and the list of undesired features.

The consistency of each partial conﬁguration 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 conﬁguration encompasses all the

partial conﬁguration made by stakeholders.

Afterward, the total conﬁguration consistency is

checked against the feature model dependency con-

straints depicted in Figure 2.

After the veriﬁcation of the obtained conﬁgura-

tion, three conﬂicting situations detected are respec-

tively presented in Table 4. The ﬁrst conﬂict 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 conﬂict where ”XML” and ”Ms” are respec-

tively alternative features (XOR) with ”Database” and

”Sec”.

To resolve these conﬂicts, MCSs are computed.

The whole list is presented in Table 5 which repre-

sents all the possible combinations of conﬂicting con-

ﬁguration decisions whose removal resolves all the

detected conﬂicts.

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-

ﬁguration decisions contained in this MCS are then

removed from the current conﬁguration.

Here, stakeholders are aware of the MCS that has

been selected to resolve conﬂicts and could be satis-

ﬁed in the sense that the resolution relies on the sub-

stitution rules they selected whatever the eliminated

conﬁguration decisions.

To evalute the feasibility of the proposed ap-

proach, a tool called Colla-Conﬁg 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 Conﬂict Resolution for Collaborative Conﬁguration of Product Lines

301

Figure 2: Web Portal Feature Model.

Table 3: Conﬁguration Scenario.

Stakeholder Priority Selected Conﬁguration 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 conﬁguration 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 Conﬂicts.

Violated Constraint Detected Conﬂict

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 conﬁguration 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 conﬁguration, running the conﬂict

resolution and delivery of the ﬁnal validation conﬁg-

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.

5 RELATED WORK

According to a recent Systematic Mapping Study car-

ried by (Edded et al., 2019), 41 primary studies ad-

Figure 3: Stakeholders Conﬁguration Interface.

dress the collaborative conﬁguration of product lines.

Collaborative conﬁguration approaches proposed by

these studies can be categorized as follows:

Approaches Relying on Predeﬁned Process. also

called workﬂow-based. In these approaches, conﬁgu-

ration activities are coordinated and assigned to stake-

holders where each of them is in charge of conﬁguring

a speciﬁc module of the feature model. Some of these

ENASE 2020 - 15th International Conference on Evaluation of Novel Approaches to Software Engineering

302

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 conﬂicts by prior-

itizing conﬁguration decisions made at earlier stage

such as the approaches proposed by (Czarnecki et al.,

2005) and (Mendonca et al., 2008) where conﬁgura-

tion decisions of some stakeholders govern the selec-

tion of other stakeholders and inﬂuence which fea-

tures are still available. These approaches proposed

also negotiation session as resolution method when

the conﬂicting decisions are shared between many

stakeholders.

Some other approaches such as the one proposed

by (Mendonca et al., 2007) anticipates conﬂicts and

identify two basic priority schemes: role-based and

decision-set-based. In the ﬁrst 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 ﬁnd other collabora-

tive conﬁguration approaches such as (Rabiser et al.,

2009), (Hubaux et al., 2010) and (Xiong et al., 2012)

who resolve conﬂicts 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 conﬁguration decisions without imposing a se-

lection order on them. Few of these approaches pro-

vide information about conﬂict management such as

the approach proposed by (Junior et al., 2011) where

personal assistance provided by software agents pro-

pose a conﬂict resolution plans and the stakeholders

are free to accept anyone of the offered suggestions.

(J.Stein et al., 2014) also proposed a free order conﬁg-

uration approach where conﬂicts are resolved based

on stakeholders preferences expressed through hard

and soft constraints. The conﬂict resolution scenario

consists in relaxing conﬂicting hard constraint to a

soft one and deciding about the maintained decision

through the higher expressed preference degree.

We also ﬁnd the approach proposed by (Ochoa

et al., 2015) that uses language-based criteria to ﬁnd

a non-conﬂicting set of solution conﬁgurations that

are aligned to stakeholders preferences expressed in

terms of non-functional properties.

However, many other approaches their main fo-

cus is on the conﬁguration process and do not pro-

vide any information about conﬂict resolution process

such as approaches proposed by (R.Dou et al., 2016)

and (Pereira et al., 2018).

Our approach offers ﬂexible conﬁguration process

where stakeholders freely express their choices. To

the best of our knowledge, our approach is the ﬁrst

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 conﬂict and its possible types. We believe

the approach represents a considerable improvement

Preference-based Conﬂict Resolution for Collaborative Conﬁguration of Product Lines

303

over current conﬂict resolution policies by proposing

a full preference-based solution .

6 CONCLUSION

Current research carried in the ﬁeld showed that

the most of existing collaborative conﬁguration 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 ﬂexibility is likely to be

a limitation when resolving conﬂicts 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 conﬁguration capable of re-

solving conﬂicts according to preferences of stake-

holders.

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.

ACKNOWLEDGMENTS

This work was ﬁnancially supported by the REVAMP

EOTP R5L220003801 project.

REFERENCES

Bailey, J. and Stuckey, P. J. (2005). Discovery of mini-

mal unsatisﬁable 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 conﬁguration through specialization and mul-

tilevel conﬁguration of feature models. In Software

Process: Improvement and Practice.

Edded, S., BenSassi, S., Mazo, R., Salinesi, C., and

BenGhezala, H. (2019). Collaborative conﬁguration

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-

ﬁguration. 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 conﬁguration 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 conﬁguration. In Proceedings

of the 14th Ibero-American Conference on Software

Engineering, pages 143–156.

Lifﬁton, M. H. and Sakallah, K. A. (2008). Algorithms

for computing minimal unsatisﬁable 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 Artiﬁcial Intelligence, IJ-

CAI ’13, pages 615–622. AAAI Press.

Mendonca, M., Bartolomei, T., and Cowan, D. (2008).

Decision-making coordination in collaborative prod-

uct conﬁguration. In ACM symposium on applied

computing, pages 108–113, New York, NY, USA.

ACM.

Mendonca, M., Cowan, D., and Oliveira, T. (2007).

Process-centric approach for coordinating product

conﬁguration 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 conﬂicts 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-

berg.

Pereira, J. A., P.Matuszyk, S.Krieter, M.Spiliopoulou, and

G.Saake (2018). Personalized recommender systems

for product-line conﬁguration processes. Computer

Languages, Systems & Structures, 54:451–471.

Rabiser, R., Wolﬁnger, 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 conﬁguration.

Computers & Industrial Engineering, 99:474–486.

Xiong, Y., Hubaux, A., She, S., and Czarnecki, K. (2012).

Generating range ﬁxes for software conﬁguration.

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

304