Logic-Based Analysis and Verification of

Software Product Line Variant Requirement Model

Shamim H Ripon*, Sk. Jahir Hossain and Moshiur Mahamud Piash
Department of Computer Science and Engineering
East West University, Dhaka, Bangladesh
Email: *dshr@ewubd.edu
Abstract: Software Product Line (SPL) provides the facility to systematically reuse of software improving the
efficiency of software development regarding time, cost and quality. The main idea of SPL is to identify the common
core functionality that can be implemented once and reused afterwards. A variant model has also to be developed to
manage the variants of the SPL. Usually, a domain model consisting of the common and variant requirements is
developed during domain engineering phase to alleviate the reuse opportunity. We present a product line model
comprising of a variant part for the management of variant and a decision table to depict the customization of
decision regarding each variant. Feature diagrams are widely used to model SPL variants. Both feature diagram
and our variant model, which is based on tabular method, lacks logically sound formal representation and hence,
not amenable to formal verification. Formal representation and verification of SPL has gained much interest in
recent years. This chapter presents a logical representation of the variant model by using first order logic. With this
representation, the table based variant model as well as the graphical feature diagram can now be verified logically.
Besides applying first-order-logic to model the features, we also present an approach to model and analyze SPL
model by using semantic web approach using OWL-DL. The OWL-DL representation also facilitates the search and
maintenance of feature models and support knowledge sharing within a reusable engineering context. Reasoning
tools are used to verify the consistency of the feature configuration for both logic-based and semantic web-based
approaches.

1 Introduction
Designing, developing and maintaining a good software system is a challenging task still in this 21st
century. The approach of reusing existing good solutions for developing any new application is now one
of the central focuses of software engineers. Building software systems from previously developed
components saves cost and time of redundant work, and improves the system and its maintainability. A
new software development paradigm, software product line [1], is emerging to produce multiple systems
by reusing the common assets across the systems in the product line. However, the idea of product line is
not new. In 1976 Parnas [2] proposed modularization criteria and information hiding for handling product
line.
A software product line is a set of software-intensive systems sharing a common, managed set of features
that satisfy the specific needs of a particular market segment or mission and that are developed from a
common set of core assets in a prescribed way [1]. Core assets are the basis for software product line. The
core assets often include the architecture, reusable software components, domain models, requirements
statements, documentation and specifications, performance model, etc. Different product line members
may differ in functional and non-functional requirements, design decisions, run-time architecture and
interoperability (component structure, component invocation, synchronization, and data communication),
platform, etc. The product line approach integrates two basic processes: the abstraction of the
commonalities and variabilities of the products considered (development for reuse) and the derivation of
product variants from these abstractions (development with reuse) [3].
1

The main idea of software product line is to explicitly identify all the requirements which are common to
all members of the family as well as those that are different, and then arrange them in a model. This
implies a huge model which will help the stakeholders to be able to trace any design choices and
variability decisions as well. Finally, the derivation of the product is done by selecting the required
variants from the model and configuring them according to product requirements.
Common requirements among all family members are easy to handle as they simply can be integrated
into the family architecture and are part of every family member. But problem arises from the variant
requirements among family members. Variants are usually modeled using feature diagram, inheritance,
templates and other techniques. In comparison to analysis of a single system, modeling variants adds an
extra level of complexity to the domain analysis. In any product line model, the same variant has
occurrences in different domain model views. Different variants have dependencies on each other. Tracing
multiple occurrences in different model views of any variant and understanding the mutual dependencies
among variants are major challenges during domain modeling. While each step in modeling variant may
be simple but problem arises when the volume of information grows. As a result, the impact of variant
becomes ineffective on domain model. Therefore, product customization from the product line model
becomes unclear and it undermines the very purpose of domain model.

Figure 1. Product derivation using variability model

The objective of this chapter is to provide an approach to modeling variants in the domain model of a
product line. This model carries all the variant related information like specifications, interdependencies,
origins of variants, etc. In developing product line, the variants are to be managed in domain engineering
phase, which scopes the product line and develops the means to rapidly produce the members of the
family. It serves two distinct but related purposes; firstly, it can record decisions about the product as a
whole including identifying the variants for each member, and secondly, it can support application
engineering by providing proper information and mechanism for the required variants during product
generation (Fig. 1).
We present a variability model to draw the common and variant features of a product line. In the
variability model, a tabular based approach [4] is used in conjunction with feature model to portray the
reusable features of product line. The tabular mechanism also provides a decision table that support
product customization. However, the variability model lacks logic based formal definition. A formal
verification of such variability model ensures a sound and consistent variability model facilitating a
verified product customization mechanism. We present a logic verification approach for variant
requirements of software product line. Our particular interest is on the notion of variant dependencies that
play a vital role in product customization. The model allows the user to select features from the feature
2

tree according to product requirements and customized product can then be derived from these selected
features. While deriving this product, the decision table is required to handle various features and their
dependencies. However, defining such table involves manual handling of variants and hence, formal
verification is not directly admissible for such approach.
We use logical representation of feature models facilitating the development of decision table in a
formally sound way. We define six types of logical notation to represent all the parts in a feature model.
First-order logic has been used for this purpose. These notations are used to define all possible scenarios
of a feature model. It is often leveled that manual verification leads to numerous error for large models
and often misses the minute detail in the verification. To overcome this problem we use the model
checker Alloy [5]. We encode our logical definitions into Alloy and check the validity of the logical
verification that we perform by hand.
Although such modeling technique supports sound formal definition, it still lacks the ontological and
sharable knowledge description of the features and concepts. To capture domain knowledge and common
vocabularies in any field ontology has shown itself an acceptable paradigm [6]. It is also necessary to
process and exploit knowledge in a computer system. Among the various available approaches for
knowledge representation, ontologies appear to be a promising solution due to its ability to make the
domain knowledge computer readable and processable. Besides various inference algorithms and tools
are available to infer new knowledge from the existing, Semantic Web technology can provide a
meaningful and shared ontological description of the domain. Web Ontology Language (OWL) [7] is one
of the most expressive languages for specifying, publishing and sharing ontologies. It also provides
proper mechanism to exploit the potential of Semantic Web by prescribing how data are defined and
related. Importantly, OWL not only facilitates better machine interoperability than that of XML, RDF,
RDFS etc. but also has formal semantics and support for defining additional vocabulary. It is therefore
evident that semantic web technology, OWL in particular, can be used to represent a particular domain
and define the relationship of various features within that domain. Among the various available dialects,
this paper uses OWL-DL which is based on Description Logic (DL) [8].
We present a case study of Hall Booking System product line. We analyze and model the variants as well
as the variants dependencies and perform our proposed verification techniques.

