grapple example: processes as plans  as an example of a small part of the software process, consider the activities preliminary to building a new version of a software system; one task involves setting up an appropriate environment in which to apply the compilation and linking tools. this task can be done in several different ways. a common approach under unix entails collecting all the compilation units representing the baseline from which the new system version is to be developed into a "reference directory" and collecting all new compilation units unique to the new system version into a "working directory". when two (or more) new system versions are being developed from the same baseline, they can share one reference directory, but each system version always needs its own working directory. obviously, one directory cannot serve as both a reference and a working directory.  in this approach, setting up an environment consists of a hierarchy of goals shown informally in the figure below. setting up the reference directory and setting up the working directory break down into further subgoals: the programmer has to commit an appropriate directory, empty it of extraneous files, and fill it with the relevant files. these goals are accomplished with operating system commands to make directories (mkdir), copy files (copy), move files (move), and delete files (delete).  the state schema for this example includes four types of entities: directories, files, contents of files, and systems. predicates are defined to record that files are in directories, contents are stored in files, contents are of different kinds source, include, executable, etc), contents can be part of systems, contents can represent the executable forms of systems, etc. directories can be used by systems as reference or working directories.  the examples shows four characteristics that we believe are typical for processes. first, there is an obvious hierarchical structure. second, there are many different action sequences that can be used to achieve a given goal. in some cases, there are several operators to choose from. for example, removing extraneous files can be achieved by delete or move, or combination thereof. in other cases, the actions chosen on the context---whether there are existing, uncommmited directories, or what the current placement of files in those directories is. third, there is a high degree of interleaving of tasks. for example, actions to setup the reference directory can be intermixed with actions to setup the working directory, or actions from two separate setup- environment plans can be intermixed. fourth, conflicts can arise that will destroy the effectiveness of the plans. if the reference directory is already setup, and the programmer is now setting up the working directories, then there are better ways of emptying the working directory of extraneous files than moving them into reference directory: this will destroy the "readiness" of the reference directory, meaning that more work will have to be done to reestablish "readiness". such a conflict leads, at best to an inefficient plan; if not detected, it leads to an improper plan (when the file is never subsequently moved out of the reference directory). the definitions given below are taken from an example that runs in the grapple plan-based process support system.  karen e. huff