SEKE 2012 Proceedings - Knowledge Systems Institute

Feature modeling and Verification based on
Description Logics
Guohua Shen, Zhiqiu Huang, Changbao Tian, Qiang Ge
College of Computer Science and Technology
Nanjing University of Aeronautics and Astronautics
Nanjing, China
{ghshen, zqhuang}@nuaa.edu.cn
Abstract Most of the current domain engineering methods have adopted
the feature model as a domain requirements capturing model. But these
methods lack the semantic description of the feature model and the
relationship between features. This has led to the redundancy and confusion
in feature model representation between different domain engineering
methods. In this paper, a description logics-based feature model, including
the feature class and the constraints of the features, is presented. A group of
rules for constraints are proposed, which are used to verify the consistency
and completeness of feature model instances. Then, combining with a real
software domain, the modeling process of the feature model with
description logic and its verification are discussed systematically.
Keywords feature model; requirements engineering; software reuse;
model verification; description logics
I. INTRODUCTION
Software Product Line (SPL) is an important way to reuse software
domain assets. SPL practices guide organizations towards the
development of products from existing assets rather than the
development of separated products one by one from scratch. Thus,
features can be shared among all software products in domain. The
feature model has been widely adopted as a domain requirements
capturing model by most of the current domain methods, such as
FODA [1], FORM [2], FeatuRSEB [3], PuLSE [4] and SPL [5].
Description logics (DLs) are a family of languages for representing
knowledge and reasoning about it. There are several studies proposing
the usage of DL to analyze feature models, such as [6,7,8]. Intuitively, a
domain-specific feature model is a concrete instance of meta-model.
However, these methods do not rigorously differentiate between the
feature meta-model and feature models (i.e., instances of meta-model).
New concepts, roles and constraints are created for every domain
feature model, which causes additional efforts and bloating in the
numbers of concepts, roles and constraints. Actually, the feature metamodel
is domain-independent and built for only once, while feature
models are domain-dependent and must be instantiated for each
domain by domain engineers.
II.
FEATUREMODEL
A. Feature
The features define both common aspects of the domain as well as
differences among all products of a SPL. A Feature is a distinctive
characteristic of a product, and it may refer to a requirement, a
component or even to pieces of code [9].
Wei Zhang
School of Electronics Engineering and Computer Science
Peking University
Beijing, China
zhangw@sei.pku.edu.cn
A feature model is a compact representation of all potential
products of a SPL. Feature models are used to model SPL in terms of
features and relations among them.
B. Feature-Oriented model
The feature model is an abstraction of commonality and variability
in a software family across a domain. Most proposals organize feature
in hierarchy, and the parent feature is composed of children features.
Figure 1 describes the feature model of the graph editor domain.
graph-compose
entity-add
graph-add
graph-select
connector-add
select-mode
increment-select
alternative
or
feature
optional
Figure 1.
graph-manipulate
graph-delete
hori-constraint
nonincrement-select
moving-constraint
graph-move
verti-constraint
dimension-value
outline-move
whole-part relation
Feature model of graph editor.
moving-mode
graph-dim
3D
2D
content-move
require
mutex
The feature model describes the variability in two ways: i) the
feature is optional; ii) the feature is a variation point (vp-feature, also
called dimension feature [10]), which attaches some value features. For
example, the feature moving-constraint is optional for its parent feature
graph-move,andthefeaturemoving-mode is a dimension feature with
two different values: content-moving and outline-moving (see Figure 1).
C. Feature Model Tailoring
Feature modeling is an activity of development for reuse. We
customize a specific software product specification through tailoring.
The system can be changed at certain time in the system’s lifecycle.
Selecting some variant of the feature model is called binding the variant.
Every variation point has at least one associated binding time. There are
three types of binding time: reuse-time,compile-time and run-time.
Every feature has the binding states like bound, removed and
undecided. A bound feature means that if its pre-conditions are
satisfied, this feature will be executed. A removed feature means that it
422