Reactive Variability Realization with Test-Driven Development and Refactoring

Transcription

1 Reactive Variability Realization with Test-Driven Development and Refactoring Glauco Silva Neves Informatics and Statistics Department - INE Federal University of Santa Catarina - UFSC Florianópolis, Brazil [email protected] Patrícia Vilain Informatics and Statistics Department - INE Federal University of Santa Catarina - UFSC Florianópolis, Brazil [email protected] Abstract Software product line is a practice that has proven its advantages since it can offer to a company the reduction of time to market, the decrease of development costs, the increase of productivity and the improvement of the final product quality. However, this practice requires a high initial investment and offers long-term risks to dynamic markets where changes are difficult to predict. One of these markets is the mobile application development, which presents a growing demand, with smartphone and tablets having already surpassed sales of PCs and notebooks. Currently, proposals bring the advantages of software product line for dynamic markets through the use of agile software development practices, which is called Agile Product Line Engineering (APLE). This paper investigates the use of test-driven development (TDD) and refactoring techniques for performing reactive variability in APLE. The variability mechanism chosen is the configuration file that allows achieving more than one platform, an important problem in mobile application development. In that manner, new products can be built as needed, without the high upfront investment, but with a code easier to maintain. Keywords- Software product line, test-driven development, refactoring, variability realization I. INTRODUCTION A Software Product Line (SPL) is a set of applications that share common artifacts addressing the need of a particular market segment. This practice has already proven the advantages of reducing the time to market, decreasing development costs, increasing productivity and improving the quality of applications [1]. There are two essential activities in the SPL development: domain engineering and application engineering [1]. In domain engineering an initial planning to identify the commonalities and variability points of the applications is done and the system architecture is defined. Moreover, the resources that will be reused in applications are produced and become part of the core assets repository. Application engineering, in its turn, focuses on understanding the needs of each specific application and then reusing the resources (e.g. architecture, code, tests) in the core assets repository through the activation of variability points and selection of components necessary to satisfy the requirements. Despite its advantages, a SPL requires a high upfront and long-term investment to design and to develop the core assets repository, hindering the SPL use in dynamic markets due to the risk of unforeseen changes and the cost of developing artifacts that may no longer be reused. To overcome this difficulty, there is a proposal of combining agile software development practices with SPL, resulting in the Agile Product Line Engineering (APLE) [2]. One example of a dynamic market that has grown rapidly is the one of applications for mobile devices. Smartphones and tablets have surpassed PC and laptop sales [3]. New and different devices are constantly released with different connection capacities, pixels densities, resolutions, screen sizes, sensors (accelerometer, barometer, gyroscope), GPS and storage [4] besides using different operating systems such as ios, Android, Windows Phone, and others. Considering this scenario where changes are constant, APLE is an interesting proposal for mobile application companies that want to make use of SPL but do not want to suffer the disadvantages the traditional SPL development. This article uses the APLE approach to define a process for developing reactive SPLs using agile practices. The SPL variability is carried out on demand using Test-Driven Development (TDD) and refactoring practices. The variability mechanism used is the configuration file. This paper is organized as follows. Section 2 describes SPL combined with agile software development. In section 3 the proposed process is explained. Section 4 shows an example of a mobile application that was developed by applying the proposed process. Related work is discussed in section 5. Finally, section 6 presents some conclusions. II. AGILE PRODUCT LINE ENGINEERING There are several reasons for combining SPL practices with agile software development practices [2]. This combination can be applied when: 1. There is not much knowledge about the domain to perform domain engineering; 2. It is not possible to predict changes in product requirements; 100

