Using decision rules in software product lines for configuration conflicts resolution

(1)

Using Decision Rules in Software Product Lines

for Configuration Conflicts Resolution

Lina María Ochoa Venegas

Systems and Computing Engineering Department

School of Engineering

Universidad de los Andes

Adviser:

Oscar Fernando González Rojas, PhD.

(2)

(3)

List of Figures

1.1 IT investment feature model. . . 12

1.2 Non-functional properties example. . . 12

1.3 Conflicts among configurations. . . 13

1.4 Resolution of conflicting configurations on decision products. . . 14

4.1 Model transformation chain for conflict resolution. . . 27

4.2 Feature model extension with non-functional properties. . . 28

4.3 Feature model transformation into a CSP. . . 29

(6)

List of Tables

4.1 Feature model translation into a CSP problem. . . 30

(7)

(8)

(9)

Abstract

Software product lines represent a set of products related to a particular domain. This set or family shares a group of variable and common features among products. These products can represent a set of decisions taken by different stakeholders in a business scenario. However, decision conflicts can arise among products when they are made in a non-sequential independent manner. This supposes long conciliating meetings in order to arrive to a solution product that conforms to stakeholders’ points of view, and global business needs. Many proposals try to solve this scenario, nonetheless the decision-making process representation results in a complex model, most solutions do not consider non-sequential or independent scenarios, and when they are considered, low level of abstraction mechanisms are proposed without taking into account the complete strategy or methodology for solving conflicts. Moreover, business needs are leaved behind due to the absence of non-functional properties representation, properties such as costs, time, and human resources related to different decisions selection. Hence, we propose a domain-specific

language namedCoCoused to specify both non-functional properties and decision rules for guiding the

conflicts resolution. Simultaneously, we propose a complete resolution strategy that makes use of CoCo language, stakeholders’ decisions, and the decision-making process representation in order to generate a new constraint satisfability problem that could propose a set of solution decisions. Finally, we evaluate our proposal by validating its effectiveness while reducing the representational model complexity, and while executing different business scenarios with different decision rules and conflicting products.

Keywords.conflicts resolution, constraint programming, constraint satisfability problem, decision con-flicts, decision rules, domain-specific language, extended feature model, feature model, feature attributes, model transformation chain, software-product lines.

(10)

(11)

Chapter

1

Introduction

1.1 Problem Statement

Feature models have been used during the last decades as an important domain engineering modeling concept, which provides an abstract, explicit, and concise representation of a system variability [1]. A feature model defines a Software Product Line (SPL) for a given domain [2], and it can also represent a decision-making process. Under this scenario, the set of selected and deselected features correspond to a set of decisions defined by a stakeholder. Usually, on an organization there are multiple stakeholders that participate on the same decision-making context. Thus, different roles such as business leads, IT leads, project managers, among others, base their decisions on their knowledge and expertise. However, the decision products defined by these stakeholders can result into different conflicts between configurations and business needs.

Several approaches manage conflicts by avoiding the introduction of inconsistencies, while using a decision propagation strategy [3]. Other approaches focus on creating configurations by allowing

inconsistencies to be solveda-posteriori[4]. Nonetheless, both approaches are supported with techniques

like Binary Decision Diagrams (BDDs), Satisfiability (SAT) [5] [6] [7], and Constraint Satisfaction Problem (CSP) solvers [8] [9]. However, any known project considers the use of quantitative decision rules to converge stakeholders’ points of view into the best product (decision scenario). These projects neither prioritize both business needs and stakeholders expertise. The evaluation of additional decision rules associated to different domains such as costs, time, or human resources are required to manage conflicts.

1.2 Motivation

This section presents a motivating example with its corresponding representation, and a problematic scenario which is the center of our research.

1.2.1 Motivating Example

Enterprise information systems such as Enterprise Resource Planning (ERP) and Customer Relationship Management (CRM) are positioned as strategic investments, which increase efficiency of business processes operation through their robustness and quality attributes. These information systems are

(12)

Decisions Implications

[…]

Figure 1.1: IT investment feature model.

composed by modules that are implemented and configured in order to fulfill different business needs. However, organizations should have a decision process in order to select the appropriate characteristics and modules that could enhance its operation. These processes involve multiple stakeholders which can be viewed as decision-makers. Given their different expertise and points of view, decisions should vary between them and can result into conflicts. This resolution task demands time and effort to seek a unanimous set of decisions.

Figure 1.1 shows a subset of a feature model that was created to represent a decision process used for

planning ERP and CRM investments1. Thedecisionsbranch contains 12 decision types defined as decision

categories represented by non-atomic features, and 125 decision options which are selection alternatives

to different decision types and are represented as atomic features. Theimplicationsbranch contains 219

consequences of the decision options selection which are defined in terms of business dimensions such costs, time, and human resources. Decisions and implications features are related through 192 cross-tree constraints.

At this example we can identify three decision types at thedecisionsbranch (i.e.,business drivers,

business systems with both ERP and CRM features, and solution type). Each of the atomic features or

feature leaves are decision options related to the given parent feature (e.g.,improve customer support,

management, and commercial, among others). There are nine decision options related to the modeled decision types. In addition, two cross-tree constraints are represented as logical propositions at the center

bottom of the image. They representrequirerelationships among features through the use of the logical

definitionp→q, wherepandqrepresent two different decision feature options on the model.

Dimension: Costs

Impact variable: Support

Min. Magnitude: 0 USD

Max. Magnitude: 5.000 USD

Observations: Less expenses.

Impact variable: Licensing

Observations: More expenses.

Impact variable: Support

Observations: More expenses.

Impact variable: Licensing

Max. Magnitude: 500 USD

Observations: Less expenses.

1

2

3

4

Figure 1.2: Non-functional properties example.

Theimplicationsfeature is parent of six additional non-atomic features:impact variablethat defines 1

The complete representation of the feature model can be found at: http://ticsw.uniandes.edu.co/ITGovernancePublic/Features Model.xml

(13)

the task or subject affected by the implication (e.g.,licensing);dimensionwhich represents the business

dimension related to the implication (i.e.,costs, time, human resources);unit measurewhich defines

the unit of the defined magnitude (e.g.,USD);magnitudethat defines a numeric value related to the

implication;frequencywhich defines the periodicity on which the implication affects the organization;

andobservationsthat are semantic additional information for the stakeholders (i.e.,it could be seen as important comments for the decision-makers). Figure 1.2 illustrates features of cost implications as if they had been specified as feature attributes. Implications that are related to decision options through cross-tree constraints are represented as annotations (rectangular boxes) on their corresponding feature (dotted connection line). Each decision option could have multiple implications associated to a unique dimension.

