-
Notifications
You must be signed in to change notification settings - Fork 34
State and Transition Properties
State and transition properties serve as a means of characterizing specific properties of automata and transition systems in a generic fashion.
Consider the simple use case as copying an automaton. Clearly, copying of a DFA should preserve whether or not states are accepting, copying of a Mealy machine should maintain the outputs associated with each transition and so on. For the DFA case, simply providing methods isAccepting() and setAccepting(boolean) will inevitably require the copying algorithm to handle DFAs in some specialized way.
State and transition properties provide a suitable abstraction for this kind of information. Their idea is to aggregate all information characterizing a state or transition in a single Java object. The purpose of this Java object is to make the characterizing information accessible in a generic fashion. It does not need to be in any way associated with the state, and it can even be created on-the-fly upon retrieving the respective property.
The basic concepts of state and transition properties (on a level of arbitrary transition systems) are defined in the interface UniversalTransitionSystem (source, javadoc). Implementing classes or interfaces are encouraged to provide more descriptive methods (such as isAccepting() for DFAs) which are to be used in non-generic settings, and realize getStateProperty() wrapping the raw data characterizing the state for the purpose of genericity only. Similarly, setXXXProperty() should be implemented extracting the information from the property object and then delegating to the more descriptive, model specific setters.
An example for this can be found in AcceptorTS' default implementation of getStateProperty() for acceptors: the returned state property is the Java object of type Boolean created from the primitive boolean return value of isAccepting().
Please note that in AutomataLib, the fact whether or not a state is initial is not considered a state property. The reason for this is that state properties should be entirely local, (fully) characterizing solely the respective state. Whether or not a state is initial however concerns the overall structure of the automaton. This is also reflected in the usual way an automaton would be implemented: by the automaton object maintaining a reference to the initial state, instead of keeping this information with the state.
| Machine model | Java type | State property (type) | Transition property (type) |
|---|---|---|---|
| DFA | DFA<S,I> (source) | acceptance (Boolean) | none (Void) |
| NFA | NFA<S,I> (source) | acceptance (Boolean) | none (Void) |
| Mealy machine | Mealy Machine<S,I,T,O> (source) | none (Void) | output symbol (O) |
| Moore machine | MooreMachine<S,I,T,O> (source) | state output (O) | none (Void) |