No abstract

This paper aims at empirically exploring the relationships between most of the existing coupling and cohesion measures for object-oriented (00) systems, and the faultproneness of 00 system classes. The underlying goal of such a study is to better understand the relationship between existing design measurement in 00 systems and the quality of the software developed. The study described here is a replication of an analogous stt.& conducted in an university environment with systems developed by students. In order to draw more general conclusions and to (dis)conJirm the results obtained there, we now replicated the study using data collected on an industrial system developed by professionals. Resul?s show that many of our Jindings are consistent across systems, despite the very disparate nature of the systems under stu& Some of the strong dimensions captured by the measures in each data set are visible in both the university and industrial case stua'y. For example, the frequency of method invocations appears to be the main driving factor of fault-proneness in all systems. However, there are also differences across studies which illustrate the fact that quality does not follow universal laws and that quality models must be developed locally, wherever needed.

A growing body of literature suggests that there is an optimal size for software components. This means that components that are too small or too big will have a higher defect content (i.e., there is a U-shaped curve relating defect content to size). The U-shaped curve has become known as the "Goldilocks Conjecture". Recently, a cognitive theory has been proposed to explain this phenomenon, and it has been expanded to characterize object-oriented software. This conjecture has wide implications for software engineering practice. It suggests (1) that designers should deliberately strive to design classes that are of the optimal size, (2) that program decomposition is harmful, and (3) that there exists a maximum (threshold) class size that should not be exceeded to ensure fewer faults in the software. The purpose of the current paper is to evaluate this conjecture for object-oriented systems. We first demonstrate that the claims of an optimal component/class size (1 above) and of smaller components/classes having a greater defect content (2 above) are due to a mathematical artifact in the analyses performed previously. We then empirically test the threshold effect claims of this conjecture (3 above). To our knowledge, the empirical test of size threshold effects for object-oriented systems has not been performed thus far. We perform an initial study with an industrial C++ system, and replicated it twice on another C++ system and on a commercial Java application. Our results provide unambiguous evidence that there is no threshold effect of class size. We obtained the same result for three systems using 4 different size measures. These findings suggest that there is a simple continuous relationship between class size and faults, and that optimal, smaller classes are better, and threshold effects conjectures have no sound theoretical nor empirical basis.

No abstract

Legacy software systems present a high level of entropy combined with imprecise documentation. This makes their maintenance more difficult, more time consuming, and costlier. In order to address these issues, many organizations have been migrating their legacy systems to new technologies. In this paper, we describe a computer-supported approach aimed at supporting the migration of procedural software systems to the objectoriented (00) technology, which supposedly, fosters reusability, expandability, flexibility, encapsulation, information hiding, modularity, and maintainability. Our approach relies heavily on the automatic formation of concepts based on information extracted directly from code to identib objects. The approach tends, thus, to minimize the need for domain application experts. We also propose rules for the identification of 00 methods from routines. A well-known and self-contained example is used to illustrate the approach. We have applied the approach on mediudlarge procedural software systems, and the results show that the approach is able to find objects and to identib their methods from procedures and functions.