Dhungana Et Al-configuration of Cardinality-based Feature Models Using GCSP

7/31/2019 Dhungana Et Al-configuration of Cardinality-based Feature Models Using GCSP

1/4

Configuration of Cardinality-based Feature Models

using Generative Constraint Satisfaction

Deepak Dhungana, Andreas Falkner, Alois Haselbock

Siemens AG Osterreich

Corporate Technology, Vienna, Austria

{deepak.dhungana, andreas.a.falkner, alois.haselboeck} @ siemens.com

AbstractExisting feature modeling approaches and tools arebased on classical constraint satisfaction which consists of afixed set of variables and a fixed set of constraints on thesevariables. In many applications however, features may not onlybe selected but cloned so that the numbers of involved variablesand constraints are not known from the beginning. We presenta novel configuration approach for corresponding cardinality-based feature models based on the formalism of generative

constraint satisfaction which - in extension to many existingapproaches - is able to handle constraints in the context ofmultiple (cloned) features (e.g., by automatically creating newfeature clones on the fly).

I. INTRODUCTION

Software product line engineering (SPLE) has established

itself as a standard practice for exploiting the commonalities

among a family of products and managing the variabilities

among them in a systematic way [1]. Configuration of indi-

vidual products is often based on variability models. Among

others, feature modeling (FM) [2] is particulary popular. FM

approaches commonly use reasoning techniques based on

propositional formulae [3] or constraint satisfaction problems

(CSP) [4].They are highly successful in domains with statically de-

fined trees of features which can be selected for the final

product. In many products, however, some features can be

selected not only once but several times, i.e. cloned, and the

subfeatures of each feature may be configured differently,

like the rooms in a house may be furnished differently.

Such requirements can be handled with Generative Constraint

Satisfaction (GCSP) [5] which overcomes the limitations of

classical CSP by incrementally introducing additional vari-

ables and constraints when features are added to satisfy a

constraint.

This paper presents a novel approach for configuring

cardinality-based feature models (CFM) based on GCSP. The

features, as they are modeled in a FM, are seen as components(variable schemata) and constraints are specified as constraint

schemata (generic constraints). GCSP is a robust and powerful

tool for representing and solving complex configuration prob-

lems. Moving from static to cardinality-based feature models

means moving close to a general configuration problem, and

therefore GCSP is well-suited for handling such CFMs.

There are few systems which support feature instances

in a cardinality-based feature model in a clean way. Two

of them are Clafer [6], which uses Alloy as underlying

reasoning mechanism, and Forfamel [7], which uses answer set

programming (smodels) for reasoning. In another cardinality-

based approach [8], global constraints (constraints between

features in different parts of a feature diagram) are checked

by translating a feature model into XML Schema and XSLT

rules encoding global constraints.

I I . CARDINALITY-BASED FEATURE MODELS AND EXAMPLECzarnecki et. al. [9] and Riebisch et. al. [10] proposed

cardinality-based feature models where cardinalities were in-

troduced. These models integrate a number of extensions to

the original FODA [2] notation.

In conventional feature models, configuration is done by

feature selection and results in a subset of features (satis-

fying the constraints) in the model. This is not sufficient in

cardinality-based feature models, as the configuration may

instantiate multiple feature instances. The result of the con-

figuration is therefore a set of feature instances satisfying

generic constraints, where the subtree of each instance can

be configured differently. Please refer to the original work [9]

for more details.In the following, we use a small example to show the main

challenges of cardinality-based feature modeling. Figure 1

represents part of a feature model for a smart home. It uses

the notation of [9], extended with a special symbol for type

groups and dashed arrows to symbolize additional (cross-tree)

constraints.

A smart home is a computer-assisted housing unit. De-

pendent on the requirements of the owner, it is outfitted for

home automation. The result of the configuration depends on

the number of rooms which shall be equipped with room-

specific features. This means that the feature model grows

as the number of equipped rooms grows, thus imposing two

challenges: multiplicity of features and generic constraints.

A. Multiplicity of features

As depicted in Figure 1, one of the key features of a

SmartHome is a SmartRoom. A SmartRoom is a room which

contains home-automation features such as LightsControl.

Each room has an automatic and/or a manual mode for control-

ling lights (LightsControl) in the room. Automatic operation is

supplied by an arbitrary number of motion detection (Motion),

manual control by any number of switches (LightSwitch).

These functional features require sensors to work. The sensors

2011 37th EUROMICRO Conference on Software Engineering and Advanced Applications

978-0-7695-4488-5/11 $26.00 2011 IEEE

DOI 10.1109/SEAA.2011.24

100


978-0-7695-4488-5/11 $26.00 2011 IEEE

