A case study of refactoring large-scale industrial systems to efficiently improve source code quality

Refactoring source code has many benefits (e.g. improving maintainability, robustness and source code quality), but it takes time away from other implementation tasks, resulting in developers neglecting refactoring steps during the development process. But what happens when they know that the quality of their source code needs to be improved and they can get the extra time and money to refactor the code? What will they do? What will they consider the most important for improving source code quality? What sort of issues will they address first or last and how will they solve them? In our paper, we look for answers to these questions in a case study of refactoring large-scale industrial systems where developers participated in a project to improve the quality of their software systems. We collected empirical data of over a thousand refactoring patches for 5 systems with over 5 million lines of code in total, and we found that developers really optimized the refactoring process to significantly improve the quality of these systems. © 2014 Springer International Publishing

Challenges in understanding, measuring, and managing technical debt

Abstract. Technical debt as a concept is vast and somewhat abstract area. The most basic definition of it is that it is analogous to a bank loan, which must be paid back so you don’t get stated bankrupt. Number of activities required to manage the debt are numerous, as 15 different sources of possible debt are identified. Technical debt management activities, possible sources, and outcomes that unpaid debt might bring are documented in this paper’s background section. Results section contains challenges that technical debt management processes are encountering in understanding, measuring, and managing the debt. Even with existing empirical research on technical debt management, research and industry are having hard time in trying to find the right tools and areas to measure to gain meaningful information on numerous types of technical debt. Without the right metrics, the monitoring tools are not able to provide useful information to aid in communication and decision-making. Currently, the tools focus mainly on code smells (code debt) and are not able to measure the most important aspects of the debt, design, and architectural debt. This research suggests future research topics to improve existing knowledge on certain areas such as the previously mentioned ability to meaningfully measure different kinds of debts

Fortran refactoring for legacy systems

The motivation of this work comes from a Global Climate Model (GCM) Software which was in great need of being updated. This software was implemented by scientists in the ’80s as a result of meteorological research. Written in Fortran 77, this program has been used as an input to make climate predictions for the Southern Hemisphere. The execution to get a complete numerical data set takes several days. This software has been programmed using a sequential processing paradigm. In these days, where multicore processors are so widespread, the time that an execution takes to get a complete useful data set can be drastically reduced using this technology. As a first objective to reach this goal of reengineering we must be able to understand the source code. An essential Fortran code characteristic is that old source code versions became unreadable, not comprehensive and sometimes “ejects” the reader from the source code. In that way, we can not modify, update or improve unreadable source code. Then, as a first step to parallelize this code we must update it, turn it readable and easy to understand. The GCM has a very complex internal structure. The program is divided into about 300 .f (Fortran 77) files. These files generally implement only one Fortran subroutine. Less than 10% of the files are used for common blocks and constants. Approximately 25% of the lines in the source code are comments. The total number of Fortran source code lines is 58000. A detailed work within the source code brings to light that [74]: 1 About 230 routines are called/used at run time. Most of the runtime is spent in routines located at deep levels 5 to 7 in the dynamic call graph from the main routine. 2 The routine with most of the runtime (the top routine from now on) requires more than 9% of the total program runtime and is called about 315000 times. 3 The top 10 routines (the 10 routines at the top of the flat profile) require about 50% of total runtime. Two of them are related to intrinsic Fortran functions. Our first approach was using a scripting language and Find & Replace tools trying to upgrade the source code, this kind of code manipulation do not guarantee preservation of software behavior. Then, our goal was to develop an automated tool to transform legacy software in more understandable, comprehensible and readable applying refactoring as main technique. At the same time a catalog of transformation to be applied in Fortran code is needed as a guide to programmers through this process.Es revisado por: http://sedici.unlp.edu.ar/handle/10915/9703Facultad de Informátic

30 Years of Software Refactoring Research: A Systematic Literature Review

Peer Reviewedhttps://deepblue.lib.umich.edu/bitstream/2027.42/155872/4/30YRefactoring.pd

30 Years of Software Refactoring Research:A Systematic Literature Review

