AI-Augmented Software Architecture: Autonomous Refactoring with Design Pattern Awareness

In the healthcare industry, software quality plays a crucial role as it is used in almost all systems used for medical intervention. If the quality of healthcare software is not considered, it can potentially have a negative effect and may create catastrophic situations for the patient’s health and can seriously affect the organisation’s reputation. Maintainability is a key component of software quality, making up 80% of the total cost of the software development life cycle cost. Software maintainability can be assessed using metrics that are stored in a centralised location. Software maintainability metrics and related data are crucial. If attackers alter this data, it affects the overall quality of healthcare software. In order to solve this issue, we adapted blockchain-based storage, which offers the advantages of decentralisation, immutability, and transparency and is a promising solution. We used Storj, a blockchain-based decentralised file system, to secure the maintainability metrics and related data. According to the results, the maintainability metrics data stored in the blockchain-based decentralised file storage is more secure, redundant, and cost-effective than centralised storage.

Developers often combine multiple programming languages to build large-scale applications. They choose programming languages properly for their tasks at hand instead of solving all of their problems with a single language. Foreign Functions Interface allow code written in one programming language to access features available in another programming language. Multi-language systems benefits from several advantages. However, they also introduce challenges related to the development, comprehension, and maintenance of such systems. Software quality is achieved partly by following good practices---architectural styles, design patterns, idioms---and avoiding bad practices---design anti-patterns and code smells. Yet, a review of the literature shows that there are a few works that study developers' practices among multi-language systems. The heterogeneity of components introduces code smells at the source code level. While design patterns are defined as good solutions to a recurrent problem, code smells are defined as poor design and coding choices that can negatively impact the quality of a software program despite satisfying functional requirements. In this paper, we report four patterns and five code smells related to multi-language systems. Those patterns and code smells were extracted from open-source systems, developers' documentation, and bug reports. We encoded these practices in the form of patterns and code smells in the context of Java Native Interface systems.

Technical Debt analysis is increasing in popularity as nowadays researchers and industry are adopting various tools for static code analysis to evaluate the quality of their code. Despite this, empirical studies on software projects are expensive because of the time needed to analyze the projects. In addition, the results are difficult to compare as studies commonly consider different projects. In this work, we propose the Technical Debt Dataset, a curated set of project measurement data from 33 Java projects from the Apache Software Foundation. In the Technical Debt Dataset, we analyzed all commits from separately defined time frames with SonarQube to collect Technical Debt information and with Ptidej to detect code smells. Moreover, we extracted all available commit information from the git logs, the refactoring applied with Refactoring Miner, and fault information reported in the issue trackers (Jira). Using this information, we executed the SZZ algorithm to identify the fault-inducing and -fixing commits. We analyzed 78K commits from the selected 33 projects, detecting 1.8M SonarQube issues, 38K code smells, 28K faults and 57K refactorings. The project analysis took more than 200 days. In this paper, we describe the data retrieval pipeline together with the tools used for the analysis. The dataset is made available through CSV files and an SQLite database to facilitate queries on the data. The Technical Debt Dataset aims to open up diverse opportunities for Technical Debt research, enabling researchers to compare results on common projects.

As one of the most popular dynamic languages, Python experiences a decrease in readability and maintainability when code smells are present. Recent advancements in Large Language Models have sparked growing interest in AI-enabled tools for both code generation and refactoring. GitHub Copilot is one such tool that has gained widespread usage. Copilot Chat, released in September 2023, functions as an interactive tool aimed at facilitating natural language-powered coding. However, limited attention has been given to understanding code smells in Copilot-generated Python code and Copilot Chat's ability to fix the code smells. To this end, we built a dataset comprising 102 code smells in Copilot-generated Python code. Our aim is to first explore the occurrence of code smells in Copilot-generated Python code and then evaluate the effectiveness of Copilot Chat in fixing these code smells employing different prompts. The results show that 8 out of 10 types of code smells can be detected in Copilot-generated Python code, among which Multiply-Nested Container is the most common one. For these code smells, Copilot Chat achieves a highest fixing rate of 87.1%, showing promise in fixing Python code smells generated by Copilot itself. In addition, the effectiveness of Copilot Chat in fixing these smells can be improved by providing more detailed prompts.