For example, if thecommercialdecision option is selected, the organization should pay between 0 and

5.000 USD each month for the systemsupport. In contrast, a monthly cost between 0 and 10.000 USD is

required for the same activity when selecting theopen sourceoption.

1.2.2 Conflicting Configurations

Conflicts can arise between decisions taken by different stakeholders. Figure 1.3 shows two conflicting configurations performed by different stakeholders on the presented feature model. Each configuration has a list of decision types and decision options that are selected (+symbol). Their selection supposes the

deselection (−symbol) of other features according to the defined constraints.

Stakeholder 1

Stakeholder 2

Figure 1.3: Conflicts among configurations.

As it can be seen, for thebusiness driversdecision type, stakeholder 1 selected the optionimprove

customers support. However, this selection supposes the deselection of the optionreduce delivery time. The conflict arises when the second stakeholder selects this last feature, forcing the deselection of the

improve customers supportwhich was previously selected by the first stakeholder. There is an evident conflict at this first decision. At the same time, the selection of theimprove customer supportimplies the

selection of thecustomers CRMmodule according to the second cross-tree constraint; while the selection

(14)

constraint.ERPandCRMare exclusive between them so we obtained a second set of conflicts between the stakeholders’ decisions. Finally, stakeholder 1 selects acommercial solution type, and stakeholder 2

selects anopen source solution type. Nevertheless, these two options are exclusive between them so a

third set of conflicts appeared between the two configurations.

1.3 Solution

This project presents a new approach to solve conflicts between stakeholders’ configurations performed

over feature models (cf. Figure 1.4). First, we propose a Domain-Specific Language (DSL) named

CoCo to specify non-functional attributes that define business analysis dimensions (i.e.,costs, time, and human resources). IT and business stakeholders can configure decision products by selecting a set of valid feature combinations in the feature model. CoCo also allows the specification of business-related constraints (namely decision rules) in terms of the above analysis dimensions to scope the set of potential non-conflicting solutions among configurations. Second, we present a model-based transformation approach to capture these three assets and transform them into a Constraint Satisfaction Problem (CSP) that enables stakeholders to obtain a set of non-conflicting products that satisfies the business needs represented through decision rules. Finally, the effectiveness of our approach was evaluated by means of non-functional properties and decision rules specification over a set of predefined decision scenarios.

Extended feature

model Decision products

Set of solution decision products

Stakeholders Business

lead

Conflicts resolution (Model Transformation Chain)

Decision rules IT lead

Figure 1.4: Resolution of conflicting configurations on decision products.

1.4 Document Structure

This document is organized as follows. Chapter 2 presents the general description of our project including the project context, the identified problems, the defined objectives, and a set of concepts that will be used along this document. Chapter 3 presents the project scope, the employed methodology, and a set of restrictions. Chapter 4 describes the main elements of the proposed DSL to specify feature attributes and decision rules for solving conflicts, and the model transformation chain created to implement the defined strategy into an executable CSP. Chapter 5 illustrates two experiments performed to validate the applicability of the proposed approach. In Chapter 6 we discuss related work. Finally, conclusions and future work are presented in Chapter 7.

(15)

Chapter

2

Problem

2.1 Context

The current projects is defined in the framework research project "Business and IT alignment: impact quantification, control, and support to strategic decision-making", and particularly in its derived project "Simulation of IT decision-making", both related to the research group TICSw at Universidad de los Andes. IT decision-making is supported by a set of methodologies, frameworks and tools that analyze, qualify and quantify decisions, in order to support organization value creation. Nonetheless, decision-making is not always structured, and their supporting mechanisms are not always available. Therefore, this research project aims to model IT decisions and their corresponding implications in an organization, propose structured guidelines to support decision-making scenarios, and develop a simulation tool that elucidates results and alternatives during a decision scenario [10].

As result of the mentioned project, it was designed a feature model that represents the most recurrent decision types and options taken into account by an organization when investing on IT. This feature model is exposed in Section 1.2. Our proposal is centered on exploring new ways of modeling IT decisions, on structuring decision-making and considering a well-defined resolution strategy among stakeholders’ decisions, and on developing a first prototype of the implemented strategy.

2.2 Problems

According to the exposed motivating example as well as to the studied related work, the following four issues are identified while managing conflicts between decision products:

Problem 1: Feature Model Complexity when Representing the Decision Process

Dimensions such as costs, time, and human resources among others, are associated to IT decisions selections as implications. When representing the decision process in a standard feature model, the organization needs to map associations among the decisions and the implications branches in the feature model. Therefore, the modeler should create the needed features at the implications branch, as well as the required constraints that generate the real mapping. Hence, the created constraint should include the decision option as a condition and the implications features as consequences. These features should define dimensions, frequencies, unit measures, magnitudes, impact variables, and other representative

(16)

implications attributes. Consequently, the introduction or edition of a constraint could suppose a manual error over the model consistency, as well as a non-maintainable task that requires the identification of the desired constraint and its correspondent change [11].

Problem 2: Few Solutions Considering Non-sequential Decision-making Scenarios

Most research projects focus on propagating decisions while considering a sequential decision-making process. These solutions are centered on a sequential process where multiple stakeholders can participate, and are responsible of a subset of decisions. Each decision taken at different moments affects the selection or deselection of future decisions. In that way, decisions taken by an stakeholder or in a particular moment directly impacts the set of decisions taken by another stakeholder or other moment in time. However, sometimes decisions can be taken simultaneously by multiple stakeholders, or they are taken in private environments, where other stakeholders do not know decisions taken by their colleagues.

Problem 3: Absence of a Well-defined Strategy for Solving Conflicts among Decisions in a Non-sequential Scenario

The few research projects that focus on non-sequential conflicts resolution scenarios do not define a complete strategy for solving conflicts among decisions. Low level of abstraction techniques and mechanisms are defined, however there does not exist a complete methodology or strategy that defines the step-by-step approach for executing the resolution process. Tools are decoupled and do not provide a complete solution to a real scenario. Organizations need an orchestrated solution that can answer to their decision-making conciliation and needs.

Problem 4: Conflicts Solving does not take Advantage of Non-functional Properties

Most research projects related to conflicts solving focus on avoiding inconsistencies between configura-tions, or they proposed alternatives that does not simultaneously take into account both non-functional properties related to each decision option, and stakeholders’ decisions. Currently, these approaches provide configuration solutions based on modifying the minimal set of features states between all stakeholders’ decisions [9], or on discarding these decisions and generating a new configuration based on a cost function

(cf.section 6). Even more, conflicts solving proposals do not take into account the overall business

interests over those non-functional properties such as restrictions over costs, time, and human resources. In our motivating example, this means that implications are not taken into account when defining the best solution for conflicting configurations.