1.1 Chapter Structure

In the rest of the chapter, first we illustrate how variants of a SPL can be modeled by using FODA [9] and
tabular method. We then present our variant model and decision table that facilitates the customization
steps. We illustrate the steps that are required to derive a customized product from the product line model.
We then show how first-order logic has been used to define the various notations in a feature diagram.
There are six types of notations and we give logical presentation of all of them. We define various rules to
support several analysis operations. The following section then shows the verification mechanism of this
logical representation. The OWL-DL representation of feature model is presented in the following
section. How all the notations in feature model are defined using OWL is depicted here. Automated
verification of feature consistency of the OWL-DL definitions is also presented. Finally, we conclude our
chapter summarizing our contributions and discussing related works.

Modeling Variants

Though it is possible to create a software system family without developing a distinct variability model
where the domain is well understood by all members (i.e. developer, stakeholders), the variability model
offers some potential advantages:

It provides a distinct document characterizing all the variants of the family as a whole for both domain
engineers and stakeholders interested in the product line.

It has a place for recording the selection and application related decision of each variant which is part
of a family and provides support to implement any member product.

The required variant of any particular product can be validated and verified by it.

While developing the variability model, we have some objectives to be met by the model. The model
should specify both the commonalities and variants of the family members. In the case of variants, it
should contain their application areas, constraints, possible values, dependencies, etc. Along with these
objectives, the variability model should contain the customization and configuration structure of each
variant of the system family which will guide the application engineer to generate any product from the
system family.

2.1 Hall Booking System Overview

We use Hall Booking System family to illustrate our variability modeling mechanism. The system is used
in academic institutions to reserve tutorial rooms and lecture halls, at companies to reserve meeting
rooms, and at hotels to reserve rooms and conference facilities, etc. In another sense, the system can be
used for either academic or non-academic purposes. Users can manage their own reservation with the
system. The main purpose and the core functionality are similar across the Hall Booking System family;
however, there are many variants on the basic theme. One of the basic variants is the charging of booking
system. Whenever the system is used for academic purposes, no charge is needed for booking halls,
whereas there may be a need to charge for booking halls in other areas. In some systems, there are
facilities available for seasonal booking as well as multiple bookings. The descriptive part of the hall
booking system consists of feature diagrams, domain defaults and domain defaults instrumented with
variants. Domain defaults describe a typical system in a domain. Our Hall Booking System default models
cover the functionalities shown in Fig 2.
Make reservation
Delete reservation
Modify reservation
Search/Retrieve reservation
Add a resource (Hall)
Delete a resource (Hall)
Modify a resource
Search/receive a Hall
Figure 2. Functionalities covered by default Hall Booking System

Figure 1.Hall Booking System feature diagram

2.2 Variant Modeling using FODA

The Feature Oriented Domain Analysis (FODA) [9] focuses on identifying features that characterize a
domain. Features are user visible aspects or characteristics of a system and are organized into And/Or
graph in order to identify the commonalities and variants of the application domain. Feature modeling is
an integral part of the FODA method and the Feature Oriented Domain Reuse Method (FORM) [10]. The
commonalities and variants within features are exploited to create a set of models that is used to
implement any member product of that family. Features are represented in graphical form as trees. The
internal nodes of a tree represent the variants and their leaves represent values of corresponding variants.
Graphical symbols are used to indicate the categories of features. The root node of a feature tree always
represents the domain whose features are modeled. The remaining nodes represent features which are
classified into three types: Mandatory, Optional, and Alternative. Mandatory features are always part of
the system. Optional features may be selected as a part of the system if their parent feature is in the
system. The decision whether an optional feature is part of the system can be made independently from
the selection of other features. Alternative features, on the other hand, are related to each other as
exclusive-or relationship, i.e. exactly one feature out of a set of features is to be selected.
The feature diagram depicts the classification of mandatory features and variant features as well as their
dependencies. Mandatory features are those which are present in all products in the respective domain.
Variant features appear only some members of the domain which differentiate one product from others.
There are more relationships between features. One is Or-feature [11], which connects a set of optional
features with a parent feature, either common or variant. The meaning is that whenever the parent feature
is selected then at least one of the optional features will be selected. Feature diagram also depicts the
interdependencies among the variants which describes the selection of one variant depends on the
selection of the dependency connected variants. Two types of dependencies are illustrated in this paper:
5

requires and exclude. A part of the feature tree of Hall Booking System is shown in Fig. 3. Extensions of
feature diagram described in [11] have been used here.

2.3 Unified Tabular Approach

In product line, variants have several impact and dependencies on other variants. Any particular product
of a product line can be customized from the generic model of the product line. On the way of
customization, several variants have to be chosen from a list of variants. During selection of variants
some queries arise, that are not easily answered. Some of these queries are:

Some variants are used by all the family members of the product line while other variants and some
values of some variants are only applicable for particular members.

Variants may have prerequisites and/or post requisites. The existing methods can express them but
situation becomes complex when dependencies increase.

When new information is added/deleted/modified, it may have impact on several others variants, so
we need an easy way to handle for large number of impacts.

All information like this can be represented using FODA or other methods but need extra annotation with
the model which will sometimes become complex and difficult to handle. The table approach that we
present here depicts all the information that are described by FODA as well as those that have just
mentioned above. This table, which is actually a categorization table, will help us selecting variants
during application engineering process. A part of the table is given here in Table 1, depicting some of Hall
Booking Systems variants, their type, values, sub domain, relationship as well as dependencies.
Table 1. Partial variant model of Hall Booking System

2.4 Table Construction

The unified table is constructed by keeping all the information available in a FODA feature diagram. By
analyzing the characteristics of variants of a domain we found that all the variants follow certain types of
common categorization and all of them have certain behavior. So, if the variants are arranged according to
these categorizations and behavior then they can be handled easily in a domain. After identifying the
6

