A heuristic-based approach to code-smell detection

Encapsulation and data hiding are central tenets of the object oriented paradigm. Deciding what data and behaviour to form into a class and where to draw the line between its public and private details can make the difference between a class that is an understandable, flexible and reusable abstraction and one which is not. This decision is a difficult one and may easily result in poor encapsulation which can then have serious implications for a number of system qualities. It is often hard to identify such encapsulation problems within large software systems until they cause a maintenance problem (which is usually too late) and attempting to perform such analysis manually can also be tedious and error prone. Two of the common encapsulation problems that can arise as a consequence of this decomposition process are data classes and god classes. Typically, these two problems occur together – data classes are lacking in functionality that has typically been sucked into an over-complicated and domineering god class. This paper describes the architecture of a tool which automatically detects data and god classes that has been developed as a plug-in for the Eclipse IDE. The technique has been evaluated in a controlled study on two large open source systems which compare the tool results to similar work by Marinescu, who employs a metrics-based approach to detecting such features. The study provides some valuable insights into the strengths and weaknesses of the two approache

Improving Prolog Programs: Refactoring for Prolog

Refactoring is an established technique from the OO-community to restructure code: it aims at improving software readability, maintainability and extensibility. Although refactoring is not tied to the OO-paradigm in particular, its ideas have not been applied to Logic Programming until now. This paper applies the ideas of refactoring to Prolog programs. A catalogue is presented listing refactorings classified according to scope. Some of the refactorings have been adapted from the OO-paradigm, while others have been specifically designed for Prolog. Also the discrepancy between intended and operational semantics in Prolog is addressed by some of the refactorings. In addition, ViPReSS, a semi-automatic refactoring browser, is discussed and the experience with applying \vipress to a large Prolog legacy system is reported. Our main conclusion is that refactoring is not only a viable technique in Prolog but also a rather desirable one.Comment: To appear in ICLP 200

Generic Model Refactorings

Many modeling languages share some common concepts and principles. For example, Java, MOF, and UML share some aspects of the concepts\ud of classes, methods, attributes, and inheritance. However, model\ud transformations such as refactorings specified for a given language\ud cannot be readily reused for another language because their related\ud metamodels may be structurally different. Our aim is to enable a\ud flexible reuse of model transformations across various metamodels.\ud Thus, in this paper, we present an approach allowing the specification\ud of generic model transformations, in particular refactorings, so\ud that they can be applied to different metamodels. Our approach relies\ud on two mechanisms: (1) an adaptation based mainly on the weaving\ud of aspects; (2) the notion of model typing, an extension of object\ud typing in the model-oriented context. We validated our approach by\ud performing some experiments that consisted of specifying three well\ud known refactorings (Encapsulate Field, Move Method, and Pull Up Method)\ud and applying each of them onto three different metamodels (Java,\ud MOF, and UML)

Interface refactoring in performance-constrained web services

This paper presents the development of REF-WS an approach to enable a Web Service provider to reliably evolve their service through the application of refactoring transformations. REF-WS is intended to aid service providers, particularly in a reliability and performance constrained domain as it permits upgraded ’non-backwards compatible’ services to be deployed into a performance constrained network where existing consumers depend on an older version of the service interface. In order for this to be successful, the refactoring and message mediation needs to occur without affecting functional compatibility with the services’ consumers, and must operate within the performance overhead expected of the original service, introducing as little latency as possible. Furthermore, compared to a manually programmed solution, the presented approach enables the service developer to apply and parameterize refactorings with a level of confidence that they will not produce an invalid or ’corrupt’ transformation of messages. This is achieved through the use of preconditions for the defined refactorings

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

Evaluation of Kermeta for Solving Graph-based Problems

Kermeta is a meta-language for specifying the structure and behavior of graphs of interconnected objects called models. In this paper,\ud we show that Kermeta is relatively suitable for solving three graph-based\ud problems. First, Kermeta allows the specification of generic model\ud transformations such as refactorings that we apply to different metamodels\ud including Ecore, Java, and Uml. Second, we demonstrate the extensibility\ud of Kermeta to the formal language Alloy using an inter-language model\ud transformation. Kermeta uses Alloy to generate recommendations for\ud completing partially specified models. Third, we show that the Kermeta\ud compiler achieves better execution time and memory performance compared\ud to similar graph-based approaches using a common case study. The\ud three solutions proposed for those graph-based problems and their\ud evaluation with Kermeta according to the criteria of genericity,\ud extensibility, and performance are the main contribution of the paper.\ud Another contribution is the comparison of these solutions with those\ud proposed by other graph-based tools

Improving Prolog programs: Refactoring for Prolog

Refactoring is an established technique from the object-oriented (OO) programming community to restructure code: it aims at improving software readability, maintainability and extensibility. Although refactoring is not tied to the OO-paradigm in particular, its ideas have not been applied to Logic Programming until now. This paper applies the ideas of refactoring to Prolog programs. A catalogue is presented listing refactorings classified according to scope. Some of the refactorings have been adapted from the OO-paradigm, while others have been specifically designed for Prolog. The discrepancy between intended and operational semantics in Prolog is also addressed by some of the refactorings. In addition, ViPReSS, a semi-automatic refactoring browser, is discussed and the experience with applying ViPReSS to a large Prolog legacy system is reported. The main conclusion is that refactoring is both a viable technique in Prolog and a rather desirable one.Comment: To appear in Theory and Practice of Logic Programming (TPLP

Object-oriented Programming Laws for Annotated Java Programs

Object-oriented programming laws have been proposed in the context of languages that are not combined with a behavioral interface specification language (BISL). The strong dependence between source-code and interface specifications may cause a number of difficulties when transforming programs. In this paper we introduce a set of programming laws for object-oriented languages like Java combined with the Java Modeling Language (JML). The set of laws deals with object-oriented features taking into account their specifications. Some laws deal only with features of the specification language. These laws constitute a set of small transformations for the development of more elaborate ones like refactorings

A Framework for Datatype Transformation

We study one dimension in program evolution, namely the evolution of the datatype declarations in a program. To this end, a suite of basic transformation operators is designed. We cover structure-preserving refactorings, but also structure-extending and -reducing adaptations. Both the object programs that are subject to datatype transformations, and the meta programs that encode datatype transformations are functional programs.Comment: Minor revision; now accepted at LDTA 200