On 22/5/06 15:31, "Peter G Lane"
6.3: I was liking the new state model until I saw this operation. I don't like this idea at all of allowing the user to monkey with the state machine directly. I would be much happier if there were specific operations to inject specific inputs that the state machine should consider. The state machine should never be open to direct manipulation, but instead should decided for itself what state and when to transition to that state based on the current state and events. At *very* least this operation should have a fault that means "too bad, I'm not doing that". If the desire is to allow for, say, reseting of the job back to New so that it will run again or canceling without destroying the job, then specific operations can be added to the spec as is. Since sub-states like "suspended" are treated as extensions now, a "SuspendActivities" operation would seem more appropriate as an extension as well.
I agree with this viewpoint. I think we should consider replacing the existing general state manipulation command with explicit commands for effecting state transitions within the base state model (so having a "CancelActivity" operation to move an Activity to the Cancelled state. Extensions (both to the state diagram and for extending the operation set to manage the new states) can be defined as Peter mentions. -- Chris