An open integrated CAx-framework supplies services to build derived CAx-environments (e.g. for concurrent Engineering (CE), VLSI-design, Software Engineering, etc.) with specialized, integrated in-house or foreign tools. Such integrated tool uses services of the CAx-framework and cooperates with other integrated tools to achieve a common engineering objective like the simulation of a VLSI-circuit. In most CAx-frameworks the integrated tools cooperate indirectly using CAx-framework services like Data Handling or Inter-Tool Communication (ITC).With obTIOS a high-level approach to control cooperation of integrated tools within a Computer Aided Concurrent Engineering (CACE) environment is introduced. The tools of a CACE-environment are grouped to domains which represent the most coarse, mutually independent, structural unit within the CACE-environment. The way in which the tools of a domain cooperate is described by Encapsulated Composed Activities (ECA). An ECA represents a template of control regarding cooperation-in-the-large and cooperation-in-the-small of tools.
We present an architecture for multi-user software development environments, covering general, process-centered and rule-based MUSDEs. Our architecture is founded on componentization, with particular concern for the capability to replace the synchronization component–to allow experimentation with novel concurrency control mechanisms–with minimal effects on other components while still suporting integration. The architecture has been implemented for the MARVEL SDE.
Existing approaches for merging the results of parallel development activities are limited. These approaches can be characterised as state-based: only the initial and final states are considered. This paper introduces operation-based merging, which uses the operations that were performed during development. In many cases operation-based merging has advantages over state-based merging, because it automatically respects the data-type invariants of the objects, is extensible for arbitrary object types, provides better conflict detection and allows for better support for solving these conflicts. Several algorithms for conflict detection are described and compared.
Reverse engineering is the process of extracting system abstractions and design information out of existing software systems. This information can then be used for subsequent development, maintenance, re-engineering, or reuse purposes. This process involves the identification of software artifacts in a particular subject system, and the aggregation of these artifacts to form more abstract system representations. This paper describes a reverse engineering environment which uses the spatial and visual information inherent in graphical representations of software systems to form the basis of a software interconnection model. This information is displayed and manipulated by the reverse engineer using an interactive graph editor to build subsystem structures out of software building blocks. The spatial component constitutes information about how a software structure looks. The coexistence of these two representations is critical to the comprehensive appreciation of the generated data, and greatly benefits subsequent analysis, processing, and decision-making.
Current software development environments tend to lie at opposite ends of a spectrum: at one extreme are specialized application generators; at the other are general-purpose programming environments. The former provide strong support for system development and reuse, but are costly to build and available only for limited domains. The latter provide weak support, but are generally available and universally applicable. We describe a technique for automating the production of application-specific environments that lie between these two extremes. The key idea is that these environments can be derived from general-purpose programming environments by a process of structured transformation. We describe a tool for performing these transformations. It provides a set of formal operators for specializing a description of a general-purpose environment; as operators are applied, the system semi-automatically builds a set of transformation rules used to translate application-specific programs into those of the original general-purpose environment. The output of the tool is an application-specific environment together with a program transformer that provides execution semantics for programs written in that environment.
In program visualization some form of graphics is used to represent some aspect of a program. However, graphics are necessarily expensive with respect to “screen real estate”. Alternatives, therefore, may be required for presentation of certain concepts fundamental to the programmer's model of a program. For example, one graphical representation of a program, written in a block-structured language like Pascal or Modula-2, is the structure chart model of the hierarchical structure of the blocks or modules making up the program. This graphic may be the most appropriate but it may not be conveniently implemented as a menu and a means of “directly” selecting blocks of program code to view or edit. Such graphics are used extensively, for example, in the Garden environment developed at Brown University. An alternative is a text-based list of block names indented to summarize the program's structure. UQ1, a language-based editor developed at the University of Queensland, implements the concept in this manner. Both types of menu structure were examined and compared for efficiency in a direct manipulation style of interaction. In general, there was no significant difference ( P > 0.05) in time taken by subjects to select items from either style of menu.
This paper presents some of the more significant technical lessons that the Arcadia project has learned about developing effective software development environments. The principal components of the Arcadia-1 architecture are capabilities for process definition and execution, object management, user interface development and management, measurement and evaluation, language processing, and analysis and testing. In simultaneously and cooperatively developing solutions in these areas we learned several key lessons. Among them: the need to combine and apply heterogenous componentry, multiple techniques for developing components, the pervasive need for rich type models, the need for supporting dynamism (and at what granularity), the role and value of concurrency, and the role and various forms of event-based control integration mechanisms. These lessons are explored in the paper.
In this paper we report the results of an experiment to determine the effect of having multiple views available for software development. 43 programmers were divided into four groups, each group using a different set of tools to perform a set of software maintenance tasks. The differences between these groups’ performances were in some cases statistically significant, and we found evidence for a synergistic interaction between tools. information was also gathered on the programmers’ subjective feelings about the usefulness of various tools, and the data support the conclusion that multiple views are desirable.
In this paper we discuss the architecture of the Conversation Builder, an environment for collaborative work, and show how our framework provides a powerful basis for support of collaborative software development activities.
ProDAG is an analysis toolset that provides an application programmatic interface for program dependence analysis. Program dependences are syntactic relationships between program statements. The ProDAG interface provides a uniform set of operations for creating and accessing several pre-defined dependence relations, which are represented as graphs, as well as a standard mechanism for developing new dependence graphs. ProDAG is one analysis toolset in Arcadia, ProDAG was developed in the Arcadia environment and has been integrated with the language processing, oject management, and process definition components of the Arcadia architecture, and further integration with the user interface development system and the measurement and evaluation components are underway. This paper describes the design, implementation and integration of proDAG within Arcadia.
While many Computer-Aided Software Engineering (CASE) tool vendors claim to provide open, integrated environments for software development, in practice such claims must be examined very carefully to understand what is meant. One of the problems faced in trying to examine these claims is that there is no established technique for examining software development environments with regard to their integration characteristics.
A concurrent software application, whether running on a single machine or distributed across multiple machines, is composed of tasks that interact (communicate and sychronize) in order to achieve some goal. Developing such concurrent programs so they cooperate effectively is a complex task, requiring that progrmmers craft their modules–the components from which concurrent applications are built—to meet both functional requirements and communication requirements. Unfortunately the result of this effort is a module that is difficult to reason about and even more difficult to reuse. Making programmers treat too many diverse issues simultaneously leads to increased development costs and opportunities for error. This suggests the need for ways that a developer may specify control requirements separately from the implementation of functional requirements, but then have this information used automatically when building the component executables. The result is an environment where programmers have increased flexibility in composing software modules into concurrent applications, and in reusing those same modules. This paper describes our research toward a technology for control integration, where we have developed techniques for users to express control objectives for an application and a system that translates those specifications for use in packaging executables.
Software productivity and quality will increase as we improve our model of software and develop tools to support that model. Development environments must take into account that software is more than source; that it is more than text; and that it forms a highly interconnected web of information. Because more time is spent understanding and maintaining software than creating it, environments should strongly support browsing and reading. Finally, environments must be easy to customize. In this paper we present HyperWeb, a framework that supports the construction of hypermedia-based software development environments having this richer view of software. It coordinates the activities of an integrated set of tools through a message server, uses an object-oriented database to store software artifacts, and supports hypermedia linking of these software artifacts. It is built around an interpreter for a general purpose scripting language, allowing for very flexible customization and environment building. We also describe our experience in using it to build an environment that supports software design, development and maintenance on Unix. Its primary features include support for document linking, source code annotation and restructuring, and modification request tracking. It is being used and evaluated internally and at several external sites.
Software development environments can increase user productivity by presenting information in more useful ways. This paper describes Proteus, the presentation system of Ensemble, a software development environment that supports a wide variety of language and document capabilities. Proteus provides a set of services which allow the appearance of software development documents, such as programs or design specifications, to be determined by formal specifications of style. Proteus is based on a generic model of presentation services and is intended for use with a wide variety of media.
The ProcessWall is a process state server providing storage for process states plus operations for defining and manipulating the structure of those states. It separates the state of a software process from any program for constructing that state. Instead, client programs implement the processes for operating on the process state. This approach has a number of potential benefits such as support for process formalism interoperability, support for multiple process languages, low-cost retro-fitting of process into existing environments, and support for long-term execution of processes. The process server interface provides descriptive mechanisms for representing process state as well as product state. A classification of client programs is provided to show how the state server can be used in a variety of ways.
Large scale software development processes often require cooperation among multiple teams of developers. To support such processes, SDEs must allow developers to interleave their access to the various components of the projects. This interleaving can lead to interference , which may corrupt the project components. In traditional database systems, the problem is avoided by enforcing serializability among concurrent transactions. In traditional software development, the problem has been addressed by introducing version and configuration management techniques combined with checkout/checkin mechanisms. Unfortunately, both of these solutions are too restrictive for SDEs because they enforce serialization of access to data, making cooperation unacceptably difficult. In this paper, I illustrate the problem and show how the encoding of the software development process in process-centered SDEs can be used to provide more appropriate concurrency control. I present the concurrency control mechanism I developed for the MARVEL SDE. This mechanism uses the process model in MARVEL to support the degree of cooperation specified in the development process.
This paper explains how to add a modern user interface to existing theorem provers, using principles and tools designed for programming environments.
An important aspect in the software development process is the consistency between various parts of the software system being designed and implemented. During the development of a system we are aware of the consistency problems and we usually solve these by special arrangements developed as part of the development of the software system. In general the solutions applied for some specific system cannot be reused for other systems. The purpose of this paper is to introduce a general understanding of consistency and the techniques and tools for handling consistency. We introduce a concept called description to denote the various pieces of information which must be consistent. The description covers any fragments software and data, e.g. such as source code, parse trees, and machine code. The interpretation of a description is defined as a mapping into the set of objects, that the description is supposed to describe. Consistency of descriptions is defined as relations between the interpretations of the descriptions. The concepts description, interpretation and relation are used as a framework for modeling consistency in software systems. A consistency model includes interfaces, control parts and representions for descriptions in a system, and a specification of the consistency relations, that are relevant for the system. The model provides consistency as a new and very important perspective on software systems. It provides a graphical notation, which gives an overview of the consistency relations in a software system being designed. The model is very general and it does therefore apply to any type of software systems. This restricts the level of detail in the model of consistency, but the model allows enhancement of the specification once the type of software system is given. We define four basic techniques for handling consistency in software systems modeled in terms of descriptions. By combining these techniques we are able to describe the handling of consistency in a given software system. These techniques and the graphical consistency modeling language form a first step towards an engineered approach to the construction of software systems from a consistency view.
We capture, define and analyse phases and rôles of computing systems development and developers. We examine the rôle of formal methods, and we set up requirements that a process model and a CASE ought satisfy. A reference process model is presented and a prototypical CASE system is outlined. The RAISE Tool Set is reviewed wrt. its conformance with the process model. The paper delineates its subjects, proposes a taxonomy, gives tentative definitions, and outlines a programme of experimental research and development.