2.3 Objectives

This section presents the general objective of the undergraduate project, as well as the specific objectives related to it.

2.3.1 General Objective

To support decision-making process through the generation of a strategy and a tool that solve conflicts between stakeholders decisions, while reducing process complexity and considering non-functional

(17)

properties.

2.3.2 Specific Objectives

• To reduce decision-making process complexity through its representation in an extended feature

model.

• To consider non-functional properties in a decision-making process.

• To define a strategy based on a model transformation chain approach to solve conflicts between

stakeholders’ decisions.

• To define a set of decision rules that supports the decision conflicts solving.

• To implement the predefined strategy through a technology that allows the interpretation of both

decision-making process and decision rules.

2.4 Conceptual Background

This chapter presents the conceptual background of our research project. Section 2.4.1 presents feature modeling process and relevant concepts and techniques; Section 2.4.2 defines conflicts among configura-tions; Section 2.4.3 defines a model transformation chain and its relation with MDE; and Section 2.4.4 describes Constraint Programming (CP) and its relation with CSP.

2.4.1 Feature Modeling

Feature modelingis a "technique for analyzing and capturing the common and the variable features of systems in a system family and their interdependencies" [1]. It was first associated to Feature-Oriented Domain Analysis (FODA) methodology by Kang et al. as part of the feature analysis activity of domain modelling [12]. Czarnecki adopted the technique as part of domain analysis, a process component of domain engineering [1]. In general, feature modeling is an activity to define common and variable aspects of a given domain.

Feature Models

Feature modelsare the most common output of feature modeling. They represent points of commonality and variability through features arranged on a feature diagram, and they also extend its expressiveness

while defining cross-tree constraints. Afeaturerepresent a reusable and configurable property or

char-acteristic from a concept that supposes a difference for a stakeholder [1]. Features in a feature model are arranged on a tree structure calledfeature diagram. This structure disposes features, tree constraints, and integrity constraints in order to define a complete concept family, specifying the domain concept on the root node [13]. Concept formalization based on Schobbens et al. proposal is shown on Definition 3 [14]. By his side, a cross-tree constraint seeks to define additional interaction among features as a logical formula over a subset of features [13].

(18)

Definition 1 (Features) Fis a set of features with typical elementfi, wherefiis a boolean functional

property wherefi ∈ {true, f alse}and1≤i≤ |F|. A featurefiis selected iffi =true, and it is

deselected iffi=f alse.

Definition 2 (Feature Model) A feature model is a duple(FD, CTC)whereFDis a well-defined feature diagram (cf. Definition 3), whileCTCis the model cross-tree constraints set (cf. Definition 6).

Definition 3 (Feature Diagram) A feature diagramFDis a tuple(F, r, TC, IC), where:

• Frepresents the features set with typical elementfi(cf.Definition 1).

• rrepresents the root feature such thatr∈F.

• TCrepresents the tree constraints set such that|F|=|T C| −1(cf.Definition 4).

• ICrepresents the integrity constraints set (cf.Definition 5).

• FDis connected, acyclic, and any two features are connected by a uniqueTCelement.

Additionally, feature models represent functional properties through features, however they could be extended in order to define non-functional properties through feature attributes. These models are known asextended feature models. As proposed by Soltani et al. we will assume that these feature attributes could express both qualitative and quantitative properties. Furthermore, they will only be valid foratomic featuresand not fornon-atomic featureswhich are used for defining variability, concept structure, and atomic features grouping. An atomic feature is a leave node from the feature model, while a non-atomic feature is an intermediary node with a non-empty set of children nodes [15].

Constraints

We identified three types of constraints: tree constraints, and integrity constraints associated to feature diagram concept, and cross-tree constraints related to feature models. We will briefly describe these types. For more detail about these concepts remit to Kang et al. and Czarnecki et al. referenced publications.

Tree constraintsdefine different relationships among parent features and children features, also known

as a logical grouping of features [13]:alternativerelations that represent a XOR function over children

features selection;orrelation which represents the needed selection of at least on feature from children features subset and at most all elements of this subset;mandatoryrelations that enforces the selection of

(19)

Integrity constraintsdefine two types of relationships among any two or more features:requireswhere given a set of selected features enforces the selection of a different set of features; andexcludeswhere given a set of selected features enforces the deselection of a different set of features. Finally,cross-tree constraintsdefine logical formulas in order to express relations that extend the integrity constraints expressiveness.

Definition 4 (Tree Constraints) Tree constraints TC is a set of triple relations on F such that

(ϕT C, fi, fj)⊆T C,fi, fj ∈F,fiis a proper ancestor or parent offj,fj is a proper descendant or

child offi, andϕT C ∈{xor, or, mandatory, optional} is a function overfiandfj.

Definition 5 (Integrity Constraints) Integrity constraintsICis a set of triple relations on F such that(ϕIC, fi, fj)⊆IC,fi, fj ∈F, andϕIC ∈{requires, excludes} is a function overfiandfj.

Definition 6 (Cross-Tree Constraints) Cross-tree constraintsCTCis a set of propositions of the elements of Fsuch that they are related by propositional connectors.

Configurations

Aconfigurationcould be defined as an instantiation of a feature model. It consists of a set of selected and deselected features from the feature diagram that should conform to both cross-tree constraints and feature diagram associated constraints [16]. Configurations have different representations according to the employed tool for defining them. However, they are usually displayed as a hierarchical check list where stakeholders define their requirements while selecting or deselecting features, i.e. while defining a selection state to each feature from the feature diagram.

Definition 7 (Configuration) A configurationCis a duple(FS, FD)such thatFS, FC ⊆ F, and

FS∩FD =∅, whereFSis the set of selected features, andFC is the set of deselected features.

The configuration process can result into avalidconfiguration when cross-tree constraints and feature diagram constraints are not violated, or into aninvalidconfiguration otherwise. In addition, a configuration could becompletewhen it defines a clear selection state for all features from the feature diagram; if at least one feature selection state is not defined we consider the set as apartialconfiguration. Furthermore,

a configuration is known as a product when it is both valid and complete, i.e. it responds to valid

(20)

2.4.2 Conflicts among Configurations

Feature modeling and configuration process can derive into different conflicts and errors. Nonetheless, we are interested on conflicts among configurations. According to White et al. "conflicts can occur when multiple stakeholders in a configuration process pull the solution in different directions" [9]. Therefore, aconflictamong configurations is a state during a configuration process, in which the resulting configurations from different stakeholders have different selected and deselected features, and the union of these configurations result into an output configuration that does not conform to the feature model constraints.

Definition 8 (Conflict) A conflict τ is a state of a configuration process on which for a set of configurations {C1, C2, ..., Cn}, we obtain an invalid resulting configurationCR = Sni=1Ci =

