Architectural decay imposes real costs in terms of developer effort, system correctness, and performance. Over time, those problems are likely to be revealed as explicit implementation issues (defects, feature changes, etc.). Recent empirical studies have demonstrated that there is a significant correlation between architectural "smells"—manifestations of architectural decay—and implementation issues. In this paper, we take a step further in exploring this phenomenon. We analyze the available development data from 10 open-source software systems and show that information regarding current architectural decay in these systems can be used to build models that accurately predict future issue-proneness and change-proneness of the systems’ implementations. As a less intuitive result, we also show that, in cases where historical data for a system is unavailable, such data from other, unrelated systems can provide reasonably accurate issue- and change-proneness prediction capabilities.

This paper identifies a model of software evolution that is prevalent in large, long-lived academic research tool suites (3L-ARTS). This model results in an "archipelago" of related but haphazardly organized architectural "islands", and inherently induces technical debt. We illustrate the archipelago model with examples from two 3L-ARTS archipelagos identified in literature.

This paper presents the design, implementation, and usage details of ARCADE, an extensible workbench for supporting the recovery of software systems' architectures, and for evaluating architectural change and decay. ARCADE has been developed and maintained over the past decade, and has been deployed in a number of research labs as well as within three large companies. ARCADE's implementation is available at https://bitbucket.org/joshuaga/arcade and the video depicting its use at https://tinyurl.com/arcade-tool-demo.

Architecture is the set of principal design decisions about a software system. In practice, new architectural decisions are added and existing ones reversed or modified throughout a system's lifetime. Frequently, these decisions deviate from the architect's well-considered intent, and software systems regularly exhibit increased architectural decay as they evolve. The manifestations of such ill-considered design decisions are seen as “architectural smells”. To date, there has been no in-depth study of the characteristics or trends involving this phenomenon. Instead, when referring to architectural smells and their negative effects, both researchers and practitioners had to rely on folklore and their personal, inherently limited experience. In this paper, we report on the systematic step we have taken in investigating the nature and impact of architectural smells. We have selected a set of representative architectural smells from literature and analyzed their instances in 421 versions from 8 open-source software systems. We have (1) developed algorithms to automatically detect instances of multiple architectural smell types, and (2) analyzed relationships between the detected smells and the lists of issues reported in the systems' respective issue trackers. Our study shows that architectural smells have tangible negative consequences in the form of implementation issues as well as code commits requiring increased maintenance effort throughout a system's lifetime.

Designing and maintaining a software system's architecture typically involve making numerous design decisions, each potentially affecting the system's functional and nonfunctional properties. Understanding these design decisions can help inform future decisions and implementation choices and can avoid introducing regressions and architectural inefficiencies later. Unfortunately, design decisions are rarely well documented and are typically a lost artifact of the architecture creation and maintenance process. The loss of this information can thus hurt development. To address this shortcoming, we develop RecovAr, a technique for automatically recovering design decisions from the project's readily available history artifacts, such as an issue tracker and version control repository. RecovAr uses state-of-the-art architectural recovery techniques on a series of version control commits and maps those commits to issues to identify decisions that affect system architecture. While some decisions can still be lost through this process, our evaluation on Hadoop and Struts, two large open-source systems with over 8 years of development each and, on average, more than 1 million lines of code, shows that RecovAr has the recall of 75% and a precision of 77%. Our work formally defines architectural design decisions and develops an approach for tracing such decisions in project histories. Additionally, the work introduces methods to classify whether decisions are architectural and to map decisions to code elements. Finally, our work contributes a methodology engineers can follow to preserve design-decision knowledge in their projects.

Ensuring the longevity of a software system is an important concern for developers and maintainers. However, when a system's architecture decays during evolution and its quality degrades as a result, the system's long-term sustainability is highly affected. In this light, providing mediums to estimate and track the sustainability of a software system is necessary to help engineers stay aware of system health. Most existing techniques and tools estimate the level of sustainability in code, paying significantly less attention to the analysis and understanding of architectural decay. This position paper provides a taxonomy of architectural smells, metrics, and their impacted quality properties. We relate these smells to maintenance and evolution areas as a first step toward our ultimate goal of estimating the sustainability of systems. We finally report some initial results drawn from a set of subject systems as promising future work using our taxonomy.

From its very inception, the study of software architecture has recognized architectural decay as a regularly occurring phenomenon in long-lived systems. Architectural decay is caused by repeated changes to a system during its lifespan. Despite decay's prevalence, there is a relative dearth of empirical data regarding the nature of architectural changes that may lead to decay, and of developers' understanding of those changes. In this paper, we take a step toward addressing that scarcity by conducting an empirical study of changes found in software architectures spanning several hundred versions of 14 open-source systems. Our study reveals several new findings regarding the frequency of architectural changes in software systems, the common points of departure in a system's architecture during maintenance and evolution, the difference between system-level and component-level architectural change, and the suitability of a system's implementation-level structure as a proxy for its architecture.