DESERT is a programming environment that attempted to achieve low-cost data integration in addition to the control integration provided by environments like FIELD. Control integration involves tools talking to one another. Data integration involves having the tools actually share data. Classically, data integration was done by having a central repository that contained all the abstract syntax trees and other information from the system (e.g. Diana representation for Ada), and having the tools work off of this repository. This turns out to be impractical (at least it was around 1990 when we started this project), in that the size of the database, the amount of incremental updates that are needed, and the rate of access needed by tools all far exceeded what database systems or machines at the time could reasonably provide. Thus systems that attempted data integration were too slow. Another factor was that the data representations tended to be quite complex and it was difficult to find an appropriate representation that could be easily updated and used by a wide variety of tools.
DESERT attempted to provide the benefits of data integration without the costs. It maintained a minimal central repository containing only the information that actually needed to be shared among the tools. For the most part, this was simply a global symbol table with type information, the kind of data that is easy to extract from a compiler and relatively easy to maintain. Next it divided the actual program in logical pieces called fragments and maintained a database of information about the fragments. Fragments represented classes, methods, declarations, etc. -- essentially they were the logical units that the programmer thought in terms of.
DESERT used the symbol database to provide up-to-date information of the overall system as the programmer edited. It could determine the nature of each identifier and tell when identifiers were defined or undefined. This information was used for formatting, for handling user queries, and to provide feedback to the users as to potential errors. The fragment database in conjunction with the symbol database was used to construct virtual files consisting of fragments. If the user wanted to modify a particular function, he/she could create a virtual file containing that function and all fragments that called that function. This virtual file could then be edited and saved. When it was saved, the various fragments would be updated in their original files. DESERT provided locking and other services to support sharing and real software development using virtual files.
In addition to the use of fragments, DESERT showed that you could provide high-quality program views while editing. Based on the previous research of Baecker and Marcus as to how to most effectively present programs, DESERT used Adobe FrameMaker as a program editor, automatically converting normal program source into a formatted document that approximated the Baecker-Marcus results. Moreover, the document was maintained dynamically as the user typed on a keystroke basis.
In DESERT we also continued our prior work on software visualization. DESERT included a 3D visualization system that was able to extract data from the various databases and from other sources such as gprof output. The initial version of this system was called CACTI which eventually evolved into VALLEY.
Framents: A Mechanism for Low Cost Data Integeration
Simplifying Data Integration: The design of the Desert software development environment
Program Editing in a Software Development Environment
Defining Software Visualizations Dynamically
Configuration Management with Logical Structures
A Formal Model for Object-based Configuration Management
Software Visualization in the Desert Environment
The Desert Environment
The FrameMaker-based Program Editor
Dynamically embedding a UML fragment into the editor
A tool for finding candidate classes and methods through part-of-speech analysis
Literate programming extendsion to the editor
The tool for defining new visualizations
The Desert software still compiles and sometimes even runs on a Solaris platform. However, I would not expect it to be that useful since it hasn't been updated in quite a while, and the compilers (it uses Sun's source browser capabilities) and FrameMaker have changed a bit since it was last tested. I have been able to give limited demos of the current software at Brown, but would not be optimistic about its being usable elsewhere.