A Systematic Literature Review on Feature Oriented Software Development Paradigm

- Feature-Oriented Software Development (FOSD) is a software development paradigm focusing on the overall process of software development of large-scale software systems. The main focus of feature orientation is to divide the software product line systems (SPLs) in terms of features. A feature represents a product requirement of a stakeholder. From the set of features, various software products have automatically derived that share some features and differ in another feature based on customer requirement. The main objective of the work is to identify the state of the art in the overall software development process using FOSD paradigm. The other focuses are finding the phase of FOSD which need more focus, based on automation, and identify the quantity and the types of researches on FOSD techniques to address the software product line development concerns and thus finding the areas discussed and problems addressed so far in the published papers of FOSD. The review was conducted by following the Kitchenham’s guidelines for conducting the systematic literature review, with five research questions and assessed 118 publications from the origin to 2017 from the 5 electronic sources of relevance to FOSD Research and selected 63 from them for detailed study. FOSD is an emerging trend in software development based on automation. Our Study analyses each area, in which existing research is focused and propose the ongoing phases of interest in feature-oriented software development and revealed the need of further research in this field.

to decompose a software system as a collection of features and from that set different software products are often generated that share fundamental features and differ in other features.
The essential properties of FOSD are reuse, structure and variation. Developers structure the system design and code in terms of features, utilizes features a unit for reuse, and variants is achieved by some features unique to the specific customer. While discussing about FOSD it is important to clear the concept of feature in detail. Features can be defined technically by Apel et al. [1] as "a structure that extends and modifies the structure of a given program in order to satisfy a stakeholder's requirement, to implement and encapsulate a design decision, and to offer a configuration option". The concept of features is emphasized in each phases of the software life cycle and appropriate concern is needed for the analysis, design, programming techniques, method, tools also in theory. Features can be defined in different ways using simple abstract words or using technical terms [1]. Each researcher defines the feature in his view point some of them are summarized in Table I.

Author
Definition Kang et al. [2] "a prominent or distinctive user-visible aspect, quality, or characteristic of a software system or systems" Kang et al. [3] "a distinctively identifiable functional abstraction that must be implemented, tested, delivered, and maintained" Czarnecki and Eisenecker [4] "a distinguishable characteristic of a concept (e.g., system, component, and so on) that is relevant to some stakeholder of the concept" Bosh [5] "a logical unit of behavior specified by a set of functional and nonfunctional requirements" Chen et al. [6] "a product characteristic from user or customer views, which essentially consists of a cohesive set of individual requirements" Batory et al. [7] "a product characteristic that is used in distinguishing programs within a family of related programs" Classen et al. [8] "a triplet, f = (R, W, S), where R represents the requirements the feature satisfies, W the assumptions the feature takes about its environment and S its specification" Zave [9] "an optional or incremental unit of functionality" Batory [10] "an increment of program functionality" Apel et al. [11] "a structure that extends and modifies the structure of a given program in order to satisfy a stakeholder's requirement, to implement and encapsulate a design decision, and to offer a configuration option" The difference between feature and other programming paradigm concepts (object, function and aspect) are huge. Features differentiate one product from the other by its externally visible characteristics, where as other programming concepts deals with only internal details of the system. The concept of abstraction is only understandable to the persons with knowledge of programming paradigms.

B. Problem Statement and Justification
The objective of the study is to explore all the aspects of research in the FOSD paradigm. There is no other review published regarding FOSD so far. To that end, we conducted a systematic literature review because it is the best method for identifying and evaluating the studies of a particular domain by make use of a set of predefined research questions. Our systematic literature review helps to obtain a fair and goal oriented evaluation of FOSD. In this survey; we give an overview about the roots and the advancements in feature oriented software development approach focusing on development of efficient and effective software product lines. So our systematic literature review helps the researchers to catch the information about the state of the art techniques and practices for FOSD and the research gaps in existing work. Our systematic literature review points out the strength and weaknesses of existing research based on the review questions and reveal the future scope of research.
We use Goal-Question-Metric (GQM) paradigm [3] to define the goal of our systematic review. In this systematic review, we aim at identifying and assessing approaches for implementing FOSD, optional feature problem, feature defect prediction, feature interaction problem, and find the scope of fully automation in the era of automatic development of software. Our research questions focus on investigating different aspects of existing methods and helping to identify the areas for improvement. The audience of this systematic review includes researchers who would like to obtain an overview of the topic, and practitioners who would like to get familiar with existing methods in order to apply them in industry.

