Home - sjdayday/xschema GitHub Wiki
Executable Schemas
The xschema project will implement simulation semantics as executable schemas (x-schemas) over the basic Petri net functions provided by PIPECore. Executable schemas model process control as "parameterized routines with internal state that execute when invoked" (Narayanan, 1997); (see also Naraynan, 2010 and Barrett, 2010).
Simulation Semantics
We propose to start with the general control schema from Narayanan (2010): images/general-controller.png
The basic control flow passes through these states:
- enabled: the x-schema is activated; evaluation of its necessary preconditions can begin
- ready: the preconditions have been met; execution of the main process can begin
- ongoing: execution of the main process is in progress, and is pending completion
- done: execution is complete; the x-schema exits
In the general control flow, the transitions between states are also named:
- prepare: evaluate the preconditions of the x-schema
- start: begin execution of the main process
- finish: complete execution of the main process
The name of a transition is a verb, and a state can generally be thought of as the past-tense of the verb of the previous transition: enable/enabled, prepare/prepared (ready), start/started (ongoing), finish/finished (done). For domain-specific x-schemas, states and transitions may not always be named, but for the general control flow the names capture the key semantics. The functions provided by the xschema project are an implementation of the ideas expressed by these names.
We propose that these core steps are present in every x-schema: images/basic-control.png
Optional standard semantics
Depending on the details of the process being modeled, additional standard transitions and states may optionally be added to capture relevant conditions:
- enable / disable: transitions to handle cases where initial activation may not be automatic
- cancel / canceled: transition / state to handle cases where the requester desires to stop execution of the main process before it starts
- suspend / suspended: transition / state to handle cases where some event(s) interrupt the ongoing execution of the main process.
- suspended / resume: state / transition to handle the resumption of a main process that was previously interrupted; capturing the notion of "beginning where we left off".
- suspended / restart: state / transition to handle the restart from the ready state of a main process that was previously interrupted; capturing the notion of "starting over from the beginning".
- iterate : transition to handle the repeated execution of the main process multiple times.
- [suspended] / stop / stopped: transition / state to handle cases where the requester desires to stop execution of the main process before it completes, either directly, or following a previous interruption.
- undo / undone: transition / state to handle cases where the requester desires that the effects of a previously completed x-schema be reversed.