Estimate Method Calls in Android Apps

Estimate Method Calls in Android Apps Rita Francese, Carmine Gravino, Michele Risi, and Genoveffa Tortora Dipartimento di Informatica Universitá di Salerno Fisciano, Via Giovanni Paolo II, 132 {francese, gravino, mrisi, tortora}@unisa.it

ABSTRACT In this paper, we focus on the definition of estimators to predict method calls in Android apps. Estimation models are based on information from requirements specification documents (e.g., number of actors, number of use cases, and number of classes in the conceptual model). We have used a dataset containing information on 23 Android apps. After performing data-cleaning, we applied linear regression to build estimation models on 21 data points. Results suggest that measures gathered from requirements specification documents can be considered good predictors to estimate the number of internal calls (i.e., methods invoking other methods present in the app) and external calls (i.e., invocations to API) as well as their sum.

Keywords Android platform; empirical study; estimation models

1.

Giuseppe Scanniello Dipartimento di Matematica, Economia ed Informatica Universitá della Basilicata Viale dell’Ateneo, Macchia Romana [email protected]

considered the numbers of actors, use cases, and classes of the conceptual model of an app. After performing datacleaning, we applied a linear regression to build estimation models on the data of 21 apps and assessed the accuracy of the method invocation predictions through a comparison with the actual number of the method invocations.

2. 2.1

EMPIRICAL STUDY Definition

We have investigated the following research questions: RQ1. Can measures gathered from requirements specification documents be considered good predictors for the number of API calls? RQ2. Can measures gathered from requirements specification documents be considered good predictors for the number of internal method calls? RQ3. Can measures gathered from requirements specification documents be considered good predictors for the total number of method calls (API and internal)?

INTRODUCTION

In recent years, we are observing rapid evolution of mobile devices in terms of available hardware, operating systems, and features that mobile applications (simply apps, from here on) implement. This evolution has also the effect of increasing energy consumption of apps. This could be due to energy greedy hardware, bad programming practices, and/or particular API usage patterns. Regarding programming practices, V´ asquez et al. [5] observed on 55 mobile apps a relationships between method invocations and energy consumption in Android devices. In other words, method calls may affect energy consumption of mobile apps developed for Android-based devices. Method calls might also suggest opportunities to reuse source code. Indeed, the reuse by API calls also indicates opportunities to save time/money and the reuse of already tested code [2]. In this paper, we show estimators to predict the number of method calls (i.e., internal, external, and their sum) in apps for Android mobile devices. We used a dataset containing information on 23 apps. To perform early estimations, we Permission to make digital or hard copies of part or all of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for third-party components of this work must be honored. For all other uses, contact the owner/author(s).

ICSE ’16 May 16-17 2016, Austin, TX, USA c 2016 Copyright held by the owner/author(s).

ACM ISBN 978-1-4503-4178-3/16/05. . . $15.00 DOI: http://dx.doi.org/10.1145/2897073.2897113

2.2

Context

We conducted a study with 46 Bachelor students in Computer Science at the University of Salerno. These students were enrolled to a Mobile Application Development (MAD) course. The didactic experience is described in [4]. To document requirements elicitation and analysis of each app, the lecturer asked students to use the template by Bruegge and Dutoit [3]. Each mobile app had to exploit native device functionalities (e.g., GPS). Students were originally 57 and were arranged in 27 teams. Data for 4 teams have been discarded due to incompleteness issues (e.g., lack of conceptual models) in the RADs (Requirements Analysis Documents) the members of these teams produced. In the remaining 23 teams were 46 students in total. 2 teams were composed of 1 student, 19 were composed of 2 students, and 2 were composed of 3 students. To manage the project the teams had to use GitHub (github.com).

2.3

Planning and Variables

