IRatePL2C: Importance Rating-Based Approach for Product Lines

Collaborative Conﬁguration

Sihem Ben Sassi

RIADI Lab., National School of Computer Science, Manouba University, Tunisia

Keywords:

Product Lines, Collaborative Conﬁguration, Conﬂict Resolution, Feature, Importance Scoring.

Abstract:

The core of any proposed approach in the context of collaborative conﬁguration of product lines focuses

on how conﬂictual situations are resolved. Few works consider stakeholders preferences in their resolution

strategy while allowing a free order conﬁguration process. However, to generate a valid solution satisfying

all constraints, they generally rely on a solution of exponential complexity. In this work, we propose the

IRatePL2C approach, which resolution strategy relies on importance degrees assigned by the stakeholders to

their initial conﬁguration choices. IRatePL2C starts by merging stakeholders’ conﬁgurations and then detect-

ing and resolving the conﬂicts according to their type: explicit or implicit in sequential steps. Finally, domain

constraints are propagated and the process is reiterated to reach a ﬁnal valid conﬁguration. An illustrative ex-

ample is presented to evaluate the approach. The complexity of IRatePL2C is polynomial which an important

advantage compared with previous works.

1 INTRODUCTION

Collaborative conﬁguration of product lines refers to

a coordinated process in which a set of stakehold-

ers share the conﬁguration activities based on their

areas of expertise in order to decide about features

that should be included in the ﬁnal product (Edded

et al., 2019). It has appealed the interest of several

researchers, such as (Czarnecki et al., 2005), (Men-

donca et al., 2007), (Pereira, 2017), (Edded et al.,

2020), (Le et al., 2022) and (Ben Sassi et al., 2023).

The mainspring of the proposed approaches is to man-

age conﬂictual situations that may arise when in-

volved stakeholders in the conﬁguration have con-

tradictory choices regarding the ﬁnal product. The

prevailing means to represent product lines is fea-

ture model (Raatikainen et al., 2019), in which fea-

tures are related with mandatory, optional, alternative

(XOR) and OR relationships; and domain constraints

are expressed through inclusion (require) and exclu-

sion (exclude) relationships (Benavides et al., 2010).

Product conﬁguration consists in selecting a set of

features that meet individual requirements toward the

desired product. When the conﬁguration is made by

a single stakeholder, it is easy to ensure its confor-

mance to the product line model with its domain con-

https://orcid.org/0000-0002-1925-4989

straints, thanks to constraints propagation (Czarnecki

and Kim, 2005). However, when several stakeholders

are involved in this process, their requirements may

be contradictory or do not comply with the product

model; such situations of inconsistency are referred

to as conﬂicts (Osman et al., 2009). In this context,

stakeholders requirements are better captured by al-

lowing them to choose the undesired features (¬F

)

that should not be present in the ﬁnal product as well

as the desired ones (F

) (Stein et al., 2014), (Le et al.,

2022), (Ben Sassi et al., 2023). According to (Ed-

ded et al., 2020), a conﬂict may be (i) explicit when

the same feature is explicitly desired by a stakeholder

and undesired by another; (ii) implicit when conﬁgu-

ration choices of the stakeholders violate the product

line feature model constraints. Two cases are distin-

guishable: (ii-1) two alternative features (related with

XOR) are desired by different stakeholders; and (ii-2)

domain constraint propagation makes the conﬁgura-

tion not valid because it requires to include/exclude

a feature that is already un/desired by another stake-

holder.

Obtaining a valid conﬁguration from the differ-

ent stakeholders’ conﬁguration choices requires to re-

solve any detected conﬂict by eliminating one or more

conﬁguration choices involved in the conﬂict. Exist-

ing approaches tackle this issue by (1) supporting ei-

ther workﬂow-based process imposing a predeﬁned

784

Ben Sassi, S.

IRatePL2C: Importance Rating-Based Approach for Product Lines Collaborative Conﬁguration.

DOI: 10.5220/0012742900003687

Paper published under CC license (CC BY-NC-ND 4.0)