C. Related Reviews
In 2009, Apel Swen et al. [1] conducted a literature study on feature oriented software development that is the one and only one review regarding this topic. In that survey, they compare FOSD with other development approaches and thus provide the roots and advancements in the field of FOSD. Their systematic summarization of several promising work in the field of FOSD give the idea of different lines of research and open issues present at that time. Their prominent aim is to attract more researchers to FOSD community. It has been around 10 years advancements now so we conduct further systematic study on the same topic.

D. Review Questions
The overall research objective of this study is to find and analyze state of the art in FOSD researches based on the available journals. This objective has been broken down into three high-level research questions (RQs) which, in turn, will drive the review method. Table II shows the RQs and their motivation.

Research Question
Interest and Motivation RQ1. What is the amount of automation acquired in each phase of FOSD?
The motivation behind this question is to find the level of automation in each phase of feature oriented software development in research focus on developing a fully automated software framework. RQ2. Which will be the best approach for Implementing variability in FOSD?
Consequently, by answering this RQ, we can get information about: existing implementation approaches and can measure the criteria to find the best one RQ3. What are the implementation techniques for solving feature interaction problem and optional feature problem?
To identify which are the implementation techniques proposed in the literature for feature interaction problem, identifying modeling techniques, analysis, particular notations and guidelines RQ4. How refactoring technique is used in FOSD?
To identify and understand the different refactoring used in feature oriented software development. RQ5. How can we derive features from an application domain?
The main process of FOSD is to analyze the requirements of the domain and derive corresponding features. The various methods for deriving feature and feature relationship are understood by answering this question RQ6. What are the uses of defects prediction techniques in features?
Quality assurance is difficult in SPLs because codes of features may scattered so individual and integration testing may difficult. If we can predict feature defects quality assurance will become easy II. REVIEW APPROACH The systematic review was designed in accordance with the systematic review procedures and processes defined by Kitchenham [12,13]. According to Kitchenham [13], there are 10 sections in the structure of a systematic review: 1. Title; 2. Authorship; 3. Executive summary or abstract; 4.Background; 5. Review questions; 6. Review Method; 7. Inclusion and exclusion of studies; 8.Results; 9. Discussion; and 10.Conclusion. The first 5 sections have been covered so far. The review method comprises four sections: 1. Data sources and search strategy; 2. Study selection; 3. Data extraction; and 4. Data synthesis. This section comprises the review method and the inclusion and exclusion of studies. The results, discussion and conclusion are presented in the next section A. Data Sources and Search Strategy 1) Data sources: In every systematic mapping, the primary studies are identified by using automatic searches on scientific bibliographies or browsing manually by the acquiring the works from journals and conferences of the target field. In our systematic mapping, we applied an automatic search that was complemented with manual searches in the specific venues listed. The aim of this search process was to find as many published papers related to the research questions as possible using a systematic search strategy.
In order to get the primary basic concepts of feature oriented software development and to gather the keywords for searching the data sources, we decided to add the book by Sven Apel et al. [16] about Feature Oriented Software Product Lines because this is the only book that is completely devoted to the study of the concept of FOSD. Sven Apel and his co-researchers are behind most of the researches happened in this field. The sources of our studies were: ACM, IEEE, Springer, Wiley Inter Science, and Google Scholar. The quality of these sources guarantees the quality of the study. The main source of recent papers is from the FOSD conference held continuously every year from 2009 to 2016.
2) Search strategy: The papers which are written in English are selected to study. To answer the questions and carry out the initial search using five steps mentioned in table III using the keywords mentioned in Table IV.

