Presentation is loading. Please wait.

Presentation is loading. Please wait.

Feature modeling and Verification based on Description Logics

Similar presentations

Presentation on theme: "Feature modeling and Verification based on Description Logics"— Presentation transcript:

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

Download ppt "Feature modeling and Verification based on Description Logics"

Similar presentations

Ads by Google