See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/220744172

A Propositional Logic-Based Method for Verification of

Feature Models

Conference Paper · November 2004

DOI: 10.1007/978-3-540-30482-1_16 · Source: DBLP

CITATIONS READS
131 652

3 authors:

Wei Zhang Haiyan Zhao

Peking University Peking University
71 PUBLICATIONS 1,146 CITATIONS 114 PUBLICATIONS 1,416 CITATIONS

SEE PROFILE SEE PROFILE

Hong Mei
Xi'an Jiaotong University
314 PUBLICATIONS 8,015 CITATIONS

SEE PROFILE

All content following this page was uploaded by Wei Zhang on 09 October 2014.

The user has requested enhancement of the downloaded file.

 A Propositional Logic-Based Method for
Verification of Feature Models

Wei Zhang, Haiyan Zhao, and Hong Mei

Institute of Software,
School of Electronics Engineering and Computer Science,
Peking University, Beijing, 100871, China
{zhangw, zhhy}@sei.pku.edu.cn, [email protected]

Abstract. The feature model is a domain/product-line oriented requirements

model based on hierarchical structure and explicit variability modeling, and has
been adopted by several important software reuse methods. However, with
respect to the problem of verification of constraints on features and verification
of partially customized feature models, these methods tend to be semi-formal
and offer little formal assistance. In this paper, we propose a propositional
logic-based method for the verification of feature models at different binding
times. The most important characteristic of this method is that it integrates the
logical verification with binding times, which makes it can be used to verify
any partially customized feature models at any binding time (except run-time).
In this method, constraints on features are formalized by logical sentences.
Thus, the verification of feature models is converted into satisfaction problems
in the logic. With this formal method, verification problems such as the
detection of inconsistent constraints or the detection of conflicting or
unnecessary binding resolutions can be automatically revealed.

1 Introduction

One practical approach to software reuse is to produce general purpose (i.e., reusable)
software artifacts, followed by customization to accommodate different situations. To
facilitate the customization of reusable software artifacts, elements in these artifacts
should be cohesive enough, and dependencies between elements should be specified
clearly.
Feature-oriented methods [1,2,3,4] have been proposed to improve the
customization of the problem space of software. These methods treat features as the
basic elements in the problem space, and use features, relationships (i.e. refinements
and constraints) between features (called feature model) to structure the problem
space. In the development for reuse phase [5, 9], a domain feature model is first
constructed by exploring commonality and variability in a software domain. Then, in
the later development with reuse phase, the domain feature model is customized into
application feature models according to different reuse contexts. Those still undecided
features in application feature models will be gradually bound or removed through a
series of binding times (e.g. compile-time, install-time, load-time, and run-time).

J. Davies et al. (Eds.): ICFEM 2004, LNCS 3308, pp. 115–130, 2004.
c Springer-Verlag Berlin Heidelberg 2004


116 W. Zhang, H. Zhao, and H. Mei

Constraints specified in the domain feature model then provide criteria to verify the
completeness and consistency of those customized feature models. In such a way,
customization of the domain feature model is operated.
However, as far as we know, all these feature-oriented methods lack effective
measures to verify partially customized feature models. A real customization process
often includes a series of binding times, in each of which, certain customizing
resolutions are decided and a partially customized feature model is obtained. The
inability to verify partially customized feature models increases the difficulty of
customization. As feature models become larger and constraints on features become
more complex, the cost of constraints modeling and maintenance will also increase
considerably. In addition, constraints defined by these methods currently are too
simple to describe complex constraints involving three or more features.
In this paper, we propose a propositional logic-based method for the verification
of feature models at different binding times. In this method, the statement “a feature is
in the bound state” is regard as a two-value proposition in the logic. These
propositions can further be combined with basic logical connectives to represent
complex constraints on features. By this way, constraints in a feature model are
formalized by a set of logical sentences. Then, at each binding time, after an
undecided feature is bound or removed, the truth value of this feature will become the
logical constant True or False respectively. Thus, the verification of feature models is
converted into satisfaction problems in the logic. Therefore, verification problems
such as the detection of inconsistent constraints or the detection of conflicting or
unnecessary binding resolutions can be automatically revealed.
The rest of this paper is organized as follows. Basic knowledge about feature
models is given in Section 2. Section 3 presents a propositional logic based
verification method in detail. Two case studies are illustrated in Section 4. Related
work is discussed in Section 5. Finally, Section 6 concludes this paper with a short
summary.

2 Context: A Metamodel of Feature Models

