Software defect prediction (SDP) is an effective approach to ensure software reliability. Machine learning models have been widely employed in SDP, but they ignore the impact of class imbalance, noise and outliers on the prediction performance. This study proposes a fuzzy cost broad learning system (FC‐BLS). FC‐BLS not only handles class imbalance problems but also considers the specific sample distribution to address noise and outliers in software defect datasets. Our approach draws fully on the idea of the cost matrix and fuzzy membership functions. It introduces them to BLS, where the cost matrix prioritises the training errors on the minority samples. Hence, the classification hyperplane position is more reasonable, and fuzzy membership functions calculate the membership degree of the sample in a feature mapping space to remove the prediction error caused by noise and outlier samples. Then, the optimisation problem is constructed based on the idea that the minority class and normal instances have relatively high costs. By contrast, the majority class and noise and outlier instances have relatively small costs. This study conducted experiments on nine NASA SDP datasets, and the experimental findings demonstrated the effectiveness of the proposed methodology on most datasets.

With the increasing scale and complexity of software recently, automated software bug repair has grown in importance. However, the current automated software bug repair process suffers from issues such as coarse-grained repair granularity and poor patch quality. To address these problems, we propose a graph mining template-based automatic software repair (GMRepair) to improve the performance of automated software bug repair. First, this approach adopts the Ochiai fault localization technique to locate and generate a list of suspicious defect statements. We utilize the GumTree tool to parse the bug and repair program files, generating edit scripts. These edit scripts are then transformed into a graphical representation. Second, we utilize a frequent graph miner to obtain graph mining templates by matching the context of the suspicious statements with the context of the graph mining templates, generating an initial population for them. The buggy program is evolved using genetic programming through mutation and crossover operations, generating new individuals. Finally, we sequentially pass the candidate patches (CPs) through corresponding test cases and prioritize the test cases using priority sorting techniques. Patches that fail to pass the test cases are filtered out, and the patches that pass the test cases are output. We conducted the experiments using two datasets, QuixBugs and Defects4J. In Defects4J, the GMRepair successfully repaired 41 defects, while in QuixBugs, it successfully repaired 15 defects. Compared to the existing methods, GMRepair offers a higher success rate and efficiency in defect repair.

Researchers in the microservices community often resort to demonstrating the impact of their proposed advancements on custom-made microservices projects. This is a possible source of bias that can reduce the trustworthiness of the results. Moreover, it is hard to compare advances in small projects, often developed due to lack of time. It is common across disciplines to recognize benchmarks that mitigate bias and unify the advancements' impact. To facilitate the identification of available open-source microservice projects (OSS-MS), we performed a comprehensive study to identify, curate, and catalog OSS-MS. We started with 389559 projects and filtered them down to 3804 projects that we manually labeled. After manual labeling, our dataset contains 378 projects with three or more microservices and with over 100 commits. We document the projects from many perspectives, including project size, platform, number of contributors, project purpose, and foundation support. This dataset can serve researchers as a roadmap to identify benchmarks, as our dataset can be used to answer questions such as whether the number of services impacts the issue count.

Abstract Software traceability plays a critical role in software maintenance and evolution. We conducted a systematic mapping study with six research questions to understand the benefits, costs, and challenges of using traceability in maintenance and evolution. We systematically selected, analyzed, and synthesized 63 studies published between January 2000 and May 2020, and the results show that traceability supports 11 maintenance and evolution activities, among which change management is the most frequently supported activity; strong empirical evidence from industry is needed to validate the impact of traceability on maintenance and evolution; easing the process of change management is the main benefit of deploying traceability practices; establishing and maintaining traceability links is the main cost of deploying traceability practices; 13 approaches and 32 tools that support traceability in maintenance and evolution were identified; improving the quality of traceability links , the performance of using traceability approaches , and tools are the main traceability challenges in maintenance and evolution. The findings of this study provide a comprehensive understanding of deploying traceability practices in software maintenance and evolution phase and can be used by researchers for future directions and practitioners for making informed decisions while using traceability in maintenance and evolution.

Architecture Smells (ASs), as one source of technical debt, indicate underlying problems at a high level of systems and negatively impact various system qualities, such as maintainability and evolvability. Detecting and refactoring ASs requires the relevant architectural knowledge and experience. Therefore, gathering the knowledge of ASs from various sources can facilitate ASs detecting and refactoring. However, manually identifying AS knowledge is time-consuming. Automatically and correctly identifying AS-related posts from Stack Overflow is a step toward utilizing the AS knowledge to help developers better maintain their systems. In this work, we propose an approach to automatically identify AS-related posts from Stack Overflow (SoF) by using machine learning algorithms. We evaluate the performance of 12 classifiers based on 3 feature extraction techniques and 4 classification algorithms with a created dataset of SoF posts (including 208 AS-related posts and 187 AS-unrelated posts). The results demonstrate that the SVM algorithm with Word2Vec achieved the best overall performance with an accuracy of 0.650, a precision of 0.613, a recall of 0.905, and an F1- score of 0.731. These results imply that the obtained model of the AS-related posts identification can be used to aid developers and researchers in collecting AS discussions from SoF.

Architecture Smells (ASs) are design decisions that can have significant negative effects on a system's quality attributes such as reusability and testability. ASs are focused on higher level of software systems than code smells, which are implementation-level constructs. ASs can have much wider impact on a system than code smells. However, ASs usually receive less attention than code smells in both research and practice. We have conducted an exploratory study of developers' conception of ASs by analyzing related discussions in Stack Overflow. We used 14 ASs related terms to search the relevant posts in Stack Overflow and extracted 207 posts. We used Grounded Theory method for analyzing the extracted posts about developers' description of ASs, causes of ASs, approaches and tools for detecting and refactoring ASs, quality attributes affected by ASs, and difficulties in detecting and refactoring ASs. Our findings show that: (1) developers often describe ASs with some general terms; (2) ASs are mainly caused by violating architecture patterns, design principles, or misusing architecture antipatterns; (3) there is a lack of dedicated tools for detecting and refactoring ASs; (4) developers mainly concern about the maintainability and performance of systems affected by ASs; and (5) the inability to quantify the cost and benefit as well as the lack of approaches and tools makes detecting and refactoring ASs difficult.