In Proceedings of the 19th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2024), pages 784-791

ISBN: 978-989-758-696-5; ISSN: 2184-4895

conﬁguration order, or a ﬂexible one allowing a free

order conﬁguration; and (2) implementing a conﬂict

resolution method adopted from social science like

negotiation and predeﬁned priority, or more technical

one such as range ﬁxes. The reader may refer to (Ed-

ded et al., 2019) for a comprehensive view character-

izing collaborative conﬁguration approaches. Actu-

ally, few works propose a ﬂexible conﬁguration pro-

cess that takes into account stakeholders preferences

in conﬂict resolution, namely (Stein et al., 2014),

(Ochoa et al., 2015), (Le et al., 2022) and (Ben Sassi

et al., 2023). However, either they do not generate

a solution that takes into account the preferences of

all stakeholders, and/or they implement an expensive

computation process.

The remainder of this paper is structured as fol-

lows: Section 2 is dedicated to the proposed approach.

Section 3 illustrates IRatePL2C with a full example.

Section 4 discusses the solution. Section 5 concludes

the paper.

2 THE IRatePL2C APPROACH

The proposed IRatePL2C approach is based on the

following principles and hypotheses: H1: each stake-

holder freely conﬁgures the product line; there is

no predeﬁned order between stakeholders during the

conﬁguration process. H2: each stakeholder makes

a conﬁguration decision by specifying the un/desired

features to be absent/present in the product. H3: a

prior agreement between stakeholders to express to

which extent they desire a conﬁguration choice i.e.

a (un)desired feature (not) to be included in the ﬁ-

nal conﬁguration. H4: each stakeholder assigns an

importance degree (ideg) to each of his/her explicit

conﬁguration choices. H5: a ﬁve scale-based score is

used to express the conﬁguration choice ideg, 5 means

that the choice is very important to be considered in

the ﬁnal conﬁguration; 4: fairly important; 3: impor-

tant; 2: slightly important; and 1: not at all impor-

tant. H6: idegs are only assigned to the explicit ini-

tial choices made by the stakeholder. In other words,

features that should be included in the conﬁguration

because of the constraints propagation to ensure its

validity do not receive scores. H7: each stakeholder

is aware that potential conﬂicting choices will be re-

solved based on the idegs, and assigns consciously

scores to the conﬁguration choices he/she makes.

Figure 1 shows the main steps of IRatePL2C ap-

proach: it starts by (1) merging the initial conﬁgura-

tion choices made by each stakeholder. Second (2),

the merged conﬁguration is analyzed to identify ex-

plicit conﬂicts; these latter are resolved and the con-

ﬁguration is accordingly updated. Third (3), the new

conﬁguration is analyzed to identify and resolve im-

plicit conﬂicts resulted from XOR constraints; the

conﬁguration is updated accordingly. Fourth (4), the

product line domain constraints are checked to propa-

gate them on the conﬁguration when applicable. The

conﬁguration is afterward checked. If it is valid, it

will be returned as ﬁnal conﬁguration. When the con-

ﬁguration is not valid, it is question to compare it with

the one of the previous iteration in order to decide to

reiterate the process starting from Step -2- in the case

the two conﬁgurations are different, or hand over to

the product line manager in order to apply the rule

he/she advocates to resolve remaining conﬂicts. This

rule may be for example one of the substitution rules

proposed in (Edded et al., 2020) and (Ben Sassi et al.,

2023), that resolves conﬂicts, among others, by favor-

ing ”the most complete product“, or by prioritizing

”the explicit choices made by a given stakeholder“.

Algorithm 1 summarizes the core process of

IRatePL2C. It requires the feature model of the prod-

uct line to conﬁgure as a tree (PL FM), the set of con-

straints related to that model including XOR, include

and require ones (PL ConstraintsList), as well as the

list of stakeholders involved in the collaborative con-

ﬁguration (Stk List). As result, it ensures a valid con-

ﬁguration as a list of features deduced from stakehold-

ers’ conﬁguration choices (FinalConﬁg). Statements

