A Mechanism for Environment Integration GEOFFREY CLEMM and LEON OSTERWEIL University of Colorado at Boulder This paper describes research associated with the development and evaluation of Odin-an environ- ment integration system based on the idea that tools should be integrated around a centralized store of persistent software objects. The paper describes this idea in detail and then presents the Odin architecture, which features such notions as the typing of software objects, composing tools out of modular tool fragments, optimizing the storage and rederivation of software objects, and isolating tool interconnectivity information in a single centralized object. The paper then describes some projects that have used Odin to integrate tools on a large scale. Finally, it discusses the significance of this work and the conclusions that can be drawn about superior software environment architectures. Categories and Subject Descriptors: D.2.2 [Software Engineering]: Tools and Techniques; D.2.6 [Software Engineering]: Programming Environments; D.4.2 [Operating Systems]: Storage Management General Terms: Experimentation, Languages Additional Key Words and Phrases: Environment integration, persistent objects, software object management 1. BACKGROUND A primary goal of software environment research is to devise superior develop- ment and maintenance processes and effectively integrate software tools to support them. The development of a large software system can easily cost between $50 and $400 per line [l], yet the quality of the end product is often disturbingly low. The cost of maintaining such systems over their lifetime usually far exceeds original development costs. Further, software costs have been steadily increasing over the past decade. Most observers blame the twin problems of high cost and low quality on the lack of orderly, systematic processes for developing software and the lack of software tools that effectively exploit computing power to support them. Accordingly, there has been much work on software tools and processes during the past decade. There have been some proposed software processes that stress extensive documentation of software products. Often these are not widely This work was supported by U.S. Department of Energy grants DE-FG0264ER13283 and DE-ACOP- 80ER10718 and National Science Foundation grants MCS-8000017 and DCR-8403341. Authors’ current addresses: G. Clemm, Evolutionary Software, 55 Commonwealth Road, Watertown, MA 02172; L. Osterweil, Department of Information and Computer Science, University of California at Irvine, Irvine, CA 92717. 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. 0 1990 ACM 0164-0925/90/0100-0001 $01.50 ACM Transactions on Programming Languages and Systems, Vol. 12, No. 1, January 1990, Pages l-25.2 l G. Clemm and L. Ostefweil used because they are onerous without significant tool support. Many tools are not used because they do not support specific processes, or are not well integrated with each other. Thus, software is usually developed in a manual, ad hoc way. Even where effective software processes are defined, they are rarely adequately supported by tools, making it difficult to experimentally determine just how effective they are and whether they should be promulgated more widely. Similarly, it is difficult to definitively evaluate individual tools, as they often do not clearly support tasks within popular processes, and are thus not comparable to manual efforts or other tools. We believe that the emergence of software environments is catalyzing improvements in processes and tools by providing a common evaluative frame- work. This paper describes a research software system called Odin [3, 41, which facilitates the rapid and effective integration of software tools, thereby aiding experimentation and evaluation. We believe Odin is a language and interpretation system for what DeRemer and Kron have called “programming in the large” [5]. Odin was first used to integrate a family of FORTRAN development, testing, and maintenance tools in the Toolpack project [16]. It was subsequently used to integrate tools to support software development in C [8], and then to integrate tools to support the creation of attribute grammars. Currently, Odin is being used to support a variety of large- scale tool integration applications, including a data flow analyzer generator project [14]. The Odin architecture, our experiences in exploiting it, conclusions about the Odin architecture, and principles to which these experiences have led us, are the subjects of this paper. In Section 2 we describe the philosophical basis upon which Odin rests, Section 3 describes related work; Section 4 describes the details of Odin’s design and some implementation issues; Section 5 the language used to specify the way in which tools are to be integrated; Section 6 the language that users employ to actually use tools; Section 7 our experiences in using Odin; and Section 8 suggests likely future research directions. 2. THE ODIN TOOL INTEGRATION PHILOSOPHY Odin was originally designed as part of the Toolpack project [16], whose aim was to integrate both existing and proposed tools for supporting the development, testing, and maintenance of FORTRAN code. Flexibility and extensibility were also key Toolpack goals. At the time (1979) there was considerable interest in software