360 likes | 518 Views
SEKE2012, Redwood City, CA, USA 2012.7.1 -- 2012.7.3. 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. Contents. 1 Introduction
E N D
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
Contents • 1 Introduction • 2 Semantic feature modeling • 3 Case study • 4 Conclusions
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)
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
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.
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.
Feature model binding&tailoring • binding states: • bound, removed and undecided. • We customize a specific S.P. specification through binding and tailoring. • Tailoring: undecidedremoved • Binding: undecidedbound
2 Semantic Feature modeling • DLs • DLs-based feature modeling • Constraints of the feature model • Reasoning for verification
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
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) …
2.2 Semantic Feature modeling • Feature class • Relations between features
Feature class • Feature def. in DL: Feature ::= ⊤ ⊓ hasBindTime.BindTime ⊓ hasState.BindState BindTime ::= {reuseTime, compileTime, runTime} BindState ::= {bound, removed, undecided, conflict }
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)
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)
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
We define a set of rules to describe constraints: • Alternative-Rule • Mutex-Rule: • Require-Rules • Conflict-Rule
Mutex rule • two instances of Feature are mutually exclusive, i.e., they cannot be bound at the same time. Mutex-Rule: f1f2 Feature(f1)Feature(f2)hasState(f1,bound) mutex(f1,f2) hasState(f2, removed)
Alternative rule • Alternative: only one instantce of DimValue can be bound. (alternative constraint implies mutex) Alternative-Rule: f1f2f3 DimFeature(f1)DimValue(f2)DimValue(f3)hasAlternativeValue(f1,f2) hasAlternativeValue(f1,f3) mutex(f2,f3)
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: f1f2 Feature(f1) Feature(f2) hasMandatoryPart (f1, f2) require(f2, f1) Require-Rule2: f1f2 Feature(f1) Feature(f2) hasState(f2,bound) require(f2, f1) hasState(f1,bound) Require-Rule3: f1f2 Feature(f1) Feature(f2) hasState(f1,removed) require(f2, f1) hasState(f2,removed)
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)
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
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)}
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)}
3 Case study • Feature modeling : graph editor • Its verification
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
DL knowledge base • TBox (meta-model) • concepts / roles • Inclusion axioms • rules • ABox (model instance) • assersions
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/
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) }
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.
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.
weakness • Some non-functional features are not taken into considerations; • How to elicit feature in a domain depends on expertise experience.
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