Understanding the Causes of Architecture Changes Using OSS Mailing Lists

Abstract

The causes of architecture changes can tell about why architecture changes, and this knowledge can be captured to prevent architecture knowledge vaporization and architecture degeneration. But the causes are not always known, especially in open source software (OSS) development. This makes it very hard to understand the underlying reasons for the architecture changes and design appropriate modifications. Architecture information is communicated in development mailing lists of OSS projects. To explore the possibility of identifying and understanding the causes of architecture changes, we conducted an empirical study to analyze architecture information (i.e., architectural threads) communicated in the development mailing lists of two popular OSS projects: Hibernate and ArgoUML, verified architecture changes with source code, and identified the causes of architecture changes from the communicated architecture information. The main findings of this study are: (1) architecture information communicated in OSS mailing lists does lead to architecture changes in code; (2) the major cause for architecture changes in both Hibernate and ArgoUML is preventative changes, and the causes of architecture changes are further classified to functional requirement, external quality requirement, and internal quality requirement using the coding techniques of grounded theory; (3) more than 45% of architecture changes in both projects happened before the first stable version was released. * This paper is an enhanced version of our previous paper "Causes of Architecture Changes: An Empirical

Architecture information communication in two OSS projects: The why, who, when, and what

“…For example, the amount of architectural threads communicated before the first stable release in ArgoUML is 65.2% and after the first stable release in Hibernate is 88.4%. In our previous work [15], we found that 89.1% architecture changes happened before the first stable release in ArgoUML and 54.3% architecture changes happened after the first stable release in Hibernate, which is positively related to the results of RQ3. Architecture information communication precedes architecture changes, and consequently the amount of architecture information communication indicates the frequency of architecture changes.…”

“…Requirements and architecture were discussed at different abstraction levels, and consequently we classified the 23 discussion subtopics into four categories: architecture topic (i.e., specific design topics about the architecture), abstraction level (i.e., the level of the architecture artifacts discussed in architecture information communication), external quality requirement (i.e., the quality characteristics of a system from the perspective of its users satisfied by architecture changes), and internal quality requirement (i.e., the quality characteristics of a system from the perspective of its developers satisfied by architecture changes). Table 5 provides the detailed descriptions and examples of the 4 categories and 23 subtopics, which are an extension of the codes identified in our previous work that specifically focuses on the causes of architecture changes communicated in mailing lists [15]. The percentages of each subtopic (i.e., content of architecture information communication) communicated in architectural threads before and after the first stable release (BFR and AFR) in ArgoUML and Hibernate are shown in Fig.…”

“…11). An example in ArgoUML, developers recommended to use generic controls with reflection mechanism in plain Java to make their code easy to maintain ("Conciseness") when employing the UML data model provided by NSUML ("Adaptive environment") 15 . An example in Hibernate, to add new Dialects in Hibernate, developers discussed whether to integrate a new class org.hibernate.dialect.HiRDDialect ("New component") into Hibernate or use an "extras" module that can encapsulate code ("Modularity") 16 .…”