An ontological knowledge-based method for handling feature model defects due to dead feature

An ontological knowledge-based method for handling feature model defects due to dead feature Megha Bhushan a,* , Jos´ e´ Angel Galindo Duarte a , Arun Negi b , Piyush Samant c a Department of Computer Languages and Systems, University of Seville, Spain b Deloitte USI, Gurugram, India c Mirxes Labs, Singapore ARTICLE INFO Keywords: Software product line Dead feature Knowledge-based method Knowledge representation Feature model Ontology ABSTRACT The specifications of a certain domain are addressed by a portfolio of software products, known as Software Product Line (SPL). Feature Model (FM) supports domain engineering by modeling domain knowledge along with variability among SPL. The quality of FM is one of the significant factors for the successful SPL in order to attain high quality software products. However, the benefits of SPL can be reduced due to defects in FM. Dead Feature (DF) is one of such defects. Several approaches exist in the literature to detect defects due to DF in FMs. But only a few can handle their sources and solutions which are cumbersome and difficult to understand by humans. An ontological knowledge-based method for handling defects due to DF in FMs is described in this paper. It specifies FM in the form of ontology-based knowledge representation. The rules based on first-order logic are created and implemented using Prolog to detect defects due to DF with sources as well as suggest solutions to resolve these defects. A case study of the product line available on SPLOT repository is utilized for illustrating the proposed work. The experiments are performed with real-world FMs of varied sizes from SPLOT and FMs created with the FeatureIDE tool. The results prove the efficiency, scalability (up to model with 32,000 features) and accuracy of the presented method. Therefore, reusability of DFs free knowledge enables deriving defect free products from SPL and eventually enhances the quality of SPL. 1. Introduction A system is artificially intelligent when it can be articulated in some language. It must include a component that incorporates the knowledge of the system and expedites its intelligent behavior (Ayorinde and Akinkunmi, 2013). These can be attained with the aid provided by Knowledge Representation (KR) and reasoning. It accumulates, manages, and stores knowledge in a structured way accessible to intelligent systems for decision making. The paradigm of shifting to mass customization from mass production enhances economic dimensions with the flexibility of custom manufacturing by creating groups of associated products rather than individual products (Heradio et al., 2012a,2012b). A well-known software reuse method for KR and reuse is defined as Software Product Line (SPL). It is defined as a group of software products developed to meet the demands of a specific field. The profits of SPL incorporate delivering a new product in less time with low cost and high quality. Several companies like CelsiusTech, Hewlett Packard, Motorola, Boeing, Nokia, Ford, Philips, Salion, Inc., General Motors, Cummins, Raytheon, McDonalds, and Rockwell-Collins have adopted the SPL approach to explore the profits exhibited by it (Northrop, 2008;Thüm et al., 2014a). Feature Model (FM) is a widely used notation to model domain knowledge (Bhushan et al., 2018a). It incorporates common and variant features with the illustration of variability (Galster et al., 2013) among SPL (Kang et al., 1990). The features along with their relationships in a FM are shown in the form of a hierarchical tree (Galindo et al., 2019). The legal and distinctive combinations of features generate each product in SPL. A feature is a prominent property of software that is significant to the user. For instance, it may be a piece of code, a characteristic, a requirement of SPL depending on the software development stage or an increment in program functionality. For example, an automated teller machine incorporates features such as cash deposit, cash withdrawal, changes your pin, balance enquiry and so on. FMs can be converted into a language that turns them to be computable (Dur´ an et al., 2017). There are many ways to represent * Corresponding author. E-mail addresses: [email protected] (M. Bhushan), [email protected] (J.´ A. Galindo Duarte), [email protected] (A. Negi), [email protected] (P. Samant). Contents lists available at ScienceDirect Engineering Applications of Artificial Intelligence journal homepage: www.elsevier.com/locate/engappai https://doi.org/10.1016/j.engappai.2024.109000 Received 5 October 2022; Received in revised form 9 May 2024; Accepted 15 July 2024 Engineering Applications of Articial Intelligence 136 (2024) 109000 Available online 23 July 2024 0952-1976/© 2024 The Authors. Published by Elsevier Ltd. This is an open access article under the CC BY-NC license ( http://creativecommons.org/licenses/bync/4.0/ ). knowledge; ontology is one of the popular KR languages. Recently, in the domain of artificial intelligence, the strong relationship between knowledge bases and ontologies has emerged as a new paradigm for KR. Ontology describes the knowledge about a particular domain and incorporates reasoning rules for processing the domain knowledge. It formally describes domain knowledge as a set of concepts and the relations among them (Bhushan et al., 2018a). Ontologies have become popular in defining knowledge domains, KR, reuse, management, sharing, storing, searching, information retrieval and extraction. Numerous studies focus on KR using ontologies (Megha et al., 2018; Lebbink et al., 2002;Brewster and O’Hara, 2004;Sureephong et al., 2008;Witherell et al., 2010;Heeptaisong and Shivihok, 2012;Jain and Mishra, 2014). Almost all KR languages are derived from formal logic such as predicate logic, temporal logic and propositional logic. A formal language that provides the benefits of being comprehensible, unambiguous and capable of expressing facts is defined as logic. The first-order formula based on predicates is the prevalent language used for the theory of KR (Van Harmelen et al., 2008). Additionally, ontology languages are generally based on either description logic or First-Order Logic (FOL). FOL is an efficient tool to describe the expressiveness of the SPL approach by enabling corresponding KR formalism (Schlick and Hein, 2000;Bhushan et al., 2018b,2021). Unlike propositional logic, which relies on declarative propositions and lacks expressive power, FOL allows reasoning and represents knowledge in a more compact and flexible way. Many expert systems such as DENDRAL (Wang, 2019), PROSPECTOR (Smith et al., 2022) and R1 (Crowley et al., 2022), have used rule-based reasoning for their success. Various activities such as technical management, organizational management, and software engineering lead to the generation of correct software products in SPL. For example, reuse aspect, interfaces, overloaded software development system and testing lead to the successful SPL approach. The productivity as well as quality of SPL are significantly impacted by the software product’s quality. The growing size and complexity of FMs, along with incorrect combinations of features may allow defects to unintentionally inject into models. The creation of software products is hindered by these defects (Salinesi and Mazo, 2012) which further reduces the FM’s quality with profits from SPL. One of these defects associated with the semantics of models, which deteriorates their quality, is defect due to Dead Feature (DF). It is not incorporated in any valid software product derived from the SPL, although it is included in the FM (Kang et al., 1990). As models can derive a huge number of valid products, defects due to DF can negatively impact other derived valid products from the SPL. Numerous methods exist to identify (Salinesi and Mazo, 2012;vonderMaßen and Lichter, 2004;Salinesi et al., 2010;Galindo and Benavides, 2020a;Ripon et al., 2013;Perez-Morago et al., 2015;Bhushan and Goel, 2016) and provide explanations for the cause of defects due to DF in FMs (Galindo and Benavides, 2020a;Elfaki et al., 2013;Giraldo et al., 2014;Rinc´ on et al., 2014;Lesta et al., 2015;Kowal et al., 2016;Hentze et al., 2021). However, only a few methods (Le et al., 2021;Felfernig et al., 2013; Zhang et al., 2013;Thüm et al., 2014b;Rinc´ on et al., 2015) have suggested corrections for these defects in a way that is complicated to comprehend by developers. For instance (Thüm et al., 2014b), has only detected the constraints involved in these defects. The significance of an efficient computation runtime on the performance of techniques handling defects due to DF in FMs is discussed in several studies (Salinesi and Mazo, 2012;Perez-Morago et al., 2015; Elfaki et al., 2013;Rinc´ on et al., 2014;Kowal et al., 2016;Zhang et al., 2013). The amount of time needed to detect defects might expand exponentially with growing size and complexity in models. For large-scale models, maintaining scalability and sustainability of defect detection methods becomes increasingly dependent on fractions of seconds saved in defects detection. Defect detection or correction operations that run frequently or on large datasets might have an impact on the overall performance and efficiency of methods. Moreover, it hinders development workflows and decision-making processes by affecting the practicability and usability of defect detection methods. The result of efficient runtime performance is an improved development process, facilitating the timely identification of defects with sources and solutions, thereby enabling developers to quickly resolve these defects. The performance of defect handling methods in FMs, crucial for practical software product line engineering, improves with minimized computation runtime, benefiting efficiency, scalability, user experience and productivity. The presented work focusses on handling defects due to DF in SPL. By utilizing KR techniques, such as ontology-based KR, the method captures domain knowledge of FMs. High quality SPL can be attained by generating DFs free products from FMs, avoiding the replication of existing defects due to DF in newly derived products. Though, it is impractical to physically identify as well as resolve these defects. Thus, detecting these defects along with their sources and solutions is of paramount significance to improve the quality of SPL. In addition, this method also categorizes these defects into four categories along with their cases. Moreover, it facilitates the derivation of DFs free software products, hence, contributing to the overall quality and reliability improvement of SPLs. Through comprehensive evaluation, including accuracy, scalability, performance analysis, minimalism of the rules, and comparative analysis with runtime comparisons yields insightful information about the effectiveness and applicability of the method. The novel contributions of the presented work are as follow: 1. Defects due to DF are classified into four categories along with their cases. 2. Ontology-based KR of FM is provided as it is an efficient way to represent the knowledge of a domain. 3. The presented ontological knowledge-based method not only identifies defects due to DF but also explains their corresponding sources and solutions in comprehensible language. 4. The results will assist modelers in resolving these defects to attain DFs free software products. Further, it enables reusability of knowledge and enhances the quality of SPL. This paper is organized as follows; the related approaches are summarized in Section 2, running example of Jogo FM is discussed in Section 3, classification of defects due to DF is given in Section 4, the proposed ontological knowledge-based method using running example is described in Section 5. Further, Section 6presents the experiments and results discussion. Section 7concludes the proposed work as well as outlines subsequent work. 2. Related work In this section, various existing studies that address the handling of FM defects in SPL, particularly focusing on DFs are discussed. These studies focus on detecting and explaining FM defects, such as DF, False- Optional Feature (FOF, which is defined as optional but is incorporated in all products of the product line), redundancy (a relationship created in multiple ways), void model (describe neither an instance nor a product), and false product line (model that permits the derivation of only one product). Additionally, many approaches, algorithms, and tools are employed to deal with defects in FMs, with a focus on enhancing accuracy, scalability, and suggesting corrective solutions in SPL engineering. This section summarizes the most relevant contributions. The authors of (vonderMaßen and Lichter, 2004) first resolved defects in FMs. However, there was no automated support available for it. They also provide a few details in the form of corrective explanations to resolve DFs, redundancies, and FOFs. In (Salinesi et al., 2010), the authors introduced a typology of FM verification criteria to explore errors. The explanation of these criteria utilized two real cases, while the authors first formalized the criteria using FOL. Later, Salinesi and Mazo M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 2 (2012) represented FMs in constraint programming for the analysis. Salinesi et al. (2010) presented a few algorithms in single-view and multi-view product line models to verify the models using the typology of verification requirements. Their work exclusively detected FOFs, void models, DFs, redundant constraints, false product line, and wrong cardinality. It supported models with features up to 2000 because the solver does not support more than 5000 variables. In FMs, the detection of redundant constraints and the explanation of various types of inconsistencies were accomplished using the FMCORE and FASTDIAG algorithms, respectively (Felfernig et al., 2013). Reiter employed a hitting set directed acyclic graph algorithm to determine the complete set of diagnoses for identifying and resolving a conflict (Reiter, 1987). Felfernig et al. (2013) recommended corrections for anomalies concerning inconsistencies and redundancies; however, they did not give any implementation details. They evaluated their work using models up to 172 features from the SPLOT repository. Furthermore, developers found anomaly interpretation challenging as explanations involved constraint sets. Ripon et al. (2013) modeled SPL variants using unified modeling language and verified them using FOL. In (Jackson, 2002), the authors employed the Alloy tool to automatically evaluate the validity and consistency of product instances and feature configurations, respectively. However, a case study was used to explain the identification of void FMs, DFs as well as invalid products. FM and orthogonal variability models represented the variability in SPL. Later, Elfaki et al. (2013) identified redundancies and DFs in the domain engineering process using FOL rules. They validated the method using self-created datasets, demonstrating its scalability with 20,000 features in a fair amount of time. Zhang et al. (2013) implemented an approach using the Feature Model Validation (FMV) Tool. They eliminated contradictory feature relationships from the model to identify FOFs and DFs with their explanations. A comparative analysis of results between FMV-Tool and the feature model analyzer (Benavides et al., 2007) concluded the effectiveness of the FMV-Tool. However, their work lacks supporting metrics or datasets for the results obtained. Giraldo et al. (2014) utilized an ontology based on the web ontology language to represent FMs. They identified DFs with some of their causes using semantic query-enhanced web rule language. FMs created using BeTTy tool (Segura et al., 2012) were used to validate the approach. Their work was restricted as it addressed only two cases of DFs. Later, Rinc´ on et al. (2014) represented FMs using ontologies. Semantic web rule language rules are used to identify FOFs, DFs as well as their causes (in natural language). However, their approach was restricted to models with up to 150 features. The FeatureIDE tool supports graphical representation of FMs and generates code (C++ or Java) from the model due to its integration with Eclipse (Thüm et al., 2014b). It enables editing of the model within its editor. This tool provides corrective solutions for dealing with DFs, void models and FOFs. Its capability is limited to providing corrections, which include the removal of only one relationship only. Fernandez-Amoros et al. (2014) calculated the count of products that applied all features to illustrate the standardization/parameterization balance, identify the scope of flaws, evaluate the incremental growth of the product line, and enhance the precision of economic models. Rinc´ on et al. (2015) transformed FMs into constraint programs. The algorithms given in (Salinesi and Mazo, 2012) were employed to analyze constraint programming for the identification of defects such as redundancies, FOFs, DFs and false product lines. A minimal subset of relationships is known as minimal correction subsets. These were identified by eliminating relationships from the model. However, providing corrections solely involves eliminating relationships from the model. Further, they evaluated their method using 78 models with varying features, including up to 120 dependencies. Perez-Morago et al. (2015) proposed using a binary decision diagram (Akers, 1978) to identify the core and DFs. However, they only used models up to 5000 features for the evaluation of their work. The volume of a binary decision diagram is crucial for the used variable ordering (Bryant, 1986). However, the problem of identifying an optimal ordering is NP-complete (Bollig and Wegener, 1996). Lesta et al. (2015) converted the FM into a constraint satisfaction problem and identified contradictions in attributed models, explaining them using the QuickXplain algorithm. They explained DFs, FOFs and void models based on a constraint solver. Further, they only used one model (with less than 500 features) for the evaluation of this work. However, there is no open-source implementation available for their work. Kowal et al. (2016) provided a generic algorithm to describe several anomalies in FMs such as DFs, FOFs, redundant constraints and void models using predicate logic. They computed shorter explanations and highlighted the most significant parts that could be the cause of an anomaly to benefit the developers. However, they only used models with 2833 constraints and 2513 features for the evaluation. Xiang et al. (2018) proposed an SATVaEA approach to handle the optimal feature selection problem. It combines the many-objective evolutionary algorithm (Xiang et al., 2016) with two SAT solvers (a stochastic local search-based SAT solver and a conflict-driven clause learning SAT solver). They evaluated their approach using models up to 62,482 features. Additionally, a feature model analyzer was developed in (Galindo and Benavides, 2020b) to determine the set of dependencies and explanations of FOFs and DFs. 3. Running example of jogo feature model This section describes feature modeling notation with an example of Jogo FM available at SPLOT. A modified version of Jogo FM (as shown in Fig. A.1 of Appendix A) is used to explain the implementation of the proposed method for handling defects due to DFs with their sources and solutions. The root feature jogo must be included in each software product. More than one child feature can have the same parent. For instance, child features of attribute are hometeam, awayteam, and homescore. Various relationships used in feature modeling notation are described in the columns 1–2 of Table 1, where columns 1 and 2 represent the name of relationship, graphical representation of FM notation along with its description, and corresponding example from Fig. A.1, respectively. For better interpretation, distinctive names are allocated to all features (including the features that appear more than once) and Cross-Tree Constraints (CTCs) in the model. Further, “m”and “o”signify a mandatory feature and an optional feature, respectively, where a feature will be one of them. The CTCs i.e., implication and exclusion have been shown with “i”and “e”, respectively, where a CTC can be either of them. To illustrate the proposed work, additionally 83 features and 39 CTCs are deliberately inserted in the Jogo FM to generate defects due to DF. 4. Classification of defects due to dead feature Various types of defects due to DF are derived from the existing literature (Salinesi and Mazo, 2012;vonderMaßen and Lichter, 2004; Salinesi et al., 2010;Rinc´ on et al., 2014;Kowal et al., 2016;Zhang et al., 2013;Segura et al., 2012;Galindo and Benavides, 2020b;Bhushan et al., 2020;Javed, 2014). These defects are classified into four categories which further include sets of possible cases (as shown in Table 2 where feature(s) in grey color is dead) (i) DFs caused by the mutual exclusion between optional feature and full-mandatory feature where DF1−DF8 represent its cases, (ii) DFs due to implication and exclusion where DF9−DF16 represent its cases, (iii) DFs due to implication and group cardinality where DF17- DF18 represent its cases, and (iv) DFs due to exclusion and group cardinality where DF19- DF20 describe its cases. Further, each of the cases (i.e., DF1−DF20) is graphically represented and its corresponding description for better comprehension of the source of DF(s) is also given in Table 2. M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 3 5. Proposed ontological knowledge-based method This section discusses the proposed method (using the running example of Jogo FM) for handling defects due to DF to derive DF free valid software products from SPL. Fig. 1 represents the framework of the proposed ontological knowledge-based method. Following describes the two stages of this framework: 5.1. Ontology-based knowledge representation FeatureIDE tool (Thüm et al., 2014b) imports Jogo FM from SPLOT repository (in simple XML feature model format). FeatureIDE’s visualization functionality is used for the graphical illustration of this model. Further, editing is enabled by the model editor of this tool. In Fig. 2, extra features (i.e. f_1 -f_83) and CTCs (i.e. i1-i16,e1-e23) are introduced into the input model (Fig. 2 (a)) to generate defects due to DF as shown in Fig. 2 (b) and 2 (c). A transformer (available at https://bit. ly/3cz9SA0) is developed and used to generate ontology-based KR of modified Jogo FM (available at https://bit.ly/3B0qOsP in XML format) as shown in Fig. B.1 of Appendix B. It corresponds to the model’s features and their relationships. Further, “exc”,“imp”,“f”,“p”, and “card” represent the predicates exclusion, implication, feature, parent, and cardinality, respectively, which are used for creating this ontology. Table 1 represents the patterns or rules used to obtain ontology-based KR of FM. Each FM notation in column 1 is transformed into corresponding ontology-based KR as shown in column 3 with its description and suitable example (from Fig. B.1) for better understanding. For predicate parent, FM notation shown in row 2 is transformed into corresponding ontology-based KR i.e., p(b1,a) which signifies that child b1 has parent a, for example, p(match, jogo) from Fig. B.1. 5.2. Analyze defects due to dead feature Each case of defect due to DF from Table 2 is shown in Fig. 2 (b) and 2 (c) i.e., DF1−DF20. FOL based rules are developed (as shown in Fig. C.1 of Appendix C i.e., df1−df20) to detect these defects with sources and solutions. These rules can be applied separately as well as concurrently to the created ontology-based KR of Jogo FM (refer Fig. B.1 of Appendix B) using SWI-Prolog to handle these defects. The outcomes produced after all rules were applied to the ontology are shown in Fig. D.1 of Appendix D. These are presented in a comprehensible natural language along with identified defects due to DF, sources and solutions. Also, product line developers can utilize the results to handle these defects by removing CTCs related to the cause of defects. 6. Experiments and results discussion In this section, the findings from experiments done to evaluate the proposed method are presented. The experimental setup and models used to evaluate the proposed method are given in Section 6.1. The accuracy, performance analysis, and scalability are used to evaluate the method. The minimalism of the rules given in Section 6.6 is used to evaluate the proposed rules. The method is also compared with previous works in Section 6.7, followed by threats to the validity in Section 6.8. 6.1. Experimental setup and benchmarks The experimental setup to evaluate the proposed method includes an Asus VivoBook S14 with Windows 10 of 64 bits, processor Intel(R) Core (TM) i3-7100U CPU @2.40 GHz, RAM memory of 8.00 GB, HDD SSD 256 GB, Eclipse Luna SR2 (5.5.2), FeatureIDE 2.7.4, SPLOT repository, and SWI-Prolog (Version 8.4.3, 64 bits). The proposed method was evaluated on a corpus of 25 FMs (5 and 20 are generated using the Table 1 Relationships in FM (Kang et al., 1990;Kowal et al., 2016;Galindo et al., 2016) and patterns used for its ontology-based KR. FM Notation with description Example (Refer Fig. A.1 of Appendix A) Ontology-based KR with description and example (Refer Figure B.1 of Fig. B.1) Optional: Whenever ais incorporated, b1 might be incorporated. Whenever awayteam is chosen, f_28 is optional to incorporate. f(b1,o) Description: Feature b1 is optional Example: f(f_70,o) Mandatory: b1 must be incorporated whenever ais incorporated and vice versa. It is mandatory to incorporate match whenever jogo is selected. f(b1,m) Description: Feature b1 is mandatory Example: f(jogo,m) Or: b1 and b2 are in or-relationship with a. Whenever ais chosen at least one from b1 and b2 must be integrated. Whenever f_81 is incorporated, f_82,f_83, or both can be incorporated. card([b1,b2],a, (Ayorinde and Akinkunmi, 2013; Heradio et al., 2012a)) Description: At least one from b1 and b2 (i.e., child features of a) can be chosen. Example: card([f_82,f_83],f_81 (Ayorinde and Akinkunmi, 2013;Heradio et al., 2012a)) Alternative: b1 and b2 are in an alternative relationship with a. Whenever ais included, exactly one from b1 and b2 has to be integrated. Whenever f_55 is incorporated, exactly one from f_56 and f_57 has to be incorporated. card([b1,b2],a, (Ayorinde and Akinkunmi, 2013Ayorinde and Akinkunmi, 2013)) Description: Exactly one from b1 and b2 (i.e., child features of a) can be chosen. Example: card([f_56,f_57],f_55, (Ayorinde and Akinkunmi, 2013Ayorinde and Akinkunmi, 2013)) Exclusion: Both cand dcannot be part of a valid product simultaneously. Exclusion between f_2 and f_3 means that no product will incorporate these features together. exc(c,d,e1) Description: cexcludes dwhere exclusion constraint is described by e1 Example: exc(f_2,f_3,e1) Implication: dmust be incorporated in each valid product with c. f_27 implies f_29 means any product including f_27 must include f_29 imp(c,d,i1) Description: cimplies dwhere implication constraint is described by i1 Example: imp(c,d,i1) * a is the parent feature where b1 and b2 are its child features, FM: Feature model, KR: Knowledge representation. M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 4 Table 2 Details of various cases of defects due to DF (Salinesi and Mazo, 2012;vonderMaßen and Lichter, 2004;Salinesi et al., 2010;Rinc´ on et al., 2014;Kowal et al., 2016; Zhang et al., 2013;Segura et al., 2012;Galindo and Benavides, 2020b;Bhushan et al., 2020;Javed, 2014). Defects due to DF Description Defects due to DF Description FMCF band OCF chave the same parent awhere b excludes c. The bbeing mandatory should be embodied in all products. Due to the exclusion between band c, both cannot be embodied jointly in any product. It signifies that cis excluded from each product and hence, cturns into a DF. OCFs b, c and dhave same PF awhere cis dead as both b and dexclude cand are implied by c. FMCF band OCF chave same parent awhere bexcludes cand turns cinto a DF. OF dalso transforms into a DF as its parent cis dead also. OCFs b, c and dhave same PF awhere bturns into a DF as dis implied by c which in turn is implied by band further, bis excluded by both cand d. ais the parent of MCF band OCF c,bis the parent of FMCF dwhere dexcludes cand thus, cconverts into a DF. OCFs b, c,dand ehave same PF awhere band cturn into dead as cimplies b, d, e, and is excluded by band dalong with eis excluded by d. MCF band OCF chave same PF a,bis parent of FMCF dand OCF ehas a parent c. The feature cturns into a DF as dexcludes it, and due to the dead parent ewill also convert into dead. Both OCFs band chave same PF awhere btransforms into dead, as it implies cwhich further excludes b. FMCF cwhich has a parent MF aexcludes an OCF dthat has a parent OF b(in this case, bcan be either OF or MF). Thus, dchanges into a DF. OCFs band chave same PF awhere bexcludes cwhich is having dand eas alternative-child features with group cardinality <1.1>, further, dimplies bconverting dinto a DF. MCF bhas a PF a. Two OCFs cand dhave same parent b where aexcludes both cand d. Thus, cand dtransform into DFs. OCF band FMCF chave same PF awhere cimplies band having d, e and fas or-child features with group cardinality <1.3>where dturns into dead as it is excluded by b. MCF band OCF chave same PF a. Therefore, cconverts into a DF as it is excluded by a. FMCF band MCF c(here, cmay be either mandatory or optional) have same PF awhere cis having dand eas alternative-child features with group cardinality <1.1>. Due to the implication from bto d, e is transformed into a DF. FMCF band OCF chave same PF a,cis parent of OCFs dand ewhere dis implied by band echanges into a DF as it is excluded by b. An OCF chas a PF aand b(here, aand bare fullmandatory features) has dand eas alternative-child features where cimplies both.Accordingly, cchanges into a DF. (continued on next page) M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 5 FeatureIDE tool and from SPLOT, respectively). Further, a description of these models is provided in Table 3, where 18 out of 25 models are with 0% CTC ratio, indicating the absence of DFs as no feature is involved in CTCs. Further, it has been clearly mentioned that in order to illustrate the proposed method, additional features and CTCs are intentionally injected in the models to describe defects due to DF (refer Subsection 5.1). 6.2. Accuracy The correct ontology-based KR of FM and detection of defects due to DF, their sources and solutions were used to evaluate the accuracy of the method. The number of exclusions, implications, cardinalities, optional and mandatory features in the generated ontology-based KR of model is compared with the XML file from FeatureIDE (consequent tags used in the transformer are searched) to check the correct KR of the model. Further, all 25 models (root feature, group cardinalities features, and CTCs) with features up to 31,761 were considered for these comparisons. These comparisons yielded identical results, with 0% false positives and 100% accuracy in the ontology-based KR of model. Further, equation (1) defines the accuracy of the detection of defects due to DF, their sources and solutions. Table 2 (continued) Defects due to DF Description Defects due to DF Description FMCF band OCF chave same PF a. The feature cis excluded by bwhich converts cinto a DF. OF dhas a parent balso turns into a DF as it implies DF c. FMCF band MCF c(here, cmay be either mandatory or optional) have same PF awhere cis having dand eas alternative-child features with group cardinality <1.1>. As bexcludes d, consequently, dcan never be selected and it turns into a DF. FMCF band OCF chave same PF awhere cturns into FOF as it is implied by b, thus, it is embodied in each product in which bis incorporated. OF dwhich has a parent bchanges into a DF as it is excluded by FOF c. FMCF band MCF c(here, cmay be either mandatory or optional) have same PF awhere cis having dand eas orchild features with group cardinality <1.2>and changes dinto DF as bexcludes d. *DF: Dead feature, OF: Optional feature, MF: Mandatory feature, PF: Parent feature, FMCF: Full-mandatory child feature, OCF: Optional child feature, MCF: Mandatory child feature, FOF: False-optional feature. Also, “a”may be either full-mandatory or root feature except in DF5 and DF18. Fig. 1. Framework of the proposed ontological knowledge-based method. M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 6 In the proposed method, 100% of the defects due to DF, their sources and solutions are detected in 25 models (see Table 3) with 0% false positives. The expected defects, sources and solutions were detected by all 20 rules (independently and concurrently) with 100% accuracy in handling defects considered in our work. 6.3. Comparison with FeatureIDE tool In this section, FeatureIDE tool is compared with the proposed method for accuracy. The results attained after analyzing Jogo FM with defects due to DF using FeatureIDE and the proposed method are shown in columns 3 and 4 of Table E.1 in Appendix E, respectively. Fig. 2. (a) Jogo FM from SPLOT repository, (b) DF1−DF14, and (c) DF15-DF20 defects due to DF where features in grey color are dead. Accuracy=Numberof identifieddefectsduetoDF(withsourcesandsolutions) Totalnumberof defectsduetoDF(withsourcesandsolutions)inmodel (1) M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 7 In Table E.1, status (Z) signifies accuracy as follows: ●1 specifies that FeatureIDE found an accurate defect due to DF or constraints for its source. ●0.5 specifies that FeatureIDE only found one or half of the constraint out of multiple which contributed to source of defect due to DF. ●0 specifies that FeatureIDE did not find any defect due to DF or correct defect or constraints incorporated in the source of defect. accuracy =1 x∑ 25 x=1(1 y∑ 20 y=1 Zx,y)(2) Z x,y ∈[0,1] where Z x,y, y and x signify the status, number of rules and count of models, respectively. Table E.1 provides the calculated values of Z for Jogo FM with defects. Further, in the same manner each of the remaining model was also analyzed using the FeatureIDE tool. The value of Z x,y was computed for all 20 rules, which were executed for each of the considered FM (i.e., 25 models) as shown in equation (2). The average of the values obtained from equation (2) was used to determine the accuracy of 15% by FeatureIDE. With 0% false positives, the presented method accurately detected all considered defects (with sources and solutions) 6.4. Performance analysis and evaluation In this section, the performance of the presented method is evaluated and analyzed by implementing the method on FMs with features 1000, 2000, 3000, 4000 and 5000, and the execution time taken by the entire rules in dealing with defects due to DF in these models was also computed. The aforementioned information is utilized for comparing the execution time of the factors (i.e., number of features and CTCs, and height of tree as shown in Figs. 3 and 4, respectively) that are impacting the performance of the proposed method. These factors were selected because they affect the execution time. Further, the data’s goodness of fit is measured by computing R 2 value. It estimates the degree of variation in a dependent variable with respect to an independent variable (Qiao et al., 2020). It also measures how strongly a relationship exists between dependent and an independent variable(s) for analyzing performance of the method. It has values between 0 and 1. The better fit will be attained if the value of R 2 is closer to 1. The R 2 values for all the plots of Figs. 3 and 4are computed and shown in Tables 4 and 6, respectively, where dependent and independent variable(s) are time required by entire rules (to detect defects, their sources and solutions) and number of features (in model), correspondingly. The value 1 signifies that the number of features explains the variation in the time required by entire rules perfectly well. Based on the aforementioned parameters, the findings of performance analysis are illustrated in Tables 5 and 7. Various notations used to comprehend these results are discussed below: (a) Enhanced: The performance of the model is enhanced, as handling defects took less time when compared to the models with moderate and decreased performance. (b) Moderate: The performance of the model is average, as handling defects took average time when compared to the models with enhanced and decreased performance. (c) Decreased: The performance of the model is decreased, as handling defects took more time when compared to the models with enhanced and moderate performance. The factors that impact the performance of proposed method are discussed as follow: 6.4.1. Cross-tree constraints and number of features Fig. 3 illustrates the time required by entire rules to deal with defects in models (with features 1000, 2000, 3000, 4000 and 5000) based on number of features (Fig. 3 (a)), implications (Fig. 3 (b)), exclusions (Fig. 3 (c)), and exclusions with implications in 1:1 proportion (Fig. 3 (d)). Here, X-axis and Y-axis depict the count of features in the model(s) and time (in seconds) required by entire rules to deal with defects, respectively. Further, green, red and blue color lines represent the total amount of time required by rules to deal with defects in models with. (i) mandatory features, optional features, mandatory and optional features in 1:1 proportion, respectively (refer Fig. 3 (a)). (ii) mandatory features with implications, optional features with implications, mandatory and optional features in 1:1 proportion with implications, respectively (refer Fig. 3 (b)). (iii) mandatory features with exclusions, optional features with exclusions, mandatory and optional features in 1:1 proportion with exclusions, respectively (refer Fig. 3 (c)). (iv) mandatory features with implications and exclusions in 1:1 proportion, optional features with implications and exclusions in 1:1 proportion, mandatory and optional features with implications and exclusions in 1:1 proportion, respectively (refer Fig. 3 (d)). Table 4 displays the calculated R 2 value for each of the graphs presented in Fig. 3. Accordingly, Table 5 presents the outcomes of the performance analysis for the same. It is observed that in most cases, performance was enhanced with (i), whereas it was decreased with (iii). 6.4.2. Height of the tree Fig. 4 illustrates the time required by entire rules to deal with defects in models with features 1000, 2000, 3000, 4000 and 5000, in accordance with the height of the tree, with levels 10, 20, 30, 40, and 50, respectively. Additionally, these models incorporate a number of features (Fig. 4 (a)), implications (Fig. 4 (b)), exclusions (Fig. 4 (c)), and exclusions with implications in 1:1 proportion (Fig. 4 (d)). Here, X-axis Table 3 Description of FMs (available at https://bit.ly/3TFo9Mu). S. No. FM NF NCTC NDF TDF SPLOT repository: Real FMs 1 CIMS PL 88 39 20 1–4 2 UPL 23 3 2 3 3 RE Process 36 5 4 3,4 4 Gsist 51 10 8 1 5 Card Product 64 13 10 1,3 6 B2B Website 78 15 12 1,3,4 7 Bike 105 34 16 1,2 8 Adempiere 121 37 18 1,2,3 9 Electronic Drum 152 42 22 3 10 ClassicShell 241 89 40 1–4 11 urna_eletronica 272 83 44 3,4 12 Webmail 346 117 60 1–4 13 PGL_add 392 129 68 1 14 Printers 524 156 80 1–4 15 Electronic Shopping 676 187 88 1 16 A Model for Decision-making for Investments on Enterprise Information Systems 806 387 100 1–4 SPLOT repository: Automatically-generated 3-CNF FMs 17 Model-1 1057 260 112 1,3,4 18 Model-2 1648 334 120 1–4 19 Model-3 2819 368 136 1,2 20 Model-4 6161 423 140 1–4 FeatureIDE Tool 21 Model-5 11759 410 158 1,2,3 22 Model-6 15705 312 160 1–4 23 Model-7 20738 322 168 1 24 Model-8 25773 346 176 1,2 25 Model-9 31761 780 400 1–4 FM: Feature model. NF: Number of features, NCTC: Number of CTCs, NDF: Number of DFs, TDF: Type of DFs where 1–4 signifies all four categories of DFs (Section 4). M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 8 and Y-axis depict the count of features in the model(s) and time (in seconds) required by entire rules to deal with defects, respectively. Further, green, red and blue color lines represent the total amount of time required by rules to deal with defects in models (as per levels 10, 20, 30, 40, and 50) with. (i) mandatory features, optional features, mandatory and optional features in 1:1 proportion, respectively (refer Fig. 4 (a)). (ii) mandatory features with implications, optional features with implications, mandatory and optional features in 1:1 proportion with implications, respectively (refer Fig. 4 (b)). (iii) mandatory features with exclusions, optional features with exclusions, mandatory and optional features in 1:1 proportion with exclusions, respectively (refer Fig. 4 (c)). (iv) mandatory features with implications and exclusions in 1:1 proportion, optional features with implications and exclusions in 1:1 proportion, mandatory and optional features with implications and exclusions in 1:1 proportion, respectively (refer Fig. 4 (d)). Table 6 displays the calculated R 2 value for each of the graphs presented in Fig. 4. Accordingly, Table 7 presents the outcomes of the performance analysis for the same. It is observed that in most cases, performance was enhanced with (ii), whereas it was decreased with (iii). 6.5. Scalability The average of execution time was computed to test the performance of the proposed method by implementing all rules to handle defects due to DF, on all the models with features (created using FeatureIDE tool) 7000, 12,000, 17,000, 22,000, 27,000 and 32,000, as shown in Fig. 5. The number of features in each model and time are represented on the X- axis and Y-axis, respectively. The plot illustrates the scalability of a given method to handle these defects. The time taken by the queries to handle defects in models with features 7000 and 32,000 is 0.174 and 0.198 s, respectively. It is observed that defects in a large-sized FM with 32,000 features were handled in a reasonable time of 0.198 s. In order to obtain the accurate measures of time, each rule was applied 75 times for each of the 25 models. The computation of execution time is based on the average of 75 executions of all rules on each model. 6.6. Minimalism of the rules A rule must have a minimum of two features (one feature must be root) and one relationship. A huge set of rules to handle defects due to DF can be more time-consuming and may deteriorate performance efficiency of the proposed method. Therefore, minimalism of the rules is required to enhance performance efficiency. In order to attain minimalism of the rules, the number of related rules should be minimized. The expected result (i.e., detected defects due to DF, their sources and solutions) is not affected by the removal of a related rule from the set of entire rules. It will diminish the overall execution time required to detect defects, their sources and solutions. However, related rules are still essential to handle particular types of defects independently, even though these defects are being handled by the set of minimum number of rules (obtained using minimalism of the rules) which is sufficient to detect defects, their sources and solutions considered in our method. For instance, as shown in Table 8, the removal of related rules DF1 and DF3 from the entire rules (DF1−DF20) does not affect the result, as the same defects can be detected using DF2 as well as DF9, and DF4, respectively. Further, the performance of the proposed method will be Fig. 3. Time taken by entire rules based on number of (a) features, (b) implications, (c) exclusions, and (d) exclusions and implications in 1:1 proportion. M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 9 Appendix D Fig. D.1. Results attained after implementation of rules. M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 16 Appendix E Table E.1 Comparing accuracy of proposed work and FeatureIDE using Jogo FM for defects due to DFs. FOF: False-optional feature, RC: Redundant constraint which could be removed, DF: Dead Feature. M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 17 References Akers, S.B., 1978. Binary decision diagrams. IEEE Comput. Architect. Lett. 27 (6), 509–516. Ayorinde, I., Akinkunmi, B., 2013. Application of first-order logic in knowledge based systems. Afr. J. Comput. ICTs 6, 45–52. Benavides, D., Segura, S., Trinidad, P., Cort´ es, A.R., 2007. FAMA: tooling a framework for the automated analysis of feature models. VaMoS 2007, 1. Bhushan, M., Goel, S., 2016. Improving software product line using an ontological approach. S¯ adhan¯ a 41 (12), 1381–1391. Bhushan, M., Goel, S., Kumar, A., 2018a. Improving quality of software product line by analysing inconsistencies in feature models using an ontological rule-based approach. Expet Syst. 35 (3), e12256 https://doi.org/10.1111/exsy.12256. Bhushan, M., Goel, S., Kaur, K., 2018b. Analyzing inconsistencies in software product lines using an ontological rule-based approach. J. Syst. Software 137, 605–617. https://doi.org/10.1016/j.jss.2017.06.002. Bhushan, M., Negi, A., Samant, P., Goel, S., Kumar, A., 2020. A classification and systematic review of product line feature model defects. Software Qual. J. 28 (4), 1507–1550. Bhushan, M., Duarte, J.´ A.G., Samant, P., Kumar, A., Negi, A., 2021. Classifying and resolving software product line redundancies using an ontological first-order logic rule based method. Expert Syst. Appl. 168, 114167. Bollig, B., Wegener, I., 1996. Improving the variable ordering of OBDDs is NP-complete. IEEE Trans. Comput. 45 (9), 993–1002. Brewster, C., O’Hara, K., 2004. Knowledge representation with ontologies: the present and future. IEEE Intell. Syst. 19 (1), 72–81. Bryant, R.E., 1986. Graph-based algorithms for boolean function manipulation. Comput. IEEE Transac. 100 (8), 677–691. Crowley, J.L., Coutaz, J., Grosinger, J., Vazquez-Salceda, J., Angulo, C., Sanfeliu, A., Cohn, A.G., 2022. A hierarchical framework for collaborative artificial intelligence. IEEE Pervas. Comput. 22 (1), 9–18. Dur´ an, Amador, Benavides, David, Segura, Sergio, Trinidad, Pablo, Cort´ es, Antonio Ruiz, 2017. FLAME: a formal framework for the automated analysis of software product lines validated by automated specification testing. Software Syst. Model 16 (4), 1049–1082. Elfaki, A.O., Fong, S.L., Aik, K.L.T., Johar, M.G.M., 2013. Towards detecting redundancy in domain engineering process using first order logic rules. Int. J. Knowl. Eng. Soft Data Paradigms 4 (1), 1–20. Felfernig, A., Benavides Cuevas, D.F., Galindo Duarte, J.´ A., Reinfrank, F., 2013. Towards anomaly explanation in feature models. In: ConfWS-2013: 15th International Configuration Workshop. CEUR-WS, pp. 117–124, 2013. Fernandez-Amoros, D., Heradio, R., Cerrada, J.A., Cerrada, C., 2014. A scalable approach to exact model and commonality counting for extended feature models. IEEE Trans. Software Eng. 40 (9), 895–910. Galindo, J.A., Benavides, D., 2020a. A Python framework for the automated analysis of feature models: a first step to integrate community efforts. In: Proceedings of the 24th ACM International Systems and Software Product Line Conference-Volume B, pp. 52–55. Galindo, Jos´ e A., Benavides, David, 2020b. A Python framework for the automated analysis of feature models: a first step to integrate community efforts. In: 24th International Software Product Line Conference. ACM, pp. 52–55. Galindo, J.A., Turner, H., Benavides, D., White, J., 2016. Testing variability-intensive systems using automated analysis: an application to android. Software Qual. J. 24 (2), 365–405. Galindo, J.A., Benavides, D., Trinidad, P., Guti´ errez-Fern´ andez, A.M., Ruiz-Cort´ es, A., 2019. Automated analysis of feature models: Quo vadis? Computing 101 (5), 387–433. Galster, M., Weyns, D., Tofan, D., Michalik, B., Avgeriou, P., 2013. Variability in software systems—a systematic literature review. IEEE Trans. Software Eng. 40 (3), 282–306. Giraldo, G.L., Rinc´ on-Perez, L., Mazo, R., 2014. Identifying dead features and their causes in product line models: an ontological approach. Dyna 81 (183), 68–77. Heeptaisong, T., Shivihok, A., 2012. Soil knowledge-based systems using ontology. In: Proceedings of the International MultiConference of Engineers and Computer Scientists, 1. Hong Kong. Hentze, M., Pett, T., Thüm, T., Schaefer, I., 2021. Hyper explanations for feature-model defect analysis. In: 15th International Working Conference on Variability Modelling of Software-Intensive Systems, pp. 1–9. Heradio, R., Fernandez-Amoros, D., De La Torre, L., Abad, I., 2012a. Exemplar driven development of software product lines. Expert Syst. Appl. 39 (17), 12885–12896. Heradio, R., Fernandez-Amoros, D., Torre-Cubillo, L., Garcia-Plaza, A.P., 2012b. Improving the accuracy of COPLIMO to estimate the payoff of a software product line. Expert Syst. Appl. 39 (9), 7919–7928. Jackson, D., 2002. Alloy: a lightweight object modelling notation. ACM Trans. Software Eng. Methodol. 11 (2), 256–290. Jain, S., Mishra, S., 2014. Knowledge representation with ontology. In: IJCA Proceedings on International Conference on Advances in Computer Engineering and Applications ICACEA, 6. Ghaziabad, India, pp. 1–5. Javed, M., 2014. Towards the maturity model for feature oriented domain analysis. Comput. Ecol. Software 4 (3), 170. Kang, K.C., Cohen, S.G., Hess, J.A., Novak, W.E., Peterson, A.S., 1990. Feature-Oriented Domain Analysis (FODA) Feasibility Study. Carnegie-Mellon Univ Pittsburgh Pa Software Engineering Inst. Kowal, M., Ananieva, S., Thüm, T., 2016. Explaining anomalies in feature models. ACM SIGPLAN Not. 52 (3), 132–143. Le, V.M., Felfernig, A., Uta, M., Benavides, D., Galindo, J., Tran, T.N.T., 2021. DirectDebug: automated testing and debugging of feature models. In: 2021 IEEE/ ACM 43rd International Conference on Software Engineering: New Ideas and Emerging Results (ICSE-NIER). IEEE, pp. 81–85. Lebbink, H.J., Witteman, C.L., Meyer, J.J.C., 2002. Ontology-based knowledge acquisition for knowledge systems. In: Proceedings of the 14th Dutch-Belgian Artificial Intelligence Conference (BNAIC’02), pp. 195–202. Leuven, Belgian. Lesta, U., Schaefer, I., Winkelmann, T., 2015. Detecting and explaining conflicts in attributed feature models. arXiv preprint arXiv:1504.03483 31–43. Megha, A. Kumar, Goel, S., 2018. A Generic Framework for Improving Software Product Line Using an Ontological Rule-Based Approach. Doctoral dissertation. Mendonca, M., Branco, M., Cowan, D., 2009. SPLOT: software product lines online tools. In: Proceedings of the 24th ACM SIGPLAN Conference Companion on Object Oriented Programming Systems Languages and Applications, pp. 761–762. Northrop, L., 2008. Software Product Lines Essentials. Carnegie-Mellon Univ Pittsburgh Pa Software Engineering Inst. Perez-Morago, H., Heradio, R., Fernandez-Amoros, D., Bean, R., Cerrada, C., 2015. Efficient identification of core and dead features in variability models. IEEE Access 3, 2333–2340. Qiao, L., Li, X., Umer, Q., Guo, P., 2020. Deep learning based software defect prediction. Neurocomputing 385, 100–110. Reiter, R., 1987. A theory of diagnosis from first principles. Artif. Intell. 32 (1), 57–95. Rinc´ on, L.F., Giraldo, G.L., Mazo, R., Salinesi, C., 2014. An ontological rule-based approach for analyzing dead and false optional features in feature models. Electron. Notes Theor. Comput. Sci. 302, 111–132. Rinc´ on, L., Giraldo, G., Mazo, R., Salinesi, C., Diaz, D., 2015. Method to identify corrections of defects on product line models. Electron. Notes Theor. Comput. Sci. 314, 61–81. Ripon, S., Hossain, S., Bhuiyan, T., 2013. Managing and Analysing Software Product Line Requirements arXiv preprint arXiv:1310.0152. Salinesi, C., Mazo, R., 2012. Defects in product line models and how to identify them. Software Product Line-Advanced Topic 97–122. Salinesi, C., Mazo, R., Diaz, D., 2010. Criteria for the verification of feature models. In: INFORSID 2010. Schlick, M., Hein, A., 2000. Knowledge engineering in software product lines. In: Proceedings of ECAI 2000-Workshop on Knowledge-Based Systems for Model-Based Engineering. Segura, S., Galindo, J.A., Benavides, D., Parejo, J.A., Ruiz-Cort´ es, A., 2012. BeTTy: benchmarking and testing on the automated analysis of feature models. In: Proceedings of the Sixth International Workshop on Variability Modeling of Software-Intensive Systems, pp. 63–71. Smith, R.G., Schoen, E.J., Tenenbaum, J.M., 2022. Early AI applications at schlumberger. IEEE Ann. Hist. Comput. 44 (1), 88–102. Sureephong, P., Chakpitak, N., Ouzrout, Y., Bouras, A., 2008. An ontology-based knowledge management system for industry clusters. In: Global Design to Gain a Competitive Edge. Springer, London, pp. 333–342. Thüm, T., Apel, S., K¨ astner, C., Schaefer, I., Saake, G., 2014a. A classification and survey of analysis strategies for software product lines. ACM Comput. Surv. 47 (1), 1–45. Thüm, T., K¨ astner, C., Benduhn, F., Meinicke, J., Saake, G., Leich, T., 2014b. FeatureIDE: an extensible framework for feature-oriented software development. Sci. Comput. Program. 79, 70–85. Van Harmelen, F., Lifschitz, V., Porter, B. (Eds.), 2008. Handbook of Knowledge Representation. Elsevier. vonderMaßen, T., Lichter, H., 2004. Deficiencies in feature models. In: workshop on software variability management for product derivation-towards tool support, 44, p. 21. Wang, L., 2019. From intelligence science to intelligent manufacturing. Engineering 5 (4), 615–618. Witherell, P., Krishnamurty, S., Grosse, I.R., Wileden, J.C., 2010. Improved knowledge management through first-order logic in engineering design ontologies. Artificial Intelligence for Engineering Design. Anal. Manuf. 24 (Special Issue 02), 24. Xiang, Y., Zhou, Y., Li, M., Chen, Z., 2016. A vector angle-based evolutionary algorithm for unconstrained many-objective optimization. IEEE Trans. Evol. Comput. 21 (1), 131–152. Xiang, Y., Zhou, Y., Zheng, Z., Li, M., 2018. Configuring software product lines by combining many-objective optimization and SAT solvers. ACM Trans. Software Eng. Methodol. 26 (4), 1–46. Zhang, G., Ye, H., Lin, Y., 2013. An approach for validating feature models in software product lines. J. Software Eng. 7 (1), 1–29. M. Bhushan et al. Engineering Applications of Articial Intelligence 136 (2024) 109000 18