common characteristics and behavior of variants we arranged the variants in a tabular format. The table
contains the following information.
The column Variant shows the name of the variants which have some values and each variant is given a
unique number to refer it in order to locate the dependency. Variants are given name corresponding to the
function they are involved.
The column Variant Type indicates the type of variants. A variant is either Mandatory or Optional. A
Mandatory variant remains in all the products of the domain and hence it will be selected each time
during customization. On the other hand an Optional variant is not present in all the products of the
domain. They can be either selected or not during customization. The presence or absence of Optional
variants during customization depends on the product for which the customization is performed.
The possible values or choices of the each variant are depicted in the column Variant Value. The values
are numbered followed by their variant numbers in order to trace variant dependencies. The Sub
Domain column is used to designate the applicable product area of the particular value of the variant. If
any variant is present in all the products then the term All will be in the column, otherwise the name of
the applicable area is given. As some variants and their values are only applicable to certain products this
column will guide the selection process faster.
The column Relation among values indicates the relationship among the values of the variant. These
relationships are used to select one or more values from the listed values of the variant. There are two
types of relationship among the values Alternative and OR. Alternative means variant values are
mutually exclusive to each other, so that only one of them will be selected and if the relationship is OR
then it means that one or more values can be selected from the list.
The Dependency column shows whether the variant is dependent on any other variants or not. Here by
dependent we mean that if a variant B is dependent on a variant A then variant B will be selected only
when the variant A is selected. In this column the unique numbers of the variants or their values are used
to identify on which variant it depends.
Usually, there are some complex dependencies among variants, and feature diagrams cannot represent
them properly. Logic notations can be used to show the legal combination of variants in any given
member of product line. We used the notations given in [12]. In Table 2 we give a list of the types of
dependencies that we found useful to use in the dependency column of the table approach. The left hand
side of the table shows the notation to be placed in the dependency column of the variant and the right
hand column shows the meaning of that notation.
Table 2. Types of variant dependencies

2.5 Comparison with Feature Diagram

It is possible to convert a feature diagram to its equivalent table approach for describing the variants and
vice versa. Having the suitability of presenting all the variant information like other approaches, we
mention it a unified approach. Along with its unified property it overcomes some of the complexities of
variant modeling faced in feature diagram.
When some variants depend on other variants the modification of its information or visual representation
will affect all the dependent variants and their values. As the feature diagram represents variants in a
graphical form, sometimes it will be very easy to check the overall features at a glance. But in a domain,
there are a lot of variants and each variant has values as well as dependencies. Combining all the variants
and their information in a feature diagram will make it very complex and difficult to handle.
By using the tabular approach, we can avoid the complexities to modify or add any variants as the table
requires only updating or adding the particular row of the corresponding variant. In the table, all
information corresponding to the variants is clearly and separately identified using different columns. By
looking any particular row one can easily find all the relevant properties of a variant. In feature diagram
annotation is used to indicate the applicable domain of one of the values of the variant. But using this
kind of annotation for all the variants will make the feature diagram very complex.
Actually, feature diagram tends to become very complex and unmanageable for domain of any reasonable
size. We found that use of textual language (table representation) to define a feature model and using
feature diagram to show the relationships among a set of selected features is more effective than using
feature diagram only. As the diagram becomes large and complex, it is very difficult to modify the
diagram and also keeping it understandable requires much editing effort. We can use tabular
representation to input and modify a feature model and can use the diagram to output the feature model
for analysis.
In addition to representing variants, table approach is also useful for processing purpose of the feature
diagram. The feature diagram is a graphical representation; therefore, the table approach will be a good
choice of representing the feature diagram for any kind of processing that need to be done on feature
diagram.

2.6 Use of Table in Customization

A separate table named decision table is constructed along with variant table to guide the customization
steps of the variants for a particular product from the domain model. A schematic view of the product
customization is depicted in Figure 24.

Figure 2. Product model customization steps

By using the table, the customization process becomes very easy. The table shows all variants as well as
their types. Therefore, looking at the table at a glance it is easy to identify the variants which must be
present as well as those which need to be selected. The table shows the applicable sub domain (applicable
product) of each variant and their values. Hence, on the way of customizing any particular product it will
be very easy to select only those variants and values which are applicable to that product and those
variants which are not applicable can be discarded easily. The dependency information also helps in
customization steps. If a variant is to be selected for a product then the other variant(s) on which this one
depends will also be selected by just looking at the dependency column.
A decision table is made based on the table approach to guide the application engineer for a particular
product customization. A decision table is constructed based on the variant values. A brief description of

the construction of a decision table is given here. A decision table is derived from our tabular
variant model as follows:

For each variant we create a variable ranging over the possible values of the variant.
Where the inclusion or exclusion of variants depends on another variants value, these variants are
subordinated in the table.
For each decision, there is a name, brief description, range of values, and traceability number for
dependency tracing is given.

During domain modeling we can use the table which will assist variant customization process in a
convenient way,
When any particular sub domain is selected to customize from the generic model, the variants which
are applicable to the particular domain will be extracted from the table as well as their dependent
variants. These will relief the application engineer going through the long list of variants and finding
their dependencies

The required variants are then selected, instructed by the decision table .

Table 3.Partial decision table

A small part of the decision table is given in Table 3. In the table, each variant is placed in a column, its
description, possible choices and traces to the variant are shown in other columns. When the inclusion or
exclusion of a variant depends on another variant or its value(s) then that variant is placed in the
subordinate position showing the values for which it can be chosen. For example, Reservation Mode
variant has two possible values either Single or Block. So these two values are placed in the subordinate
position of the parent variant (Reservation Mode) in the decision table. Similarly when Block reservation
is to be considered then it needs to check its values (Multiple Room and Multiple Time) and these values
along with their other information will be also be subordinated. For each variant and for each of their
values, the decision table can have a corresponding entity.
By using the proposed variability model, it is now possible to derive any member product from the
system family model according to the users requirements. In the proposed variability model, all the
possible variants are added to the default models, which help the developer to select the proper variants
according to the users requirements. Suppose there is a need for a Hall Booking System for the university
purpose where the user wants to be notified by printed paper and there is no need to handle conflicts when
a reservation is not available. When the developer gets the above requirements, the required variants are
extracted from the variant model. As the required system is for the academic purpose, those variants
which are only for non-academic purposes like reservation charge are discarded. Using the variant
dependency information given in the variant model, other dependant variants are also extracted along
with the required variants. So the developer does not need to check all the dependencies of the system
family. This results a smaller variant table model as shown in Table 4.
Similarly, the decision table is also reduced containing only the decisions for the required features. By
using the decision table, the user can take decisions on variants. Suppose the user wants to reserve a hall
for multiple time slots. Using the dependency information of the decision table and the variant model, it is
clear that if this variant is required then there is a need to choose the reservation mode to Block.
Following this way the developer can select the proper variants according to the requirements and
consequently can derive the proper product model, from where the developer can develop the required
customised product in a suitable developing language.

