TopIntroduction
Recently, Software Product Line (SPL) is a major technical paradigm to develop software products that has been used by big companies. There are two main phases in SPL: the domain-engineering phase and the application-engineering phase. In Domain-engineering Phase, software assets are collected and organized in suitable model for configuration. Domain-engineering Phase is a continuous process. When there are new assets, they are added to the existing assets. Cumulative aggregation (for the software assets) may produce some errors. The grouping of assets may be made at different times and by different groups of people. In some cases, there is a parallel development process, i.e., several people add assets (to develop domain-engineering) at the same time. Moreover, Ajila and Kaba (2008) have proved that the domain-engineering process is a dynamic for some of reasons, such as changes in: technology, user requirements, or business rules. Another reason why domain-engineering is complicated is that the nature of a feature, i.e. software asset, (whether optional or mandatory) can differ from product to product (Buhne et al., 2004). As a fact, a successful software product which is generated from domain-engineering is highly dependent on the validity of it. Hence, validation is a significant process within the domain-engineering.
Recently, validation of SPL has been discussed as an important issue (Benavides et al., 2010; Heymans et al., 2011; Eisenecker et al., 2012). Mannion (2002) defines validation in SPL as a mechanism that is used to ensure that a SPL can produce at least one product that can satisfy the constraint dependency rules. Lan et al. (2006) define validation in variability as a mechanism to check if the configuration output satisfies corresponding variability constraints (in a specific domain) or not. In this article, we define validation in domain-engineering as a method used to ensure the detection of inconsistency in the domain-engineering’s and provide explanations to the modeler so that inconsistency can be detected and eliminated.
Formalization and reasoning represent the lifecycle steps for the automated validation of SPL. Formalization means modeling SPL using the standard method, which allows some standard tools to reason the model. In this work, we have used First Order Logic (FOL) to formalize SPL and used Prolog (Wielemaker, 2007) as a reasoning tool.
In this article, inconsistency detection in domain engineering has been discussed. The initial versions of this work are published in Elfaki etl (2008) and Elfaki et al. (2009) where the formalization of our approach, i.e., our notations has been described in details.
In this article, we analyse the inconsistency problem and define three types of inconsistency. First Order Logic rules are developed in order to detect inconsistency in the domain-engineering process. The definition of the three types of inconsistency and the detection of inconsistency in the domain-engineering process are our contributions to the literature in respect of this operation. In the literature, only direct inconsistency is detected at the configuration stage (Hemakumar, 2008; White et al., 2009)
This article is organized as follow: Background is states in section 2. The inconsistency detection operation are described and discussed in section 3. Future directions are presented in section 4. Conclusion is discussed in section 5.