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— 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: 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 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 , 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. In the case of new features, new unit application developed in the book Test-Driven iOS tests and production code is developed through the Development [8] was chosen as the first application of a red/green/refactor form and then added to the core assets reactive SPL. The choice of an existing application, which was repository. test-driven developed, has been made to reduce the bias of

101 writing the first application. Moreover, this application was not BrowseOverflow developed following the SPL approach. This first application serves as a basis for the development of the second application, where new features and variabilities are inserted. The tests of the first application are refactored so that the core assets StackOverflow API Questions Availability repository continues to support both applications. In the following, we initially describe the first application. V 1.1 Online Then we describe the second application and the modifications that were made to the core assets repository.

1.1 First Application Topic Listing questions Answer sorting The first application is an application for the iOS operating system that provides to the user the latest questions of Stack 20 more Order by 1 Predefined Overflow forum related to mobile development for iOS. The recent upvote questions are organized by topics, and users can also view the answers that were given to these questions. The name of this application is BrowseOverflow. Legend Describing such application in more detail, we obtain the Alternative Optional following user stories: Or Mandatory

• List of topics. The application starts showing a list of Figure 1. Feature model of the first application topics related to iOS. Each topic is associated with a tag from Stack Overflow. Besides the development of the first application has been test-driven, it was done incrementally following a layered • Access the latest questions. When a topic is selected, architecture. The model layer was developed first, followed by another list appears showing the 20 latest questions that the controller layer. Finally the integration between both layers have a tag associated with the selected topic. This list is was done. The source of the first application is open2 and has sorted in chronological order, from most recent to least 24 classes and 182 unit tests. recent. Each item of the list shows the title of the question, the user who made the question (name and image), and the 1.2 Second Application score of the question (number of people who upvoted or In the second application some new user stories were downvoted the question). added, some user stories from the first application were modified and some user stories from the first application were • Connection availability. To load the list of recent questions, an internet connection is necessary, but it is maintained. possible that the connection to the stackoverflow.com site The following user stories are either new ones or variations fails. In the latter case, the application must then inform of the first application stories: the user that the information cannot be loaded, either for lacking an internet connection or communication failure • Access the 30 most recent questions. When a topic is with the site. selected, the list appears showing the 30 most recent questions. • Get answers to one question. When selecting a question, the application opens a screen showing the question • Using the API 2.0. The API version used to request the description and a list of answers. If an answer was chosen questions and answers should be 2.0 instead of 1.1. as correct, it appears first. Otherwise, if no answer is • Access content without internet connection. The content chosen, the answers are listed according to the score they (questions and answers) that was displayed previously have. For each answer the name and avatar of the user who must be available to the user even if there is no internet answered it are also shown. connection. The user stories were transcribed to a feature model that • Insert new topics. On the topic screen, the user can add shows which features were developed. The resulting feature new topics in order to look for questions. model is shown in Figure 1. As the features come from the first application, all of them are mandatory. • Order the answers chronologically. A list of answers to a question must be chronologically ordered, showing the most recent answers first. To exemplify the development of the SPL and its unit tests, the development of the first three user stories listed above is discussed next.

1 Available at http://stackoverflow.com 2 Available at https://github.com/iamleeg/BrowseOverflow