10

Table 4.Customized variant table

Variant

Values of variant

V1.

V1.1 Single

Reservation Mode
V3.

V1.2 Block
V3.1 Multiple Room

Block Reservation
V4.

V3.2 Multiple Time

Notification

Relations

Applicable
Area

Dependency

All

None

All

V1.2

All

None

Alternativ
e
OR

V4.3 Printed Paper

3 Logic-based Representation
A feature model is a hierarchically arranged set of features. It represents all possible products of a
software product line in a single model. The relation between a parent (variation point) features and its
child features (variants) are categorized as Mandatory, Optional, Alternative, Optional Alternative, Or,
and Optional Or. The logical representation of feature models facilitates the development of decision
table in a formally sound way. We define six types of logical notation to represent all the parts in a feature
model using first-order logic. These notations are used to define all possible scenarios of a feature model.
The logical notions of these features are defined in Fig. 5.

Figure 3. Logical notations for feature model

A feature model (e.g. Fig. 3) can be considered as a graph consists of a set of sub-graphs. Each sub-graph
is created separately by defining a relationship between the variation point (denoted as vi) and the
variants (vi.j) by using the expressions shown in Fig. 5. The complexity of a graph construction lies in the
definition of dependencies among variants. When there is a relationship between cross-tree (or cross
hierarchy) variants (or variation points) we denote it as a dependency. Typically, dependencies are either
inclusion or exclusion: if there is a dependency between p and q, then if p is included then q must be
included (or excluded). Dependencies are drawn by dotted lines.

11

3.1 Analysis of Feature Model

From the logical representation of feature model it is possible to analyze various scenarios during
product customization. We consider a feature model as a graph consists of a set of sub-graphs. Each subgraph is created separately by defining a relationship between the variation point (denoted as
the variants (

vi . j

v i ) and

) by using the expressions shown in Fig. 5. A relationship between cross-tree (or

cross hierarchy) variants (or variation points) is denoted as a dependency. There are two types of
dependencies considered in this paper, inclusion and exclusion: if there is a dependency between p and q,
then if p is included then q must be included (or excluded). Dependencies are drawn by dotted lines.
Scenario 1: If there is a require relation between variants

v2

is elected whenever

v1

v 1 and v 2 as shown in Fig. 6(a), then

is selected. Adopting the notation in [13] the rule for dependency

among variants as well as variation points is defined as follows,

v
v 1 , v 2 type ( v1 , variant ) type ( v 2 , variant ) require v 1 , v 2 select ( v 1) select (v 2)

vp
v 1 , v 2 type ( v1 , variation point ) type ( v 2 , variationpoint ) require v1 , v 2 select (v1 ) select (v 2 )

Figure 4.a)-(c) Requires dependency between variants and

(d)-(e) Exclude dependency between variants and variation points

Where

type(vi )

selection of

vi

indicates
and

vi

require( )

is either a variant or variation point,

select ( vi )

indicated the

indicates the require relationship. Similar notation will be used for

12

rest of the rules definition. Due to this dependency rule the dependant variant, v2 here, will always be
selected if v1 is selected and such selection will not be affected by the type of relationship such as
Alternative, with their parent
Scenario 2: From Fig. 6(b), we derive the following rule,

v 1 , v 2 , xtype ( x , variant ) type (v 1 , variation point )

type(v 2 , variation point)
requires v vp ( x , v ) select ( x) select (v 2 )
2

Scenario 3: The following rule is derived from Fig. 6(c)

v 1 , v 2 , x , y ty pe ( x , variant) type( y , variant)

variants ( v1 , x ) variant ( v 2 , y ) common( y)
requires v p vp ( v , v ) select (x) select ( y )
1

Scenario 4: When there is an exclude relation between variants (and/or variation point) as shown in
Fig. 6(d), only one among them can be selected at a time.
Here v1 and v2 are variants in the left figure and variation point in the right part of the figure. In both
cases, as there is exclude relationship between them only one can be selected at a time. Here, we can
suggest that for such scenario the relationship among the variants or variation points must be Alternative
to keep the feature model well-formed. Similar to previous example, we define rules for such
dependencies.

v
v 1 , v 2 type ( v 1 , variant ) type ( v 2, variant ) exclude v 1 , v 2 select (v 1) notselect ( v 2)

vp
v 1 , v 2 type ( v 1 , variation p oint ) type(v 2 , variation point)exclude v 1 , v 2 select (v 1) notselect ( v 2)
Scenario 5: From Fig. 6(e) we derive the following rule,

v 1 , v 2 , x , y type ( x , vari ant ) type(v 1 , variation point)type ( v 2 , variation point ) exclude v vp ( x , v 2 ) sele
Scenario 6: The scenario in Fig 6(f) depicts the following rule,

vp
v 1 , v 2 , x , y type ( x , variant ) type( y , variant )variant ( v 1 , x ) variant ( v 2 , y ) common( y , yes) require

13

Figure 5.(a) Inconsistency checking; (b) False optional feature detection and (c) Dead feature detection

3.2 Analysis Operations

Inconsistency: In Fig. 7(a),
variants of

v1

and

v 2.1

v , v1

and

and

v 2.2

v2

are three variation points where

are of

v 1.1

and

v 1.2

v 2 . There exists a require relationship between

v 1.2 and variation point v 2 . As v 1.1 and v 1.2 are mandatory feature whenever

variant

is selected both variants will be selected, and consequently, variation point

due to require relation. However,

are

v1

v 2 will be selected as well

v 1 and v 2 are alternative features, and both cannot be selected at

the same time and it introduces an inconsistency into the feature model.
False optional is a situation where a feature is declared as optional which does not need so. In Fig. 7(b),

v2

is False optional. There is a require dependency between the variant v1.2 and the variation point

v2. Here

v 2 is an optional feature. As v1.2 is a mandatory feature it will be selected and consequently

v2 is selected. Although it is an optional feature it will be always selected, hence we call it as a false
optional feature. If the relation is an exclude relationv2 will never be selected
Dead feature is a feature that never appears in any legal product from a feature model. As shown in Fig.
7(c) due to exclude relation

v 2.1 will never be part of any valid product from the feature model.

14