(St.) 6-8 allow to collect stakeholders’ conﬁgurations.

IRatePL2C’s step -1- is reﬂected by St. 9 which in-

vokes MergeCon f igs() procedure. The while loop

encompasses the three next steps implemented thanks

to the ResolveExplicitCon f licts() procedure (St. 13)

for Step -2-, ResolveXORCon f licts() procedure (St.

16) for Step -3-, and the PropagateConstraints()

function (St. 19) for Step -4-. The two procedures

have as output a list of conﬁguration choices to re-

move from the current conﬁguration CurrentCon f ig

in order to resolve the related identiﬁed conﬂicts (St.

14 and 17). The function determines the features to

add to the current conﬁguration (St. 20) and updates

the conﬁguration choices idegs accordingly (St. 21).

The while loop exits either with a valid conﬁguration,

in such case it represents the FinalCon f ig to return,

or with a conﬁguration that still has some remaining

conﬂicts where idegs cannot help in their resolution;

in such case, the product manager takes a decision and

ﬁnal conﬁguration is returned to stakeholders.

2.1 Conﬁgurations Merging

As mentioned earlier, each stakeholder makes a set of

explicit conﬁguration choices expressing the features

he/she desires to be included or not in the ﬁnal con-

IRatePL2C: Importance Rating-Based Approach for Product Lines Collaborative Conﬁguration

785

Figure 1: The proposed approach process.

ﬁguration; each explicit choice is accompanied by an

ideg ranging from 1 to 5. Only explicit choices made

by the stakeholder are subject to ideg assignment.

Algorithm 2 describes the process of conﬁguration

merging, which consists in obtaining, from the stake-

holders conﬁguration choices LE Con f igStk

, two

lists: (1) the set of all explicit conﬁguration choices

including the desired features and non desired fea-

tures without redundancy List EFs (St. 7), and (2) the

set of all explicit conﬁguration choices, where each

one of them is accompanied with an ordered list of

its related idegs expressed by stakeholders who made

that choice List EFsImportance (St. 8 and 10).

2.2 Explicit Conﬂicts Resolution

This step consists in detecting explicit conﬂicts, oc-

curring when the same feature is, at the same time, de-

sired by a stakeholder and undesired by another one,

in the merged conﬁguration choices; then resolving

them using idegs comparison of involved conﬁgura-

tion choices. If the conﬁguration choice is present

only one time, the same ideg expressed by that stake-

holder is reported. In case that several stakeholders

desired the same state regarding a given feature, the

corresponding ideg is based on the ordered impor-

tance given by the stakeholders related to that fea-

ture. The rationale is to keep what each stakeholder

believes essential to include in the conﬁguration. We

resolve conﬂicts by keeping the conﬁguration choice

with the highest ideg, and eliminating from the con-

ﬁguration the other one involved in the conﬂict.

Algorithm 3 describes the explicit conﬂicts res-

olution steps. It requires as input a conﬁguration

in an intermediate state CurrentCon f ig as well as

List EFsImportance list. It returns two lists; the ﬁrst

one is the list of conﬁguration choices to delete from

the conﬁguration CurrentCon f ig to resolve the identi-

ﬁed explicit conﬂicts (toRemoveList); the second one

contains any eventual non resolved explicit conﬂict

(RemainedExplicitCon f lictsList). St. 10 compares

the idegs of a conﬁguration choice f with those of

its negation ¬ f extracted from List EFsImportance

in St. 8 and 9. The comparison consists in walking

through the two lists degrees; since they are ordered,

the ﬁrst who has an element of grater value than the

corresponding one in the other list, or who has a

greater number of elements in case of equality is the

winner. The looser is added to toRemoveList (St. 11-

15). In case of equality in values and lists length, the

conﬂict is added to RemainedCon f lictsList (St. 17).

This process is applied to each conﬁguration choice

in the form of ¬ f in the CurrentCon f ig in order to

detect all conﬂicts (St. 4-5). The current conﬁgura-

tion is afterward updated by removing toRemoveList

from CurrentCon f ig (St. 14 in Algorithm 1).

