UML state machine

A UML state machine, also known as a UML statechart, is a special way to describe how things like machines, computer programs, or processes work. It helps organize things so that an object—like a part of a machine or a program—is always in one specific state at a time. From that state, it can change to another state when certain conditions are met.

This idea comes from a mathematical concept called a finite automaton. It is used in computer science. UML state machines build on older ideas called Harel statecharts. They add new features like nested states and orthogonal regions. These additions make the models more powerful and flexible.

UML state machines have features from two types of machines called Mealy machines and Moore machines. They can do actions based on the current state and an event, like Mealy machines. They can also have actions that happen when entering or leaving a state, like Moore machines.

There are two main kinds of UML state machines: behavioral state machines and protocol state machines. Behavioral state machines model how individual parts of a system behave. Protocol state machines describe how different parts should interact with each other in allowed ways.

Basic state machine concepts

Figure 1: UML state diagram representing the computer keyboard state machine

Many software systems wait for things like a mouse click or a button press. When something happens, the system reacts and then waits for the next thing. How the system reacts depends on what happened and its current state, which can change.

UML keeps the basic idea of state diagrams but adds more features. In UML, states are shown as rounded rectangles with names, and changes between states are shown as arrows labeled with events. Each diagram starts with an initial state, shown by a solid circle, which is the default state when the system begins. UML state machines can include extra details, like conditions that must be met for a change to happen, making them useful for more complex systems.

UML extensions to the traditional FSM formalism

Traditional finite state machines (FSMs) work well for simple problems, but they can become confusing for more complex systems. This is because traditional FSMs often repeat the same actions and transitions in many states, making them hard to manage.

UML state machines solve this problem by offering features that reduce repetition. These features make state machines easier to use for real-world applications.

Figure 4: Two orthogonal regions (main keypad and numeric keypad) of a computer keyboard

Hierarchically nested states

A key idea in UML state machines is hierarchically nested states. This means states can have other states inside them. If a system is in a nested state, like "result," it is also in the surrounding state, like "on." If an event happens that the nested state can't handle, the system checks the surrounding state for a way to handle it.

States that contain other states are called composite states, while states without internal parts are simple states. This nesting helps avoid repeating actions, making it easier to manage complex systems.

Figure 5: Toaster oven state machine with entry and exit actions

Orthogonal regions

UML state machines also allow orthogonal regions. These are independent parts of a state that can act at the same time. For example, a keyboard can have a main keypad and a numeric keypad, each with its own states. Orthogonal regions let these parts work independently without creating too many combined states.

Entry and exit actions

Figure 6: UML state diagram of the keyboard state machine with internal transitions

Every state can have entry actions and exit actions. These are actions that run when entering or leaving a state. For example, when a door opens in an oven, entry actions can turn on a light, and exit actions can turn it off. This ensures important actions happen every time, without needing to repeat them in many places.

Internal transitions

Sometimes an event causes actions but doesn't change the state. These are internal transitions. For example, pressing keys on a keyboard changes what is typed but doesn't change the keyboard's state unless Caps Lock is pressed. Internal transitions let actions run without switching states.

Figure 7: State roles in a state transition

Transition execution sequence

When a state changes, UML has a specific order for what happens. First, it checks if the change can happen. Then it exits the old state, runs any actions for the change, and finally enters the new state. This order helps keep everything organized, especially when states are nested inside each other.

Local versus external transitions

UML has two types of state changes: external transitions and local transitions. External transitions fully exit the old state and enter the new one. Local transitions are used when the new state is inside the old state, so they don't fully exit and reenter the old state.

Event deferral

Sometimes an event happens when the system can't handle it. UML state machines can defer these events, saving them for later when the system is in a state that can handle them. This helps manage events that come at the wrong time.

The limitations of UML state machines

UML state machines were created to fix problems with older methods called Harel statecharts. Statecharts are good for drawing complex systems, but they have some issues. They often need a lot of extra text to explain everything, and this text depends on the programming language being used, like C++ or Java.

Also, statecharts can make it hard to see the order of actions and events. When these state machines are turned into computer code, designers must decide the order, which some think is too strict. Statechart diagrams use many special symbols to show flow, but these do not add much more information than simple code. UML state machines try to balance visual diagrams with clear text to better show how systems work.