Figure 6. Partial feature graph and its sub-graphs

3.3 Analysis Examples

Automatic analysis of variants is already identified as a critical task [14]. Our logical representation can
define and validate a number of analysis operations suggested in [15, 16]. In order to construct an
instance product from the product line model, TRUE (T) is assigned to the selected features and FALSE
(F) to those not selected. These truth values are assigned to the product line model and if TRUE value is
evaluated, we call the model as valid otherwise the model is invalid. For convenience, we represent a
partial feature tree in Fig. 8 which is splitted into smaller sub-graphs (Fig. 8(b), 8(c) and 8(d)).
Example 1: Suppose the selected variants are
the validity of the sub-graphs

v 1 , v 1.1 , v 2 , v 2.1 , v 2.3 , v 2.3.1 , v 2.4 , v 3 and v 3.2 . We check

G1 , G2 and G3 by substituting the truth values of the variants of the

sub-graphs.

G1 :(v 1.1 v 1.2 ) v 1=T

G2 : v 2 v 2.1 v 2.2 v 2.3 v 2.4
v 2 v2.1 v 2.2 ( ( v 2.3 .1 v 2.3 .2 ) v 2.3 ) v 2.4=T
G3 :(v 3.1 v 3.2 ) v 3=T
As the sub-graphs

G1 , G2

and

G3

are evaluate to TRUE, the product model is valid. However,

variant dependencies are not yet considered in this case. Checking the validity of each sub-graph is not
enough for the validity of the whole model. Variant dependencies must also be checked as additional
constraints. We evaluate the dependencies of the selected variants and we get,
Dependency:

( v2.3.1 v 1.1 ) ( v 2.4 v 3.2 )

15

 ( T T ) (T T )=T
The truth (T) value of the dependencies ensures the validity of the product instance
Example 2: Suppose the selected variants are,

v 1 , v 1.2 , v 2 , v 2.3 , v 2.3.1 , v 2.4 , v 3 , v 3.1 . To check whether

these input combination build a valid product we check the validity of the sub-graph

G1 , G2

and

G3 by substituting the truth values of the variants of the sub-graphs.

G1 : ( v 1.1 v 1.2 ) v 1 =T
G 2 :(v 2.1 v 2.2 v 2.3 v 2.4 ) v 2
( v 2.1 v 2.2 ( ( v 2.3 .1 v 2.3.2 ) v 2.3 ) v 2.4 ) v 2=T
G 3 :(v 3.1 v 3.2 ) v 3=T
We then evaluate the dependencies of the selected variants,
Dependency:

( v2.3.1 v 1.1 ) (v 2.4 v 3.1)=F

Due to conflict within variant dependencies, the whole graph becomes invalid, which is due to an
incorrect selection of input.

3.4 Feature Models in Alloy

In order to define feature model in Alloy we first define the abstract syntax of the feature model. A feature
model (FM) has a set of features and one root feature. A FM also has a set of relations and formulas.

sig FM {
features: set Name,
root: feature,
relation: set Relation,
form: Formula
}
sig Name{}
sig Relation{
parent: Name,
child: set Name,
type: Type
}
abstract sig Type{}
one sig Optional, Mandatory, OrFeature,
16

Alternative OptionalAlternative, OptionalOr

extends Type {}
Feature model declares formulas using propositional logic that returns a Boolean value when a
configuration satisfies a formula. An Alloy signature is also declared for binary formulas.
abstract sig Formula {
satisfy: configuration -> one Bool
}
Sig Form extends Formula {
f: Formula,
g: Formula,
op: Op
}
abstract sig Op{}
one sig AndF, OrF, Implies, NotF
extends Op{}
After defining the abstract syntax, the semantics are defined by first defining the configuration which is a
set of feature names. The semantics of FM is then defined as the set of configurations that satisfy all the
relations whereas constraints are denoted as predicates. We also define several constraints over
configurations as well as rules for formula satisfactions.
sig configuration{
value: set Name}
fact configDatatype{
all n:set Name | some c: configuration |
c.value = n
}
pred satisfyRelations (fm: FM, c: Configuration) {
all r: fm.relation {
(r.type = Optional =>
(r.child in c.value =>r.parent in c.value))
(r.type = Mandatory =>
(r.child in c.value<=>r.parent in c.value))
(r.type = Alternative =>
(r.parent in c.value => one n: r.child |n in c.value))
(r.type = OrFeature =>
(r.parent in c.value => some n: r.child |n in c.value))
(r.type = OptionalAlternative =>
(r.parent in c.value => (one n: r.child +no n:r.child) |
n in c.value))
(r.type = OptionalOr =>
(r.parent in c.value =>(some n: r.child +no n:r.child)|
n in c.value)) }}
Similarly, we can define various constraints as well as checking for binary formulas. By using these
definitions we can now specify a feature model.
17

3.5 Examples
We show how the feature diagram in Fig. 8(a) can be constructed from the syntax and semantics defined
in previous section. The feature diagram consists of three sub-graphs. First we define the overall diagram
by using the sub-graphs and their relations and then define the parent-children relations.
one sig G extends FM{}
one sig c1,c2,c3 extends Relation{}
fact elements {
G.root = v
G.feature = G1 + G2 + G3
G.relation = c1 + c2 + c3
}
The parent-child relationship of v1, v2 and v3 as well as their types are defined as follows,
fact relations{
c1.type = Mandatory
c1.parent = v
c1.child = v1
c2.type = Mandatory
c2.parent = v
c2.child = v2
c3.type = Optional
c3.parent = v
c3.child = v3
}
By following the similar steps, each of the sub-graphs can be defined as well. For example, sub-graph G1
along with its child and their types are defined as follows,
one sig G1 extends FM{}
one sig r1 extends Relation{}
fact element{
G1.root = v1
G1.features = v1_1 + v1_2
G1.relation = r1
}
fact relations{
r1.type = Alternative
r1.parent = v1
r1.child = v1_1 + v1_2
}
The sub-graphs G2, G3 and their relations as well as types can also be defined in the same approach.
Alloy checks the consistency of the sub-graphs and variant dependencies and shows that a valid instance
is found. If we select another combination of features as in Example 2 in earlier section, an invalid
18

product would be created and hence in instance should be found. Alloy produce an error stating that no
instance is found from the selected features. Currently, we are performing various other analysis
operations mentioned in [15, 16].

