We present a general model of software development environments that consists of three components: structures, mechanisms and policies. The advantage of this model is that it distinguishes intuitively those aspects of an environment that are useful in comparing and contrasting software development environments. Our initial application of the model is to characterize four classes of environments by means of a sociological metaphor based on scale: the individual, the family, the city and the state models. The utility of the IFCS taxonomy is that it delineates the important classes of interactions among software developers and exposes the ways in which current software development environments inadequately support the development of large systems. We demonstrate the generality of our model by also applying it to a previously published taxonomy that categorizes environments according to how they relate to four historical trends: language-centered, structure-oriented, toolkit and method-bas...

In many execution environments software components cannot interoperate easily because of differences in their interfaces and implementations. Additional software is often required to integrate such components and implement the interfacing decisions between them. For example, a procedure call across architectures may require extensive software to relocate data and coerce parameters. Even when powerful integration facilities are available, application programs need some additional software --- often called `stubs' --- so they can access the available communication media. Interface software can be more expensive to program that other software, since its creation requires knowledge of the machine architectures and communication mechanisms. Moreover, it must be rewritten whenever components are reused in different configurations. This paper describes a way to automatically generate custom interface software for heterogeneous configurations. Whereas previous research focused on `stub generat...

Existing systems for software deployment are neither safe nor sufficiently flexible. Primary safety issues are the inability to enforce reliable specification of component dependencies, and the lack of support for multiple versions or variants of a component. This renders deployment operations such as upgrading or deleting components dangerous and unpredictable. A deployment system must also be flexible (i.e., policy-free) enough to support both centralised and local package management, and to allow a variety of mechanisms for transferring components. In this paper we present Nix, a deployment system that addresses these issues through a simple technique of using cryptographic hashes to compute unique paths for component instances.

The make command has been a central part of the UNIX* programming environment for over fifteen years. An excellent example of a UNIX system software tool, it has a simple model and delegates most of its work to other commands. By dealing with general relationships between files and commands, make easily adapts to diverse applications. This generality, however, has become a handicap when compared with specialized integrated programming environments. Integrated environments are collections of tightly coupled (seamless) programs that can take advantage of programming language details not available to the loosely coupled (tool-based) make model. There are limitations to both approaches, but it would seem that the make model, at least for software construction, is reaching the breaking point. make can be revitalized by abandoning restrictive implementation details and by extending the basic model to meet modern software construction demands. This paper explores these demands and changes an...

This document is an updated version of the Indian Hill C Style and Coding Standards paper, with modifications by the last three authors. It describes a recommended coding standard for C programs. The scope is coding style, not functional organization. February 14, -- -- Recommended C Style and Coding Standards L.W. Cannon R.A. Elliott L.W. Kirchhoff J.H. Miller J.M. Milner R.W. Mitze E.P. Schan N.O. Whittington Bell Labs Henry Spencer Zoology Computer Systems University of Toronto David Keppel EECS, UC Berkeley CS&E, University of Washington Mark Brader SoftQuad Incorporated Toronto 1. Introduction This document is a modified version of a document from a committee formed at AT&T's Indian Hill labs to establish a common set of coding standards and recommendations for the Indian Hill community. The scope of this work is C coding style. Good style should encourage consistent layout, improve portability, and reduce errors. This work does not cover functional organization, or ge...

Abstract: This article examines the academic substance of software engineering. It identifies the basic research questions and the methods used to solve them. What is learned during this research constitutes the body of knowledge of software engineering. The article then discusses at length what about software makes its production so difficult and makes software engineering so challenging an intellectual discipline. 1

CHIME is an immersive, collaborative virtual environment designed to support the productivity of teams of software developers. Our initial experiences with CHIME have pointed out some deficiencies which limit its potential usefulness as a support environment for large software projects. In an attempt to address these deficiencies, we plan to create within CHIME “structured guidance ” based on the MBASE software engineering approach. In this paper, we describe CHIME and our initial experiences with it (which led us to consider adding a more structured underpinning), as well as the synergies we hope to exploit by embedding MBASE. CHIME (the Columbia Hypermedia IMmersion Environment) is a collaborative environment which aims to support team software development productivity. The original goal of CHIME was to support project- and domain-specific Multi-User Domain (MUD) style virtual worlds whose layout (map) was to be generated, according to a supplied theme, from the relationships among

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.

“But to this day I thank my friends for constantly reminding me of a very important word called Persistence. Persistence is to the quality of the character of man, what carbon is to steel. ”- Billy Ray Cyrus

Enterprise is a graphical programming environment for designing, coding, debugging, testing, monitoring, profiling and executing programs in a distributed hardware environment. Enterprise code looks like familiar sequential code. The user attaches icons, called assets, to sequential code modules to specify the parallelism of the program. The system provides several kinds of assets, each representing a different high-level technique of parallelism. There is an analogy between assets in a program and those in an organization. The system automatically inserts the code to handle communication and synchronization into a module based on its attached asset kind. Also, the system runs the program and supports limited process migration and dynamic distribution of work, based on the demand and availability of resources. Enterprise is an on going project involving many researchers. This thesis presents the work on the design and implementation of the textual interface, the Enterprise assets, the ...