Control (session summary)

Abstract

Bob Balzer initiated the discussion with the contentious claim that planning languages are the proper basis for process models. He then divided the participants into two general camps according to their position papers: those for and those against the planning thesis with subgroups of zealots, believers and supporters. The argument for the thesis is exemplified by two approaches taken by the zealots: 1) [Huff's view] process definition as a plan instantiation — plan construction is subgoaling, envisionment is done via explicit pre and post conditions, and exceptions are handled via replanning; and 2) [Thomas' view] process as a goal-directed activity — where planning separates and systematizes execution dynamics from model dynamics and the paradigm is plan, instantiate, and replan. Balzer listed (by first author on the basis of the position papers) Curtis, Dieters, Heimbigner, Kaiser, Roberts and Balzer as believers in this position, and Boehm, Carr, Cheatham, Feiler, Finkelstein, Kishida, Lehman, Matsumoto, Nakajima, Redwine, Rombach, Scacchi, and Zave as supporters of this position. The argument against the thesis is exemplified by the process programming camp where it is held that process languages will strongly resemble programming languages and that properly conceived and developed environments can support both process and product development. Implicit in this approach is the claim that current languages are sufficient and that there is experience to support this claim. Balzer remarked that the examples in the position papers did not supply a sufficient basis for this claim. Unfortunately, Lee Osterweil had been unable to attend and support his position (though it was in fact supported rather eloquently by others). Garlan, Kellner, Nakagawa, Sugiyama and Wileden were listed by Balzer as believers, and Katayama was listed as a supporter. (Humphrey, Minksy, Penedo, and Reiss were listed as “other”.) The force fit into one of two camps was strongly objected to. Dowson noted that we need to look at the harder issues and support for them, provide abstract arguments and reasoning about them. There may be elements of planning languages and elements of standard languages in a multiparadigm environment. It was also noted that there was as little evidence on the planning paradigm side as was claimed for process programming. In particular, we have not seen any non-trivial plans. Finkelstein noted that the “pro” camp was anyone with a slightly AIish flavor and that his work stressed the local management of the process where the dominant features result from the manipulation of the minutia of work rather than of overall goals. Further we need to keep the methodic angle in full view — that is, we are concerned with more than just the invocation of tools. Further discussion centered on modeling and the levels of description required — for example, descriptions that range from very general goals to explicit, detailed descriptions of how things are to be done. Wileden pointed out that planning languages are very vague about how a goal is to be achieved, but very good at recognizing what has been done. It was pointed out by Kellner that there are various objectives that may be desired in a model and these may differ from one context to another. In order to adequately compare objectives, we need to identify the context. For example, a general goal may not be particularly useful in the context of learning. We may need more guidance in how to achieve the goal, need more structure, need a more detailed “roadmap”. In this sense, planning is often more “implicit” than “explicit”, though it is often claimed as the reverse. In general, we need a wide variety of plans from general goals to detailed descriptions. Feiler and Zave agreed that we needed multiple paradigms: in the case of building a system, we may need only general goals; in the case of training, we need details. Roberts agreed with Dowson and went on to point out that planning is relevant because that is what we do in the actual process: we plan, analyse, design, instantiate, evaluate and replan. Huff noted that we need to cover a range of planning in the processes. Some environments need highly structured process while others do not. We need to keep in mind both the process and the product (the one is bound up in the other). Thomas rightly noted that the underlying computation model was exceedingly important in considering the language of expressing processes in all their generality and detail. Dynamism was another important topic of discussion. Balzer noted that the problems of process creation during enactment were compounded by the results of creative human input and by unplanned reactive elements. Some discussion centered around what was meant by “creation”. Balzer indicated that he was concerned here with filling in a generic process, or instantiating a process, not with defining a new process. Perry noted that this is what happens in his and Kaiser's Infuse prototype: module change and module integration processes are instantiated dynamically according to the structure of the product at that particular time. The relative strength of planning lies in that fact that it has a more explicit representation of the process (thereby providing increased comprehension) and that it is more modular (and hence more evolvable). Further, problems of process evolution (that is, changes in the nature of the process) are brought about because of new capabilities, new restrictions, or new objectives. In the imperative approach, one needs to add a new definition and integrate it operationally while in the planning approach, one adds the new definition and integration is automatic. Tully responded that the identification of non-planning with imperative was too simplistic. Balzer agreed but argued that he was trying to characterize a whole class of languages. This led to a discussion of the specification problem of “white lies”. Finkelstein distinguished two meanings to “white lies”: meaning 1 is that we start with an incorrect specification and systematically correct it; meaning 2 is that we maintain that the while lie is a satisfactory explanation, but we run into hiccups that we try to gloss over. Meaning 1 has implications for planning languages; meaning 2 has implications for imperative languages. Balzer responded that he believed in both scenarios: in the case of trying to bring someone up to speed, one provides white lies; in the case trying to understand something, one often believes white lies that one does not yet know are not quite true. According to Scacchi, process fragments provide the needed modularity. There are drawbacks to AI/planning that are not appropriate to process modeling. One can get flexibility from planning, but we need encapsulation coupled with a multi-paradigm approach. Kellner noted that in human thinking, we get an exceedingly complex balancing act. Can planning handle that? Can we identify what the human goals are, what their hidden agenda's are? How do you get that out of people and make use of it in process models? In a non-planning approach, we look at procedural issues — we look at what people do in order to better understand how to do it. But how do we get the plans? Planning is much more concise, noted Wileden. In order to get the equivalent thing in other languages we have to write the explicit ways to achieve the goal. Hence, planning languages are much more implicit, not more explicit. If we already have a way of satisfying the goal, then integration of the goal into the model is easy. But if we have a new goal, then we need something to tell us when to use it and how to satisfy it. Balzer offered two observations: 1) in implementing a planning system, one might use an imperative language; and 2) planning language advantages are also advantages of guarded command languages — one must distinguish the model from the explicit representation. Thomas noted that planning languages were more dynamic that guarded command languages. If you add a new guard, you still have the same computational model. The planning language proponents were asked by Curtis to describe the largest thing built using a planning language. Huff named SITE, the mobile robot, at SRI. The size of the system is defined as the number of alternatives. Interactions among these alternatives cause an increase in time. However, several hundred subgoals were achieved in 1/2 minute of execution time. This example was for a single agent. The problem is that we have multiple agent interactions in software development processes. Dowson noted that we do project plans in building systems. Some succeed, some do not. For example, consider the following conditions under which a plan might be executed and maintained: 40 man years of implementation effort described in 100 pages or so, using various tools and providing fairly complete detailed descriptions, etc. We would like to be able 1) to support their execution (that is, make aspects of them machine interpretable, automate the clerical parts, etc.) and 2) to provide ways of abstracting from the actual plans to represent them and reason about them. There are strong theoretical problems and we need appropriate computational models. Tully stated that we need to do the same thing for methods. If we can do this support for both plans and methods, then we will have done something worthwhile. Configuration management (CM) was a thread that was woven throughout the various sessions. Here Feiler pointed out that CM is a control function on the software development process. We have methods defined and tools to support that we can learn from. CM can be considered 1) as support for managing software evolution and 2) as management/control and developer support (in particular, as management of evolving products, as management of the change process, and as evolution through cooperation and collaboration). Further, CM interacts with the build process, the t