(FSR, FDR)that does not conform to TC, IC, and CTC constraints.

2.4.3 Model Transformation Chain

A Model Transformation Chain (MTC) is a sequence of transformation tasks that take a high-level input model and translate it into low-level output assets. In that way, problem domain concepts are transformed into solution domain concepts [18]. MDE which is a clear exponent of separation of concerns, uses MTC to integrate those concerns when a translation to a solution domain is needed [19].

2.4.4 Constraint Programming

Constraint programming is a programming approach that combines both reasoning and computing techniques. It is based on the concept ofconstraintwhich defines a relationship among a set of variables domains. When a problem is defined in a constraint programming context by means of a finite set of variables and constraints, we obtained aconstraint satisfaction problem(i.e.CSP). A CSP aims to define a consistent problem (i.e. a problem modeling with at least one solution), to find a set of solutions, and to find optimal solutions [20]. A formal definition is taken from Alvarez-Divo and exposed on Definition 9 [17].

Definition 9 (Constraint Satisfaction Problem) A CSP is a triple (V,D,C) where V =

{v1, v2, ..., vn}is the problem variables finite set,D ={d1, d2, ..., dn}is the respective variables

domain set such that∀i:vi ∈diand1≤i≤n, andC ={c1, c2, ..., cn}is the problem constraints

(21)

Chapter

3

Design and Restrictions

3.1 Scope

The scope of this undergraduate project is centered on developing a conflicts resolution strategy that could solve conflicts between stakeholders’ decisions. This strategy should have a first implementation while using existing tools related to Java and Eclipse technologies. In addition, the undergraduate project results will be used for deriving a set of papers that gathers the main goals of our research. In that way, at the end of the project implementation we should produce a well-defined resolution strategy, a first Eclipse plugin version with the strategy implementation, and a set of papers that make use of the generated content. A complete set of user testing is not consider for this first development iteration.

3.2 Methodology

This undergraduate project has a hybrid-based methodology, given the intention of having a qualitative and a quantitative approach. Moreover, we consider an application-based nature, related to the need of applying the obtained results to a well-defined context. Therefore, we propose the execution of a set of experiments over the exposed motivating example. Therefore, this project should be developed though two phases: an experimentation phase for discovering the capabilities of new technologies; and a second phase where the solution is defined and should be implemented through a particular mechanism obtained from the first phase.

3.2.1 Experimentation Phase

For this phase we proposed three types experiments needed for defining the solution road map:

1. Exploring FeatureIDE: we pretend to explore FeatureIDE capabilities, and the possibility of defining configurations. We also pretend to align its functionalities with the business dynamics, in order to start implementing the needed conflicts resolution strategy.

2. Exploring transformation languages:we should verify two available transformation languages, in order to compare and select the best alternative for the project needs. The languages that we will verify correspond to ATL and Epsilon Languages. We should compare learning curves, expressiveness, and capabilities.

(22)

3. Exploring solvers: it is important to explore different solvers that can traduce the complete expressiveness of our decision rules, and the complete decision-making process. We should compare SAT, BDD, and CSP solvers to implement a first solution for our predefined problems.

3.2.2 Solution Implementation Phase

For the solution implementation phase we propose the design and execution of five tasks that elucidates the complete strategy. Each task is described below:

1. Decision-making process representation: the decision-making process should be represented through a feature model, while making use of FeatureIDE capabilities. We count with a first feature model version defined in S.P.L.O.T. which will be use as motivating example.

2. Configurations managing: a set of configurations should represent the stakeholders’ decisions. These assets should be represented through FeatureIDE. Each configuration has a set of independent decisions that can conflict with other stakeholders’ configurations.

3. Non-functional properties specification:we should incorporate a set of non-functional properties to the possible decisions modeled through the feature model. In this way, we should make use of an extended feature model that supports this additional information.

4. Decision rules specification: we should specify a set of decision rules that support the conflicts resolution strategy, while taking into account the stakeholders’ decisions, and the business interests and restrictions.

5. Conflicts solving: the complete strategy should be implemented in order to generate a set of solution configurations. This implementation should include the translation of the extended feature model, the set of configurations, and the set of decision rules, through the usage of the selected solver.

3.3 Restrictions

The project counts with three restriction types: resources, time, and technology restrictions.

• Resources restriction:the project counts with the participation of one assistant teacher, and one

undergraduate student with a six hours weekly time dedication.

• Time restrictions: the project should be designed, implemented, and validated during a four

months period, concerning to an academic term.

• Technology restrictions:we count with a feature model implemented in S.P.L.O.T. that should be

employed along the project development. Moreover, the employed technologies should not suppose a high learning curve due to time and resources restrictions.

(23)

Chapter

4

Implementation

4.1 CoCo DSL Implementation

This section describes how feature attributes and decision rules are specified through a DSL named CoCo

(Conflicts amongConfigurations resolution). Both types of specifications are associated to business

dimensions such as costs, time, and human resource, in order to favor separation of concerns and maintainability. Feature attributes represent non-functional properties such as the implications described in Section 1.2. Decision rules are a set of optimization and hard limit functions applied to the total value of business dimensions. This total value is obtained from the sum of the different feature attributes associated values for a given business dimension.

4.1.1 Specification of Non-functional Properties on CoCo

The specification of non-functional properties is done with the aim of enriching the feature model with information related to decision options, and to take advantage of these specifications in order to apply decision rules during conflicts among configurations resolution process. Non-functional properties are specified through attribute types and feature attributes.

Attribute typesare semantic information which define an organization ambit of evaluation,i.e.,they are categories that are analyzed during a decision-making process. We define a dimension as a tuple of four values: anidentificationthat represents the dimension in both organizational and technical contexts;

a dimension such as costs, time, human resources, and risks; aunit measure, such as USD in the case of

costs dimension; and afrequency unitthat defines the periodicity of the dimension impact such as each

month, quarter, and year, among others. Attribute types could vary from organization to organization, that is why they should be customisable. Although, attribute types express the overall ambit of evaluation inside an organization, their related values to atomic features (i.e.,decision options) are the real impact that allows project alternatives selection.

Listing 1 provides an example of the specification of attribute types below the keywordAttribute_Types. In this example we present three new attribute types. The first attribute type has the identificationCosts01, it is from thecostsdimension, it is measured inUSD, and it has an impact over the project execution each

month. The second dimension has the identificationHR01, it is from thehuman resourcesdimension,

it is measured inpeople units, and it has an impact eachmonth. Finally, the third dimension has the

(24)

year.