The focus of this paper is on the verification of feature models. Hence, we need to
first give an introduction about feature models. In the remainder of this section, we
introduce a metamodel of feature models. The content of this section is mainly based on
our previous work on feature modeling [12] and other related literature [1, 2, 3, 4, 7].
Figure 1 shows a metamodel of feature models. This metamodel consists of three
basic concepts: Feature, Refinement, and Constraint. All these concepts are subclasses
of the two concepts: Classifier and Relationship in UML Core Package [22].

2.1 Feature

A feature describes a product characteristic from user or customer views [2, 16],
which essentially consists of a cohesive set of individual requirements [17, 18, 19]. In
feature models, a feature is characterized by a set of attributes: name, description,
optionality, binding-time and binding-state.
 A Propositional Logic-Based Method for Verification of Feature Models 117

Classifier Decomposition
+requirer
Require 1 Feature
*
* 1 +parent
Constraint Detailization
* Refinement
+requiree name 1
Exclude description 1 0..1
* 2 optionality
1..2 +child 0..1
binding-time
Specialization
ComplexConstraint binding-state
*
1..*
Relationship

Fig. 1. A MetaModel of Feature Models

Name is a short character string. Its main purpose is to facilitate the

communication between stakeholders. In this paper, we also use the name of a feature
to denote the logic proposition of “this feature is in the bound state”. Description is a
detailed representation of a feature.
Optionality describes whether a feature has the chance to be removed from the
current feature model when its parent feature (if has) has been bound. This attribute
has two values: mandatory and optional.
Binding-time is an attribute related to optional features. It describes a phase in the
software life-cycle when an optional feature should either be bound or removed form
the current feature model. Typical binding-times include reuse-time, compile-time,
deploy-time, load-time, and run-time.
The attribute binding-state has three values: bound, removed and undecided. A
bound feature means that if its trigger conditions and pre-conditions are satisfied, this
feature will be executed. A removed feature means that it will never be bound
again.An undecided feature means that it is currently not in the bound state, but still
has the chance to be bound or removed in later binding-times. In this paper, we use
“tailoring” to denote the action of changing a feature’s binding-state from undecided
to removed, use “binding” to denote the action of changing a feature’s binding-state
from undecided to bound, and also use “binding resolution” to denote the decision of
whether to bind or tailor a feature from the current feature model in a specific
binding-time.

Table 1. Explanation of Feature Attributes

Attribute Description Value Range

name The denotation of a feature possible meaningful character strings
The detailed representation of a feature
description {informal, semi-formal, formal}
Whether a feature must also be bound when its
optionality parent feature is bound {mandatory, optional}

The phase when a feature must be bound or {construct-time, reuse-time, compile-

binding-time
removed time, install-time, load-time}
Whether a feature has been bound or removed,
binding-state or is waiting for being decided {bound, removed, undecided}
118 W. Zhang, H. Zhao, and H. Mei

A concise explanation of these attributes is given in Table 1. Further information

about feature model construction and feature description can be found in [12, 1, 3, 14]
and [13, 15].

2.2 Refinement

Refinement is a subclass of Relationship and has three subclasses: decomposition,

detailization and specialization. Through refinements, features with different abstract
levels and granularities form a hierarchy structure.

Fig. 2. Examples of decomposition, detailization and specialization

Refining a feature into its constituent features is called decomposition [1]. For
example, the edit feature in many software systems is often decomposed into three
sub-features: copy, paste and delete (see Fig. 2). Refining a feature by identifying its
attribute features is called detailization. For example, in graph editor domain, the
graph-move feature can be detailized by two attribute features: moving-mode and
moving-constraint. The difference between decomposition and detailization is often
omitted by most feature modeling methods, but the distinguishing between them does
have necessity for binding resolutions verification, because of the different constraints
implied by them: a fully decomposed feature must be removed if all its constituent
features have been removed; while a feature may still be bound, even if all its
attribute features have been removed. Refining a general feature into a feature
incorporating further details is called specialization [1]. Specialization is often used to
represent a set of variants of a general feature in feature models. A general feature is
also called a variation point feature (vp-feature) in [3].
Features with different abstract levels and granularities form a hierarchy structure
through refinement relationships between them. More strictly, most feature modeling
methods limit this hierarchy structure to be one or more feature trees. This limitation
contributes to the simplicity and understandability of feature models. [20] and [21]
present guidelines on transforming general structures into tree structures and
maintaining tree structures in feature modeling process.

2.3 Constraint