2 3. There is a need to decrease the risk of developing artifacts that may not be reused, due to market modifications. According to Silva [5], Scrum and Extreme Programming (XP) are the most used agile methods in SPL development. Some studies combine Scrum and XP due to the fact that the nature of these methods has different focus. While Scrum focuses on project management, XP focuses on development practices. One of the most famous practices of XP is the Test- Driven Development (TDD). TDD is a way of programming where the coding tasks are performed in small cycles according to the mantra Red/Green/Refactor [6]. In the red phase, a failed unit test is written, which may not even compile. In the green phase, code 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 and maintain the behavior. It is in the refactor phase that design decisions are made, one at a time. TDD also assists in preventing bugs and may serve as documentation of the system. According to Beck [6], TDD can also aid the framework development because it focuses on what is needed instead of attempting to accommodate different features at once. As new features arise, the code is tested and refactored, eliminating duplicated code. The common code is placed in separate from the specific code, facilitating the reuse of common code later. There are two main strategies for building a SPL: proactive and reactive [1]. The more traditional approach is proactive, where scope, architecture, components, and other resources, are defined in early stages, anticipating commonalities and specificities. In the reactive approach one or more applications are developed at first, then the core assets are extracted from them. It is also possible an incremental approach, combining the ideas of both strategies at different times. In this work, we choose the reactive approach to be used in conjunction with agile practices because among its advantages is the lower cost for development, since the core assets repository is not constructed upfront [1]. In this way, the risk of developing useless components is lower since there is no need to provide the variations of products in advance and the knowledge about the domain can grow as applications are developed. III. A PROCESS FOR REACTIVE SPL DEVELOPMENT The goal of this work is to define a process for developing a reactive SPL. Such process applies TDD and refactoring agile practices to product conception and variability realization. During this process, the first application is developed focusing only on satisfying its existing requirements. This development is test-driven and its results include the application and a unit test suite that ensures its behavior. During the development of the second application, its requirements are either mapped to new features or the existing features can be modified. In the case of new features, new unit tests and production code is developed through the red/green/refactor form and then added to the core assets repository. When new requirements are variations of features previously added to the SPL, unit tests and code changes are applied to allow activating this new variability. Testing helps with making sure that the first application continues to behave properly. The new unit tests will drive the changes in the source code for the integration of variability points, which are then configured in the second application. The main mechanism to activate the variability is the configuration file. In addition to centralize the settings for building applications, the configuration file also documents the variations of each application. The file format chosen was the JavaScript Object Notation (JSON) [7], because it is a lightweight file format, easy to read and is commonly used to data-interchange. The configuration file is created when features are added as variabilities to the features that already exist in the core assets 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 possible combinations of keys and values. It is also necessary to create a class in the code to read the configuration file and to instantiate a configurator object, which will be used to inform the application of what variability will be activated. The configuration file is modified as more variabilities are added to the SPL. Each application has its own configuration file, activating and configuring variabilities as needed. The proposed process can be described as follows: 1. The first application is developed using TDD as if it were the only one, without attempting to predict future features and variations. 2. Tests related to the first application become part of the core asset artifacts. 3. The features of the second application are gathered and described by user stories, which is a usual technique to define requirements in agile methods. 4. The features of the second application that are not related to existing features are developed with TDD. 5. The features of the second application that are variations of existing features follow a slightly different path: 5.1. Identify where the existing feature is tested Add new(s) test(s) to include the new expected behavior and refactor the existing code to pass these tests Refactor the existing code to use the configurator object that is modified Add new tests to verify the behavior of the new entries in the configurator object. IV. EXAMPLE To illustrate the use of our proposed process, the application developed in the book Test-Driven ios Development [8] was chosen as the first application of a reactive SPL. The choice of an existing application, which was test-driven developed, has been made to reduce the bias of 101

