The increasing importance being placed on software measurement has lead to an increased amount of research developing new software measures. Given the importance of object-oriented development techniques, one specific area where this has occurred is cohesion measurement in object-oriented systems. However, despite a very interesting body of work, there is little understanding of the motivation and empirical hypotheses behind many of these new measures. It is often difficult to determine how such measures relate to one another and for which application they can be used. As a consequence, it is very difficult for practitioners and researchers to obtain a clear picture of the state-of-the-art in order to select or define cohesion measures for object-oriented systems. This situation is addressed and clarified through several different activities. First, a standardized terminology and formalism for expressing measures is provided which ensures that all measures using it are expressed in a f...

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...

The availability of significant measures in the early phases of the software development life-cycle allows for better management of the later phases, and more effective quality assessment when quality can be more easily affected by preventive or corrective actions. In this paper, we introduce and compare various high-level design measures for object-based software systems. The measures

Many coupling measures have been proposed in the context of object-oriented (OO) systems. In addition, several studies have highlighted the complexity of using dependency analysis in OO software to perform impact analysis. The question is then: can we use simple decision models based on coupling measurement to support impact analysis in OO systems? Such an approach has for main advantage its simplicity and complete automation. To investigate this question, we perform here a thorough analysis on a commercial C++ system where change data has been collected over several years. We identify the coupling dimensions that seem to be significantly related to ripple effects and use them to rank classes according to their probability of containing ripple effects. We then assess the expected effectiveness of such decision models. Keywords Coupling, metrics, measurement, impact analysis, object -oriented. 1 Introduction A claimed benefit of object-oriented (OO) modeling approaches is that they ...

This paper aims at empirically exploring the relationships between most of the existing design coupling, cohesion, and inheritance measures for object-oriented (OO) systems, and the fault-proneness of OO system classes. The underlying goal of this study is to better understand the relationship between existing design measurement in OO systems and the quality of the software developed. In addition, we aim at assessing whether such relationships, once modeled, can be used to effectively drive and focus inspections or testing. The study described here is a replication of an analogous study conducted in a university environment with systems developed by students. In order to draw more general conclusions and to (dis)confirm the results obtained there, we now replicated the study using data collected on an industrial system developed by professionals. Results show that many of our findings are consistent across systems, despite the very disparate nature of the systems under study. Some of the strong dimensions captured by the measures in each data set are visible in both the university and industrial case study. 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, although many principles and techniques can be reused, quality does not follow universal laws and quality models must be developed locally, wherever needed.

A primary expected benefit of object-oriented (OO) methods is the creation of software systems that are easier to adapt and maintain. OO design patterns are especially geared to improve adaptability, since patterns generally increase the complexity of an initial design in order to ease future enhancements. For design patterns to really provide benefit, they must reduce the cost of future adaptation. The evidence of improvements in adaptability through the use of design patterns and other design structures consists primarily of intuitive arguments and examples. There is little empirical evidence to support claims of improved flexibility of these preferred structures. In this case study, we analyze 39 versions of an evolving industrial OO software system to see if there is a relationship between patterns, other design attributes, and the number of changes. We found a strong relationship between class size and the number of changes --- larger classes were changed more frequently. We also found two relationships that we did not expect: (1) classes that participate in design patterns are not less change prone --- these pattern classes are among the most change prone in the system, and (2) classes that are reused the most through inheritance tend to be more change prone. These unexpected results hold up after accounting for class size, which had the strongest relationship with changes. Keywords Design patterns, object-oriented design, software changes, adaptability. 1.

Large software systems are difficult to understand and maintain. Program dependency analysis plays a key role in both understanding and maintenance. This paper discusses hidden dependencies among software components that make both understanding and maintenance hard. Hidden dependency is a relationship between two seemingly independent components and it is caused by a data flow inside of a third software components. The paper uses Abstract System Dependence Graphs to define hidden dependencies. It discusses the impact of hidden dependencies on the process of change propagation and also discusses an algorithm that warns about possible presence of hidden dependencies.

Abstract: Software architecture analysis is a cost-effective means of controlling risk and maintaining system quality throughout the processes of software design, development and maintenance. This paper presents a sequence of steps that maps architectural quality goals into scenarios that measure the goals, mechanisms that realize the scenarios and analytic models that measure the results. This mapping ensures that design decisions and their rationale are documented in such a fashion that they can be systematically explored, varied, and potentially traded off against each other. As systems evolve, the analytic models can be used to assess the impact of architectural changes, relative to the system’s changing quality goals. Although scenarios have been extensively used in software design to understand the ways in which a system meets its operational requirements, there has been little systematic use of scenarios to support analysis, particularly analysis of a software architecture’s quality attributes: modifiability, portability, extensibility, security, availability, and so forth. In this paper we present a unified approach to using scenarios to support both the design, analysis and maintenance of software architectures, and examples from large-scale software development projects where we have applied the approach. We also present a tool, called Brie, that aids in: scenario capture, mapping scenarios to software architectures, and the association of analytic models with particular portions of architectures. The approach that we have devised, and that Brie supports, is a foundation for a discipline of architectural engineering. Architectural engineering is an iterative method of design, analysis and maintenance where design decisions are motivated by scenarios, and are supported by documented analyses. 1

Coupling is an internal software attribute that can be used to indicate the degree of interdependence among the components of a software system. Coupling is thought to be a desirable goal in software construction, leading to better values for external attributes such as maintainability, reusability, and reliability. Aspect-oriented software development (AOSD) is a new technique to support separation of concerns in software development. In aspect-oriented (AO) systems, the basic components are aspects or classes, which consist of attributes (aspect or class instance variables) and those modules such as advice, intertype declarations, pointcuts, and methods. Thus, in AO systems, the coupling is mainly about the degree of interdependence among aspects and/or classes. To test this hypothesis, good coupling measures for AO systems are needed. In this paper, we propose a coupling measure suite for assessing the coupling in aspect-oriented systems. We first present a coupling framework for AO systems which specially designed to count the dependencies between aspects and classes in the systems. Based on this framework, we formally define various coupling measures in terms of different types of dependencies between aspects and classes. We also discuss the mathematical properties of these measures. 1

Loose coupling is often quoted as a desirable property of systems architectures. One of the main goals of building systems using Web technologies is to achieve loose coupling. However, given the lack of a widely accepted definition of this term, it becomes hard to use coupling as a criterion to evaluate alternative Web technology choices, as all options may exhibit, and claim to provide, some kind of “loose ” coupling effects. This paper presents a systematic study of the degree of coupling found in service-oriented systems based on a multi-faceted approach. Thanks to the metric introduced in this paper, coupling is no longer a one-dimensional concept with loose coupling found somewhere in between tight coupling and no coupling. The paper shows how the metric can be applied to real-world examples in order to support and improve the design process of service-oriented systems.