2.3 Implicit Conﬂicts Resolution

with XOR) are desired by different stakeholders.

The resolution principle of the XOR implicit con-

ﬂicts, is similar to the used one for the explicit con-

ﬂicts, but applied to features involved in violated

XOR constraints. As illustrated in St. 4-7 of Algo-

rithm 4, it is ﬁrst question to identify any two fea-

tures participating in a XOR constraint; then, extract

the idegs associated to each one (St. 9-10) to de-

termine which one to remove (St. 11-16), or add

the conﬂict to RemainedX ORCon f lictsList if nec-

essary. The conﬁguration choices in the returned

toRemoveList are removed from the conﬁguration

CurrentCon f ig and the non resolved conﬂicts are

added to RemainedCon f lictsList (St. 17 and 18 in

Algorithm 1).

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

786

Algorithm 1: Core Process of IRatePL2C Approach.

Data: PL FM: the tree of features representing the product line to conﬁgure

PL ConstraintsList: the list of constraints related to the product line

Stk List: the list of stakeholders involved in the conﬁguration

Result: FinalConﬁg: a valid conﬁguration as a list of features deduced from stakeholders’ choices

1 begin

2 valid ← False ;

3 di f f erent ← True ;

4 toRemoveList ←

0 ;

5 RemainedCon f lictsList ←

0 ;

6 foreach (Stk

∈ Stk List) do

7 LE Con f igStk

← Con f igure(PL FM) ;

8 MergeCon f igs({LE Con f igStk

} i = 1..Nb Stks → List EFs, List EFsImportance) ;

9 CurrentCon f ig ← List EFs ;

10 while (not valid and different) do

11 PreviousCon f ig ← CurrentCon f ig;

12 ResolveExplicitCon f licts(CurrentCon f ig, List EFsImportance →

toRemoveList, RemainedExplicitCon f lictsList);

13 CurrentCon f ig ← RemoveFromList(CurrentCon f ig, toRemoveList);

14 RemainedCon f lictsList ← RemainedCon f lictsList ∪ RemainedExplicitCon f lictsList ;

15 ResolveX ORCon f licts(CurrentCon f ig, List EFsImportance, PLConstraintsList →

toRemoveList, RemainedXORCon f lictsList);

16 CurrentCon f ig ← RemoveFromList(CurrentCon f ig, toRemoveList);

17 RemainedCon f lictsList ← RemainedCon f lictsList ∪ RemainedXORCon f lictsList ;

18 toAddList ← PropagateConstraints(CurrentCon f ig, PL ConstraintsList);

19 CurrentCon f ig ← AddToList(CurrentCon f ig, toAddList);

20 List EFsImportance ← U pdateFImportance(List EFsImportance, toAddList);

21 di f f erent ← CompareCon f igLists(PreviousCon f ig, CurrentCon f ig);

22 valid ← CheckValidity(CurrentCon f ig);

23 if valid then

24 FinalCon f ig ← CurrentCon f ig;

25 else /* not valid and not different */

26 RemainedCon f lictsList ← CheckRemainedCon f licts(CurrentCon f ig, RemainedCon f lictsList) ;

27 FinalCon f ig ← ApplyProductManagerRules(CurrentCon f ig, RemainedCon f lictsList);

28 return FinalConﬁg;

2.4 Constraints Propagation

Resolving implicit conﬂicts resulting from require

resp. exclude constraints violation amounts to resolv-

ing explicit conﬂicts as they imply the inclusion of

the second part of the constraint ( f

resp. ¬ f

) to

the conﬁguration, which may lead to an explicit con-

ﬂict in case that ¬ f

resp. f

already part of the con-

ﬁguration. Constraints propagation is already dealt

with in the literature (Czarnecki and Kim, 2005), (Be-

navides et al., 2010); it is simply done by walking

through domain (require and exclude) constraints and

updating the conﬁguration by adding a feature or its

negation accordingly. For the purpose of this work,

we need to consider the ideg of any (un)desired fea-

ture added to the conﬁguration in order to keep be-

