Accommodating Manual Activities In Automated Process Programs
Stanley M. Sutton · 2005
Introduction Along with Dennis Heimbigner, I have been investigating tlhe programming of software processes in automatically-executable process-programming languages such a:; APPL/A [SH090] and P4 [Hei89]. Although we believe that process programs should be automatically executable insofar as possible, we also believe that software processes must necessarily include manual as well as automated activities. Consequently, we have had to confront several issues related to the modeling and control of manual activities in automated process programs. A particularly interesting aspect of manual activities is the potential for unanticipated actions. In considering how unanticipated actions may be accommodated, we have arrived at a broader view of software processes in which they are implemented by multiple process programs executed in concert. A brief overview of these issues is presented below. Modeling of Manual Activities In writing process programs to model sofitware processes, we typically represent and encapsulate manual activities within specific control constructs aiuch as subroutines or tasks. For example, a manual control decision may be encapsulated in a function, and manual subroutines may be encapsulated in procedures. Because manual activities are represented explicitly in the program, the intended relationship between a manual activity and other activities (manual or automated) can be derived by analysis. Additionally, the implementation of the procedure or task can facilitate communication and coordination between the automated process and the person responsible for the manual activity. Thus, when the automated program is executed, it can facilitate and direct the intended manual activities in various ways. This approach was used in the APPL/A program for the ISPWG problem. Ada tasks were used to represent the manual activities, and interactions between the automated program and developers included the sending of schedules to engineers, the sending of notifications for task initiation and termination, and the exchange of software products and associated data. Decomposition of Manual Activities If a manual activity is represented by control constructs in process programs, the issue arises as to how far that activity should be decomposed. This is an issue of program design. A complex manual activity may be represented by a single procedure (e.g., “revise module”). In this case the program contains no information about the internals of the task and will be able to provide little support for it. Alternatively, the top-level procedure for a manual activity may be decomposed into subroutines (e.g., “check out module; repeatedly edit and review module until aaceptable; check in module”). In this case the program serves to model the manual activity in more detail and may provide correspondingly elaborate support. Aspects of Process Control With respect to the execution of a software process that combines both manual and automated activities, questions naturally arise as to which components should control process execution. With respect to an automatically-executable process program, we presume that certain basic mechanisms are available. A person may invoke the program and send it signals that otherwise affect its execution (e.g., “kill” or “suspend”). The program itself proceeds under the automatic control of its interpreter, in accordance with control decisions that have been pre-programmed. This is a necessary but mechanistic view of process control that is not completely satisfying or useful for designing and analyzing software processes. It does not help to explicate whether abstract control decisions in the process are made