A Feature Based Methodology for Variable Requirements Reverse Engineering

In the past years, software reverse engineering dealt with source code understanding. Nowadays, it is levered to software requirements abstract level, supported by feature model notations, language independent, and simpler than the source code reading. The recent relevant approaches face the following insufficiencies: lack of a complete integrated methodology, adapted feature model, feature patterns recognition, and Graph based slicing. This work aims to provide some solutions to the above challenges through an integrated methodology. The following results are unique. Elementary and configuration features are specified in a uniform way by introducing semantics specific attributes. The reverse engineering supports feature pattern recognition and requirements feature model graph-based slicing. The slicing criteria are rich enough to allow answering questions of software requirements maintainers. A comparison of this proposed methodology, based on effective criteria, with the similar works, seems to be valuable and competitive: the enrichment of the feature model and feature pattern recognition were never approached and the proposed slicing technique is more general, effective, and practical.


Introduction
One of the main Software Product Lines (SPLs) purposes is to identify and to manage the variations between the whole products family requirements; these variants provide different functional and non functional requirements based on features [1].SPLs are defined as a family of systems that share a common set of core technical assets, with a preplanned extensions and variations to address the requirements of specific customers and market [2].Several methods have been used to manage and formalize the variability among products requirements.Feature Models (FM) are the most popular ones.Their major aspect is a graph representation that includes a group of defined features and relations between them [3,4,5].Management operations have been established for reverse engineering, merging, slicing, or refactoring feature models from a group of configurations [3].
One important process, that should be mentioned, in software engineering is reverse engineering [19,20].Certain authors have defined it as the process of analyzing a subject system to identify the system's constituents and creating representations in another form at higher levels of abstraction [6].These authors show how meta-models are frequently used, during source code based reverse engineering.Another research work dealt with the challenge of understanding and analyzing parts of software using a reverse engineering tool that clarifies the limitations of all past source code based reverse engineering [7].Software reverse engineering is mainly supported by patterns recognition, slicing, and shopping techniques.Different works presented pattern recognition in different domains [9,10].However, there is no works on feature pattern nor on feature pattern recognition in FM.Several works presented feature model slicing techniques and algorithms based on mathematical formula model [13,14].But, no one is based on feature graph model itself; which is a conceptual weakness.Software requirements are becoming a specialized engineering science [21,22].It is supported by engineering methodologies, methods, techniques, and tools.But, so far, it suffers of the lack of reverse engineering fundamentals.This is mainly due to the recent accreditation of the requirements engineering and to the non-formal nature of its large products number.Anyway, the requirements reverse engineering should help in requirements understanding by successive abstractions and meta models.This understandability is the kernel of any requirements evolution.The idea of featurebased requirements reverse engineering is similar to program reverse engineering [6,7].They differ only on used techniques.Feature model slicing is inspired from program slicing that is currently used in computer programming to avoid and eliminate all parts of the program that are not relevant to a current interest [11,12].
All of the research works on FM reverse engineering do not deal with (1) FM notations suitability to support reverse engineering tasks, (2) features patterns recognition, (3) graph-based slicing, and a methodology uniformly integrating the above activities [15,16,17].This work overcomes the above stated shortages.It unifies the definition of an elementary feature as well as the composed (configuration) one by enhancing the feature notation with its semantics.It introduces feature pattern recognition allowing the understanding of any requirement feature semantics, and the feature model graph-based slicing allowing the identification of (1) a sub feature model which might affect a given requirement feature (backward slice) or (2) a sub feature model which might be affected by a given requirement feature (forward slice).The proposed methodology integrates the above techniques.
A comparison of this work, based on effective criteria, with the similar works, seems to be valuable and competitive: the enrichment of the feature model and feature pattern recognition were never approached and the proposed slicing technique is more general, effective, and useful to requirements maintainer because it is based on graph notations.

A Methodology for Variable
Requirements Reverse Engineering

Supporting Example
The following example, which is a variable requirements FM of a software List (figure 1), will be used along with the proposed methodology.This feature model (ExFM) is an extension of the conventional one.It is composed of two sub models: Elementary Feature Model (EIFM), modeling elementary requirements features, and Evolution Feature Model (EVFM), modeling configurations requirements features (composed by selected elementary or configuration features).The EIFM of List software requirements consists of behaviors requirements, structures requirements, methods requirements, etc.Each feature exists in two variations: static or dynamic.The Requirements Evolution Feature Model (EVFM) of software List requirements deals with List configurations (evolution) aspects.

