Process Panel Issues

PP Issue 1

If an action can be expanded in more than one way,
  1. What do viewers show before we know which expansion has been chosen?
  2. What do we do if the action is expanded in different ways in different COAs?
  3. What do we do if the action is expanded in different ways on different iterations of a loop?

PP Issue 2

How do we handle a change in the process model while monitoring is in progress?

One plausible approach: The process model / workflow stepper could just install the new model and replay the events it's already received. They will presumably still have happened, because we're not supposing the past can have altered.

Objection: What if the new version has a different structure in the "past", for the next time it's used, or for the next time around a loop?

Reply: Then I guess we'll need a stack of versions.

PP Issue 3

Are parent nodes "transparent"?

Suppose we have a node N with children N.1, N.2, ... and (just as an example) that the N.1 has to execute before its siblings.

There seem to be two different kinds of parent nodes. For one kind, N would be an action in its own right, and when there's complete monitoring (ie, everything that actually happens is known to the monitor), startAction(N) and startAction(N.1) are separate events. (You'd get separate Kqml messages for them, or whatever.)

But "transparent parents" are just groupings of nodes. In this case, startAction(N) and startAction(N.1) are (conceptually) the same event, and we would probably say that startAction(N) isn't something that really happens at all.

More generally, if a node N that has children starts executing, do all initial children (ie children that will execute first) start executing, or do they merely become ready. For transparent nodes, they should start executing; for opaque nodes, they should merely become ready.

The issue also comes up when we try to count the number of nodes that have executed.

In the ACP3 model, it looks like "execute plan-cycle" is pretty transparent (at least translucent), but "create COA" is not.

This creates a great deal of confusion when trying to understand the model, especially when nested loops involve both translucent and opaque nodes, and it makes me wonder whether IDEF models are really well-defined when it comes to saying what events can occur.

The ACP3 Java code treats all nodes as opaque, which doesn't seem to cause any serious problems.

Software Issues

Software Issue 1

We need a good software graph-drawer, written in Java. It should allow manual move-around to tidy up.