B. Study Selection (Inclusion and Exclusion of Studies)
From the sources mentioned in previous section, study selection is started by applying the keyword shown in table 4 using AND or OR logical connectives and then followed the steps as shown in table V based on the inclusion exclusion criteria. In initial search we got 118 papers and after the study selection process we select 63 papers for the detailed study.

C. Study Quality Assessment
Our research source is only the publications, which maintained high quality levels. So the initial basic quality is achieved from the initial stage itself. The papers which are selected by applying inclusion exclusion criteria is passed through some quality assessment questions shown in table VI.The quality criteria for the study is aggregated and shown in the quality assessment form. The objective is to assess the quality of the paper before data extraction. The papers which have satisfied the quality criteria are moved to the next section for collecting more detailed information extraction.

Item
Quality criteria 1 Does study report unambiguous and clear in terms of concepts? 2 Are the findings are based on evidence and arguments? 3 Is the paper well/appropriately referenced? 4 Number of participants? 5 Is Internal validity and external validity achieved? 6 Does the report is unbiased?

D. Data Extraction
After completing the study selection process, we extracted data from the selected papers using the data extraction form as Table VII. We recorded all the necessary information on each paper got from data extraction form to gather information on our review questions.

E. Data Synthesis
After the study selection and data extraction process, data synthesize is performed for collating and summarizing the selected study. According to Kitchenham [12,13], there are two main methods of data synthesis: Qualitative and Quantitative. We are using a mixed approach here for data synthesize. The extracted data were represented using quantitative methods and make use of this we did the qualitative synthesize to answer our questions.

1) Domain Analysis:
A key success of FOSD is to select a well defined, well focused and well scoped domain. Czarnecki K and, Eisenecker [14] defines domain as " An area of knowledge that is scoped to maximize the satisfaction of the requirements of its stakeholders, includes a set of concepts and terminology understood by practitioners in that area and includes the knowledge of how to build software systems in that area." Commonality and variability from a domain has to be identified and understood well for the development of reusable core assets for a software product line. Domain analysis is the requirements engineering phase for a feature oriented product line.
In FOSD, Domain scoping and feature modeling are the main processes of domain analysis. In domain scoping the description of desired features or specific product variations which the software product line should be supported is identified and recorded. Domain experts have to study and analyze the targeted domain and extract useful information from that domain for effective and efficient domain scoping. In domain modeling the captured information in the scoping process is modeled and documented in terms of commonality and variability. The feature groups such as mandatory, optional, alternative has to be identified and recorded carefully.
2) Domain design and specification: In this phase, from the documents of variability feature model using feature diagram is developed. A feature model represents and documented the features and their relationships in a software product line. Andreas Classen and co-scholars [15] defines "A Feature Diagram is a hierarchical diagram that visually depicts the features of a Domain in groups of increasing levels of detail". The great way to summarize the features of a domain in visual manner is by using feature trees.
Swen Apel [16] defines "A feature diagram is a graphical representation of a feature model as a tree over the feature set F. Each edge in the tree is defined by exactly one feature constraint, that is, by a declaration of one of the feature constraint types mandatory, optional, alternative, or or". The set of cross-tree constraints (requires, excludes) may also be defined additionally by make use of feature diagram. The corresponding propositional formula of a feature diagram can be generated by conjoining the feature constraints and the cross-tree constraints. This will represent the semantics of the whole feature model.

3) Domain Implementation:
In this phase, the identified and modeled features of the domain are implemented in the form of reusable artifacts. There are mainly two steps for domain implementation. Firstly, suitable implementation strategy has to be selected according to the domain. There are a lot of strategies are there, which may be language based (Framework, AOP, FOP, etc) or tool based ( build systems, Preprocessors, etc). Secondly, according to the strategy selected, prepare the design and code to hook implementations.

