Serge Demeyer

A language independent approach for detecting duplicated code

Code duplication is one of the factors that severely complicates the maintenance and evolution of large software systems. Techniques for detecting duplicated code exist but rely mostly on parsers, technology that has proven to be brittle in the face of different languages and dialects. In this paper we show that is possible to circumvent this hindrance by applying a language independent and visual approach, i.e. a tool that requires no parsing, yet is able to detect a significant amount of code duplication. We validate our approach on a number of case studies, involving four different implementation languages and ranging from 256 K up to 13 Mb of source code size.

Finding refactorings via change metrics

Reverse engineering is the process of uncovering the design and the design rationale from a functioning software system. Reverse engineering is an integral part of any successful software system, because changing requirements lead to implementations that drift from their original design. In contrast to traditional reverse engineering techniques ---which analyse a single snapshot of a system--- we focus the reverse engineering effort by determining where the implementation has changed. Since changes of object-oriented software are often phrased in terms of refactorings, we propose a set of heuristics for detecting refactorings by applying lightweight, object-oriented metrics to successive versions of a software system. We validate our approach with three separate case studies of mature object-oriented software systems for which multiple versions are available. The case studies suggest that the heuristics support the reverse engineering process by focusing attention on the relevant parts of a software system.

Challenges in software evolution

Todays information technology society increasingly relies on software at all levels. Nevertheless, software quality generally continues to fall short of expectations, and software systems continue to suffer from symptoms of aging as they are adapted to changing requirements and environments. The only way to overcome or avoid the negative effects of software aging is by placing change and evolution in the center of the software development process. In this article we describe what we believe to be some of the most important research challenges in software evolution. The goal of this document is to provide novel research directions in the software evolution domain.

Predicting the severity of a reported bug

The severity of a reported bug is a critical factor in deciding how soon it needs to be fixed. Unfortunately, while clear guidelines exist on how to assign the severity of a bug, it remains an inherent manual process left to the person reporting the bug. In this paper we investigate whether we can accurately predict the severity of a reported bug by analyzing its textual description using text mining algorithms. Based on three cases drawn from the open-source community (Mozilla, Eclipse and GNOME), we conclude that given a training set of sufficient size (approximately 500 reports per severity), it is possible to predict the severity with a reasonable accuracy (both precision and recall vary between 0.65–0.75 with Mozilla and Eclipse; 0.70–0.85 in the case of GNOME).

Formalising Behaviour Preserving Program Transformations

The notion of refactoring --transforming the source-code of an object-oriented program without changing its external behaviour-- has increased the need for a precise definition of refactorings and their properties. This paper introduces a graph representation of those aspects of the source code that should be preserved by a refactoring, and graph rewriting rules as a formal specification for the refactoring transformations themselves. To this aim, we use type graphs, forbidden subgraphs, embedding mechansims, negative application conditions and controlled graph rewriting. We show that it is feasible to reason about the effect of refactorings on object-oriented programs independently of the programming language being used. This is crucial for the next generation of refactoring tools.

Refactoring - improving coupling and cohesion of existing code

Refactorings are widely recognised as ways to improve the internal structure of object-oriented software while maintaining its external behaviour. Unfortunately, refactorings concentrate on the treatment of symptoms (the so called code-smells), thus improvements depend a lot on the skills of the maintained coupling and cohesion on the other hand are quality attributes which are generally recognized as being among the most likely quantifiable indicators for software maintainability. Therefore, this paper analyzes how refactorings manipulate coupling/cohesion characteristics, and how to identify refactoring opportunities that improve these characteristics. As such we provide practical guidelines for the optimal usage of refactoring in a software maintenance process.

A meta-model for language-independent refactoring

Refactoring-transforming code while preserving behaviour-is considered a key approach for improving object-oriented software systems. Unfortunately, all of the current refactoring tools depend on language-dependent refactoring engines, which prevents a smooth integration with mainstream development environments. We investigate the similarities between refactorings for Smalltalk and Java, derive a language-independent meta-model and show that it is feasible to build a language-independent refactoring engine on top of this meta-model. Our feasibility study is validated by means of a tool prototype which uses the same engine to refactor both Smalltalk and Java code. Using our approach we minimize the language-dependent part of refactoring tools, providing a standard way for programmers and tools to perform refactorings no matter what language they work in.

Towards automating source-consistent UML refactorings

With the increased interest in refactoring, UML tool vendors seek ways to support software developers in applying a (sequence of) refactoring(s). The problem with such tools is that the UML metamodel – on which their repository is based – is inadequate to maintain the consistency between the model and the code while one of them gets refactored. Therefore, we propose a set of minimal extensions to the UML metamodel, which is sufficient to reason about refactoring for all common OO languages. For instance, by specifying pre- and postconditions in OCL, we are able to compose primitive refactorings, verify preservation of program behavior, and trigger refactorings based on code smells. This way, we provide future MDA tools with the ability to improve existing UML designs, yet keeping them in synch with the underlying code base.

Studying software evolution information by visualizing the change history

Before re-engineering a large and complex software system, it is wise to study its change history in order to identify the most valuable and problematic parts. Unfortunately, typical change histories contain thousands of entries, therefore the challenge is to discover those changes which are relevant for both the current and future situations of our product and process. We demonstrate how a simple visualization allows us to recognize relevant changes. Applying the technique on the change history of Tomcat, we have been able to identify (a) unstable components, (b) coherent entities, (c) design and architectural evolution, and (d) fluctuations in team productivity.

Reconstruction of successful software evolution using clone detection

In modern software engineering, researchers regard a software system as an organic life form that must continue to evolve to remain successful. Unfortunately, little is known about how successful software systems have evolved, and consequently little has been learned from previous experience. We demonstrate a heuristic to reconstruct evolution processes of existing software systems by exploiting techniques to detect duplication in large amounts of data. A case study, evaluating various versions of Tomcat using this heuristic, revealed that the removal of duplicated code is a much smaller concern than grouping functionality in classes with one clear responsibility.