Feature-oriented engineering of PBX software for adaptability and reuseability

Abstract

Incorporating a high level of adaptability and reusability into software is one challenge that all software engineers face. PBX (Private Branch Exchange) is one such system that requires a high level of adaptability and reusability because of rapidly expanding service features, ever changing communication technology, continuously evolving standards and diverse communication laws and standards in different countries. The software engineering community has made various efforts to address the problem of enhancing software adaptability and reusability. As a result, many programming concepts, such as information hiding, encapsulation, object orientation, abstract data type and modularization, have been developed. Although adequate application of these principles requires the domain or program family perspective, most methods, so far, have been oriented toward developing a single application. FORM (Feature-Oriented Reuse Method), the domain-based software reuse method applied in this paper, concentrates on analyzing and modeling commonalities and differences in applications of a given domain and using the analysis results to develop domain-oriented architectures and software components. The model that captures commonalities and differences is called the 'feature model' and it is used for both the engineering of reusable domain artifacts and the development of actual application software with reusable artifacts. We found that FORM facilitates analysis of variability, as well as commonality, of software before the start of engineering and implementation. With this understanding, adaptability and reusability can be built into software. Also, feature modeling has been found to be an effective method for identifying objects.

PLFaultCAT: A Product-Line Software Fault Tree Analysis Tool

“…A product-line dependency restricts and/or dictates some combinations of variability subsets from being viable products in the form of "mutual exclusion" or "requires" variability dependencies (Kang et al, 1999;Doerr, 2002). A dependency requirement can thus take the form "Any product-line member that has Variability A can not also have Variability B" or in the form "Any product-line member that has Variability C must also have Variability D".…”

From Goals to High-Variability Software Design

“…As such, it can directly help in generating domain-oriented architectures such as productline families [15].…”

Configuring features with stakeholder goals

“…Feature-Oriented Domain Analysis (FODA) assumes that features can be the basis for analyzing and representing commonality and variability of applications in a solution domain [15,7]. A feature represents system functionality realized by a software component [14].…”