Reactive Variability Realization with Test-Driven Development and Refactoring Glauco Silva Neves Patrícia Vilain Informatics and Statistics Department - INE Informatics and Statistics Department - INE Federal University of Santa Catarina - UFSC Federal University of Santa Catarina - UFSC Florianópolis, Brazil Florianópolis, Brazil [email protected] [email protected] Abstract— Software product line is a practice that has proven its Despite its advantages, a SPL requires a high upfront and advantages since it can offer to a company the reduction of time long-term investment to design and to develop the core assets to market, the decrease of development costs, the increase of repository, hindering the SPL use in dynamic markets due to productivity and the improvement of the final product quality. the risk of unforeseen changes and the cost of developing However, this practice requires a high initial investment and artifacts that may no longer be reused. To overcome this offers long-term risks to dynamic markets where changes are difficulty, there is a proposal of combining agile software difficult to predict. One of these markets is the mobile application development practices with SPL, resulting in the Agile Product development, which presents a growing demand, with Line Engineering (APLE) [2]. smartphone and tablets having already surpassed sales of PCs and notebooks. Currently, proposals bring the advantages of One example of a dynamic market that has grown rapidly is software product line for dynamic markets through the use of the one of applications for mobile devices. Smartphones and agile software development practices, which is called Agile tablets have surpassed PC and laptop sales [3]. New and Product Line Engineering (APLE). This paper investigates the different devices are constantly released with different use of test-driven development (TDD) and refactoring techniques connection capacities, pixels densities, resolutions, screen for performing reactive variability in APLE. The variability sizes, sensors (accelerometer, barometer, gyroscope), GPS and mechanism chosen is the configuration file that allows achieving storage [4] besides using different operating systems such as more than one platform, an important problem in mobile iOS, Android, Windows Phone, and others. application development. In that manner, new products can be built as needed, without the high upfront investment, but with a Considering this scenario where changes are constant, code easier to maintain. APLE is an interesting proposal for mobile application companies that want to make use of SPL but do not want to Keywords- Software product line, test-driven development, suffer the disadvantages the traditional SPL development. refactoring, variability realization This article uses the APLE approach to define a process for developing reactive SPLs using agile practices. The SPL I. INTRODUCTION variability is carried out on demand using Test-Driven A Software Product Line (SPL) is a set of applications that Development (TDD) and refactoring practices. The variability share common artifacts addressing the need of a particular mechanism used is the configuration file. market segment. This practice has already proven the advantages of reducing the time to market, decreasing This paper is organized as follows. Section 2 describes SPL development costs, increasing productivity and improving the combined with agile software development. In section 3 the quality of applications [1]. There are two essential activities in proposed process is explained. Section 4 shows an example of the SPL development: domain engineering and application a mobile application that was developed by applying the engineering [1]. proposed process. Related work is discussed in section 5. Finally, section 6 presents some conclusions. In domain engineering an initial planning to identify the commonalities and variability points of the applications is done II. AGILE PRODUCT LINE ENGINEERING and the system architecture is defined. Moreover, the resources that will be reused in applications are produced and become There are several reasons for combining SPL practices with part of the core assets repository. Application engineering, in agile software development practices [2]. This combination can its turn, focuses on understanding the needs of each specific be applied when: application and then reusing the resources (e.g. architecture, 1. There is not much knowledge about the domain to perform code, tests) in the core assets repository through the activation domain engineering; of variability points and selection of components necessary to satisfy the requirements. 2. It is not possible to predict changes in product requirements; 100 3. There is a need to decrease the risk of developing artifacts When new requirements are variations of features that may not be reused, due to market modifications. previously added to the SPL, unit tests and code changes are applied to allow activating this new variability. Testing helps According to Silva [5], Scrum and Extreme Programming with making sure that the first application continues to behave (XP) are the most used agile methods in SPL development. properly. The new unit tests will drive the changes in the Some studies combine Scrum and XP due to the fact that the source code for the integration of variability points, which are nature of these methods has different focus. While Scrum then configured in the second application. focuses on project management, XP focuses on development practices. One of the most famous practices of XP is the Test- The main mechanism to activate the variability is the Driven Development (TDD). configuration file. In addition to centralize the settings for building applications, the configuration file also documents the TDD is a way of programming where the coding tasks are variations of each application. The file format chosen was the performed in small cycles according to the mantra JavaScript Object Notation (JSON) [7], because it is a Red/Green/Refactor [6]. In the red phase, a failed unit test is lightweight file format, easy to read and is commonly used to written, which may not even compile. In the green phase, code data-interchange. is modified in the simplest way just to pass the test. And in the last phase, refactor, the code is modified in order to improve The configuration file is created when features are added as and maintain the behavior. It is in the refactor phase that design variabilities to the features that already exist in the core assets decisions are made, one at a time. repository. This file has a key and a value to configure each feature. Along with this file a test class is created for testing the TDD also assists in preventing bugs and may serve as possible combinations of keys and values. It is also necessary documentation of the system. According to Beck [6], TDD can to create a class in the code to read the configuration file and to also aid the framework development because it focuses on what instantiate a configurator object, which will be used to inform is needed instead of attempting to accommodate different the application of what variability will be activated. The features at once. As new features arise, the code is tested and configuration file is modified as more variabilities are added to refactored, eliminating duplicated code. The common code is the SPL. Each application has its own configuration file, placed in separate from the specific code, facilitating the reuse activating and configuring variabilities as needed. of common code later. The proposed process can be described as follows: There are two main strategies for building a SPL: proactive and reactive [1]. The more traditional approach is proactive, 1. The first application is developed using TDD as if it were where scope, architecture, components, and other resources, are the only one, without attempting to predict future features defined in early stages, anticipating commonalities and and variations. specificities. In the reactive approach one or more applications 2. Tests related to the first application become part of the are developed at first, then the core assets are extracted from them. It is also possible an incremental approach, combining core asset artifacts. the ideas of both strategies at different times. 3. The features of the second application are gathered and In this work, we choose the reactive approach to be used in described by user stories, which is a usual technique to define requirements in agile methods. conjunction with agile practices because among its advantages is the lower cost for development, since the core assets 4. The features of the second application that are not related repository is not constructed upfront [1]. In this way, the risk of to existing features are developed with TDD. developing useless components is lower since there is no need to provide the variations of products in advance and the 5. The features of the second application that are variations knowledge about the domain can grow as applications are of existing features follow a slightly different path: developed. 5.1. Identify where the existing feature is tested. 5.2. Add new(s) test(s) to include the new expected III. A PROCESS FOR REACTIVE SPL DEVELOPMENT behavior and refactor the existing code to pass these The goal of this work is to define a process for developing a tests. reactive SPL. Such process applies TDD and refactoring agile practices to product conception and variability realization. 5.3. Refactor the existing code to use the configurator object that is modified. During this process, the first application is developed focusing only on satisfying its existing requirements. This 5.4. Add new tests to verify the behavior of the new development is test-driven and its results include the entries in the configurator object. application and a unit test suite that ensures its behavior. IV. EXAMPLE During the development of the second application, its requirements are either mapped to new features or the existing To illustrate the use of our proposed process, the features can be modified.