Predicting the Impact of Batch Refactoring Code Smells on Application Resource Consumption

Automated batch refactoring has become a de-facto mechanism to restructure software that may have significant design flaws negatively impacting the code quality and maintainability. Although automated batch refactoring techniques are known to significantly improve overall software quality and maintainability, their impact on resource utilization is not well studied. This paper aims to bridge the gap between batch refactoring code smells and consumption of resources. It determines the relationship between software code smell batch refactoring, and resource consumption. Next, it aims to design algorithms to predict the impact of code smell refactoring on resource consumption. This paper investigates 16 code smell types and their joint effect on resource utilization for 31 open source applications. It provides a detailed empirical analysis of the change in application CPU and memory utilization after refactoring specific code smells in isolation and in batches. This analysis is then used to train regression algorithms to predict the impact of batch refactoring on CPU and memory utilization before making any refactoring decisions. Experimental results also show that our ANN-based regression model provides highly accurate predictions for the impact of batch refactoring on resource consumption. It allows the software developers to intelligently decide which code smells they should refactor jointly to achieve high code quality and maintainability without increasing the application resource utilization. This paper responds to the important and urgent need of software engineers across a broad range of software applications, who are looking to refactor code smells and at the same time improve resource consumption. Finally, it brings forward the concept of resource aware code smell refactoring to the most crucial software applications

Rohelisema tarkvaratehnoloogia poole tarkvaraanalüüsi abil

Mobiilirakendused, mis ei tühjenda akut, saavad tavaliselt head kasutajahinnangud. Mobiilirakenduste energiatõhusaks muutmiseks on avaldatud mitmeid refaktoreerimis- suuniseid ja tööriistu, mis aitavad rakenduse koodi optimeerida. Neid suuniseid ei saa aga seoses energiatõhususega üldistada, sest kõigi kontekstide kohta ei ole piisavalt energiaga seotud andmeid. Olemasolevad energiatõhususe parandamise tööriistad/profiilid on enamasti prototüübid, mis kohalduvad ainult väikese alamhulga energiaga seotud probleemide suhtes. Lisaks käsitlevad olemasolevad suunised ja tööriistad energiaprobleeme peamiselt a posteriori ehk tagantjärele, kui need on juba lähtekoodi sees. Android rakenduse koodi saab põhijoontes jagada kaheks osaks: kohandatud kood ja korduvkasutatav kood. Kohandatud kood on igal rakendusel ainulaadne. Korduvkasutatav kood hõlmab kolmandate poolte teeke, mis on rakendustesse lisatud arendusprotessi kiirendamiseks. Alustuseks hindame mitmete lähtekoodi halbade lõhnade refaktoreerimiste energiatarbimist Androidi rakendustes. Seejärel teeme empiirilise uuringu Androidi rakendustes kasutatavate kolmandate osapoolte võrguteekide energiamõju kohta. Pakume üldisi kontekstilisi suuniseid, mida võiks rakenduste arendamisel kasutada. Lisaks teeme süstemaatilise kirjanduse ülevaate, et teha kindlaks ja uurida nüüdisaegseid tugitööriistu, mis on rohelise Androidi arendamiseks saadaval. Selle uuringu ja varem läbi viidud katsete põhjal toome esile riistvarapõhiste energiamõõtmiste jäädvustamise ja taasesitamise probleemid. Arendame tugitööriista ARENA, mis võib aidata koguda energiaandmeid ja analüüsida Androidi rakenduste energiatarbimist. Viimasena töötame välja tugitööriista REHAB, et soovitada arendajatele energiatõhusaid kolmanda osapoole võrguteekeMobile apps that do not drain the battery usually get good user ratings. To make mobile apps energy efficient many refactoring guidelines and tools are published that help optimize the app code. However, these guidelines cannot be generalized w.r.t energy efficiency, as there is not enough energy-related data for every context. Existing energy enhancement tools/profilers are mostly prototypes applicable to only a small subset of energy-related problems. In addition, the existing guidelines and tools mostly address the energy issues a posteriori, i.e., once they have already been introduced into the code. Android app code can be roughly divided into two parts: the custom code and the reusable code. Custom code is unique to each app. Reusable code includes third-party libraries that are included in apps to speed up the development process. We start by evaluating the energy consumption of various code smell refactorings in native Android apps. Then we conduct an empirical study on the energy impact of third-party network libraries used in Android apps. We provide generalized contextual guidelines that could be used during app development Further, we conduct a systematic literature review to identify and study the current state of the art support tools available to aid green Android development. Based on this study and the experiments we conducted before, we highlight the problems in capturing and reproducing hardware-based energy measurements. We develop the support tool ‘ARENA’ that could help gather energy data and analyze the energy consumption of Android apps. Last, we develop the support tool ‘REHAB’ to recommend energy efficient third-party network libraries to developers.https://www.ester.ee/record=b547174

