What email address or phone number would you like to use to sign in to Docs.com?
If you already have an account that you use with Office or other Microsoft services, enter it here.
Or sign in with:
Signing in allows you to download and like content, and it provides the authors analytical data about your interactions with their content.
Embed code for: Verifying feature models using OWL
Select a size
Journal of Web Semantics 2007
Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 Verifying feature models using OWL Hai H. Wanga,∗, Yuan Fang Lib, Jing Sunc, Hongyu Zhangd, Jeff Pane a University of Southampton, UK b National University of Singapore, Singapore, Singapore c The University of Auckland, Auckland, New Zealand d Tsinghua University, China e The University of Aberdeen, Aberdeen, UK Received 7 June 2006; accepted 10 November 2006 Available online 20 January 2007 Abstract Feature models are widely used in domain engineering to capture common and variant features among systems in a particular domain. However, the lack of a formal semantics and reasoning support of feature models has hindered the development of this area. Industrial experiences also show that methods and tools that can support feature model analysis are badly appreciated. Such reasoning tool should be fully automated and efﬁcient. At the same time, the reasoning tool should scale up well since it may need to handle hundreds or even thousands of features a that modern software systems may have. This paper presents an approach to modeling and verifying feature diagrams using Semantic Web OWL ontologies. We use OWL DL ontologies to precisely capture the inter-relationships among the features in a feature diagram. OWL reasoning engines such as FaCT++ are deployed to check for the inconsistencies of feature conﬁgurations fully automatically. Furthermore, a general OWL debugger has been developed to tackle the disadvantage of lacking debugging aids for the current OWL reasoner and to complement our veriﬁcation approach. We also developed a CASE tool to facilitate visual development, interchange and reasoning of feature diagrams in the Semantic Web environment. © 2007 Elsevier B.V. All rights reserved. Keywords: Semantic Web; OWL; Ontologies; Feature modeling 1. Introduction Domain engineering is a software reuse approach that focuses on a particular application domain. Examples of dif- ferent domains are word processing, device driver for network adapters, inventory management systems, etc. In domain engi- neering, we perform domain analysis and capture domain knowledge in the form of reusable software assets. By reusing the domain assets, an organization will be able to deliver a new product in the domain in a shorter time and at a lower cost. In industry, domain engineering forms a basis for software product line practices . Feature modeling  plays an important role in domain engineering. Features are prominent and distinctive user visible characteristic of a system. Systems in a domain share common ∗ Corresponding author. Tel.: +44 2380593268; fax: +44 2380592865. E-mail addresses: firstname.lastname@example.org (H.H. Wang), email@example.com (Y.F. Li), firstname.lastname@example.org (J. Sun), email@example.com (H. Zhang), firstname.lastname@example.org (J. Pan). features and also differ in certain features. In feature modeling, we identify the common and variant features and capture them as a graphical feature diagram. Feature modeling is considered as “the greatest contribution of domain engineering to software engineering” . Quite a number of feature-based reuse approaches have been proposed, such as FODA (Feature-Oriented Domain Analysis) , FORM (Feature-Oriented Reuse Method)  and Fea- tuRSEB . However, there is a lack of methods and tools that can support analysis over a feature model. Such methods and tools should provide us with a means of verifying the correct- ness of a feature model as the design of a feature model may be inconsistent. Once we have chosen a combination of features (a feature conﬁguration) for a speciﬁc software product, such toolsshouldbeabletocheckthecorrectnessoftheconﬁguration based on the constraints deﬁned in the feature model. Further- more, feature models may evolve when the knowledge of the domain increases. Thus when features are added/removed, such tools should enable us to check if a feature conﬁguration is still valid. Industrial experiences show that in large scale software product line development, the number of features (variabilities) 1570-8268/$ – see front matter © 2007 Elsevier B.V. All rights reserved. doi:10.1016/j.websem.2006.11.006 118 H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 could be thousands and as a result, a substantial amount of effort is spent on correcting these human errors . Due to the absence of a formal semantics of features and feature modeling, there is no mature tool that can check the correctness of a particular feature conﬁguration based on the constraints speciﬁed in a feature model. Ideally, such a tool should bear a number of requirements: Automatedinconsistencydetection.Differentfeaturerequire- ments may be contradictory and the product conﬁguration may be invalid respecting to the feature model. In order to pre- vent inconsistent products being combined from incompatible features,itisimportantthatinconsistenciescanbedetectedauto- matically. It allows the domain experts to focus only on the system to be built, rather than the usability of the tool. Fur- thermore, the automation also enables the computer agents to compose software products run-timely based on users demands. Reasoning efﬁciency. As a feature model may evolve con- stantly, specially for the dynamic re-conﬁgured feature systems, it requires the feature reasoning tool be able to conclude the validity of conﬁgurations in very short time. Scalability. Modern software could be very large. Applica- tions like Microsoft Windows OS have thousands of different features. The manual checking of such models/conﬁgurations are highly painstaking and error-prone. Hence, the feature rea- soning system should scale up well to handle large and complex models. Expressivity. As features interact with each other, the rela- tionship among various features could be very complicated. The reasoning system should provide for means for representing and efﬁcient reasoning over the wide variety of feature relations. Debugging aids. It should provide some explanation as to why the feature models are inconsistent. The Semantic Web has emerged as the next generation of the Web since the past few years. Ontology languages such as OWL  play a key role in realizing the full potential of the Semantic Web as they prescribe how data are deﬁned and related. According to W3C, “an ontology deﬁnes the terms used to describe and represent an area of knowledge ... Ontolo- gies include computer-usable deﬁnitions of basic concepts in the domain and the relationships among them ...They encode knowledge in a domain and also knowledge that spans domains. In this way, they make that knowledge reusable”. One of the advantages of logic based ontology languages, such as OWL, in particular OWL-DL or OWL-Lite, is that reasoners can be used to compute subsumption relationships between classes and to identify unsatisﬁable (inconsistent) classes. With the matura- tion of tableaux algorithm based DL reasoners, such as RACER , FaCT++  and PELLET , it is possible to perform efﬁcient reasoning on large ontologies formulated in expressive description logics. There is a strong similarity between Semantic Web ontology engineering and feature modeling, both of which represent con- cepts in a particular domain and deﬁne how various properties relate them. Hence, we believe that the Semantic Web can play important roles in domain engineering. In this paper, we explore the synergy of domain engineering and the Semantic Web. Given the rich expressiveness of OWL and its efﬁcient and automated reasoning support, OWL can be adopted to reason and check feature models effectively. We propose methods for transforming a feature model into an OWL ontology. We use OWL reasoning engine such as FaCT++  to perform automated analysis over an OWL representation of the feature model. The analysis helps us detect possible inconsistencies in fea- ture conﬁgurations. Furthermore, a general OWL debugger has been developed to tackle the disadvantage of lacking debug- ging aids for the current OWL reasoner and complement our verifying approach. We illustrate our approach using an exam- ple of the Graph Product Line (GPL) feature model, which is a standard problem proposed in  for evaluating product line technologies. Moreover, the performance of the approach has been evaluated by another very large and complicated feature model. Furthermore, we have developed a CASE tool to facil- itate visual development, reasoning and distribution of Feature models in the OWL environment. Theremainderofthepaperisorganizedasfollows.InSection 2, we give a brief overview of feature modeling and Semantic Web ontology languages and tools. Section 3 describes the rep- resentation of a feature model in OWL. In Section 4, we show how FaCT++, a Semantic Web reasoning engine, can be used to perform automated analysis over the OWL representation of the feature models and present the OWL debugger to complement the FaCT++. In Section 5, we demonstrate the visual CASE tool we built to facilitate the creation and reasoning about fea- ture models. Section 7 concludes the paper and describes future works. 2. Overview 2.1. Feature modeling 2.1.1. Concepts and features There are many deﬁnitions about features in the software engineering community, some of which are summarized below. • A clustering of individual requirement that describe a cohe- sive, identiﬁable unit of functionality (Feature Engineering ). • A prominent and distinctive user visible characteristic of a system (FODA ). • A distinguishable characteristic of a concept that is relevant to some stakeholders (ODM ). We use the ODM deﬁnition as it has its root in concep- tual modeling and cognitive science. In classical conceptual modeling, we describe concepts by listing their features, which differentiate instances of a concept. In software engineering, we believe software features differentiate software systems. Fea- tures of a software system are not only related to user-visible functional requirements of the system, but also related to non- functional requirements (quality attributes), design decisions, and implementation details. Indomainengineeringandsoftwareproductlinecontext,fea- tures distinguish different members of a product line. A product H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 119 Table 1 Types of features Type Notation Mandatory Optional Alternative Or line can be seen as a concept, and members of the product line can be seen as instances of the concept. Product line members share common features and also differ in certain features. 2.1.2. Feature diagrams and feature relations Conceptual relationships among features can be expressed by a feature model as proposed by Kang et al. . A feature model consists of a feature diagram and other associatedinformation(suchasrationale,constraintsanddepen- dency rules). A feature diagram provides a graphical tree-like notation that shows the hierarchical organization of features. The root of the tree represents a concept node. All other nodes represent different types of features. Table 1 provides an overview of some commonly found fea- ture types. The graphical notation introduced by Czarnecki and Eiseneckerisusedhere.InTable1,assumingtheconceptCis selected, we have the following deﬁnitions on its child features: • Mandatory. The feature must be included into the description of a concept instance. • Optional. The feature may or may not be included into the description of a concept instance, hence its presence is optional. • Alternative. Exactly one feature from a set of features can be included into the description of a concept instance. • Or.Oneormorefeaturesfromasetoffeaturescanbeincluded into the description of a concept instance. Feature models are often used to model commonality and variability in a domain-engineering context. Commonalities can be modeled by common features (mandatory features whose ancestors are also mandatory), and variabilities can be modeled byvariantfeatures,suchasoptional,alternative,andor-features. A domain can be modeled as a concept. Feature diagrams sometimes cannot capture all the inter- dependenciesamongfeatures.Wehaveidentiﬁedtwoadditional relations among features: requires and excludes. • Requires. The presence of some feature in a conﬁguration requires the presence of some other features. • Excludes.Thepresenceofsomefeatureexcludesthepresence of some other features. AstheRequiresandExcludesrelationsdonotappearinafea- turediagram,theyareusuallypresentedasadditionalconstraints in a textual description. 2.1.3. The graph product line feature model The Graph Product Line (GPL) example is proposed by Lopez-Herrejon and Batory as a standard problem for evaluat- ing software product line technologies . We use it as a case study to demonstrate the effectiveness of our approach in verify- ing feature models using OWL. The GPL is a family of classical graph applications in the Computer Science domain. Members ofGPLimplementoneormoregraphalgorithms,overadirected or undirected graph that is weighted or unweighted, and one search algorithm if required.1 We summarize it as follows. GPL is a typical software product line in that different GPL applications are distinguished by a set of features. Lopez- Herrejon and Batory have identiﬁed the following features in GPL: • Algorithms. A graph application implements one or more of the following algorithms: Vertex numbering (Number), Connected Components (Connected), Strongly Connected Components (StronglyConnected), Cycle Checking (Cycle), MinimumSpanningTrees(MST),andSingle-SourceShortest Path (Shortest). • Graph type. A graph is either Directed or Undirected, and its edges can be either Weighted or Unweighted. • Search. A graph application requires at most one search algorithm: Breadth-First Search (BFS) or Depth-First Search (DFS). Based on the above feature classiﬁcation, a feature diagram for the Graph Product Line (GPL) applications can be deﬁned as shown in Fig. 1. We also know from our knowledge of the graph algorithms that not all combinations of the features described in the above feature diagram (Fig. 1) are valid in a GPL implementation. For example, if a graph application implements the Minimum Spanning Trees (MST) algorithm, we have to use the Weighted and Undirected graph types and it requires no search algo- rithm. Table 2 shows the additional constraints among the GPL features for representing a valid combination, adapted from Lopez-Herrejon and Batory . 1 More information about the GPL example can be found online at: http://www.cs.utexas.edu/users/dsb/GPL/graph.htm. 120 H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 Fig. 1. A feature model for Graph Product Line. Table 2 Additional constraints on GPL Algorithms Algorithm Searches required Required graph type Required weight Vertex numbering DFS, BFS Directed, Undirected Weighted, Unweighted Connected components DFS, BFS Undirected Weighted, Unweighted Strongly connected DFS Directed Weighted, Unweighted Cycle checking DFS Directed, Undirected Weighted, Unweighted Minimum spanning tree None Undirected Weighted Single-source shortest path None Directed Weighted FromtheaboveGPLmodelandadditionalconstraints,wecan see that (GPL, GraphType, Directed, Unweighted, Algorithms, Number) is a possible conﬁguration derived from the GPL feature model. However, the conﬁguration (GPL, GraphType, Directed, Undirected, Weighted, Algorithms, Shortest) is invalid since the features Directed and Undirected are exclusive to each other. 2.2. The Semantic Web—languages and tools The Semantic Web was originally proposed by Berners-Lee et al. as “an extension to the current web in which information is given well-deﬁned meaning, better enabling computers and people to work in cooperation” . OWL is the latest standard in ontology languages, which was developed by members of the WorldWideWebConsortium2 andtheDLcommunity.AnOWL ontology consists of classes, properties and individuals. Classes are interpreted as sets of objects that represent the individuals in the domain of discourse. Properties are binary relations that link individuals, and are interpreted as sets of tuples, which are subsets of the cross product of the objects in the domain of discourse. Table 3 summarizes the “DL syntax” used in the following sections for feature modeling in OWL. Interested readers may refer to  for full details. 2 http://www.w3.org. Ontology-related tools have been built alongside the devel- opment of ontology languages. FaCT++ (Fast Classiﬁcation of Terminologies)  and RACER (Renamed ABox and Concept Expression Reasoner ) are the two most widely accepted OWL reasoners. They supportautomatedclasssubsumptionandconsistencyreasoning and some queries on OWL ontologies. Prot´eg´ eisasystemfordevelopingknowledge-basedsys- tems. It is an open-source, Java-based Semantic Web ontology editor that provides an extensible architecture, allowing users to create customized applications. In particular, the Prot´eg´e-OWL plugin  enables editing OWL ontologies and connecting to reasoning engines such as FaCT++ to perform tasks such as automated consistency checking and ontology classiﬁcation. Table 3 Summary of OWL syntax used in the paper Notation Explanation Super class of all OWL class N1N2 N1 is a sub class/property of N2 C1C¬2 Classes C1 and C2 are disjoint C1≡C2 Class equivalence C1/C2 Class intersection/union ∀P·C Range of property P is class C ∀/∃P·C allValuesFrom/someValuesFrom restriction, giving the class that for every instance of this class that has instances of property P, all/some of the values of the property are members of the class C H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 121 Tobetterpresenthowtomodelandreasonaboutfeaturemod- els in OWL, we use Prot´eg´e-OWL as the ontology editor and FaCT++ as the reasoner. The OWL model will be automatically generated by our feature modeling CASE tool. 3. Feature modeling using OWL In this section, we describe how to build a Semantic Web environment for feature modeling. Various feature relations can be model using OWL language constructs. We will discuss four types of feature relations: mandatory, optional, alternative, or and the two additional ones: requires and excludes. Model- ing feature models using OWL has several advantages, such as facilitating feature model storing, sharing and distributing and assisting cooperative designing. In this paper, we only focus on verifying feature model using OWL. In order to make use of the full power of FaCT++, we model the feature relations in OWL DL, since it is more expressive than OWL Lite and still retains decidability. As TBox reason- ing is more comprehensive than that of ABox, we will model feature diagrams and feature conﬁgurations using OWL classes and properties instead of individuals. In this way the reasoning power of the engine is exploited to detect inconsistencies. Ref.  gives some more detailed discussion about the difference between those two modelling ﬂavors. Our presentation of the OWL encoding will be divided into two parts. Firstly, we present how a feature diagram and addi- tional constraints are modeled in OWL, and in the second part, the modeling of feature conﬁgurations are discussed. 3.1. Conceptual modeling Before we model the different feature relations in a feature diagram, we need to build the OWL ontology for the various nodes and edges in the diagram. The ontology is constructed in a number of steps. Step 1. We identify the nodes (concepts and features) present in a feature diagram. Each node in the diagram is modeled as an OWL class. Moreover, we assert that these classes are mutually disjoint. In OWL, all classes are assumed to overlap unless it is otherwise stated that they are disjoint with each other using a disjointaxiom.Bydefault,weassumethatfeatureswithdifferent names are distinct. Step 2. For each of these nodes in the diagram, we create a Ruleclass.ThisRuleclasshastwokindsofconditions:ﬁrstly, a necessary and sufﬁcient (NS, EquivalentClass) condi- tion,usinganexistentialrestrictiontobindtheRulenodetothe correspondingfeaturenodeinthediagram;andsecondly,anum- ber of (possibly 0) necessary (N, subClassOf) constraints later, serving two purposes: • To specify how each of its child features are related to this node, capturing the various relations between features. • To specify how this feature node is constrained by other fea- tures, in the form of requires and excludes as discussed in Section 2. Step 3. The root concept and features in a feature diagram are inter-related by various feature relations, represented by dif- ferent edge types in the diagram. In our OWL model, for each of these edges, we create an object-property. We assert that the range of the property is the respective feature class. For a parent feature G and its child features F1, ... , Fn, the initial modeling above produces the following ontology. G hasGObjectProperty GRule ∀hasG·G GRule ∃hasG·G F1 F1Rule hasF1ObjectProperty ... hasF1·F1 Fn F1Rule ∃hasF1·F1 FnRule ... hasFnObjectProperty G¬Fi, for 1≤i≤n hasFn·Fn FnRule ∃hasFn·Fn Fi¬Fj, for 1≤i, j≤n∧i=j Now we are ready to model the feature relations using the ontology. The general deﬁnition of each of the four feature rela- tions will be shown, based on the above feature ontology. The GPL example presented in Section 2.1.3 will be used to illus- trate the idea. The ontology will be constructed incrementally to show the modeling of various feature relations and addition constraints deﬁned in Table 2. 3.1.1. Mandatory A mandatory feature is included if its parent feature is included. For each of the mandatory features F1, ... , Fn of a parent feature G, we use one N constraints in GRule to model it. It is a someValuesFrom restriction on hasFi, stating that each instance of the rule class must have some instance of Fi class for hasFi. The following ontology fragment shows the modeling of mandatory feature set and parent feature G. GRule∃hasF1·F1 ... GRule∃hasFn·Fn It can be seen from Fig. 1 that the root node GPL has a mandatory child feature GraphType, which is itself a non-leaf node. We create two new classes for these two non-leaf nodes.3 GPL hasGPLObjectProperty GraphType hasGPL·GPL GPLRule GPLRule ∃hasGPL·GPL GraphTypeRule hasGraphTypeObjectProperty hasGraphType·GraphType GraphTypeRule ∃hasGraphType·GraphType GPLRule∃hasGraphType·GraphType The statement GPLRule∃ hasGraphType·GraphType ensures that GPL will have some GraphType as one of its child features. 3.1.2. Optional Anoptionalfeaturemayormaynotbeincludedinadiagram, if its parent is included. 3 Disjointness and range statements will not be shown from here onwards. 122 H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 For each of the optional features F1, ... , Fn of a parent feature G, no additional statements are required to model this relationship. Fig. 1 shows that feature Search is an optional feature for GPL. That is, Search may, or may not be included in a conﬁgu- ration of GPL. Asusual,wecreateonenewclassSearchRuleforSearchsince it is a non-leaf node, and one object-property hasSearch. The ontology is augmented as follows. Note that no new restriction on GPL is added. Search hasSearchObjectProperty SearchRule SearchRule ∃hasSearch·Search 3.1.3. Alternative As stated in Section 2, one and only one feature from a set of alternative features can be included, if their parent feature is included in a conﬁguration. Hence,forasetofalternativefeaturesF1,... ,Fn andaparent feature G, we use disjunction of someValuesFrom restric- tions over hasFis to ensure that some feature will be included. Weusethecomplementofdistributeddisjunctionoftheconjunc- tionoftwosomeValuesFromrestrictionstoensuresthatonly onefeaturecanbeincluded.Thesymbolrepresentsdistributed disjunction. GRule(∃hasFi·Fi), for 1≤i≤n GRule¬(∃hasFi·Fi∃hasFj·Fj), for 1≤i≤j≤n Fig. 1 shows that features BFS and DFS compose an alterna- tive feature set for Search. We model this relation as follows. BFS hasBFSObjectProperty BFSRule BFSRule ∃hasBFS·BFS DFS hasDFSObjectProperty DFSRule DFSRule ∃hasDFS·DFS SearchRule((∃hasBFS·BFS)(∃hasDFS·DFS)) SearchRule¬((∃hasBFS·BFS)(∃hasDFS·DFS)) The last two restrictions ensure that one and only one feature from the set of alternative features can be included. 3.1.4. Or According to Section 2, at least one from a set of or features is included, if the parent feature is included. For a set of or features F1, ... , Fn of a parent feature G, we need to use a disjunction of someValuesFrom restrictions to model this relation. GRule(∃hasFi·Fi), for 1≤i≤n Itmaybenoticedthatthedeﬁnitionoforisverysimilartothat of alternative, with the omission of the negation of distributed disjunction to allow for multiple or features to be included. In Fig. 1, the feature Algorithms has a number of or features. We use the following constructs to model it. To save space, the deﬁnitions of the various Rule classes will not be shown. Algorithms AlgorithmsRule hasAlgorithmsObjectProperty AlgorithmsRule ∃hasAlgorithms·Algorithms AlgorithmsRule((∃hasNumber·Number) (∃hasConnected·Connected)(∃hasCycle·Cycle) (∃hasMST·MST)(∃hasShortest·Shortest) (∃hasStronglyConnected·StronglyConnected)) 3.1.5. Requires A feature may depend on some other features, hence its pres- ence in a feature conﬁguration requires the appearance of the others. For a given feature G and a set of features F1, ... , Fn that G requires, besides the NS condition that binds GRule to G, we make sure that each of the Fi features appears in a conﬁguration if G is present. GRule∃hasF1·F1 ... GRule∃hasFn·Fn In Table 2, feature StronglyConnected requires both DFS and Directed, and either Weighted or Unweighted. Its OWL repre- sentation is as follows. StronglyConnectedRule StronglyConnectedRule ∃hasStronglyConnected·StronglyConnected StronglyConnected∃hasDFS·DFS StronglyConnected∃hasDirected·Directed Since Weighted and Unweighted form the set of two alterna- tive features of GraphType, which is itself a mandatory feature and exactly one from a set of alternative features must appear in the conﬁguration, we do not need to express them as additional constraints for StronglyConnected. 3.1.6. Excludes The presence of a feature may be inhibited by that of some other features. We say the appearance of a feature in a conﬁgu- ration excludes the appearance of some other features. For a given feature G and a set of features F1, ... , Fn that G excludes, we make sure, using the negation of someValues- From restriction on hasFi property, that Grule does not have any Fi feature. GRule¬(∃hasFi·Fi) ... GRule¬(∃hasFn·Fn) The next example shows both requires and excludes con- straints for a single feature. In GPL, cycle checking algorithm Cycleexcludestheuseofbreadth-ﬁrstsearchBFS.FromTable2, we know that Cycle only requires DFS, hence it also excludes BFS. CycleRule CycleRule ∃hasCycle·Cycle CycleRule∃hasDFS·DFS CycleRule¬ (∃hasBFS·BFS) H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 123 The complete GPL ontology model in XML syntax can be found at http://www.comp.nus.edu.sg/∼liyf/GPL.owl. 4. Verifying and debugging feature conﬁguration in OWL 4.1. Verifying feature conﬁguration In feature modeling, a feature conﬁguration derived from a feature model represents a concrete instance of a concept (i.e., a speciﬁc system in a domain). Intuitively, given a feature ontol- ogy, features and concepts in a conﬁguration should be ground instances (OWL individuals) of the OWL classes deﬁned in the ontology. Hence modeling feature conﬁgurations using individ- uals is a straightforward approach. However, a number of reasons made us model feature con- ﬁgurations as OWL classes but not individuals. • Firstly, since feature models and individual feature conﬁgura- tions both classify individual implementations, representing the speciﬁc conﬁguration as a sub-concept is the most natural from a semantic viewpoint. • Secondly, the reasoning support that we need is more readily available in TBox than in ABox. (1) Inconsistencies asso- ciated with an ABox may not be discovered by the TBox reasoning engine such as FaCT++. (2) If an ABox reasoner discovers that a particular feature conﬁguration is inconsis- tent, it can only indicate that the entire ontology (ABox) is incoherent. It cannot determine, however, which instances actually cause the inconsistency. This greatly increases the difﬁculty in debugging the conﬁgurations. On the other hand, most of the reasoners are capable of locating the speciﬁc classes that are inconsistent. As a result, in our approach, we use classes to simulate fea- tureandconceptinstancessothatthefullpowerofthereasoning engine can be exploited to detect inconsistencies in the conﬁg- uration. Deﬁnition 1. Feature conﬁguration modeling. A feature con- ﬁguration is a set of features that an instance of a concept may hold.Themodelingofagivenfeatureconﬁgurationisasfollows. We model the concept node in the conﬁguration as a subclass of the rule class for the root in a feature diagram. We use an existential restriction for each feature included in the conﬁguration. For each feature F present in a feature diagram but not in its conﬁguration, we use a “¬∃hasF·F” restriction to prevent the reasoning engine from inferring the existence of this feature in the conﬁguration. This is necessary because of the Open World Assumption adopted by OWL . We make the concept class to be equivalent (NS condition) to the conjunction of the above constraints. For a concept instance C derived from a feature diagram with root concept G and a set of features F1, ... , Fn, assuming that F1, ... , Fi appear in the conﬁguration of C and Fi+1, ... , Fn do not, a feature conﬁguration can be modeled as follows. CGRule C≡(∃hasFj·Fj, for 1≤j≤i) (¬∃hasFk·Fk, for i<k≤n) The feature conﬁguration is constructed as a separate ontol- ogyandthereasoningengineisinvokedtocheckitsconsistency. The conﬁguration is valid if the ontology is checked to be con- sistent with respect to the feature diagram ontology. We use the GPL example to illustrate this approach. Suppose that we have a conﬁguration containing a concept instance E and some features for the above GPL feature diagram. We call the instance node the class E. Note that the namespace name of the feature diagram ontology is GPL and is omitted from the presentation. EGPLRule E≡((∃hasConnected·Connected)(∃hasSearch·Search) (∃hasAlgorithms·Algorithms)(∃hasBFS·BFS) (∃hasGraphType·GraphType)(∃hasNumber·Number) (∃hasWeighted·Weighted)(∃hasUndirected·Undirected) (∃hasStronglyConnected·StronglyConnected) (¬∃hasDirected·Directed)(¬∃hasMST·MST) (¬∃hasShortest·Shortest) (¬∃hasUnweighted·Unweighted)(¬∃hasDFS·DFS) (¬∃hasCycle·Cycle)) If we input this ontology into Prot´eg´e and use FaCT++ to check it, FaCT++ will complain that E is inconsistent (Fig. 2). In Prot´eg´e the inconsistent classes are marked as red. A closer inspection reveals that StronglyConnected requires DFS and Directed, which are both absent in the conﬁguration. We correct the above conﬁguration by asserting that E does haveDFSandDirected.SinceBFSandDFSandUndirectedand Directedarealternativefeatures,weremoveBFSandUndirected from E. EGPLRule E≡((∃hasConnected·Connected)(∃hasSearch·Search) (∃hasAlgorithms·Algorithms)(∃hasDFS·DFS) (∃hasGraphType·GraphType)(∃hasNumber·Number) (∃hasWeighted·Weighted)(∃hasDirected·Directed) (∃hasStronglyConnected·StronglyConnected) (∃hasUndirected·Undirected)(∃hasMST·MST) (∃hasShortest·Shortest) (∃hasUnweighted·Unweighted)(∃hasBFS·BFS)(∃hasCycle·Cycle)) However, FaCT++ complains that the updated concept E is stillinconsistent.Thesourceofthisinconsistencydoesnotcome from StronglyConnected. However, it is caused by the fact that featureConnectedrequiresUndirected,whichisabsentfromthe conﬁguration. Then we realize that features StronglyConnected and Connected aremutuallyexclusiveinanyvalidconﬁguration since they require different features from a set of alternative features. After we remove Connected from the conﬁguration of E, FaCT++ conﬁrms that the ontology is consistent, hence the conﬁguration is valid. Although FaCT++ cannot tell why a conﬁguration is invalid (debugging feature models in OWL will be discussed in a later section), it can identify the inconsistency of a conﬁguration with full automation. As the case study shows, with the growth of the number of features in a feature diagram, manual checking of the consistency of a conﬁguration is very laborious and highly 124 H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 Fig. 2. FaCT++ detects an inconsistency. error-prone.Moreover,sinceontologyreasoningtoolsaredevel- oped to reason about knowledge bases with enormous size, this approach is very scalable. The automated approach we adopt here is thus very advantageous. 4.2. Debugging feature OWL models The OWL reasoners, like FaCT++, can perform efﬁcient rea- soning on large ontologies automatically. Another important requirement for feature model reasoning tool, as discussed in Section 1 is the debugging support. However, the lack of debug- gingaidsisamajorshortcomingfortheexistingOWLreasoners. When checking satisﬁability (consistency), the OWL reasoners canonlyprovidealistofunsatisﬁableclassesandoffernofurther explanation for their unsatisﬁability. It means that the reasoner can only conclude if a feature model is consistent and ﬂag the invalid conﬁgurations. The process of “debugging” a feature model is left for the user. When faced with several unsatisﬁ- able conﬁgurations in a moderately large feature model, even expert ontology engineers can ﬁnd it difﬁcult to work out the underlying error. Debugging an ontology has been well recognized as a non- trivial task. To provide some debugging assistance for the inconsistent feature models, we have built an OWL debugging tool based on the heuristics . Our OWL debugger has been designed to adopt the general OWL DL ontology and it can be also used to explain the errors in the feature models as well. Over the past ﬁve years we have presented a series of tuto- rials, workshops and post-graduate modules on OWL DL and its predecessors. Based on our experiences, a list of frequently made errors have been identiﬁed as reported in . This cata- logue of common errors has been used in turn to develop a set of heuristics that have been incorporated into a debugging tool for Protege-OWL . The heuristic debugger treats the tableaux reasoner as a “black box” or “oracle”. This “black box” approach has the Fig. 3. The debugging process. advantage that it is independent of the particular reasoner used. ItworkswithanyDIGcompliantreasoner,evenoneswhich have been specially augmented or adapted. Beingindependentofthereasonerhasadvantagesevenifonly asinglereasoneristobeused.Manymodernreasonerstransform the input ontology in order to optimize the reasoning process. Although logically equivalent, the internal representation may bear little resemblance to the ontology as it was constructed by the user. Given such transformations, even it were possible for the reasoner to ‘explain’ its actions, the explanation in terms of the transformed ontology would be unlikely to be of direct use to the user. An additional advantage of the ‘black box’ approach is that it is independent of such transformations. 4.2.1 Debugging process Fig. 3 illustrates the main steps of the debugging process. The user selects an OWL class for debugging, which is checked to ensure it is indeed inconsistent, and that the user is making a valid request to the debugger. The debugger then attempts to identify the unsatisﬁable core for the input class in order to min- imize the search space. The unsatisﬁable core is the smallest set of local conditions (direct super classes) that leads to the class in question being inconsistent. Having determined the unsat- isﬁable core, the debugger attempts to generate the debugging super conditions, which are the conditions that are implied by the conditions in the unsatisﬁable core. Fig. 8 presents the rules that are used in generating the debugging super conditions. The debuggerthenexaminesthedebuggingsuperconditionsinorder to identify the most general conﬂicting class set, which is ana- lyzedtoproduceanexplanationastowhytheclassinquestionis inconsistent. There are many different ways in which the axioms in an ontology can lead to an inconsistency. However, in general, we have found that most inconsistencies can be boiled down into a smallnumberof‘errorpatterns’.Insummarythe‘errorpatterns’ for class inconsistency may be boiled down to the following reasons: The inconsistency is from some local deﬁnition. (1) Having both a class and its complement class as super con- ditions. H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 125 (2) Having both universal and existential restrictions that act alongthesameproperty,whilsttheﬁllerclassesaredisjoint. (3) Having a super condition that is asserted to be disjoint with owl:Thing (). (4) Havingasuperconditionthatisanexistentialrestrictionthat has a ﬁller which is disjoint with the range of the restricted property. (5) Having super conditions of n existential restrictions that act along a given property with disjoint ﬁllers, whilst there is a superconditionthatimposesamaximumcardinalityrestric- tion or equality cardinality restriction along the property whose cardinality is less than n. (6) Having super conditions containing conﬂicting cardinality restrictions. The inconsistency is propagated from other source. (1) Having a super condition that is an existential restriction that has an inconsistent ﬁller. (2) Having a super condition that is a hasValue restriction that has an individual that is asserted to be a member of an inconsistent class. Due to the space limitation, some of the patterns have been omittedhere.Thedebuggerdetermineswhichoftheabovecases led to an inconsistency, and then uses provenance information that describes how the debugging super conditions were gener- ated in order to determine the ‘root’ cause of the inconsistency. Fig. 4 shows the result of debugging the GPL feature ontol- ogy. It suggests that the conﬁguration E is invalid (The class E is inconsistent) because that Directed cannot both be present (∃ hasDirected·Directed) and absent (¬∃hasDirected·Directed). Directed is explicitly stated to be absent. However, it is also required from feature StronglyConnected, which is present in the conﬁguration (see Table 2 for details). As discussed before, there are more than one reasons leading the conﬁguration E to being invalid. The debugger will pick one error each time. Note that the primal feedback from the debugger has been presented Fig. 4. Debugging GPL class. inthepaperdeliberatelytogivepeopleanintuitiveexperienceof the OWL debugger. Those information will be further processed for providing a nature explanation of the reason of a feature model been inconsistent and a conﬁguration been invalid. 4.3 Evaluation To better evaluate our approach, we constructed a feature model for a large system. It contains around 1000 different features and more than 400 different feature relations covering Mandatory, Alternative, Optional, Or features and Requires and Excludes relations. Ten different conﬁgurations has been con- ducted respecting with the feature models. The evaluation was conducted on a Pentium IV 2.8GHz system with 1GB memory running Windows XP. First, we transform the feature model into OWL (The trans- formation process is automatic). We then load the resulted ontology into FaCT++ and check its consistency. Notethatthefeatureconﬁgurationsbelowarepresentedinthe followingsyntaxforbrevityreasons.Thesymbol“+”represents set union. Hence, for example, F416+F417 denotes the set of two members, F416 and F417. The statement Or(PL, F226, F416+F417) denotes that with PL being the parent concept (or feature) node, features F416 and F417 form an Or feature set. Prot´eg´e has been used for presenting the OWL ontology. FaCT++ concludes that the feature model is inconsistent using 28.238s.Alargeportionofthetimeconsumptionistheoverhead fromtheOWLeditorProt´eg´eitself,e.g.pre-possessingontology and rendering the classes. The reasoning task itself only takes 5.306s. The inconsistency is caused by F136 and F137 being alternative and they are both included in the description of PL. The detailed explanations are as follows. First of all F6 is a mandatory feature of PL, F126 is a required feature of F6 and F137 is a required feature of F126. Hence, F137 must be held by PL. Inaddition,F416isrequiredbyF126,soF416alsomustbe held by PL. Because of the fact Or (PL, F226, F416+F417), since F226 is the parent of F416 and that F416 is held by PL, according to the deﬁnition of or type,F226must be held byPL. Because of the fact Optional (PL, F136, F226+F227) and the same reasoning as above, F136 must also be held by PL. AsF136 and F137 are alternative features, the model is inconsistent. Ourdebuggercanbeusedtotracethesereasonseffectively.If we remove the constraint that feature F137 is a required feature of F126, the feature model becomes consistent, concluded by FaCT++ as well. After that, we translate the 10 conﬁgurations into OWL, as shown in Fig. 5, FaCT++ picks up all the inconsistent conﬁgura- tionsasexpected.Ittakesonly32.766sforFaCT++tocheckthe ten conﬁgurations. The reasoning task itself only takes 9.406s. The debugger can be used to help us explain the reason why a conﬁguration is invalid as well. For example, as shown in Fig. 6, the reason why the conﬁguration 2 is invalid is because that F416, which is required by F126 is missed from the conﬁgu- ration. 126 H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 Fig. 5. Discovery of invalid conﬁgurations. Apart from verifying if a conﬁguration is entailed from the featuremodels(consistent),FaCT++canalsosupportthecheck- ing of semantic equivalence of feature models. Two feature models can be semantically equivalent even though they have different appearances in diagram. By “semantically equivalent”, we mean that all valid feature instances (conﬁgurations) derived fromonefeaturemodelcanalsobederivedfromtheothermodel, and vice versa. In OWL, we can convert this problem to a sub- sumption (subclass) reasoning task and use FaCT++ to test it. This can also be done with full automation. 5. Tool support for feature modeling in OWL In the previous section, we showed that OWL can be used to do the feature modeling. However it will be a tedious job for software engineers to design their system at such a level of details. In this section we present a visual case tool which provides a high-level and intuitive environment for constructing feature models in OWL. Our feature modeling tool was built based on the meta-tool Pounamu . Pounamu is a meta-case tool for developing multi-view visual environment. Fig. 7 shows Fig. 7. A case tool for feature modeling. the GPL feature model deﬁned by the tool. From it we can see that the GPL feature model can be deﬁned easily by creating instances of the pre-deﬁned model entities and associations. Note that additional constraints among the features can also be speciﬁed in the “constraints” attribute of a concept. By triggering the deﬁned event handler menu item in the tool, it transforms all the default XML format of each feature in the diagram into a single OWL representation of the feature model and saves it for later reasoning. One undergoing development is to develop our tool as a plugin within the overall Protege plug-and-play framework. 6. OWL experiences discussion In this paper, we presented an OWL application. We believe that feature modeling is a novel domain for OWL. In this sec- tion, we would like to feedback some of our experiences of using OWL to the Semantic Web community for the beneﬁt of designing the next generation of OWL languages. As shown in the previous sections, OWL provides a very expressive solution for providing fully automated, efﬁcient and scalable reasoning service for verifying feature models. How- ever, there are also some nuisances about current OWL. Fig. 6. Debugger determines why Conﬁguration 2 is invalid. H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 127 Fig. 8. Rules for the membership of Debugging Super Conditions (DSC). Apart from the lack for debugging aids as discussed before, another omission in the OWL language that we feel confounded is that there is no construct in OWL to make a set of classes mutually disjoint from each other, although OWL DL has the owl:AllDifferent construct to make a set of individuals mutually distinct from each other. This is because that the designers of OWL believe that “As the number of mutually disjoint classes grows the number of disjointness assertions grows proportion- ally to n2. However, in the use cases we have seen, n is typically small”.Theexperiencesinpracticearethatthisisnotthecase—n istypicallylargeenoughsuchthatthenumberofdisjointaxioms becomesseriouslyproblematic.Forexample,inourlargefeature models, there are about one thousand different features, which are distinct with each other. In the respected OWL ontology, almost 97% of axioms are the disjoint axioms for asserting the mutual disjointness. In terms of ﬁle size, these triples cause the 1MB owl ﬁle to blow up to 24MB. Similar problems are found in other biomedical ontologies such as GALEN, SNOMED, the NCI Thesaurus and the Gene Ontology. We believe that the owl:AllDisjoint construct should be added to the next version of OWL. Although it does not increase the expressive power, it willamelioratethepracticalsituationintermsofreducingmodel and ﬁle sizes, more efﬁcient computation and clearer model content. 6.1. Feature modeling beyond OWL OWL has considerable expressive power. All of the stan- dard feature relationship types can be expressed within OWL. However, to retain the decidability of key inference problems in OWL DL and OWL Lite, OWL has expressivity limitations. Some non-standard and complicated feature type may not be abletobeexpressedwithinOWL.Inthiscase,amoreexpressive language like SWRL  or SWRL-FOL  may be needed. However, currently there is no mature reasoning tools for these expressive languages. 7. Conclusion In domain engineering, feature models are used to capture common and variant features among systems in a particular domain. Current efforts on feature modeling are largely graph- ical and informal, which have hindered precise representation and automated analysis of feature models. In the Semantic Web, an ontology is a representation of domain knowledge, which has formally-deﬁned semantics and machine-understandable repre- sentation. Asbothfeaturemodelsandontologiesareintendedtocapture domain knowledge conceptually, it is natural to use ontology languages to rigorously represent and formally verify feature models and their conﬁgurations. The similarity between the two areas also suggests that ontology engineering techniques are applicable to feature modeling. In this paper, we propose a Semantic Web approach to fea- ture modeling, veriﬁcation and debugging. We use the OWL DL language to represent feature models and conﬁgurations in an unambiguous way. Features of a particular domain are 128 H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 identiﬁed as OWL classes. Feature diagrams represent a graphi- cal means of expressing relationships among different features. These relationships are captured by OWL properties. Feature conﬁgurationsrepresentpossiblecombinations(validorinvalid) of feature instances of a feature diagram. As discussed in Sec- tion 3, although it is natural to model feature conﬁgurations as OWL individuals, we model conﬁgurations using OWL classes in order to make use of the comprehensive reasoning support for TBox which is not available for ABox. Feature model and conﬁguration veriﬁcation is an impor- tant task in feature modeling. With the growth of the number of features in a feature model, manual checking of validity is very laborious and error-prone. As OWL has a formal and rig- orous semantical basis and the decidability of OWL DL, fully automated analysis is achievable. In our approach, we use an OWL reasoning engines such as FaCT++ to perform automated analysis over the OWL rep- resentation of the feature models. The analysis helps us detect possible inconsistencies in feature conﬁgurations. As such rea- soning engines are designed to handle large-scale knowledge bases, efﬁcient and effective analysis of large feature models are possible. The Graph Product Line example, a standard problem for evaluating software product line technologies, was used throughoutthepapertoillustrateourapproach.Wedemonstrated that inconsistencies within various feature conﬁgurations are effectively detected by reasoning engines such as FaCT++. Although reasoners such as FaCT++ and RACER are fully automated and very scalable. They cannot indicate the reasons as to why a class is inconsistent. With the growth of num- bers of features in a feature diagram, the manual debugging of invalid conﬁgurations will be a very laborious and error-prone process. We use a general OWL debugger to automatically ana- lyzeaninconsistentconceptinstance.Thedebuggerwillprovide some insight and hints on how the inconsistency is caused. This greatly helps to reduce the efforts and to improve debugging efﬁciency. A large feature model containing some 1000 features with ten conﬁgurations was constructed to test the reasoning and debugging of feature models/conﬁgurations. It turns out that our approach is quite effective and precise. To facilitate visual development and analysis of feature mod- els, we also develop a CASE tool that enables drawing feature diagrams and expressing additional constraints on various fea- tures.FeaturediagramsarethenconvertedtoOWLsyntax,made ready for online interchange and analysis. We believe that the Semantic Web can play important roles in domain engineering, and we will continue exploring the synergies between them. In the future, we plan to develop an integrated environment based on the current tool to support the construction, analysis and exchange of the feature models and conﬁgurations in OWL. Acknowledgements This work was supported in part by the EU-funded TAO project(IST-2004-026460),theHyOntUseProject(GR/S44686) funded by the UK Engineering and Physical Science Research Council and the Singapore Millennium Foundation. References  K.C. Kang, J. Lee, P. Donohoe, Feature-oriented product line engineering, IEEE Softw. 9 (2002) 58–65.  K. Czarnecki, U. Eisenecker, Generative Programming: Methods, Tools and Applications, Addison-Wesley, MA, 2000.  K.C. Kang, S. Cohen, J. Hess, W. Nowak, S. Peterson, Feature-oriented domain analysis (FODA) feasibility study, Technical Report CMU/SEI- 90TR-21, Software Engineering Institute, Carnegie Mellon University, Pittsburgh, PA, November 1990.  K.C. Kang, S. Kim, J. Lee, K. Kim, E. Shin, M. Huh, FORM: a feature- oriented reuse method with domain-speciﬁc reference architectures, Ann. Softw. Eng. 5 (1998) 143–168.  M.Griss,J.Favaro,M.d’Alessandro,Integratingfeaturemodelingwiththe RSEB, in: Proceedings of the Fifth International Conference on Software Reuse, Vancouver, BC, Canada, 1998, pp. 76–85.  S. Deelstra, M. Sinnema, J. Bosch, Experiences in software product fam- ilies: problems and issues during product derivation, in: R.L. Nord (Ed.), SPLC, Lecture Notes in Computer Science, vol. 3154, Springer, 2004, pp. 165–182.  D.L. McGuinness, F. van Harmelen (Eds.), OWL Web Ontology Language Overview, 2003. http://www.w3.org/TR/2003/PR-owl-features- 20031215/.  V. Haarslev, R. M¨oller, RACER system description, in: Proceedings of the Automated Reasoning: First International Joint Conference, No. 2083 in Lecture Notes in Computer Science, Siena, Italy, 2001, pp. 701–706.  I. Horrocks, Fact++ web site. http://owl.man.ac.uk/factplusplus/.  B.P. Evren Sirin, Pellet: an owl dl reasoner, in: R.M. Volker Haaslev (Ed.), Proceedings of the International Workshop on Description Logics (DL2004), 2004.  R.E. Lopez-Herrejon, D.S. Batory, A standard problem for evaluating product-line methodologies, in: Proceedings of the Third International Conference on Generative and Component-Based Software Engineering, Springer-Verlag, Erfurt, Germany, 2001, pp. 10–24.  C. Turner, A. Fuggetta, L. Lavazza, A. Wolf, A conceptual basis for feature engineering, J. Syst. Softw. 49 (1999) 3–15.  M.S. et al., Software technology for adaptable reliable system (STARS) organization domain modeling (ODM) guidebook version 2.0, Tech. Rep. STARS-VC-A025/001/00, Lockheed Martin Tactical Defense Systems, Manassas, VA, 1996.  T. Berners-Lee, J. Hendler, O. Lassila, The Semantic Web, Sci. Am. 284 (5) (2001) 35–43.  I. Horrocks, P.F. Patel-Schneider, F. van Harmelen, From SHIQ and RDF to OWL: the making of a web ontology language, J. Web Semant. 1 (1) (2003) 7–26, URL download/2003/HoPH03a.pdf.  V. Haarslev, R. M¨oller, RACER User’s Guide and Reference Manual: Version 1.7.6, 2002.  J. Gennari, M.A. Musen, R.W. Fergerson, W.E. Grosso, M. Crubezy, H. Eriksson, N.F. Noy, S.W. Tu, The evolution of protege: an environment for knowledge-based systems development, Tech. Rep. SMI-2002-0943, Stanford Medical Informatics, Stanford University, 2002.  H. Knublauch, R.W. Fergerson, N.F. Noy, M.A. Musen, The Prot´eg´ e OWL plugin: an open development environment for semantic web applica- tions, in: Proceedings of the Third International Semantic Web Conference (ISWC 2004), Hiroshima, Japan, 2004.  N. Noy, Representing classes as property values on the semantic web. http://www.w3.org/TR/2005/NOTE-swbp-classes-as-values-20050405.  M.K. Smith, C. Welty, D.L. McGuinness (Eds.), OWL Web Ontology Language Guide, 2004. http://www.w3.org/TR/2004/REC-owl-guide- 20040210/.  H. Wang, M. Horridge, A. Rector, N. Drummond, J. Seidenberg, Debug- ging OWL-DL Ontologies: A Heuristic Approach, in: Proceedings of the of Fourth International Semantic Web Conference (ISWC’05), Springer- Verlag, Galway, Ireland, 2005. H.H. Wang et al. / Web Semantics: Science, Services and Agents on the World Wide Web 5 (2007) 117–129 129  A. Rector, N. Drummond, M. Horridge, J. Rogers, H. Knublauch, R. Stevens, H. Wang, C. Wroe, Owl pizzas: practical experience of teaching owl-dl: common errors and common patterns, in: Proceedings of the Euro- pean Conference on Knowledge Acquistion, Lecture Notes in Computer Science, Springer-Verlag, 2004, pp. 63–81.  A.R. Holger Knublauch, M. Musen, Editing description logic ontologies withtheprot´eg´e-owlpluginInternationalWorkshoponDescriptionLogics- DL2004, 2004.  S. Bechhoffer, The dig description logic interface: Dig/1.1, Tech. rep., The University Of Manchester, The University Of Manchester, Oxford Road, Manchester M13 9PL, 2003.  N. Zhu, J. Grundy, J. Hosking, Pounamu: a meta-tool for multi-view visual language environment construction, in: Proceedings of the IEEE Sympo- sium on Visual Languages and Human-Centric Computing (VL/HCC’04), Rome, Italy, 2004.  I. Horrocks, P.F. Patel-Schneider, H. Boley, S. Tabet, B. Grosof, M. Dean, SWRL: A Semantic Web Rule Language Combining OWL and RuleML, 2004. http://www.w3.org/Submission/2004/SUBM-SWRL-20040521.  H. Boley, M. Dean, B. Grosof, I. Horrocks, P. Patel-Schneider, S. Tabet, G. Wagner, SWRL FOL, 2004. http://www.daml.org/2004/11/fol/. issues during product derivation, in: R.L. Nord (Ed.), SPLC, Lecture Notes in Computer Science, vol. 3154, Springer, 2004, pp. 165–182.  D.L. McGuinness, F. van Harmelen (Eds.), OWL Web Ontology Language Overview, 2003. http://www.w3.org/TR/2003/PR-owl-features- 20031215/.  V. Haarslev, R. M¨oller, RACER system description, in: Proceedings of the Automated Reasoning: First International Joint Conference, No. 2083 in Lecture Notes in Computer Science, Siena, Italy, 2001, pp. 701–706.  I. Horrocks, Fact++ web site. http://owl.man.ac.uk/factplusplus/.  B.P. Evren Sirin, Pellet: an owl dl reasoner, in: R.M. Volker Haaslev (Ed.), Proceedings of the International Workshop on Description Logics (DL2004), 2004.  R.E. Lopez-Herrejon, D.S. Batory, A standard problem for evaluating product-line methodologies, in: Proceedings of the Third International Conference on Generative and Component-Based Software Engineering, Springer-Verlag, Erfurt, Germany, 2001, pp. 10–24.  C. Turner, A. Fuggetta, L. Lavazza, A. Wolf, A conceptual basis for feature engineering, J.