Software architecture is the abstraction of a software system, that significantly influences software development and maintenance. As software evolves, continuous changes could deviate its architecture from the original design, leading to architecture degradation that causes a decline in software quality. Architecture refactoring becomes necessary to address or mitigate architecture degradation for improving overall quality. Although researchers have developed various architecture refactoring tools and techniques, there has been limited research on how architecture refactoring is practiced in real-world scenarios. In this paper, we conducted an empirical study by analyzing posts from Stack Overflow to understand architecture refactoring in practice. Through our analysis of 694 posts with 3,468 discussion threads, we identified 12 types of architecture refactoring based on two classification dimensions. Additionally, we categorized architecture problems faced by practitioners and explored their corresponding refactoring solutions. Furthermore, we revealed six potential risks that may result from architecture refactoring. We believe that our study can provide valuable insights for practitioners to perform architecture refactoring effectively. The findings can serve as a foundation for future research and offer practical guidance to improve architecture quality.

In recent years, the development of Solidity smart contracts has been increasing rapidly in popularity. Code cloning is a common coding practice, and many prior studies have revealed that code clones could negatively impact software maintenance and quality. However, there is little work systematically analyzing the nature and impacts of code clones in solidity smart contracts. To bridge this gap, we investigate the prevalence, evolution, and bug-proneness of code clones in solidity smart contracts, and further identify the possible reasons for these clones' occurrences. With our evaluation of 26,294 smart contracts with 97,877 functions, we have found that code clones are highly prevalent in smart contracts. Additionally, on average, 32.01% of clones co-evolve, indicating the need for careful management to avoid consistency issues. Surprisingly, unlike in traditional software development, code clones in smart contracts are rarely involved in bug fixes. Finally, we identify three main factors that affect the occurrences of clones. We believe our study can provide valuable insights for developers to understand and manage code clones in solidity smart contracts.

In recent years, with the rapid development of automated driving technology, the safety and quality of automated driving software have become important concerns.Prior studies have shown that code clones are prevalent in autonomous driving software and significantly impact software quality, maintenance costs, and module independence.Although code cloning can improve development productivity, they are more likely to introduce co-modifications and software defects, which leads to high detection and fixing costs.In this paper, we propose a novel approach to predict defective code clones in autonomous driving software by focusing specifically on clone code snippets as prediction targets.We designed a comprehensive set of nine code metrics characterizing clone snippets from three dimensions: code size, complexity, and historical modifications.Using six machine learning algorithms, we built prediction models and evaluated them on two representative L4 opensource autonomous driving platforms: Apollo and Autoware.Our experimental results demonstrate that the developed prediction models achieve good performance with accuracy rates ranging from 82.7% to 94.4%.Through principal component analysis, we identified that the number of added lines, modification frequency, and clone line count are the most significant factors contributing to defect proneness in code clones.We believe that this work enables developers to locate defective code clones more precisely.Thus, they can improve testing efficiency, reduce bug fix costs, and ultimately improve the quality and reliability of autonomous driving software.

With the rapid advancement of automated driving technology, numerous manufacturers deploy vehicles with auto-driving features. This highlights the importance of ensuring the quality of automated driving software. To achieve this, characterizing bugs in automated driving software is important, as it can facilitate bug detection and bug fixes, thereby ensuring software quality. Automated driving software typically has a modular architecture, where software is divided into multiple modules, each designed for its own functionality for automated driving. This may lead to varying bug characteristics. Additionally, our recent study has shown a correlation between bugs caused by code clones and the functionalities of modules in automated driving software. Hence, we consider the modular structure when analyzing bug characteristics. In this article, we analyze 3,078 bugs from two representative open-source Level-4 automated driving systems, Apollo and Autoware. By analyzing the bug report description, title, and developers’ discussions, we have identified 20 bug symptoms and 17 bug-fixing strategies and analyzed their relationships with the respective modules. Our analysis achieves 12 main findings offering a comprehensive view of bug characteristics in automated driving software. We believe our findings can help developers better understand and manage bugs in automated driving software, thereby improving software quality and reliability.

