This paper describes the main concepts behind the implementation of the Merlin prototype and sketches current and further work within the research project evolving from the current experience with the prototype.

In this paper, we review software development as a document-based process, with the capture of a full but ideal development history as the assumed purpose of the documents concerned. We identify generic requirements for perusal, editing and verification of such documents, and illustrate how these requirements could be met in a software development environment based on current interaction technology. Finally, we propose a generic environment architecture for implementation of the facilities concerned, and outline how our own research work has addressed some of the requirements of this architecture.

The paper introduces a version management model which exploits knowledge about the contents of documents. This is in contrast to most existing models which basically consider versioned objects as flat (attributed) files. The benefits of the approach are illustrated by describing some sample operations which are not possible with a conventional model. The paper then discusses a feasible implementation of the model on top of an existing object-oriented data base management system. Finally, it discusses related work and indicates how a sophisticated configuration management system is being built on top of the version management system.

We argue that a fully object-oriented database management system is a very suitable basis of every modern CASE environment. We describe how the features provided by an OODBMS are exploited to build a CASE tool or environment. We discuss especially problems concerning inter-document consistency constraints and multi-user support. We finally sketch the features which are still missing in OODBMSs.

We report on the experimental application of process technology at British Airways #BA#. We used SLANG to model BA's C++ class library management process, and we constructedanexperimental process-centred software engineering environment #PSEE# basedon SPADE. BA requiredprocesses to be automatedata #ner degreeofgranularity than tool invocation. We have demonstrated that SLANG and SPADE o#er the basic mechanisms for modelling these #ne-grainedprocesses. We have also shown that it is feasible to generate tools for dedicatedprocesses and integrate them with a SLANG model so as to facilitate #ne-grainedprocess automation. However, our experience highlighted some open problems. For instance, SLANG process models are tuned to e#cient enactment, thus containing very detailedprocess fragments. These are not the most appropriate representation for humans trying to understand the process model. A morecomprehensible notation is needed for design and documentation purposes. Although the airline d...

One of the functionalities of software development environments is to maintain all the documents produced in the software development process. To facilitate the much needed traceability support for the software process, the representation of the software documents should capture not only the individual documents, but also their relationships and structural properties. In this paper, we present an approach to the representation and description of software documents. Syntax trees, structural relations and structural constraints are introduced to capture the syntactic structures of documents, the interand intra-document relationships and the structural properties of these documents and relationships. With this three-tiered approach, we are able to obtain a complete, static representation and description of the documents' syntactic and structural features.

Syntax Graph implement syntactic relationships, and referenceedges, which arise from semantic relationships. Documents are identi#ed by the subgraph whose node-set is the transitive closure of nodes reachable by aggregation edges from document root nodes. Nodes that cannot have out-going aggregation edges are called terminal nodes, for they are derived from terminal symbols of the underlying grammar. Those nodes that mayhave out-going aggregation edges shall be called non-terminal nodes.

The goal of the GOODSTEP project is to enhance and improve the functionality of a fully object-oriented database management system to yield a platform suited for applications such as Software Development Environments (SDEs). The baseline of the project is the O2 database management system (DBMS). The O2 DBMS already includes many of the features required by SDEs. The project has identifed enhancements to O2 in order to make it a real software engineering database management system. These enhancements are essentially upgrades of the existing O2 functionality, and hence require relatively easy extensions to the O2 system. They have been developed in the early stages of the project and are now exploited and validated by a number of software engineering tools built on top of the enhanced O2 database system. To ease tool construction, the GOODSTEP platform encompasses tool generation capabilities which allow for generation of integrated graphical and textual tools from high-level speci cations. In addition, the GOODSTEP platform provides a software process toolset which enables modeling, analysis and enaction of software processes and is also built on top of the extended O2 database. The GOODSTEP platform will be validated using two CASE studies carried out to develop an airline application and a business application. This work has been funded by the EU under contract

One of the major goals of the Viewpoint framework is to allow for heterogeneous and distributed implementation of viewpoint-based tools. This poses a number of challenges on the integration of tools into a viewpoint-based environment. We review di#erent infrastructures that could be deployed for tool integration and argue that the OMG#CORBA architecture provides the best support for achieving heterogeneity and distribution. We then discuss how viewpoint-based tools can be integrated on the basis of CORBA. This involves the integration of di#erent viewpoint representations as well as their presentation at user interfaces. 1 Introduction Anumber of di#erent tasks have to be performed during the construction of a software-intensive system. Any such system of non-trivial size requires multiple developers with different knowledge and expertise to cooperate on the di#erent tasks involved. Tasks range from requirements analysis over architectural and componentinterface design to component i...

The ability to construct a software system from separate pieces while the system is being used is a feature which has become more prevalent and important in recent years; in fact, the ability to dynamically compose a system has existed in various programming languages and computing systems for some time. We use the term dynamically composed systems to refer to systems with this property. In general, dynamically composed systems suffer a number of problems, not the least of which is the difficulty in ascertaining what pieces comprise a system. Furthermore, the definition of how particular pieces are selected, what a consistent collection of pieces is, and how multiple versions of the same piece are handled when composing a system dynamically is typically ambiguous, and feedback to users or maintainers of the system with respect to these issues is often non-existent or too late. Traditional configuration management tools address such system composition and evolution issues, but only in a s...