FAVE - Factor Analysis Based Approach for DetectingProduct Line Variability from Change HistoryKentaro Yoshimura∗,Fumio Narisawaand Koji HashimotoHitachi Research Laboratory, Hitachi, Ltd.(MD#244) 7-1-1 Omika, Hitachi,Ibaraki 319-1292, [email protected] KikunoGraduate School of Information Science andTechnology, Osaka University1-5 Yamadaoka, Suita, Osaka 565-0871, [email protected] paper describes a novel approach to detect variability in asoftware product line from its change history such that softwarechanges are converted to vectors and a factor analysis is applied. Toshow the applicability of our approach, we conducted experimentalapplications using a software repository of automotive engine con-trol software. As a result of the experiments, variability is detectedfrom the change history of products.Categories and Subject DescriptorsD.2.7 [Software Engineering]: Distribution, Maintenance, andEnhancement; D.2.13 [Software Engineering]: Reusable SoftwareGeneral TermsAlgorithms, Measurement, DesignKeywordsSoftware Product Lines, Variability, Factor Analysis, Change His-tory1. INTRODUCTIONNow, most control systems consist of embedded software be-cause of its flexibility and cost efficiency. For example, an automo-tive control system has millions of lines of code for a high-class ve-hicle that includes hybrid power-train control, stability control, andGPS. Recently, developing control software has become increas-ingly difficult because the software size and number of variationsare increasing dramatically. Software product line (SPL) engineer-ing has been proposed as a development method for software thathas variations. In the SPL engineering approach, software is de-veloped for a specific product and for a product line that includes∗Graduate School of Information Science and Technology, OsakaUniversityPermission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies arenot made or distributed for profit or commercial advantage and that copiesbear this notice and the full citation on the first page. To copy otherwise, torepublish, to post on servers or to redistribute to lists, requires prior specificpermission and/or a fee.MSR’08, May 10-11, 2008, Leipzig, Germany.Copyright 2008 ACM 978-1-60558-024-1/08/05 ...$5.00.variations of the products. For reusing software across the productline, variability that are differences of requirement between productvariations are analyzed. Then variants of the software component(e.g. a set of files) are implemented in order to satisfy specificationsof the requirements. Benefits of SPL engineering have been exten-sively discussed in the literature and have been widely recognizedby industry[1][2].Research in SPL engineering has mostly focused on the con-struction of product line infrastructures and activities based on re-quirements of future products: scoping, domain analysis, architec-ture creation, and variability management [3][4][5]. On the otherhand, existing products contain a lot of domain expertise and arereliable from an industry point of view. The commonality and vari-ability analysis for existing software is one of the most importantissues to define a future product line while reusing existing soft-ware.However, commonality and variability analysis of existing soft-ware is a block against migrating into SPL engineering. Relatedworks proposed methods for analyzing commonality and variabil-ity from a requirement point of view and connecting that to the im-plementation [6][7]. On the other hand, some industrial case stud-ies reported that commonality and variability analysis takes a longtime[8][9]. Requirements and implementations of existing soft-ware are enormous. Moreover, such requirement analysis stronglydepends on the expertise of the analysts and is time consuming.There is a need for analyzing the commonality and variability in anautomatic way.We have already developed a method for evaluating common-ality between two current products in a quantitative way [10]. Inthe proposed method, the commonality between products was de-tected, but we were unable to detect the variability across the vari-ations. The difference between products consists of variability andproduct-specific parts, and we could not separate them when ana-lyzing only two products.This paper proposes a novel method to detect variability acrossexisting software by analyzing the change history. The idea is in-spired by factor analysis. Factor analysis is a multivariable analysistechnique used to explain commonality among observed variablesin terms of fewer unobserved variables called "factors." The ob-served variables are modeled as linear combinations of the factorsplus "specific variables." We thus tried to apply the factor-analysistechnique to detect variability in existing products and call our ap-proach "FAVE: Factor Analysis based Variability Extraction."We apply the factor analysis for changes between the existingproducts and detect the commonality of the changes. Of course,software product line is not a set of the existing products, but a11set of variability of the product property, variation points in soft-ware architecture and variants of software components. From ourviewpoint, it is difficult for detecting variability and mapping fromvariability to variation point that is a set of software components.Because an actual product has many internal and invisible variabil-ity, and the mappings from the requirements to the software com-ponents is not one-to-one, but complex. Before we develop thevariants, we have to detect the variability and variation points.Existing products contain their variability. If we could extractthe variability from the existing products, it will be an useful in-formation for migrating the software product line because most ofthe existing variability will be valid also in future product line. Wefocus on the change history of software components that composethe products. When the selections of variability were different be-tween the products in the history, the implementation of the soft-ware components that relates the variability was also different. Amajor variability should occur several times and the relationship tothe software components could be detected as a significant changepattern in the history. The factor analysis extracts the change pat-tern as commonality of changes and a set of software