COTS, integration, package-oriented programming, reuse, wrappers, mediators, architecture, software engineering

We present an innovative fault-tree analysis tool that we developed using a novel software architectural style that we call package-oriented programming (POP). The tool is largely implemented using multiple, tightly integrated, shrink-wrapped software packages as components. These packages are integrated using custom-coded integration mediators into a cohesive superstructure that provides much of the functioning required of many sophisticated modeling and analysis tools. In addition to serving as a proof of concept, the tool provides a test-bed for further research on the approach.

Sophisticated, specialized software tools are needed in many engineering activities and disciplines. Unfortunately, it is hard and expensive to build such tools quickly and inexpensively. One result is that when the market is small for a tool supporting a new technique, it is either prohibitively expensive to develop the tool or it ends up functionally inadequate. Lack of tool support then inhibits the use and development of the technique. We need ways to build sophisticated tools quickly and inexpensively.

In our research program, we are exploring a new technique for building high-value, industrially viable tools quickly and at low cost using a novel architectural style that we call package-oriented programming (POP). The POP style is based on the use (or reuse, if you prefer) of massive, architecturally coherent, interactive components as basic building blocks [3]. In current work, we are using modern, commercial off-the-shelf (COTS), shrink-wrapped software packages as these basic building blocks.

The idea of reusing package software is hardly new. However, innovations appearing in recent packages, such as those of Microsoft Office, have created promising new architectural possibilities. We have demonstrated that we can implement powerful, cohesive software tools using tightly integrated systems of such packages to provide the bulk of the function needed in such tools.

This approach to software construction appears to be novel and interesting enough that it suggests new thinking on a range of software engineering issues. How does the use of massive, executable packages as components affect modularity, reuse, the software lifecycle, the construction of documentation, testing, and evolution? The POP style also touches on issues of increasing concern to a growing number of people, especially the trend toward system development through the "wrapping" and integration of only partially known and independently developed COTS.

We chose software tools as a domain in which to explore POP architecture because there seemed to be a good match between the requirements of many software tools and the availability of particular large-scale components. In particular, many tools seem to split into small specialized modeling and analysis kernels that are surrounded by vast superstructures supporting such functions as technical drawing, text editing, data entry and management, report generation, and so on. Attacking the essence of the tool construction problem thus demands an effective attack on the problem of building tool superstructures.

In earlier work, Garlan et al. [1] described the difficulties that they faced when attacking a similar problem through an approach based on the reuse of large-scale components. The problem was that the selected components turned out to be architecturally incompatible, even though they were ostensibly designed to be reusable.

We noted claims of not only architectural compatibility but also ease of specialization and integration made by the vendors of a range of shrink-wrapped software packages. We hypothesized that these components supported large-scale reuse and that they would shed light on how to design components for such reuse. In particular, we thought we might build tool superstructures by specializing and integrating just a few of these massive components in simple and straightforward ways. We believe that we have demonstrated the potential of the POP architectural style.

Our demonstration application is a tool for fault-tree analysis [7] that support novel modeling and analysis techniques developed by Dugan and her students [2]. We built our tool superstructure by specializing and integrating packages that support technical drawing, text editing, and data management. In particular, we used Visio Corporation’s Visio drawing program and Microsoft’s Word and Access programs.

We specialized these packages using their built-in specialization mechanisms. We integrated them with each other and with the computational core (which we ported from Dugan’s tool) by writing a program in Microsoft’s Visual C++ that essentially functions as a large-scale integration mediator [4,5,6]. This mediator presents an interface to the user for controlling the tool. We use information hiding, integrity-maintaining interfaces, or "wrappers," implemented as C++ classes, to abstract the packages. These wrappers use OLE Automation (a Microsoft-defined, late-bound, remote procedure call mechanism now supported by many software packages) to manipulate the underlying packages.

Our experience has been positive in that we have been able to build a sophisticated tool with a significant level of useful functioning quickly and at low cost. We believe in particular that we have achieved a new level of integration of COTS shrink-wrapped packages employed as reusable components.

However, some important issues remain unresolved. One problem is that the packages we have used do not support wrapping, or encapsulation, adequately. The result is that users can execute package functions that violate integrity constraints imposed by the tool of which the packages are components. In essence, users have undue access to the "implementation details" of the tool. We need mechanisms that will permit designers who want to use packages as components to selectively hide and restrict package functions whose execution would violate such constraints. Of course, we want to be able to do this while leaving the desired, powerful functions of the packages available to the tool user.

Other problems remain as well, of course; but the demonstrated promise of package-oriented programming appears to be sufficient to warrant ongoing investigation. We can see emerging, vaguely, powerful new concepts of modularity that just might provide a basis for profitable software construction through large-scale, systematic reuse in the not-too-distant future.

This work was supported by the National Science Foundation under grants CCR-9502029, CCR-9506779, and MIP-95-29258; by the Defense Advanced Research Projects Agency (DARPA) through Rome Labs AFB under grant F30603-96-1-0314; and with a software grant from the Visio Corporation.