ing able to resolve conﬂicts based on idegs. As the

source of any addition is a conﬁguration choice be-

longing to the conﬁguration and causing the require

or exclude constraint to be triggered, we assign to the

added (un)desired feature the highest ideg associated

with the source conﬁguration choice. St. 19 in Al-

gorithm 1 returns the list of (un)desired features to

add to the current conﬁguration (St. 20). This same

list is also used to update the idegs associated with

the conﬁguration choices already made by stakehold-

ers and/or add non existing (un)desired features with

their related idegs (St. 21).

On the other hand, any newly added feature to the

conﬁguration may violate a XOR constraint; this ex-

plains the iterative processing for the conﬂicts reso-

lution in IRatePL2C approach. Furthermore, it is ob-

IRatePL2C: Importance Rating-Based Approach for Product Lines Collaborative Conﬁguration

787

Algorithm 2: MergeConﬁgs: Stakeholders initial Conﬁgurations Merging.

Data: LE Con f igStk

i = 1..Nb Stks: list of initial conﬁguration choices made by each stakeholder

Result: List EFs: a list of features representing the merged stakeholders conﬁguration choices

List EFsImportance: a list of the merged conﬁguration choices along with their idegs

1 begin

2 List EFs ←

0 ;

3 List EFsImportance ←

0 ;

4 foreach LE Con f igStk

i = 1..Nb Stks do

5 foreach e ∈ LE Con f igStk

6 if not (e.F ∈ List EFs) then

7 List EFs ← List EFs ∪ e.F;

8 List EFsImportance ← List EFsImportances ∪ (e.F, e.I);

9 else

10 List EFs ← insertOrderedImportance(List EFs, e.F, e.I);

Algorithm 3: ResolveExplicitConﬂicts: Determine explicit conﬂicts and which feature state to remove.

Data: CurrentConﬁg: a list of features reﬂecting an intermediate state of a conﬁguration

List EFsImportance: a list of the merged conﬁguration choices with their related importance

Result: toRemoveList: a list of features to remove from CurrentCon f ig to resolve detected conﬂicts

RemainedExplicitConﬂictsList: a list of explicit conﬂicts that has not been resolved

1 begin

2 toRemoveList ←

0 ;

3 RemainedExplicitCon f lictsList ←

0 ;

4 foreach n f ∈ CurrentCon f ig do

5 if nf.charAt[0]=’¬’) then

6 f ← n f .subString(1);

7 if ( f ∈ CurrentCon f ig) then

8 f ImpList ← extract(List EFsImportances, f );

9 n f ImpList ← extract(List EFsImportances, n f );

10 res ← isMoreImportant( f ImpList, n f ImpList);

11 if (v=1) then

12 toRemoveList ← toRemoveList ∪ n f ;

13 else

14 if (v=2) then

15 toRemoveList ← toRemoveList ∪ f ;

16 else

17 RemainedExplicitCon f lictsList ← RemainedExplicitCon f lictsList ∪ ( f , n f );

vious that the resolution of a given conﬂict may re-

sult in the resolution of another conﬂict. This also

explains the rationale behind the stepped resolution

of conﬂicts. In each step, conﬂicts of a certain type

are detected and resolved before dealing with another

type. This also explains why remained non resolved

conﬂicts need to be checked before passing them to

the product manager in St. 26-27 of Algorithm 1.

3 ILLUSTRATIVE EXAMPLE

We illustrate IRatePL2C through the example of the

Web portal feature model shown in Figure 2, used

in previous works (e.g. (Mendonca et al., 2008) and

(Ben Sassi et al., 2023)). The model contains 3 XOR

relationships, 5 domain constraints of inclusion re-

quirement and 1 exclusion requirement. The conﬁg-

uration scenario is summarized in Table 1, where the

ideg is noted as superscript of the related explicit con-

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

788

Algorithm 4: ResolveXORConﬂicts: Determine XOR conﬂicts and which feature to remove.

Data: CurrentConﬁg: a list of features reﬂecting an intermediate state of a conﬁguration

