jollyblume / statemachine

jollyblume/workflow

branch philosophy: A workflow and a state machine are the same thing, differing only in implementation. symfony/workflow also takes this approach, but I need a different concept of state machine.

components: Workflow class (implements symfony/workflow::WorkflowInterface)

• There is no StateMachine class. A workflow operates as a workflow or a state machine based on configuration.

Device classes (input and output). The device concept will only be relevant in early development.

State chart class.

Mediator service.

• collection of state machines, dispatcher
• this is not intended to be a registry. it is just glue.
• collection of inputs and outputs. these will be used to virtualize concrete state machines for individual inputs.
• events and inputs are pointed at input devices. the input device for a virtual state machine will restore all state to a state machine before executing next state combinational logic. or any other logic.
• input devices are used by the mediator to interact with a concrete state machine.
• application code uses input devices as it they were the actual state machine.

In this component

• a workflow is the same as symfony/workflow::Workflow.
• a state machine starts the same and can only be in a single state.
• a state machine only performs next state combinational login in response to an input signal.
• a state machine has output. Normally, output is only dependent on state. for a mealy machine, the inputs and the current state define the output.
• state machines will use a state machine to convert configuration into a working state machine. eventually.
• must successfully run symfony/workflow test suites.
• must use symfony/workflow::Definition
• Will use jollyblume/marking-store
• will use jollyblume/composed-collection

symfony/workflow::WorkflowInterface handling (early dev) There are a lot of different concerns addressed by this interface and is focused on workflow behavior. State machines in this component have different behavior and will require implementation driven definition of the meaning for this interface. It is important to integrate this interface into the component, since it is a core symfony/workflow interface. Parameter DSL

$subject

• while a workflow has a subject or token progressing from place(s) to place(s), a state machine has a state that is not related to a subject or token. state machine state is a black box that is in a given state based on its current state in input signals.
• in fsm, this is a memory device? or similar
• $subject is either a current fsm internal state or input signals to processs next state.
• $subject is always an array of input signals. note memory needs to internally persist entire current persist at next state combinational logic.

$transitionName

Method DSL

getMarking($subject)

can($subject, $transition)

buildTransitionBlockerList($subject, string $transitionName): TransitionBlockerList

apply($subject, $transitionName)

getEnabledTransitions($subject)

getName()

getDefinition()

getMarkingStore()

getMetadataStore(): MetadataStoreInterface