AI programming has become a popular topic in recent years. Code suggestion, with code suggestion being a key capability of AI programming. Copilot, an “AI programmer” that provides code suggestions from natural language descriptions, has been launched by GitHub and OpenAI. By far, Copilot has been widely used by millions of developers. However, little work has systematically evaluated the correctness of Copilot’s suggestions. We conducted an empirical study on all 2,033 LeetCode problems to assess Copilot’s code generation across four mainstream languages: C, Java, JavaScript, and Python. We have found that: (1) 70.0% of problems received at least one correct suggestion, with language-specific rates of 29.7% (C), 57.7% (Java), 54.1% (JavaScript), and 41.0% (Python); (2) correctness decreases as problem difficulty increases, with acceptance rates of 89.3% (easy), 72.1% (medium), and 43.4% (hard); (3) acceptance rates vary across problem domains from 49.5% to 90.1%, while Graph problems challenge C and Python most, and Prefix Sum and Heap challenge Java and JavaScript most; (4) for the incorrect suggestions, we further summarize 17 types of error reasons accounting for their incorrectness and analyzed possible causes for why these errors occur. We believe our study can provide valuable insights into Copilot’s capabilities and limitations.

During software evolution, commits with various purposes, such as bug fixes, feature additions, improvements, etc., are continuously applied to software systems. This could drift software architecture from its planned design, and even cause architectural decay, that negatively affects software maintenance. Although prior studies have presented that even daily code commits could induce architectural changes, and the commit-level analysis has been widely used for multiple software comprehension and maintenance tasks, there is little work analyzing the architectural changes at the commit level. To bridge this gap, we conduct a study investigating the relationships between commits and architectural changes. Through our evaluation of thirty projects, we have shown that the architecture remains stable after most of the commits. However, there still exists a large portion of commits (27% of all studied commits) that have induced architectural changes, which deserve more attention. This further suggests the importance of analyzing architectural changes at the commit level. Meanwhile, we present a suite of commit-level metrics strongly correlated with architectural changes. Finally, we propose prediction models that can effectively forecast how much of the architecture would be changed after a commit.

Background: In modern software systems, more and more systems are written in multiple programming languages (PLs). There is no comprehensive investigation on the phenomenon of multi-programming-language (MPL) bugs, which resolution involves source files written in multiple PLs. Aim: This work investigated the characteristics of bug resolution in MPL software systems and explored the reasons why bug resolution involves multiple PLs. Method: We conducted an empirical study on 54 MPL projects selected from 655 Apache OSS projects, of which 66,932 bugs were analyzed. Results: (1) the percentage of MPL bugs (MPLBs) in the selected projects ranges from 0.17% to 42.26%, and the percentage of MPLBs for all projects as a whole is 10.01%; (2) 95.0% and 4.5% of all the MPLBs involve source files written in 2 and 3 PLs, respectively; (3) the change complexity resolution characteristics of MPLBs tend to be higher than those of single-programming-language bugs (SPLBs); (4) the open time for MPLBs is 19.52% to 529.57% significantly longer than SPLBs regarding 9 PL combinations; (5) the reopen rate of bugs involving the PL combination of JavaScript and Python reaches 20.66%; (6) we found 6 causes why the bug resolution involves multiple PLs and identified 5 cross-language calling mechanisms. Conclusion: MPLBs are related to increased development difficulty.

Deep learning frameworks (DLFs) have been playing an increasingly important role in this intelligence age since they act as a basic infrastructure for an increasingly wide range of AI-based applications. Meanwhile, as multi-programming-language (MPL) software systems, DLFs are inevitably suffering from bugs caused by the use of multiple programming languages (PLs). Hence, it is of paramount significance to understand the bugs (especially the bugs involving multiple PLs, i.e., MPL bugs) of DLFs, which can provide a foundation for preventing, detecting, and resolving bugs in the development of DLFs. To this end, we manually analyzed 1497 bugs in three MPL DLFs, namely MXNet, PyTorch, and TensorFlow. First, we classified bugs in these DLFs into 12 types (e.g., algorithm design bugs and memory bugs) according to their bug labels and characteristics. Second, we further explored the impacts of different bug types on the development of DLFs, and found that deployment bugs and memory bugs negatively impact the development of DLFs in different aspects the most. Third, we found that 28.6%, 31.4%, and 16.0% of bugs in MXNet, PyTorch, and TensorFlow are MPL bugs, respectively; the PL combination of Python and C/C++ is most used in fixing more than 92% MPL bugs in all DLFs. Finally, the code change complexity of MPL bug fixes is significantly greater than that of single-programming-language (SPL) bug fixes in all the three DLFs, while in PyTorch MPL bug fixes have longer open time and greater communication complexity than SPL bug fixes. These results provide insights for bug management in DLFs.