List EFsImportance: a list of the merged conﬁguration choices with their related importance

PLConstraintsList: the list of constraints related to the product line

Result: toRemoveList: a list of features to remove from CurrentCon f ig to resolve detected conﬂicts

RemainedXORConﬂictsList: a list of implicit XOR conﬂicts that has not been resolved

1 begin

2 toRemoveList ←

0 ;

3 RemainedX ORCon f lictsList ←

0 ;

4 foreach Constraint

∈ PLConstraintsList do

5 if (TypeOf(Constraint

)=XOR ) then

6 for j ← 1 to nbFeatures(Constraint

)-1 do

7 for m ← j + 1 to nbFeatures(Constraint

) do

8 if ((F

∈ CurrentCon f ig) and (F

∈ CurrentCon f ig)) then

9 f j ImpList ← extract(List EFsImportances, F

);

10 f m ImpList ← extract(List EFsImportances, F

);

11 v ← isMoreImportant( f j ImpList, f m ImpList);

12 if (v=1) then

13 toRemoveList ← toRemoveList ∪ F

;

14 else

15 if (v=2) then

16 toRemoveList ← toRemoveList ∪ F

;

17 else

18 RemainedX ORCon f lictsList ← RemainedXORCon f lictsList ∪ (F

, F

);

ﬁguration choice made by each of the ﬁve involved

stakeholders. Throughout the example description,

and for the sake of clarity and space, we mainly fo-

cus on features susceptible to cause conﬂicts.

Table 1: Collaborative conﬁguration scenario.

Stakeholder Explicit conﬁguration choices

Stk1 KeyWordSupport

(2)

, DB

(4)

, ¬Active

(3)

, https

(5)

Stk2 XML

(4)

, ¬Text

(4)

, ¬Active

(5)

, ms

(3)

Stk3 Active

(5)

, Php

(2)

, XML

(1)

, DataTransfer

(4)

Stk4 Text

(2)

, Dynamic

(5)

, KeyWordSupport

(4)

, DB

(3)

¬https

(1)

, ¬Sec

(3)

Stk5 Text

(4)

, Database

(5)

, Active

(4)

, DataTransfer

(3)

Step-1: Merging Stakeholders’ Conﬁguration

Choices. As described in the previous section, merg-

ing stakeholders’ conﬁguration choices leads to two

results: (List EFs) and (List EFsImportance) shown

in Table 2. For example, both Stk1 and Stk4 de-

sire KeyWordSupport with an ideg equals to 2 and

4 respectively. The list (4, 2) is therefore asso-

ciated as ordered idegs to the conﬁguration choice

KeyWordSupport.

Step-2: Resolving Explicit Conﬂicts. Three explicit

conﬂicts are identiﬁed, as mentioned in Table 3. In

the case of the ﬁrst conﬂict, htt ps has one ideg which

is 5, while ¬htt ps has 1 as sole ideg; this means that

Table 2: Merged conﬁguration choices results.

Merged conﬁguration choices

KeyWordSupport, DB, https, XML, ms, Active, Php, ¬https, Data-

Transfer, Text, Dynamic, Database, ¬Text, ¬Active, ¬Sec

Conﬁguration choices with importance degrees

Feature degree Feature degree

https 5 ¬https 1

Active 5, 4 ¬Active 5, 3

Text 4, 2 ¬Text 4

ms 3 ¬Sec 3

XML 4, 1 PHP 2

DataTransfer 4, 3 Dynamic 5

KeyWordSupport 4, 2 Database 5

DB 4, 3

htt ps is retained and ¬htt ps has to be removed. As

to Active and ¬Active, both of them have 5 as ﬁrst

ideg; the following degree should therefore be consid-

ered. The second ideg is respectively 4 and 3, which

means to keep Active in the conﬁguration and remove

¬Active. Regarding Text and ¬Text, both have 4 as

ﬁrst ideg; however ¬Text has only one ideg while

Text has two ones. This means that Text is retained

and ¬Text should be removed. The conﬁguration is

updated accordingly as reported in Table 3.