In a majority of Indian Engineering colleges, Software Engineering tends to be considered as a theoretical course. More specifically, software design is taught using traditional lecture based teaching methods with minimal hands-on experience on working with team based projects. As part of this paper, we share our experiences in teaching code smells and design patterns using project-based learning approach to students in a Software Engineering course. We tracked students’ ability to detect code smells and codify design patterns through code evaluation. A confidence survey conducted at the end of the course had a positive feedback. We believe the approach can be repeated across engineering colleges in India to teach Software Engineering design.

Concretely communicating technical debt and its consequences is of common interest to both researchers and software engineers. In the absence of validated tools and techniques to achieve this goal with repeatable results, developers resort to ad hoc practices. Most commonly they report using issue trackers or their existing backlog management practices to capture and track technical debt. In a manual examination of 1,264 issues from four issue trackers from open source industry and government projects, we identified 109 examples of technical debt. Our study reveals that technical debt and its related concepts have entered the vernacular of developers as they discuss development tasks through issue trackers. Even when issues are not explicitly tagged as technical debt, it is possible to identify technical debt items in these issue trackers using a categorization method we developed. We use our results and data to motivate an improved definition and an approach to explicitly report technical debt in issue trackers.

In this article the advances in software engineering are i) evolvement of software processes from rigid, sequential and slow processes to iterative and agile processes and standardization of process models, such as CMMI (Capability Maturity Model Integration) and ISO 12207, ii) programming paradigms and software design techniques, such as object-oriented programming and model-driven architecture, iii) various techniques for software reuse, such as design patterns and component-based software development, iii) formal methods for software specification and verification, and numerous methods for software testing, iv) software architecture, such as event-driven architecture and service-oriented architecture, and architecture description languages. All these advances aim at improving the quality of software, reducing cost, and promoting software reuse.

Code smells are specific patterns or characteristics in software code that indicate potential design or implementation problems. Identifying code smells has gained significant attention in software engineering. It is essential to address code smells to maintain high-quality software systems. Machine learning (ML) models, such as Long Short-Term Memory (LSTM), have been to detect code smells automatically based on source code features. However, the imbalanced distribution of code smells within software projects poses a challenge to the accuracy of these models. This study explores the role of data balancing methods in optimizing the accuracy of the LSTM model for code smell detection. We investigate different techniques for addressing the class imbalance problem, including random oversampling and synthetic minority oversampling techniques (SMOTE). We evaluate the performance of the LSTM model with and without data balancing methods using accuracy, precision, recall, f-measure, Matthew’s correlation coefficient (MCC), and the area under a receiver operating characteristic curve (AUC). Our experimental results, conducted on four code smell datasets (God class, data class, feature envy, and long method) extracted from 74 open-source systems, demonstrate the effectiveness of data balancing methods in improving the accuracy of the LSTM model for code smell detection. The results indicate that the use of data balancing methods had a positive effect on the predictive accuracy of the LSTM model. In addition, we compared our proposed method with state-of-the-art code smell detection approaches. The findings from the comparison indicate that our proposed method performs notably better than existing state-of the-art approaches across the majority of datasets.

Prevalence, common causes and effects of technical debt: Results from a family of surveys with the IT industry

There is a pressing need to be able to calculate and to justify the costs of software re‐engineering. The purpose of the paper is to address that need by establishing a framework for the economics of re‐engineering. The objective of re‐engineering is to reduce maintenance costs. This objective is served by increasing quality and reducing complexity. Both of these goals are examined here in the light of software maintainability metrics. The costs of re‐engineering are driven by the size and interdependency of the software as well as by the degree of automation available. The paper presents a method of estimating the costs of re‐engineering, and presents some figures acquired through practical experience. Finally, a method is defined for weighing estimated costs against expected benefits in order to support decisions on whether to renovate existing software or replace it by a new development. This is a major decision faced by many industrial managers today.