4) Product Configuration and generation:
It is the final phase of the FOSD. The main activities of this phase are Feature selection, Product derivation, Product validation and verification. The essential step of individual product customization in product line engineering is feature selection, in which the multiple features, that may exhibit competing and conflicting interaction, have to be considered in a well defined manner. Product derivation can do automatically and manually. In manual task, glue code is written by developers and thus the artifacts corresponding to the selected features is connected and the gaps are patched for the customized product derivation. Where as in automatic task a push down approach is used to derive the product, the stake holders select the features and a compositional engine is called to combine the corresponding artifacts into an executable software product. Product validation is needed for the customized product which is derived in either way by unit testing mechanisms.
In the area of FOSD, the researchers and practitioners were mostly concerned with Feature implementation, Refactoring of software product lines, Feature interactions, Analysis of software product line, and Tool support. Our aim is to classify and summarize the works and searching for finding the scope of future research work in FOSD.
From the current literature, it is clear that the existing frameworks for Feature Oriented Software Product Line development (FeatureIDE, pure::variants, BigLever) are automatic except for the processes of domain scoping and feature selection. Human involvement is necessary for those two phases. During Domain scoping, domain experts collect information about the targeted domain through requirement analysis techniques of software engineering. Feature selection is the process of selecting the required features from the set of features of the product line by the stake holder according to their requirement. So in both requirement analysis of domain and the human involvement is needed. The requirement engineering in large scale software development process can result in massive amounts of noisy and semi structured data that must be analyzed and distilled in order to extract useful requirements.

B. Results: RQ2
Our second review question is "Which will be the best approach for implementing variability in FOSD?" In order to deal with this question a number of terms have to be explored.
 What is variability?  What is the classification of implementation strategies?  What are the quality criteria for evaluating the implementation strategies? Variability is the ability to change or customize a system. Software product variants are quite similar, but typically differ in new or additional features. Improving variability in a system implies making it easier to do certain kinds of changes. The goals of FOSD, such as automated software derivation, efficiently facilitating reuse, and variation of features in a software product lines, can be achieved only by the systematic implementation of features. There are around 12 implementation strategies are studied and classified according to binding time, technology and representations used in those strategies.  [16] proposed six quality criteria for evaluating these 12 software product-line implementation techniques. Implementation strategies and the specific quality criteria is shown in table X.

C. Results: RQ3
Our third question deals with features and their interactions and corresponding problems. Features have to be interacted to achieve the requirement and predefined functionality of the software product, by exchanging information. This interaction helps to refine and utilize other feature behavior and thus accomplish a specific task by cooperation of the features. But when one feature influences the behavior of other features in an unintended way, it is call inadvertent feature interaction problem or simply feature interaction problem. These feature interaction problems have to be detected, managed and resolved to attain the specific goals of the interactions between the features.
An example of unintended feature interaction problem is between the call waiting and forwarding features of a telephony system [17]; when both features are activated simultaneously, the system will collapsed and reach in an unfavorable state while it receives a call on a busy line. Reisner et al. [18] reveals that higher order interactions of features are also exists in practice. In this more than two features are interacted and interconnected and thus it is difficult to find unfavorable conditions even though it is a rare case.
For solving feature interaction problem first we have to identify the feature interactions. Now in every product line engineering features are developed independently this will make identifying and detecting interactions among features is a challenging task. Proper and systematic requirement engineering in the domain analysis is the only solution to detect feature interactions [19,20]. Heymans [21] proposed "formal methods can be successfully applied on core models of software product line, but scale them to be able to analyze source code instead of requirements models or manually abstracted models remains an open problem in feature interaction detection." Apel et al. [16] defines " Optional feature problem is the mismatch between intended variability and the actual variability provided by the implementation, due to coordinate code. It occurs when two or more optional features interact and the presence of coordination code reduces the intended variability of the product line." The implementation strategies [16] are  Change in feature model: "Instead of a proper implementation, exclude problematic feature combinations from the feature model".
 Multiple Implementations: "To account for configurations with and without coordination code, features are implemented separately for each combination".  Moving Code: "Coordination code is moved to one of the interacting features or to a shared required feature".  Conditional Compilation: "Using a preprocessor, the coordination code annotated and only complied if both features are present".  Optional Weaving: "Coordination code is implemented as implicitly optional, using mechanisms inspired by aspect weaving".  Distinct module for coordination code: "A distinct module separates coordination code from feature code; the module is automatically included when both features are included". Apel et.al [16] compares these feature interaction strategies based on the quality criteria such as code quality, binary size and performance, variability, and implementation effort. We are not able to find a generally preferable strategy for feature interaction problem solving. The multiple implementation strategy is not a good idea. Depending on the need and domain characteristics the developer has to select one among the remaining. Optional weaving is an emerging technique for this purpose.

