Ensuring the readability and comprehension of source code is key for effective software maintenance and evolution, particularly in tasks involving bug fixing, refactoring, and optimization. Previous studies highlight that challenges in maintenance and the emergence of certain bugs can be traced back to small code fragments called "Atoms of Confusion" (AC). While initial investigations identified these snippets in C++ code bases, subsequent studies have identified analogous structures in languages such as Java. Although numerous studies have delved into observing ACs in Java projects, there is a lack of studies focused on the Android ecosystem. This paper aims to address this gap by constructing a comprehensive dataset, which catalogs ACs and assesses their prevalence in the Android Open Source Project (AOSP). After analyzing over 125,000 source code files across 370 Git repositories, our findings reveal that more than 30% of Java files within the AOSP contain at least one AC, totaling over 320,000 recorded instances. This equates to one AC for approximately every 91 lines of code. Particularly, this dataset can be used to support further studies on shedding light on the ACs prevalence in the Android ecosystem, alongside their relation with traditional object-oriented software metrics (e.g., size, complexity, cohesion, and coupling), also recorded in the dataset. Using this dataset, researchers may provide valuable insights for developers and software engineers, emphasizing the need for strategies to mitigate the possible impact of ACs on software maintenance.

Android developers can use both Java and Kotlin programming languages to create their own apps. Such programming languages provide exception handling facilities to improve apps’ robustness (providing means to implement fault-tolerant measures) and maintainability (separating the error-handling code from the regular one). The Android architecture imposes complexity on the way apps handle exceptions, once exceptions may be raised in parts that are not responsible for handling this abnormal situation. A straightforward solution is to send the Exception Notification (EN) to its concerned handler. However, the way developers are using Android’s inter-component communication mechanism to perform EN may lead to well-known exception handling drawbacks related to the usage of error/return code (e.g., decaying of code readability, programmability, and extensibility). To overcome this problem, we propose a pub/sub-based mechanism to perform EN between Android components called R-EventBus. We evaluate R-EventBus through a performance benchmark and by refactoring a set of apps from the F-Droid repository and comparing the original and refactored versions regarding behavior preservation and EN concern diffusion. Our results indicate that R-EventBus shows negligible performance issues, preserves the apps’ behavior, and considerably improves the modularization of EN concern in the refactored apps.

Software comprehension is essential to improve understanding and avoid mistakes in the software development lifecycle. Code confusion occurs when a developer and the computer reach different interpretations about the behavior of the same piece of code. Such pieces of code can be represented as small and isolated code patterns called Atoms of Confusion (ACs). In this study, we empirically investigated the effects of ACs in the software development lifecycle of 21 open-source Java projects. We built a dataset linking more than 8,000 commits, 4,000 reported issues, and 7,000 ACs from the subject projects. Our findings showed a positive correlation between the number of ACs and the number of reported bugs and improvements. We also investigated changes in commits, looking forward to gathering a better understanding of in what context ACs are removed. As each commit is linked to at least one reported issue (e.g., bug and improvement), we were able to compare the ratio of ACs removal regarding each kind of commit and use it as a proxy to indicate whether ACs are likely to be the cause behind a reported issue. We found a higher ratio of removed ACs in bug-fix and improvement commits than in the other kind of commits (task, sub-task, new feature, wish, and test) for 14 of the 19 studied projects, which had ACs removed in commits. Finally, to support our quantitative results, we conducted a qualitative analysis to understand better how often atoms of confusion contributed to the occurrence of a bug or improvement. We inspected ACs removed in these types of commits with up to ten lines removed, analyzing the source code, messages of each involved commit, and the title, description, and comments of related Jira issues. Out of a universe of 8,641 commits from 21 analyzed projects, 391 removed ACs. Among them, 53 met the condition for our qualitative analysis. In 7 of these commits, 9 removed ACs were likely to contributed directly to the occurrence of a bug or improvement. To the best of our knowledge, our research is the first to investigate the connection between Atoms of Confusion and the source of bugs or the cause of improvements in Java projects.

Background: Bug-fixing is the crux of software maintenance. It entails tending to heaps of bug reports using limited resources. Using historical data, we can ask questions that contribute to better-informed allocation heuristics. The caveat here is that often there is not enough data to provide a sound response. This issue is especially prominent for young projects. Also, answers may vary from project to project. Consequently, it is impossible to generalize results without assuming a notion of relatedness between projects.

Program comprehension is a fundamental activity in software maintenance and evolution, impacting several tasks such as bug fixing, code reuse, and implementation of new features. The Atom of Confusion (AC) is considered the smallest piece of code that can confuse programmers, difficulting the correct understanding of the source code under consideration. Previous studies have shown that these atoms can significantly impact the presence of bugs in C++ projects and increase the time and effort to code understanding in C++ and Java programs. To gather more evidence about the diffusion of ACs in the Java ecosystem, we conduct a study to analyze the prevalence, co-occurrences (at the class level), and evolution of ACs in 27 long-lived Java libraries. To support our investigation, we developed an ACs automatic search tool, which found 11.404 occurrences in the studied libraries. The Conditional Operator and Logic as Control Flow ACs were the most prevalent among the 10 types of ACs assessed. Our findings show that Conditional Operator and Logic as Control Flow were more likely to co-occur in the same class. Finally, we observed that the prevalence of ACs did not decrease over time. On the contrary, in 13 libraries, the presence grew proportionally more than the size of the library in lines of code. Furthermore, in 15 libraries, the fraction of Java classes containing at least one AC also increases over time.

