ISPW7 PROCESS EXAMPLE IN GRAPPLE (PROCESS CHANGE) Karen E. Huff GTE Laboratories khuff@gte.com The following material addresses the new extension on Change (#4.2) is handled in the GRAPPLE system. First we present a partial definition of the process of the design engineer, as per the ISPW6 example. This definition is just sufficient to support the change examples. Then, we show how both changes (4.2.1 Process Modification and 4.2.2 Process Exception) are handled with respect to this definition. For those not familiar with the GRAPPLE system, a short introduction to plan-based process definitions is appended at the end of the solution. ---------------------------------------- Design Engineer's Process ---------------------------------------- Both cases of change affect the process of the design engineer who is assigned to a module change task. This process consists of three parts: modify design, review design, and modify code. (A fourth part, testing, which may alternatively be performed by the QA engineer, is not addressed here, as the changes do not affect it.) The three parts are gathered together in one operator shown below. Operator design-and-implement-module-change (R,M,D1,D2,SC1,SC2,O) /*where R is a requirements change M is the module affected by R D1 is the current design for M D2 is the design created for R from D1 SC1 is the source code that implements D1 SC2 is the source code to implement D2 O is the object code for SC2 */ Goal designed-and-implemented(R) Precond * static: assigned-to(THISAGENT, R) Constraints affects(R,M) current-design(M,D1) implements(SC1,D1) Subgoals * design-modified( R,M,D1,D2) * design-approved(D2) * code-modified(SC1,D2,SC2,O) Effects designed-and-implemented(R) In a full definition, there would be at least one operator for each of the subgoals of the operator above. We show one for the "modify code" subgoal and one for the "design review" subgoal: Operator modify-code(D,SC1,SC2,O) /*where D is a design SC1 is the source code to be modified SC2 is the source code to meet D O is the object code for SC*/ Goal code-modified(SC1,D,SC2,O) Precond /*none - coding can begin before the review*/ Constraints Subgoals * source-modified(SC1,D,SC2) * object-code-for-source(SC2,O) * released-for-testing(SC2) Effects code-modified(SC1,D,SC2,O) Note that the requirement that coding is not complete until the design is approved would be reflected in a precondition to an operator that achieves the goal "released-for-testing". Operator design-review(D) /* where D is the design to be reviewed */ Goal design-approved(D) Precond * circulated-to-reviewers(D) * static: review-personnel-available(D) Constraints Subgoals * design-reviewed(D) Effects /* effects = whatever is achieved by the design review subgoal*/ The expected outcome of the design review is that the design is approved. However if the review "fails", then the goal of getting the design approved is not achieved. When an operator that is expected to achieve a particular goal has been executed, and the goal is still not achieved, recovery strategies must be applied. In GRAPPLE, these are defined as metaoperators that modify instances of operators in plans. In the case of a design that fails its review, the recovery strategy defined in the example problem calls for the design to be reworked and a review to be held on the new design. This amounts to modifying the plan involving "design-and-implement-module-change" by replacing the original approval subgoal with two additional subgoals to do a (new) design and to review that design. The metaoperator for this is paraphrased below: Metaoperator add-redesign-and-rereview /*Note: metaoperators modify instances of operators in plans*/ Goal no failed subgoal that is required Precond there is an instance of design-and-implement- module-change, in which the approval subgoal has failed Constraints Subgoals Effects add new subgoal: design-modified( R,M,D2,D3) add new constraint: not-equal(D2,D3) add new subgoal: design-approved(D3) replace the occurrence of D2 in the code-modified subgoal with D3 mark the failed approval subgoal as "not-required" (i.,e, it is no longer required to be achieved for the operator to complete, but it is left as a subgoal to show why the original review occurred.) ------------------------------------------ Process Modification (4.2.1) ------------------------------------------ This process modification involves instituting the requirement that the design be approved before coding begins, not simply before the coded module is released for testing. This change is made by removing (from the operator library) the original definition of the operator "modify-code" and adding a new definition of the same operator as follows: Operator modify-code(D,SC1,SC2,O) /*where D is a design SC1 is the source code to be modified SC2 is the source code to meet D O is the object code for SC */ Goal code-modified(SC1,D,SC2,O) Precond approved(D) /* this is the only change */ Constraints Subgoals * source-modified(SC1,D,SC2) * object-code-for-source(SC2,O) * released-for-testing(SC2) Effects code-modified(SC1,D,SC2,O) The effect of changing the definition of "modify-code" is discussed below. We enumerate each possible case that could hold after the operator library is modified. (The cases below are not intended to line up with the three cases given in the ISPW7 example problem description.) Note that in case 4, the process designer has the option of pursuing a variety of strategies-- no particular strategy is forced upon him/her. --->(1) Process Steps Already Executed: For instances of processes in which "design-and-implement-module-change" has started and the subgoal "code-modified" has already been achieved, the execution of the process will have been in keeping with the old (unmodified) process definition. That is, the process modification does not apply to already-executed steps. In these cases, no rollback would help anyway -- the design reviews took place, only at a later date than is now deemed advisable. --->(2) Process instances that have not yet been planned: Any instance of "design-and-implement-module-change" that is instantiated after the operator library is modified will be in accordance with the modified process (i.e., approval will be required before coding begins.) --->(3) Process steps that have not yet been planned: For instances of processes in which "design-and-implement-module-change" has been instantiated (whether it has started or not) but no planning has been done to determine how to achieve the subgoal "code-modified", the new definition of "modify-code" will be used automatically. Therefore, in these cases all future process steps will be consistent with the modified process. --->(4) Process steps that have already been planned: For instances of processes in which "modify-code" has already been instantiated (according to the old definition) to achieve the subgoal "code-modified", the execution of the process will be in keeping with the old (unmodified) process definition. In this case, it is possible that some process steps executed after the process modification still follow the old definition. This is what GRAPPLE would currently do, but other possibilities are outlined below. Further Discussion It is possible to modify the planning algorithm to do something different for case 4 -- steps already planned. Suppose operator O1 is deleted from the operator library, and replaced by O2. A new part of the algorithm could look for each instance of O1 and delete those that have not yet started to execute. Then the normal planning algorithm can be called to determine how to satisfy the goal G that O1 was originally instantiated to satisfy, as well as to determine whether any other parts of the plan in which G appears are affected. During this process, O2 would be found in the operator library as a way of satisfying G, so O2 would get instantiated. Note that this proposal only affects instances of O1 that have not yet started to execute. These cases are always safe to treat in this way. If the process designer wants to make changes to an instance of the old definition of "modify-code" in the case where it already started, then this should be done by defining one or more metaoperators to be added to the library at the same time as the definition of "modify-code" is changed. Each metaoperator should describe all the necessary details of transitioning from the old process to the new according to the amount of the old process that had been completed. %As an example, suppose it is the process designer's intention that coding already in progress be halted until the design is approved, after which coding can complete. In this case, two metaoperators are needed, one to add in the review subgoal and halt all other activity, and one to enable continuation after the design is approved. Metaoperator add-review-midstream Goal new subgoal in instance of "modify-code" Precond there is an instance of "modify-code" with no precondition and in which the subgoal "source- modified" has started but not finished Constraints Subgoals Effects add new subgoal: approved(D) mark all other subgoals "suspended" Metaoperator continue-after-midstream-review Goal no suspended subgoals in operator instance Precond there is an instance of "modify-code" in which the approval subgoal has completed satisfactorily, and in which all other subgoals are suspended. Constraints Subgoals Effects mark all suspended subgoals "active" -------------------------------------- Process Exception (4.2.2) -------------------------------------- This process exception involves skipping a rereview due to unavailability of personnel. The change is not intended to remove reviewing from the process, but rather to allow its omission under certain circumstances. This change naturally lends itself to a metaoperator implementation in GRAPPLE since metaoperators make changes to process instances. The metaoperator would be as follows. (Remember that rereviewing is something that is itself added via a metaoperator.) Metaoperator skip-rereview-when-personnel-not-available Goal operator instance no longer blocked Precond there is an instance of "design-and-implement- module-change" with a failed approval subgoal that is not required and an approval subgoal that has started, but the precondition"review-personnel- available" (in the operator achieving the approval subgoal) is not satisfied. Constraints Subgoals Effects mark the incomplete approval subgoal as "not-required" in the process state (not the metalevel plan state), mark the design "approved" And, that's all there is to it! If the process designer wants to make additional restrictions on when rereviewing can be skipped, such as restricting the omission of a review to certain design engineers only, then these conditions could be added as additional preconditions on the metaoperator. ------------------------------- Introduction to GRAPPLE ------------------------------- GRAPPLE is based on the AI "planning" paradigm. Thus, a "process definition" consists of a state schema and a set of operators (the operator library). Two additional aspects are optional; they are a set of metalevel operators and a set of default rules (not used here). Processes are not defined by prespecifying sequences of actions, as in event-based formalisms (petri nets, state machines, procedural approaches). Rather, a plan is dynamically created by selecting and ordering instances of operators so that the execution of these operators will achieve a specific process goal in a specific process context (state of the world). This business of creating a plan is accomplished by a domain-independent (therefore, process-independent) algorithm called "planning." The "state schema" is a collection of predicates. For the example above, these predicates include: design-modified(, , , ), approved(), code-modified(, , , ), and so forth. The "operators" in a GRAPPLE process definition each specify the goal, preconditions, subgoals, constraints, and effects for that operator. The first four of these clauses consist of propositions (predicates with parameters) formed into expressions, using standard logical connectives but no quantifiers. The logic underlying these expressions is that of Prolog, and so existential quantification is implicit and negation-as-failure is used to achieve universal quantification. Operator parameters are listed in parentheses following the operator name; each parameter starts with a capital letter. Each operator is a separate namescope. Comments appear in italics or between /* */ pairs. The "goal" consists of a single expression stating what is intended to be true when this operator executes successfully. An operator can have any number of "preconditions", including no preconditions. Preconditions are of two types. Static preconditions are restrictions on the applicability of the operator*if not true, it is not intended that actions be taken to make them true. Normal preconditions are simply distinguished subgoals that must be achieved before any of the subgoals are achieved. If the keyword "preconditions-missing" is attached to an operator, then certain applicability conditions (i.e., static preconditions) for this operator have not been made explicit. This means that a human decision is needed to select this operator in lieu of alternative operators that achieve the same goal; the planner has not been given enough information to make such a decision on its own. An operator can have any number of "subgoals", including no subgoals; an operator with no subgoals is a primitive operator corresponding to an action that can be taken in the process environment. A subgoal can be iterated, and there are two types of iteration. One type, denoted by the keyword "iterated-until" corresponds to a while loop, and the other, denoted "iterated(x)", means that the subgoal expression is to be achieved at least x times. "Iterated(0)" means zero or more times. When subgoals are iterated, some parameters to the operator may need to be treated as arrays, not scalars. These are denoted with an asterisk following the parameter name in each expression where the parameter appears. "Constraints" are restrictions on parameter bindings. An operator can have as many constraint expressions as are needed. The built-in constraint "under-constrained" is used to denote a parameter for which there are missing constraints. That is, only the person executing the process can make the final decision on binding that parameter*the planning system does not have enough information to make a decision on its own; of course, any value chosen by the person must adhere to all constraints that are actually specified in the operator. The "effects" clause lists the state changes that occur when the operator executes normally. (The state changes that occur when the operator fails are not predefined. Whatever actually occurs during operator execution, whether expected or not, is recorded in the state schema, and this may cause replanning if the operator failed to achieve its purpose in the plan.) There are five types of state changes: creating a new entity (new), removing an existing entity (remove), adding a proposition (add), deleting a proposition (delete), and a simultaneous add/delete (set). The state of the world is modelled as a collection of propositions under the closed world assumption: a proposition in the current collection is true, and a proposition not in the current collection is false. This model is what motivates the terminology of add and delete. When a new entity is created via a new effect, the proposition "exists(, )" is automatically made true; it remains true until that entity is removed. Note that when an operator in instantiated in a plan, its parameters start to acquire bindings to real software development objects, and the operator itself acquires some state information (such as active, suspended, blocked, ...) For additional information on GRAPPLE see: Huff, K.E. Plan-based Intelligent Assistance: An Approach to Supporting the Software Development Process. Ph.D. dissertation, University of Massachusetts at Amherst, September 1989. Huff, K.E. and Lesser, V.R. "A Plan-based Intelligent Assistant that Supports the Software Development Process". Proceedings ACM Symposium on Practical Software Development Environments, 1988, 97-106. _______________________________________________________ Dr. Karen E. Huff Email: khuff@gte.com GTE Laboratories Voice: (617) 466-4235 40 Sylvan Road Fax: (617) 290-0628 Waltham, MA 02254