object encapsulation and enable local reasoning about program correctness in object-oriented languages. However, a type system that enforces strict object encapsulation is too constraining: it does not allow e#cient implementation of important constructs like iterators. This paper argues that the right way to solve the problem is to allow objects of classes defined in the same module to have privileged access to each other's representations; we show how to do this for inner classes. This approach allows programmers to express constructs like iterators and yet supports local reasoning about the correctness of the classes, because a class and its inner classes together can be reasoned about as a module. The paper also sketches how we use our variant of ownership types to enable e#cient software upgrades in persistent object stores.

Schema versioning is one of a number of related areas dealing with the same general problem- that of using multiple heterogeneous schemata for various database related tasks. In particular, schema versioning, and its weaker companion, schema evolution, deal with the need to retain current data and software system functionality in the face of changing database structure. Schema versioning and schema evolution offer a solution to the problem by enabling intelligent handling of any temporal mismatch between data and data structure. This survey discusses the modelling, architectural and query language issues relating to the support of evolving schemata in database systems. An indication of the future directions of schema versioning research are also given.

Making software reliable is one of the most important technological challenges facing our society today. This thesis presents a new type system that addresses this problem by statically preventing several important classes of programming errors. If a program type checks, we guarantee at compile time that the program does not contain any of those errors. We designed our type system in the context of a Java-like object-oriented language; we call the resulting system SafeJava. The SafeJava type system offers significant software engineering benefits. Specifically, it provides a statically enforceable way of specifying object encapsulation and enables local reasoning about program correctness; it combines effects clauses with encapsulation to enable modular checking of methods in the presence of subtyping; it statically prevents data races and deadlocks in multithreaded programs, which are known to be some of the most difficult programming errors to detect, reproduce, and

Achieving correct changes is the dominant activity in the application software industry. Modification of database schemata is one kind of change which may have severe consequences for database applications. The paper presents a method for measuring modifications to database schemata and their consequences, by using a thesaurus tool. Measurements of the evolution of a large-scale database application currently running in several hospitals in the UK are presented and interpreted. The kind of measurements provided by this in-depth study is useful input to the design of change management tools. Keywords: Schema evolution, change statistics, change management tools. * Published in: Information and Software Technology, Vol. 35, No. 1, pp. 35-44, January 1 1 Introduction One of the most challenging problems of building and maintaining large, long-lived application systems is to cope with all the changes that inevitably will be imposed on the systems over time. Many large application systems...

Persistent object stores require a way to automatically upgrade persistent objects, to change their code and storage representation. Automatic upgrades are a challenge for such systems. Upgrades must be performed in a way that is efficient both in space and time, and that does not stop application access to the store. In addition, however, the approach must be modular: it must allow programmers to reason locally about the correctness of their upgrades similar to the way they would reason about regular code. This paper provides solutions to both problems. The paper first defines upgrade...

This paper presents some of the more signi cant technical lessons that the Arcadia project has learned about developing e ective software development environments. The principal components of the Arcadia-1 architecture are capabilities for process de nition and execution, object management, user interface development and management, measurement and evaluation, language processing, and analysis and testing. In simultaneously and cooperatively developing solutions in these areas welearned several key lessons. Among them: the need to combine and apply heterogenous componentry, multiple techniques for developing components, the pervasive need for rich type models, the need for supporting dynamism (and at what granularity), the role and value of concurrency, and the role and various forms of event-based control integration mechanisms. These lessons are explored in the paper. 1

When a database is shared by many users, updates to the database schema are almost always prohibited because there is a risk of making existing application programs obsolete when they run against the modified schema. This paper addresses the problem by integrating schema evolution with view facilities. Each user is assigned his or her own database view, and develops application programs against the view. When new requirements necessitate schema updates for a particular user, then the user specifies schema changes to his personal view rather than to the shared base schema. Our view schema evolution approach then computes a new view schema that reflects the semantics of the desired schema change, and replaces the old view with the new one. This approach provides the means for schema change without affecting other views (and thus without affecting existing application programs). The persistent data is shared by different views of the schema, i.e. by both old as well as newly developed app...

Schema evolution is a problem that is faced by long-lived data. When a schema changes, existing persistent data can become inaccessible unless the database system provides mechanisms to access data created with previous versions of the schema. Most existing systems that support schema evolution focus on changes local to individual types within the schema, thereby limiting the changes that the database maintainer can perform. We have developed a model of type changes incorporating changes local to individual types as well as compound changes involving multiple types. The model describes both type changes and their impact on data by defining derivation rules to initialize new data based on the existing data. The derivation rules can describe local and nonlocal changes to types to capture the intent of a large class of type change operations. We have built a system called Tess (Type Evolution Software System) that uses this model to recognize type changes by comparing schemas and then produces a transformer that can update data in a database to correspond to a newer version of the schema.

this paper, we propose a sound and complete axiomatic model for DSE in OBSs. The main benefit of the model is the formalization of DSE characteristics into a welldefined set of axioms. The axioms automatically maintain complex schema relationships and properties from two input sets associated with each type in a schema. The elements of these sets can be provided by the user, schema designer, system, or a combination of sources. One set is called the essential supertypes and contains the types that must be maintained as supertypes of a type for as long as it is consistently possible. The other set is called the essential properties and contains the properties that must be maintained in the type for as long as it is consistently possible. The correct properties and relationships within the schema are automatically derived by the axiomatic model using the essential supertypes and essential properties as a basis. The derivations performed by the axiomatic model have a proven soundness, completeness, and termination. The inclusion/exclusion of axioms in the model leads to a design space that categorizes OBSs into object-based, type-based, and object-oriented systems. The last category is further refined into several distinct subcategories that vary in functionality and expressiveness. To illustrate the power and practical usefulness of the model, the DSE operations of several existing OBSs are reduced to the axiomatic model and compared within this common framework. In recent years, researchers have addressed the problem of defining DSE policies for OBSs. These studies approach the issue from the perspective of individual systems. The axiomatic model is unique in this respect in that it captures and formalizes the salient features of DSE in OBSs and can be adopted as a commo...

. In this paper, we address the problem of supporting more flexibility on the schema of object-oriented databases. We describe a general framework based on an object-oriented data model, where three levels of objects are distinguished: data objects, schema objects, and metaschema objects. We discuss the prerequisites for applying the query and update operations of an object algebra uniformly on all three levels. As a sample application of the framework, we focus on database evolution, that is, realizing incremental changes to the database schema and their propagation to data instances. We show, how each schema update of a given taxonomy is realized by direct updating of schema objects, and how this approach can be used to build a complete tool for database evolution. 1 Introduction There is an increasing need for database evolution facilities, offering more flexibility on the logical structure of object-oriented databases (OODBs). On the one hand, schema evolution is the basic prereq...