An Interface between Different Software Development

Environments?

Greger Lind?en and A. Inkeri Verkamo

Department of Computer Science

P.O. Box 26, FIN-00014 University of Helsinki, Finland

e-mail: flinden, [email protected].

Abstract

Information sharing between two well-defined development environments demands data transformation between the tools or the underlying repositories of the environments.

In the Proceedings of the Tenth Knowledge-Based Software Engineering Conference, Boston, Massachusetts, pages 79 - 87. IEEE Computer Society Press, November 1995.

We give a solution to the problem
of making tools in different environments cooperate without modifying the tools or their environments. In building an interface between a kbs environment and a selected case tool we have used a transformation generator called alchemist. This has reduced the work of respecifying the environments for each transformation. We have encountered several problems in the transformation that we have solved, including, e.g., incompatible views of the tools, multiple views, and different ways of representing graphical information. Additional problems can be addressed through user interaction before, during, or after the transformation.

1 Introduction

Even though the literature handling case tools has for some time recommended using integrated project support environments (ipses) in systematic large scale software production (see, e.g., [4]) the practitioners on the field are mostly involved with much less advanced practical problems in tool cooperation. Only recently, a study of the state of the practice in case integration described that it is difficult to find industry experience of long time operational use of integrated case tools [11]. Among the most important problems reported in the study is the inadequacy of the interfaces for actual integration, which is contrary to claims often made by case vendors.

Several ways have been suggested to ease case tool interfacing. Among these are common data presentation frameworks such as pcte (adopted by ecma [6]) and irds (approved by iso and ansi [7]), and tool connection using message passing [12]. So far, none of these standards or methods have been unanimously accepted by tool vendors. Within tool integration, tool developers concentrate on making their own tools

?This research was supported by the Technology Development Center (TEKES) and in part by the Commission of the European Communities under ESPRIT-II project 5365 VITAL. This paper reflects the opinions of the authors and not necessarily those of the VITAL consortium.

work together, using one of the many de-facto industry standards, while cooperation of tools from different origin is considered less important or even commercially disadvantageous. However, the users' best interest is in truly open software development environments that include cross-environmental tool cooperation, whether it is based on common standardization activity or market-driven industry standards [17].

In the present situation software developers who want to make tools of different origin cooperate are more or less left on their own in building the interface. In a previous paper, we have discussed the specific types of problems that must be solved to build such an interface [16]. In this paper, we describe our experience in implementing an interface between the conceptual modeling tools of a development environment for building knowledge based systems and the analysis and design tools of a commercial case environment. This work was done in a research project, vital, for building a full scale workbench for kbs development [13].

The paper has the following structure. In section 2, we present the two environments that are to be interfaced. In section 3, we describe the requirements for the interface and the solution strategy, based on a transformation generator. The following sections describe how we solved the most essential practical problems in the interface, such as handling different source and target views (section 4), information collection (section 5), and user interaction during the transformation (section 6). We close by a brief conclusion of our experiences and some suggestions for future improvements.

2 The environments

2.1 The source environment

The source environment is the vital workbench, a development environment for knowledge based systems, produced in the vital research project, [13]. We are specifically looking at the conceptual modeling tool of vital, the ocml (Operationalizable Conceptual Modeling Language) editor [5]. The ocml editor includes capabilities for constructing diagrams for domain data, domain knowledge, and problem solving behavior. The ocml editor is the vital tool for the conceptual modeling phase and even part of the design