The Desert environment

Abstract

The Desert software engineering environment is a suite of tools developed to enhance programmer productivity through increased tool integration. It introduces an inexpensive form of data integration to provide additional tool capabilities and information sharing among tools, uses a common editor to give high-quality semantic feedback and to integrate different types of software artifacts, and builds virtual files on demand to address specific tasks. All this is done in an open and extensible environment capable of handling large software systems.

Advanced Information Systems Engineering Workshops

“…This decomposition is often used when structuring development efforts or case studies. Discussions often lead to which technical mechanisms (such as explicit message passing vs. message servers, etc., hereon after mentioned only as mechanisms) should be covered ( [4]) or were used to address which integration aspect ( [5], [6], [7], [8], [9], [10], [11]). These discussions often take a "broad" view of what the different aspects entail and discuss only the mechanisms actually used.…”

Building Reverse Engineering Tools with Software Components: Ten Lessons Learned

“…Many researchers leverage components when they build tools, but there are few examples of researchers who discuss their approach and experiences of CBTD. Reiss reports on his experiences with using FrameMaker to implement the Desert software engineering environment [12]. Coppit and Sullivan discuss how they leveraged Microsoft Word and Visio to implement the Galileo fault tree analysis tool [3].…”

A framework for visual notation exchange

“…Most integration approaches tend to focus on supporting data integration [32], control integration [28,29], user interface integration [29], and/or process integration [1]. Data-oriented tool integration approaches have typically used CASE tool data exchange [32], common exchange formats like XMI and GXL [21,30], and shared databases [12].…”

“…Control integration approaches typically use APIs and object-based integration approaches, such as CORBA and related distributed object technologies [10], software components [36], and web services, particularly for workflow system integration [23]. These approaches provide powerful integration support, but often lack adequate user interface and process integration support across the integrated tool sets [25,29]. Process integration approaches typically require data and/or control integration strategies if integrated tools are intended to exchange model or view information [25,33].…”

“…Table 1 summaries many of the common approaches to addressing this problem. Some approaches focus on user interface or presentation integration, such as shared GUI frameworks or WWW browser [22,28,29], OLE-style Embedded Objects, or shared desktops (e.g. VNC) and application sharing (e.g.…”