Facilitating process prototyping by controlling the impact of change

Abstract

The UMass Software Development Laboratory (SDL), in collaboration with our colleagues in the Arcadia consortium [7], is working toward the development of advanced software environments. An important goal of this work is to support research on software processes. It is increasingly clear that such research must be based on experimental, exploratory, prototyping activities. It is equally clear that process prototyping will require a corresponding ability to rapidly produce and easily modify prototype software environments. As a result, one important element of SDL's environment research has been the development of appropriate tools and techniques to facilitate environment prototyping. An application-oriented notation and a software reuse capability are two frequently proposed approaches for supporting software prototyping in many traditional application areas. Another common approach is the use of a high-level language that is interpreted rather than compiled. Often the language is weakly typed, or typeless, and any type checking that it might provide is done at run time rather than statically. For certain well-understood applications, the language may be application-oriented. More often it is a general-purpose language such as LISP. Such languages facilitate rapid development and easy modification in part because avoiding the time required to compile or type check reduces development and modification time. While these approaches are beneficial for rapid creation of a software system, they are not as valuable for supporting the easy modification that is required in experimental situations. This is particularly true if the prototype system being modified is large and complex. Realistic process experimentation will require the use of full-fledged software environment prototypes. Such prototypes are by nature large, complex and highly interrelated collections of components. Those components include tools, such as editors, compilers, testing and debugging support systems and the like, and also data objects, such as source text, abstract syntax trees, object modules, symbol tables, test data sets, test results and many others. The components are highly interrelated in that a typical activity by an environment user will involve coordinated actions by several tools affecting several (typically shared) data objects. These characteristics of environment prototypes have led us to conclude that tools and techniques for controlling the impact of change are of primary importance for facilitating the prototyping of environments. Controlling the impact of change in environment prototyping is intimately related to the information visible through the interfaces of environment components. A change to an environment component can only have an impact on another component if that other component can observe the change. Thus, the more that a component's interface conceals information about aspects of the component that may change, the less chance there is for a change to have an impact on other components, in particular on components not interested in the change. One class of approaches to controlling the impact of change, therefore, heavily restricts the information content of components' interfaces. An alternative is to provide information-rich interfaces, but carefully control which other components are allowed to observe (some or all of) the information in a given component's interface. We have found that these two classes of approaches, and variants within them, offer different advantages and disadvantages. To date, we have explored three particular approaches that fall within these classes. The three approaches can be characterized as follows:Externally-interpreted descriptions. An environment component's interface reveals little or nothing about the component's properties. Instead, descriptive information about the component is encoded in a data structure, possibly within the component itself. Other environment components seeking to use the data object must interpret the description at run time. Access to the description and to the component is through a general purpose (i.e., information-poor) interface. Internally-interpreted descriptions. An environment component's interface reveals little or nothing about the component's properties. Instead, descriptive information about the component is procedurally encoded in the bodies of the component's access routines. Other environment components seeking to use the component must make appropriately parameterized requests on the access routines via the component's general purpose (i.e., information-poor) interface. The routines determine the acceptability of those requests at run time. Precise interface control. Descriptive information about a component (e.g., the kinds of information contained in a data object) is explicitly presented in the component's interface. Visibility of that information is explicitly controlled so that only those other environment components interested in some aspect of the information are able to observe it. Specifically, in our work on environment prototyping, we have been using three tools that illustrate these three approaches. They are:IRIS, a graph-based scheme for representing the static semantics of computer programs [1,6]; GRAPHITE, an abstract data type generator for user-specified classes of graphs [2]; and PIC, a language framework and analysis technique for precisely describing and analyzing module interfaces [10,11]. A more complete discussion of the three approaches, the tools, and our experiences with them appears in [9]. Other researchers have implemented and used tools and techniques for controlling the impact of change in prototyping situations. Examples include innumerable users of LISP or PROLOG, as well as such software engineering efforts as GANDALF [3], Infuse [4], the Cornell Synthesizer Generator [5], “smart recompilation” [8] and others. In general, however, these efforts have employed just one approach to controlling the impact of change, whether one of the ones described here, a hybrid approach or some other point on the continuum implied by the three we have discussed. Our work is unusual in that we have implemented and explored three quite different points within that continuum. Our conclusion, based upon our experience with these three tools, is that all three of the approaches that we have used are well suited for facilitating environment prototyping by helping to control the impact of change. Their appropriate uses differ somewhat, however. The IRIS approach is well suited for its originally intended purpose, namely to facilitate change to a language's semantic definition (e.g., adding new primitive operators). It is not as appropriate for use in other prototype change situations, such as adding a new analysis tool. In such situations, the decentralized dynamic type-checking and the complexity involved in determining which components are interested in the change make changing the prototype too difficult and error prone. We are planning to develop a GRAPHITE implementation of IRIS precisely so that both kinds of change will be supported with appropriate impact control techniques available for each. In other situations, information-rich interfaces seem preferable to the information-poor interfaces of the IRIS and GRAPHITE approaches. There also seem to be cases where different components should be able to observe different aspects of an interface, whether information-rich or information-poor. Obviously, in such cases, the PIC approach seems the best choice. We are currently considering merging the PIC capabilities with either or both of the other two approaches. Such a synthesis could offer advantages over all of the approaches that we have explored thus far.