With the continuous improvement of artificial intelligence technology, autonomous driving technology has been greatly developed. Hence automated driving software has drawn more and more attention from both researchers and practitioners. Code clone is a commonly used to speed up the development cycle in software development, but many studies have shown that code clones may affect software maintainability. Currently, there is little research investigating code clones in automated driving software. To bridge this gap, we conduct a comprehensive experience study on the code clones in automated driving software. Through the analysis of Apollo and Autoware, we have presented that code clones are prevalent in automated driving software. about 30% of code lines are involved in code clones and more than 50% of files contain code clones. Moreover, a notable portion of these code clones has caused bugs and co-modifications. Due to the high complexity of autonomous driving, the automated driving software is often designed to be modular, with each module responsible for a single task. When considering each module individually, we have found that Perception, Planning, Canbus, and Sensing modules are more likely to encounter code clones, and more likely to have bug-prone and co-modified clones. Finally, we have shown that there exist cross-module clones to propagate bugs and co-modifications in different modules, which undermine the software's modularity.

To efficiently fix defects within a specific time frame during software development, researchers have proposed defect severity prediction to help developers determine which defects to fix first and make efficient use of limited resources.Additionally, to improve the efficiency of defect fixing, just-in-time (JIT) defect prediction has been proposed to promptly predict code fragments that may introduce defects when developers make code changes (i.e., submit a commit).In this way, defect feedback is prompt and localization precision is high.Typically, high-priority defects must be addressed as soon as possible, but when the bug report records a defect back to developers, they need to take time to get reacquainted with the related code fragments, slowing down the speed of high-priority defect fixes.Therefore, we used three machine learning algorithms to develop a JIT defect severity prediction model that allows developers to classify the severity of potential defects when submitting code changes.Our models were tested on ten large-scale projects and showed they can effectively predict defect severity just in time.With Random Forest, our models achieved an average precision of 0.552, and an average recall, F1-measure, and AUC of 0.579, 0.528, and 0.729, respectively.Using Decision Tree, the average precision, recall, F1-measure, and AUC achieve 0.479, 0.494, 0.485, and 0.619, respectively; Using KNN, the average precision, recall, F1measure, and AUC are 0.466, 0.468, 0.467, and 0.593, respectively.Meanwhile, we find a large portion (90.3% on average) of defectintroducing changes are at a high severity level.

Abstract Dependency cycles have been claimed to incur negative impacts on software quality and make a system difficult to test, maintain, and reuse. Previous studies have investigated dependency cycles' evolution and proposed various methods to detect and break dependency cycles. While these studies provide valuable inputs for understanding dependency cycles, we do not know how developers address dependency cycles in their daily activities and whether dependency cycles' resolution follows certain patterns. Therefore, in this paper, using the data from 18 open‐source projects, we extracted dependency cycles along with their changes from each commit and studied how dependency cycles evolved in a fine‐grained level. Our results demonstrate that, 28.4% of dependency cycles have been continuously changing through different status: aggregating, breaking, newly‐forming, and disappearing. Furthermore, we found that dependency cycles in different shapes present their specific evolution characteristics, for example, star and circle dependency cycles tend to preserve their original shape during aggregation or breaking. In addition, we discovered several recurring patterns that developers applied in fully breaking star and circle dependency cycles. We believe the recurring patterns we summarized have the potential to be automated in breaking dependency cycles in practice.

Deep learning (DL) is a really active topic in recent years. Code cloning is a common code implementation that could negatively impact software maintenance. For DL software, developers rely heavily on frameworks to implement DL features. Meanwhile, to guarantee efficiency, developers often reuse the steps and configuration settings for building DL models. These may bring code copy-pastes or reuses inducing code clones. However, there is little work exploring code clones’ impact on DL software. In this article, we conduct an empirical study and show that: (1) code clones are prevalent in DL projects, about 16.3% of code fragments encounter clones, which is almost twice larger than the traditional projects; (2) 75.6% of DL projects contain co-changed clones, meaning changes are propagated among cloned fragments, which can bring maintenance difficulties; (3) Percentage of the clones and Number of clone lines are associated with the emergence of co-changes; (4) the prevalence of Code clones varies in DL projects with different frameworks, but the difference is not significant; (5) Type 1 co-changed clones often spread over different folders, but Types 2 and 3 co-changed clones mainly occur within the same files or folders; (6) 57.1% of all co-changed clones are involved in bugs.

