A Systematic Review of the Literature of the Techniques to Perform Transformations in Software Engineering / Uma revisão sistemática da literatura das técnicas para realizar transformações na engenharia de software

Along with software evolution, developers may do repetitive edits. These edits can be identical or similar to different codebase locations, which may occur as developers add features, refactor, or fix a bug. Since some of these edits are not present in Integrated Development Environments (IDEs), they are often performed manually, which is time-consuming and error-prone. In order to help developers to apply repetitive edits, some techniques were proposed. In this work, we present a systematic review of the literature of the techniques to do transformations in software engineering. As a result, this systematic review returned 51 works ranging from the domains programming-by-examples, linked editing, API usage, bug fixing, complex refactoring, and complex transformations, which can be used to help tools' designer in the proposition of new approaches.  Along with software evolution, developers may do repetitive edits. These edits can be identical or similar to different codebase locations, which may occur as developers add features, refactor, or fix a bug. Since some of these edits are not present in Integrated Development Environments (IDEs), they are often performed manually, which is time-consuming and error-prone. In order to help developers to apply repetitive edits, some techniques were proposed. In this work, we present a systematic review of the literature of the techniques to do transformations in software engineering. As a result, this systematic review returned 51 works ranging from the domains programming-by-examples, linked editing, API usage, bug fixing, complex refactoring, and complex transformations, which can be used to help tools' designer in the proposition of new approaches.

Scheduling Refactoring Opportunities Using Computational Search

Maintaining a high-level code quality can be extremely expensive since time and monetary pressures force programmers to neglect improving the quality of their source code. Refactoring is an extremely important solution to reduce and manage the growing complexity of software systems. Developers often need to make trade-offs between code quality, available resources and delivering a product on time, and such management support is beyond the scope and capability of existing refactoring engines. The problem of finding the optimal sequence in which the refactoring opportunities, such as bad smells, should be ordered is rarely studied. Due to the large number of possible scheduling solutions to explore, software engineers cannot manually find an optimal sequence of refactoring opportunities that may reduce the effort and time required to efficiently improve the quality of software systems. In this paper, we use bi-level multi-objective optimization to the refactoring opportunities management problem. The upper level generates a population of solutions where each solution is defined as an ordered list of code smells to fix which maximize the benefits in terms of quality improvements and minimize the cost in terms of number of refactorings to apply. The lower level finds the best sequence of refactorings that fixes the maximum number of code smells with a minimum number of refactorings for each solution (code smells sequence) in the upper level. The statistical analysis of our experiments over 30 runs on 6 open source systems and 1 industrial project shows a significant reduction in effort and better improvements of quality when compared to state-of-art bad smells prioritization techniques. The manual evaluation performed by software engineers also confirms the relevance of our refactoring opportunities scheduling solutions.Master of ScienceComputer Science, College of Engineering and Computer ScienceUniversity of Michigan-Dearbornhttp://deepblue.lib.umich.edu/bitstream/2027.42/136063/1/Scheduling Refactoring Opportunities Using Computational Search.pd

Moving beyond Deletions: Program Simplification via Diverse Program Transformations

To reduce the complexity of software, Developers manually simplify program (known as developer-induced program simplification in this paper) to reduce its code size yet preserving its functionality but manual simplification is time-consuming and error-prone. To reduce manual effort, rule-based approaches (e.g., refactoring) and deletion-based approaches (e.g., delta debugging) can be potentially applied to automate developer-induced program simplification. However, as there is little study on how developers simplify programs in Open-source Software (OSS) projects, it is unclear whether these approaches can be effectively used for developer-induced program simplification. Hence, we present the first study of developer-induced program simplification in OSS projects, focusing on the types of program transformations used, the motivations behind simplifications, and the set of program transformations covered by existing refactoring types. Our study of 382 pull requests from 296 projects reveals that there exist gaps in applying existing approaches for automating developer-induced program simplification. and outlines the criteria for designing automatic program simplification techniques. Inspired by our study and to reduce the manual effort in developer-induced program simplification, we propose SimpT5, a tool that can automatically produce simplified programs (semantically-equivalent programs with reduced source lines of code). SimpT5 is trained based on our collected dataset of 92,485 simplified programs with two heuristics: (1) simplified line localization that encodes lines changed in simplified programs, and (2)checkers that measure the quality of generated programs. Our evaluation shows that SimpT5 are more effective than prior approaches in automating developer-induced program simplification