Due to the growing complexity of software systems, there has been a dramatic increase and industry demand for tools and techniques on software refactoring in the last ten years, defined traditionally as a set of program transformations intended to improve the system design while preserving the behavior. Refactoring studies are expanded beyond code-level restructuring to be applied at different levels (architecture, model, requirements, etc.), adopted in many domains beyond the object-oriented paradigm (cloud computing, mobile, web, etc.), used in industrial settings and considered objectives beyond improving the design to include other non-functional requirements (e.g., improve performance, security, etc.). Thus, challenges to be addressed by refactoring work are, nowadays, beyond code transformation to include, but not limited to, scheduling the opportune time to carry refactoring, recommendations of specific refactoring activities, detection of refactoring opportunities, and testing the correctness of applied refactorings. Therefore, the refactoring research efforts are fragmented over several research communities, various domains, and objectives. To structure the field and existing research results, this paper provides a systematic literature review and analyzes the results of 3183 research papers on refactoring covering the last three decades to offer the most scalable and comprehensive literature review of existing refactoring research studies. Based on this survey, we created a taxonomy to classify the existing research, identified research trends, and highlighted gaps in the literature and avenues for further research.Comment: 23 page

Finding parallel patterns through static analysis in C++ applications

Since The 'Free Lunch' Of Processor Performance Is Over, Parallelism Has Become The New Trend In Hardware And Architecture Design. However, Parallel Resources Deployed In Data Centers Are Underused In Many Cases, Given That Sequential Programming Is Still Deeply Rooted In Current Software Development. To Address This Problem, New Methodologies And Techniques For Parallel Programming Have Been Progressively Developed. For Instance, Parallel Frameworks, Offering Programming Patterns, Allow Expressing Concurrency In Applications To Better Exploit Parallel Hardware. Nevertheless, A Large Portion Of Production Software, From A Broad Range Of Scientific And Industrial Areas, Is Still Developed Sequentially. Considering That These Software Modules Contain Thousands, Or Even Millions, Of Lines Of Code, An Extremely Large Amount Of Effort Is Needed To Identify Parallel Regions. To Pave The Way In This Area, This Paper Presents Parallel Pattern Analyzer Tool, A Software Component That Aids The Discovery And Annotation Of Parallel Patterns In Source Codes. This Tool Simplifies The Transformation Of Sequential Source Code To Parallel. Specifically, We Provide Support For Identifying Map, Farm, And Pipeline Parallel Patterns And Evaluate The Quality Of The Detection For A Set Of Different C++ Applications.This work was partially supported by the EU Projects ICT 644235 “RePhrase: Refactoring Parallel Heterogeneous Resource-Aware Applications” and the FP7 609666 “Repara: Reengineering and Enabling Performance and Power of Application

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

Proceedings of the 3rd Workshop on FAMIX and MOOSE in Software Reengineering (FAMOOSr'09)

International audienceThe goal of the FAMOOSr workshop is to strengthen the community of researchers and practitioners who are working in re- and reverse engineering, by providing a forum for building future research using Moose and FAMIX as shared infrastructure. Research should be collaborative and supported by tools. The increasing amount of data available about software systems poses new challenges for reengineering research, as the proposed approaches need to scale. In this context, concerns about meta-modeling and analysis techniques need to be augmented by technical concerns about how to reuse and how to build upon the efforts of previous research. That is why Moose is an open-source software for researchers to build and share their analysis, meta-models, and data. Both FAMIX and Moose started in the context of FAMOOS, a European research project on object-oriented frameworks. Back in 1997 Moose was as a simple implementation of the FAMIX meta-model, which was a language independent meta-model for object-oriented systems. However over the past decade, Moose has been used in a growing number of research projects and has evolved to be a generic environment for various reverse and reengineering activities. In the same time, FAMIX was extended to support emerging research interest such as dynamic analysis, evolution analysis, identifier analysis, bug tracking analysis, or visualization. Recent work includes analysis of software architecture and semantic annotations. Currently, several research groups are using Moose as a platform, or FAMIX as a meta-model, and other groups announced interest in using them in the future