A State is the key structural element used within the State Machine formalism to partition the software model for a script. It represents a static point in the script's logic (which is determined by it's previous history), at which point a new Event may be processed and transition the script to a new state.
A State is represented by the following graphic.
A State can also optionally display (State Options) the following additional information:
Entry Action and Exit Action, where x==1 is the Entry Action and x=2; is the Exit Action. By default, the configuration item, Cap Notation within the States panel of the Options menu is enabled and so each line of information is capped. However when disabled, as much text as the state's width allows will be displayed for each line of property information.
Internal events associated with contained transitions, where touch_end is the event, x==2 is the Guard Condition and x=3; is the Transition Action;
Extended State Variables and Functions, where x is a State Variable of type integer and initialized to 22; and f is a State Function which has parameters and returns a float. If there are State Variables/Functions defined then the icon will be displayed.
►Note that the length of information shown is capped to minimize the clutter of model diagrams. As well if there is insufficient space to show all the required information an ellipsis will be displayed at the bottom of the state.
A State's name by default is set to a new name which is unique among the other substates within the decomposition of a Composite State (including the top-level state). This setting can be changed within the Options menu such that User will always be prompted to choose the name first when creating a new State. However the user can manually at any time change the name of a State as long as it remains unique among the other substates at that same level.
Generally speaking, a particular state of a system is represented by the set consisting of the current values of all it's defining attributes, together with the set of outside events that the system will respond to at a particular point in time. States as visually represented in a MiceOnABeam model, can be used to replace the most significant of these attributes (i.e., variables), making the design intent clearer.
A State in MiceOnABeam represents a static or quiescent point in the script's program logic, at which point a new event may be processed and transition the script to a new State. By having multiple states, a particular event can be handled in different ways, depending on which State the system is in when the event is received.
Each State may optionally specify:
Entry Action: An Entry Action is a sequence of LSL statements that is executed whenever the State is newly entered, (i.e., becomes an active State).
Exit Action: An Exit Action is a sequence of LSL statements that is executed whenever the Stateis exited, (i.e., becomes an inactive State, and the Last State at it's level in the state hierarchy).
- State Variables & Functions: These are variables and functions declared within the scope of a state such that they are only accessible from within that State, and within all it's contained substates, and so on down to the leaf states of the nested state hierarchy. By reducing the need for globals State Variables & Functions can help to modularize the design and abstract out lower-level implementation details.
There are two major types of states:
Simple State: Also known as a Leaf State, the Simple State has no internal decomposition.
- Composite State: A Composite State is a State which has an internal structure consisting of a set of one or more states, transitions and other components. A Composite State can serve as a high-level abstraction within the hierarchy of states, with only the appropriate design details shown at every level of the model.
The following example is of a simple robot which carries out commands which are chatted to it. The Robot state has both an Entry and Exit Action, which are executed upon entering and leaving the state respectively. It also has a listen Self Transition, which carries out the command received.
Inside the Robot Composite State there are Asleep and Awake substates. A touch_start event moves the script into the Awake state, whose Entry Action sets up a filter for a listen event. When one occurs, the Group Transition listen will first leave the Awake and Robot states, executing their Exit Actions in turn, and perform the command. The script will then re-enter Robot, executing it's Entry Action followed by a return to history, which will then execute Awake's Entry Action thereby setting up the listen filter again.
- All states by default have an internal structure consisting of an Initial Point which can be seen by opening up a State Editor on the state. However, an Initial Point alone does not make the state a Composite State.