Subsequent releases of a system have common development environments and characteristics. However, prediction models based on within‐project data potentially suffer from being based on fault data reported within relatively short maintenance time intervals, which potentially decreases their prediction abilities. In this study, the authors propose an approach that improves the classification performance of models based on within‐project data that are applied to predict the fault‐proneness of the classes in a software post‐release (PR). The proposed approach involves selecting a set of immediate pre‐releases and constructing a prediction model based on each pre‐release. The PR classes are categorised based on whether they are newly developed or they are reused, with or without modification, from one or more of the selected pre‐releases. The prediction models are applied to the PR classes reused from selected pre‐releases, and the results are used to construct a fault‐proneness prediction model. After applying this prediction model to all PR classes, the fault‐proneness results are adjusted by considering the relationship between the prediction results of the individual pre‐release models and the actual fault data. They reported an empirical study that shows that the classification performance of the categorisation‐based fault‐proneness prediction models is considerably better than those constructed using existing approaches.

Software refactoring is a maintenance task that addresses code restructuring to improve its quality. Many studies have addressed the impact of different refactoring scenarios on software quality. This study presents a systematic literature review that aggregates, summarizes, and discusses the results of 76 relevant primary studies (PSs) concerning the impact of refactoring on several internal and external quality attributes. The included PSs were selected using inclusion and exclusion criteria applied to relevant articles published before the end of 2015. We analyzed the PSs based on a set of classification criteria, including software quality attributes and measures, refactoring scenarios, evaluation approaches, datasets, and impact results. We followed the vote-counting approach to determine the level of consistency among the PS reported results concerning the relationship between refactoring and software quality. The results indicated that different refactoring scenarios sometimes have opposite impacts on different quality attributes. Therefore, it is false that refactoring always improves all software quality aspects. The vote-counting study provided a clear view of the impacts of some individual refactoring scenarios on some internal quality attributes such as cohesion, coupling, complexity, inheritance, and size, but failed to identify their impacts on external and other internal quality attributes due to insufficient findings.

Intuitively, in a certain class, a pair of methods that share an attribute of an object type is potentially more cohesive than those that share an attribute of a primitive type because the attribute of a reference type could implicitly refer to multiple data. Existing class cohesion measures ignore the implicit access to or sharing of attributes due to the encapsulation feature. As a result, the obtained cohesion values can be inaccurate and could lead to incorrect quality indications. This paper aims at demonstrating how to account for data encapsulation (DE) in cohesion measurement and reports empirical studies that investigate the impact of considering DE in cohesion measurement on cohesion values and the abilities of cohesion measures to predict class fault proneness. To differentiate between attributes and parameters of different types, we propose a weight assignment algorithm. The weight that is assigned to an attribute or a parameter of a type depends on the number of encapsulated attributes of the type. Seven cohesion measures are extended to consider the assigned weights in cohesion measurement. The results of the empirical study show that the cohesion values and the corresponding fault-proneness prediction results can significantly change when accounting for DE in cohesion measurement. Copyright © 2015 John Wiley & Sons, Ltd.

SUMMARY Class cohesion metrics apply different approaches to quantify the relatedness of the attributes and methods in a class. These relations can be direct or transitive. Method invocations are among the key sources of potential transitive attribute–method relations. That is, a method is not only related to the attributes that it references, but it may also be transitively related to the attributes referenced by the methods that it invokes. A few of the existing class cohesion metrics capture this potential transitive cohesion aspect. In this paper, we classify the method invocations as direct or transitive. The definitions of the class representative models used by 16 existing low‐level design (LLD) metrics are extended to incorporate the cohesion caused by the two types of method invocations. The impact of incorporating the transitive relations because of the two types of method invocations on the cohesion values and on the ability of the LLD metrics to predict faulty classes are studied empirically. The results show that the transitive relations because of both types of method invocations featured a considerable degree of cohesion that is not captured by most of the existing LLD metrics. However, practically, incorporating transitive relations in cohesion measurement was found to be ineffective in improving the fault‐prediction powers of most of the LLD metrics. Copyright © 2012 John Wiley & Sons, Ltd.

