An Empirical Study of the Interplay between Architecture and Software Quality using Evolutionary History of Software

AN EMPIRICAL STUDY OF THE INTERPLAY BETWEEN ARCHITECTURE AND SOFTWARE QUALITY USING EVOLUTIONARY HISTORY OF SOFTWARE Ehsan Kouroshfar, PhD George Mason University, 2016 Dissertation Director: Dr. Paul Ammann Conventional wisdom suggests that a software system’s architecture has a significant impact on its evolution. Well-designed software architecture employs the principle of separation of concern to allocate different functionalities and responsibilities to different architectural elements comprising the system [42, 49] and it is easier to make changes to a software system that has a well-designed architecture. Conversely, bad architecture, manifested as architectural bad smells [42], can increase the complexity, possibly leading to poor software quality [49]. However, a software system’s architecture is known to commonly undergo the phenomenon of architectural decay [82], where changes and design decisions are added to the system which may break the initially designed system’s software architecture. Architectural decay has a negative impact on maintaining the system and results in defects and architectural problems in the system. Thus detecting and preferably avoiding decay will save considerable time and other resources from developers and stakeholders in a system. This dissertation targets empirical research in the domain of architecture-based software maintenance. It benefits from both fields of software architecture and mining software repository. The mining software repository (MSR) field investigates the rich data in source code repositories and defect repositories to uncover interesting information about software systems. For example data in source code repositories can be linked with data in defect repositories to observe what kind of changes would result in more defects. This would help to warn practitioners and developers about risky changes based on prior changes and faults. In this research, I first investigate the impact of software architecture on defects from evolutionary history of software. To do that, I designed an empirical study to see whether there is a difference between types of changes made to a software system from software architecture perspective. Specifically I wanted to investigate the impact of co-changes involving several architectural modules versus co-changes localized within a single module. This provided empirical evidence for the importance of considering of software architecture while making changes to a system. Next, I construct novel models that predict the quality of an architectural element by utilizing multiple architectural views (both structural and semantic) and architectural metrics as features for prediction. Using these models, I accurately predict low architectural quality, i.e., architectural decay in software systems. Engineers can significantly benefit from determining which architectural elements will decay before that decay actually occurs. Forecasting decay allows engineers to take steps to prevent decay, such as focusing maintenance resources on the architectural elements most likely to decay. This research underlines the importance of software architecture in the construction and maintenance of software. Chapter 1: Introduction Software maintenance is a set of activities associated with the modification of a software product after it has been delivered to end-users. These activities include modifications made to fix defects (corrective maintenance), modifications performed to cope with changes in the software environment (adaptive maintenance) and modifications that address new requirements or improve software quality (perfective maintenance). Maintaining large software systems is hard and expensive. Making post release changes requires not only the understanding of the part of the system that needs to be changed but also the impact of the changes to its dependencies that might be affected by the change. Software engineers have developed numerous abstractions to deal with the complexity of implementing and maintaining software systems. One of those abstractions is software architecture, which is particularly effective for reasoning about the system’s structure, its constituent elements and the relationships among them. Software architecture enables the engineers to reason about the functionality and properties of a software system without getting involved in low-level source code and implementation details. At the outset of any large-scale software construction project is an architectural design phase. The architecture produced at this stage is often in the form of Module View [22], representing the decomposition of the software system into its implementation units, called architectural modules, and the dependencies among them1. This architecture serves as a high-level blueprint for the system’s implementation and maintenance activities. Well-designed software architecture employs the principle of separation of concern to The notion of architectural module should not be confused with module traditionally used in the literature to refer to files or classes. Here, I use the notion of module to mean architecturally significant implementation artifacts, as opposed to its typical meaning in the programming languages. Architectural modules represent the construction units (subsystems), and therefore, are also different from software components that represent the runtime units of computation in the Component-Connector View [22].