We have implemented our proposals in JAVA. The implementation architecture consists of two layers:
feature locationlayer andfeature location applicationslayer (see FigureA.1). The top layer receives three inputs concerning product variants: product configurations, source codeandfeature descrip-tions. This layer aims to locate feature implementations in a collection of product variants. Under the feature location layer is the feature location applications layer. This layer is a group of two sub-systems called respectively: feature-level CIAand SPLA. Feature-level CIA receives change request and feature implementations, and returns a ranked list of affected features. SPLA receives feature descriptions, product configurations and feature implementations, and returns mandatory compo-nents and variation points of compocompo-nents. Below, we detail each layer as a separated architecture.
Each architecture is a set of components withrequiredandprovidedinterfaces.
141
142 Appendix A. Implementation Architecture of Proposed Approaches
Figure A.1 : Layered Implementation Architecture.
A.1 Implementation Architecture of our Feature Location Approach
FigureA.2shows the implementation architecture of feature location approach as a set of compo-nents. Below, we detail these components according to the order of their use in the feature location process:
• FCA. This component implements Formal Concept Analysis (FCA) technique. It provides GSH corresponding to the given formal context. In our work, this component deals with different formal contexts: product configurations, cosine similarity matrix, structural dependency ma-trix and combination of cosine similarity and structural dependency matrices. The usage of GSH corresponds to these contexts as follows:
– Analysis variability distribution in terms of features across product variants. For this ser-vice, FCA component requires product configurations and provides the corresponding GSHMinimal Disjoint Sets of Features and Classes Findercomponent.
– Clustering similar classes together. For this service, FCA component requires the men-tioned above matrices to provide the corresponding GSH toCode-Topics Generator com-ponent.
Most of the existing tools implementing FCA are referenced from the web page of Uta Priss1.
1http://www.upriss.org.uk/fca/fca.html
A.1. Implementation Architecture of our Feature Location Approach 143
Figure A.2 : Feature Location Implementation Architecture.
For this work, we used the eclipse eRCA2.
• Minimal Disjoint Sets of Features and Classes Finder. This component is responsible for re-ducing IR search spaces (feature and source code) into minimal disjoint sets of features (resp.
source code classes). It requires feature descriptions, source code of product variants in XML format and GSH generated by FCA. It provides minimal disjoint sets of features and classes.
• ASTParser. This component is responsible for obtaining all source code information: names of packages, classes, methods, attributes, local variables, method invocation. Also, it is used to ob-tain structural dependency information, such as inheritance relation, attributes access, method invocation. It saves all this information in XML formate. It requires source code of all product variants and provides source code information in XML format for each variant separately. We used Java parserJDT/ASTto parse source code of a given collection of product variants. Also, we usedJDOMparser to save source code information in XML format.
• VSM. This component is responsible for computing textual similarity of a given set of classes.
It requires a minimal disjoint set of classes. The textual information related to these classes is obtained by callingASTParsercomponent. Then, VSM creates a document for each class containing its textual information. The collection of class documents represents the corpus
2https://code.google.com/p/erca/
144 Appendix A. Implementation Architecture of Proposed Approaches
and query documents. We used theTD/IDFformula to assign a weight for each term extracted from class documents. VSM component provides a similarity matrix of these given classes. I have implemented VSM according to the description mentioned in the preliminaries chapter3.
• Structural Dependency Detector. This component is responsible for determining structural dependencies of a given set of classes. It requires a minimal disjoint set of classes. Also, this component builds a data structure to save source code of a given a collection of product vari-ants. This data structure is explored to determine structural dependencies among a given min-imal disjoint set of classes. This component provides a structural dependency matrix of these given classes.
• AHC. The role of this component is to group similar classes of a given minimal disjoint set of classes into clusters according to agglomerative hierarchical clustering principles. It invokes the VSM components to compute textual similarity, initially among class documents, then be-tween class documents and cluster documents during the clustering process and among only cluster documents. This component provides a set of clusters. Each cluster can be a candidate code-topic.
• Code-Topics Generator. This component is responsible for identifying code-topics from each minimal disjoint set of classes. It requires FCA and Agglomerative Hierarchical Clustering (AHC) components to cluster similar classes together. It provides a set of code-topics that can be derived from a given minimal disjoint set of classes.
• LSI. The role of this component is to compute textual similarity between feature descriptions and code-topics information. It requires both minimal disjoint sets of features and code-topics derived from the minimal disjoint set of classes. To create LSI’s corpus, a document is created for each code-topic containing the source code information for that code-topic. Also to cre-ate query documents, a document is crecre-ated for each feature containing the feature descrip-tion. TheTD/IDFformula is used to assign a weight for each term extracted from corpus and query documents. We used an external library to implement SVD technique calledJAMA4. Co-sine similarity equation is used to measure textual similarity between corpus and query docu-ments. After linking features to their corresponding code-topics, this component also decom-poses each code-topic into its classes. This component provides the implementation of each feature as a set of classes. I have implemented LSI according to the description mentioned in the preliminaries chapter5.
TableA.1presents statistical source code information of the the feature location approach in terms of number of packages (NOP), number of classes (NOC) and number of line of codes (LOC).
3https://code.google.com/p/tool-vsm 4http://math.nist.gov/javanumerics/jama/
5https://code.google.com/p/tool-lsi
A.2. Implementation Architecture of our Feature-Level CIA Approach 145
Table A.1 : Statistical source code information of feature location approach.
Approach NOP NOC LOC
Feature Location with IR 21 61 5,221
A.2 Implementation Architecture of our Feature-Level CIA Approach
FigureA.3shows the implementation architecture of feature-level CIA approach as a set of compo-nents. Below, we detail these components according to the order of their use in the feature-level CIA process.
• Affected Classes Finder. This component is responsible for determining impact set of classes for a given change set of classes. In this component, we build data structure to save source code of obtained features from product variants. This data structure contains packages, classes of these features. We explore this data structure to find classes that are coupled to the change set according to predefined coupling relations (see section6.3). We parse the source code of features using JDT/AST. This is performed by building a Java project containing source code of all features. This component provides the impact set of classes.
• FCA. The role of this component is to generate a GSH corresponding to formal context that rep-resents the feature-to-code traceability matrix. This component is the same FCA component presented in the architecture of feature location process. We again presented it because it is shared between these architectures.
• Affected Features Finder. The role of this component is to determine a ranked list of affected features. It requires the GSH generated by theFCAcomponent and impact set of classes ob-tained byAffected Classes Generatorcomponent. In this component, we query the GSH by the impact set of classes according to algorithms proposed in section6.5. It provides a ranked list of affected features as a final output.
TableA.2presents statistical source code information of the feature level CIA approach in terms of number of packages (NOP), number of classes (NOC) and number of line of codes (LOC).
Table A.2 : Statistical source code information of feature-level CIA approach.
Approach NOP NOC LOC
Feature-Level CIA 7 25 2,223
146 Appendix A. Implementation Architecture of Proposed Approaches
Figure A.3 : Feature-Level CIA Implementation Architecture.
A.3 Implementation Architecture of our SPLA reverse-engineering approach
FigureA.4shows the implementation architecture of SPLA approach as a set of components. We detail these components according to the order of their uses.
• Feature-Level Commonality & Variability Analyzer. This component is responsible for deter-mining mandatory features (commonality) and variation points (VPs) of features (variability) across product variants. It requires product configurations and feature descriptions. In this component, we implement the algorithms proposed in section7.3. It provides mandatory fea-tures, AND-Groups, XOR-Groups, OR-Groups and OP-Groups of features.
• Feature Group Implementation Finder. The role of this component is to determine the plementation of feature groups (i.e., VPs and mandatory features). It requires all feature im-plementations. This implementation consists of all source code classes corresponding to each feature.
and provides feature group implementations.
• ROMANTIC. This component is responsible for extracting components from the implementa-tion of feature groups. It requires a feature group implementaimplementa-tion and provides a set of compo-nents. We dedicated the AppendixCto detail how ROMANTIC works.
• Architectural-Level Commonality & Variability Analyzer. The role of this component is to de-termine mandatory components and VPs of components. It requires components extracted
A.3. Implementation Architecture of our SPLA reverse-engineering approach 147
Figure A.4 : SPLA Implementation Architecture.
Table A.3 : Statistical source code information of Reverse Engineering SPLA Approach.
Products NOP NOC LOC
Reverse Engineering SPLA 20 56 5,269
using the ROMANTIC. In this component, we link each feature to the corresponding compo-nent(s). We also conduct textual matching between component names for all features of each VP to find parent components. This component provides mandatory components and VPs of components.
TableA.3presents statistical source code information of the reverse engineering SPLA approach in terms of number of packages (NOP), number of classes (NOC) and number of line of codes (LOC).