The building of highly cohesive classes is an important objective in object-oriented design. Class cohesion refers to the relatedness of the class members, and it indicates one important aspect of the class design quality. A meaningful class cohesion metric helps object-oriented software developers detect class design weaknesses and refactor classes accordingly. Several class cohesion metrics have been proposed in the literature. Most of these metrics are applicable based on low-level design information such as attribute references in methods. Some of these metrics capture class cohesion by counting the number of method pairs that share common attributes. A few metrics measure cohesion more precisely by considering the degree of interaction, through attribute references, between each pair of methods. However, the formulas applied by these metrics to measure the degree of interaction cause the metrics to violate important mathematical properties, thus undermining their construct validity and leading to misleading cohesion measurement. In this paper, we propose a formula that precisely measures the degree of interaction between each pair of methods, and we use it as a basis to introduce a low-level design class cohesion metric (LSCC). We verify that the proposed formula does not cause the metric to violate important mathematical properties. In addition, we provide a mechanism to use this metric as a useful indicator for refactoring weakly cohesive classes, thus showing its usefulness in improving class cohesion. Finally, we empirically validate LSCC. Using four open source software systems and eleven cohesion metrics, we investigate the relationship between LSCC, other cohesion metrics, and fault occurrences in classes. Our results show that LSCC is one of three metrics that explains more accurately the presence of faults in classes. LSCC is the only one among the three metrics to comply with important mathematical properties, and statistical analysis shows it captures a measurement dimension of its own. This suggests that LSCC is a better alternative, when taking into account both theoretical and empirical results, as a measure to guide the refactoring of classes. From a more general standpoint, the results suggest that class quality, as measured in terms of fault occurrences, can be more accurately explained by cohesion metrics that account for the degree of interaction between each pair of methods.

Several object-oriented cohesion metrics have been proposed in the literature. These metrics aim to measure the relationship between class members, namely, methods and attributes. Different metrics use different models to represent the connectivity pattern of cohesive interactions (CPCI) between class members. Most of these metrics are normalized to allow for easy comparison of the cohesion of different classes. However, in some cases, these metrics obtain the same cohesion values for different classes that have the same number of methods and attributes but different CPCIs. This leads to incorrectly considering the classes to be the same in terms of cohesion, even though their CPCIs clearly indicate that the degrees of cohesion are different. We refer to this as a lack of discrimination anomaly (LDA) problem. In this paper, we list and discuss cases in which the LDA problem exists, as expressed through the use of 16 cohesion metrics. In addition, we empirically study the frequent occurrence of the LDA problem when the considered metrics are applied to classes in five open source Java systems. Finally, we propose a metric and a simulation-based methodology to measure the discriminative power of cohesion metrics. The discrimination metric measures the probability that a cohesion metric will produce distinct cohesion values for classes with the same number of attributes and methods but different CPCIs. A highly discriminating cohesion metric is more desirable because it exhibits a lower chance of incorrectly considering classes to be cohesively equal when they have different CPCIs.

An application framework provides a reusable design and implementation for a family of software systems. Frameworks are introduced to reduce the cost of a product line (i.e., family of products that share the common features) and to increase the maintainability of software products through the deployment of reliable large-scale reusable components. A key challenge with frameworks is the development, evolution and maintenance of test cases to ensure the framework operates appropriately in a given application or product. Reusable test cases increase the maintainability of the software products because an entirely new set of test cases does not have to be generated each time the framework is deployed. At the framework deployment stage, the application developers (i.e., framework users) may need the flexibility to ignore or modify part of the specification used to generate the reusable class-based test cases. This paper addresses how to deal effectively with the different modification forms such that the use of the test cases becomes easy and straightforward in testing the framework interface classes (FICs) developed at the application development stage. Finally, the paper discusses the fault coverage and experimentally examines the specification coverage of the reusable test cases. Copyright © 2005 John Wiley & Sons, Ltd.

An application framework provides a reusable design and implementation for a family of software systems. If the framework contains defects, the defects will be passed on to the applications developed from the framework. Framework defects are hard to discover at the time the framework is instantiated. Therefore, it is important to remove all defects before instantiating the framework. The problem addressed in this paper is developing an automated state-based test suite generator technique that uses hook technology to produce test suites to test frameworks at the system level. A case study is reported and its results show that the proposed technique is reasonably effective at detecting faults. A supporting tool that automatically produces framework test cases, executes them, and evaluates the results is presented.