SEKE 2012 Proceedings - Knowledge Systems Institute

hasOptionalPart hasPart
hasMandatoryPart hasPart
The role hasValue, which is sub-role of role hasPart, describes the
relation between concept DimFeature and DimValue. The sub-role
relation is defined in GRI axiom as:
hasValue hasPart.
Figure 3 depict the roles, and their inclusion relation.
C. Constraints of the feature model
Several methods proposed their own constraints of the model. E.g.,
the semantic between vp-feature and variant features in FeatuRSEB [3]
is somewhat similar to the one between dimension feature and value
features in FODM [10]. However, the “require”, “mutual exclusion” in
FODA [1], and “OR”, “XOR” constraints in FeatuRSEB are redundant
and easy to cause confusion among different methods. In this paper, we
define roles require and mutex, to describe the dependency and mutual
exclusion constraints respectively (see Figure 3).
We define a role hasAlternativeValue, which is sub-role of role
hasValue,to indicate the mutual exclusion constraints.
hasAlternativeValue hasValue.
We use DLs to describe the semantic of constraints between
features. The rules are defined in DLs knowledge base.
Alternative-Rule: f1f2f3 DimFeature(f1)DimValue(f2)
DimValue(f3)hasAlternativeValue(f1,f2)hasAlternativeValue(f1,f3)
mutex(f2,f3)
Mutex-Rule:f1f2 Feature(f1)Feature(f2) hastate(f1,bound)
mutex(f1,f2) hasState(f2, removed)
The alternative-rule indicates that f2 and f3 are mutually exclusive.
The mutex-rule means that f1 and f2 are instances of Feature,and
they are mutually exclusive, if f1 is bound,then f2 must be removed.
The role hasMandatoryPart expresses the dependency constraint
implicatively. That is, feature instance f1 has a mandatory child feature
f2 means that f2 depends on f1 (see require rule1). If f2 is bound, then f1
must be bound (see require rule2). If f1 is removed, then f2 must be
removed (see require rule3).
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)
D. Reasoning about model for its verification
There are some basic inference issues considered in the reasoning
about consistency and completeness of feature model. In order to
reason about consistency, we define the state conflict by using the
following conflict rule, which 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)
Definition 1. consistency
For knowledge base K=(T,A), the ABox A, in which the feature
model is described, is consistent with respect to (w.r.t.) the TBox T if
there is no state conflict.
Definition 2. completeness
For K=(T,A), the ABox A, in which the feature model is described,
is complete w.r.t. the TBox T if all the assertions necessary are included.
IV. CASE STUDY
We take the graph editor system as an example, and analyze its
feature modeling and verification based on DLs. The graph editor is
used for manipulating and displaying graphs in domains such as
CAD/CAM. It is a relatively simple, easy to understand domain system.
A. Semantic model of graph editor
Though the notations of the graphs have different semantic, we can
abstract features, which can be shared among all graph software.
In graph editor, graph manipulation is a key function; it controls the
lower level functions such as graph addition, selection, deletion,
moving and composition. These lower level functions are bound in
reuse time, and graph composition is optional. Figure 1 depicts its
typical feature model.
B. Reasoning about feature model of graph editor
Figure 4.
Feature meta-model definition in Protégé.
We adopt Protégé3.4.4 2 as OWL editor, Jena 3 as ontology API.
Jena is a Java framework for ontology application. It provides a
programmatic environment for OWL, query language SPARQL 4 and
includes a rule-based inference engine and SPARQL query engine.
First, we create the feature meta-model according to the DLs-based
modeling method (see Section 3.2) in Protégé. That is, we define the
concepts, roles and constraints (see Figure 4).
Second, we use rule language to describe all rules.
2 http://protege.stanford.edu/
3 http://jena.sourceforge.net/
4 http://www.w3.org/TR/rdf-sparql-query/
424