Constraint captures static dependencies between features. And these dependencies

must be satisfied when customizing feature models. In other words, constraints provide
 A Propositional Logic-Based Method for Verification of Feature Models 119

criteria to verify the results of customization of feature models (i.e. application

feature models). Only those results that don’t violate constraints on features are the
candidates of valid application feature models.
Require and exclude are two kinds of binary constraint on features [1]. For
features A and B, “A require B” indicates the rule that B cannot be removed from the
current feature model when A hasn’t been removed. “A exclude B” means that the
two features can not coexist in a same context.
Besides binary constraints require and exclude, this metamodel also define two
kinds of ComplexConstraint on a set of features: GroupConstraint and
CompositeConstraint (Figure 3).

ComplexConstraint
ComplexConstraint

1..*
2
GroupConstraint CompositeConstraint BindingPredicate
GroupConstraint CompositeConstraint BindingPredicate

Mutex-Group None-Group All-Group Single-Bound Multiple-Bound All-Bound

Mutex-Group None-Group All-Group Single-Bound Multiple-Bound All-Bound
0..* 0..* 0..* 0..* 0..* 0..*

1..* 1..* 1..* 1..* 1..* 1..*

Entity
Entity

Fig. 3. Complex Constraints

GroupConstraint is a kind of constraint on a set of feature. It has three subclasses:

Mutex-Group, None-Group and All-Group. Mutex-Group indicates that there is an
exclude constraint on any two elements in a feature set. None-Group means there is
no require and exclude constraints on any two elements in a feature set. Thus, features
in a None-Group set can be bound or unbound freely without considering the binding-
state of other features in this set. All-Group indicates a kind of strong constraint on a
feature set: features in this set must be all in the bound state, or all in the unbound state.
CompositeConstraint is a kind of constraint on two feature sets, and the two
feature sets themselves are constrained by some kinds of GroupConstraint. For
example, binding one feature in a Mutex-Group set may require binding one or more
features in another None-Group set. To represent such kind of constraint, we need to
define three binding predicates corresponding to the three GroupConstraints
respectively. For a Mutex-Group set, there are two possible binding results which
satisfy the Mutex-Group constraint. One result is that no feature in the set is in the
bound state, the other is that only one feature in the set is in the bound state. Hence,
the predicate single-bound is derived to indicate whether no feature or exactly one
feature in a feature set is in the bound state. Similarly, predicates multiple-bound and
all-bound can be derived from None-Group and All-Group.
120 W. Zhang, H. Zhao, and H. Mei

Basic Constraints: (require) (mutual require) (exclude) Example

Constraints:
Group Constraints: (Mutex-Group) (None-Group) (All-Group) A require E, C exclude Fˈ
Mutex-Group(A, B, C),
single-bound(A, B, C) require D.
Binding Predicates: (single-bound) (multiple-bound) (all-bound)
Visual Notation:
Composite Constraints:

Fig. 4. Visual Constraint Notation

By composing single-bound, multiple-bound and all-bound with require or

exclude, we thus can represent constraints on two feature sets. If considering the
mutual require constraint, there are totally 27 kinds of CompositeConstraint.
For convenience of constraint modeling, we develop a visual constraint notation
(Figure 4), to represent all aforementioned constraints in a graphical manner. This
notation has been supported by our feature modeling tool. It is also used in the
remainder of this paper to represent constraints on features.
It should be noticed that refinements between features implicitly impose one or
two constraints on the parent feature and the children. This is the reason why there is
an association between refinement and constraint in this metamodel. For example, for
a feature P and its refined feature C, there is a constraint “C require P” on them,
which means that if you want to bind C, you must firstly bind its parent P. Such
constraints are called refinement imposed constraints in this paper, to distinguish
them from those constructor imposed constraints. The issue of extracting refinement
imposed constraints from refinements is addressed in section 3.

3 Formal Verification of Feature Models

3.1 An Overview of the Process

The process of feature model verification is depicted in Figure 5. There are five main
steps in the process. The first step is feature model construction. In this step, features,
refinement relations between features and constraints on features associated with a
software domain/product-line are systematically identified as in [12, 1, 3, 14]. Most
feature-oriented reuse approaches have provided tool supporting to this step. The
second step is to formalize constraints on features into logic sentences, which will be
presented in section 3.3. The third step is to compute atomic-sets contained in a
feature model, and use these atomic-sets to simplify constraints by replacing features
involved in constraints with their corresponding atomic-sets (see section 3.4). In our
approach, the second and third steps can be automated by tool supporting. After the
third step, operators can apply the SUS criteria to verify constraints on features (the
fourth step, see section 3.5), and further take binding resolutions at each binding-time
(the fifth step) and repeatedly apply the SUS criteria to verify these resolutions. The
fourth step can be automated by using model checkers, such as SMV [11].
 A Propositional Logic-Based Method for Verification of Feature Models 121