Buggy software impacts people's lives and businesses. Nowadays, a huge portion of a software project's cost is spent on debugging (finding and fixing bugs). Therefore, reducing the time needed to release new software versions free from bugs becomes crucial. Continuous delivery (CD) arises as an alternative to traditional software release engineering by providing the capability to faster and continuously release software to customers through automated pipelines. Previous studies claim that CD adoption leads to a reduction in the software release cycle time, including the time lag to fix reported bugs (bug-fixing time) and apply correction patches in the affected versions. However, there is a lack of empirical evidence supporting (or not) this claim. To fulfill this gap, we conducted an empirical study to evaluate the impact of CD adoption in the bug-fixing time. We study 25 open-source projects comparing the bug-fixing time before and after adopting CD. Our results show that bug-fixing time after CD adoption becomes shorter (with statistical significance) than the bug-fixing time before CD adoption.

Software Engineering (SE) education presents many challenges, especially related to hands-on activities that aim to improve practical skills and competencies to solve real-world problems. Some new Learning Approaches, such as Flipped Classroom (FC), emerged and can improve learning processes in this scenario. This doctoral work explores the Flipped Classrooms ideas, identifies challenges, and proposes a tool for reducing them, thus contributing to improved software engineering teaching research. Furthermore, the study aims to combine Adaptive Learning and Flipped Classroom approaches to offer study guides personalization and positively impact SE students’ learning during outside classroom studies.

Technical debt (TD) is a metaphor that reflects the technical compromises that sacrifice the long-term health of a software product to achieve short term benefit. It is important to manage TD to avoid software degradation. In large-scale distributed projects, technical debt management (TDM) becomes more complex and challenging. There is a lack of empirical studies on the TD accumulation in large-scale distributed projects. Then, to address this gap, we conducted a case study in Ericsson (a European Telecom Company) to identify the relationship between TD accumulation and factors such as task complexity, lead time, total of developers, and task scaling. We used data from 33 projects extracted from managerial documents to conduct a regression analysis. We also conducted interviews with seniors developers of the team to interpret the results. We found out that Task Complexity has a strong relationship (p-value = 5.69 × 10−5) with Technical Debt, while Global Distance was mentioned by the interviewees as a relevant factor for TD accumulation (although not statistically significant in our regression analysis). Practitioners should consider avoiding complex/big tasks, breaking down big tasks into small ones (if possible). We also plan to analyze other projects in this company to confirm our findings further.

Code Smell can be defined as any feature in the source code of a software that may indicate possible problems. In database languages, the term Bad Smell has been used as a generalization of Code Smell, once some features that are not directly related to code also can indicate problems, such as, for instance, the inappropriate type of an index structure or a SQL query written inefficiently. Bearing in mind the recurrence of different Bad Smell, they were catalogued. Along with these catalogs, tools were developed to automatically identify Bad Smell occurrences in a given code. With the help of these tools, it has become possible to perform quick and effective analysis. In this context, this paper proposes an exploratory study about Bad Smell in PL/SQL codes, from free software projects, published on GitHub. We analyzed 20 open-source PL/SQL projects and empirically study the prevalence of bad smells. Our results showed that some smells occur together. Besides, some smells are more frequent than others. Based on this principle, this paper has the potential to aid professionals from the databases area to avoid future problems during the development of a PL/SQL project.

Software unbundling consists of dividing an existing software artifact into smaller ones. Unbundling can be useful for removing clutter from the original application or separating different features that may not share the same purpose, or simply for isolating an emergent functionality that merits to be an application on its own. This phenomenon is frequent with mobile apps and it is also propagating to APIs. This paper proposes a first empirical study on unbundling to understand its effects on popular APIs. We explore the possibilities of splitting libraries into 2 or more bundles based on the use that their client projects make of them. We mine over than 71,000 client projects of 10 open source APIs and automatically generate 2,090 sub-APIs to then study their properties. We find that it is possible to have sets of different ways of using a given API and to unbundle it accordingly; the bundles can vary their representativeness and uniqueness, which is analyzed thoroughly in this study.

Currently, mobile applications have become increasingly complex. One trend is the usage of contextual information gathered from device sensors and external data sources, which are used to improve the user experience when using mobile applications. As the amount of sensing data increases as well as the complexity of context inference procedures, it leads to an undesirable situation where the mobile device has not enough resources (e.g., memory capacity, processing speed, and battery power) to perform some computation tasks. This paper addresses this issue by proposing CAOS, a software platform that employs the offloading approach to enhance mobile context-aware applications. CAOS allows mobile application developers to offload rocesses and data into cloud and cloudlets infrastructures, aiming at improving the overall application performance and saving battery power. In order to assess our proposal, a reference implementation was built, and experiments were performed in order to evaluate performance and energy consumption of our proposal. Results showed gains in both aspects in most of scenarios, which denote the feasibility of the proposed solution.

In this paper we present a new tool called Bean-Watcher. This tool allows the semi-automatic generation of monitoring and management applications for wireless networks such as WLANs and WPANs. The architecture of the tool is based on a component model flexible enough to allow the creation of new components and the optimization of the components currently provided. BeanWatcher was designed to offer a development environment suitable for both expert and beginner users allowing them to choose the programming language that better fits the application requirements.