Editorial Nowadays, software development is being increasingly viewed as the process of creating families of systems instead of building individual applications. In domains such as telecommunications or logistics, application variants have to be produced to fulfil the changing needs of widely different markets, comply with a great variety of standards, and run on a broad range of platforms. Object-orientation has often been promoted as the most effective approach to master software variability. Inheritance, late binding, and genericity make it possible to extend and customize software without having to modify any existing code. It is this capability for incremental modification more than anything else that differentiates object-oriented languages from other modern programming languages. While its benefits are apparent and largely recognized, this technology has also led many software engineers to rely on incremental modification as an easy way to delay hard design decisions. This incremental modification syndrome is compounded by the fact that object-oriented analysis and design methods have so far provided little, if any, support for evolutionary software development and reuse. The results are systems overloaded with patches and workarounds, and exhibiting poor flexibility and adaptability. When a reorganization ends up being inescapable, these systems have usually become so large and are so widely used that modifications are extremely time-consuming, error-prone, and, thereby, very expensive. Early adopters of object-orientation are already facing the challenging task of managing the evolution of large, long-lived systems with little methodological or tool support. For example, software engineers at Nokia have to maintain object-oriented systems consisting of over 10,000 classes and several millions of lines of C++ code. In a sense, it can be said that legions of C++ and Smalltalk—and now Java—programmers have been diligently at work to develop the legacy systems of tomorrow—with a productivity far exceeding that of the C, Fortran, or Cobol coders of the past. Nowadays, engineering, telecommunications, and manufacturing companies are the hardest hit by this problem. Given the pace at which all economic sectors are taking up object-orientation, re-engineering object-oriented sys- c 1997 John Wiley & Sons, Inc. tems is quickly becoming a strategical consideration for companies that rely extensively on this technology. The banking sector, which has been investing significantly in it for advanced financial services, and small and medium sized enterprises, that have migrated to Delphi and Visual C++ from their earlier C, Basic, or Pascal environments, should experience similar difficulties in a not too distant future. The fact that applications must be re-engineered to correct an inadequate design had been noticed quite early on in the history of object-oriented programming. The first proposals addressing this issue (mainly in the area of object-oriented databases) were widely published about ten years ago. Since then, several techniques have been developed, though very few have been tested in real cases . However, the topic left its status of an arcane research theme only in the past couple of years. Workshops have been organized by the editors of this special issue at OOPSLA in 1995 and 1996, and at ECOOP in 1997, gathering an attendance that has grown regularly at each edition. The organization of a technical session devoted to refactoring and reuse at OOPSLA’96 further demonstrates that software evolution and re-engineering is emerging as an important area in the object-oriented community. It is in this context that Nokia, together with Daimler-Benz (Germany), TakeFive Software (Austria), SEMA Group (Spain), FZI (Germany), and the University of Bern (Switzerland) launched “FAMOOS”1 in 1996, a project to elaborate practical methods and tools for object-oriented software evolution, and to apply them concretely to the re-engineering of very large C++ and Ada systems. Besides raising the awareness about the darker side of object-oriented technology, the goal of this special issue is to present solutions and ideas for the management and reengineering of mature, large-scale object-oriented systems. The three contributions to the special issue highlight different facets of the problem, and provide original approaches to tackle the problem of object-oriented software evolution. Inheritance has many different uses in object-oriented programming: conceptual specialization, subtyping, code sharing . The incremental modification syndrome is closely related to the distinction between these concepts, as resorting to incremental alterations instead of a more comprehensive overhaul often leaves a system with grave design problems unresolved. In his paper, Hernán As- THEORY AND PRACTICE OF OBJECT SYSTEMS, Vol. 3(4), 233–234 1997 CCC 1074-3227/97/040233-02 tudillo shows how the various usages of inheritance can be reconciled in a single conceptual framework. He proposes a technique to reorganize an inheritance graph that achieves both optimal code sharing and clean conceptual relationships among classes. His method draws on previous results from biological sciences and from type theory; the underlying idea of restructuring a class relation along multiple dimensions simultaneously should open new directions to the development of class reorganization algorithms—which has been a major field of study in the area of object-oriented software evolution since the very beginning. In general, the transformation of a first-generation object system into a flexible, reusable framework must deal with all aspects of object-orientation, not just inheritance. In this context, reorganizations become much more intricate, seemingly trivial changes such as modifying the name of a class can have far-reaching implications, and knowledge of reorganization strategies plays a major role in the success of the re-engineering process. The interactive tool described by Don Roberts, John Brant, and Ralph Johnson in their article represents, therefore, a good example of the kind of environment that is needed to support re-engineering tasks efficiently. Their refactoring browser provides a set of common transformations that can be combined to form high-level, complex re-engineering procedures. Special routines detect the impact of changes and alter the software to preserve its behavior—possibly at run time, should the extensive analysis and immediate modification of the source code be impractical. The refactoring browser has found acceptance in the Smalltalk community, and is in use throughout industry and academia; we hope that future generations of development environments for languages such as Java and C++ will have browsers and programming tools extended with similar refactoring facilities. In contrast to corrective measures, preventive approaches cope with software evolution by providing software engineers with the knowledge required to build object-oriented systems that are inherently adaptable and maintainable. Such a knowledge is often formalized as 234 THEORY AND PRACTICE OF OBJECT SYSTEMS–1997 software structures, design patterns, or system architectures. In their paper, Kai-Uwe Mätzel and Walter Bischofberger build upon this body of knowledge to handle both anticipated and unanticipated changes during object-oriented design. The article classifies various mechanisms to introduce flexible coupling in a system, and provides guidelines as to their appropriate utilization. These mechanisms can also serve as targets for re-engineering operations. The paper documents (partly) the rich experience of the developers of Sniff and Beyond Sniff in building flexible frameworks, and should, therefore, be a worthwhile reading for all object-oriented software engineers and re-engineers alike. Managing the evolution of object-oriented software will probably always remain a hard, on-going process for experienced software engineers. The contributions to this special issue do not claim to bring a definitive solution to this problem; nevertheless, they demonstrate that substantial progress has been made towards a comprehensive methodology and scaleable tools that should ultimately alleviate the pains of a growing number of developers struggling with the maintenance of their object-oriented software legacy. Eduardo Casais Antero Taivalsaari Guest Editors Notes 1. FAMOOS stands for Framework-based Approach for Mastering Object Oriented Software evolution. The project (No. 21975) is carried out in the context of the ESPRIT-IV IT programme of the European Union, and described in http://dis.sema.es/projects/FAMOOS. References  Casais, E. (1995). Managing class evolution in object-oriented systems, in Object-Oriented Software Composition, O. Nierstrasz and D. Tsichritzis, (Eds.) Prentice Hall, 201–244.  Taivalsaari, A. (September 1996). On the notion of inheritance. ACM Computing Surveys 28(3), 438–479.