3 writing the first application. Moreover, this application was not 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 repository continues to support both applications. In the following, we initially describe the first application. Then we describe the second application and the modifications that were made to the core assets repository. 1.1 First Application The first application is an application for the ios operating system that provides to the user the latest questions of Stack Overflow 1 forum related to mobile development for ios. The 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. Describing such application in more detail, we obtain the following user stories: List of topics. The application starts showing a list of topics related to ios. Each topic is associated with a tag from Stack Overflow. Access the latest questions. When a topic is selected, another list appears showing the 20 latest questions that have a tag associated with the selected topic. This list is sorted in chronological order, from most recent to least recent. Each item of the list shows the title of the question, the user who made the question (name and image), and the score of the question (number of people who upvoted or downvoted the question). Connection availability. To load the list of recent questions, an internet connection is necessary, but it is possible that the connection to the stackoverflow.com site fails. In the latter case, the application must then inform the user that the information cannot be loaded, either for lacking an internet connection or communication failure with the site. Get answers to one question. When selecting a question, the application opens a screen showing the question description and a list of answers. If an answer was chosen as correct, it appears first. Otherwise, if no answer is chosen, the answers are listed according to the score they have. For each answer the name and avatar of the user who answered it are also shown. The user stories were transcribed to a feature model that shows which features were developed. The resulting feature model is shown in Figure 1. As the features come from the first application, all of them are mandatory. BrowseOverflow StackOverflow API Questions Availability V 1.1 Online Topic Listing questions Answer sorting Predefined Alternative Or 20 more recent Legend Optional Mandatory Order by upvote Figure 1. Feature model of the first application Besides the development of the first application has been test-driven, it was done incrementally following a layered architecture. The model layer was developed first, followed by the controller layer. Finally the integration between both layers was done. The source of the first application is open 2 and has 24 classes and 182 unit tests. 1.2 Second Application In the second application some new user stories were added, some user stories from the first application were modified and some user stories from the first application were maintained. The following user stories are either new ones or variations of the first application stories: Access the 30 most recent questions. When a topic is selected, the list appears showing the 30 most recent questions. Using the API 2.0. The API version used to request the questions and answers should be 2.0 instead of 1.1. Access content without internet connection. The content (questions and answers) that was displayed previously must be available to the user even if there is no internet connection. Insert new topics. On the topic screen, the user can add new topics in order to look for questions. 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 2 Available at 102

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

5 1. { 2. "limitofquestions": 30, 3. } Figure 7. Example of JSON configuration file Using the API 2.0 In the case of the API variation, the modification is more complex. In the first application, a facade [9] called StackOverflowManager is responsible for the communication with the class StackOverflowCommunicator (Figure 8). The requests to the API 1.1 are centralized in this communicator class. Now we need a class that tests the communicator that will be used independently of the API version. The tests guide the construction of an adapter [9] StackOverflowCommunicator. This adapter is responsible for calling the communicators with the API 1.1 (StackOverflowComunicatorV11, the old StackOverflowComunicator class of the first application) and with the API 2.0 (StackOverflowComunicatorV20) (Figure 9). This technique of extracting an adapter during refactoring was proposed by Kerievsky in [10]. However, other problems arise from the API change because the JSON format of the response from each API is different. Despite the PersonBuilder, QuestionBuilder and AnswerBuilder classes not knowing about the requests, they assume they will receive a JSON file with the same predefined fields. So, in this case the builder classes must receive the JSON file and also the mapping between this file and the object to be instantiated. Figure 8. Relationship between the facade and other classes [8] Figure 9. StackOverflowCommunicator new adapters Access Content Without Internet Connection The availability of the content even without internet connection leads to changes in many places, since the first application always notifies the user that a problem has occurred when there is no internet connection. The StackOverflowManager class also acts as a facade between the communicator and the builder [9] classes (PersonBuilder, QuestionBuilder and AnswerBuilder). The facade asks for the communicator to make a request to retrieve a JSON response from the Stack Overflow. When successful, the manager passes the JSON response to the builder classes. At this point, the JSON response must be saved by the application. When the request fails, the StackOverflowManager should verify if the JSON response was saved in memory before. After applying all the changes in the code, the configuration files for each application are defined as shown in Figures 10 and { 2. "limitofquestions": 20, 3. "stackoverflowapiversion": 1.1, 4. "userdefinedtopic": false, 5. "contentavailability": "online", 6. "answersorting": "upvote" 7. } Figure 10. Configuration file of the first application 1. { 2. "limitofquestions": 30, 3. "stackoverflowapiversion": 2, 4. "userdefinedtopic": true, 5. "contentavailability": "offline", 6. "answersorting": "date" 7. } Figure 11. Configuration file of the second application 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. 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 generate options. Then the variabilities are configured in a specific class of the code. Our work differs from Ghanam s work [11] because we explore more design patterns to generate variability. There are cases where the factory and decorator patterns are not enough or they are not the best option to insert variability. Furthermore, the solution presented in [11] is platform-dependent, whereas the configuration file of our work was designed to be used in other platforms too. 104