4 Knowledge-based Representation
Various feature relations are modeled using OWL language constructs. By using OWL-DL we model six
types of relations, namely mandatory, optional, alternative, or, optional alternative and optional or. Two
additional constraints: requires and excludes are also modeled. Modeling feature models using OWL have
several advantages, such as facilitating feature model storing, sharing and distributing and assisting
cooperative designing.
First, OWL ontology is built for various nodes and edges in the feature model. The ontology is
constructed in a number of steps.
Step1: We identify the nodes (concepts and features) present in a feature diagram. Each node in the diagram is
modeled as an OWL class. Moreover, we assert that these classes are mutually disjoint. In OWL, all
classes are assumed to overlap unless it is otherwise stated that they are disjoint with each other using a
disjoint axiom. By default, we assume that features with different names are distinct.
Step 2: For each of these nodes in the diagram, we create a Rule class. This Rule class has two kinds of
conditions: firstly, a necessary and sufficient (NS, EquivalentClass) condition, using an existential
restriction to bind the Rule node to the corresponding feature node in the diagram; and secondly, a
number of (possibly 0) necessary (N, subClassOf) constraints later, serving two purposes:
To specify how each of its child features is related to this node, capturing the various relations between
features. To specify how this feature node is constrained by other features, in the form of requires,
excludes, Optional Alternative and Optional Or.
Step 3: The root concept and features in a feature diagram are interrelated by various feature relations,
represented by different edge types in the diagram. In our OWL model, for each of these edges, we create
an object-property. We assert that the range of the property is the respective feature class.
Table 5.Summary of OWL syntax

Notations

Explanation
Superclass of all OWL classes

A B

A is a subclass of B

A B

A and B are disjoint class

A B

Class intersection

A B

Class union

A B

Class equivalence

19

 P . A Range of property is class A

/ P A

allValuesFrom/someValuesFrom restriction, giving the class that

for every instance of this class that has instances of property P,
all/some of the values of the property are members of the class A

The OWL syntax used in this chapter is summarized in Table 5. For a parent feature A and for each of
its child features B1, B2. . ., Bn, the initial modeling produces the following ontology.

hasA ObjectProperty

ARule

hasAA
ARule hasAA

Bi

hasBi ObjectProperty

Bi Rule

hasBi Bi
Bi Rule hasBi Bi

A B i, for 1 i n
B i B j , for 1 i , j n i= j
Now we are ready to model the feature relations using the ontology. The general definition of each of
the four feature relations will be shown, based on the above feature ontology. The ontology will be
constructed incrementally to show the modeling of various feature relations and addition constraints
Mandatory
A mandatory feature is included if its parent feature is included. For each of the mandatory features

B 1 , B2 , ... , B n

of a parent feature A, we use one N constraints in ARule to model it. It is a

someValuesFrom restriction on hasBi, stating that each instance of the rule class must have some instance of
Bi class for

has Bi . The following ontology fragment shows the modeling of mandatory feature set and

parent feature A.

ARule hasB i Bi

It can be seen fromFig. 3 that the root node has a mandatory child feature Reservation Mode, which is
itself a non-leaf node. We create two new classes (parent and child) for these two non-leaf nodes.
For parent feature:
HallBooking
HallBookingRule

hasHallBooking ObjectProperty
hasHallBookingHallBooking
HallBooking has HallBooking HallBooking

For child feature:

ReservMode
ReservMode Rule
20

hasReservMode ObjectProperty
has ReservMode ReservMode
ReservMode Rule hasReservModeReservMode
HallBookingRule hasReservModeReservMode
(This line means that Reservation mode (ReservMode) is a mandatory child)
Optional
An optional feature may or may not be included in a diagram, if its parent is included. For each of the
optional features B1, B2, . . ., Bn of a parent feature A, no additional statement is required to model this
relationship. In that case they are denoted by,
Bi
BiRule

has BiObjectProperty
BiRule hasBiBi

Reservation Charge is an optional feature of Hall Booking and it may, or may not be included in a
configuration of Hall Booking System. As it is a non-leaf node, we create one new class ReservCharge for
Reservation Charge and one object-property hasReservCharge. The ontology is augmented as follows. Note
that no new restriction on HallBooking is added.
ReservCharge
ReservChargeRule

hasReservCharge ObjectProperty
ReservChargeRule hasReservCharge ReservCharge

Alternative
One and only one feature from a set of alternative features can be included, if their parent feature is
included in a configuration. Hence, for a set of alternative features Bi and Bj are two children of parent
feature A, we use disjunction of someValuesFrom restrictions over hasBi and hasBj to ensure that some
feature will be included. We use the complement of distributed disjunction of the conjunction of two
someValuesFrom restrictions to ensure that only one feature can be included. The Or symbol

represents distributed disjunction.

ARule ((hasBiBi) (hasBjBj))
ARule ((hasBiBi) (hasBjBj))

for 1 i n and for 1 j n

for 1 i n and for 1 j n

Fig. 3 shows that features Block and Single are alternate features of Reservation mode. We model this
relation as follows.
ReservMode
ReservModeRule

hasReservModeObjectProperty
hasReservModeReservMode
ReservModeRule has ReservModeReservMode
Block
hasBlockObjectProperty
BlockRule
hasBlock Block
BlockRulehasBlockBlock
ReservModeRulehasBlockBlock
Single
hasSingleObjectProperty
SingleRule
hasSingle Single
SingleRulehasSingle Single
21

ReservModeRulehasSingle Single
RmRule ((hasBlockBlock) (hasSingleSingle))
RmRule (( has BlockBlock) (hasSingleSingle))
The last two restrictions ensure that one and only one feature from the set of alternative features can be
included.
Or
At least one from a set of available features is included, if the parent feature is included. For a set of or
features B1,B2,, Bn of a parent feature A, we need to use a disjunction of someValuesFrom restrictions to
model this relation.

ARule (hasBi Bi), for 1 i n

It may be noticed that the definition of Or is very similar to that of Alternative, with the omission of the
negation of distributed disjunction to allow for multiple or features to be included. In Fig. 3, the feature
Reservation Chargehas a number of Or features. We use the following constructs1 to model it.
ReservCharge
ReservChargeRule
Deposit
DepositRule

hasReservCharge ObjectProperty
ReservChargeRule hasReservCharge ReservCharge
hasDeposit ObjectProperty
hasDepositDeposit
DepositRule hasDepositDeposit
ReservChargeRule hasDepositDeposit

