Download
feature modeling and verification based on description logics n.
Skip this Video
Loading SlideShow in 5 Seconds..
Feature modeling and Verification based on Description Logics PowerPoint Presentation
Download Presentation
Feature modeling and Verification based on Description Logics

Feature modeling and Verification based on Description Logics

122 Vues Download Presentation
Télécharger la présentation

Feature modeling and Verification based on Description Logics

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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