Feature modeling and Verification based on Description Logics

1. SEKE2012, Redwood City, CA, USA 2012.7.1 -- 2012.7.3 Feature modeling and Verification based onDescription 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 • 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. 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) 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

24. conflict • 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)}

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. variation point feature Run time bind optional， reuse/compile bind 3.1Semantic model of graph editor • The graph editor is typical, easy to understand. • Feature model of graph editor

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

30. conflict conflict • 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) }

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 ghshen@nuaa.edu.cn http://www.nuaa.edu.cn College of Computer Science and Technology Nanjing University of Aeronautics and Astronautics Nanjing, China