1 A t t r i b u t e _ T y p e s {

2 c r e a t e Costs01: Costs measuredIn "USD" each "Month";

3 c r e a t e HR01: HumanResources measuredIn "People" each "Month"; 4 c r e a t e Time01: Time measuredIn "Months" each "Year";

5 }

Listing 1: CoCo attribute types specification.

Afeature attributecan be defined as an extension of a feature inside a feature diagram. It associates a set of non-functional information that cannot be captured by a feature. A standard feature model (i.e.,a model without feature attributes) needs a complex solution in terms of the number and management of constraints and features to represent this data. Hence, in order to centralize the management of these non-functional properties, they are arranged as attributes of atomic features or decision options.

CoCo defines a feature attribute in terms of five well defined properties: anattribute type reference

that captures the previously defined attribute type identification; animpact variablethat defines the task or organizational subject that is directly affected by the non-functional definition; alower valueboundary that defines the floating minimum value that could be taken by the feature attribute in a given context; anupper valueboundary that defines the floating maximum value that could be taken by the feature attribute; and finally, additionalobservationsthat have qualitative information that could be relevant for stakeholders.

Listing 2 provides an example of feature attributes specification below the keywordFeature_Attributes. In this case we present the definition of the four feature attributes shown in Figure 1.2. We present

the assignation of two feature attributes to bothcommercial andopen source decision options. Both

options are children of the non-atomic featuresolution type(cf.feature model in section 1.2). As it can be noticed, the organization can assign multiple feature attributes to the same feature, and they could be part of different attribute types. The only restriction if they are part of the same attribute type, is that the impact variable should vary in order to avoid inconsistencies or overwriting non-functional properties. Returning to Listing 2, the first non-reserved value of each feature attribute represents the previously

defined attribute type identification such asCosts01; the second non-reserved value defines an existing

feature; the third non-reserved value defines the impact variable such assupport, orlicensing; the next non-reserved values represent in the corresponding order the lower bound value, the upper bound value, and additional observations.

1 F e a t u r e _ A t t r i b u t e s {

2 a t t r i b u t e Costs01 onFeature Commercial impacts "Support" between 0.0 and 5000.0

3 observations "Less expenses.";

4

5 a t t r i b u t e Costs01 onFeature OpenSource impacts "Support" between 0.0 and 10000.0

6 observations "More expenses.";

7

8 a t t r i b u t e Costs01 onFeature Commercial impacts "Licensing" between 0.0 and 1250.0

9 observations "More expenses.";

10

11 a t t r i b u t e Costs01 onFeature OpenSource impacts "Licensing" between 0.00 and 500.0

12 observations "Less expenses.";

13 }

(25)

4.1.2 Decision Rules Specification on CoCo

The second objective of CoCo DSL is the specification of decision rules.Decision rulesare defined by

the organization as impartial and conclusive criteria for solving conflicts between stakeholders’ decisions without losing their knowledge. These rules reduce the set of solution alternatives into a subset that focuses on giving an answer to the organization interests. CoCo admits two types of rules: optimization rules, and hard limit rules.

Optimization rulesdefine a maximization or minimization task over a dimension; whilehard limit rulesdefine a set of boundaries over a dimension, this means that a limit is applied over the sum of the values related to a given attribute type. Hard limit rules are logical relations over attribute type values that admit the following operators:less than(i.e.,lt),less than or equal to(i.e.,leq),equal to(i.e.,eq),

greater than(i.e.,gt), andgreater than or equal to(i.e.,geq). Simultaneously, the company could define an optimization function that minimizes or maximizes the product value according to the defined hard limit.

After the specification block ends, the organization should specify the rules to be executed. In that way, they should refer to the decision rule name or to the keywordallfor executing all the rules defined in the corresponding decision rules block. The way on which rules are executed is defined in Section 4.1.3.

For example, the company in the motivating example decided to maximize the investment costs while assuring that these costs could not exceed 15.000 USD. Listing 3 illustrates the proposed specification for

the previous exposed decision rules. Decision rules should be defined below the labelDecision_Rules,

and they could be both optimization and hard limit rules. Each optimization rule defines as first non-reserved value the rule identification; it is followed by the desired optimization function represented by the terminal symbolsmaximize, orminimize; finally, the affected attribute type identification (e.g., Costs01,

Time01, orHR01) is specified. On its side, each hard limit rule defines as first non-reserved value the rule identification, and as second non-reserved value the affected attribute type identification; these values are pursued by a hard limit logical relation terminal symbol (i.e., lt,leq,gt,geq, oreq); and the rule ends with a double value related to the defined hard limit. At the end, the organization specifies the execution of both decision ruleR1, andR2.

1 D e c i s i o n _ R u l e s{

2 //This is an optimization rule

3 d e c i s i o n R u l e optimization R1: minimize Costs01; 4

5 //This is a hard limit rule

6 d e c i s i o n R u l e hardLimit R2: Costs01 leq 15000.00;

7 }

8

9 e x e c u t e: R1, R2;

Listing 3: CoCo decision rules specification.

4.1.3 DSL Syntax

CoCo uses a set of forms and keywords employed during the specification of attribute types, feature attributes, and decision rules. We will show the specific forms and the corresponding keywords for each mentioned element.

(26)

Attribute types. For defining an attribute type CoCo proposes the usage of the keywords create,

measuredIn,each, and the labelAttribute_Types. This last label is used once on the DSL to specify the attribute types’ definition block, which is encapsulated between curly braces. For defining an attribute type the remaining keywords should be arranged in the next form:

createattributeTypeId: dimensionNamemeasuredInunitMeasureeachfrequencyUnit;

Feature attributes. For feature attributes specification CoCo uses the keywordsattribute,onFeature,

impacts,between,and,observations, and the labelFeature_Attribute. This label is used once in the DSL to define the feature attributes block, which are also encapsulated between curly braces. For defining a feature attribute the remaining keywords should be arranged in the next form:

attributeattributeTypeIdonFeaturefeatureNameimpactsimpactVariablebetweenminimumValue

andmaximumValueobservationsobservations;

Decision rules. For specifying decision rules CoCo uses different keywords depending on the rule type.

For both rules CoCo employs the keyworddecisionRule, and the labelDecision_Ruleswhich defines the

rules specification block. This block is also encapsulated between curly braces. For optimization rules it is used the keywordsoptimization, andmaximizeorminimize; and for hard limit rules it is usedhardLimit, andleq, lt, eq, geq, orgt. For both cases we use the next specification forms in the respective order:

decisionRule optimizationruleId: (maximize|minimize)attributeTypeId;

decisionRule hardLimitruleId:attributeTypeId(leq|lt|eq|geq|gt)boundaryValue;

