If we do not learn to manage change, we will become its victims, not its beneficiaries. Edward H. Bersoff and Alan M. Davis [BD91]
Object-oriented software systems, as all software systems, are usually not developed in one shot", but rather are subject to ample restructuring and reprogramming during their whole life cycle. The popularity of evolutionary and/or prototyping models of software development life cycles demonstrates this [BD91].
There are primarily three situations where class reorganization is required: Firstly, the motivation to improve the class organization of an object-oriented system often arises during development after a large part of the system has already been built. It is typically a case of hindsight by which one realizes that the class organization can be improved. This presents a dilemma to application developers. They can continue to write the application with the no longer adequately designed classes or take on the tougher task of improving their classes and adapt the already written software, with the hope that it will pay off in the long run. With no tools available to manage the evolution and in the presence of deadlines and other forms of pressure to finish their task, programmers are often tempted to take the easy way out. In this article, we will present a framework for object-oriented software evolution that will help manage the evolution process. A second reason for class reorganization addresses the need of adapting old code and class structures that are being reused in a new application. This is the case even if standard class libraries are used, since the libraries themselves are subject to changes. As an example, the Eiffel libraries were partly redesigned with the second version of the language [Mey90]. Thirdly, later in their life cycle, applications often need to integrate further functionality or have to conform to additional constraints resulting also in change of existing software.
For the reorganization of class hierarchies, the issue of reusing as much as possible of the old design components is paramount. This reuse of object-oriented design represents a coarse grained level of reuse which still lacks a common terminology and means of classification. This article discusses the evolution of object-oriented systems modeled by class dictionary graphs, the key structures in the Demeter data model described in section 2. In section 3 we present a set of high level extension relations that provide a means for management and classification of object-oriented software evolution. The extension relations can be decomposed into a set of primitive relations which form a minimal and complete basis for class dictionary graph extensions. The mathematical foundation of class dictionary graphs is used to give a proof of this. Section 4 analyzes the impact of the extension relations on the objects that are defined by the extended class dictionary graphs. We close with a section on related work and a conclusion.
2 The Demeter Data Model
This study uses the Demeter data model because of its concise mathematical notation and its ability to model classes with both their inheritance and part-of relationship in a uniform theory. These two features make it an ideal foundation for theoretical studies. [LBSL91, LX91a] define