Microservice is an architecture style that decomposes complex software into loosely coupled services, which could be developed, maintained, and deployed independently. In recent years, the microservice architecture has been drawing more and more attention from both industrial and academic communities. Many companies, such as Google, Netflix, Amazon, and IBM have applied microservice architecture in their projects. Researchers have also studied microservices in different directions, such as microservices extraction, fault localization, and code quality analysis. The recent work has presented cross-service code clones are prevalent in microservice projects and have caused considerable co-modifications among different services, which undermines the independence of microservices. But there is no systematic study to reveal the underlying reasons for the emergence of such clones. In this paper, we first build a dataset consisting of 2,722 pairs of cross-service clones from 22 open-source microservice projects. Then we manually inspect the implementations of files and methods involved in cross-service clones to understand why the clones are introduced. In the file-level analysis, we categorize files into three types: DPFile (Data-processing File), DRFile (Data-related File), and DIFile (Data-irrelevant File), and have presented that DRFiles are more likely to encounter cross-service clones. For each type of files, we further classify them into specific cases. Each case describes the characteristics of involved files and why the clones happen. In the method-level analysis, we dig information from the code of involved methods. On this basis, we propose a catalog containing 4 categories with 10 subcategories of method-level implementations that result in cross-service clones. We believe our analyses have provided the fundamental knowledge of cross-service clones, which can help developers better manage and resolve such clones in microservice projects.

Bugs are usually in associations with other bugs in a software system, e.g., a bug may result from another bug.However, such bug associations are implicit and usually cannot be traced without a significant amount of effort.Intuitively, if a bug association is easier to trace, the involved bugs can be fixed in a cleaner way.However, there is little evidence on the explicitness of bug associations.In this paper, we aim to evaluate the explicitness of bug associations, so as to get a basic understanding on such associations.To this end, we defined a metric to quantify the explicitness of a bug association, and conducted an empirical study on 11 non-trivial Apache open source software systems.The main findings are summarized as follows: (1) From the perspective of code change history, around 29% of bug pairs are not explicitly associated, and about 71% are explicitly associated to some extent; (2) Bugs in the association of Container have relatively strong association explicitness, while bugs in the association of Blocked or Blocker, Cloners, and Dependent have relatively weak association explicitness.These findings provide insights on software analyzability to practitioners and researchers.

Architectural Technical Debt (ATD) refers to sub-optimal architectural design in a software system that incurs high maintenance “interest” over time. Previous research revealed thatATDhas significant negative impact on daily development. This paper contributes an approach to enable an architect to precisely locateATDs, as well as capture the trajectory of maintenance cost on each debt, based on which, predict the cost of the debt in a future release. TheATDsare expressed in four typical patterns, which entail the core of each debt. Furthermore, we aggregate compoundATDsto capture the complicated relationship among multipleATDinstances, which should be examined together for effective refactoring solutions. We evaluate our approach on 18 real-world projects. We identifiedATDsthatpersistentlyincur significant (up to 95 percent of) maintenance costs in most projects. The maintenance costs on the majority of debts fit into a linear regression model—indicating stable “interest” rate. In five projects, 12.1 to 27.6 percent of debts fit into an exponential model, indicating increasing “interest” rate, which deserve higher priority from architects. The regression models can accurately predict the costs of the majority of (82 to 100 percent) debts in the next release of a system. By aggregating relatedATDs, architects can focus on a small number of cost-effective compound debts, which contain a relatively small number of source files, but account for a large portion of maintenance costs in their projects. With these capabilities, our approach can help architects make informed decisions regarding whether, where, and how to refactor for eliminatingATDsin their systems.

