Leon J. Osterweil

Software processes are software too

The major theme of this meeting is the exploration of the importance of process as a vehicle for improving both the quality of software products and the way in which we develop and evolve them. In beginning this exploration it seems important to spend at least a short time examining the nature of process and convincing ourselves that this is indeed a promising vehicle.

Data Flow Analysis in Software Reliability

The ways that the methods of data flow analysis can be applied to improve software reliability are described. There is also a review of the basic terminology from graph theory and from data flow analysis in global program optimization. The notation of regular expressions is used to describe actions on data for sets of paths. These expressions provide the basis of a classification scheme for data flow which represents patterns of data flow along paths within subprograms and along paths which cross subprogram boundaries. Fast algorithms, originally introduced for global optimization, are described and it is shown how they can be used to implement the classification scheme. It is then shown how these same algorithms can also be used to detect the presence of data flow anomalies which are symptomatic of programming errors. Finally, some characteristics of and experience with DAVE, a data flow analysis system embodying some of these ideas, are described.

Foundations for the Arcadia environment architecture

Early software environments have supported a narrow range of activities (programming environments) or else been restricted to a single “hard-wired” software development process. The Arcadia research project is investigating the construction of software environments that are tightly integrated, yet flexible and extensible enough to support experimentation with alternative software processes and tools. This has led us to view an environment as being composed of two distinct, cooperating parts. One is the variant part, consisting of process programs and the tools and objects used and defined by those programs. The other is the fixed part, or infrastructure, supporting creation, execution, and change to the constituents of the variant part. The major components of the infrastructure are a process programming language and interpreter, object management system, and user interface management system. Process programming facilitates precise definition and automated support of software development and maintenance activities. The object management system provides typing, relationships, persistence, distribution and concurrency control capabilities. The user interface management system mediates communication between human users and executing processes, providing pleasant and uniform access to all facilities of the environment. Research in each of these areas and the interaction among them is described.

Dave—a validation error detection and documentation system for fortran programs†

This paper describes DAVE, a system for analysing Fortran programs. DAVE is capable of detecting the symptoms of a wide variety of errors In programs, as well as assuring the absence of these errors. In addition, DAVE exposes and documents subtle data relations and flows within programs. The central analytic procedure used is a depth first search. DAVE itself is written in Fortran. Its implementation at the University of Colorado and some early experience are described.

On Two Problems in the Generation of Program Test Paths

In this paper we analyze the complexity of algorithms for two problems that arise in automatic test path generation for programs: the problem of building a path through a specified set of program statements and the problem of building a path which satisfies impossible-pairs restrictions on statement pairs. These problems are both reduced to graph traversal problems. We give an efficient algorithm for the first, and show that the second is NP-complete.

Little-JIL/Juliette: a process definition language and interpreter

Little-JIL, a language for programming coordination in processes is an executable, high-level language with a formal (yet graphical) syntax and rigorously defined operational semantics. The central abstraction in Little-JIL is the step, which is the focal point for coordination, providing a scoping mechanism for control, data and exception flow and for agent and resource assignment. Steps are organized into a static hierarchy, but can have a highly dynamic execution structure including the possibility of recursion and concurrency. Little-JIL is based on two main hypotheses. The first is that coordination structure is separable from other process language issues. Little-JIL provides rich control structures while relying on separate systems for resource, artifact and agenda management. The second hypothesis is that processes are executed by agents that know how to perform their tasks but benefit from coordination support. Accordingly, each Little-JIL step has an execution agent (human or automated) that is responsible for performing the work of the step. This approach has proven effective in supporting the clear and concise expression of agent coordination for a wide variety of software, workflow and other processes.

Language constructs for managing change in process-centered environments

Change is pervasive during software development, affecting objects, processes, and environments. In process centered environments, change management can be facilitated by software-process programming, which formalizes the representation of software products and processes using software-process programming languages (SPPLs). To fully realize this goal SPPLs should include constructs that specifically address the problems of change management. These problems include lack of representation of inter-object relationships, weak semantics for inter-object relationships, visibility of implementations, lack of formal representation of software processes, and reliance on programmers to manage change manually. APPL/A is a prototype SPPL that addresses these problems. APPL/A is an extension to Ada.. The principal extensions include abstract, persistent relations with programmable implementations, relation attributes that may be composite and derived, triggers that react to relation operations, optionally-enforceable predicates on relations, and five composite statements with transaction-like capabilities. APPL/A relations and triggers are especially important for the problems raised here. Relations enable inter-object relationships to be represented explicitly and derivation dependencies to be maintained automatically. Relation bodies can be programmed to implement alternative storage and computation strategies without affecting users of relation specifications. Triggers can react to changes in relations, automatically propagating data, invoking tools, and performing other change management tasks. Predicates and the transaction-like statements support change management in the face of evolving standards of consistency. Together, these features mitigate many of the problems that complicate change management in software processes and process-centered environments.

The design of a next-generation process language

Process languages remain a vital area of software process research. Among the important issue for process languages are semantic richness, ease of use, appropriate abstractions, process composability, visualization, and support for multiple paradigms. The need to balance semantic richness with ease of use is particularly critical. JIL addresses these issues in a number of innovative ways. It models processes in terms of steps with a rich variety of semantic attributes. The JIL control model combines proactive and reactive control, conditional control, and more simple means of control-flow modeling via step composition and execution constraints. JIL facilitates ease of use through semantic factoring, the accommodation of incomplete step specifications, the fostering of simple sub-languages, and the ability to support visualizations. This approach allows processes to be programmed in a variety of terms, and to a variety of levels of detail, according to the needs of particular processes, projects, and programmers.