The organization can specify multiple decision rules related to both optimization and hard limit categories. However, it is needed to specify at most two rules of each type to be executed, and at least one optimization rule. The execution of the rules is defined out of the decision rules block after the keyword

execute. Therefore, CoCo proposes four different ways of defining the rules execution, which are defined below:

execute :optimizationRuleId;

execute :optimizationRuleId,hardLimitRuleId; execute :hardLimitRuleId,optimizationRuleId; execute : all ;

The first expression defines the execution of just one optimization rule using the rule identification. The second and third way allow the specification of two rules (a rule of each type) separated by commas

in any order. Finally, the fourth way allows the usage of the keywordallwhich executes all the rules

define under theDecision_Ruleslabel. If this block has more than one rule of each type, the interpreter

(27)

4.1.4 DSL Advantages

The advantages of CoCo reside on the possibility of defining non-functional properties and decision rules at a high level abstraction, its expressiveness aligned with real context business needs, and its strong relationship with a well-defined feature model that represents a decision process. The first mentioned advantage is achieved with the usage of natural language, and the specification of the minimum set of variables needed to transform decision rules into a CSP. In that way, both technical and non-technical stakeholders could define a set of decision rules that conform to the organization interests.

On its side, CoCo is completely aligned to a feature model that represents a decision process. It relies on developed technologies in order to extend their capabilities. In that way, CoCo enhances functionalities of real tools with the objective of favoring the business decision process characterization, and the conflicts among configurations resolution.

4.2 Model Transformation Chain Implementation

This section describes the MTC implemented to transform the strategy inputs into a CSP that can be executed in order to solve conflicts among configurations. The implementation of the strategy considers two alternatives with a unique resolution path. The first alternative uses as inputs a standard feature model, and non-functional properties specified with CoCo. The second alternative was created due to the design of the feature model presented in Section 1.2. This alternative considers a standard feature model that

contains non-functional properties (i.e.,implications) modeled as features, and relationships between

these properties are modeled as constraints. In Figure 4.1 we illustrate the inputs, outputs, and involved transformations in the MTC.

CoCo DSL (Non-functional properties) Non-functional properties model EOL program Standard feature model Extended feature model T2M [Xtext] M2T [EGL] M2M Standard feature model (with implications) M2M [EOL] Parser Configurations Marked feature model Choco CSP (Java class) M2T [EGL] CoCo DSL (Decision rules) Solution decision products set Execute Alternative 2 Alternative 1

Figure 4.1: Model transformation chain for conflict resolution.

The MTC will be described in two parts: the extension of the feature model with non-functional properties, and the creation of decision rules that will be part of the conflicts among configurations solving strategy. This MTC is partially developed using tools as: FeatureIDE for managing feature models in a XML format [7]; Xtext for the CoCo DSL specification [21]; Epsilon languages such as Epsilon Generation Language (EGL) for model to text transformations, and the Epsilon Object Language (EOL) used for the model to model transformations [22]; and the Java CSP solver, Choco [23].

(28)

4.2.1 Feature Model Extension with Non-Functional Properties

The MTC presented in this section is graphically represented in Figure 4.2. A feature model that represents a decision process could be extended with non-functional properties. As earlier mentioned, we propose two alternatives for achieving this objective.

CoCo DSL (Non-functional

properties)

Standard feature model

Standard feature model (with implications)

Extended feature model

Alt ern ativ e 1 Alt ern ativ e 2 Feature Implications feature Feature attribute Legend:

Figure 4.2: Feature model extension with non-functional properties.

The first alternative applies for any standard feature model with a set of defined decision types and

options. This alternative receives as inputs the feature model and the CoCo DSL. TheCoCo DSLgenerates

anon-functional properties modelthrough a text to model (T2M) transformation. Then the created model

is transformed into anEOL programthat will be used to extend the originalstandard feature modelinto

anextended feature model. This EOL program contains the information related to the non-functional properties. In Figure 4.2 the feature attributes are represented through the light-purple squares related to their corresponding feature.

On the other hand, the second alternative was strictly developed for our motivating example, but it could be used for any other standard feature model that defines implications as it was described in Section 1.2. In Figure 4.2 the implications branch is represented through the dark-purple feature. Through this path thestandard feature model (with implications)is transformed into aextended feature model. This is done while taking the implications features and their associated cross-tree constraints, deleting them from the feature model, and converting them into feature attributes related to a specific feature. It is important

to notice that theextended feature modelcreated at the end of both alternatives has the same XML schema

for the two solutions.

4.2.2 Feature Model Transformation into a CSP

Once theextended feature modelis obtained (cf.section 4.2.1), configurations and decision rules

speci-fication could be taken into account in order to propose a set ofsolution decision products. Figure 4.3

illustrates this final set of tasks related to the proposed MTC.

At this point, stakeholders should define their decisions through a configuration process. This will

result into a set ofconfigurationsthat could be conflicting among them. All the selected features of

(29)

CoCo DSL (Decision rules)

Extended feature model Marked feature model

Choco CSP Feature

Selected feature Feature attribute Legend:

Figure 4.3: Feature model transformation into a CSP.

invalid. Therefore, both the extended feature model and the configurations are inputs to a parser which is

responsible of adding the attributeselected = “true”to the corresponding parent features. Theselected

attribute is created as an attribute over some feature nodes, in order to apply the theory proposed by Karatas et al. [11]. This results into amarked feature modelthat continues to be an extended feature model with an additional tag under certain features. In the Figure the green rectangles represent the selected features by any stakeholder.

Afterwards, the marked feature model and the specification ofdecision rulesthrough theCoCo DSL

are used as inputs of a model to text transformation that traduces the feature model elements and the new

defined decision rules into a CSP. TheCSPis traduced in terms of the Java CSP solver,Choco. This

transformation results into a Java class with the CSP implementation, and a main method. When this asset is executed the organization obtains a set of solution decision products. The mapping between the feature model and the CSP was based on the research made by Benavides et al. [24]. Listing 4 illustrates a segment of the generated Choco specification containing the transformations of feature attributes, constraints, and decision rules.

1 int [] Feature = {x,y};

2 model [i][0] = problem.makeEnumIntVar("Feature",

3 Feature);

4 model [i][1] = problem.makeEnumIntVar("VFeature",

5 0, 1);

6 configs.put("Feature",i); 7

8 problem.post(problem.leq(valuesSum, 15000));

9 problem.minimize(valuesSum, false);

Listing 4: Choco implementation generated from CoCo specifications.

First, for features and feature attributes we applied the guidelines proposed by Benavides et al. [24] in whichi)features are set as variables, andii)their domain could betrueorfalse. However, the maximum and minimum magnitudes from the dimension implication associated to a feature attribute are used for creating an additional variableFeature, which defines the implication magnitude finite domain [25] [26].