1. Feature Model 4. SUS Verification

Construction Criteria Application

2. Constraint 3. Atomic-Set Computation 5. Tailoring &

Formalization & Constraint Simplification Binding

Fig. 5. The Process of Feature Model Verification

3.2 Partition Features in Feature Models

As discussed above, tailoring and binding features in different binding times can be
viewed as changing the binding states of features. Usually, features in a feature model
can be partitioned into three sets according to their binding-states: BFSet, UFSet and
RFSet. The definition of the three set is:
BFSet = { f | f.binding-state = bound };
UFSet = { f | f.binding-state = undecided };
RFSet = { f | f.binding-state = removed };
The partition of features among the three sets may not be stable when current
binding time changes. Features in UFSet may move to the other two sets after
tailoring or binding actions. Once a feature moves to BFSet or RFSet, the truth value
of this feature will become the logical constant of True or False. Figure 6 shows the
transition of a feature’s binding-state between different binding times.

binding action
bound

undecided

removed
tailoring action

Fig. 6. Feature Binding-State Transition Diagram

The three feature sets combined with the feature binding-state transition provide a
uniform view of these tailoring and binding actions which are taken both at the
development for reuse phase (i.e. construct-time) and at the development with reuse
phase (such as reuse-time, compile-time, and so on). At the beginning, all features in a
feature model belong to UFSet, and each feature’s binding-time is carefully decided.
Then, at the construct-time, feature model constructors put those construct-time
bound features into BFSet through binding actions. The set of construct-time bound
features is also called the commonality of a feature model, because these features will
exist in every application feature models. The construct-time is the only binding time
at the development for reuse phase. After the construct-time is the reuse-time. At this
time, requirement analyzers for individual applications will take some tailoring and
binding actions according their current reuse contexts. The result is that some features
in UFSet are partitioned into BFSet or RFSet. Similar tailoring and binding actions
122 W. Zhang, H. Zhao, and H. Mei

can be taken at each binding time, although the operators of these actions may change
from feature model constructors to requirement analyzers, even to end users at run-
time. Thus, the verification of feature models is transformed into checking the
rationality of tailoring and binding actions at each binding time, besides checking the
consistency of constraints in feature models.

3.3 Formalize Constraints on Features

To achieve the above-mentioned verification, we need to transform the constraints

into a form that can be processed by model checkers. According to the cause of
constraints, constraints in a feature model can be roughly divided into two categories.
Constraints in the first category are imposed explicitly by feature model constructors.
Constraints in the second category are imposed implicitly by feature refinements.
For the explicit constraints, we can formalize typical constraints on features [1, 2,
3] and binding predicates into the propositional logic. Table 2 shows the results of our
formalization. For conciseness, only one kind of Composite Constraint’s formalization is
given in this table. Others can be deduced in a similar way.

Table 2. Formalization of Typical Constraints

Constraint/Predicate Formalization
f1 require f2 f1o f2
f1 mutex f2 ¬( f1ˆ f2)
Mutex-Group(f1,f2,…fn)  fj ,fk{ f1,f2,…fn }, jzk, ¬( fjˆ fk)
None-Group(f1,f2,…fn) True
All-Group(f1,f2,…fn) (ˆ1d j d n fj) ‰ (ˆ1d j d n ¬fj)
single-binding(f1,f2,…fn)  1d i d n (ˆ1d j d n, j z i ¬fj)ˆ fi
multiple-binding(f1,f2,…fn) ‰i=1,…,n fi
all-binding(f1,f2,…fn) ˆi=1,…,n fi
single-bound(f1,…fn) require multiple-
single-bound(f1,…fn) o multiple-bound(g1,…gn)
bound(g1,…gn)

For the implicit constraints, we can represent them as the following rules. These
rules essentially reflect constraints imposed by refinements.
 A pre-condition of binding a feature is that its parent must have been bound.
 A post-condition of binding a feature is that all its mandatory children must
also be bound.
 A post-condition of binding a fully decomposed feature is that at least one of
its constituent features must also be bound.
Similarly, there are also two kinds of rules when unbinding a feature:
 A pre-condition of unbinding a feature is that all its children must have been
