Sander Tichelaar - Academia.edu (original) (raw)

Uploads

Papers by Sander Tichelaar

Whereas a design pattern describes and discusses a solution to a design problem, a reverse engine... more Whereas a design pattern describes and discusses a solution to a design problem, a reverse engineering pattern describes how to understand aspects of an object-oriented design and how to identify problems in that design. In the context of a project developing a methodology for reengineering objectoriented legacy systems into frameworks, we are working on a pattern language for reengineering. This paper presents three samples of that pattern language, all dealing with reverse engineering. 1 1 Note that some colleagues of ours have submitted another document discussing patterns for the related problem of reengineering. This other submission is entitled "Type-Check Elimination: Two Reengineering Patterns".

Tools support is recognised as a key issue in the reengineering of large scale object-oriented sy... more Tools support is recognised as a key issue in the reengineering of large scale object-oriented systems. However, due to the heterogeneity in today's object-oriented programming languages, it is hard to reuse reengineering tools across legacy systems. This paper proposes a language independent exchange model, so that tools may perform their tasks independent of the underlying programming language. Beside supporting reusability between tools, we expect that this exchange model will enhance the interoperability between tools for metrics, visualization, reorganisation and other reengineering activities.

Nowadays development environments are required to be open: users want to be able to work with a c... more Nowadays development environments are required to be open: users want to be able to work with a combination of their preferred commercial and home-grown tools. TakeFive has opened up SNiFF+ with a so-called "Symbol Table API"; Rational has opened up the UML tool Rose via the so-called "Rose Extensibility Interface (REI)". On the other hand, efforts are underway to define standards for exchanging information between case-tools; CDIF being a notable example. This paper reports on our experience to generate UML diagrams in Rational Rose from the symbol table in SNiFF+ using a standard CDIF exchange format.

Surprising as it may seem, many of the early adopters of the object-oriented paradigm already fac... more Surprising as it may seem, many of the early adopters of the object-oriented paradigm already face a number of problems typically encountered in large-scale legacy systems. The reengineering of those systems often poses problems because of the considerable size and complexity of such systems. In the context of the FAMOOS project we have developed a language independent environment called Moose which can deal with that complexity. This paper describes the architecture of Moose, the tools which have been developed around it and the industrial experiences we have obtained.

Lecture Notes in Computer Science, Oct 28, 1999

UML is currently embraced as "the" standard in object-oriented modeling languages, the recent wor... more 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.

Recently exchange formats have gained lots of attention. Multiple tools need to interact and/or w... more Recently exchange formats have gained lots of attention. Multiple tools need to interact and/or work on the same 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 modelbased information exchange.

Refactoring-transforming code while preserving behaviour-is currently considered a key approach f... more Refactoring-transforming code while preserving behaviour-is currently 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. In this paper 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 languageindependent 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.

Lecture Notes in Computer Science, 1999

UML is currently embraced as "the" standard in object-oriented modeling languages, the recent wor... more 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.

Journal of Software Maintenance and Evolution: Research and Practice, 2003

Over the last decade many research groups and commercial companies have been developing reenginee... more 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.

In the FAMOOS project we have developed a set of tools for reengineering object-oriented legacy s... more In the FAMOOS project we have developed a set of tools for reengineering object-oriented legacy systems. These tools are based on the FAMIX meta model and exchange information using CDIF, an industry standard exchange format. For several reasons XMI, an emerging standard for information exchange, has appealed to us to be used as our interchange format. In this paper we discuss why XMI is interesting for us and what, to our current experience, are the advantages and disadvantages of XMI over CDIF.

This document describes the language plug-in to the FAMIX 2.0 model for the Java programming lang... more This document describes the language plug-in to the FAMIX 2.0 model for the Java programming language. It handles interpretation issues concerning Java in FAMIX and the extension of the FAMIX model for Jav specific features.

Whereas a design pattern describes and discusses a solution to a design problem, a reverse engine... more Whereas a design pattern describes and discusses a solution to a design problem, a reverse engineering pattern describes how to understand aspects of an object-oriented design and how to identify problems in that design. In the context of a project developing a methodology for reengineering object-oriented legacy systems into frameworks, weare working on a pattern language for reengineering. This paper presents three samples of that pattern language, all dealing with reverse engineering.