In recent years, microservice architecture has been widely applied in software design. In addition, more and more monolithic software systems have been migrated into a microservice architecture. The core idea is to decompose the concerns of software projects into small and loosely-coupled services. Each service is supposed to be developed and even managed independently, which in turn improving the efficiency of development and maintenance. Code clone is common during software implementations, and many prior studies have revealed that code clones could cause maintenance difficulties. However, there is little work exploring the impacts of code clones on microservice projects. To bridge this gap, we focus on exploring the existence and co-modifications of within-service and cross-service code clones. With our evaluation of eight microservice projects, we have presented that there still exist code clones within services or across services. In addition, both within-service and cross-service code clones have been involved in co-modifications, meaning that these clones have caused maintenance difficulties. Finally, we have explored the characteristics of co-modifications in terms of changed LOC for both within-service and cross-service code clones.

Modern software systems, such as Spark, are usually written in multiple programming languages (PLs). Besides benefiting from code reuse, such systems can also take advantages of specific PLs to implement certain features, to meet various quality needs, and to improve development efficiency. In this context, a change to such systems may need to modify source files written in different PLs. We define a multi-programming-language commit (MPLC) in a version control system (e.g., Git) as a commit that involves modified source files written in two or more PLs. To our knowledge, the phenomenon of MPLCs in software development has not been explored yet. In light of the potential impact of MPLCs on development difficulty and software quality, we performed an empirical study to understand the state of MPLCs, their change complexity, as well as their impact on open time of issues and bug proneness of source files in real-life software projects. By exploring the MPLCs in 20 non-trivial Apache projects with 205,994 commits, we obtained the following findings: (1) 9% of the commits from all the projects are MPLCs, and the proportion of MPLCs in 80% of the projects goes to a relatively stable level; (2) more than 90% of the MPLCs from all the projects involve source files written in two PLs; (3) the change complexity of MPLCs is significantly higher than that of non-MPLCs in all projects; (4) issues fixed in MPLCs take significantly longer to be resolved than issues fixed in non-MPLCs in 80% of the projects; and (5) source files that have been modified in MPLCs tend to be more bug-prone than source files that have never been modified in MPLCs. These findings provide practitioners with useful insights on the architecture design and quality management of software systems written in multiple PLs.

Bug prediction is helpful for facilitating bug fixes and improving the efficiency in software development and maintenance. In the past decades, researchers have proposed numerous studies on bug prediction by using code metrics. However, most of the existing studies use syntax-based metrics, there exists little work building bug prediction models with semantic metrics from source code. In this paper, we propose a new model, semantic dependency graph (SDG), to represent semantic relationships among source files. Based on the SDG, we formally define a suite of semantic metrics reflecting semantic characteristics of a project’s source files. Moreover, we create a tool to automate the generation of our proposed SDG-based metrics. Through our experimental studies, we have demonstrated that the SDG-based semantic metrics are effective for building bug prediction models, and the SDG-based metrics outperform traditional syntactic metrics on bug prediction. In addition, models using the SDG-based metrics could achieve a better prediction performance than two state-of-the-art models that learn semantic features automatically. Finally, we have also presented that our approach is applicable in practice in terms of execution time and space.

Monolithic systems increasingly suffer from maintainability and scalability issues as they grow in functionality, size, and complexity. It is widely believed that (micro)service-based architectures can alleviate these problems as each service is supposed to have the following characteristics: clearly defined functionality, sufficient modularity, and the ability to evolve independently. Industrial practices show that service extraction from a legacy monolithic system is labor-intensive and complex. Existing work on service candidate identification aims to group entities of a monolithic system into potential service candidates, but this process has two major challenges: first, it is difficult to extract service candidates with consistent quality; second, it is hard to evaluate the identified service candidates regarding the above three characteristics. To address these challenges, this paper proposes the Functionality-oriented Service Candidate Identification (FoSCI) framework to identify service candidates from a monolithic system. Our approach is to record the monolith's execution traces, and extract services candidates using a search-based functional atom grouping algorithm. We also contribute a comprehensive service candidate evaluation suite that uses interface information, structural/conceptual dependency, and commit history. This evaluation system consists of 8 metrics, measuring functionality, modularity, and evolvability respectively of identified service candidates. We compare FoSCI with three existing methods, using 6 widely-used open-source projects as our evaluation subjects. Our results show that FoSCI outperforms existing methods in most measures.

