Sander Tichelaar

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.

Why unified is not universal: UML shortcomings for coping with round-trip engineering

UML is currently embraced as “the” standard in object-oriented modeling languages, the recent work of OMG on the Meta Object Facility (MOF) being the most noteworthy example. We welcome these standardisation efforts, yet warn against the tendency to use UML as the panacea for all exchange standards. In particular, we argue that UML is not sufficient to serve as a tool-interoperability standard for integrating round-trip engineering tools, because one is forced to rely on UML’s built-in extension mechanisms to adequately model the reality in source-code. Consequently, we propose an alternative meta-model (named FAMIX), which serves as the tool interoperability standard within the FAMOOS project and which includes a number of constructive suggestions that we hope will influence future releases of the UML and MOF standards.

FAMIX and XMI

Exchange formats have gained lots of attention. Multiple tools need to interact and/or work on the some software system. Especially there is a need to reuse parser technology. Within the FAMOOS project we have developed a model for representing object-oriented software systems at the program entity level. The model has been designed for language independence, extensibility and information exchange. For the actual exchange of data we are currently moving to use XMI, a standard for model-based information exchange.

Dimensions of reengineering environment infrastructures

Over the last decade many research groups and commercial companies have been developing reengineering environments. However, many design decisions such as support for multiple models, incremental loading of information, tool integration, entity grouping, and their impacts on the underlying meta-model and resulting environment have remained implicit. Based on the experience accumulated while developing the Moose reengineering environment and on a survey of reengineering environments, we present a design space defined by a set of criteria that makes explicit the different options and especially their dependencies and trade-offs. Using this design space, developers of future environments should have a better understanding of the problems they face and the impact of design choices.

Why Unified Is not Universal

UML is currently embraced as “the” standard in object-oriented modeling languages, the recent work of OMG on the Meta Object Facility (MOF) being the most noteworthy example. We welcome these standardisation efforts, yet warn against the tendency to use UML as the panacea for all exchange standards. In particular, we argue that UML is not sufficient to serve as a tool-interoperability standard for integrating round-trip engineering tools, because one is forced to rely on UML’s built-in extension mechanisms to adequately model the reality in source-code. Consequently, we propose an alternative meta-model (named FAMIX), which serves as the tool interoperability standard within the FAMOOS project and which includes a number of constructive suggestions that we hope will influence future releases of the UML and MOF standards.

Design guidelines for coordination components

The distributed nature of a typical web application combined with the rapid evolution of underlying platforms demands for a plug-in component architecture. Nevertheless, code for controlling distributed activities is usually spread over multiple subsystems, which makes it hard to dynamically reconfigure coordination services. This paper investigates coordination components as a way to encapsulate the coordination of a distributed system into a separate, pluggable entity. In an object-oriented context we introduce two design guidelines (namely, “ turn contracts into objects ” and “turn configuration into a factory object ”) that help developers to separate coordination from computation and to develop reusable and flexible solutions for coordination in distributed systems.