A Productivity-Centred Approach for Classifying Software Tool Interfacing

A Productivity-Centred Approach for Classifying Software Tool Interfacing

Yun Yang

School of Computing and Mathematics

Deakin University

Geelong, Australia 3217

[e-mail]

Jun Han

School of Computing and Info. Tech.

Monash University

Melbourne, Australia 3199

[e-mail]

AbstractThe effectiveness of tool integration in software development environments is ultimately measured by its ability in improving the productivity of the user. Traditionally, issues related to tool integration are often classified according to aspects of such mechanisms as user interface, control, and data integration which are purely from the viewpoint of the environment developer. This mechanism-based classification has worked well in analysing the relevant issues of tool integration. However, its usefulness as a guide to achieving effective tool integration is limited. In this paper, we introduce an alternative classification scheme aimed at gradual improvement to the effectiveness of tool integration. As such, this classification scheme provides a guide to tool integration along the line of improving the user's productivity. In terms of this classification, we compare and experiment in depth a variety of integration techniques using a uniform tool interfacing architecture as well as discuss the issues of the potential user productivity gains.

Keywords: Software development environments, productivity, tool interfacing, control integration, data integration, software tools classification.

1 Introduction

The architecture of an integrated software development environment (SDE) composed of multiple software tools must recognise two kinds of interface [24]:

• the interface presented to the user of the overall tool set

• the interface between component tools within the set

In other words, the first interface is related to presentation or user interface integration, and the second interface is related to tool interface integration including control and data integration. This classification scheme is based on such integration mechanisms as user interface, control and data integration, and is commonly referenced [21, 7]. We must note that successful development of complex (software) systems depends on support of an appropriate and useful set of tools, as indicated by Wasserman [22]. In this paper, we focus on tool interface issues, and therefore the aspects of control and data integration are of major concern.

From the control integration viewpoint, tools must be able to notify one another of relevant events. Control integration refers to the ability of tools to perform such notification, as well as the ability to activate other tools under program control [21]. It is related to communication issues among tools [7]. In general, control integration among tools can take place in following ways:

• -

  indirect control integration

Tools can be activated via facilities accessible directly to the user. For example, an operating system command which is accessible to the user can also be issued (as a system call) by another tool.

• -

  triggers

Tools can be activated through triggers which are events in a database or object base and cause certain actions to take place when particular item(s) are touched.

• -

  a message server

Tools can be activated by the message broadcast mechanism in a message server when particular messages are received.

• -

  procedure calls

Tools can be activated through (remote) procedure calls.

From the data integration viewpoint, tool integration requires both sharing of data among tools and managing the relationships among data objects produced by different tools [21]. In other words, data integration allows sharing and exchange of data among tools [7]. Accordingly, relevant data integration between tools can occur in a number of ways, which may be employed in a mixed manner:

• -

  intermediate files

Tools can transfer data using intermediate files.

• -

  a database or object base

Tools can exchange data via a shared repository such as a database or object base.

• -

  message passing

Tools can exchange data using explicit messages.

• - a "canonical" representation

Tools can share a canonical internal data representation.

In [26], we have examined the well-known aspects of user interface, control and data integration. In general, the consideration of user interface, control and data integration has helped to clarify and analyse the nature and relevant issues of tool integration. However, it is clear that a directly corresponding classification based on the integration mechanisms seems inappropriate. Sometimes, goals perceived under user interface integration are met by control and data integration mechanisms. For example, how to integrate the user input required by, and feedback to the user produced by, the tools is likely to be met by appropriate choice of techniques for control and data integration between the tools concerned. Likewise, a strict separation between control and data integration mechanisms seems inappropriate given the closely related functions which they commonly perform. Thus, an alternative classification scheme must be sought. In practice, the most fruitful classification seems to be the one with respect to the primary goal of tool integration — improving the user's productivity. Based on control and data integration aspects, in this paper we introduce such an alternative classification scheme for tool integration, aimed at providing some guidance to design and selection of tool integration techniques regarding user productivity.

In the next section, we concentrate on the new classification scheme of the tool interfacing paradigms, where three classes or levels of tool integration are introduced and discussed. Next, we introduce an architecture for tool interfacing under the new classification scheme. Finally, we present in detail our tool integration experiments in terms of these three classes of tool interfacing paradigms, followed by a discussion on the issues of the potential productivity gains.

2 A classification of tool interfacing

The alternative classification, initially addressed in [27], presents the overall purpose of tool interfacing concerned, as reflected by the goals for control and data integration, with a gradual increase for improving productivity and the corresponding technological requirements that arise. By improving productivity, we mean a gradual increase in the level of assistance towards user productivity gains, as illustrated below.

2.1 Eliminating user-generated delay: class 1

To illustrate this class of tool interfacing, we introduce a simple and familiar example, variations of which will also serve to illustrate subsequent classes. Consider the use of an editor and a compiler to support the program development process in an interactive environment. In a typical development cycle, the user will edit the source file concerned, request its compilation, edit it again in the light of the syntax and semantic error messages produced by the compiler, and continue this edit/compile cycle until no error messages are produced. In a totally unintegrated tool environment, the user will specify the source file to be edited in each edit request, and again in each subsequent compilation request, as well as initiate each step by entering edit and compile commands as required. From the control integration viewpoint, an obvious improvement of this situation is one in which the default file name for each edit request is the last file compiled (or edited), and the default file name for each compilation request is the last compilable file edited. Furthermore, it is also possible to automate the activation of, for example, the relevant compiler each time a compilable source file is edited. In general, however, the user may wish to retain some control over when such automatic activations should occur. From the data integration viewpoint, it normally requires file-based data access.

Class 1 interfacing improves productivity by eliminating user-generated delay as illustrated above, i.e., it reduces the need for user input between tool activations. In addition, this class of tool interfacing allows the feedback from the tools to be associated with the relevant sections of the input. Therefore, it also reduces the user effort required to comprehend tool feedback. In general, such integration implies the basic requirements for control and data integration mechanisms.

The feature that distinguishes class 1 interfacing from the subsequent classes which we will define, is that the user's expectation of performance from the integrated tool set is no greater than that obtainable with separate use of unintegrated tools. Under these circumstances, the granularity of control and data transfer is coarse and the data structures involved are simple (normally sequential files). In effect, the requirements listed are little more than those met by many operating systems except the removal of user-generated delay. For example, the combination of and described in the previous section serves well for this class.

In summary, class 1 interfacing must meet the goal of control integration for sequential activation of tools, and the goals of data integration to support simple data structures and the potential for maintaining data consistency.

2.2 Eliminating tool-generated delay: class 2

To illustrate this class of tool interfacing, a simple example of concurrent activation arises when an editor is used to update a set of related source files which make up a modular program. As editing of each file is completed, its (incremental) compilation can proceed in parallel with the editing of subsequent source files. By the time the user finishes editing the last file, compilation of the previous files may be complete, and either editing of detected errors can proceed immediately or a linked executable program is available with minimum delay. From the control integration viewpoint, the granularity of concurrent tool activity can be large at the file level of compilation or finer for incremental compilation, but the concurrent activities spawned are essentially asynchronous. From the data integration viewpoint, normally the data structure processed by the compiler is conceptually a shared and randomly updated structure, in which components may be added or replaced by the editor in any order. An efficient form of shared structure may well be structured data such as syntax trees.

In addition to the productivity gain achieved by class 1 interfacing, class 2 interfacing improves productivity by eliminating tool-generated delay as illustrated above, by exploiting techniques such as incremental data processing, and by exploiting concurrent execution of tools and hence the user's "thinking time". Such integration may imply the requirements of a finer granularity of control and data integration for integration mechanisms.

The emphasis of class 2 interfacing is mainly put on tool performance improvement. The granularity of control and data transfer may vary. The concurrent processing involved is typically asynchronous, and structured data is normally used. For example, the combination of and described in the previous section serves well for this class.

In summary, in addition to the achievement of class 1, class 2 interfacing must meet the goal of control integration for (fine-grained) concurrent activation of tools, and the goal of data integration to support fine-grained, directly transferred or shared data structures. These goals are primarily for the purpose of tool performance improvement.

2.3 Introducing tool construction: class 3

To illustrate this class of tool interfacing, consider the interaction in a theorem proving system consisting of a proof editor and an incremental proof checker. The proof editor enables the user to prepare and modify logical proof documents. The proof checker verifies each proof step introduced. Unlike an incremental compiler, however, the proof checker not only checks the consistency of the user input at each step, but also computes the subsequent proof obligations which have to be met (as feedback necessary to the user in formulating the next proof step). Proof construction is thus achieved by an interactive dialogue between the user and the proof checker, with the proof editor acting as an intermediary and scribe which records the resultant proof for subsequent review, revision and re-use. From the control integration viewpoint, control synchronisation between the proof editor and proof checker is now vital to effective proof construction, with the granularity of synchronised interleaving being determined by the step-by-step proof construction process to be supported. From the data integration viewpoint, it raises no new associated data integration requirements. Furthermore, the proof editor and proof checker may often be implemented in very different ways which could cause serious problems with integration if using a shared data structure described in the class 2 example.

In addition to the benefits brought by the previous two classes, class 3 interfacing improves productivity by introducing tool construction as illustrated above. As exemplified above, the tools in this class of integration are usually special tools of high interactive nature (e.g., the interactive proof checker). Further to the achievement of the above two classes, another objective of this class of tool interfacing is from the environment developer's viewpoint, to achieve economy in SDE construction and maintenance by allowing SDE and tool construction from reusable tool components, while retaining the degree of synchronisation between such components that advanced tools require. As such, SDE architectural concerns are also a motivating factor to this class of tool interfacing. For example, combinations of and , and described in the pre-vious section serve well for this class.

In summary, in addition to the achievements of the above two classes, class 3 interfacing must meet the goals of fine-grained synchronisation for control and data integration and component independence from architecture concerns. Tool construction and associated fine-grained synchronisation are key characteristics of this class. In contrast, fine-grained synchronisation between tools is not a characteristic of classes 1 and 2, while component independence in SDE architecture is not seen as a discriminating factor in this context.

2.4 Class variations

In the above subsections, we have classified three levels of tool interfacing with a gradual increase for improving productivity and the corresponding technological requirements that arise. We should note that the primary focus of this paper with its tool interfacing classification is for user productivity gains, no matter in which way. Therefore, we should not exclude some variations of tool interfacing with respect to improving the productivity of the users.

The productivity-centered classification should be viewed as a guidance. Any variation along this line should also be valued as long as it can help the user to improve the productivity. Some tools, for example, graphical user interface (GUI) editing tools, may provide tool construction service without provision of class 2 facilities of incrementality and/or concurrent execution and the class 3 requirement of synchronised control, and sometimes perhaps may not have explicit tool interfacing involved, i.e. single piece tools such as Visual Basic [19]. In this sense, they do not meet the criteria of class 3 interfacing since they may only qualify for the criteria of class 1. However, these GUI editors can clearly contribute to speeding up GUI development by requesting the user only dragging and dropping visually to generating the corresponding code (as tool construction) for the user. The user can easily build as well as modify the graphical user interface using a GUI editor and develop the software based on the tool assisted input (the code) and hence improve the productivity.

3 A tool interfacing architecture

As a basis for experimenting different interfacing classes, we use the conceptual architecture shown in Figure 1 [26, 28, 25]. There are many reasons why two or more applications/tools need to interoperate (as an integrated tool set), such as to exchange data or to programmatically control one another [14]. This tool interfacing architecture covering data and control integration reflects tool interoperability naturally.

Figure 1:
The conceptual architecture

The rationale for this architecture is as follows. Capabilities such as document input and editing, navigation, parameter definition, and software display, are all candidates for inclusion in the front-end, giving the user a uniform interface for a range of software-related activities. Use of a single general-purpose front-end in this way effectively meets the basic needs of user interface integration in that the user has a single framework for activation of the service tools involved, and feedback from these tools can in principle be collated and displayed by the front-end. The diversity of service support needed is met by the range of back-end service tools that can be activated via the front-end. The means (and ease) of adding such service tools is determined by the generic interface provided, which is in effect responsible for control and data integration.

Such an architecture may be seen as an extension of the design strategy for interactive systems, which separates user interface and functional application concerns into presentation and application layers. Our front-end is a user interface with built-in knowledge of the editing and display primitives appropriate to software objects, which separates these concerns from the service applications that deal with the meaning or semantics of the objects under manipulation.

Our assumption that a single general-purpose front-end is sufficient to meet the user's editing and display needs is in direct contrast to multiple concurrent view environments such as MultiView [9] and PECAN [15]. The architecture of these environments is specifically designed to allow simultaneous manipulation of a software object via multiple view processes, each with its own edit and display paradigm. The generic front-end UQ1 [23] supports the projection of multiple views of software objects, but with a common edit and display paradigm. Projection of (read-only) views based on other display paradigms can be incorporated via additional back-end tools. We feel, however, that the desirability of edit capabilities on such views remains an open question. At this stage, therefore, we retain an architecture in which all user editing of software objects occurs through a single front-end.

The purpose of the architecture described is to offer the user a uniform interface to a range of software development activities. In principle, for the purpose of experimentation, the front-end tool needs to be no more than a text editor with the capacity to control and feed the back-end verification tools involved. Environments based on the emacs editor [20] are examples of this approach. We note, however, that the inclusion of language knowledge in the front-end of the architecture proposed above is of immediate relevance to how communication is achieved between the front-end and the back-end tools. We therefore assume a language-based editing facility for the front-end as shown in Figure 1 and note that the nature of this language-based editing affects the representation of software objects which it must maintain. Editors which follow the tree-editing or template-based paradigms commonly use abstract syntax trees (ASTs) to represent the objects under edit, and rely on an unparsing process to regenerate the concrete textual or graphical representation required for display. Such ASTs are very similar to the representations needed by back-end tools for semantic analysis of the objects concerned. In contrast, editors which follow a text-recognition paradigm, and allow essentially text editing operations on the displayed object, commonly use much more concrete syntax trees (CSTs) to represent the objects concerned. In subsequent discussions of integration paradigms, we therefore recognise the need for significantly different representations between the front-end and the back-end tools with which it is integrated.

Clearly, it can be argued that the choice of the specific architecture proposed above may bias any conclusions about tool integration mechanisms which are arrived at by its use. A similar argument can be made about any architecture selected for experimental investigation. The argument should not, however, be seen as invalidating an experimental approach. Rather, it makes explicit the need to take account of such bias in presenting the experimental conclusions.

In the next section, we describe the experiments of the three interfacing classes defined in the previous section, followed by a subsection of demonstrations of experiments for illustration. Experimentation described is within the context of the architecture depicted in Figure 1, using the generic editor UQ1 as the front-end.

4 Interfacing experimentation

In the following subsections, we discuss a number of tool integration experiments in terms of the three interfacing classes introduced above. They are very much described as data integration oriented, with primitive yet sufficient illustration of corresponding control integration.

4.1 Class 1 interfacing experimentation

The simplest means of front-end/back-end "inte-gration" is file and operating system based. We term this the uncoupled interfacing paradigm since all communication among tools is via operating system facilities and each tool has its separately executable code, with no direct dependence on the others' existence. In general, referring to section 1, this paradigm is corresponding to / combination.

Figure 2 shows the typical information flow in the UQ1 realisation of the uncoupled paradigm. When verification of the document under edit is required, the front-end (FE) generates an intermediate ASCII file by unparsing its CST representation; this file is then parsed by the back-end (BE) to construct the AST representation required for verification. Feedback from the back-end is written to another intermediate file, and is integrated in the front-end display by a reverse mapping of the lines (and characters) positions in the first ASCII file to the front-end representation from which it was produced.

Figure 2:
Information flow in the uncoupled paradigm

Basically, the performance of this kind of integrated tool set is no better than that obtainable with separate use of unintegrated tools, only the user-generated delay can be eliminated to some extent, for the purpose of productivity improvement. Because of the coarse granularity of communication, fine-grained synchronisation associated with tool construction is not achievable. Therefore, the paradigm allows class 1 interfacing only. We note that this paradigm offers the lowest integration cost and the unique feasibility of integrating binary executable tools. We also note that this paradigm may be employed to introduce tool assisted input (tool construction) without achievement of classes 2 and 3 criteria.

At present, many environments utilise this simple integration paradigm based on operating system facilities or the like such as the Unix scripts and Emacs [20]. They normally achieve class 1 interfacing. In summary, the experimentation of this class can be applied to the similar cases in the tool integration context.

4.2 Class 2 interfacing experimentation

The directly contrasting approach to the uncoupled paradigm is the tightly-coupled interfacing paradigm, in which the tools are combined in a single executable system by linking compatibly compiled modules, communication among tools is by compiler generated calls, and they typically share an internal representation of the document concerned. In general, referring to section 1, this paradigm is corresponding to / combination.

Figure 3 shows the typical information flow in UQ1's tightly-coupled paradigm. The front-end and back-end effectively share the same representation, with automatic integration of front-end and back-end displays. To support the tightly-coupled paradigm in a generic fashion, the UQ1 front-end editor exports to back-end tools an appropriate abstract data type — AST. UQ1 retains explicit user activation of tightly-coupled tools, but the technique can be easily adapted to automatic tool activation.

Figure 3:
Information flow in the tightly-coupled paradigm

In addition to achieving the general requirements of tool integration, the key characteristic of the tightly-coupled paradigm is its capacity for elimination of tool-generated delay, for the purpose of productivity improvement. By direct sharing of the representation used by the front-end and back-end, all overheads associated with unparsing and parsing in the uncoupled paradigm are avoided, and fully incremental evaluation by the back-end is enabled. In this sense, the paradigm clearly allows class 2 interfacing. We note that this paradigm offers the best performance potential, but the integration cost could be high and not all tools could be integrated. We should also note that class 3 interfacing is achievable through this paradigm because it is possible to incorporate tool construction. However, such cases are limited, given that the construction tools are usually developed separately and compatible compilation and linking as well as internal representation sharing are difficult to achieve.

Most experiments with the tightly-coupled integration appear in programming environments based on language-based editors such as the GANDALF project [11], the Cornell Synthesizer Generator [17], and the CENTAUR system [1]. They have similar properties to our tightly-coupled prototype. In summary, the experimentation of this class can also be applied to the similar cases in the tool integration context.

4.3 Class 3 interfacing experimentation

As we evaluated in [26, 28, 25], the uncoupled and tightly-coupled paradigms are two extremes for tool integration, with directly complementary advantages and disadvantages. Various compromises termed loo-sely-coupled interfacing paradigms can also be comsidered, in which tools communicate by some means smarter than basic operating system facilities, but each tool has sufficient separation to maintain system flexibility. In general, referring to section 1, this paradigm is corresponding to combinations of / , / or some hybrid.

In UQ1, we have adopted a message passing approach for reasons similar to those asserted for Field in [16] but with more emphasis on fine-grained data integration. Figure 4 shows the typical information flow in UQ1's loosely-coupled paradigm. Front-end and back-end tools exist as separate, concurrently executing processes which communicate via some inter-process communication mechanism. Each maintains its own representation of the document under edit. Front-end and back-end representation transformation tables (RTTs) enable transceivers in the front-end and back-end to exchange AST/feedback transactions by direct communication when required.

Figure 4:
Information flow in the loosely-coupled paradigm

We note, as indicated in [26, 28, 25], the above loosely-coupled paradigm offers similar performance and feedback behaviour to the tightly-coupled paradigm, and a similar integration cost (in general) and similar degree of component independence to the uncoupled paradigm. Therefore, it offers an attractive SDE architecture. As initially used, however, the capacity for concurrent activity is exploited only to reduce data transmission overheads, and processing is interleaved only in a coarse-grained, user-determined way. As such, this initial implementation achieves only class 2 interfacing, but the potential for reaching class 3 interfacing with the same architecture clearly exists. That is, greater control synchronisation can be achieved in the circumstance of dealing with back-end feedback and front-end display of the feedback, especially when tool-assisted input (or tool construction) is involved rather than only (common) user input, for the purpose of productivity improvement. We note that most existing loosely-coupled systems do not (or maybe unnecessary to) provide this key facility of synchronous control required in class 3 interfacing.

The synchronisation capability of this message passing loosely-coupled integration architecture is later used in an effort to integrate an interactive theorem prover Demo2 [18] with UQ1 to provide better user interface support for theorem proving activities [6, 5]. In this exercise, the document (i.e., a proof) contains interleaved user input and tool contribution. The process of interactive theorem proving is such that the user enters a proof command and the prover accepts the command through the editor and responds with the result of the corresponding proof step. In most cases, both the command and the returned result are incorporated into the document. Such interaction continues until the proof is complete.

The proof commands and the results of individual proof steps are all fine-grained segments in the document. Therefore, the communication between the editor and the back-end tool (i.e. the prover) are fine-grained. In addition, the next command in the proof process usually depends on the prover's response to the previous command, so that the communication has to be synchronous. This shows that the loosely-coupled architecture is suited to fine-grained synchronisation while maintaining tool independence and high performance, i.e., achieving class 3 interfacing.

It should be noted that the information exchanged between the UQ1 editor and the Demo2 prover is in textual format rather in AST format. Since the communication is fine-grained, this has not led to the decrease in performance. On the contrary, this strategy does not need a complicated back-end transceiver, which would otherwise be required because the prover's internal representation is very different from that of the editor as in our case of integrating the UQ1 Z editor with Hippo [25] where Hippo is a Z type checker written in ML.

There are two basic approaches to pursuing loosely-coupled interfacing: one is to use a purpose-built database or object base as in PCTE [2] and CAIS [10] and the other is to use the message passing paradigm as in Field [16], SoftBench from HP [4] and FUSE from DEC [8]. Some hybrid models combining these basic approaches have also been investigated [9, 12, 3, 14]. For example, Microsoft OLE (object linking and embedding) [3] enables the integration of components through different relationships, from low to high levels using uniform data transfer, binding and other mechanisms. Another example is OMG CORBA (common object request broker architecture) [13] and Microsoft DCOM (distributed component object model) [14]. They are basically based on remote procedure calls (remote method invocation) and message/object passing which can be referred as the / combination addressed in section 1. Sometimes, in a client-server environment such as an Internet/Web-based cooperative editor, an instance of the editor tool can be the front-end for the local user and at the same time be the back-end for remote instances of the editor by propagating constructive materials to other users. In summary, the experimentation of this class can again be applied to the similar cases in the tool integration context.

4.4 Demonstrations of experimentation

Based on the previous subsections, we can draw a conclusion of which mechanisms should be used for tool integration, as detailed in [28, 25]. In summary, our architecture provides all mechanisms which can be chosen for integrating tools via either un-, tightly- or loosely-coupled approach. Using the uncoupled paradigm, it is cost effective from the software developer's viewpoint but it is not good enough from the user's perspective. Using the tightly-coupled paradigm, it shows the opposite characteristics. The loosely-coupled paradigm achieves the compromise which is much better in overall terms.

In this subsection, we demonstrate our experiments described in the previous subsections to show their working reality and in particular to illustrate explicitly how the tool construction is incorporated.

All the three interfacing paradigms described in subsections 4.1, 4.2 and 4.3 have been implemented with UQ1 as a generic interface. The screen dump of the Pascal editor is shown in Figure 5 which clearly demons-trates the back-end tool menu of Compile, Check Semantics and LC-check-sem, indicating the uncoupled Pascal compiler, the tightly-coupled and loosely-coupled Pascal semantic analysers for interfacing classes 1 and 2 respectively, and the integrated feedback obtained on invocation of any of these tools (the offending construct is highlighted in the editing pane of the left window, and the associated error report is displayed in the upper window).

Figure 5
: The screen dump of the Pascal editor

Figure 6 shows a screen dump of the theorem proving editor realised by integrating Demo2 into UQ1 using the loosely-coupled paradigm for interfacing class 3. The upper display window shows an overall proof sequence while the lower display window shows a nested sub-proof sequence which is represented in the upper display by the highlighted openwin command. In general, it shows that a proof is composed of interleaved user commands (in bold face) and tool responses (in box format).

Figure 6:
The screen dump of the Demo2 editor

5 Discussion on productivity gains

In this section, we discuss briefly on the potential user productivity gains according to our experimentation in particular and the classification in general. The aim of this discussion is for illustration of to what extent the user productivity can be improved.

Based on class 1 tool interfacing, time can be saved by eliminating the user input of such as typing commands and file names in our experimentation during software development, i.e. to eliminating user-generated delays. This is the explicit facet of improving productivity by saving perhaps several seconds each time from typing a file name which may accumulate a fairly amount of time in total during development of complex software. The implicit facet is that the user is also relieved from the situation of remembering such as various file names so as to allow him or her to concentrate on more important things for software development. Time saved in this respect is hard to measure in terms of absolute time saved regarding user productivity gains.

Based on class 2 tool interfacing, in addition to time saved by eliminating user-generated delays, time can also be saved by eliminating the tool-generated delays based on such as exploring incremental and concurrent execution. Different tools may achieve to various extent in this respect. This allows the user to improve the productivity by not wasting too much time on waiting for the tool response. In our experimentation, we have collected some typical data to illustrate.