The minimum valuexis related to the minimum magnitude found on all the feature attributes associated

to the selected dimension; the maximum valueyis calculated by adding the maximum magnitudes from

(30)

Constraint Choco function Feature values

Mandatory and f = 1,∀f ∈children f eatures

Optional or f ={0,1},∀f ∈children f eatures

Or or f = {0,1},∀f ∈children f eatures with at least one selected sibling feature

Alternative ifOnlyIf fs = 1 and fd = 0, such that fs ∈

children f eatures, fd ∈ (children

f eatures\fs)

Children selection implies fc= 1→ fp = 1,such thatfcis

chil-dren of fp

Parent deselection implies fp = 0→ fc= 0,such thatfcis

chil-dren of fp

Requires (p→q) implies p = 1 → q = 1, for any p, q ∈

f eatures

Excludes (p→ ¬q) implies p = 1 → q = 0, for any p, q ∈

f eatures

Table 4.1: Feature model translation into a CSP problem.

and depending on if the feature appears on the configuration set, it will have a domain of {0, 0} or {0, 1}

into the tuple. Finally, with the aim of improving performance, each feature locationiin the matrix is

stored on a Hash Map structure namedconfigs(cf.lines 1-6 in Listing 4).

Second, feature model constraints are translated to Choco following Benavides guidelines, where

iii)relationships among features result into a CSP constraint [24]. Table 4.1 summarizes the proposed

mapping. By this means,mandatoryrelationships are translated into a Chocoandfunction where the

selection of the implicated features of the relationship is mandatory, thus all children should have atrue

selection state (i.e.,feature value equal to 1); optionalrelationships are managed in the same way by

using the Chocoorfunction, and the selection state for all children under the relationship could befalse

(i.e.,feature value equal to 0) or true; the same mapping happens fororrelationships, where at least

one sibling feature should have a value equal to 1; lastly,alternativerelationships supposed the usage

of ChocoifOnlyIf function, where if a child has atrueselection state its siblings should have afalse

state. Furthermore, relationships between parent features selection and deselection should be represented in the Choco CSP. For this reason, each children selection implies its parent selection, and each parent deselection implies its children corresponding deselection. These constraints are represented through

Chocoimpliesfunction. At the same time,requiresandexcludesconstraints are also represented through

Chocoimpliesfunction. For therequiresrelationship the selection of the antecedent implies the selection of the consequent, and for theexcludesrelationship the selection of the antecedent implies the deselection of the consequent. For a further mapping between feature models and CSP refer to Benavides et al. research [24].

Lastly, decision rules for a given attribute type are translated to Choco while usinglt(less than),leq

(less than or equal to), gt(greater than), geq(greater than or equal to), oreq(equal to) functions for

the hard limit expression, andmaximizeorminimizefunctions for the optimization segment. Hence, all

the related attribute type values of each selected feature, should be added to a sum variable,valuesSum, that should respect and conform to the specified constraint (cf.lines 8-9 in Listing 4). For our decision rules specification example (cf.Listing 3), the hard limit rule is specified in line 8 of Listing 4, while the

(31)

optimization rule is defined in line 9. Afterwards, the Choco CSP is executed obtaining the desired set of configurations that solves the stakeholders’ decision conflicts based on the decision rules.

(32)

(33)

Chapter

5

Assessment

This section illustrates the results obtained in terms of: conflicts among configurations resolution based on certain decision scenarios related to costs, time, and human resources dimensions; and the correct attribute types and feature attributes specification over our motivating example, and the corresponding reduction of the feature model complexity.

5.1 Experiment 1: Decision Scenarios for Conflicts Resolution

This experiment was designed to evaluate the effectiveness of the proposed strategy for solving conflicts among configurations during a decision process. With this objective we proposed a set of decision scenarios where the number of stakeholders and the meaning of decision rules varied. Then, the MTC was executed according to these parameters. All decision scenarios were executed on a machine with an Intel(R) Core(TM) i7-4700MQ of 2,40GHz processor, an 8,00GB RAM, and a 64-bit Operating System. The Java Virtual Machine was configured with a maximum memory allocation pool of 3,072MB.

We defined five stakeholders’ configurations over our motivating example. The configurations performed by these stakeholders were merged into one invalid product (cf.refer to Section 4.2.2) through four testing sets: the first set used the merged product between configuration 1 and configuration 2; second set employed the merged product between configuration 1, configuration 2 and configuration 3; third and fourth set used a merged configuration that included configuration 4 and 5 in the same way.

In addition, we considered the three attribute types defined in Listing 1, 30 boundary limits related to each attribute type, and three decision rules of the form:

decisionRule optimizationR1:maximizeattributeTypeId; decisionRule optimizationR2:minimizeattributeTypeId; decisionRule hardLimitR3:attributeTypeIdleqboundaryValue;

