Detecting Inconsistency in the Domain-Engineering

Detecting Inconsistency in the Domain-Engineering

Abdelrahman Osman Elfaki (University of Tabuk, Saudi Arabia) and Yucong Duan (Hainan University, China)
Copyright: © 2015 |Pages: 13
DOI: 10.4018/978-1-4666-5888-2.ch697
OnDemand PDF Download:
$30.00
List Price: $37.50

Chapter Preview

Top

Introduction

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.

Key Terms in this Chapter

Feature Model (FM): Considered to be one of the most well-known methods for modelling SPLs. The FM is defined as providing: 1) descriptions of the system from the user point of view and 2) a clear description of a concept (e.g., test-case, input file, component, etc). The features in a FM represent essential abstractions of the SPL to both developers and customers. The FM represents common language between customers and developers. Generally, the software product characteristics are described to both customers and developers as features. Therefore, it is natural and intuitive to express any commonality or variability in terms of features (Kang et al., 1990).

Variability: Different software products can be configured based on customization of the software assets. In order to implement the configuration of software products, all the software assets related to a specific business area are collected in domain engineering. These software assets are categorized into two groups: common assets and variant assets. The common assets are included in all software products, i.e., they must be selected in each configuration. For instance, a save option is a common software asset in all word processing software. The variant assets are options which change from product to product. For instance, send as email is a variant asset because it is not included in all word processing software.

First Order Logic (FOL): Represents the world in terms of objects, properties of objects, and relations between objects. By using connectives and quantifiers, FOL allows sentences to be written about everything in the universe at once. It can also express facts about all of the objects in the universe.

Complete Chapter List

Search this Book:
Reset