COTS products can play various architectural roles in software systems: as interfaces to problem-specific functionality, as components that provide such functionality itself, and as intermediary connectors and components in more complex systems. In doing so, COTS products impose their own, unique constraints on organization and functionality. Over the last ten years, we have gained considerable experience with adopting, adapting, and living with the limitations of COTS products. Our goal was to adapt the COTS product to make it fit the application rather than adapting the application needs to make them fit the COTS product - thus, in essence, adapting the COTS product without access to its source code or documentation (a unique form of maintenance). We report on a large set of experiences involving eight COTS products and a wide range of COTS-Based Software Systems - most of which were done with and for industrial partners or government agencies. This experience report attempts to both give a feeling for how applications can be augmented with such COTS interfaces and also tries to tease out the specific architectural issues that anyone adapting COTS products is certain to face.

One of the major problems in cooperative software development is that of maintaining certain global consistency properties.Broadcasting changes that have already occured, as many programming environments do, will not resolve this problem.We argue in favor of an architecture where the announcements deal with impending or proposed changes as well as changes that have already occurred.One can then formulate consistency requirements on the system that are maintained "lazily" as it evolves.Such an architecture can support a wider range of cooperative processes than traditional software development environments.This paper describes the design and implementation of this architect ure.

The process of developing and evolving complex software systems is intrinsically exploratory in nature.Some prototyping activity is therefore inevitable in every stage of that process.Our program development and evolution methodology is predicated upon this observation.In this methodology, a prototype software system is developed as an approximation to an envisioned target system by compromising along one or more of the following dimensions: system performance, system functionality, or user interface.However, the prototype is not the end-product of the process.Instead, we support iterative evolution of the prototype towards the envisioned system by gradually dealing with the three general areaa of compromise.This paper describes the methodology of using this alternative lifecycle; to wit, the programming language concepts and related implementation technology that support practice of the suggested methodology.We summarize the lessons we have learned in building and using this technology over the last several years.

We are deeply indebted to the members of ISI Software Division who developed the basic technology and approach for our effort. We especially wish to acknowledge the contributions of our colleagues, Dave Dyer and Matt Morgenstern, to the conceptualization and design of the system.

This paper is concerned with the need for computer-based tools which help human designers formulate formal process-oriented specifications. It first determines some attributes of a suitable process-oriented specification language, then examines the reasons why specifications would still be difficult to write in such a language in the absence of formulation tools. The key to overcoming these difficulties seems to be the careful introduction of informality based on partial, rather than complete, descriptions and the use of a computer-based tool that uses context extensively to complete these descnrptions during the process of constructing a well-formed specification. Some results obtained by a running prototype of such a computer-based tool on a few informal example specifications are presented and, finaliy, some of the techniques used by this prototype system are discussed.

~SrRACT.The MARGIE system is a set of three programs that attempt to understand natural language.They are based on the Conceptual Dependency system for meaning representation.The analysis program maps sentences into conceptual structures.The memory program makes inferences from input conceptual structures.The generator codes conceptual structures back into natural language.Together the programs function as a paraphrase and inference system.tv.y