unbound.
 A post-condition of unbinding a mandatory feature is that its parent must also
be unbound.
Table 3 shows constraints implied by typical refinement scenarios.
 A Propositional Logic-Based Method for Verification of Feature Models 123

Table 3. Constraints Implied by Typical Refinement Scenarios

Refinement Scenario Implied Constraints

fp: a feature;
fpo all-binding(fm1,fm2,…fmi),
{fm1,fm2,…fmi}: the set of mandatory refinement features of fp;
multiple-binding(fm1,fm2,…fmi)o fp,
{ fo1,fo2,…foj }: the set of optional refinement features of fp;
And there is no decomposition feature of fp; multiple-binding(fo1,fo2,…foj)o fp
fp: a feature; fpl all-binding(fm1,fm2,…fmi),
{fm1,fm2,…fmi}: the set of mandatory refinement features of fp; multiple-binding(fm1,fm2,…fmi)o fp,
{ fo1,fo2,…foj }: the set of optional refinement features of fp; multiple-binding(fo1,fo2,…foj)o fp,
{ fd1,fd2,…fdk }: the set of decomposition features of fp; fpo multiple-binding(fd1,fd2,…fdk)
fvp: a vp-feature;
fvpl single-binding(fv1,fv2,…fvn)
{ fv1,fv2,…fvn }: the set of Mutex-Group specialized features of fvp;
fvp: a vp-feature;
fvpl multiple-binding(fv1,fv2,…fvn)
{ fv1,fv2,…fvn }: the set of None-Group specialized features of fvp;

3.4 Atomic Feature Sets in Tailoring and Binding Actions

In above discussions, features are the basic units in tailoring and binding actions.
However, considering those pre-/post-conditions of binding or unbinding features (see
section 3.3), we can find that for any feature f, all its mandatory child features, its parent
feature (if f is a mandatory feature) and f itself can be treated as a whole in tailoring
and binding actions if the constraints implied by refinements are not broken. Thus,
features that can be treated as a whole in tailoring and binding actions can be viewed
as an atomic set, which is represented as atomic-set in this paper. More formally, the
atomic-set containing feature f can be constructed by the following four rules:
1. Create an empty set atomic-set, put f into it.
2. If mandatory feature g  atomic-set, and this feature’ parent gp  atomic-set,
then put gp into atomic-set.
3. If feature g  atomic-set, feature gc is a mandatory child of g, and gc  atomic-
set, then put gc into atomic-set.
4. Repeat rules 2 and 3, until no feature in atomic-set satisfies the two rules.

Legend
mandatory feature

optional feature

decomposition or detailization

specialization

atomic-set

Fig. 7. Atomic-Sets in a Feature Tree

124 W. Zhang, H. Zhao, and H. Mei

Based on the four rules, general algorithms to compute atomic-sets of feature

models can be further developed. Figure 7 shows atomic-sets derived from a possible
feature tree by following the atomic-set construction rules presented above.
Atomic-sets derived from a feature tree compose a partition of features in this
feature tree. Any feature is only contained by one atomic-set.
The reason for using atomic-sets as the basic units in tailoring and binding is that
the granularity of atomic-sets is often larger than that of features, and thus, tailoring
or binding will become more efficient. The transition to using atomic sets as the basic
units can be achieved by simply replacing features in a constraint with their
corresponding atomic sets.

3.5 The SUS Verification Criteria

To evaluate whether the proper tailoring and/or binding actions have been taken in
each binding time, we propose three properties (i.e. Satisfiability, Usability and
Suitability) to verify feature models. We call them “the SUS verification criteria” in
this paper.
Suppose {C1, C2, ..., Cn} is the set of logic sentences capturing all constraints in a
feature model and UFSetI denotes the set of all possible interpretations of the
proposition symbols in UFSet. After tailoring and binding actions at each binding
time, features in UFSet should satisfy the SUS verification criteria to ensure the
rationality of those tailoring and binding actions.
Satisfiability:
 I  UFSetI, I |= ˆ i=1,..., n Ci
Usability:
 f  UFSet,  I  UFSetI, I |= (ˆ i=1,..., n Ci )ˆ f
Suitability:
 f  UFSet,  I  UFSetI, I |= (ˆ i=1,..., n Ci )ˆ (¬ f )