Refactoring for parameterizing Java classes

Type safety and expressiveness of many existing Java libraries and theirclient applications would improve, if the libraries were upgraded to definegeneric classes. Efficient and accurate tools exist to assist clientapplications to use generics libraries, but so far the libraries themselvesmust be parameterized manually, which is a tedious, time-consuming, anderror-prone task. We present a type-constraint-based algorithm forconverting non-generic libraries to add type parameters. The algorithmhandles the full Java language and preserves backward compatibility, thusmaking it safe for existing clients. Among other features, it is capableof inferring wildcard types and introducing type parameters formutually-dependent classes. We have implemented the algorithm as a fullyautomatic refactoring in Eclipse.We evaluated our work in two ways. First, our tool parameterized code thatwas lacking type parameters. We contacted the developers of several ofthese applications, and in all cases where we received a response, theyconfirmed that the resulting parameterizations were correct and useful.Second, to better quantify its effectiveness, our tool parameterizedclasses from already-generic libraries, and we compared the results tothose that were created by the libraries' authors. Our tool performed therefactoring accurately -- in 87% of cases the results were as good as thosecreated manually by a human expert, in 9% of cases the tool results werebetter, and in 4% of cases the tool results were worse

Can Refactoring be Self-Affirmed? An Exploratory Study on How Developers Document their Refactoring Activities in Commit Messages

Refactoring is a critical task in software maintenance and is usually performed to enforce best design practices, or to cope with design defects. Previous studies heavily rely on defining a set of keywords to identify refactoring commits from a list of general commits extracted from a small set of softwaresystems. All approaches thus far consider all commits without checking whether refactorings had actually happened or not. In this paper, we aim at exploring how developers document their refactoring activities during the software life cycle. We call such activity Self-Affirmed Refactoring, which is an indication ofthe developer-related refactoring events in the commit messages. Our approach relies on text mining refactoring-related change messages and identifying refactoring patterns by only consideringrefactoring commits. We found that (1) developers use a variety of patterns to purposefully target refactoring-related activities; (2) developers tend to explicitly mention the improvement of specific quality attributes and code smells; and (3) commit messages withself-affirmed refactoring patterns tend to have more significant refactoring activit

Formal Verification of Security Protocol Implementations: A Survey

Automated formal verification of security protocols has been mostly focused on analyzing high-level abstract models which, however, are significantly different from real protocol implementations written in programming languages. Recently, some researchers have started investigating techniques that bring automated formal proofs closer to real implementations. This paper surveys these attempts, focusing on approaches that target the application code that implements protocol logic, rather than the libraries that implement cryptography. According to these approaches, libraries are assumed to correctly implement some models. The aim is to derive formal proofs that, under this assumption, give assurance about the application code that implements the protocol logic. The two main approaches of model extraction and code generation are presented, along with the main techniques adopted for each approac

Adaptoring: Adapter Generation to Provide an Alternative API for a Library

Third-party libraries are a cornerstone of fast application development. To enable efficient use, libraries must provide a well-designed API. An obscure API instead slows down the learning process and can lead to erroneous use. The usual approach to improve the API of a library is to edit its code directly, either keeping the old API but deprecating it (temporarily increasing the API size) or dropping it (introducing breaking changes). If maintainers are unwilling to make such changes, others need to create a hard fork, which they can refactor. But then it is difficult to incorporate changes to the original library, such as bug fixes or performance improvements. In this paper, we instead explore the use of the adapter pattern to provide a new API as a new library that calls the original library internally. This allows the new library to leverage all implementation changes to the original library, at no additional cost. We call this approach adaptoring. To make the approach practical, we identify API transformations for which adapter code can be generated automatically, and investigate which transformations can be inferred automatically, based on the documentation and usage patterns of the original library. For cases where automated inference is not possible, we present a tool that lets developers manually specify API transformations. Finally, we consider the issue of migrating the generated adapters if the original library introduces breaking changes. We implemented our approach for Python, demonstrating its effectiveness to quickly provide an alternative API even for large libraries.Comment: Accepted at the International Conference on Software Analysis, Evolution and Reengineering (SANER 2024