We describe a system called Polylith that helps programmers prepare and interconnect mixed-language software components for execution in heterogeneous environments. Polylith's principal benefit is that programmers are free to implement functional requirements separately from their treatment of interfacing requirements; this means that once an application has been developed for use in one execution environment (such as a distributed network) it can be adapted for reuse in other environments (such as a shared-memory multiprocessor) by automatic techniques. This flexibility is provided without loss of performance. We accomplish this by creating a new run-time organization for software. An abstract decoupling agent, called the software bus, is introduced between the system components. Heterogeneity in language and architecture is accommodated since program units are prepared to interface directly to the bus, not to other program units. Programmers specify application structure in terms of ...

Rights to individual papers remain with the author or the author's employer. Permission is granted for noncommercial reproduction of the work for educational or research purposes. This copyright notice must be included in the reproduced paper. USENIX acknowledges all trademarks herein.

In a typical file system, only the current version of a file (or directory) is available. In Wayback, a user can also access any previous version, all the way back to the file’s creation time. Versioning is done automatically at the write level: each write to the file creates a new version. Wayback implements versioning using an undo log structure, exploiting the massive space available on modern disks to provide its very useful functionality. Wayback is a userlevel file system built on the FUSE framework that relies on an underlying file system for access to the disk. In addition to simplifying Wayback, this also allows it to extend any existing file system with versioning: after being mounted, the file system can be mounted a second time with versioning. We describe the implementation of Wayback, and evaluate its performance using several benchmarks. 1

We present a new approach to the control of versions of software and other hierarchically structured entities. Any part of a system, from the smallest component to a complete system, may exist in different versions. The set of all possible versions under the refinement relation forms a partial order (in fact, a lattice). The fact that version V approximates version V in this order means that V is relevant to V in this sense: when constructing version V of a system, we can sometimes use version V of a component if nothing more appropriate is available. More precisely, a particular version of an entire system is formed by combining the most relevant existing versions of the various components of the system. We call this the variant structure principle; it makes precise the idea that components of a given version of the system can be inherited by more refined versions of the system.

Recently there has been considerable work toward standardizing SEFs (software exchange formats) for interchange of information about source programs. An exchange format is a common textual form for data extracted from source programs and used by a variety of software analysis and visualization tools. An SEF can be further specified by a schema, analogous to a schema for a data base. This paper explains how a schema union, which is combination of schemas, can be used as the basis for creating an extractor. The paper describes the CPPX extractor, which transforms GCC output (satisfying the internal schema of the GCC compiler) to a new format (satisfying a schema designed for exchange, namely that of the Datrix project). CPPX performs this transformation as a pipelined sequence of sub-transformations. At each stage in the pipeline, the intermediate data conforms to the union of the two schemas. Keywords:

A comprehensive versioning file system creates and retains a new file version for every WRITE or other modification request. The resulting history of file modifications provides a detailed view to tools and administrators seeking to investigate a suspect system state. Conventional versioning systems do not efficiently record the many prior versions that result. In particular, the versioned metadata they keep consumes almost as much space as the versioned data. This paper examines two space-efficient metadata structures for versioning file systems and describes their integration into the Comprehensive Versioning File System (CVFS). Journal-based metadata encodes each metadata version into a single journal entry; CVFS uses this structure for inodes and indirect blocks, reducing the associated space requirements by 80%. Multiversion b-trees extend the per-entry key with a timestamp and keep current and historical entries in a single tree; CVFS uses this structure for directories, reducing the associated space requirements by 99%. Experiments with CVFS verify that its current-version performance is similar to that of non-versioning file systems. Although access to historical versions is slower than conventional versioning systems, checkpointing is shown to mitigate this effect.

"Industrial strength" software development environments (SDEs) must provide facilities to address three essential properties of multi-developer software systems: evolution, complexity and scale. It is my contention that in order to be an industrial strength SDE, an environment must support at least a city model environment. Moreover, SDEs must include such high level policies as supporting cooperation and communication, supporting a unified process and product, providing multiple means of expression, supporting inter- and intraconnections, managing the change process and managing the multiplicity of versions. Underlying the implementation of these policies are three themes: developer-machine symbiosis in which the machine becomes an active partner in system development and evolution; formalization of the development/evolution process so that we can reason about the process and automate its support; and finally, formalization of the software product so that we can reason about it and au...

Architectural designs specify the components of a software system, their interfaces, and their interrelationships. Module Interconnection Languages (MILs) are useful for specifying architectural designs, but lack an intuitive visual representation similar to the visual design notations found in CASE tools. This paper presents a framework for formally defining the syntax and semantics of languages for specifying and visualizing architectural designs. Also described are an instance and prototype implementation of this framework consisting of two languages: one for specifying designs and one for visualizing them. 1 Background One of the phases of the software development process is the specification of the system's components, their interfaces, and their interrelationships. Throughout this paper, we will refer to the product of this phase as the architectural design. Our definition of architectural design is close to the definition of software architecture given by Schwanke, Altucher, ...

In building systems there are various levels at which we consider the problems reasoning about consistency and it means different things at those various levels. At the version management level, consistency means what it does in databases: no data is lost due to concurrency problems (eg, race conditions). At the composition and substitution (or creation and evolution) levels it means something that is significantly different--- namely, the syntactic and semantic consistency of the various pieces that make up the system. I first address the issue of what makes a system composition well-formed both syntactically and semantically. I then address the issue of substitution in well-formed system compositions, first in the context of simple substitution and then in the context of compound substitution (that is, the simultaneous substitution of multiple components). Note: This paper derived and extended from papers: the well-formed system composition paper [9] was published only as a technical report at CMU (though variously used without references or with misleading ones) the version control paper from ICSE9 [16], the extended abstract for SCM3 [19], and the shared dependency paper from SCM6 [20] all of which have been published only in conference or workshop versions. There may be parts of the other Inscape papers (ICSE9 [15], ICSE11 [17], and TAV3 [18]) included as well- all of which have been published only in conference versions.

Design patterns describe common features of software systems. Notations intended to describe individual programs are unsuitable for formalizing patterns because they are not su#ciently abstract, expressive, and well-defined. We describe LePUS, a notation that is both formal and su#ciently abstract to represent patterns and provide a framework for reasoning about them. The key features of LePUS are that: it is based on conventional logic; it models meaning as well as structure; and it facilitates reasoning with higher order sets that we have found to occur frequently in design patterns. Although the main focus of this paper is on design patterns, the techniques that we describe can also be applied to architectures. 1 Introduction As the complexity of software has steadily increased, notations for describing software have moved to ever higher levels of abstraction. Starting from machine code and progressing through assembly languages, imperative programming languages, and declarative p...