Nowadays development environments are required to be open: users want to be able to work with a c... more Nowadays development environments are required to be open: users want to be able to work with a combination of their preferred commercial and home-grown tools. TakeFive has opened up SNiFF+ with a so-called "Symbol Table API"; Rational has opened up the UML tool Rose via the so-called "Rose Extensibility Interface (REI)". On the other hand, efforts are underway to define standards for exchanging information between case-tools; CDIF being a notable example. This paper reports on our experience to generate UML diagrams in Rational Rose from the symbol table in SNiFF+ using a standard CDIF exchange format.

In the FAMOOS project we have developed a set of tools for reengineering object-oriented legacy s... more In the FAMOOS project we have developed a set of tools for reengineering object-oriented legacy systems. These tools are based on the FAMIX meta model and exchange information using CDIF, an industry standard exchange format. For several reasons XMI, an emerging standard for information exchange, has appealed to us to be used as our interchange format. In this paper we discuss why XMI is interesting for us and what, to our current experience, are the advantages and disadvantages of XMI over CDIF.

Proceedings Ninth International Workshop on Database and Expert Systems Applications (Cat. No.98EX130)

Most of the work on coordination technology so far has focused on the development of special coor... more Most of the work on coordination technology so far has focused on the development of special coordination languages and environments that provide the basic mechanisms for realizing the coordination layer of an open system. It is clear that the idea of managing separately the coordination aspect from the computation in a language has a lot of advantages in the development of those systems. Nevertheless, most of the coordination languages do not take care that additionally to managing coordination requirements, they must manage other kinds of "openness" related requirements in Open Systems. The most important requirement being to support the evolution of the coordination requirements themselves. This problem manifests during the software development process by the development over and over again of solutions to similar coordination problems. To tackle this problem, and instead of proposing a new language, we are attempting to develop an open set of adaptable and reusable software components that realize various useful coordination abstractions. With these components we provide explicit separation of coordination from computation, and facilitate reuse and evolution of coordination aspects in Open Systems.

Whereas a design pattern describes and discusses a solution to a design problem, a reverse engine... more Whereas a design pattern describes and discusses a solution to a design problem, a reverse engineering pattern describes how to understand aspects of an object-oriented design and how to identify problems in that design. In the context of a project developing a methodology for reengineering objectoriented legacy systems into frameworks, we are working on a pattern language for reengineering. This paper presents three samples of that pattern language, all dealing with reverse engineering. 1 1 Note that some colleagues of ours have submitted another document discussing patterns for the related problem of reengineering. This other submission is entitled "Type-Check Elimination: Two Reengineering Patterns".

Tools support is recognised as a key issue in the reengineering of large scale object-oriented sy... more Tools support is recognised as a key issue in the reengineering of large scale object-oriented systems. However, due to the heterogeneity in today's object-oriented programming languages, it is hard to reuse reengineering tools across legacy systems. This paper proposes a language independent exchange model, so that tools may perform their tasks independent of the underlying programming language. Beside supporting reusability between tools, we expect that this exchange model will enhance the interoperability between tools for metrics, visualization, reorganisation and other reengineering activities.

Nowadays development environments are required to be open: users want to be able to work with a c... more Nowadays development environments are required to be open: users want to be able to work with a combination of their preferred commercial and home-grown tools. TakeFive has opened up SNiFF+ with a so-called "Symbol Table API"; Rational has opened up the UML tool Rose via the so-called "Rose Extensibility Interface (REI)". On the other hand, efforts are underway to define standards for exchanging information between case-tools; CDIF being a notable example. This paper reports on our experience to generate UML diagrams in Rational Rose from the symbol table in SNiFF+ using a standard CDIF exchange format.

Surprising as it may seem, many of the early adopters of the object-oriented paradigm already fac... more Surprising as it may seem, many of the early adopters of the object-oriented paradigm already face a number of problems typically encountered in large-scale legacy systems. The reengineering of those systems often poses problems because of the considerable size and complexity of such systems. In the context of the FAMOOS project we have developed a language independent environment called Moose which can deal with that complexity. This paper describes the architecture of Moose, the tools which have been developed around it and the industrial experiences we have obtained.

