A Propositional Logic-Based Method for Verification of Feature Models

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 Classifier Require Constraint 1..2

+requirer

Decomposition Feature

1 1 +requiree name Exclude description 2 optionality * binding-time binding-state ComplexConstraint

* *

*

Relationship

117

+parent 1 1

* Refinement

Detailization

0..1

+child

0..1

Specialization

1..*

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 name description optionality binding-time binding-state

Description The denotation of a feature The detailed representation of a feature Whether a feature must also be bound when its parent feature is bound The phase when a feature must be bound or removed Whether a feature has been bound or removed, or is waiting for being decided

Value Range possible meaningful character strings {informal, semi-formal, formal} {mandatory, optional} {construct-time, reuse-time, time, install-time, load-time} {bound, removed, undecided}

compile-

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

GroupConstraint

CompositeConstraint

GroupConstraint

CompositeConstraint

1..*

2

BindingPredicate 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..* 1..*

0..* 1..*

0..*

0..* 1..*

1..*

0..* 1..*

0..* 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 bindingstate 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: Group Constraints: Binding Predicates:

(require) (Mutex-Group) (single-bound)

(mutual require) (None-Group) (multiple-bound)

(exclude) (All-Group) (all-bound)

Example

Constraints: A require E, C exclude Fˈ Mutex-Group(A, B, C), single-bound(A, B, C) require D. 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 1. Feature Model Construction

2. Constraint Formalization

121

4. SUS Verification Criteria Application

3. Atomic-Set Computation & Constraint Simplification

5. Tailoring & 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 tailoring action

removed

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 runtime. 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 f1 require f2 f1 mutex f2 Mutex-Group(f1,f2,…fn) None-Group(f1,f2,…fn) All-Group(f1,f2,…fn) single-binding(f1,f2,…fn) multiple-binding(f1,f2,…fn) all-binding(f1,f2,…fn) single-bound(f1,…fn) require multiplebound(g1,…gn)

Formalization f1o f2 ¬( f1ˆ f2)  fj ,fk{ f1,f2,…fn }, jzk, ¬( fjˆ fk) True (ˆ1d j d n fj) ‰ (ˆ1d j d n ¬fj)  1d i d n (ˆ1d j d n, j z i ¬fj)ˆ fi ‰i=1,…,n fi ˆi=1,…,n fi single-bound(f1,…fn) o multiple-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 fp: a feature; {fm1,fm2,…fmi}: the set of mandatory refinement features of fp; { fo1,fo2,…foj }: the set of optional refinement features of fp; And there is no decomposition feature of fp; fp: a feature; {fm1,fm2,…fmi}: the set of mandatory refinement features of fp; { fo1,fo2,…foj }: the set of optional refinement features of fp; { fd1,fd2,…fdk }: the set of decomposition features of fp; fvp: a vp-feature; { fv1,fv2,…fvn }: the set of Mutex-Group specialized features of fvp; fvp: a vp-feature; { fv1,fv2,…fvn }: the set of None-Group specialized features of fvp;

Implied Constraints fpo all-binding(fm1,fm2,…fmi), multiple-binding(fm1,fm2,…fmi)o fp, multiple-binding(fo1,fo2,…foj)o fp fpl all-binding(fm1,fm2,…fmi), multiple-binding(fm1,fm2,…fmi)o fp, multiple-binding(fo1,fo2,…foj)o fp, fpo multiple-binding(fd1,fd2,…fdk) fvpl single-binding(fv1,fv2,…fvn) fvpl multiple-binding(fv1,fv2,…fvn)

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  atomicset, 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 constructorimposed 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 as0

Features Contained by Atomic-Set Lambda-Feedback-Control, First-Sensor-Feedback-Control, 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

Main-Sensor-Feedback-

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 //empty //asi = 1; //asi = 0; SPEC AG !( (as0 (as1 | as2))& (as4 (as5 | as6))& (as4 -> as0)& (as3 -> as2)& (as1 -> ! as2) & (as5 -> ! as6) & (as0 -> as6) & (as6 -> ! as3) & (as1 -> ! as3) )

This input is used to check the Satisfiability of constraints. This input is used to check the Usability of ˆš . This input is used to check the Suitability of ˆš .

Refinement imposed constraints

Constructor imposed constraints

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 constructorimposed 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.