TL;DR: A novel, network-based methodology based on statistically robust structural analysis of class collaboration networks whose nodes are enriched with both software metrics and domain-independent metrics used in analysis of complex networks indicates that high structural class coupling in real software systems cannot be accurately modeled by power-law distributions.
Abstract: Understanding coupling between classes in object-oriented (OO) software systems is useful for a variety of software development and maintenance activities. In this paper we propose a novel, network-based methodology to analyze high structural class coupling in OO software systems. The proposed methodology is based on statistically robust structural analysis of class collaboration networks whose nodes are enriched with both software metrics and domain-independent metrics used in analysis of complex networks. To demonstrate the usefulness of the methodology we analyze five open-source, large-scale software systems written in Java. Contrary to frequently reported findings, the obtained results indicate that high structural class coupling in real software systems cannot be accurately modeled by power-law distributions. Our analysis also shows that highly-coupled classes tend to be significantly more voluminous and functionally important compared to loosely coupled classes, and do not tend to be localized in class inheritance hierarchies. Finally, in four out of five analyzed systems highly coupled classes tend to have drastically higher afferent than efferent coupling. This implies that the existence of high class coupling in an OO software system would rather indicate negative aspects of extensive internal class reuse than negative aspects of extensive internal class aggregation.
TL;DR: The aim in this paper is to present an initial investigation about the applicability of this concern-based cohesion metric as a change proneness indicator, and to check if this metric has a correlation with efferent coupling.
Abstract: Structure-based cohesion metrics, such as the well-known Chidamber and Kemerer's Lack of Cohesion in Methods (LCOM), fail to capture the semantic notion of a software component's cohesion. Some researchers claim that it is one of the reasons they are not good indicators of change proneness. The Lack of Concern-based Cohesion metric (LCC) is an alternative cohesion metric which is centered on counting the number of concerns a component implements. A concern is any important concept, feature, property or area of interest of a system that we want to treat in a modular way. In this way, LCC focus on what really matters for assessing a component's cohesion - the amount of responsibilities placed on them. Our aim in this paper is to present an initial investigation about the applicability of this concern-based cohesion metric as a change proneness indicator. We also checked if this metric has a correlation with efferent coupling. An initial empirical assessment work was done with two small to medium-sized systems. Our results indicated a moderate to strong correlation between LCC and change proneness, and also a strong correlation between LCC and efferent coupling.
TL;DR: A prediction model using these metrics to predict faults by using multivariate logistic linear regression and results indicate that the efferent coupling (Ce) is a better indicator for fault prediction than afferent coupling and CBO (coupling between object).
Abstract: Software product's quality is one of the important aspects that affect the user, the developer, and the product. Measuring quality in the early phases of the project life cycle is a major goal of project planning. Accordingly, several research studies have been proposed to measure the software product quality attributes. In this paper, we empirically study the impact of afferent coupling (Ca), efferent coupling (Ce) and coupling between object (CBO) metrics on fault prediction using bivariate correlation. We built a prediction model using these metrics to predict faults by using multivariate logistic linear regression. A case study of an open source object oriented systems is used to evaluate the correlation between coupling metrics and faults. The results indicate that the efferent coupling (Ce) is a better indicator for fault prediction than afferent coupling (Ca) and CBO (coupling between object)
TL;DR: Results showed that design pattern participant classes were marginally more fault-prone than non-participant classes, and The Adaptor, Method and Singleton patterns were found to be the most fault- prone of thirteen patterns explored.
Abstract: This paper documents a study of fault proneness in commercial, proprietary software and attempts to determine whether a relationship exists between class faults and the design context of a class, namely the coupling and cohesion of a class, and whether the class is a participant of common design patterns. The authors studied a commercial software system for a 24 month period and identified design pattern participants by inspecting the design documentation and source code; coupling and cohesion metrics were measured by inspecting the source code with a tool; we also extracted fault data for the same period to determine whether a relationship existed between the design context and the fault propensity of a class. Results showed that design pattern participant classes were marginally more fault-prone than non-participant classes, The Adaptor, Method and Singleton patterns were found to be the most fault-prone of thirteen patterns explored. Coupling was found to have a significant relationship with the fault proneness of classes in the system; efferent coupling was a stronger indicator of fault propensity than afferent coupling. Cohesion, when measured using the LCOMHS metric, was not found to have a strong relationship with fault proneness.
TL;DR: It is concluded that software architects and engineers should concentrate more efforts to produce low instability software since first version, because the most of software keep the instability level through the releases.
Abstract: Software instability measures indicate the necessity to modify a software module (class, package, subsystem, etc) due to changes in other related software entities. If there is low instability, then there is evidence the analyzed entity has little dependence on others and the project has a good maintainability. Otherwise, there is evidence that the analyzed entity is sensitive to changes occurred in other entities. In the latter case, software reconstruction could be necessary and the maintainability becomes harder because of dependencies. Consequently, the higher the value of instability in an entity the more vulnerable it is to unexpected changes, even if the entity does not suffer direct changes in its code. This article adopts the instability definition of Martin [1] that depends on the afferent (Ca) and efferent (Ce) coupling metrics. It presents a Systematic Literature Review (SLR) of Martin's instability looking for reference values published in scientific articles and practiced in the open source market. Furthermore, this article analyzes the Martin's instability equation and the evolution of Ca, Ce and instability through new releases of 107 software. Authors applied a systematic literature review (SLR), and observed that there is a shortage of reference values in scientific articles. They performed a statistical analysis of instability measures in 107 free software products, involving three different versions of each, totaling 321 product versions. It was not possible determine or suggest a reference value to Ca, Ce and instability measures due to the high variation of those measures. It was observed that 48% of software products had high instability equal to 1, the maximum value allowed, and the instability average obtained was 0.7. Based on results of this paper, we conclude that software architects and engineers should concentrate more efforts to produce low instability software since first version, because the most of software keep the instability level through the releases. More analysis is necessary to confirm this behavior about software instability through releases.