Lecture Notes in Computer Science, Oct 28, 1999

UML is currently embraced as "the" standard in object-oriented modeling languages, the recent wor... more 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.

Recently exchange formats have gained lots of attention. Multiple tools need to interact and/or w... more Recently exchange formats have gained lots of attention. Multiple tools need to interact and/or work on the same 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 modelbased information exchange.

Refactoring-transforming code while preserving behaviour-is currently considered a key approach f... more Refactoring-transforming code while preserving behaviour-is currently 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. In this paper 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 languageindependent 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.

Lecture Notes in Computer Science, 1999

UML is currently embraced as "the" standard in object-oriented modeling languages, the recent wor... more 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.

Journal of Software Maintenance and Evolution: Research and Practice, 2003

Over the last decade many research groups and commercial companies have been developing reenginee... more 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.

In the FAMOOS project we have developed a set of tools for reengineering object-oriented legacy s... more In the FAMOOS project we have developed a set of tools for reengineering object-oriented legacy systems. These tools are based on the FAMIX meta model and exchange information using CDIF, an industry standard exchange format. For several reasons XMI, an emerging standard for information exchange, has appealed to us to be used as our interchange format. In this paper we discuss why XMI is interesting for us and what, to our current experience, are the advantages and disadvantages of XMI over CDIF.

This document describes the language plug-in to the FAMIX 2.0 model for the Java programming lang... more This document describes the language plug-in to the FAMIX 2.0 model for the Java programming language. It handles interpretation issues concerning Java in FAMIX and the extension of the FAMIX model for Jav specific features.

Whereas a design pattern describes and discusses a solution to a design problem, a reverse engine... more Whereas a design pattern describes and discusses a solution to a design problem, a reverse engineering pattern describes how to understand aspects of an object-oriented design and how to identify problems in that design. In the context of a project developing a methodology for reengineering object-oriented legacy systems into frameworks, weare working on a pattern language for reengineering. This paper presents three samples of that pattern language, all dealing with reverse engineering.

Nowadays development environments are required to be open: users want to be able to work with a c... more Nowadays development environments are required to be open: users want to be able to work with a combination of their preferred commercial and home-grown tools. TakeFive has opened up SNiFF+ with a so-called "Symbol Table API"; Rational has opened up the UML tool Rose via the so-called "Rose Extensibility Interface (REI)". On the other hand, efforts are underway to define standards for exchanging information between case-tools; CDIF being a notable example. This paper reports on our experience to generate UML diagrams in Rational Rose from the symbol table in SNiFF+ using a standard CDIF exchange format.

In the FAMOOS project we have developed a set of tools for reengineering object-oriented legacy s... more In the FAMOOS project we have developed a set of tools for reengineering object-oriented legacy systems. These tools are based on the FAMIX meta model and exchange information using CDIF, an industry standard exchange format. For several reasons XMI, an emerging standard for information exchange, has appealed to us to be used as our interchange format. In this paper we discuss why XMI is interesting for us and what, to our current experience, are the advantages and disadvantages of XMI over CDIF.

Proceedings Ninth International Workshop on Database and Expert Systems Applications (Cat. No.98EX130)

Most of the work on coordination technology so far has focused on the development of special coor... more Most of the work on coordination technology so far has focused on the development of special coordination languages and environments that provide the basic mechanisms for realizing the coordination layer of an open system. It is clear that the idea of managing separately the coordination aspect from the computation in a language has a lot of advantages in the development of those systems. Nevertheless, most of the coordination languages do not take care that additionally to managing coordination requirements, they must manage other kinds of "openness" related requirements in Open Systems. The most important requirement being to support the evolution of the coordination requirements themselves. This problem manifests during the software development process by the development over and over again of solutions to similar coordination problems. To tackle this problem, and instead of proposing a new language, we are attempting to develop an open set of adaptable and reusable software components that realize various useful coordination abstractions. With these components we provide explicit separation of coordination from computation, and facilitate reuse and evolution of coordination aspects in Open Systems.