6 BrowseOverflow StackOverflow API Questions Availability V 1.1 V 2.0 Online Offline Topics Listing questions Answer sorting Legend First app features Variations Adapt from first version Alternative Optional Predefined User defined Predefined User defined Or Mandatory n more recent User defined Figure 12. Feature model of the second application developed Kakarontzas [12] proposed a systematic approach to create new quality and functional variant components through the customization of existing core assets of a SPL. This work also uses the TDD to assist with the evolution of SPL software components. It suggests the creation of a new component, which is an extension of a pure component, when new features are added. Thus, when a new functionality is needed, just a pure component or a component in the higher hierarchy has to be used. The component hierarchy presented in [12] increases the complexity. With a large hierarchy, it is more difficult to select alternative and requirements options to compose a new product. The configuration file we use in our work seems to be a simpler solution to centralize the variabilities choice as well as to serve as a guide for building a new application. VI. CONCLUSIONS Traditional SPLs have the disadvantages of high initial investment, the development of artifacts that may not be used, and the difficulty of dealing with unknown segments. The APLE arises to address these disadvantages using agile practices. This paper showed how TDD and refactoring agile practices could make a reactive SPL evolve and acquire variability points on demand. This is done through a defined process and the use of the configuration file as the variability mechanism. In our proposed process the first step is the development of an application using TDD, without considering the creation of other applications belonging to the same SPL. Then new features and variations of existing features are added in the form of user stories. To develop the features we create new variability points from new tests, and we also create the configuration file to activate the desired variability of each application. Then we implement the code necessary to pass all tests. The configuration file allows visualizing the application variability points in an easy way and centralizing the variability mechanisms in a unique place. It can also be used as a guide for the construction of a new SPL application. As future work we intend to apply the proposed process practices in a company of the mobile applications segment, addressing the cross platform development challenges. We will develop one ios application using the Objective-C language and another Android application using the Java language so that the variabilities are specified in the configuration file. REFERENCES [1] Clements, P., Northrop, L. A Framework for Software Product Line Practice, Version Pittsburgh, PA, USA: Software Engineering Institute, [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 , [3] Constantinou, A., Camilleri, E., Kapetanakis, M. Developer Economics 2012: The new mobile app economy. London: Visionmobile, [4] Milano, D. T. Android Application Testing Guide. Birmingham: Packt Publishing, [5] Silva, I. F., Neto, P. A. M. S., O'Leary, P., Almeida, E. S., Meira, S. R. L. Agile Software Product Lines: A Systematic Mapping Study. Software, Practice & Experience (Print), v. 41, p , [6] Beck, K. Test-Driven Development By Example [7] JSON. Introducing JSON [8] Lee, G. Test-Driven ios Development. Crawfordsville: Addison-Wesley, [9] Gamma E., Helm R., Johnson R., Vlissides J. Design patterns: elements of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, [10] Kerievsky, J. Refactoring to Patterns. Crawfordsville: Addison-Wesley Professional; 1 edition, [11] Ghanam, Y. An Agile Framework for Variability Management in Software Product Line Engineering. Doctor Thesis. Calgary, Alberta, Canada: University of Calgary, [12] Kakarontzas, G., Stamelos, I., Katsaros, P. Product line variability with elastic components and test-driven development. CIMCA 08: Proceedings of the 2008 International Conference on Computational Intelligence for Modeling Control and Automation. IEEE Computer Society: Washington, DC, U.S.A., 2008: