A Model of Tool Interconnections in Integrated Software
Jennifer G. Harvey
Discipline of Computer Science, Flinders University of South Australia, Adelaide, 5001, Australia School of Computer and Information Science, University of South Australia, The Levels 5095, Australia
A recent trend in improved support for software engineering activities is the increasing use of integrated software engineering environments (ISEEs), in which various specific software engineering tools cooperate to facilitate the software development process. A number of integration frameworks which purport to support cooperation between tools have been proposed and marketed. In assessing the capabilities of an ISEE or Integration Framework it is necessary to consider not only the facilities available but also the ways in which to tools interact and the extent to which they can make use of the provided facilities. This paper outlines a proposal to develop an operational model which will be used describe tool interconnection in current and proposed frameworks.
Software engineering environments (SEEs) provide an aggregation of services to support a software engineer in the production of quality software. Early SEEs were monolithic structures, e.g. , and, in general, supported the programming process only. More recently, however, it has become increasingly clear that the flexibility of an environment is an important characteristic of any SEE which is to support a range of software development activities in organisations where the requirements for such an environment differ between projects. The term flexibility indicates an ability to extend and alter an environment as required; such environments are built up from separate tools and are termed integrated software engineering environments (ISEEs). The level of support, therefore, that an ISEE can provide is determined not only by the tool set provided, but also by the flexibility in the ways in which these tools can interact.
The understanding of tool integration in ISEEs is still naive. Several authors (e.g.?[2, 3, 16]), have suggested various detailed views of integration ? what is clear from this work is that an appropriate view is dependent upon the role of the person considering integration. For example, a framework builder, a tool integrator and an environment user will have different adgendas and hence different views of integration. Earlier, Wasserman  introduced five themes of integration. These themes present a coarse view of integration and there is obviously some overlap between the themes, but they have been widely accepted as a convenient framework in which to describe and discuss integration. The themes are outlined briefly below:
? Data Integration: the management of data (both persistent and non-persistent), the relationships between data objects, and of mechanisms to facilitate sharing and transfer of data between the tools;
? Control Integration: the strategies to support or control the automatic and manual invocations of tools, and to manage the communication and transfer of data between tools;
? Process Integration: the use of tools to define and track software development activities, allowing the process to be managed and monitored more effectively so that subsequent improvements can be made to the process definition;
? Presentation Integration: the extent to which a user is unaware of the existence of multiple tools combining to deliver a service;