A concurrent object is a data object shared by concurrent processes. Linearizability is a correctness condition for concurrent objects that exploits the semantics of abstract data types. It permits a high degree of concurrency, yet it permits programmers to specify and reason about concurrent objects using known techniques from the sequential domain. Linearizability provides the illusion that each operation applied by concurrent processes takes effect instantaneously at some point between its invocation and its response, implying that the meaning of a concurrent object’s operations can be given by pre- and post-conditions. This paper defines linearizability, compares it to other correctness conditions, presents and demonstrates a method for proving the correctness of implementations, and shows how to reason about concurrent objects, given they are linearizable.

The use of hierarchy is an important component of object-oriented design. Hierarchy allows the use of type families, in which higher level supertypes capture the behavior that all of their subtypes have in common. For this methodology to be effective, it is necessary to have a clear understanding of how subtypes and supertypes are related. This paper takes the position that the relationship should ensure that any property proved about supertype objects also holds for its subtype objects. It presents two ways of defining the subtype relation, each of which meets this criterion, and each of which is easy for programmers to use. The subtype relation is based on the specifications of the sub- and supertypes; the paper presents a way of specifying types that makes it convenient to define the subtype relation. The paper also discusses the ramifications of this notion of subtyping on the design of type families.

Abstract not found

The testing process is typically systematic in test data selection and test execution. For the most part, however, the effective use of test oracles has been neglected, even though they are a critical component of the testing process. Test oracles prescribe acceptable behavior for test execution. In the absence of judging test results with oracles, testing does not achieve its goal of revealing failures or assuring correct behavior in a practical manner; manual result checking is neither reliable nor cost-effective. We argue that test oracles should be derived from specifications and in conjunction with testing criteria, represented in a common form, and their use made integral to the testing process. For complex, reactive systems, oracles must reflect the multiparadigm nature of the required behavior. Such systems are often specified using multiple languages, each selected for its utility in specifying a particular computational paradigm. Thus, we are developing an approach for derivi...

The Inscape Environment is an integrated software development enviroment for building large software systems by large groups of developers. It provides tools that are knowledgeable about the process of system construction and evolution and that work in symbiosis with the system builders and evolvers. These tools are integrated around the constructive use of formal module interface specifications. We first discuss the problems that Inscape addresses, outline our research strategies and approaches to solving these problems, and summarize the contributions of the Inscape Environment. We then discuss the major aspects

Current research in specifications is emphasizing the practical use of formal specifications in program design. One way to encourage their use in practice is to provide specification languages that are accessible to both designers and programmers. With this goal in mind, the Larch family of formal specification languages has evolved to support a two-tiered approach to writing specifications. This approach separates the specification of state transformations and programming language dependen-cies from the specification of underlying abstractions. Thus, each member of the Larch family has a subset derived from a programming language and another subset independent of any programming languages. We call the former interface languages, and the latter the Larch Shared Language. This paper focuses on Larch interface language specifications. Through examples, we illustrate some salient features of Larch/CLU, a Larch interface language for the programming language CLU. We give an example of writing an interface specification following the two-tiered approach and discuss in detail issues involved in writing interface specifications and their interaction with their Shared Language components.

Inheritance is well-known and accepted as a mechanism for reuse in object-oriented languages. Unfortunately, due to the coarse granularity of inheritance, it may be difficult to decompose an application into an optimal class hierarchy that maximizes software reuse. Existing schemes based on single inheritance, multiple inheritance, or mixins, all pose numerous problems for reuse. To overcome these problems we propose traits, pure units of reuse consisting only of methods. We develop a formal model of traits that establishes how traits can be composed, either to form other traits, or to form classes. We also outline an experimental validation in which we apply traits to refactor a non-trivial application into composable units.

We present a formulation of interconnection models and present the unit and syntactic models --- the primary models used for managing the evolution of large software systems. We discuss various tools that use these models and evaluate how well these models support the management of system evolution. We then introduce the semantic interconnection model. The semantic interconnection model incorporates the advantages of the unit and syntactic interconnection models and provides extremely useful extensions to them. By refining the grain of interconnections to the level of semantics (that is, to the predicates that define aspects of behavior) we provide tools that are better suited to manage the details of evolution in software systems and that provide a better understanding of the implications of changes. We do this by using the semantic interconnection model to formalize the semantics of program construction, the semantics of changes, and the semantics of version equivalence and compatibi...

We investigate the use of the dot notation in the context of abstract types. The dot notation—that is, a.f referring to the operation f provided by the abstraction a—is used by programming languages such as Modula-2 and CLU. We compare this notation with the Mitchell-Plotkin approach, which draws a parallel between type abstraction and (weak) existential quantification in constructive logic. The basic operations on existentials coming from logic give new insights about the meaning of type abstraction, but differ completely from the more familiar dot notation. In this paper, we formalize simple calculi equipped with the dot notation, and relate them to a more classical calculus à la Mitchell and Plotkin. This work provides some theoretical foundations for the dot notation, and suggests some useful extensions.

Abstract not found