UML state machine

A UML state machine, formerly called a UML statechart, is a special way to describe how devices, computer programs, or other technical processes work. It helps organize things so that an entity—such as a part of a machine or a part of a computer program—is always in one specific state at a time. From that state, it can change to another state based on certain conditions.

This idea comes from a mathematical concept called a finite automaton, and it is used in a field called computer science. UML state machines build on older ideas called Harel statecharts, adding new features like hierarchically nested states and orthogonal regions. These additions help 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 perform actions based on both the current state and an event, like Mealy machines, and 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, while protocol state machines describe how different parts should interact with each other in allowed ways.

Basic state machine concepts

Many software systems wait for events like a mouse click or a button press. When an event happens, the system reacts and then waits for the next event. The way a system reacts depends on both the event and its current state, which can change because of the event. This pattern of events, states, and changes between states can be represented as a finite-state machine.

UML keeps the basic idea of traditional 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) are great for simple problems, but they can become messy for more complex systems. This happens because traditional FSMs repeat the same actions and transitions in many states, making them hard to manage.

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

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.

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

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.

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 developed to improve upon older methods called Harel statecharts. While statecharts are good for drawing pictures of complex systems, they have some problems. They often need a lot of extra text to fully explain what is happening, and this text depends on the specific programming language being used, such as C++ or Java.

Also, the way statecharts show the order of actions and events can be unclear. When these state machines are turned into actual computer code, designers have to decide the order themselves, which some people think makes the rules too strict. In addition, statechart diagrams use many special symbols to show the flow, which do not add much more information than simple code could provide. Overall, UML state machines aim to balance visual diagrams with clear textual descriptions to better represent how systems work.