Table 1 represents a typical comparison for our three interfacing paradigms which indicates the CPU time consumed by five specific user requests on a Pascal program of around 500 lines of code. The time measured is to accuracy of ten milliseconds. All times are shown in seconds in this table, as measured on a Sun 4/75. The initial loading time is the CPU time consumed in loading the program. For the uncoupled and tightly-coupled paradigms, this involves reading the program file, parsing the source and building the internal program representation. For the loosely-coupled paradigm, it also involves transmitting the initial AST representation to the back-end tool. The 1st analysis time is the CPU time consumed in analysing the whole program. The 2nd analysis time is the CPU time consumed in re-analysing the program without any intervening change. The FE 5 changes time is the CPU time consumed by five user updates of five different regions in which each region affected is around 50 lines of code (the normal size of a procedure). Together, the five changes imply re-analysing about half of the program. The base edit time depends on the edit command and is irrelevant to our consideration. We note, however, that in the loosely-coupled case this time is increased by the time required for transmission of the resultant change. The 3rd analysis time is the CPU time consumed in re-analysing the changed program after the fifth change.

Table 1:
The typical performance comparison

We briefly interpret the data displayed in the table for explanation of eliminating tool-generated delays compared to the uncoupled paradigm. We can see that in the tightly- and loosely-coupled paradigms, analysis time has been improvely significantly because it is unnecessary to generate intermediately files as in the uncoupled paradigm. You can see the additional time improvement for the 2nd analysis and 3rd analysis with involvement of incremental analysis. Impact of concurrent execution (of the front- and back-ends) can be evidenced in the loosely-coupled paradigm since it generally does not create more delays compared to the tightly-coupled paradigm although it does have extra transmission overheads between the front- and back-ends.

Based on class 3 tool interfacing, with the tool input, explicit time saved for user productivity gains can be potentially enormous, in additions to time saved from eliminating both user and tool generated delays. For example, in our experimentation, the proof editor helps the user to prove a theory the user wants to do. With the constructive help from the tool, the result would be much easily achieved. Another illustrative example may be graphical user interface (GUI) construction tools for software development, as a varia tion of tool interfacing. With a GUI tool such as Visual Basic, which may well be a single-piece tool, it is extremely helpful for a user to construct a graphical user interface visually on the computer monitor without any hassle to worry about the pixels, positions etc. in detail. Productivity gains in this respect is very well appreciated in the real world. In addition, of the implicit facet, with tool input, the quality of software is in general higher than that from scratch which implies the higher maintainability of software. This also clearly helps improving the productivity.

6 Conclusions and future work

