Robert Balzer

A 15 Year Perspective on Automatic Programming

Automatic programming consists not only of an automatic compiler, but also some means of acquiring the high-level specification to be compiled, some means of determining that it is the intended specification, and some (interactive) means of translating this high-level specification into a lower-level one which can be automatically compiled.

On the inevitable intertwining of specification and implementation

Contrary to recent claims that specification should be completed before implementation begins, this paper presents two arguments that the two processes must be intertwined. First, limitations of available implementation technology may force a specification change. For example, deciding to implement a stack as an array (rather than as a linked list) may impose a fixed limit on the depth of the stack. Second, implementation choices may suggest augmentations to the original specification. For example, deciding to use an existing pattern-match routine to implement the search command in an editor may lead to incorporating some of the routines features into the specification, such as the ability to include wild cards in the search key. This paper elaborates these points and illustrates how they arise in the specification of a controller for a package router.

Transformational Implementation: An Example

A system for mechanically transforming formal program specifications into efficient implementations under interactive user control is described and illustrated through a detailed example. The potential benefits and problems of this approach to software implementation are discussed.

Informality in Program Specifications

This paper is concerned with the need for computer-based tools which help human designers formulate formal process-oriented specifications. It first determines some attributes of a suitable process-oriented specification language, then examines the reasons why specifications would still be difficult to write in such a language in the absence of formulation tools. The key to overcoming these difficulties seems to be the careful introduction of informality based on partial, rather than complete, descriptions and the use of a computer-based tool that uses context extensively to complete these descnrptions during the process of constructing a well-formed specification. Some results obtained by a running prototype of such a computer-based tool on a few informal example specifications are presented and, finaliy, some of the techniques used by this prototype system are discussed.

Tolerating inconsistency (software development)

The author presents a simple technique for creating a formalism that allows development environments and other software systems to tolerate and manage their inconsistencies. It softens constraints without introducing special cases by treating violations as temporary exceptions which will eventually be corrected. Until then the offending (i.e., inconsistent) data are automatically marked by guards to identify it to code segments that can help resolve the inconsistency-normally by notifying and involving human agents-and to screen such inconsistent data from other code segments that are sensitive to the violation. The formalism which performs the above operations is described.<<ETX>>

Mediating connectors: a non-bypassable process wrapping technology

We have developed a technology for mediating all shared library calls. These mediators can be used to instrument these interfaces, monitor their behavior, integrate legacy components together, or encapsulate potentially harmful or unreliable components. They can be dynamically installed and removed during execution or installed before execution begins. Since modern commercial operating systems promote packaging third party functionality as shared libraries and are themselves composed of shared libraries the ability to mediate these interfaces provides access to the broad range of services available on that platform. We have hardened this mediation technology to prevent its bypass or removal by malicious code and applied it to increase the security and integrity of processes. An implementation of this technology is available for Windows NT.

Integrating COTS Software into Systems through Instrumentation and Reasoning

Commercial-off-the-shelf (COTS) software tends to be cheap, reliable, and functionally powerful due to its large user base. It has thus become highly desirable to incorporate COTS software into software products (systems) as it can significantly reduce development cost and effort, while maintaining overall software product quality and increasing product acceptance. However, incorporating COTS software into software products introduces new complexities that developers are currently ill equipped to handle. Most significantly, while COTS software frequently contains programmatic interfaces that allow other software components to obtain services from them on a direct call basis, they usually lack the ability to initiate interactions with other components. This often leads to problems of state and/or data inconsistency. This paper presents a framework for integrating COTS software as proactive components within a software system that maintain the consistency of the state and data they share with other components. The framework utilizes a combination of low-level instrumentation and high-level reasoning to expose the relevant internal activities within a COTS component required to initiate the communication needed to maintain consistency with the other components with which it shares state and data. We will illustrate these capabilities through the integration of IBMs Rational Rose into a design suite and demonstrate how our framework solves the complex data synchronization problems that arise from this integration.

Assuring the safety of opening email attachments

A wrapper has been developed that monitors the runtime behavior of opened email attachments to ensure that these processes do not do anything harmful. The wrapper detects violations of process-specific rules establishing the acceptable (and safe) behavior of these processes relative to four resources: the file system, the system registry, inter-host communication, and process spawning. The wrapper can determine whether an operation is being performed by the native application or by active content within the email attachment and applies a different (and presumably more stringent) set of rules to the latter. When attempted violations are detected, the user is notified and informed of the severity of the violation. The user determines whether to allow or prohibit the offending operation. The violation, the users response, and the initiating email and attachment-obtained from the email client-are logged.

The Briefing Associate: easing authors into the Semantic Web

The Semantic Web has clear benefits for information consumers, but for authors it typically means added work with no immediate payoff. This article describes Briefing Associate (BA), a tool that eases the effort by automating markup within a popular commercial off-the-shelf (COTS) application. The BA is a descendent of the Design Editor, an application for producing visual, domain-specific design environments. Both tools are implemented as extensions of Microsofts PowerPoint, which, as this paper describes, is a key factor in our research.

Mechanisms for generic process support

As more and more programming environments incorporate explicit process descriptions, generic process capabilities will become crucial to the convenient instantiation and maintenance of process description. However, partly because process modeling languages have followed the example of programming languages in general, they are surprisingly weak in supporting generic process descriptions.We propose mechanisms whereby generic process capability can be added to any process formalism. The generic portions of the process description can then be refined through instantiation. We define a system architecture in which a generic process description can be refined gradually during its enactment. Such capabilities will be crucial to incorporating explicit process descriptions into the program environments of the future.