1. Feature modeling and Verification based on Description Logics
SEKE2012, Redwood City, CA, USA
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

2. Contents 1 Introduction 2 Semantic feature modeling 3 Case study
4 Conclusions

3. 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)

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

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

6. Fig. 1 Feature model of graph editor

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

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

9. Fig.2 Feature model in lifecycle of S.P.

10. 2 Semantic Feature modeling
DLs
DLs-based feature modeling
Constraints of the feature model
Reasoning for verification

11. 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
Language family：AL, ALC, ALCN, ALCQ, SHIQ…
expressive power vs decidability
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+| R-
for example:
Father ::= Person ⊓ hasChild.Person
hasParent ::=¬hasChild

12. 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 …
ABox
Person(mike), Father(ben)
hasChild(ben,mike) …

13. 2.2 Semantic Feature modeling
Feature class
Relations between features

14. Feature class Feature def. in DL:
Feature ::= ⊤ ⊓ hasBindTime.BindTime ⊓ hasState.BindState
BindTime ::= {reuseTime, compileTime, runTime}
BindState ::= {bound, removed, undecided, conflict }

15. A dimension feature (DimFeature): is the sub-class of concept Feature
concept DimValue is the sub-class of Feature
DimFeature::=Feature ⊓  hasValue.DimValue
DimValue ⊑ Feature
Fig. 4a Feature meta-model (concepts)

16. Relations between features
Whole-part relation: hasPart
Its domain, range : Feature
Two sub-relation: hasOptionalPart, hasMandatoryPart
Express as inclusion axioms ：
hasOptionalPart ⊑ hasPart, hasMandatoryPart ⊑ hasPart
Fig. 4b Feature meta-model (roles and constraints)

17. 2.3 Constraints of the feature model
Mutex (also called exclude)
the mutual exclusion constraints between two feature instances
require
the dependency constraints between two feature instances

18. We define a set of rules to describe constraints:
Alternative-Rule
Mutex-Rule:
Require-Rules
Conflict-Rule

19. Mutex rule
two instances of Feature are mutually exclusive, i.e., they cannot be bound at the same time.
Mutex-Rule: f1f2 Feature(f1)Feature(f2)hasState(f1,bound) mutex(f1,f2)  hasState(f2, removed)

20. 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)

21. Require rules Require describes the dependency constraints
Three rules, for two instances of feature f1 and f2 :
1: f1 has a mandatory child f2 means that f2 depends on f1
2: If f1 is bound, then f2 must be bound
3: If f1 is removed, then f2 must be removed
Require-Rule1: f1f2 Feature(f1) Feature(f2) hasMandatoryPart (f1, f2)  require(f2, f1)
Require-Rule2: f1f2 Feature(f1) Feature(f2) hasState(f2,bound) require(f2, f1)  hasState(f1,bound)
Require-Rule3: f1f2 Feature(f1) Feature(f2) hasState(f1,removed) require(f2, f1)  hasState(f2,removed)

22. 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)

23. Reasoning for its verification
Before reasoning, establish the TBox and ABox:
TBox:
Define concepts and roles for feature model
define include axioms
Define rules for constraints
ABox:
Define the assertions for domain-specific features instances
TBox
Feature ::= ⊤ ⊓ hasBindTime.BindTime ⊓ hasState.BindState
DimFeature ⊑ Feature, DimValue ⊑ Feature …
hasPart, hasOptionalPart ⊑ hasPart, hasMandatoryPart ⊑ hasPart
Alternative-Rule, Mutex-Rule , Require-Rule1 , Require-Rule2 , Require-Rule3
ABox
Feature(f1), hasMandatoryPart(f1, f2), requre(f2, f3)

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

25. 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)}

26. 3 Case study
Feature modeling : graph editor
Its verification

27. 3.1Semantic model of graph editor
The graph editor is typical, easy to understand.
Feature model of graph editor
variation point feature
Run time bind
optional，
reuse/compile bind

28. DL knowledge base TBox (meta-model) ABox (model instance)
concepts / roles
Inclusion axioms
rules
ABox (model instance)
assersions

29. 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]
[2]
[3]
[4]

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

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

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

33. weakness
Some non-functional features are not taken into considerations;
How to elicit feature in a domain depends on expertise experience.

34. Thank you! Guohua Shen College of Computer Science and Technology
College of Computer Science and Technology
Nanjing University of Aeronautics and Astronautics
Nanjing, China