Stéphane Ducasse

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.

The LAN-simulation: a refactoring teaching example

The notion of refactoring - transforming the source-code of an object-oriented program without changing its external behaviour - has been studied intensively within the last decade. This diversity has created a plethora of toy-examples, cases and code snippets, which make it hard to assess the current state-of-the-art. Moreover, due to this diversity, there is currently no accepted way of teaching good refactoring practices, despite the acknowledgment in the software engineering body of knowledge. Therefore, this paper presents a common example - the LAN simulation - which has been used by a number of European Universities for both research and teaching purposes.The notion of refactoring —- transforming the source-code of an object-oriented program without changing its external behaviour —- has been studied intensively within the last decade. This diversity has created a plethora of toy-examples, cases and code snippets, which make it hard to assess the current state-of-the-art. Moreover, due to this diversity, there is currently no accepted way of teaching good refactoring practices, despite the acknowledgment in the software engineering body of knowledge. Therefore, this paper presents a common example —- the LAN simulation —- which has been used by a number of European Universities for both research and teaching purposes.

Object-oriented reengineering patterns — an overview

Successful software systems must be prepared to evolve or they will die. Although object-oriented software systems are built to last, over time they degrade as much as any legacy software system. As a consequence, one must invest in reengineering efforts to keep further development costs down. Even though software systems and their business contexts may differ in countless ways, the techniques one uses to understand, analyze and transform these systems tend to be very similar. As a consequence, one may identify various reengineering patterns that capture best practice in reverse- and re-engineering object-oriented legacy systems. We present a brief outline of a large collection of these patterns that have been mined over several years of experience with object-oriented legacy systems, and we indicate how some of these patterns can be supported by appropriate tools.

Objektorientierte Re-Engineering-Muster: ein Ãœberblick

Erfolgreiche Softwaresysteme mussen so konzipiert sein, dass sie sich weiterentwickeln konnen —- ansonsten gehen sie ein. Obwohl objektorientierte Softwaresysteme auf eine lange Lebensdaur ausgerichtet sind, veralten sie uber die Jahre genauso wie jedes andere Legacy-Softwaresystem. Um die weiteren Entwicklungskosten niedrig zu halten, mussen daher Investitionen im Bereich Re-Engineering getatigt werden. Softwaresysteme und der Geschaftskontext, in dem sie eingesetzt werden, unterscheiden sich in vielen Punkten —- dennoch ahneln sich Techniken, sie zu verstehen, zu analysieren und zu transformieren. Folglich lassen sich verschiedene Re-Engineering-Muster identifizieren, die bewahrte Vorgehensweisen beim Reverse- und Re-Engineering objektorientierter Legacy-Systeme beinhalten. Dieser Artikel stellt einen kleinen Ausschnitt aus einer gron Sammlung dieser Muster vor, die auf der mehrjahrigen Erfahrung mit objektorientierten Legacy-Systemen basieren. Daruber hinaus werden Hinweise gegeben, wie einige dieser Muster durch geeignete Werkzeuge unterstutzt werden konnen.