Chemistry Foundation Models (CFMs) that leverage Graph Neural Networks (GNNs) operating on 3D molecular graph structures are becoming indispensable tools for computational chemists and materials scientists. These models facilitate the understanding of matter and the discovery of new molecules and materials. In contrast to GNNs operating on large homogeneous graphs, GNNs used by CFMs process a large number of geometric graphs of varying sizes, requiring different optimization strategies than those developed for large homogeneous GNNs. This paper presents optimizations for two critical phases of CFM training: data distribution and model training, targeting MACE - a state-of-the-art CFM. We address the challenge of load balancing in data distribution by formulating it as a multi-objective bin packing problem. We propose an iterative algorithm that provides a highly effective, fast, and practical solution, ensuring efficient data distribution. For the training phase, we identify symmetric tensor contraction as the key computational kernel in MACE and optimize this kernel to improve the overall performance. Our combined approach of balanced data distribution and kernel optimization significantly enhances the training process of MACE. Experimental results demonstrate a substantial speedup, reducing per-epoch execution time for training from 12 to 2 minutes on 740 GPUs with a 2.6M sample dataset.

In software engineering, maintainability is related to investigating the defects and their causes, correcting the defects and modifying the system to meet customer requirements. Maintenance is a time consuming activity within the software life cycle. Therefore, there is a need for efficiently organizing the software resources in terms of time, cost and personnel for maintenance activity. One way of efficiently managing maintenance resources is to predict defects that may occur after the deployment. Many researchers so far have built defect prediction models using different sets of metrics such as churn and static code metrics. However, hidden causes of defects such as code smells have not been investigated thoroughly. In this study we propose using data science and analytics techniques on software data to build defect prediction models. In order to build the prediction model we used code smells metrics, churn metrics and combination of churn and code smells metrics. The results of our experiments on two different software companies show that code smells is a good indicator of defect proneness of the software product. Therefore, we recommend that code smells metrics should be used to train a defect prediction model to guide the software maintenance team.

Technical Debt arises from decisions that favour short-term outcomes at the cost of longer-term disadvantages. They may be taken knowingly or based on missing or incomplete awareness of the costs; they are taken in different roles, situations, stages and ways. Whatever technical or business factor motivate such decisions, they always imply a trade-off in time, a 'now vs. later'. How exactly are such decisions made, and how have they been studied? This paper analyzes how decisions on technical debt are studied in software engineering via a systematic literature review. It examines the presently published Software Engineering research on Technical Debt, with a particular focus on decisions involving time. The findings reveal surprising gaps in published work on empirical research in decision making. We observe that research has rarely studied how decisions are made, even in papers that focus on the decision process. Instead, most attention is focused on engineering measures and feeding them into an idealized decision making process. These findings lead to a set of recommendations for future empirical research on Technical Debt.

Federated learning has been applied to various tasks in intelligent transportation systems to protect data privacy through decentralized training schemes. The majority of the state-of-the-art models in intelligent transportation systems (ITS) are graph neural networks (GNN)-based for spatial information learning. When applying federated learning to the ITS tasks with GNN-based models, the existing frameworks can only protect the data privacy; however, ignore the one of topological information of transportation networks. In this article, we propose a novel federated learning framework to tackle this problem. Specifically, we introduce a differential privacy-based adjacency matrix preserving approach for protecting the topological information. We also propose an adjacency matrix aggregation approach to allow local GNN-based models to access the global network for a better training effect. Furthermore, we propose a GNN-based model named attention-based spatial-temporal graph neural networks (ASTGNN) for traffic speed forecasting. We integrate the proposed federated learning framework and ASTGNN as FASTGNN for traffic speed forecasting. Extensive case studies on a real-world dataset demonstrate that FASTGNN can develop accurate forecasting under the privacy preservation constraint.

Cross-disciplinary and cross-life-cycle-phase Technical Debt in automated Production Systems: two industrial case studies and a survey