A meta-analysis approach to refactoring and XP

The mechanics of seventy-two different Java refactorings are described fully in Fowler's text. In the same text, Fowler describes seven categories of refactoring, into which each of the seventy-two refactorings can be placed. A current research problem in the refactoring and XP community is assessing the likely time and testing effort for each refactoring, since any single refactoring may use any number of other refactorings as part of its mechanics and, in turn, can be used by many other refactorings. In this paper, we draw on a dependency analysis carried out as part of our research in which we identify the 'Use' and 'Used By' relationships of refactorings in all seven categories. We offer reasons why refactorings in the 'Dealing with Generalisation' category seem to embrace two distinct refactoring sub-categories and how refactorings in the 'Moving Features between Objects' category also exhibit specific characteristics. In a wider sense, our meta-analysis provides a developer with concrete guidelines on which refactorings, due to their explicit dependencies, will prove problematic from an effort and testing perspective

An empirical study of evolution of inheritance in Java OSS

Previous studies of Object-Oriented (OO) software have reported avoidance of the inheritance mechanism and cast doubt on the wisdom of ‘deep’ inheritance levels. From an evolutionary perspective, the picture is unclear - we still know relatively little about how, over time, changes tend to be applied by developers. Our conjecture is that an inheritance hierarchy will tend to grow ‘breadth-wise’ rather than ‘depth-wise’. This claim is made on the basis that developers will avoid extending depth in favour of breadth because of the inherent complexity of having to understand the functionality of superclasses. Thus the goal of our study is to investigate this empirically. We conduct an empirical study of seven Java Open-Source Systems (OSSs) over a series of releases to observe the nature and location of changes within the inheritance hierarchies. Results show a strong tendency for classes to be added at levels one and two of the hierarchy (rather than anywhere else). Over 96% of classes added over the course of the versions of all systems were at level 1 or level 2. The results suggest that changes cluster in the shallow levels of a hierarchy; this is relevant for developers since it indicates where remedial activities such as refactoring should be focused

An Approach Based on Maintainability Criteria for Building Aspect-Oriented Software Design Model

Software modeling is an important activity for maintenance since it can facilitate the software comprehension as well as the understanding of its activities towards evolution, correction and adaptation. In this sense, maintainability and its subcharacteristics as presented in the ISO/IEC 9126 standard should be incorporated 0to the artifacts produced in the modeling activity aiming at designing software with characteristics that render its maintenance less costly. Especially in non-trivial software, such as those that are aspect-oriented, the research on maintenance process considering it during the software development is remarkable. These categories of software aim at maintainability and reusability since they provide the separation of concerns. Thus, seeking to reduce the transition effort to the artifacts generated during the Aspect-Oriented Software Development among the different abstraction levels, this paper presents a proposal of maintainability criteria for building aspect-oriented software design models based on the Maintainability Criteria for Implementation Models, on the aSideML language modeling conventions and on the ISO/IEC 9126 standard

A framework for the simulation of structural software evolution

This is the author's accepted manuscript. The final published article is available from the link below. Copyright @ 2008 ACM.As functionality is added to an aging piece of software, its original design and structure will tend to erode. This can lead to high coupling, low cohesion and other undesirable effects associated with spaghetti architectures. The underlying forces that cause such degradation have been the subject of much research. However, progress in this field is slow, as its complexity makes it difficult to isolate the causal flows leading to these effects. This is further complicated by the difficulty of generating enough empirical data, in sufficient quantity, and attributing such data to specific points in the causal chain. This article describes a framework for simulating the structural evolution of software. A complete simulation model is built by incrementally adding modules to the framework, each of which contributes an individual evolutionary effect. These effects are then combined to form a multifaceted simulation that evolves a fictitious code base in a manner approximating real-world behavior. We describe the underlying principles and structures of our framework from a theoretical and user perspective; a validation of a simple set of evolutionary parameters is then provided and three empirical software studies generated from open-source software (OSS) are used to support claims and generated results. The research illustrates how simulation can be used to investigate a complex and under-researched area of the development cycle. It also shows the value of incorporating certain human traits into a simulation—factors that, in real-world system development, can significantly influence evolutionary structures

Class movement and re-location: An empirical study of Java inheritance evolution

This is the post-print version of the final paper published in Journal of Systems and Software. The published article is available from the link below. Changes resulting from the publishing process, such as peer review, editing, corrections, structural formatting, and other quality control mechanisms may not be reflected in this document. Changes may have been made to this work since it was submitted for publication. Copyright @ 2009 Elsevier B.V.Inheritance is a fundamental feature of the Object-Oriented (OO) paradigm. It is used to promote extensibility and reuse in OO systems. Understanding how systems evolve, and specifically, trends in the movement and re-location of classes in OO hierarchies can help us understand and predict future maintenance effort. In this paper, we explore how and where new classes were added as well as where existing classes were deleted or moved across inheritance hierarchies from multiple versions of four Java systems. We observed first, that in one of the studied systems the same set of classes was continuously moved across the inheritance hierarchy. Second, in the same system, the most frequent changes were restricted to just one sub-part of the overall system. Third, that a maximum of three levels may be a threshold when using inheritance in a system; beyond this level very little activity was observed, supporting earlier theories that, beyond three levels, complexity becomes overwhelming. We also found evidence of ‘collapsing’ hierarchies to bring classes up to shallower levels. Finally, we found that larger classes and highly coupled classes were more frequently moved than smaller and less coupled classes. Statistical evidence supported the view that larger classes and highly coupled classes were less cohesive than smaller classes and lowly coupled classes and were thus more suitable candidates for being moved (within an hierarchy)

