SEKE2012, Redwood City, CA, USA
2012.7.1 -- 2012.7.3
Feature modeling and Verification
based on Description Logics
Guohua Shen1, Zhiqiu Huang1 , Wei Zhang2
1 Nanjing Univ. of Aeronautics and Astronautics, China
2 Peking Univ., China
Contents

1 Introduction

2 Semantic feature modeling

3 Case study

4 Conclusions
1 Introduction

The feature model has been widely adopted by
most of the current domain engineering methods

FODA [1] (Feature-Oriented Domain Analysis),

FORM [2] (Feature-Oriented Reuse Method),

FeatuRSEB [3] (Feature and Reuse-driven Software Engineering
Business),

PuLSE [4] (Product Line Software Engineering) and

SPL [5] (Software Product Line)
Feature modeling base on DLs

DLs(Description logics) are a family of languages
for representing knowledge & reasoning about it

Some existing research work used DL to
analyze feature models, such as [6,7,8].

However, these methods do not differentiate
between the feature meta-model and feature
models, which causes additional efforts :
 New
concepts, roles and constraints are created for
every domain feature model
Feature

What is a feature:

a distinctive characteristic of a software product, and it may refer
to a requirement, a component or even to pieces of code of a
SPL.

The features define both common aspects of the domain as well
as differences among all products of a SPL.
graph-manipulate
graph-compose
graph-add
graph-select
graph-delete
graph-move
graph-dim
moving-constraint
entity-add connector-add
moving-mode
3D
2D
select-mode
hori-constraint
increment-select
nonincrement-select
verti-constraint
outline-move
content-move
alternative
feature
dimension-value
require
or
optional
whole-part relation
mutex
Fig. 1 Feature model of graph editor
Feature model binding&tailoring


Selecting some variant of the feature model is
called binding the variant.
three types of binding time:
 reuse-time,
compile-time and run-time.
Feature model binding&tailoring

binding states:
 bound,

removed and undecided.
We customize a specific S.P. specification
through binding and tailoring.
 Tailoring:
undecided  removed
 Binding:
undecided  bound
reuse dev.
dev. for reuse
dev. with reuse
bind time
reuse-time
compile-time, load-time
feature model
tailor
run-time
feature model run-time 1 of sys.A
of sys.A
domain feature model
feature model
run-time 2 of sys.A
of sys.B
bound feature
Fig.2 Feature model in lifecycle of S.P.
2 Semantic Feature modeling

DLs

DLs-based feature modeling

Constraints of the feature model

Reasoning for verification
2.1 description logics, DLs

DL: decidable fragment of FOL (first order logic)

Basic elements:


Concepts: e.g., Person、Father
Roles, also called Properties: e.g., hasChild
C::=A|⊥| ⊤ |¬C|C⊓D | C⊔D|R.C | R.C |nR.C |nR |{a1,…,an}
R::=P|¬R|R⊓S |R⊔S| R◦S| R+| Rfor example:
Father ::= Person ⊓ hasChild.Person
hasParent ::=¬hasChild

Language family：AL, ALC, ALCN, ALCQ, SHIQ…

expressive power vs decidability

DL knowledge base: K = (T, A)，
T
(Terminology), i.e., TBox : concepts, axioms
 A (Assertion),
i.e., ABox :assertions
TBox
Person, Parent= Person ⊓ hasChild
hasChild, Parent ⊑ Person, hasSon ⊑
hasChild …
TBox
Description
Language
Reasoning
ABox
Person(mike), Father(ben)
hasChild(ben,mike) …
KB
Application
Programs
ABox
Rules
Fig. 3 Architecture of DL knowledge base
2.2 Semantic Feature modeling

Feature class

Relations between features
Feature class

Feature def. in DL:
Feature ::= ⊤ ⊓ hasBindTime.BindTime ⊓ hasState.BindState
BindTime ::= {reuseTime, compileTime, runTime}
BindState ::= {bound, removed, undecided, conflict }

A dimension feature (DimFeature): is the subclass of concept Feature
DimFeature::=Feature ⊓  hasValue.DimValue

concept DimValue is the sub-class of Feature
BindTime
BindState
DimValue ⊑ Feature
hasState
Feature
hasBindingTime
hasPart
DimFeature hasValue DimValue
property
concept
sub-concept/property
Fig. 4a Feature meta-model (concepts)
Relations between features

Whole-part relation: hasPart
 Its

domain, range : Feature
Two sub-relation: hasOptionalPart,
hasMandatoryPart
 Express
as inclusion axioms ：
hasOptionalPart ⊑ hasPart, hasMandatoryPart ⊑ hasPart
require
hasPart
mutex
hasValue
Feature
hasOptionalPart hasMandatoryPart
hasPart
hasAlternativeValue
property
concept
sub-concept/property
Fig. 4b Feature meta-model (roles and constraints)
2.3 Constraints of the feature model

Constraints
 Mutex

(also called exclude)
the mutual exclusion constraints between two feature
instances
 require

the dependency constraints between two feature instances

We define a set of rules to describe constraints:
 Alternative-Rule
 Mutex-Rule:
 Require-Rules
 Conflict-Rule
Mutex rule

two instances of Feature are mutually exclusive, i.e.,
they cannot be bound at the same time.
Feature
mutex
Mutex-Rule: f1f2 Feature(f1)Feature(f2)hasState(f1,bound)
mutex(f1,f2)  hasState(f2, removed)
Alternative rule