Step-3: Resolving Implicit XOR Conﬂicts. The

XOR constraint between XML and Database is not

IRatePL2C: Importance Rating-Based Approach for Product Lines Collaborative Conﬁguration

789

Figure 2: Web Portal Feature Model.

Table 3: Explicit conﬂicts resolution results.

Detected conﬂict Retained choice To Remove choice

(https, ¬https) https ¬https

(Active, ¬Active) Active ¬Active

(Text, ¬Text) Text ¬Text

Updated conﬁguration

KeyWordSupport, DB, https, XML, ms, Active, Php,

DataTransfer, Text, Dynamic, Database, ¬Sec

respected. Importance degrees determined in Step-1

and shown in Table 2 are used to decide which feature

to remove. The idegs associated with X ML are 4 and

1. Even though Database has only one ideg, it wins

as its ideg, which is 5, is greater than 4. XML should

therefore be eliminated from the conﬁguration. The

resulted conﬁguration is therefore:

(KeyWordSupport, DB, htt ps, ms, Php, Text,

Dynamic, ¬Sec, Database, Active, DataTrans f er)

Step-4: Propagating Constraints. The full

list of added (un)desired features to the con-

ﬁguration as consequence of constraint propaga-

tion are clariﬁed in Table 4. The idegs as-

sociated with the conﬁguration choices and the

newly (un)desired added features is updated accord-

ingly. The new resulted conﬁguration is as follows:

(KeyWordSupport, DB, htt ps, ¬ms, ms, Php, Text,

Dynamic, ¬Sec, Database, Active, DataTrans f er)

Table 4: Constraints propagation results.

Constraint (Un)desired feature ideg

(KeyWordSupport ⇒ Text) Text 4

(DB ⇒ Database) Database 4

(https ⇒ ¬ ms) ¬ ms 5

(Dynamic ⇒ Active) Active 5

(DataTransfer ⇒ https) https 4

In the second iteration, (i) explicit conﬂicts res-

olution reveals that the conﬂict (ms, ¬ms) is re-

solved by keeping ¬ms since the latter has 5 as

ideg vs. 3 for ms; (ii) all XOR constraints are re-

spected; (iii) constraints propagation does not alter

the conﬁguration obtained from the previous step;

(iv) the validity is checked and veriﬁed. The pro-

cess stops and returns the following ﬁnal conﬁgura-

tion. (KeyWordSupport, DB, htt ps, ¬ms, Php, Text,

Dynamic, ¬Sec, Database, Active, DataTrans f er)

4 DISCUSSION

Satisfaction results for the scenario example (c.f. Ta-

ble 5) that 4 conﬁguration choices among 5 that were

assigned 5 as ideg and 5 among 7 with 4 as ideg were

retained in the ﬁnal conﬁguration. Besides, no con-

ﬁguration choice with 1 as ideg was retained, which

makes sense. The weighted satisfaction shows that

the ﬁnal conﬁguration globally satisﬁed 72% of the

stakeholders conﬁguration choices. When each stake-

holder is taken separately, we ﬁnd that Stk5 is fully

satisﬁed (100%), while Stk2 is not satisﬁed at all

(0%) even though he/she assigned the highest idegs

to his/her conﬁguration choices (5, 4 and 3). The sce-

nario example was deliberately chosen to show that

the retained conﬁguration choices depend not only on

what the stakeholder assigns, but also on what the

other stakeholders chose and what idegs they assigned

to their choices. After all, the IRatePL2C approach

is based on the awareness of stakeholders about how

conﬂicts are resolved.

Regarding the complexity, the proposed solution

is polynomial. Each of its sub-processes relies on

walking through lists and constructing new lists. It

depends on the number of involved stakeholders, the

number of features of the product model, the num-

ber of related constraints and the number of features

per constraint. Previous works that may be compared

to ours, i.e. focusing on collaborative conﬁguration

of product lines and allowing a free-order process

and taking into account stakeholders preferences in

the conﬂicts resolution, namely (Stein et al., 2014),

ENASE 2024 - 19th International Conference on Evaluation of Novel Approaches to Software Engineering

