In this paper, we investigate software architecture as a set of overlapping design rule spaces, formed by one or more structural or evolutionary relationships and clustered using our design rule hierarchy algorithm. Considering evolutionary coupling as a special type of relationship, we investigated (1) whether design rule spaces can reveal structural relations among error-prone files; (2) whether design rule spaces can reveal structural problems contributing to error-proneness. We studied three large-scale open source projects and found that error-prone files can be captured by just a few design rule sub-spaces. Supported by our tool, Titan, we are able to flexibly visualize design rule spaces formed by different types of relationships, including evolutionary dependencies. This way, we are not only able to visualize which error-prone files belong to which design rule spaces, but also to visualize the structural problems that give insight into why these files are error prone. Design rule spaces provide valuable direction on which parts of the architecture are problematic, and on why, when, and how to refactor.
Designers often seek modular architectures to better accommodate expected changes and to enable parallel development. However, we lack a formal theory and model of modularity and software evolution, which can be used for description, prediction, and prescription. According to Baldwin and Clark’s theory, modular architectures add value to system designs by creating options to improvethe system by substituting or experimenting on individual modules. In this paper, we evaluate their theory by looking at the design evolution of two software product platforms through the modeling lens of design structure matrices (DSMs) and design rule theory. Our analysis shows that DSM models and options theory can explain how real-world modularization activities in one case allowed for different rates of evolution in different software modules and in another case conferred distinct strategic advantages on a firm (by permitting substitution of an at-risk software module without substantial change to the rest of the system). The experiment supports our hypothesis that these formal models and theory can account for important aspects of software design evolution in large-scale systems.
Our research goal is to develop a decision-support system that would allow managers to play out various “what-if” scenarios to manage modularity debt and make informed decisions regarding refactoring. A decision-support system approach would appropriately address the need to simulate and visualize scenarios that include many different (current and future) factors under different assumptions that may affect the decision outcome. Our proposed system is called the modularity debt management decision-support system (MDM-DSS). Our MDM-DSS is built on a scientific foundation that we are constructing for explicitly manifesting the economic implications of software modularization activities, so that the costs and the benefits of such activities can be understood, analyzed, and predicted in a way that is amenable to both engineers and managers. The research questions being addressed include: how to manifest the costs and benefits of modularization activities as functions of modularity variations; how to locate the components with the most uncertainty and risk; how to determine that there is a debt; how to quantitatively account for the relation between modularization activities and their economic consequences; and, in particular, how to manifest the value of modularity as options so as to plan an optimal strategy of evolution based on viewing software as investment?
In addressing these research questions, we have developed an integrated economics-driven modularization evaluation (IEDME) framework that combines code-level analysis, design-level analysis, expert stakeholder elicitation, and history-based cost-benefit analysis. This framework links measures of modularity with quantified economic benefits—that is, maintenance cost-savings—to serve as the foundation of our target MDM-DSS. In what follows, we present the design considerations for the MDM-DSS.