Yamuna Dhungana Supervisor : Dr. R.M.A.P. Rajatheva May 16, 2011.
Dhungana Et Al-configuration of Cardinality-based Feature Models Using GCSP
Transcript of 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
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
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
-
7/31/2019 Dhungana Et Al-configuration of Cardinality-based Feature Models Using GCSP
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
-
7/31/2019 Dhungana Et Al-configuration of Cardinality-based Feature Models Using GCSP
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
-
7/31/2019 Dhungana Et Al-configuration of Cardinality-based Feature Models Using GCSP
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