The Satisfiability ensures that there is no inconsistency in tailoring and binding
actions. If this property is not satisfied, constraints on features or those tailoring and
binding actions of the current binding time should be reconsidered to eliminate
inconsistencies.
The Usability ensures that every feature in UFSet has the possibility of being
bound in some future binding time. If this property is not satisfied, it means that there
are one or more features that will not have the chances to be bound after the current
binding time. That is to say, these features actually have been removed from the
feature model. The possible causes may be that the operators have ignored the
tailoring actions on these features, or have done some improper tailoring or binding
actions, or some constraints themselves are wrong. These causes can be eliminated by
putting these features to RFSet, or by undoing some actions at the current binding
time, or by revising constraint on features.
The Suitability ensures that every feature in UFSet has the possibility of being
removed in some future binding time. If this property is not satisfied, it means that
there are one or more features that will not have the chances to be removed after the
current binding time. That is to say, these features actually have been bound. The
possible causes may be that the operators have ignored the binding of these features,
 A Propositional Logic-Based Method for Verification of Feature Models 125

or have done some improper tailoring or binding actions, or some constraints

themselves are wrong. These causes can be eliminated by putting these features to
BFSet, or by undoing some actions of the current binding time, or by revising
constraint on features.

4 Case Studies

We applied our method to two real feature models which we have found in the
literature. The first one is the feature model of Lambda Feedback Control (LFC),
which is presented in [10]. The second one is the feature model of Window
Management Systems, which is presented in [1] as a case study of the FODA method.
In these two case studies, we use the model checker SMV to automate the fifth step of
feature model verification.

4.1 Verification of the Feature Model of Lambda Feedback Control (LFC)

Figure 8 depicts the feature model of LFC. Table 4 shows the 6 atomic sets in the
feature model. In these atomic sets, only the atomic-set as0 contains 4 features, while
others contain only 1 feature.
After steps 2 and 3, we get the simplified constraints using atomic-sets as basic
variables (see the SPEC section in Figure 9). In this case, the number of refinement
imposed constraints decreases from 7 to 4 after step 3, and the number of constructor-
imposed constraints is unchanged. Then, we put these constraints to SMV to check the
three properties in the SUS verification criteria. Figure 9 shows the input files to SMV.

Table 4. Atomic-sets in the LFC Feature Model

Atomic-Set Features Contained by Atomic-Set

Lambda-Feedback-Control, First-Sensor-Feedback-Control, Main-Sensor-Feedback-
as0
Control, Continous-Feedback-Control-Main-Sensor
as1 Two-State-Feedback-Control-First-Sensor
as2 Continous-Feedback-Control-First-Sensor
as3 Catalyst-Outcome-Feedback-Control
as4 Middle-Sensor-Feedback-Control
as5 Continous-Feedback-Control-Middle-Sensor
as6 Natural-Frequency-Feedback-Control

The result of this verification is that constraints in the feature model satisfy the
Satisfiability and the Suitability, but as3, as5 violate the Usability. As we are not familiar
with LFC domain, we do not know what the cause of these two violations is. However,
as an experiment, we omit the two violations and further verify the feature model at the
construct-time. At this binding-time, all construct-time binding (mandatory) features
are partitioned to BFSet. Besides the two violations having been found, we further
identify that as4, as6 violate the Suitability after these construct-time binding actions.
126 W. Zhang, H. Zhao, and H. Mei

Constructor imposed constraints

Refinement imposed constraints

Fig. 8. The Feature Model of Lambda Feedback Control (LFC) (Recreated from [10])

MODULE main
VAR
as0:boolean; as1:boolean;
as2:boolean; as3:boolean;
as4:boolean; as5:boolean;
as6:boolean;
ASSIGN This input is used to check the
Satisfiability of constraints.
//empty
This input is used to check the
//asi = 1;
Usability of ˆš .
//asi = 0; This input is used to check the
SPEC Suitability of ˆš .
AG !(
(as0 <-> (as1 | as2))&
(as4 <-> (as5 | as6))&
Refinement imposed constraints
(as4 -> as0)&
(as3 -> as2)&

(as1 -> ! as2) &

(as5 -> ! as6) &
(as0 -> as6) & Constructor imposed constraints
(as6 -> ! as3) &
(as1 -> ! as3)
)

Fig. 9. Input Files to the Model Checker SMV

 A Propositional Logic-Based Method for Verification of Feature Models 127

4.2 Verification of the Feature Model of Window Management Systems (WMS)