In large-scale software systems, error-prone or change-prone files rarely stand alone. They are typically architecturally connected and their connections usually exhibit architecture problems causing the propagation of error-proneness or change-proneness. In this paper, we propose and empirically validate a suite of architecture anti-patterns that occur in all large-scale software systems and are involved in high maintenance costs. We define these architecture anti-patterns based on fundamental design principles and Baldwin and Clark's design rule theory. We can automatically detect these anti-patterns by analyzing a project's structural relationships and revision history. Through our analyses of 19 large-scale software projects, we demonstrate that these architecture anti-patterns have significant impact on files' bug-proneness and change-proneness. In particular, we show that 1) files involved in these architecture anti-patterns are more error-prone and change-prone; 2) the more anti-patterns a file is involved in, the more error-prone and change-prone it is; and 3) while all of our defined architecture anti-patterns contribute to file's error-proneness and change-proneness, Unstable Interface and Crossing contribute the most by far.

Defect technical debt (defect debt) refers to known deferred bugs that have not been fixed. The interest of a defect debt item (i.e., bug) is the extra effort needed to fix the bug due to the delay of fixing. It is important to measure defect debt interest in a software system in order to be aware of how much the interest of certain bugs is and which bugs should be fixed first. Furthermore, it is valuable to understand the features of the bugs of high interest or no interest, so as to facilitate the identification of those kinds of bugs. In this work, we proposed three pairs of measures for quantifying defect debt interest at three granularities (i.e., lines of code, source file, and package) of software changes, and conducted an exploratory case study on 13,438 bugs collected from 59 non-trivial Apache open source software projects written mainly in Java. We have the following findings. (1) Each bug, with an average of 224 days delay of fixing, has interest of 660 to 845 lines of code, 0.57 to 1.05 source files, and 0.29 to 0.35 package on average in need for understanding or modifying when fixing the bug. (2) The average interest of a bug shows overall increasing trends over delayed time of bug fixing and bug priority levels from the lowest to highest. (3) Around 30% of the bugs under study did not incur interest at the granularity of lines of code, which means that the involved source files in the bug-fixing commits of such bugs were not modified at all during the delayed time of bug fixing. (4) The average code change size of bug-fixing commits of a bug without interest is much smaller than that of a bug with (high) interest; for a bug without interest at the granularity of lines of code, the source files involved in the bug-fixing commits of the bug were alternately modified by different committers much less frequently than those of the bug with (high) interest.

Both complexity of code change for bug fixing and bug severity play an important role in release planning when considering which bugs should be fixed in a specific release under certain constraints. This work investigates whether there are significant differences between bugs of different severity levels regarding the complexity of code change for fixing the bugs. Code change complexity is measured by the number of modified lines of code, source files, and packages, as well as the entropy of code change. We performed a case study on 20 Apache open source software (OSS) projects using commit records and bug reports. The study results show that (1) for bugs of high severity levels (i.e. Blocker, Critical and Major in JIRA), there is no significant difference on the complexity of code change for fixing bugs of different severity levels for most projects, while (2) for bugs of low severity levels (i.e. Major, Minor and Trivial in JIRA), fixing bugs of a higher severity level needs significantly more complex code change than fixing bugs of a lower severity level for most projects. These findings provide useful and practical insights for effort estimation and release planning of OSS development.

During software evolution, files are usually changed together for accommodating modifications. Although co-change analysis has been widely adopted for difference studies, such as defect prediction, impact analysis, architectural relations identification etc., there has been little work characterizing co-changed files as a group and modeling the evolution of these files to represent software maintenance and evolution. In this paper, we present the concept of history coupling dependency, based on which, we propose a novel model, history coupling space (HCSpace), to link the co-changed files and represent how files are historically connected as a group. Our investigations on seven open source projects show that each HCSpace could be treated as a maintenance unit where the involved files are more likely to evolve together. The results also show that the HCSpaces have important impacts on a project's maintenance. In particular, we demonstrate that identified HCSpaces consumes a relatively large portion of maintenance effort spent on a project, and these HCSpaces are still actively evolving.

