States
States represent stable configurations of the system.
This can be inactivity like Waiting, ongoing activity like Calculating, a description
like Solid or Liquid, or some other configuration unique to your system.
Because states are stable, unlike pseudostates, simulation time can pass while a state is active.
Entry, exit, and do behaviors
States can have Entry, Exit, and Do Activity behaviors, which describe what happens immediately after entering the state, immediately before exiting the state, and while the state is active. A state can have any combination of these behaviors, including all or none of them. SysML allows these behaviors to be any valid Behavior type (UML 2.5.1 section 14.2.2), but Moxie restricts Entry and Exit to only be opaque behaviors, and Do Activity to only be a state machine. While do behaviors are often used for activity diagrams, Moxie does not support activity diagrams.
Example
Figure 1 shows a state machine with entry, exit, and do behaviors, and with insets for the do behaviors' state machines.
The Running Task A state first executes its entry behavior, then its do behavior.
It waits for its do behavior, the executeTaskA state machine, to complete before executing its exit behavior and
transitioning out.
The Running Task B state waits for both its do behavior and its
nested region before transitioning out.
Lastly, the Running Task C state's do behavior never completes because it never reaches a
final state, but eventually the transition out triggers, interrupting the
do behavior, executing the exit behavior, and then transitioning out.
Figure 1: States with entry, exit, and do behaviors
State hierarchy
In general, states are mutually exclusive — if one state is active, all of its peers must be inactive — but SysML state machines allow for hierarchical relationships between states. States that are nested inside of each other or are orthogonal to each other can be active at the same time.
Nesting
States that are nested within each other enable you to describe the inner working of complex states explicitly. The parent state must be active for any of its child states to be active, and the states at each level of nesting are still mutually exclusive, unless they are in orthogonal regions.
Figure 2: Nested states
Orthogonal regions
States with orthogonal regions, called composite states, are often used to model simultaneous independent functions of a single system. Within each region, states at the same level of nesting are still mutually exclusive, but states in one region are not mutually exclusive with those in another region.
Figure 3: A composite state with two orthogonal regions
Example
Figure 4 shows the balloon operator state machine of the hot air balloon ride example included with Moxie. This state machine contains many nested states in three orthogonal regions:
- In the top region, the operator manages the business: checking calendars and transitioning from one customer to the next.
- In the middle region, the operator interacts with the balloon itself: activating or deactivating the burner to reach a target altitude and remain there.
- In the bottom region, the operator interacts with the current passenger: informing the passenger when it is safe to take a photo.
For simplicity, this is all modeled as one operator, but there could instead be an attendant on the ground handling the management side of things while a separate operator is handling the balloon itself.
This example shows how nested child states can be interrupted by their parent state exiting.
Even if the passenger is in the middle of taking a photo, if the operator is instructed in the top orthogonal region to land, then in the
bottom region, the land() call event interrupts the
Photo Opportunity state and transitions from its parent state to
Idle.
The same land() call event also interrupts the operator's control of the burner in the middle region.
This situation shows how simultaneous regions (whether orthogonal or nested) can interact with each other
using call events and signal events, just like how simultaneous state machines interact with each other.
Figure 4: A state machine with orthogonal regions and nested states
Pseudostates and final states
Pseudostates are not actually states; they do not represent stable configurations that can stay active. Like states, they can serve as the source or target of a transition, but once entered, they are immediately exited before the state machine does anything else (UML 2.5.1 section 14.2.3.9.1). This can create a compound transition between actual states.
Another exception to normal states is the final state. As its name implies, a final state is technically an actual state because it is a stable configuration, but it does not otherwise act like one. It cannot perform any entry, exit, or do behaviors, cannot have anything nested inside of it, and cannot be transitioned out of. It simply indicates that the region it is in has completely finished and will not do anything else.