D. Results: RQ4
Our fourth question deals with refactoring techniques. Refactoring is an important activity in software development, maintenance, and evolution. Apel et al [16] says the origin of refactoring as " Refactoring are typically traced to the dissertation of Opdyke [22] and have been popularized by the seminal book of Fowler [23]. Fowler [23] defines refactoring as "Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure".
Refactoring technique is used to eliminate code smells and thus enhancing program comprehension. The well known code smells in software product line such as long methods, large classes, and duplicate codes can be eliminated by applying traditional Object Oriented refactoring techniques. Alves et al [24] extends the traditional refactoring techniques for feature oriented software product lines. In their technique they first focused on the changes to feature model and later the implementation artifacts. Lastly problem to solution space is also being considered for refactoring.
The main focus of product line refactoring is on FOSD paradigm. It may affect the feature model and domain artifacts of Feature oriented software product line. The different types of refactoring techniques proposed by different authors for FOSD is summarized and defined in Table XII.  [S26] variability enhancing refactoring "A product line refactoring that does not change the set of valid products and corresponding feature selections and preserves the observable behavior of all products. It may introduce additional products"  Extract feature Thum et al. [27] Product preserving refactoring "A product line refactoring that does not change the set of valid products and corresponding feature selections and preserves the observable behavior of all products. It may add and remove products outside the given set" The concept of feature refactoring and extraction is introduced by Liu et al [28],based on formal algebraic model to deal with interacting and overlapping features. The refactoring model developed by Kastner et el [29] deal with how the transformation between annotation abd composition based feature implementations take place, with the help of refactorings. Apel et al. [30] introduces pseudo commutatively , suggests a better refactoring is possible in AspectJ.
Kastner et al [31] reported the experience with feature extraction in Berkeley DB using AspectJ and granularity implications of feature implementations with Berkeley DB. Rosenmuller et al.
[32] refactored the C version of Berkeley DB using FeatureC++.

E. Results: RQ5
Our fifth review question is concerned with the requirement engineering process for application domain in order to identify the features and their relationships to satisfy the requirement of every stakeholders of that domain. The requirement engineering in software product line development has to deal with large volume of semi structured and unstructured data, so proper requirement engineering is needed to extract useful information from these noisy data. Human intensive tasks such as requirement elicitation, analysis and management are the base of feature extraction from the application domain of the software product line. Domain scoping and analysis plays a major role in feature extraction.
Like every other software development technique, requirement engineering is a manual task by analyzing the application domain is needed in FOSD paradigm too. In FOSD experts analyze the SRS document and derive the features corresponding to each requirement in the domain and find the relationship among them and represent them in a feature model. "A feature diagram is a graphical AND/OR hierarchy of features, captures structural or conceptual relationships among features". The feature diagram is a structured tree diagram based on specialization generalization concept. The mandatory", "optional", "alternative" and "or" feature groups can easily represented using feature models with tree structure in a way that nodes represent features and the arcs represent variability. To specify which feature is needed in a variant, the following rules in Table 13 are applied. If selecting a parent feature in a variant.  Queiroz et al.[37] propose a defect prediction model to identify defective features using machine learning techniques, aiming at improving the cost-effectiveness of QA activities for features in SPLs. If effective, feature defect predictions could (i) help developers to select (or prioritize) samples of features that are prone to defects and should be tested more thoroughly; (ii) increase the detection of defects scattered across implementation artifacts, as these will likely have a low impact on the prediction model if using traditional filebased prediction; and (iii) improve the actual QA (e.g., code reviews) when features are used for communicating and coordinating within and across teams.

