Previous taxonomies of software change have focused on the purpose of the change (i.e., the why) rather than the underlying mechanisms. This paper proposes a taxonomy of software change based on characterizing the mechanisms of change and the factors that influence these mechanisms. The ultimate goal of this taxonomy is to provide a framework that positions concrete tools, formalisms and methods within the domain of software evolution. Such a framework would considerably ease comparison between the various mechanisms of change. It would also allow practitioners to identify and evaluate the relevant tools, methods and formalisms for a particular change scenario. As an initial step towards this taxonomy, the paper presents a framework that can be used to characterize software change support tools and to identify the factors that impact on the use of these tools. The framework is evaluated by applying it to three different change support tools and by comparing these tools based on this analysis.

No abstract

No abstract

We identify three programming language abstractions for the construction of reusable components: abstract type members, explicit selftypes, and modular mixin composition. Together, these abstractions enable us to transform an arbitrary assembly of static program parts with hard references between them into a system of reusable components. The transformation maintains the structure of the original system. We demonstrate this approach in two case studies, a subject/observer framework and a compiler front-end.

We present a type system for a language based on F ≤ , which allows certain type annotations to be elided in actual programs. Local type inference determines types by a combination of type propagation and local constraint solving, rather than by global constraint solving. We refine the previously existing local type inference system of Pierce and Turner[PT98] by allowing partial type information to be propagated. This is expressed by coloring types to indicate propagation directions. Propagating partial type information allows us to omit type annotations for the visitor pattern, the analogue of pattern matching in languages without sum types.

A major problem for writing extensible software arises when recursively defined datatypes and operations on these types have to be extended simultaneously without modifying existing code. This paper introduces Extensible Algebraic Datatypes with Defaults which promote a simple programming pattern to solve this well known problem. We show that it is possible to encode extensible algebraic datatypes in an object-oriented language, using a new design pattern for extensible visitors. Extensible algebraic datatypes have been successfully applied in the implementation of an extensible Java compiler. Our technique allows for the reuse of existing components in compiler extensions without the need for any adaptations.

Abstract. Component-based programming is currently carried out using mainstream object-oriented languages. These languages have to be used in a highly disciplined way to guarantee flexible component composition and extensibility. This paper investigates abstractions for component-oriented programming on the programming language level. We propose a simple prototype-based model for first-class components on top of a class-based object-oriented language. The model is formalized as an extension of Featherweight Java. Our calculus includes a minimal set of primitives to dynamically build, extend, and compose software components, while supporting features like explicit context dependencies, late composition, unanticipated component extensibility, and strong encapsulation. We present a type system for our calculus that ensures type-safe component definition, composition, and evolution.

We present the programming language KERIS, an extension of Java with explicit support for software evolution. KERIS introduces extensible modules as the basic building blocks for software. Modules are composed hierarchically, explicitly revealing the architecture of systems. A distinct feature of the module design is that modules do not get linked manually. Instead, the wiring of modules gets inferred. The module assembly and refinement mechanism of KERIS is not restricted to the unanticipated extensibility of atomic modules. It also allows extensions of already linked systems by replacing selected submodules with compatible versions without needing to re-link the full system. Extensibility is type-safe and noninvasive, i.e., the extension of a module preserves the original version and does not require access to source code.Modules, as architectural building blocks, are subject to continuous change. We consider this lack of support for unanticipated extensibility to be a serious shortcoming. In practice, one is required to use ad-hoc techniques to introduce changes in modules. In most cases this comes down to hacking the changes into the source code of the corresponding modules. This obviously contradicts the idea of deploying compiled module binaries. However, even for cases where the source code is available, invasive changes such as source code modifications are considered error-prone. With modifications on the source code level one risks invalidating the use of modules in contexts where they get already successfully deployed.The design of the programming language KERIS includes primitives for creating and linking modules as well as mechanisms for extending modules or even fully linked programs statically. KERIS' type system ensures that the definition, assembly and evolution of modules is safe. Programs written in KERIS are closed in the sense that they can be executed, but they are open for extensions that statically add, refine or replace modules or whole subsystems of interconnected modules. Extensibility does not have to be planned ahead and does not require modifications of existing source code, promoting a smooth software evolution process.In this paper we introduce KERIS as an extension of the programming language Java. In Section 2 we substantiate the need for linguistic abstractions in object-oriented programming languages for programming in the large and for evolving systems safely in the large. In Section 3 we present the design of the programming language KERIS by a stepwise introduction of KERIS' extensible module abstractions. The examples presented in Section 4 explain how extensible modules support family polymorphism. Section 5 gives an informal overview over the type-system. Our prototypical implementation of the KERIS compiler gets briefly reviewed in Section 6, followed by a discussion of related work in Section 7. Section 8 concludes. MOTIVATIONLike many popular object-oriented languages, Java does not provide suitable abstractions for programming in the large [4]. In this section we argu...