Hence, the resulting combination of the four configurations testing sets, the three attributes types, and the 30 boundary limits for each attribute type, resulted in a set of decision scenarios (e.g.,for thefirst configuration testing setapply the optimization rule to theCosts01attribute type, with a hard limit rule

(34)

1 10 100 1000 10000 100000 1000000 10000000 So lu ti o n D eci si o n Produ ct Cost (U SD )

Decision Rule Cost Restriction (USD)

1 10 100

1 2 3-9 10 11 12 13 14-19 20 21 22 23 24-29 30

Sol u ti o n D ecisio n P ro d u ct H R (Peop le)

Decision Rule HR Restricton (People)

Maximum Minimum

Figure 5.1: Decision rules over costs and human resources dimensions.

The boundary limits related to the three attribute types were defined based on the sum of the feature

model maximum values related to each attribute type, presented in Section 1.2. In particular,Costs01

attribute type had an initial restriction value of 250.000 USD with and incremental interval of 250.000

USD. Hence, the 30th costs restriction value was defined to 7.500.000 USD.Time01attribute type had an

initial restriction of four hours as well as an incremental interval of four hours.HR01attribute type had an initial restriction of one person and an incremental interval of one person. For each decision scenario, there were measured four different aspects: configuration total value related to the specified attribute type that minimizes the restriction, and configuration total value related to the specified attribute type that maximizes the restriction.

The resulting configurations total value related to bothCosts01andHumanResources01attribute types

are shown on the logarithmic graph shown in Figure 5.1. The cases in which there was no solution or the solver was not able to give an answer are unmarked in the graph for each series. To understand the values presented in this Figure, we analyze the results highlighted over each chart with a purple circle. The solid outlined circle represents the value related to the configuration that maximizes the restriction, whereas the dotted circle represents the product that minimizes the decision rule. Both elements apply only to the series of 2 configurations (i.e.,the first configurations testing set). Thus, for theCosts01attribute type the suggested decision configuration had a maximum cost of 250.000 USD and a minimum cost of 300

USD; and for theHR01attribute type the product that maximizes the total value had a magnitude of three

people and a product with a minimum magnitude of two people. In this case, the investment decisions fulfill the business restrictions. For theTime01attribute type all sets had the same behavior: from 4 to 32 hours there did not exist a solution (based on the feature attributes associated to each decision); from 36 to 120 hours the maximum and minimum configuration had a value of 36 hours for the four configurations testing sets.

(35)

confor-mance to the feature model constraints. This result was obtained for all three attribute types. Furthermore, the resulting products also conformed to the defined decision rules. If there did not exist a product that satisfied the applied decision rule, the solver did not returned a configuration which was the expected behavior. Nonetheless, for certain decision scenarios, the solver overtook the limit of time to give an answer obtaining an exception, and obtaining no solution at all.

5.2 Experiment 2: Non-functional Properties Specification and

Feature Model Complexity

This experiment was executed with the objective of generating an extended feature model from the motivating example presented in Section 1.2, while applying the presented strategy. We evaluate the correct creation of the respective attribute types and feature attributes related to the feature model while applying the proposed strategy. For our motivating example we followed the alternative 2 path (cf.Section 4.2). Table 5.1 illustrates the differences among the input standard feature model and the output extended feature model. The extended solution had a 61,75% reduction of features, a 63,66% reduction on decision options, and 93,23% reduction on cross-tree constraints. Meanwhile, there were created 178 features attributes with their 23 corresponding attributes types.

Elements of the Feature Model Baseline model Generated model Delta

Features 366 140 61,75%

Decision options 344 125 63,66%

Cross-tree constraints 192 13 93,23%

Feature attributes 0 178 NA

Attribute types 0 23 NA

Table 5.1: Differences between the standard and the extended feature model.

According to the obtained results, the strategy implementation allowed the introduction of feature attributes over a previous defined standard feature model. In that way, decision options were enriched with non-functional properties that are the base for using decision rules in a conflicts among configurations resolution path. At the same time, when reducing the number of features and the cross-tree constraints that relate them, the model reduces its size favoring the maintenance of its components. Particularly, features and cross-tree constraints maintenance is favored while all implication are transformed to feature attributes. The introduction or deletion of feature attributes is simpler and decoupled avoiding the modification of both cross-tree constraints and features; if an implication changes the modeler should change just the corresponding feature attribute, and not a the feature and the cross-tree constraint that represent the named implication.

(36)

(37)

Chapter

6

Related Work

As it was earlier defined, there have been multiple research projects focused on creating conflict avoidance strategies as well as conflicts resolution approaches. The first approach type could be specialized by using decisions propagation while configuring products. Conflict avoidance does not allow the introduction of inconsistencies during the decision-making process, and simultaneous or non-sequential configurations are not allowed. This last property is a notable difference from our proposal. The second approach tolerates inconsistencies with the objective of using them for a conflict resolution strategy possibly based on the usage of a solver. For both scenarios we would like to highlight the work made on seven different research projects.

On the conflict avoidance scenario, Mendonça et al. [4] developed a domain-specific propagation algorithm for feature diagrams that provides unit propagation and forward checking (i.e.,given a specific context, the algorithm computes a value in a boolean domain that reflects the selection state of an un-instantiated feature). The propagation is done each time the modeler defines the selection state for a particular feature, which result into a non-conflicting configuration.

Over the same scenario, Chavarriaga et al. allow the configuration of decision products over multiple feature models [3]. In that way, each stakeholder decides over its own domain or model, though their decisions impact other existing models over the decision scope. A Feature-Solution Graph (FSG) is used

to relate features among models by means ofprohibitsandforcesrelationships. Forces relations oblige

the selection of a feature in a different model, while prohibits forbids the selection of an option. Therefore, while stakeholders are configuring their products, features are marked as non-selectable or mandatory depending on the defined relation over the FSG. Simultaneously, there exists an algorithm that supports conflict explanation through the decision propagation process.

The last research related to this first approach is the one presented by Czarnecki et al. They proposed the application of staged configurations, which are implemented through feature model specialization or multi-level configuration. In this proposal roles and decision responsibilities are delegated to each stakeholder. Each stakeholder decision could impact others configurations in a well-defined stage, or in a certain unit of time of a sequential decision [16].

On the conflict resolution scenario there are different approaches. Nöhrer et al. propose four strategies for tolerating inconsistencies during decision-making process, while using a SAT solver. By this means, the introduction of inconsistencies over decision configurations are allowed without propagating the selected choices [6]. Nevertheless, they propose a manual resolution based on the SAT strategies where users fix the identified conflicts, which supposes a time consuming task where conflicts are automatically

(38)

detected but conflicts resolution needs stakeholders’ intervention.

Moreover, White et al. presents a constraint-based diagnostic approach that focuses on solving invalid configuration conflicts by minimizing the set of selected features (fi = 1) and deselected features (fi = 0) from the flawed configuration possible resulting from stakeholders’ parallel decisions. This work is known as Configuration Understanding and Remedy (CURE) which is implemented in four steps: feature model translation into a CSP, conflicting features identification, recommendations of features selection and/or deselection in order to create a valid configuration, and valid product generation [9]. However, the resolution proposal is not based on non-functional properties that could represent the overall business interests.

Another conflict resolution scenario could be found at Benavides et al. research. They present a framework named FAMA that combines multiple solvers (SAT, CSP, BDD) on runtime to improve the performance for analyzing standard and extended feature models. However, its API does not include the identification of inconsistencies and conflicts among configurations over extended feature models, and the resolution strategy should be implemented at a low level of abstraction [8]. Furthermore, there is another research proposal related to the same main author, which aims to translate cardinality-based features into a CSP problem with the objective of calculating number of valid configurations and detecting possible conflicts. They implement their solution using two Java CSP solvers, JaCoP and Choco [5].

Finally, on the inconsistencies tolerant context, Machado et al. proposed SPLConfig, an Eclipse plugin that uses FeatureIDE capabilities in order to derive an optimal product based on customer budget and other non-functional requirements. In that way, they extend feature models with non-functional requirements, and using search-based software engineering (SBSE) they propose an automatic product configuration method [27]. Nonetheless, they do not propose a conflict resolution tool, instead it is about an automatic product configuration process.

All the last four conflict-tolerant approaches do not consider a conflicts resolution based on the com-plete set of stakeholders’ configurations, which supposes a lost on specialized knowledge. Furthermore, they do not consider the definition of objective organization criteria, which responds to business needs and defines guidelines during the conflicts resolution path.

Using decision rules in software product lines for configuration conflicts resolution