DOI 10.1109/SEAA.2011.24

100


978-0-7695-4488-5/11 $26.00 2011 IEEE

DOI 10.1109/SEAA.2011.24

100


2/4

Fig. 1. Example feature model of a smart home, depicting feature cardinal-ities and generic constraints (to be instantiated for each feature instance).

are modeled as features, too: each sensor is either a light sensor

(Light) or a movement detector (Movement), the latter one

having a subfeature for infra-red (IR) detection.

The number of rooms is unbounded in a house. Each

room can be configured differently (i.e. equiped with different

features). Therefore, a smart home cannot be modeled with

conventional feature models except for assuming some upper

bound (which might not hold) and massive duplication of

subfeatures. Building a feature model for each room separately

is not sufficient, either, as it cannot cover global constraintslike C3 of our example (the selection of a sensor in any

room requires a control unit in the smart home). Even worse,

multiplicity could occur on any level - e.g. different sensor

configuration.

B. Generic constraints

In constrast to a conventional feature model where each

feature corresponds to only one instance, in a cardinality-

based feature model there can be several different instances

for a feature. Therefore a constraint on a feature does no

longer simply apply to its only instance. Rather, it can refer

either to the feature type, or to all instances, or to instances in

some given context. Therefore the meaning of constraints must

be defined exactly - like in subsection III.A(iv). The activeconstraints are generic in a way that they are not known stati-

cally but have to be instantiated (generated) dynamically at

runtime together with the instances of multiple features. This

constraint instantiation corresponds to quantification (x : . . .)in predicate logic.

(i) The example in Figure 1 shows how some of the

cardinality constraints can be modeled directly in the FM, e.g.

- A SmartHome contains at least one SmartRoom.

- Each SmartRoom contains at most 10 Sensors.

Czarnecki et.al [9] define feature cardinality such that it

denotes how many instances of a feature (with its entire

subtree) can be included as children of the features par-

ent when specifying a concrete configuration. Cardinality is

an interval of the form [m..n], where, m and n are non-negative integers denoting minimum and maximum number

of instances allowed. [0..1] denotes optional features, [1..1]denotes mandatory features, and [0..] denotes unconstrainedfeatures. By that, the basic structure of a feature model is a

tree of subfeatures with cardinalities. The cardinality of the

parent feature is always [1..1].(ii) The group cardinalities, too, are represented like in [9]

except for constraints with type cardinalities.

G1: Each Sensor is either a Movement or a Light detector

(i.e. an alternative).

G2: The instances of subfeatures ofLightsControl must

be from at least one and at most two of its types

(Motion, or LightSwitch).

(iii) Other cardinality constraints are cross-tree dependen-cies and can be depicted by dashed lines.

C1: Each SmartRoom contains at most 2 Light sensors.

C2: Each SmartRoom requires as many IR sensors as

Motion features for the lights control. An alternative

formulation is: Each Motion feature requires a dis-

tinct Movement feature (with IR) in the same room.

C3: Each Sensor requires at least one ControlUnit (which

may be used by different sensors).

III. FEATURE MODELING WITH GCSP

A. Generative constraint satisfaction for CFM

Generative constraint satisfaction (GCSP) is an extension of

classical CSP designed to cope with dynamic aspects arisingin many technical application domains, like configuration,

design, or planning. Classical CSP represents a problem by a

fixed set of variables, their domains and constraints, which is

usually not appropriate if the number of variables in a solution

is not known at modeling time. The most prominent extensions

of the classical CSP schema towards a more dynamic view are

Conditional CSP [11], Dynamic CSP [12], and - as used in

this work - Generative CSP [5], [13].

GCSP was originally designed for representing and solving

large-scale, complex configuration problems and is therefore a

powerful and highly expressive framework. Besides constraint

satisfaction, the main background of GCSP is the object-

oriented paradigm with its clean separation of the problemmodel and the problem instance. Because of space restrictions,

here we sketch only that fragment of GCSP which is necessary

for feature models with multiplicity.

(i) The knowledge base (KB) stands for the specification of

the domain of discourse (i.e. the problem model), representing

all possible concrete instances. It is a tuple

KB = TKB , AKB , CKB

101101101


3/4

where TKB is a set of component types, AKB is a set ofassociation schemata, and CKB is a set of constraint schemata.Constraint schemata restrict the set of valid configurations -

we define them in paragraph (iv). Each association schema is

a tuple

t1, t2,min2,max2

t1, t2 are component types from TKB

0 min2 max2 are cardinalities

(we use * for not restricted in max2)

The rectangles (types) and lines (associations) with cardi-

nalities in Figure 1 represent the KB in an UML-like format.

(ii) A configuration (i.e. a problem instance) is a concrete