The feature model of WMS is relatively a large and complex one, which contains 117
features, and about 12 constructor-imposed constraints involving 33 features. The
number of atomic-sets in this feature model is 93.
After the third step of feature model verification, constraints on features are
transformed into constraints on atomic sets. Figure 10 shows constraints in the form
of atomic sets. Although the number of possible variables in constraints has decreased
form 117 (features as the variables) to 93 (atomic-sets as the variables), the number of
constructor-imposed constraints does not decrease in this case. The reason for this is
that each atomic set, which is involved in constructor-imposed constraints, contains
only one feature. However, the number of refinement-imposed constraints does
decrease, since there are 5 atomic-sets that contain more than one features, and
refinement-imposed constraints on features in these atomic sets will be eliminated
after using atomic sets as the variables.
Then we apply the SUS verification criteria to the feature model before and at the
construct-time respectively, which is automated by using SMV. The result is that no
constraint or feature in the feature model violates the SUS criteria at these two phases.

Refinement imposed constraints (part) Constructor imposed constraints

Fig. 10. Constraints in the Form of Atomic-Sets

5 Related Work

In [6], a first-order logic based variability validation method was proposed. In fact,
this method only employs those propositional constructs of the first-order logic to
capture constraints on features. The style of constraint representation adopted by this
method is, to some extent, different from the conventional propositional logic. Thus,
this style may not be directly parsed by those general-purpose model checkers.
Moreover, this method does not consider the binding-time property of features, i.e. it
does not distinguish between bound features and undecided features. Hence, this
method may not apply well when some features in a feature model are in the
undecided states.
128 W. Zhang, H. Zhao, and H. Mei

[7] proposes the concept of “commonality of a feature”, which is slightly different

from the concept of atomic set in our approach. In most cases, the commonality of a
feature can be constructed by following the construction rules of atomic-sets (not
including the second rule, see section 3.4). Although the commonality of a feature
also possesses the atomic property in tailoring or binding actions, its granularity is
less than that of the atomic-set in most cases.
A discriminant-based tailoration method has been proposed by [8]. A discriminant
corresponds to an optional feature in feature models. This method mainly focuses on
refinement-imposed constraints and some simple constructor-imposed constraints.
However, this method adapts a different way from our method to ensure that any
application feature model will not violate these constraints. This method fully
employs the tree structure of feature models and these pre-/post-conditions when
binding or unbinding features, while our method transforms such knowledge into
formal logic sentences. Our method further identifies the atomic feature sets in
tailoring or binding actions, and translates constraints on features into constraints on
atomic feature sets.

6 Conclusions

A propositional logic-based method is proposed for verification of feature models at

different binding times in this paper. The most important characteristic of this method is
that it integrates the logical verification with binding times, which makes it can be used
to verify any partially customized feature models at any binding time. In this method,
constraints on features, including refinement-imposed constraints and constructor-
imposed constraints, are firstly formalized into propositional logic sentences. Then,
three properties (i.e. Satisfiability, Usability and Suitability) are proposed to checking
the consistency of constraints and rationality of tailoring and binding actions taken at
each binding time. This method also employs atomic feature sets in tailoring or
binding actions to decrease the complexity of constraints. Since all constraints in a
feature model are formalized into logic sentences in this method, general-purpose
model checkers can be easily used to automate the verification process.
We also applied our method to two real feature models, and some errors were
detected in one of them. A phenomenon we have found in the two case studies is that,
although using atomic sets can decrease the number of possible variables involved in
constraints in the two case studies (one from 10 to 7, and the other from 117 to 93), the
complexity of constructor-imposed constraints does not decrease. The reason is that
each atomic set involved in constructor-imposed constraints in the two feature models
accidentally contains only one feature. Hence, we still believe that replacing features
with atomic sets in constraints can decrease the complexity of constraints in general.

Acknowledgements

This work is supported by the National Grand Fundamental Research 973 Program of
China under Grant No. 2002CB31200003, the National Natural Science Foundation
 A Propositional Logic-Based Method for Verification of Feature Models 129

of China under Grant No. 60233010, 60125206, and the Research Fund for the
Doctoral Program of Higher Education under Grant No. 20010001001.
The authors would like to thank Lu Zhang for his invaluable advice and help in
polishing this paper.