Feature Modelling
This section introduces a uniform definition of elementary and configuration (composed) feature [8].In the proposed methodology, these two FMs are unified in a unique simplified one.Below the definition of a uniform feature model using EBNF notation [18]: <FM> = "feature model" < FM name>";" < Feature> // no difference between ELFM and EVFM "End FM" < FM name> ";" Each feature, in the FM, is composed of attributes and relations: <Feature> = "feature" <feature name>";" F2 or F3: a feature F1 might be composed by feature F2, or by feature F3 or by both.Select: is a relation that determines which features will be selected.Default: is a relation that determines a standard feature to be selected in case where no feature has been explicitly selected.The constraint relations are defined by: <Constraint> = "constraints" <imply> | <exclude> | <reject> These constraints have the following semantics: A feature F1 implies a feature F2 if a software holding F1 must hold F2 too.
A feature F1 excludes a feature F2 if a software holding F1 must not hold F2.
A feature F1 is rejected if F1 is unwanted.The Included in relations have the following semantics: <Included in> = "included in" (<Features> ",")* Figure 2 represents a unified FM of software List (Figure 1) using the semantics introduced above.

Reverse Engineering
A FM is composed of elementary and configuration features.Each one of these features is an instance of a predefined pattern specifying its semantics and allowing its.
a Elementary feature pattern A pattern of an elementary feature is introduced as it follows: FPattern Elementary ( ) Variation: str, st-beh, sq-methods Decomposition: static_queue and (str and st-beh and st-methods) Constraint: static_queue exclude static-stack Included in: St-Queue} As side effect to static-list evolution, the Slicing Slice Static-list Forward AND, on the FM Figure 2, will identify the following Figures 4 (a, b, c) which might be selected, modified, deleted, etc.As side effect to static-list evolution, the Slicing Slice Static-list Forward OR static-queue, on the feature model Figure 2, will identify the following Figures 5 which might be selected, modified, deleted, etc.

Results Discussion
The implementation environment of this work methodology requires a strongly typed object-oriented programming language and graph abstract data type.A strong combination between the FM, the reverse engineering, and feature slicing model should be guaranteed.Adding, an extension to an existing Object-Oriented Programming Language might be required to handle the added concepts of Feature-based Reverse Engineering.
Relying on the previous study on feature-based modelling and Reverse Engineering techniques, a comparison between the proposed methodology (including its supporting mechanisms) with similar recent works is presented below.This comparison is based on the following criteria: (1) Methodology supporting FM reverse engineering, (2) FM adaptation, (3) Supporting pattern recognition, (4) Slicing technique, and (5) Supporting tools.The studied similar works do not satisfy the criteria 1, 2, and 3. Some ones satisfy the criteria 4 but a mathematical way and some others satisfy the criteria 5.However, the proposed methodology covers all the first four criteria, but not the 5 th .It satisfies the 4 th criteria in a graphical way, which better (than the mathematical one) for software requirements maintainers.

Conclusion
According to the previous works, the current approaches in FM Reverse Engineering encounter some insufficiencies, where the methodology is informal, not sufficiently adapted FM, no pattern for Feature Model and slicing technique are mathematically-based.This work consequently proposed a formal methodology, a uniform and adapted FM supporting reverse engineering concepts and algorithms, a feature pattern and pattern recognition algorithm and graph based slicing technique.
This work dealt only with feature-based requirements Reverse Engineering.Two feature patterns were introduced, the prospection of others feature patterns will be valuable.The slicing was limited to AND and OR relations, the study of others relations is important.What is about feature-based requirements reengineering modelling?and self-adaptation?The answers to these open questions will be challenging in this domain.

Figure 2 .
Figure 2. FM of software list.St-Queue is a configuration feature.The others are elementary ones.

Figure 4 .
Figure 4. (a, b, c): The result of Slice Static-list Forward AND.

Figure 5 .
Figure 5.The result of Slice Static-list Forward OR static-queue.