102 1.2.1 Access the 30 Most Recent Questions 1. @synthesize limit; The steps required to develop the user story that changes 2. the amount of questions from 20 to 30 are detailed as follows. 3. - (id)initWithName:(NSString *)newName 4. tag:(NSString *)newTag First of all, we need to find where this feature is tested 5. limit:(int)newLimit inside the unit tests of the first application. In the proposed 6. { model for the first application, each topic contains between 0 7. if ((self = [super init])) { and 20 questions. The class diagram corresponding to this user 8. name = [newName copy]; story, presented in [8], is shown in Figure 2. 9. tag = [newTag copy]; 10. limit = newLimit; 11. questions = [[NSArray alloc] init]; 12. } 13. return self; 14. } Figure 2. Relationship between Topic and Question in the first application In the class responsible for testing topics (TopicTests) is the Figure 5. New class field and change in the constructor signature method testLimitOfTwentyQuestions (Figure 3). This method 1. - (void)addQuestion:(Question *)question ensures that the modifications made to accept the new value 2. { will not affect the behavior of first application. 3. NSArray *newQuestions = 4. [questions arrayByAddingObject: question]; 1. - (void)testLimitOfTwentyQuestions 5. if ([newQuestions count] > 20) { 2. { 6. newQuestions = 3. Question *q1 = [[Question alloc] init]; 7. [self sortQuestionsLatestFirst: 4. for (NSInteger i = 0; i < 25; i++) { 8. newQuestions]; 5. [topic addQuestion: q1]; 9. newQuestions = 6. } 10. [newQuestions subarrayWithRange: 7. XCTAssertTrue( 11. (NSMakeRange(0, 20)]; 8. [[topic recentQuestions] count] < 21); 12. } 9. } 13. questions = newQuestions; 14. } Figure 3. First application test limit of twenty questions method Since the first application had a limit of 20 questions and 1. - (void)addQuestion:(Question *)question the second application extends this limit to 30 questions, this 2. { feature has to be modified. We can generalize the limit of 3. NSArray *newQuestions = questions to n, where n is defined in the configuration file 4. [questions arrayByAddingObject: question]; responsible for building each application. 5. if ([newQuestions count] > limit) { 6. newQuestions = Thus, a new method, called testLimitOfQuestions (Figure 7. [self sortQuestionsLatestFirst: 4), is created to test the limit of questions that must be defined 8. newQuestions]; at compile time. A new field is created in Topic class to store 9. newQuestions = this value and the signature of the constructor is refactored to 10. [newQuestions subarrayWithRange: accept a new limit parameter (Figure 5). These changes 11. (NSMakeRange(0, limit)]; resulted in changes elsewhere. The method setUp in the 12. } TopicTests class needed to be refactored to use the new 13. questions = newQuestions; constructor. The method addQuestions, that previously stored 14. } the number 20 directly in code, now uses the limit defined for the application (Figure 6). After having passed all tests, we Figure 6. Changes in the method addQuestions (before and after) found out that the test testLimitOfTwentyQuestions was no Since this was the first feature modified in the SPL features longer necessary, and then it was removed. model, it was necessary to create the test class responsible for testing the class that will read the configuration file and 1. - (void)testLimitOfQuestions instantiate the configurator object. The configurator object is 2. { accessed by the system to enable the variability points. 3. Question *q1 = [[Question alloc] init]; 4. for (NSInteger i = 0; i < topic.limit; i++) { The necessary information to instantiate the configurator 5. [topic addQuestion: q1]; object comes from the configuration file, a JSON file that is 6. } created for each application. A JSON file to configurate the 7. XCTAssertTrue( number of question is shown in Figure 7. For each variability 8. [[topic recentQuestions] count] < topic.limit); point of the SPL there is a descriptive key in the configuration 9. } file and that key references a value that has the settings required to activate that point. Figure 4. Added method testLimitOfQuestions

103 1. { (PersonBuilder, QuestionBuilder and AnswerBuilder). The 2. "limitOfQuestions": 30, facade asks for the communicator to make a request to retrieve 3. } a JSON response from the Stack Overflow. When successful, the manager passes the JSON response to the builder classes. Figure 7. Example of JSON configuration file At this point, the JSON response must be saved by the application. When the request fails, the StackOverflowManager 1.2.2 Using the API 2.0 should verify if the JSON response was saved in memory In the case of the API variation, the modification is more before. complex. In the first application, a facade [9] called After applying all the changes in the code, the configuration StackOverflowManager is responsible for the communication files for each application are defined as shown in Figures 10 with the class StackOverflowCommunicator (Figure 8). The and 11. requests to the API 1.1 are centralized in this communicator class. 1. { Now we need a class that tests the communicator that will 2. "limitOfQuestions": 20, be used independently of the API version. The tests guide the 3. "stackOverflowApiVersion": 1.1, construction of an adapter [9] StackOverflowCommunicator. 4. "userDefinedTopic": false, This adapter is responsible for calling the communicators with 5. "contentAvailability": "online", the API 1.1 (StackOverflowComunicatorV11, the old 6. "answerSorting": "upvote" 7. } StackOverflowComunicator class of the first application) and with the API 2.0 (StackOverflowComunicatorV20) (Figure 9). Figure 10. Configuration file of the first application This technique of extracting an adapter during refactoring was proposed by Kerievsky in [10]. 1. { However, other problems arise from the API change 2. "limitOfQuestions": 30, because the JSON format of the response from each API is 3. "stackOverflowApiVersion": 2, 4. "userDefinedTopic": true, different. Despite the PersonBuilder, QuestionBuilder and 5. "contentAvailability": "offline", AnswerBuilder classes not knowing about the requests, they 6. "answerSorting": "date" assume they will receive a JSON file with the same predefined 7. } fields. So, in this case the builder classes must receive the JSON file and also the mapping between this file and the object Figure 11. Configuration file of the second application to be instantiated. As a JSON file does not support comments, we need other support file to document the possible values for each key. At the end of the development of the second application, the feature model evolves including features that are mandatory, optional or mutually exclusive alternatives, as shown in Figure 12. It is important to point out that, in the case of the feature related to the quantity of questions we now have a more generic feature, and in the case of the features related to the API version and content availability we now have alternatives. Figure 8. Relationship between the facade and other classes [8]

V. RELATED WORK Ghanam [11] proposed the use of a test-driven approach to introduce variability through the refactoring of the existing code. Tests can guide the insertion of new forms of system variability as required. He proposed the use of the factory pattern [9] in the refactoring process in order to generate new feature alternatives and the use of the decorator pattern [9] to Figure 9. StackOverflowCommunicator new adapters generate options. Then the variabilities are configured in a specific class of the code. 1.2.3 Access Content Without Internet Connection Our work differs from Ghanam’s work [11] because we The availability of the content even without internet explore more design patterns to generate variability. There are connection leads to changes in many places, since the first cases where the factory and decorator patterns are not enough application always notifies the user that a problem has occurred or they are not the best option to insert variability. Furthermore, when there is no internet connection. the solution presented in [11] is platform-dependent, whereas The StackOverflowManager class also acts as a facade the configuration file of our work was designed to be used in between the communicator and the builder [9] classes other platforms too.

104 BrowseOverflow

StackOverflow API Questions Availability

Legend V 1.1 V 2.0 Online Offline

First app features Variations Topics Listing questions Answer sorting Adapt from first version

Alternative Optional

Or Mandatory Predefined User defined Predefined User defined

n more User defined recent Figure 12. Feature model of the second application developed

Kakarontzas [12] proposed a systematic approach to create mechanisms in a unique place. It can also be used as a guide for new quality and functional variant components through the the construction of a new SPL application. customization of existing core assets of a SPL. This work also uses the TDD to assist with the evolution of SPL software As future work we intend to apply the proposed process practices in a company of the mobile applications segment, components. It suggests the creation of a new component, which is an extension of a pure component, when new features addressing the cross platform development challenges. We will develop one iOS application using the Objective-C language are added. Thus, when a new functionality is needed, just a pure component or a component in the higher hierarchy has to and another Android application using the Java language so that the variabilities are specified in the configuration file. be used.

The component hierarchy presented in [12] increases the REFERENCES complexity. With a large hierarchy, it is more difficult to select [1] Clements, P., Northrop, L. A Framework for Software Product Line alternative and requirements options to compose a new Practice, Version 5.0. product. The configuration file we use in our work seems to be http://www.sei.cmu.edu/productlines/frame_report/index.html, a simpler solution to centralize the variabilities choice as well Pittsburgh, PA, USA: Institute, 2012. as to serve as a guide for building a new application. [2] Dfaz, J., Perez, J., Alarcón, P. P., Garbajosa, J. Agile Product Line Engineering - A Systematic Literature Review. Software, Practice & Experience (Print), v. 41, p. 921-941, 2011. VI. CONCLUSIONS [3] Constantinou, A., Camilleri, E., Kapetanakis, M. Developer Economics Traditional SPLs have the disadvantages of high initial 2012: The new mobile app economy. London: Visionmobile, 2012. investment, the development of artifacts that may not be used, [4] Milano, D. T. Android Application Testing Guide. Birmingham: Packt and the difficulty of dealing with unknown segments. The Publishing, 2011. APLE arises to address these disadvantages using agile [5] Silva, I. F., Neto, P. A. M. S., O'Leary, P., Almeida, E. S., Meira, S. R. practices. L. Agile Software Product Lines: A Systematic Mapping Study. Software, Practice & Experience (Print), v. 41, p. 899-920, 2011. This paper showed how TDD and refactoring agile [6] Beck, K. Test-Driven Development By Example. 2002. practices could make a reactive SPL evolve and acquire [7] JSON. Introducing JSON. http://www.json.org/. 2013. variability points on demand. This is done through a defined [8] Lee, G. Test-Driven iOS Development. Crawfordsville: Addison-Wesley, process and the use of the configuration file as the variability 2012. mechanism. [9] Gamma E., Helm R., Johnson R., Vlissides J. Design patterns: elements of reusable object-oriented software. Addison-Wesley Longman In our proposed process the first step is the development of Publishing Co., Inc., Boston, MA, 1995. an application using TDD, without considering the creation of [10] Kerievsky, J. Refactoring to Patterns. Crawfordsville: Addison-Wesley other applications belonging to the same SPL. Then new Professional; 1 edition, 2004. features and variations of existing features are added in the [11] Ghanam, Y. An Agile Framework for Variability Management in form of user stories. To develop the features we create new Software Product Line Engineering. Doctor Thesis. Calgary, Alberta, variability points from new tests, and we also create the Canada: University of Calgary, 2012. configuration file to activate the desired variability of each [12] Kakarontzas, G., Stamelos, I., Katsaros, P. Product line variability with elastic components and test-driven development. CIMCA ’08: application. Then we implement the code necessary to pass all Proceedings of the 2008 International Conference on Computational tests. The configuration file allows visualizing the application Intelligence for Modeling Control and Automation. IEEE Computer variability points in an easy way and centralizing the variability Society: Washington, DC, U.S.A., 2008: 146–15.

105