Improving the user's productivity is the primary purpose of tool integration in software development environments. So it is a useful way to investigate a classification along this line. In this paper, we have proposed a three-level classification of tool interfacing which reflects this primary purpose. This is in contrast to the currently most popular classification based on the tool integration mechanisms such as user interface, control and data integration, which is from the environment developer's viewpoint (rather than from the user's viewpoint).

The productivity gains at three levels of integration of our classification are gradually achieved and discussed by eliminating user-generated delay, eliminating tool-generated delay, and especially introducing tool construction. This classification scheme provides the necessary guidance to the design and selection of tool integration mechanisms. It characterises the capability of tool integration mechanisms with respect to productivity gained by the user.

In terms of the new classification scheme proposed, we have discussed the experiments of uncoupled file-based tool integration (achieving class 1), tightly-coupled representation-sharing tool integration (achie-ving class 2 but feasible for class 3), and loosely-coupled message-passing tool integration (achieving class 2 and class 3). All these experiments use a uniform conceptual architecture for tool integration, and are carried out using the UQ1 editor as the generic front-end in this architecture, as demonstrated in the paper. The conclusions drawn from our experiments may be applied to tool integration in general.

The work presented in this paper focuses only on tool interfacing covering control and data integration, with primitive experimentation along the line of productivity improvement. In the future, ideally, more extensive experimentation should be carried out. In addition, we may need to investigate how to improve productivity in a much broader sense.

Acknowledgement

The work reported in this paper was partly funded by grants from the Australian Research Council. We are grateful for the insight of Prof. Jim Welsh. It may be impossible to form this paper without his involvement. We also thank for the help and advice of Warwick Allison, Paul Bakker, Anthony Cheng, Andrew Wood, as well as anonymous referees.

References

[1] P. Borras and D. Clément. CENTAUR: the system. ACM SIGPLAN Notices, 24(2):14-24, 1989.

[2] G. Boudier, F. Gallo, R. Minot, and I. Thomas. An overview of PCTE and PCTE+. ACM SIGPLAN Notices, 24(2):248-257,. 1989.

[3] K. Brockschmidt. Inside OLE. 2nd Edition, Microsoft Press, 1995.

[4] M. Cagan. HP SoftBench: an architecture for a new generation of software tools. Hewlett-Packard Journal, 41(3):37-47, 1990.

[5] A.S.K. Cheng, J. Han, J. Welsh, and A. Wood. Incorporating constructive tools into a generic language-based editor. In Proc. of 7th Australian Software Engineering Conference, pages 197-208, Sydney, Sept./Oct. 1993.

[6] A.S.K. Cheng, J. Han, J. Welsh, and A. Wood. Providing user-oriented support for software development by formal methods. In Proceedings of 6th Int. Workshop on CASE, pages 156-165, Singapore, July 1993. IEEE Computer Society Press.

[7] D. Clément. A distributed architecture for programming environments. ACM SIGPLAN Notices, 26(1):11-21, 1991.

[8] DEC. DEC FUSE environment. http://www.digital.com/info/SP4471, June 1996.

[9] C. D. Marlin. A distributed implementation of a multiple view integrated software development environment. In Proc. 5th. Conf. on knowledge-based software assistant, pages 388-402, Liverpool, New York, Sept. 1990.

[10] R. Munck, P. Oberndorf, E. Ploedereder, and R. Thall. An overview of DOD-STD-1838A (proposed), the common APSE interface set, revision A. ACM SIGPLAN Notices, 24(2):235-247, 1989.

[11] D. Notkin. The GANDALF project. J. of systems and software, 5(2):91-106, May 1985.

[12] H. Oliver. Adding control integration to PCTE. In A. Endres and H. Weber, editors, Proc. European symposium on software development environments and CASE technology, pages 69-80, Konigswinter, Germany, June 1991. Springer-Verlag. Also in Lecture Notes in Computer Science, Vol. 509.

[13] OMG. CORBA/IIOP 2.1 specification. http://www.omg.org/corba/c2indx.htm, Aug. 1997.

[14] F. E. Redmond III. DCOM Microsoft distributed component object model. IDG Books, 1997.

[15] S. Reiss. Graphical program development with PECAN program development environments. ACM SIGPLAN Notices, 19(5):30-41, 1984. Also in Proc. 1st ACM SIGSOFT symposium on software development environments, May 1984.

[16] S. Reiss. FIELD: a friendly integrated environment for learning and development. Kluwer Academic Press, 1994.

[17] T. Reps. Generating language-based environments. MIT Press, 1984.

[18] P. J. Robinson and T. G. Tang. The demonstration interactive theorem prover: Demo2.1. Technical Report 91-4, Software Verification Research Centre, The University of Queensland, St. Lucia, Australia, September 1991.

[19] P. Shackleton and D. McConville. Program design through Visual Basic. Data Publishing, 1996.

[20] R. M. Stallman. EMACS: the extensible, customizable, self-documenting display editor. In D. R. Barstow, H. E. Shrobe, and E. Sandewall, editors, Interactive programming environments, pages 128-140. Mcgraw-Hill, 1984.

[21] A. I. Wasserman. Tool integration in software engineering environments. In F. Long, editor, Proc. Int. Workshop on environments, 137-149, Chinon, France, Sept. 1989. Springer-Verlag. Also in Lecture Notes in Computer Science, Vol. 467.

[22] A. I. Wasserman. Requirements for OO design environments. In Proc. Software Engineering Environments, pages 207-211, Noordwijkerhout, The Netherlands, Apr. 1995.

[23] J. Welsh, G. Rose, and M. Lloyd. An adaptive program editor. The Australian Computer Journal, 18(2):67-74, 1986.

[24] J. Welsh and Y. Yang. Tool integration techniques. In P. A. Bailes, editor, Proc. 6th Australian Software Engineering Conference, pages 405-418, Sydney, July 1991.

[25] J. Welsh and Y. Yang. Integration of semantic tools into document editors. Software - Concepts and Tools, 15(2):68-81, 1994. Springer-Verlag.

[26] Y. Yang. Tool interfaces for software development. PhD thesis, Department of Computer Science, The University of Queensland, Australia, 1992.

[27] Y. Yang and J. Han. Classification of and experimentation on tool interfacing in software development environments. In Proc. of Asia-Pacific Conf. on Software Engineering, 56-65, Seoul, Korea, Dec. 1996. IEEE Computer Society Press.

[28] Y. Yang, J. Welsh, and W. Allison. Supporting multiple tool integration paradigms within a single environment. In Proc. 6th Int. Workshop on CASE, pages 364-374, Singapore, July 1993. IEEE Computer Society Press.

Publication Dates

• Publication in this collection
  21 Dec 1998
• Date of issue
  July 1998