New Inheritance Complexity Metrics for Object-Oriented Software Systems: An Evaluation with Weyuker's Properties

Two inheritance complexity metrics, one at class level CCI (Class Complexity due to Inheritance) and another at program level ACI (Average Complexity of a program due to Inheritance), have been proposed for object-oriented software systems. These proposed metrics are evaluated with Weyuker's properties and compared with other well known object-oriented inheritance metrics. It has been found that the proposed metrics better represent the complexity, due to inheritance, of a class and a program. Weyuker's property 7 (Significance of Permutation) has received a negative response regarding its applicability to object-oriented software metrics. It has been observed that this property is not satisfied by any of the object-oriented inheritance metrics proposed so far. Contrary to past beliefs, the relevance of this property to object-oriented systems has been brought out in this paper. Examples with C++ code are also presented to support the applicability of this property

Measuring the complexity of product configuration systems

International audienceThe complexity of product configuration systems is an important indicator of both development and maintenance effort of the systems. Existing literature proposes a couple of effort estimation approaches for configurator projects. However, these approaches do not address the issues of comprehensibility and modifiability of a configuration model. Therefore, this article proposes a metric to measure the total cognitive complexity of the configuration model corresponding to a product configuration system, expressed in the form of an UML class diagram. This metric takes into account the number and the type of attributes, constraints and the relationships between classes in an UML class diagram. The proposed metric can be used to compare two configuration models, in terms of their cognitive complexity. Moreover, a relation between development time for a PCS project and the total cognitive complexity of the corresponding configuration model is established using linear regression. To validate the proposed approach a case study is conducted where the cognitive complexity is calculated for two configuration models

DISTANCE: a framework for software measure construction.

In this paper we present a framework for software measurement that is specifically suited to satisfy the measurement needs of empirical software engineering research. The framework offers an approach to measurement that builds upon the easily imagined, detected and visualised concepts of similarity and dissimilarity between software entities. These concepts are used both to model the software attributes of interest and to define the corresponding software measures. Central to the framework is a process model that embeds constructive procedures for attribute modelling and measure construction into a goal-oriented approach to empirical software engineering studies. The underlying measurement theoretic principles of our approach ensure the construct validity of the resulting measures. The approach was tested on a popular suite of object-oriented design measures. We further show that our measure construction method compares favourably to related work.Software;

Restructuring source code identifiers

In software engineering, maintenance cost 60% of overall project lifecycle costs of any software product. Program comprehension is a substantial part of maintenance and evolution cost and, thus, any advancement in maintenance, evolution, and program understanding will potentially greatly reduce the total cost of ownership of any software products. Identifiers are an important source of information during program understanding and maintenance. Programmers often use identifiers to build their mental models of the software artifacts. Thus, poorly-chosen identifiers have been reported in the literature as misleading and increasing the program comprehension effort. Identifiers are composed of terms, which can be dictionary words, acronyms, contractions, or simple strings. We conjecture that the use of identical terms in different contexts may increase the risk of faults, and hence maintenance effort. We investigate our conjecture using a measure combining term entropy and term context-coverage to study whether certain terms increase the odds ratios of methods to be fault-prone. We compute term entropy and context-coverage of terms extracted from identifiers in Rhino 1.4R3 and ArgoUML 0.16. We show statistically that methods containing terms with high entropy and context-coverage are more fault-prone than others, and that the new measure is only partially correlated with size. We will build on this study, and will apply summarization technique for extracting linguistic information form methods and classes. Using this information, we will extract domain concepts from source code, and propose linguistic based refactoring

A COUPLING AND COHESION METRICS SUITE FOR

The increasing need for software quality measurements has led to extensive research into software metrics and the development of software metric tools. To maintain high quality software, developers need to strive for a low-coupled and highly cohesive design. One of many properties considered when measuring coupling and cohesion is the type of relationships that made up coupling and cohesion. What these specific relationships are is widely understood and accepted by researchers and practitioners. However, different researchers base their metrics on a different subset of these relationships. Studies have shown that because of the inclusion of multiple subsets of relationships in one measure of coupling and cohesion metrics, the measures tend to correlate among each other. Validation of these metrics against maintainability index of a Java program suggested that there is high multicollinearity among coupling and cohesion metrics. This research introduces an approach of implementing coupling and cohesion metrics. Every possible relationship is considered and, for each, addressed the issue of whether or not it has significant effect on maintainability index prediction. Validation of orthogonality of the selected metrics is assessed by means of principal component analysis. The investigation suggested that some of the metrics are independent set of metrics, while some are measuring similar dimension