Alternative: only one instantce of DimValue can
be bound. (alternative constraint implies mutex)
Alternative-Rule: f1f2f3
DimFeature(f1)DimValue(f2)DimValue(f3)hasAlternativeValue(f1,f2)
hasAlternativeValue(f1,f3)  mutex(f2,f3)
Require rules
Feature

Require describes the dependency constraints

Three rules, for two instances of feature f1 and f2require
:

1: f1 has a mandatory child f2 means that f2 depends on f1
Require-Rule1: f1f2 Feature(f1) Feature(f2) hasMandatoryPart
(f1, f2)  require(f2, f1)

2: If f1 is bound, then f2 must be bound
Require-Rule2: f1f2 Feature(f1) Feature(f2)
hasState(f2,bound) require(f2, f1)  hasState(f1,bound)

3: If f1 is removed, then f2 must be removed
Require-Rule3: f1f2 Feature(f1) Feature(f2)
hasState(f1,removed) require(f2, f1)  hasState(f2,removed)
Conflict rule

we define the state conflict by using the following
conflict rule,

It indicated that a feature instance f1 has the two
states: bound and removed at the same time,
then f1 has the state conflict.
Conflict-Rule: f1 Feature(f1)  hasState(f1,bound) hasState(f1,removed)
 hasState(f1,conflict)
Reasoning for its verification

Before reasoning, establish the TBox and ABox:
TBox
 TBox:

Define
concepts
and roles for feature
model
Feature
::= ⊤ ⊓ hasBindTime.BindTime
⊓ hasState.BindState

DimFeature
⊑ Feature,
define
include
axiomsDimValue ⊑ Feature …
hasPart, hasOptionalPart ⊑ hasPart, hasMandatoryPart ⊑ hasPart
 Define rules for constraints
Alternative-Rule, Mutex-Rule , Require-Rule1 , Require-Rule2 ,
Require-Rule3
 ABox:

Define the assertions for domain-specific features instances
ABox
Feature(f1), hasMandatoryPart(f1, f2), requre(f2, f3)

Verify by reasoning
 consistency

the feature model is consistent, if there is no state conflict. ;

For example
A={Feature(f1), mutex(f1, f2), Feature(f2) , hasState(f1, bound), hasState(f2, bound) }
=>
A’={Feature(f1), mutex(f1, f2), Feature(f2) , hasState(f1, bound), hasState(f2, bound) ,
hasState(f2, removed), hasState(f1, removed) }
conflict
 completeness

feature model is complete, if all the assertions necessary are
included

For example:
A={ Feature(f1), Feature(f2), hasMandatoryPart(f1, f2), hasState(f1, bound) } =>
A’={Feature(f1), Feature(f2), hasMandatoryPart(f1, f2), hasState(f1, bound) , require(f1,
f2), hasState(f2,bound)}
3 Case study

Feature modeling : graph editor

Its verification
3.1Semantic model of graph editor


The graph editor is typical, easy to understand.
variation point feature
Run time bind
Feature model of graph editor
graph-manipulate
graph-compose
graph-add
graph-select
graph-delete
graph-move
graph-dim
moving-constraint
entity-add connector-add
moving-mode
3D
2D
select-mode
optional，
reuse/compile bind
hori-constraint
increment-select
nonincrement-select
verti-constraint
outline-move
content-move
alternative
feature
dimension-value
require
or
optional
whole-part relation
mutex
DL knowledge base

TBox (meta-model)
 concepts
/ roles
 Inclusion
axioms
 rules

ABox (model instance)
 assersions
3.2 Reasoning about feature model
of graph editor

Ontology editor:Protégé1

Ontology language:OWL

reasonor:Jena/ Pellet2 / RacerPro3

Rule language:


e.g., [Require-Rule1: (?f1 hasMandatoryPart ?f2)  (?f2 require ?f1)]
Query language: SPARQL4

e.g., "SELECT ?x WHERE {?x hasState conflict}"
[1] http://protege.stanford.edu/
[2] http://pellet.owldl.com/
[3] http://www.racer-systems.com/
[4] http://www.w3.org/TR/rdf-sparql-query/

Case : feature ”graphDelete” requires “graphSelect”.
A={Feature(graphManipulate), Feature(graphDelete), Feature(graphSelect),
hasState(graphDelete,bound), hasState(graphSelect,removed), require(graphDelete,graphSelect) }
== using Require-Rule2, 3 ==>
A’={……, hasState(graphDelete,removed), hasState(graphSelect,bound) }
== using Conflict-Rule ==>
A’’={……, hasState(graphDelete, conflict), hasState(graphSelect, conflict) }
conflict
conflict
graph-manipulate
graph-select
graph-delete
......
isBound
4 Conclusions

We propose a DLs-based method to model
feature:
 describing
feature meta-model with concepts, roles,
axioms and rules in TBox,
 while
describing feature model with assertions in
ABox.

We can reason about the semantic feature
model to verify the consistency and
completeness by using DLs reasoner.
strengths

Our feature model is compatible with the common
feature models (such as FODA, FORM, PLA and FODM).

The explicit semantic clarifies the similarity and
differences among these methods.

This model differentiates the meta-model and model.

Concrete feature models are instantiated in ABox, so it is
convenient to perform running-time verification.
weakness

Some non-functional features are not taken into
considerations;

How to elicit feature in a domain depends on
expertise experience.
Thank you!
Guohua Shen
ghshen@nuaa.edu.cn
http://www.nuaa.edu.cn
College of Computer Science and Technology
Nanjing University of Aeronautics and Astronautics
Nanjing, China