set of objects, instantiating structure and constraints defined

in the knowledge base. It is a tuple

CONF = TI, AI, CI

where TI is the set of all components (instances) in theconfiguration, AI is the set of associations between the com-ponents, and CI are the constraint instances. Each component

has a unique type. TI/t denotes the set of components oftype t.

(iii) For each association schema t1, t2, min2, max2 inthe knowledge base, and for each cobj1 TI/t1 and cobj2 TI/t2 in CONF, the following association constraints arein C:

min2 |cobj1.t2| max2

|cobj2.t1| = 1

cobj1 cobj2.t1 cobj2 cobj1.t2

Whenever a new component instance is created (or deleted),

its associations and constraints are created (or deleted), too.

(iv) Like the other constraints, consistency constraints are

Boolean expressions which reduce the set of possible solu-tions. Since we dont have concrete components in our KB,

but component types, we cannot define concrete constraints,

but constraint schemata.

CKB is the set of constraint schemata. A constraint schemafor a component type t TKB has the form

cobj : cobj.type = t p(t)

p(t) is a Boolean expression evaluating to true or false in aconcrete configuration. We allow the following syntax for the

expression p(t):Let S, S1, S2 be sets of components from T

I (we write Sfor S(t)). Let min, max be non-negative integers. Let r bea role name of an association in AKB (i.e. the name of an

associated component type - t1 or t2).

p(t) ::= |S|maxmin| |S1| = |S2|

S ::= t.r

| S1.r

| S1[i]

| S1 S2 | S1 S2 | S1 S2

Interpretation:

- The expression |S|maxmin constrains the cardinality of thegiven set. It is said to be satisfied, if and only if the

number of components in S is greater or equal than minand less or equal than max.

- The expression |S1| = |S2| is satisfied, if and only if thetwo sets S1 and S2 have the same number of members.

- The expression t.r represents the set of components of theassociation t.r. If r is not a valid role of t, this evaluatesto the empty set.

- The expression S.r represents the set of all componentsreachable from the components in S via the role r:cS

c.r- The expression S[i] for a positive integer i represents the

set containing the ith component of S. If S is empty orhas less than i elements, this evaluates to the empty set.

- , and are the standard set union, intersection andsubtraction.

(v) For defining consistency of a configuration CONFbased on a knowledge base KB, we induce a classical

CSP V, C for it, where the variables V correspond to theassociations AI in CONF, and C to its constraints CI. Theconfiguration is consistent if and only if its induced CSP is

satisfied - i.e., all its variables have values from their domains

and all its association constraints and consistency constraints

are satisfied.

B. Example KB of the GCSP

The mapping from CFM to GCSP is straight-forward:

Features are component types, feature-subfeature relations

(incl. their cardinalities) are associations, group cardinalities

and cross-tree dependencies are modeled as consistency con-

straints.

The example CFM of Section II (Figure 1) can be repre-

sented by a GCSP in the following way:

TKB = {SmartHome, SmartRoom, ControlUnit,

LightsControl, Motion,LightSwitch,

Sensor, Movement, Light}

AKB = {

SmartHome, SmartRoom, 1, ,

SmartHome, ControlUnit, 1, ,

SmartRoom, LightsControl, 0, 1,

. . .}

CKB = {G1, G2, C1, C2, C3}

Group cardinality constraints:

G1 : s : s.type = Sensor

| s.Movement s.Light |11

G2 : l : l.type = LightsControl

| l.Darkness[1] l.Motion[1] l.LightSwitch[1] |21

The general pattern for consistency constraints is to specify

the cardinality restrictions of a subset of all features, starting

102102102


4/4

from a certain feature. Since all features in the tree are

connected via child-parent paths, navigation from a starting

feature to all other features is always possible:

// C1: Each SmartRoom contains at most 2 light sensors.

r : r.type = SmartRoom | r.Sensor.Light |20

// C2: Same number of IRs as Motion controls.r : r.type = SmartRoom

| r.LightsControl.Motion | =

| r.Sensor.Movement.IR |

// C3: A Sensor requires a ConstrolUnit.

s : s.type = Sensor

| s.SmartRoom.SmartHome.ControlUnit |1

IV. REASONING WITH GCSP

Declarative representation of both model and instances

allows for various interesting reasoning tasks. As suggested

in [9], a KB can be analyzed by consistency algorithms forchecking consistency, detecting anomalies, computing metrics,

or finding all features which must be present in every solution.

The process of configuring a product is usually a semi-

interactive task: The user selects (or - in case of feature models

with multiplicities - instantiates) one or more features, then a

solver automatically derives some knowledge, which can be:

- Which features are additionally needed?

- Which features are now forbidden?