A. Dimensions
In this study we found that almost every paper is published in ACM and IEEE. FOSD community is conducting a continuous attempt to empower FOSD in every year from 2009 to now. They are dealing with every aspects of FOSD. The major areas of FOSD research are  Programming language and tool support for FOSD  Domain engineering and/or application engineering  Software product lines and program families  Feature and variation modeling  Formal methods and theory for FOSD  Type systems and formal semantics of FOSD languages  Feature composition, interaction, and refactoring  Multi-dimensional separation of concerns and aspect-oriented software development  Generative programming and automatic programming  Design patterns, frameworks, and components  Model-driven development and service-oriented architecture  Variability-aware analysis (e.g., type checking, testing, data flow analysis, and verification)  Versioning, evolution, and maintenance  Components, services, and models  Variability-aware analysis  Feature interaction, modeling, composition, and refactoring  Versioning, evolution, and maintenance  Components, services, and models  Build systems and feature-to-code mappings  Program comprehension  Empirical studies of all these topics

B. Principal Findings
Our review is only focused on the review questions; we didn't research further to find the other dimensions of the research. Our first question deals with automation of software development using FOSD paradigm. It is found that information processing by humans is going only on feature analysis and extraction phase of domain engineering and feature selection phase of application engineering. Our second question deals with, various variability implementation techniques for implementing FOSD. The main focus of FOSD is commonality, variability and reuse. In our study we found 12 implementation techniques and their strength and weakness based on the quality criteria. Feature interaction and optional feature problem are the most concerned problems when dealing with features and their relationships. The techniques for solving these also considered and answered with third review question. The scope and use of refactoring in FOSD is also discussed in this review. Our final question deals with feature extraction from an application domain. We found that the future scope of research must deal with this area because it is still based on the contemporary requirement engineering process of software engineering and thus expert knowledge is needed.

C. Threats to Validity
We feel that our review study have the following threats to validity.

Construct validity
This is primarily related with obtaining the relevant information by defining the research scope. At this stage, the biggest challenge is to decide the inclusion and exclusion criteria for selecting the papers. To address this issue, we considered all the systematic review reports related to software engineering.

External validity
The findings of this review cannot be generalized because the results are based on a specific set of keywords and the research repositories that have been used for the data collection. Therefore, our results could be limited and cannot be applied to every organizational setup.

Results validity
Our results deal with only the review questions and the selected papers only. It provides the future research focus only on the selected area.

Internal validity
We only searched in online libraries and further snowballing is also performed.

Conclusion validity
Our study focused with review questions and to ensure the correctness of the extracted data, the protocol was developed to define the data extraction strategy and format.

V. CONCLUSION AND FUTURE WORK
In this paper we reported a systematic literature review in the field of FOSD. The purpose of this study is to find the state of the art on this software development paradigm. For this we designed a review protocol, which covers 63 papers selected from 118 available research papers on the topic. Our focus is to answer the review questions and thus cover the sub areas of FOSD. The first question deals with the automation achieved through different phases of FOSD. Although software development automation is the main aim of FOSD, we couldn't able to say it is fully automated now. Human interaction and expertise is needed in both domain and application engineering in the form of feature extraction requirement engineering and feature selection requirement engineering. Here it is clear that full automation is still an open problem for researchers of this area.
The second and third question deals with variability implementation and feature interaction problems respectively. Many techniques are available for these purposes even though there is no general preferable standard technique for that and each strategy is on an emerging stage. Feature oriented Programming is good but has little experience in practice only used as an academic tool. The developers can choose a strategy according to their expertise and domain. The fourth question deals with the uses of refactoring and feature in this field. Actually refactoring techniques of Object Oriented paradigm is extended to feature oriented software product line development for overcoming the pitfalls.
Based on our fifth question some practical difficulty of domain requirement engineering, feature extraction and modeling are also discussed. The sixth question is concerned with the effective use of feature defect prediction technique for the betterment of FOSD because it is based on features. As mentioned in each section, all areas of software development are not fully explored by the researchers yet. If someone approaching FOSD with a research focus the scope is very huge because it is an emerging technique. Each area reveals a research focus for the researchers. With proper research and development FOSD has the capability to change total concept of software engineering.
ACKNOWLEDGEMENT This Systematic Review is performed as an initiation to the Ph.D work on the topic FOSD. There is no funding source(s) involved in this research.