Our investigation used information from RADs for predicting the number of API and internal calls as well as their sum. In particular, size measures (dependent variables) from RADs (i.e., #functional requirements - FR, #use case actors - Act, #use cases - UC, #classes - Cla, and #sequence diagrams - SD) were correlated with measures summarizing the number of method calls. The considered dependent variables are: API, INTERNAL, and SUM. The variable API is computed as the number of API call in the source code of

Table 1: Spearman’s rho results Variable FR Act UC Cla SD

API statistic p-value 0.023 0.9 0.339 0.1 0.251 0.3 0.485 0.03 0.23 0.3

INTERNAL statistic p-value -0.119 0.6 0.011 1 0.051 0.8 0.534 0.01 -0.0723 0.8

SUM statistic p-value -0.017 0.9 0.192 0.4 0.312 0.2 0.573 0.007 0.188 0.4

Table 2: Linear regression results using Cla Dependent variable API INTERNAL SUM

R2 0.295 0.305 0.354

F 7.945 8.345 10.42

Sign. F (p-value) 0.011 0.009 < 0.001

an app. INTERNAL is the number of internal calls, while SUM is computed as the sum of both.

2.4

Data Analysis

Independent variables significantly correlated with dependent variable are employed to build an estimation model. We opted for a linear regression model. It has been widely used in the context of software prediction with appreciable results [1]. To evaluate the goodness of fit of a model, several indicators have been proposed. Among them, we exploited the square of the linear correlation coefficient (i.e., R2 , the higher the value, the better it is). We also considered the F value indicator and corresponding p-value (denoted by Sign. F). High and low values for these indicators denote a high degree of confidence for the prediction, respectively. As for the validation of a model, we performed a k-fold cross validation. In particular, we exploited a leave-one-out cross validation, where k = n and n is the dataset size. To assess accuracy, we compared estimated values (computed by applying our predictive models) with the actual values of dependent variables. The smaller the difference between predicted and actual values, the better a prediction model is.

3.

OUTCOMES

In Table 1, we summarize the results of the Spearman’s rho test on the dependent and independent variable. The results suggest that the only independent variable significantly correlated with the dependent variables is Cla. The statistic values range in between 0.485 and 0.573. The obtained p-values for API, INTERNAL, and SUM are 0.03, 0.01, and 0.007, respectively. According to these results, we have considered only Cla. It is worth mentioning that we applied Spearman’s rho test because of data were not normally distributed as the Shapiro test results suggested (i.e., p-values are always less than 0.02 for each variable). Before applying linear regression, we verified that needed assumptions were all verified. We also performed an analysis of outliers on the 21 observations in the dataset and one observation was removed from the dataset. The results of the linear regression analysis are summarized in Table 2. We can observe that the models built using Cla are characterized by a Sig. F value less than 0.05 for all the dependent variables. That is, the models resulted to be significant. However, the obtained R2 and F values are not so high. For each project in the dataset, we observed that predicted values are close to estimated ones and in a few cases we had over-estimations. That is, the number of estimated method calls is higher than the number of actual calls. Assuming that methods calls affect energy consumption of Android

Table 3: Correlation results: actual and predicted values Dependent variable statistic p-value API INTERNAL SUM

0.411 0.599 0.442

0.065 0.004 0.046

apps [5], this can be considered a minor issue since actual energy consumption will be inferior to the predicted one. The results of the Spearman’s rho test (see Table 3) suggest that predicted method calls are significantly correlated with actual method calls for INTERNAL and SUM. Corresponding p-values are less than 0.05. Thus, both the models based on INTERNAL and SUM were able to provide good estimates. We can then summarize our outcomes with respect to defined research questions as follows: RQ1. Measures from requirements specification documents can be considered good predictors for the number of API calls to methods that Android platform provides. This implies that this research question can be positively answered even if data analysis did not allow obtaining definitive results. RQ2. Measures from requirements specification documents can be considered good predictors for the number of calls to methods developers implemented, namely internal calls. Also, this research question can be positively answered even if caution is needed. RQ3. Measures from requirements specification documents can be considered good predictors for the sum of API and internal calls. Indeed, the predictions for this dependent variable are better than those obtained for internal method and API calls. We can then positively answer also RQ3.

4.

CONCLUSION AND FUTURE WORK

In this paper, we focus on the definition of estimators to predict method calls in mobile apps. The built estimation models are based on information from requirements specification documents (e.g., number of actors, number of use cases, and number of classes). The results of our dataanalysis suggest that gathered data can be considered good predictors to estimate the number of internal and API calls, as well as their sum. That is, our models can be used as early estimators in the software development process.

5.

REFERENCES

[1] V. R. Basili, L. C. Briand, and W. L. Melo. A Validation of Object-Oriented Design Metrics as Quality Indicators. IEEE Trans. on Soft. Eng., 22(10):751–761, 1996. [2] G. Bavota, M. L. V´ asquez, C. E. Bernal-C´ ardenas, M. Di Penta, R. Oliveto, and D. Poshyvanyk. The Impact of API Change- and Fault-Proneness on the User Ratings of Android Apps. IEEE Trans. on Softw. Eng., 41(4):384–407, 2015. [3] B. Bruegge and A. H. Dutoit. Object-Oriented Software Engineering: Using UML, Patterns and Java. Prentice-Hall, 2nd edition, 2003. [4] R. Francese, C. Gravino, M. Risi, G. Scanniello, and G. Tortora. Using Project-Based-Learning in a Mobile Application Development Course: An Experience Report. J. of Vis. Lang. and Comp., 31:196–205, 2015. [5] M. L. V´ asquez, G. Bavota, C. Bernal-C´ ardenas, R. Oliveto, M. D. Penta, and D. Poshyvanyk. Mining Energy-Greedy API Usage Patterns in Android Apps: An Empirical Study. In Proc. of Working Conf. on Mining Soft. Repositories, pages 2–11. ACM Press, 2014.