Bad Droid! An in-depth empirical study on the occurrence and impact of Android specific code smells

Knowing the impact of bad programming practices or code smells has led researchers to conduct numerous studies in software maintenance. Most of the studies have defined code smells as bad practices that may affect the quality of the software. However, most of the existing research is heavily focused on detecting traditional code smells and less focused on mobile application specific Android code smells. Presently, there is a few papers that focus on android code smells - a catalog for Android code smells. This catalog defines 30 Android specific code smell that may impact maintainability of an app. In this research, we plan to introduce a detector tool called \textit{BadDroidDetector} for Android code smells that can detect 13 code smells from the catalog. We will also conduct an empirical study to know the distribution of 13 smell that we detect and know the severity of these smells

Characterizing the evolution of statically-detectable performance issues of Android apps

Mobile apps are playing a major role in our everyday life, and they are tending to become more and more complex and resource demanding. Because of that, performance issues may occur, disrupting the user experience or, even worse, preventing an effective use of the app. Ultimately, such problems can cause bad reviews and influence the app success. Developers deal with performance issues thorough dynamic analysis, i.e., performance testing and profiler tools, albeit static analysis tools can be a valid, relatively inexpensive complement for the early detection of some such issues. This paper empirically investigates how potential performance issues identified by a popular static analysis tool — Android Lint — are actually resolved in 316 open source Android apps among 724 apps we analyzed. More specifically, the study traces the issues detected by Android Lint since their introduction until they resolved, with the aim of studying (i) the overall evolution of performance issues in apps, (ii) the proportion of issues being resolved, as well as (iii) the distribution of their survival time, and (iv) the extent to which issue resolution are documented by developers in commit messages. Results indicate how some issues, especially related to the lack of resource recycle, tend to be more frequent than others. Also, while some issues, primarily of algorithmic nature, tend to be resolved quickly through well-known patterns, others tend to stay in the app longer, or not to be resolved at all. Finally, we found how only 10% of the issue resolution is documented in commit messages

Energy-aware Software

Luca Ardito has focused his PhD on studying how to identify and to reduce the energy consumption caused by software. The project concentrates on the application level, with an experimental approach to discover and modify characteristics that waste energy. We can define five research goals: RG1. Is it possible to measure the energy consumption of an application? Measuring the energy consumption of an electronic device (PC, mobile phone, etc.) is straightforward, but several applications coexist on it, possibly with very different energy needs. Usage profiles for applications are certainly important too. We will consider the most common platforms (Windows, Linux, Mac Osx). RG2. Could Energy Efficiency be considered as a software non- functional requirement? Research has increasingly focused on improving the Energy Efficiency of hardware, but the literature still lacks in quantifying accurately the energy impact of software. This research goal is strictly related to the following one. RG3. Is it possible to profile the energy consumption of a software application? An empirical experiment could assess quantitatively the energetic impact of software usage by building up common application usage scenarios and executing them independently to collect power consumption data. RG4. Is there a relationship between the way a program is written and its energy consumption? The same application, at the code level, can be written in different ways. Here the question is if the different ways have impact on energy consumption. The code should be considered at two levels: source code (programmer) and object code/byte code (compiler). RG5. Is it possible to use the energy consumption information to trigger self-adaptation? A software application could automatically modify its behaviour in order to reduce its energy consumption

