The purpose of this paper is to build the foundation for software architecture. We first develop an intuition for software architecture by appealing to several well-established architectural disciplines. On the basis of this intuition, we present a model of software architec-ture that consists of three components: elements, form, and rationale. Elements are either processing, data, or connecting elements. Form is defined in terms of the properties of, and the relationships among, the elements-- that is, the constraints on the elements. The ratio-nale provides the underlying basis for the architecture in terms of the system constraints, which most often derive from the system:requirements. We discuss the compo-nents of the model in the context of both architectures and architectural styles and present an extended exam-ple to illustrate some important architecture and style considerations. We conclude by presenting some of the benefits of our approach to software architecture, sum-marizing our contributions, and relating our approach to other current work.

Specification matching is a way to compare two software components based on descriptions of the components' behaviors. In the context of software reuse and library retrieval, it can help determine whether one component can be substituted for another or how one can be modified to fit the requirements of the other. In the context of object-oriented programming, it can help determine when one type is a behavioral subtype of another. We use formal specifications to describe the behavior of software components, and hence, to determine whether two components match. We give precise definitions of not just exact match, but more relevantly, various flavors of relaxed match. These definitions capture the notions of generalization, specialization, and substitutability of software components. Since our formal specifications are pre- and post-conditions written as predicates in firstorder logic, we rely on theorem proving to determine match and mismatch. We give examples from our impleme...

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 ...

This paper focuses on the version models underlying both commercial systems and research prototypes. It provides an overview and classification of different versioning paradigms. Furthermore, it defines and relates fundamental concepts such as revisions, variants, configurations, and changes. In particular, we focus on intensional versioning, i.e., construction of versions based on configuration rules. Finally,we provide an overview of systems whichhave had significant impact on the development of the SCM discipline, and classify them according to a detailed taxonomy

this document are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of Wright Laboratory or the U. S. Government. The U. S. Government is authorized to reproduce and distribute reprints for Government purposes notwithstanding any copyright notation thereon. This manuscript is submitted for publication with the understanding that the U. S. Government is authorized to reproduce and distribute reprints for Governmental purposes. Authors' address: School of Computer Science, Carnegie Mellon University, 5000 Forbes Avenue, Pittsburgh, PA 15213; email: amy;wing@cs.cmu.edu. To appear, ACM Transactions on Software Engineering and Methodology (TOSEM), April 1995. Permission to copy without fee all or part of this material is granted provided that the copies are not made or distributed for direct commercial advantage, the ACM copyright notice and the title of the publication and its date appear, and notice is given that copying is by permission of the Association for Computing Machinery. To copy otherwise, or to republish, requires a fee and/or specific permission. c fl 1995 ACM xxxx-xxxx/xx/xxxx-xxxx $xx.xx 2 \Delta A. Moormann Zaremski and J. M. Wing ware libraries successfully, especially as libraries increase in size, is the availability of good tools to organize, navigate through, and retrieve from libraries. Currently many libraries use the file system for their only organization (directories and files) and file system and editor commands for navigation and retrieval. For example, the local ML library is organized with categories of components as directories (e.g., local/lib/Container/, local/lib/Threads/); one uses ls and

GenVoca generators synthesize software systems by composing components from reuse libraries. GenVoca components are designed to export and import standardized interfaces, and thus be plugcompatible, interchangeable, and interoperable with other components. In this paper, we examine two different but important issues in software system synthesis. First, not all syntactically correct compositions of components are semantically correct. We present simple, efficient, and domainindependent algorithms for validating compositions of GenVoca components. Second, components that export and import immutable interfaces are too restrictive for software system synthesis. We show that the interfaces and bodies of GenVoca components are subjective, i.e., they mutate and enlarge upon instantiation. This mutability enables software systems with customized interfaces to be composed from components with “standardized ” interfaces. 1

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...

A critical challenge faced by the developer of a software system is to understand whether the system’s components correctly integrate. While type theory has provided substantial help in detecting and preventing errors in mismatched static properties, much work remains in the area of dynamics. In particular, components make assumptions about their behavioral interaction with other components, but currently we have only limited ways in which to state those assumptions and to analyze those assumptions for correctness. We have formulated a method that begins to address this problem. The method operates at the architectural level so that behavioral integration errors, such as deadlock, can be revealed early and at a high level. For each component, a specification is given of its interaction behavior. From this specification, assumptions that the component makes about the corresponding interaction behavior of the external context are automatically derived. We have defined an algorithm that performs compatibility checks between finite representations of a component’s context assumptions and the actual interaction behaviors of the components with which it is intended to interact. A configuration of a system is possible if and only if a successful way of matching actual behaviors with assumptions can be found. The state-space complexity of this algorithm is significantly less than that of comparable approaches, and in the worst case, the time complexity is comparable to the worst case

A critical challenge faced by the developer of a software system is to understand whether the system's components correctly integrate. While type theory has provided substantial help in detecting and preventing errors in mismatched static properties, much work remains in the area of dynamics. In particular, components make assumptions about their behavioral interaction with other components, but currently we have only limited ways in which to state those assumptions and to analyze those assumptions for correctness. We have begun to formulate a method that addresses this problem. The method operates at the architectural level so that behavioral integration errors, such as deadlock, can be revealed early in development. For each component, a specification is given both of its own interaction behavior and of the assumptions that it makes about the interaction behavior of the external context in which it expects to operate. We have defined an algorithm that, given such specifications for...