Software processes are software too, revisited: an invited talk on the most influential paper of ICSE 9

The ICSE 9 paper, “Software Processes are Software Too”’ suggests that software processes are themselves a form of software and that there are considerable benefits that will derive from basing a discipline of software process development on the more traditional discipline of application software development. This paper attempts to clarify some misconceptions about this original ICSE 9 suggestion and summarizes some research carried out over the past ten years that seems to confirm the original suggestion. The paper then goes on to map out some future research directions that seem indicated. The paper closes with some ruminations about the significance of the controversy that has continued to surround this work. Introduction “Software Processes are Software Too.” How many times I have heard that phrase quoted back to me in the past ten years! And how many times it has been (sometimes amusingly) misquoted too. Often I have been flattered to have had the ICSES paper [15] and its catchy title referred to as being “classic” and “seminal”. But often I have also been asked, “what does that really mean?” The idea is, alas, still misunderstood and misconstrued in some quarters. But amazingly, and gratifyingly, the phrase is still used, and the discussion of the idea still continues, even after ten years. The suggestion that software, and the processes that deal with it, might somehow be conceptually similar remains a powerfully appealing one that seems to have *This work was supported in part by the Air Force Materiel Command, Rome Laboratory, and the Defense Advanced Research Projects Agency under Contract F3060294-C0137. permission to &ke digitafiard copies of all or part ofthis mate&l for perSonal or classroom use is granted without fee provided that the copies we not made or distributed for profit or commercial advantage, the copy@bt notice, the title ofthe publication and its date appear, and notice is &‘a that copyright is by permission oftbe ACM, Inc. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires specific permission and/or fee ICSE 97 Boston MA USA Copyright 1997 ACM 0-89791-914-9/97/05 ..

Cecil: a sequencing constraint language for automatic static analysis generation

3.50 led to a considerable body of investigation, The suggestion was immediately controversial, and continues to be argued. Subsequently I discuss why I believe this discussion indicates a pattern of behavior typical of traditional scientific inquiry, and therefore seems to me to do credit to the software engineering community. But what of the (in)famous assertion itself? What does it really mean, and is it really valid? The assertion grew out of ruminations about the importance of orderly and systematic processes as the basis for assuring the quality of products and improving productivity in developing them. Applying the discipline of orderly process to software was not original with me. Lehman [13] and other8 [18] had suggested this long before. But I was troubled because I had started to see the development of a whole new discipline and technology around the idea of software process, and to notice the emergence of many notions and tools that seemed eerily familiar. I was starting to see the creation of a software process universe parallel to the universe of notions and tools surrounding application software development. The more I looked, the more similarities I saw. Processes and applications are both executed, they both address requirements that need to be understood, both benefit from being modelled by a variety of sorts of models, both must evolve guided by measurement, and so forth. Thus it seemed important to suggest that software process technology might not need to be invented from scratch (or reinvented), but that much of it might be borrowed from application software technology. I have often been reminded that application software technology is still badly underdeveloped and that using it as a model for software process technology might be of dubious value. This, however, overlooks clear evidence that, while we have not mastered application software technology, we have, nevertheless, created a powerful assortment of tools, principles, and techniques in this domain. Thus, there is much to be gained from using obvious parallels to hasten the maturation of software process technology. It seemed important to suggest that the community should look to the more traditional and better-developed disciplines of application development to see what might be borrowed or adapted. It seemed clear that there were strong similarities, but likely that there were differences as well. Investigation of the extent of each seemed to be in order. The ICSE 9 talk invited community investigation of how processes and application software are the same and how they differ, so that relevant findings, approaches, and tools of one could be of use to the other. It has been gratifying to see that this invitation has been taken up and that these explorations are still ongoing. Conversely it has been disappointing to see the way in which the suggestion has continued to be misconstrued in some quarters. Subsequent sections will deal with these misconceptions in more detail, but the following brief summary seems in order here. Software is not simply code. Neither are software processes. Application software generally contains code. This suggests that software processes might also contain code. Coding software processes thus seems to be an interesting possibility. Research has borne this out. Programming is not the same as coding, it entails the many diverse steps of software development. Software process programming should, likewise, not simply be coding, but seemed to entail the many non-coding steps usually associated with application development. Process modelling, testing, and evolution research seems to have borne that out. There are many examples of application code that are not inordinately prescriptive, authoritarian, or intolerable to humans (eg. operating systems). Thus, there should be no presumption that process code must be overly prescriptive, authoritarian, or intolerable either. Process programs need not treat humans like robotsunless that is the intention of the process programmer. Process modellmg and coding languages demonstrate this. Finally, good software code is written at all levels of detail. Code contains fine scale details, but they emerge at lower levels, after high level code addresses larger issues. Similarly process code contains details that are nested below higher abstract levels. Process code, like application code, can demonstrate that precise implementation of broader notions in terms of lower level engineering details. Contemporary process coding languages demonstrate this too. The following section summarizes some research that suggests continued and broadened research into these issues. Parallels Between Software Processes and Appli-