EARMO: An Energy-Aware Refactoring Approach for Mobile Apps

The energy consumption of mobile apps is a trending topic and researchers are actively investigating the role of coding practices on energy consumption. Recent studies suggest that design choices can conflict with energy consumption. Therefore, it is important to take into account energy consumption when evolving the design of a mobile app. In this paper, we analyze the impact of eight type of anti-patterns on a testbed of 20 android apps extracted from F-Droid. We propose EARMO, a novel anti-pattern correction approach that accounts for energy consumption when refactoring mobile anti-patterns. We evaluate EARMO using three multiobjective search-based algorithms. The obtained results show that EARMO can generate refactoring recommendations in less than a minute, and remove a median of 84% of anti-patterns. Moreover, EARMO extended the battery life of a mobile phone by up to 29 minutes when running in isolation a refactored multimedia app with default settings (no WiFi, no location services, and minimum screen brightness). Finally, we conducted a qualitative study with developers of our studied apps, to assess the refactoring recommendations made by EARMO. Developers found 68% of refactorings suggested by EARMO to be very relevant.This work has been supported by the Natural Sciences and Engineering Research Council of Canada (NSERC) and Consejo Nacional de Ciencia y Tecnología, México (CONACyT)

The Dilemma of Security Smells and How to Escape It

A single mobile app can now be more complex than entire operating systems ten years ago, thus security becomes a major concern for mobile apps. Unfortunately, previous studies focused rather on particular aspects of mobile application security and did not provide a holistic overview of security issues. Therefore, they could not accurately understand the fundamental flaws to propose effective solutions to common security problems. In order to understand these fundamental flaws, we followed a hybrid strategy, i.e., we collected reported issues from existing work, and we actively identified security-related code patterns that violate best practices in software development. We further introduced the term ``security smell,'' i.e., a security issue that could potentially lead to a vulnerability. As a result, we were able to establish comprehensive security smell catalogues for Android apps and related components, i.e., inter-component communication, web communication, app servers, and HTTP clients. Furthermore, we could identify a dilemma of security smells, because most security smells require unique fixes that increase the code complexity, which in return increases the risk of introducing more security smells. With this knowledge, we investigate the interaction of our security smells with the 192 Mitre CAPEC attack mechanism categories of which the majority could be mitigated with just a few additional security measures. These measures, a String class with behavior and the more thorough use of secure default values and paradigms, would simplify the application logic and at the same time largely increase security if implemented appropriately. We conclude that application security has to focus on the String class, which has not largely changed over the last years, and secure default values and paradigms since they are the smallest common denominator for a strong foundation to build resilient applications. Moreover, we provide an initial implementation for a String class with behavior, however the further exploration remains future work. Finally, the term ``security smell'' is now widely used in academia and eases the communication among security researchers

On energy debt: Managing consumption on evolving software

This paper introduces the concept of energy debt: a new metric, reflecting the implied cost in terms of energy consumption over time, of choosing a flawed implementation of a software system rather than a more robust, yet possibly time consuming, approach. A flawed implementation is considered to contain code smells, known to have a negative influence on the energy consumption. Similar to technical debt, if energy debt is not properly addressed, it can accumulate an energy "interest". This interest will keep increasing as new versions of the software are released, and eventually reach a point where the interest will be higher than the initial energy debt. Addressing the issues/smells at such a point can remove energy debt, at the cost of having already consumed a significant amount of energy which can translate into high costs. We present all underlying concepts of energy debt, bridging the connection with the existing concept of technical debt and show how to compute the energy debt through a motivational example.This work is financed by National Funds through the Portuguese funding agency, FCT - Fundação para a Ciência e a Tecnologia, within project UIDB/50014/2020. The first author is also financed by FCT grant SFRH/BD/132485/2017. The last author is also supported by operation Centro-01-0145-FEDER-000019 - C4 - Centro de Competências em Cloud Computing, cofinanced by the European Regional Development Fund (ERDF) through the Programa Operacional Regional do Centro (Centro 2020), in the scope of the Sistema de Apoio à Investigação Científica e Tecnológica - Programas Integrados de IC&DT