- Is it possible to complete the current product fragment to

a solution, at all?

Then the user selects features again, and so forth. The

user makes the decisions, and the reasoning system guides

him/her through the configuration process and enforces theconsistency of the final configuration. The solver can either

compute possible repair actions, or it provides explanations

so that the user can easily identify the features in conflict and

can repair them manually.

Reasoning performance is, of course, a challenge. To decide,

in general, whether a classical (static) CSP has a solution, is

NP-complete. Since we extended classical CSP to a dynamic

version, reasoning gets even more challenging. CSP or SAT

solvers, which are highly efficient and often used for static

features models, cannot be applied directly to our dynamic

systems. Attempts to adapt these approaches to a dynamic

behavior are, e.g.:

- Artificially limit the number of possible instances of eachcomponent type to make the problem static.

- Extend static algorithms (e.g. backtracking) to cope with

dynamic situations.

- Use local propagation or search algorithms to locally

repair/expand a partial configuration.

GCSP-based configurators in areas like telecommunication

or railway systems have shown that local propagation is

highly efficient and can therefore be used in an interactive

environment (requiring a response time below 1 second) - even

for complex configurations with thousands of components.

V. CONCLUSION AND FUTURE WORK

The main contribution of this paper is the exploitation of

synergies between generative configuration satisfaction sys-

tems and multiplicities in cardinality-based feature modeling.

In particular, we provide a sound theory for configuration offeature models with multiplicities based on GCSP.

We have developed tool support (consistency checking,

auto-completion) for this work. Due to space restriction, those

results will be published later. We are currently working on

additional types of constraint expressions and on performance

analysis of GCSP reasoning for very large feature models.

ACKNOWLEDEGMENTS

This research is co-funded BMVIT and by the FFG within theproject RECONCILE in the programme FIT-IT Semantic Systems(grant number 825071). We are very grateful for the valuable com-ments from Krzysztof Czarnecki on an earlier version of this paper.

REFERENCES

[1] P. Clements and L. Northrop, Software Product Lines: Practices andPatterns, ser. SEI Series in Software Engineering. AddisonWesley,Aug. 2001.

[2] K. Kang, S. Cohen, J. Hess, W. Novak, and S. Peterson, FeatureOriented Domain Analysis (FODA) Feasibility Study, Software Engi-neering Institute, Carnegie Mellon University, Tech. Rep. CMU/SEI-90-TR-21, Nov. 1990.

[3] D. Batory, Feature models, grammars, and propositional formulas,in SPLC 2005, ser. Lecture Notes in Computer Sciences, vol. 3714.SpringerVerlag, 2005, pp. 720.

[4] D. Benavides, S. Segura, P. Trinidad, and A. R. Cortes, FAMA: Toolinga framework for the automated analysis of feature models, in VaMoS,2007, pp. 129134.

[5] G. Fleischanderl, G. Friedrich, A. Haselbock, H. Schreiner, andM. Stumptner, Configuring large systems using generative constraintsatisfaction, IEEE Intelligent Systems, vol. 13, no. 4, pp. 5968, 1998.

[6] K. Bak, K. Czarnecki, and A. Wasowski, Feature and meta-models in

clafer: Mixed, specialized, and coupled, in SLE, 2010, pp. 102122.[7] T. Asikainen, T. Mannisto, and T. Soininen, A unified conceptual

foundation for feature modelling, in SPLC, 2006, pp. 3140.[8] V. Cechticky, A. Pasetti, O. Rohlik, and W. Schaufelberger, Xml-based

feature modelling, in Software Reuse: Methods, Techniques and Tools:8th International Conference, ICSR 2004. Springer-Verlag, 2004, pp.59.

[9] K. Czarnecki and C. H. P. Kim, Cardinality-based feature modelingand constraints: A progress report, 2005.

[10] M. Riebisch, K. Bllert, D. Streitferdt, and I. Philippow, Extendingfeature diagrams with uml multiplicities, in Integrated Design andProcess Technology, 2002.

[11] S. Mittal and B. Falkenhainer, Dynamic constraint satisfaction prob-lems, in AAAI, 1990, pp. 2532.

[12] R. Dechter and A. Dechter, Belief maintenance in dynamic constraintnetworks, in AAAI, 1988, pp. 3742.

[13] A. Felfernig, G. Friedrich, D. Jannach, M. Stumptner, and M. Zanker,Configuration knowledge representations for semantic web applica-

tions, AI EDAM, vol. 17, no. 1, pp. 3150, 2003.

103103103

Dhungana Et Al-configuration of Cardinality-based Feature Models Using GCSP

Documents

Transcript of Dhungana Et Al-configuration of Cardinality-based Feature Models Using GCSP