Presentation is loading. Please wait.

Presentation is loading. Please wait.

Feature modeling and Verification based on Description Logics Guohua Shen 1, Zhiqiu Huang 1, Wei Zhang 2 1 Nanjing Univ. of Aeronautics and Astronautics,

Similar presentations


Presentation on theme: "Feature modeling and Verification based on Description Logics Guohua Shen 1, Zhiqiu Huang 1, Wei Zhang 2 1 Nanjing Univ. of Aeronautics and Astronautics,"— Presentation transcript:

1 Feature modeling and Verification based on Description Logics Guohua Shen 1, Zhiqiu Huang 1, Wei Zhang 2 1 Nanjing Univ. of Aeronautics and Astronautics, China 2 Peking Univ., China SEKE2012, Redwood City, CA, USA

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 |{a 1, …,a n } 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 Constraints  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 optional , reuse/compile bind variation point feature Run time bind

28 DL knowledge base TBox (meta-model)  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/ Pellet 2 / RacerPro 3 Rule language:  e.g., [Require-Rule1: (?f1 hasMandatoryPart ?f2)  (?f2 require ?f1)] Query language: SPARQL 4  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 Nanjing University of Aeronautics and Astronautics Nanjing, China


Download ppt "Feature modeling and Verification based on Description Logics Guohua Shen 1, Zhiqiu Huang 1, Wei Zhang 2 1 Nanjing Univ. of Aeronautics and Astronautics,"

Similar presentations


Ads by Google