References
1. Kyo C. Kang, Sholom G. Cohen, James A. Hess, William E. Novak, A. Spencer Peterson,
“Feature-Oriented Domain Analysis Feasibility Study”, SEI-90-TR-21, Software
Engineering Institute, Carnegie Mellon University, Nov. 1990.
2. Kyo C. Kang, Sajoong Kim, Jaejoon Lee, Kijoo Kim, Euiseob Shin, Moonhang Huh,
“FORM: A Feature-Oriented Reuse Method with Domain-Specific Architecture”, Annals
of Software Engineering, 5:143-168, September, 1998.
3. Martin L.Griss, John Favaro, Massimo d’Alessandro, “Integrating Feature Modeling with
the RSEB”, in Proceedings of Fifth International Conference on Software Reuse, pp.76-85,
IEEE Computer Society, Canada, June 1998.
4. Gray Chastek, Patrick Donohoe, Kyo C. Kang, Steffen Thiel, “Product Line Analysis: A
Practical Introduction”, SEI-2001-TR-001, Software Engineering Institute, Carnegie
Mellon University, 2001.
5. Even-André Karlsson (editor) “Software Reuse: A Holistic Approach”, REBOOT
Methodology Handbook, John Wiley & Sons, 1995.
6. Mike Mannion, “Using First-Order Logic for Product Line Model Validation”, The Second
Software Product Line Conference 2002, LNCS 2379, pp.176–187, August 2002.
7. Dániel Fey, Róbert Fajta, and András Boros, “Feature Modeling: A Meta-Model to
Enhance Usability and Usefulness”, The Second Software Product Line Conference 2002,
LNCS 2379, pp.198–216, August 2002.
8. Mike Mannion, Barry Keepence, Hermann Kaindl, Joe Wheadon, “Reusing Single System
Requirements from Application Family Requirements”, in Proceedings of the International
Conference on Software Engineering, pp.453-462, 1999.
9. Hafedh Mili, Fatma Mili, Ali Mili, “Reusing Software: Issues and Research Directions”,
IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, VOL. 21, NO. 6, JUNE
1995.
10. Stefan Ferber, Jürgen Haag, Juha Savolainen, “Feature Interaction and Dependencies:
Modeling Features for Reengineering a Legacy Product Line”, The Second Software
Product Line Conference 2002, LNCS 2379, pp.235–256, August 2002.
11. SMV, “Model Checking @CMU, The SMV System”, http://www-2.cs.cmu.edu/~
modelcheck/smv.html.
12. Hong Mei, Wei Zhang, Fang Gu, “A Feature Oriented Approach to Modeling and Reusing
Requirements of Software Product Lines”, The 27th Annual International Computer
Software and Applications Conference, pp.250-255, November, 2003.
13. D. Amyot, L. Charfi, N. Gorse, T. Gray, L. Logrippo, J. Sincennes, B. Stepien, T. Ware,
“Feature Description and Feature Interaction Analysis with Use Case Maps and LOTOS”,
FIW’00, Glasgow, May, 2000.
14. Kwanwoo Lee, Kay C. Kang, Jaejoon Lee, “Concepts and Guidelines of Feature Modeling
for Product Line Software Engineering”, ICSR-7, pp. 62-77, 2002.
15. P. Zave, “Feature interactions and formal specifications in telecommunications”, IEEE
Computer, 26(8):20-29, August, 1993.
130 W. Zhang, H. Zhao, and H. Mei

16. Martin L. Griss, “Implementing Product-Line Features with Component Reuse”, in

Proceedings of Sixth International Conference on Software Reuse, pp. 137–152, LNCS
1844,Vienna, June, 2000.
17. C. Reid Turner, Alfonso Fuggetta, Luigi Lavazza, Alexander L.Wolf, “A Conceptual Basis
for Feature Engineering”, Journal of Systems and Software, VOL. 49, NO. 1, December
1999.
18. Karl E.Wiegers, “Software Requirements”, Microsoft Press, 1999.
19. Alok Mehta, George T. Heineman, “Evolving Legacy System Features into Fine-Grained
Components”, Proceedings of the 24th international conference on Software engineering,
Orlando, Florida, 2002.
20. Kyo C. Kang, Kwanwoo Lee, Jaejoon Lee, Sajoong Kim, “Feature Oriented Product Line
Software Engineering: Principles and Guidelines”. A chapter in “Domain Oriented
Systems Development – Practices and Perspectives”, UK, Gordon Breach Science
Publishers, 2002.
21. Stefan Ferber, Jürgen Haag, Juha Savolainen, “Feature Interaction and Dependencies:
Modeling Features for Reengineering a Legacy Product Line”, The Second Software
Product Line Conference 2002, LNCS 2379, pp.235–256, August 2002.
22. Unified Modeling Language (UML), Version 1.5, http://www.omg.org/
technology/documents/formal/uml.htm.

View publication stats