In this paper, we propose an architecture model called Design Rule Space (DRSpace). We model the architecture of a software system as multiple overlapping DRSpaces, reflecting the fact that any complex software system must contain multiple aspects, features, patterns, etc. We show that this model provides new ways to analyze software quality. In particular, we introduce an Architecture Root detection algorithm that captures DRSpaces containing large numbers of a project's bug-prone files, which are called Architecture Roots (ArchRoots). After investigating ArchRoots calculated from 15 open source projects, the following observations become clear: from 35 to 91 percent of a project's most bug-prone files can be captured by just 5 ArchRoots, meaning that bug-prone files are likely to be architecturally connected. Furthermore, these ArchRoots tend to live in the system for significant periods of time, serving as the major source of bug-proneness and high maintainability costs. Moreover, each ArchRoot reveals multiple architectural flaws that propagate bugs among files and this will incur high maintenance costs over time. The implication of our study is that the quality, in terms of bug-proneness, of a large, complex software project cannot be fundamentally improved without first fixing its architectural flaws.

Background: Though much research has been conducted to investigate software maintenance activities, there has been little work charactering maintenance files as a community and exploring the evolution of this community. Aims: The goal of our research is to identify maintenance communities and monitor their evolution-birth, growth, death and rejuvenation. Method: In this paper, we leveraged a social community detection algorithm---clique prelocation method (CPM)---to identify file communities. Then we implemented an algorithm to detect new communities, active communities, inactive communities and reactivated communities by cumulatively detecting and constantly comparing communities in time sequences. Results: Based on our analysis of 14 open-source projects, we found that new communities are mostly caused by bug and improvement issues. An active community can be vigorous, on and off, through the entire life of a system, and so does an inactive community. In addition, an inactive community can be reactivated again, mostly through bug issues. Conclusions: These findings add to our understanding of software maintenance communities and help us identify the most expensive maintenance spots by identifying constantly active communities.

In large-scale software systems, the majority of defective files are architecturally connected, and the architecture connections usually exhibit design flaws, which are associated with higher change-proneness among files and higher maintenance costs. As software evolves with bug fixes, new features, or improvements, unresolved architecture design flaws can contribute to maintenance difficulties. The impact on effort due to architecture design flaws has been difficult to quantify and justify. In this paper, we conducted a case study where we identified flawed architecture relations and quantified their effects on maintenance activities. Using data from this project's source code and revision history, we identified file groups where files are architecturally connected and participated in flawed architecture designs, quantified the maintenance activities in the detected files, and assessed the penalty related to these files.

Enabling rapid feature delivery is essential for product success and is therefore a goal of software architecture design. But how can we determine if and to what extent an architecture is "good enough" to support feature addition and evolution, or determine if a refactoring effort is successful in that features can be added more easily? In this paper, we contribute a concept called the Feature Space, and a formal definition of Feature Dependency, derived from a software project's revision history. We capture the dependency relations among the features of a system in a feature dependency structure matrix (FDSM), using features as first-class design elements. We also propose a Feature Decoupling Level (FDL) metric that can be used to measure the level of independence among features. Our investigation of 17 open source projects shows that files within each feature space are much more likely to be changed together, hence each feature space forms a meaningful maintainable unit that should be treated separately. The data also show that the history-based FDL is highly correlated a structure-based maintainability metric: Decoupling Level (DL). When we examine a project's evolution history, we see that if a system is well-modularized, it is more likely that features can be added independently. For shorter periods of time, however, FDL and DL may not be consistent, e.g., when the addition of new features deviates from the designed architecture or does not involve parts of the system that have architecture flaws. In such cases, FDL and FDSM can be used to monitor potential architecture degradation caused by improper feature addition.

In this paper, we report our experiences of applying three complementary automated software architecture analysis techniques, supported by a tool suite, called DV8, to 8 industrial projects within a large company. DV8 includes two state-of-the-art architecture-level maintainability metrics—Decoupling Level and Propagation Cost, an architecture flaw detection tool, and an architecture root detection tool. We collected development process data from the project teams as input to these tools, reported the results back to the practitioners, and followed up with telephone conferences and interviews. Our experiences revealed that the metrics scores, quantitative debt analysis, and architecture flaw visualization can effectively bridge the gap between management and development, help them decide if, when, and where to refactor. In particular, the metrics scores, compared against industrial benchmarks, faithfully reflected the practitioners’ intuitions about the maintainability of their projects, and enabled them to better understand the maintainability relative to other projects internal to their company, and to other industrial products. The automatically detected architecture flaws and roots enabled the practitioners to precisely pinpoint, visualize, and quantify the “hotspots" within the systems that are responsible for high maintenance costs. Except for the two smallest projects for which both architecture metrics indicated high maintainability, all other projects are planning or have already begun refactorings to address the problems detected by our analyses. We are working on further automating the tool chain, and transforming the analysis suite into deployable services accessible by all projects within the company.

