The first goal of this paper is to empirically explore the relationships between existing object-oriented coupling, cohesion, and inheritance measures and the probability of fault detection in system classes during testing. In other words, we wish to better understand the relationship between existing design measurement in OO systems and the quality of the software developed. The second goal is to propose an investigation and analysis strategy to make these kind of studies more repeatable and comparable, a problem which is pervasive in the literature on quality measurement. Results show that many of the measures capture similar dimensions in the data set, thus reflecting the fact that many of them are based on similar principles and hypotheses. However, it is shown that by using a subset of measures, accurate models can be built to predict which classes contain most of the existing faults. When predicting fault-prone classes, the best model shows a percentage of correct clas...

Contemporary evidence suggests that most field faults in software applications are found in a smafi percentage of the software's components. This means that if these faulty software components can be detected early in the development project's life cycle, mitigating actions can be taken, such as a redesign. For object-oriented applications, prediction models using design metrics can be used to identify faulty classes early on. In this paper we report on a study that used object-oriented design metrics to construct such prediction models. The study used data collected from one version of a commercial Java application for constructing a prediction model. The model was then validated on a subsequent release of the same application. Our results indicate that the prediction model has a high accuracy. Furthermore, we found that an export coupling metric had the strongest association with faultproneness, indicating a structural feature that may be symptomatic of a class with a high probability of latent faults.

In the context of software cost estimation, system size is widely taken as a main driver of system development effort. But, other structural design properties, such as coupling, cohesion, and complexity, have been suggested as additional cost factors. In this paper, using effort data from an object-oriented development project, we empirically investigate the relationship between class size and the development effort for a class and what additional impact structural properties such as class coupling have on effort. This paper proposes a practical, repeatable, and accurate analysis procedure to investigate relationships between structural properties and development effort. This is particularly important as it is necessary, as for any empirical study, to be able to replicate the analysis reported here. More specifically, we use Poisson regression and regression trees to build cost prediction models from size and design measures and use these models to predict system development effort. We also investigate a recently suggested technique to combine regression trees with regression analysis which aims at building more accurate models. Results indicate that fairly accurate predictions of class effort can be made based on simple measures of the class interface size alone (mean MREs below 30 percent). Effort predictions at the system level are even more accurate as, using Bootstrapping, the estimated 95 percent confidence interval for MREs is 3 to 23 percent. But, more sophisticated coupling and cohesion measures do not help to improve these predictions to a degree that would be practically significant. However, the use of hybrid models combining Poisson regression and CART regression trees clearly improves the accuracy of the models as compared to using Poisson regression alone.

The quality of a design has a decisive impact on the quality of a software product; but due to the diversity and complexity of design properties (e.g., coupling, encapsulation), their assessment and correlation with external quality attributes (e.g., maintenance, portability) is hard. In contrast to traditional quality models that express the “goodness ” of design in terms of a set of metrics, the novel Factor-Strategy model proposed by this paper, relates explicitly the quality of a design to its conformance with a set of essential principles, rules and heuristics. This model is based on a novel mechanism, called detection strategy, that raises the abstraction level in dealing with metrics, by allowing to formulate good-design rules and heuristics in a quantifiable manner, and to detect automatically deviations from these rules. This quality model provides a twofold advantage: (i) an easier construction and understanding of the model as quality is put in connection with design principles rather than “raw numbers”; and (ii) a direct identification of the real causes of quality flaws. We have validated the approach through a comparative analysis involving two versions of a industrial software system.

This paper presents an approach to build and visualize traceability links and properties of a set of OO software releases. The process recovers an "as is" design from C++ software releases, compares recovered designs at the class interface level, and helps the user to deal with inconsistencies by pointing out regions of code where differences are concentrated. The comparison process exploits edit distance and a maximum match algorithm and has been experimented with 9 releases of a library of foundation classes. Results as well as consideration related to presentation issues are reported in the paper.

In order to compute metrics automatically, these must be implemented as software programs. As metrics become increasingly complex, implementing them using imperative and interrogative programming is oftentimes cumbersome. Consequently, their understanding, testing and reuse are severely hampered. In this paper we identify a set of key mechanisms that are involved in the implementation of design metrics and, more general, of design-related structural analyses: navigation, selection, set arithmetic, filtering and property aggregation. We show that neither of the aforementioned approaches offers a simple support for all these mechanisms and, as a result, an undesirable overhead of complexity is added to the implementation of metrics. The paper introduces SAIL, a language designed to offer a proper support to a simplified writing of design metrics and similar design-related analyses, with a especial emphasis on object-oriented design. In order to validate the expressiveness of SAIL the paper provides a comprehensive comparison with the other two approaches. 1

In this paper we consider empirical evidence in support of a set of object-oriented software metrics. In particular, we look at the object oriented design metrics of Chidamber and Kemerer, and their applicability in different application domains. We briefly describe the metrics, and present our empirical findings, arising from our analysis of systems taken from a number of different application domains. Our investigations have led us to conclude that a subset of the metrics can be of great value to software developers, maintainers and project managers.

This paper aims at empirically exploring the relationships between existing object-oriented coupling, cohesion, and inheritance measures and the probability of fault detection in system classes during testing. The underlying goal of such a study is to better understand the relationship between existing design measurement in OO systems and the quality of the software developed. Results show that many of the measures capture similar dimensions in the dataset, thus reflecting the fact that many of them are based on similar principles and hypotheses. However, it is shown that by using a subset of measures, accurate models can be built to predict in which classes most of the faults are likely to lie in. By inspecting an amount of code comparable to the one contained in faulty classes, it is possible to find between 90% and 95% of the faults, depending on the type of model validation considered. Besides the size of classes, the frequency of method invocations and the depth of inheritance hie...

A practical application of object-oriented measures is to predict which classes are likely to contain a fault. This is contended to be meaningful because object-oriented measures are believed to be indicators of psychological complexity, and classes that are more complex are likely to be faulty Recently, a cognitive theory has been proposed suggesting that there are threshold effects for many object-oriented measures. This means that objectoriented classes are easy to understand as long as their complexity is below a threshold. Above that threshold their understandability decreases rapidly, leading to an increased probability of a fault. This occurs, according to the theory, due to an overflow of short-term human memory. If this theory is confirmed, then it would provide a mechanism that would explain the introduction of faults into objectoriented systems, and would also provide some practical guidance on how to design object-oriented programs. In this paper we empirically test this theory on two C++ telecommunications systems. We test for threshold effects in a subset of the Chidamber and Kemerer (CK) suite of measures. The dependent variable was the incidence of faults that lead to field failures. Our results indicate that there are no threshold effects for any of the measures studied. This means that there is no value for the studied CK measures where the fault-proneness changes from being steady to rapidly increasing. The results are consistent across the two systems. Therefore, we can provide no support to the posited cognitive theory.

Metrics have long been used to measure and evaluate software products and processes. Many metrics have been developed that have lead to different degrees of success. Software architecture is a discipline in which few metrics have been applied, a surprising fact given the critical role of software architecture in software development. Software product line architectures represent one area of software architecture in which we believe metrics can be of especially great use. The critical importance of the structure defined by a product line architecture requires that its properties be meaningfully assessed and that informed architectural decisions be made to guide its evolution. To begin addressing this issue, we have developed a class of closely related metrics that specifically target product line architectures. The metrics are based on the concept of service utilization and explicitly take into account the context in which individual architectural elements are placed. In this paper, we define the metrics, illustrate their use, and evaluate their strengths and weaknesses through their application on three example product line architectures.