ReservCharge Rule ((hasDepositDeposit)

(hasTax Tax)
(hasBasic_ChargeBasic_Charge)
(hasDiscount Discount))
Optional Or
One or more optional feature may be included when parent feature is included. There is no Optional Or
feature in our brief case study but a detailed feature model consists of such features. If A is parent feature
of child features B and C then OWL-DL representation is defined as follow:
B
BRule
C
CRule
ARule ((hasBB) (hasC C))

hasB ObjectProperty
BRulehasBB
hasCObjectProperty
CRulehasCC

1For brevity, definitions of Rule classes are omitted from here.

22

Optional Alternative
One feature from a set of alternative features may or may not be included if parent is included. Suppose A
is parent feature of child features B and C. We can write the OWL-DL representation as follow:
A
ARule

hasAObjectProperty
hasAA
ARulehasAA
B
hasBObjectProperty
BRule
BRulehasB B
C
hasCObjectProperty
CRule
CRulehasCC
ARule (( has BB) (hasC C))
ARule (( has BB) (hasC C))
Requires
A feature may depend on some other features; hence its presence in a feature configuration requires the
appearance of the others. For a given feature A and a set of features B1, B2. . ., Bn that A requires, besides
the NS condition that binds ARule to A, we make sure that each of the Bi features appears in a
configuration if A is present.

ARule hasBiBi

In Fig 3, if Fax feature requires Printed-Paper, then its OWL representation is as follows.
FaxRule
FaxRule hasFaxFax
Fax hasPrinted_PaperPrinted_Paper
Excludes
The presence of a feature may be inhibited by that of some other features. We say the appearance of a
feature in a configuration excludes the appearance of some other features. For a given feature A and a set
of features B1, B2,Bn that A excludes, we make sure, using the negation of someValuesFrom restriction
on hasBi property, that Arule does not have any Bi feature.

ARule ( hasBiBi)
We encoded the OWL-DL models of the Hall Booking System features into Protg [17] tool. Protg
gives an immediate feedback to the encoded logic by showing the corresponding feature graph ensuring
the preliminary correctness of the syntax as shown in Fig.9.

23

Figure 7. Feature tree definition consistency

4.1 Feature Configuration Verification

In feature modeling, an instance of a concept is a configuration derived from the feature model. When an
instance is checked, the reasoner not only checks inconsistency but also shows which class/classes are
inconsistent. We use an existential restriction for each feature included in the configuration. For each
feature B presents in a feature diagram but not in its configuration, we use a

hasB B restriction to

prevent the reasoning engine from inferring the existence of this feature in the configuration.
If an instance C of a concept is derived from a feature diagram with root concept A and a set of features

B 1 , B2 , . . ., Bn , assuming that

B 1 , B2 , . . ., Bi

appear in the configuration and

B i+1 ,. . . , Bn

do

not, the feature configuration can be modeled as follows,

C ARule
C ( has B j B j , for 1 j i) ( has B k Bk , for i<k n)
Suppose we have a configuration containing a concept instance E and some features of the feature
diagram. We call the instance node the class E.

E HallBookingRule
(hasT ax T ax )(hasRese rvCharge ReservCharge)
E
( hasBasicCharge BasicCharge)(hasReservMode ReservMode)

24

( hasNotification Notification)( hasBlock . Block )

( ha sMultipleRooms MultipleRooms ) ( Fax Fax)

( hasHandleConflict HandleConflict ) (hasDelete Delete)

( hasReservMgt ReservMgt )( hasDeposit Deposit)

( hasDiscount Discount )( hasSingle Single)

( hasPaperPrinted Paperprinted )( hasEmail Email)

( hasAddModify Add Modify )

( hasMultipleT imes MultipleT imes)
RACER [18] shows that the configuration is inconsistent. After closer inspection, it is revealed that
Reservation Management is a mandatory feature of the system, but it is absent in the configuration.

Figure 8. Racer output showing inconsistency in feature configuration

Let us consider a Requires relation between the features Discount and Block from Reservation
Charge and Reservation Mode respectively. A part of the figure is shown in Fig. 11, where the Requires
relation is shown by using a dotted line.

DiscountRule
DiscountRule hasDiscount Discount

DiscountRule hasBlock Block

Suppose the configuration containing a concept instance E and some features for the feature diagram in
Fig 11. We call the instance node as the class E. The feature Block requires Discount, but in the
instances if Block is not selected, the reasoned tool [18] shows inconsistency in the configuration.

25

E HallBooking
(hasReservCha rge ReservCharge)
E
( hasReservMode ReservMode )

( hasDiscount Discount )
( hasBlock Block )

Figure 9. Partial feature diagram with Dependency

5 Discussion
Successful development of software product line requires appropriate organization and management of
products requirements. A significant characteristic of developing product line is the management of the
variants. We have presented a unified approach to modeling variants of a product line. A variant model
has been presented in this chapter which explicitly represents all the variant related information
facilitating the generation of customized products from the domain model. The advantages of the tabular
method are its expressive power, ease of use, traceability, scalability, as well as support for separation of
concern. The tabular approach aloes offers some benefits of improving the variant handling process which
ease the customization process and reduce the complexities that arise due to handling of variants.
Modelling variants is considered as one the crucial factor for the successful deployment of software
product line. This chapter presented an approach to formalizing and verifying SPL feature models to be
able to create a customized product by using formal reasoning techniques. We provided formal semantics
of the feature models by using first-order logic and defined variant selection rules for various variant
scenarios and relationships. We also defined cross-tree variant dependencies. Examples are provided
describing various analysis operations, such as validity, inconsistency, dead feature detection etc. Such
formal definition supports automated decision making during product customization. The various analysis
operation suggested in [15, 16] are also addressed here. To overcome the hurdles of by-hand verification,
we encode our first-order logic representation into Alloy that automatically checks the consistency of
feature configuration and validity of product instances.
We presented a verification approach of product line model by using semantic web technology. OWL-DL
is used to represent feature models and configuration in a concise and unambiguous way. Features are
26