Despite decades of research on software metrics, we still cannot reliably measure if one design is more maintainable than another. Software managers and architects need to understand whether their software architecture is "good enough", whether it is decaying over time and, if so, by how much. In this paper, we contribute a new architecture maintainability metric---Decoupling Level (DL)---derived from Baldwin and Clark's option theory. Instead of measuring how coupled an architecture is, we measure how well the software can be decoupled into small and independently replaceable modules. We measured the DL for 108 open source projects and 21 industrial projects, each of which has multiple releases. Our main result shows that the larger the DL, the better the architecture. By "better" we mean: the more likely bugs and changes can be localized and separated, and the more likely that developers can make changes independently. The DL metric also opens the possibility of quantifying canonical principles of single responsibility and separation of concerns, aiding cross-project comparison and architecture decay monitoring.

Our prior work showed that the majority of error-prone source files in a software system are architecturally connected. Flawed architectural relations propagate defects among these files and accumulate high maintenance costs over time, just like debts accumulate interest. We model groups of architecturally connected files that accumulate high maintenance costs as architectural debts. To quantify such debts, we formally define architectural debt, and show how to automatically identify debts, quantify their maintenance costs, and model these costs over time. We describe a novel history coupling probability matrix for this purpose, and identify architecture debts using 4 patterns of architectural flaws shown to correlate with reduced software quality. We evaluate our approach on 7 large-scale open source projects, and show that a significant portion of total project maintenance effort is consumed by paying interest on architectural debts. The top 5 architectural debts, covering a small portion (8% to 25%) of each project's error-prone files, capture a significant portion (20% to 61%) of each project's maintenance effort. Finally, we show that our approach reveals how architectural issues evolve into debts over time.

Recently there has been increased attention to the consequences of architecture design decisions and their impact on security. Architectural design decisions have been identified as being critical for achieving high levels of software system security. However the majority of this research has been anecdotal and there are few tools or methods for understanding the architectural relations among files, and their impact on security. In this paper we employ a DRSpace-based analysis approach to identify architectural design flaws and we show, via an empirical study of 10 open source projects, that areas of a software architecture that suffer from greater numbers of design flaws are highly correlated with security bugs, and high levels of churn associated with those security bugs. Finally, we show that a specific type of design flaw -- unstable interface -- is correlated with the greatest increase in software security bugs.

Our recent research has shown that, in large-scale software systems, defective files seldom exist alone. They are usually architecturally connected, and their architectural structures exhibit significant design flaws which propagate bugginess among files. We call these flawed structures the architecture roots, a type of technical debt that incurs high maintenance penalties. Removing the architecture roots of bugginess requires refactoring, but the benefits of refactoring have historically been difficult for architects to quantify or justify. In this paper, we present a case study of identifying and quantifying such architecture debts in a large-scale industrial software project. Our approach is to model and analyze software architecture as a set of design rule spaces (DRSpaces). Using data extracted from the project's development artifacts, we were able to identify the files implicated in architecture flaws and suggest refactorings based on removing these flaws. Then we built economic models of the before and (predicted) after states, which gave the organization confidence that doing the refactorings made business sense, in terms of a handsome return on investment.

In this paper, we propose and empirically validate a suite of hotspot patterns: recurring architecture problems that occur in most complex systems and incur high maintenance costs. In particular, we introduce two novel hotspot patterns, Unstable Interface and Implicit Cross-module Dependency. These patterns are defined based on Baldwin and Clark's design rule theory, and detected by the combination of history and architecture information. Through our tool-supported evaluations, we show that these patterns not only identify the most error-prone and change-prone files, they also pinpoint specific architecture problems that may be the root causes of bug-proneness and change-proneness. Significantly, we show that 1) these structure-history integrated patterns contribute more to error- and change-proneness than other hotspot patterns, and 2) the more hotspot patterns a file is involved in, the more error- and change-prone it is. Finally, we report on an industrial case study to demonstrate the practicality of these hotspot patterns. The architect and developers confirmed that our hotspot detector discovered the majority of the architecture problems causing maintenance pain, and they have started to improve the system's maintainability by refactoring and fixing the identified architecture issues.