790

Table 5: Satisfaction results for the scenario example.

(Ochoa et al., 2015), (Le et al., 2022) and (Ben Sassi

et al., 2023) have exponential complexity since they

build a set of combinations based on a given set of

features (e.g. SAT solvers, MCS computing); such

problems are known to be NP-complete.

5 CONCLUSION

In this paper, we presented a new approach to re-

solve conﬂicts in the context of collaborative conﬁg-

uration of product lines. Its process allows stake-

holders to freely conﬁgure the product line model

and takes into account their preferences to resolve

conﬂicts expressed through an importance degree as-

signed to each explicit conﬁguration choice. To reach

its aim, IRatePL2C proceeds in steps; in each step,

conﬂicts are detected, resolved and the intermediate

conﬁguration is updated accordingly before starting

the following step. This allows to reduce the num-

ber of conﬂicts and reach easier to a valid solution.

The approach does not prevent to have a completely

dissatisﬁed stakeholder (i.e. all his/her conﬁguration

choices are not included in the ﬁnal conﬁguration), as

the solution depends on the choices of all stakehold-

ers regarding the features to include exclude and the

importance degrees they assign. Further empirical in-

vestigation is needed to reveal some “tips” to avoid

such situations. This is the subject of our future work.

REFERENCES

Ben Sassi, S., Edded, S., Mazo, R., Ben Ghezala, H.,

and Salinesi, C. (2023). Colla-conﬁg: A stakehold-

ers preferences-based approach for product lines col-

laborative conﬁguration. Journal of Syst. and Soft.,

197:111586.

Benavides, D., Segura, S., and Ruiz-Cort

es, A. (2010). Au-

tomated analysis of feature models 20 years later: A

literature review. Information Systems, 35:615–636.

Czarnecki, K., Helsen, S., and Eisenecker, U. (2005).

Staged conﬁguration through specialization and mul-

tilevel conﬁguration of feature models. In Software

Process: Improvement and Practice.

Czarnecki, K. and Kim, C. H. P. (2005). Cardinality-

based feature modeling and constraints: A progress

report. In International Workshop on Software Facto-

ries, pages 16–20. ACM San Diego, California, USA.

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 Syst. and Soft.,

158:110422.

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

BenGhezala, H. (2020). Preference-based conﬂict

resolution for collaborative conﬁguration of product

lines. In 15th Int. Conf. on Evaluation of Novel Ap-

proaches to Software Engineering, pages 297–304.

Le, V.-M., Tran, T. N. T., and Felfernig, A. (2022).

Consistency-based integration of multi-stakeholder

recommender systems with feature model conﬁgura-

tion. In 26th ACM Int. Systems and Software Product

Line Conference, page 178–182.

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.

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

Process-centric approach for coordinating product

conﬁguration decisions. In 40th Hawaii Int. Conf. on

System Sciences, pages 1–10.

Ochoa, L., Gonz

alez-Rojas, O., and Th

um, T. (2015). Using

decision rules for solving conﬂicts in extended fea-

ture models. In ACM SIGPLAN Int. Conf. on Software

Language Engineering, pages 149–160.

Osman, A., Phon-Amnuaisuk, S., and Ho, C. K. (2009).

Investigating Inconsistency Detection as a Validation

Operation in Software Product Line, pages 159–168.

Springer Berlin Heidelberg.

Pereira, J. A. (2017). Runtime collaborative-based conﬁgu-

ration of software product lines. In 39th Int. Conf. on

Software Engineering Companion, pages 94–96.

Raatikainen, M., Tiihonen, J., and M

annist

o, T. (2019).

Software product lines and variability modeling: A

tertiary study. Journal of Syst. and Soft., 149:485–510.

Stein, J., Nunes, I., and Cirilo, E. (2014). Preference-based

feature model conﬁguration with multiple stakehold-

ers. In 18th Int. Software Product Line Conf., pages

132–141.

IRatePL2C: Importance Rating-Based Approach for Product Lines Collaborative Conﬁguration

791