represented as OWL classes and relations as properties. We presented on-going work of consistency
checking using RACER. A through consistency checking is currently undergoing. The OWL-DL
verification of the feature models of system family gives confidence of our previously defined variability
model.
A knowledge-based approach to specifying and verifying feature models is presented in [13]. Comparing
to that presentation, our definition relies on first-order logic which can be directly applied in many
verification tools as in [19]. In contrast to other approaches [14, 20, 21, 22, 23, 24], our proposed method
defines across-graph variant dependencies as well as dependencies between variation point and variants.
Our particular interest is developing a tool to automatically generate customized product based on user
requirement as in [25].
While most approaches applied FOL, very few used semantic web and ontology to model and analyze
feature model. Similar to our approach, OWL-DL has also being used in [26, 27] to analyze feature
diagram. Along with modeling feature using OWL-DL both of them proposed additional tool support to
design feature models. Comparing to these approaches we not only use OWL-DL not check feature
consistency, but also plan to check both domain and product level feature configurations to check the
analysis operations suggested in [15].

References
[1] P. a. N. Clements, L., Software product lines: practices and patterns, illustrated ed.: Addison-Wesley, 2002.
[2] Parnas, D.L.: Software fundamentals. Addison-Wesley Longman Publishing Co.,Inc., Boston, MA, USA
(2001) 193213.
[3] A. Hein, M. Schlick, and R. Vinga-Martins, "Applying feature models in industrial settings," Proceedings of
the first conference on Software product lines : experience and research directions: experience and research
directions, Denver, Colorado, United States, 2000.
[4] Ripon, S.: A unified tabular method for modeling variants of software product line. ACM SIGSOFT Software
Engineering Notes 37(3) (2012) 17. In Pulvermuller, E., Speck, A., Coplien, J., Hondt, M.D., Meuter, W.D.,
eds.:
[5] Jackson, D.: Alloy: a lightweight object modelling notation. ACM Trans. Softw. Eng. Methodol. 11(2) (April

2002) 256290.
[6] Zhang, S., Shen,W., Ghenniwa, H.: A review of internet-based product information sharing and visualization.
Comput. Ind. 54(1) (May 2004) 115.
[7] Horrocks, I., Patel-Schneider, P.F., Harmelen, F.V.: From shiq and rdf to owl: The making of a web ontology
language. Journal of Web Semantics 1 (2003) 2003.
[8] Baader, F., Calvanese, D., Mc Guinness, D.L., Nardi, D., Patel-Schneider, P.F., eds.: The description logic
handbook: theory, implementation, and applications. Cambridge University Press, New York, NY, USA (2003).
[9] Kang, K.C., Cohen, S.G., Hess, J.A., Novak,W.E., Peterson, A.S.: Feature-oriented domain analysis (FODA)
feasibility study. Technical report, Carnegie-Mellon University Software Engineering Institute (November
1990).
[10] Kang, K.C., Kim, S., Lee, J., Kim, K., Shin, E., Huh, M.: Form: A feature-oriented reuse method (FORM) with
domain-specific reference architectures. Ann. Softw. Eng. 5 (January 1998) 143168.
[11] Czarnecki, K., Eisenecker, U.W.: Generative programming: methods, tools, and applications. ACM
Press/Addison-Wesley Publishing Co., New York, NY, USA (2000)

27

[12] Y. C. Cheong and S. Jarzabek, "Frame-based method for customizing generic software architectures,"
presented at the Proceedings of the 1999 symposium on Software reusability, Los Angeles, California, United
States, 1999.
[13] A. O. Elfaki, S. Phon-Amnuaisuk, and C. K. Ho. Knowledge based method to validate feature models. In S.
Thiel and K. Pohl, editors, SPLC (2), pages 217225. Lero Int. Science Centre, University of Limerick,
Ireland, 2008.
[14] M. Janota and J. Kiniry. Reasoning about feature models in higher-order logic. In SPLC, pages 1322. IEEE
Computer Society, 2007.
[15] D. Benavides, A. R. Cortes, P. Trinidad, and S. Segura. A survey on the automated analyses of feature models.
In JISBD, pages 367376, 2006.
[16] D. Benavides, S. Segura, and A. R. Cortes. Automated analysis of feature models 20 years later: A literature
review. Inf. Syst., 35(6):615636, 2010.
[17] Noy, N.F., Sintek, M., Decker, S., Crubezy, M., Fergerson, R.W., Musen, M.A.: Creating semantic web
contents with protege-2000. In: Protg-2000. IEEE Intelligent Systems (2001. (2001) 6071.
[18] Haarslev, V., Mller, R.: Racer user guide and reference manual - version 1.7.6 (2002).
[19] J. Sun, H. Zhang, and H. Wang. Formal semantics and verification for feature modeling. In Proceedings of the
10th IEEE International Conference on Engineering of Complex Computer Systems, ICECCS 05, pages 303
312, Washington, DC, USA, 2005. IEEE Computer Society.
[20] D. S. Batory. Feature models, grammars, and propositional formulas. In J. H. Obbink and K. Pohl, editors,
SPLC, volume 3714 of LNCS, pages 720. Springer, 2005.
[21] D. Benavides, P. Trinidad, and A. Ruiz-Cortes. Automated reasoning on feature models. In Proceedings of the
17th international conference on Advanced Information Systems Engineering, CAiSE05, pages 491503,
Berlin, Heidelberg, 2005. Springer-Verlag.
[22] K. Czarnecki and M. Antkiewicz. Mapping features to models: A template approach based on superimposed
variants. In R. Gluck and M. R. Lowry, editors, GPCE, volume 3676 of LNCS, pages 422437. Springer, 2005
[23] M. Mannion. Using first-order logic for product line model validation. In Proceedings of the Second
International Conference on Software Product Lines, SPLC 2, pages 176187, London, UK, 2002. SpringerVerlag.
[24] W. Zhang, H. Zhao, and H. Mei. A Propositional Logic-Based Method for Verification of Feature Models. In J.
Davies, W. Schulte, and M. Barnett, editors, Formal Methods and Software Engineering, volume 3308 of
LNCS, chapter 16, pages 115130. Springer Berlin / Heidelberg, 2004
[25] P. Trinidad, D. Benavides, A. Ruiz-Cortes, S. Segura, and A. Jimenez. Fama framework. In Proceedings of the
2008 12th International Software Product Line Conference, SPLC 08, pages 359, Washington, DC, USA,
2008. IEEE Computer Society.
[26] Wang, H.H., Li, Y.F., Sun, J., Zhang, H., Pan, J.: Verifying feature models using owl. Web Semantics. 5(2)
(June 2007) 117129.
[27] Noorian, M., Ensan, A., Bagheri, E., Boley, H., Biletskiy, Y.: Feature model debugging based on description

logic reasoning. In: DMS, Knowledge Systems Institute (2011) 158164.

28