{"id":6087,"date":"2022-05-26T02:11:39","date_gmt":"2022-05-26T02:11:39","guid":{"rendered":"https:\/\/www.booksofall.com\/ru\/?post_type=product&p=6087"},"modified":"2022-06-15T05:13:17","modified_gmt":"2022-06-15T05:13:17","slug":"specification-of-software-uml-state-machines","status":"publish","type":"product","link":"https:\/\/www.booksofall.com\/ru\/specification-of-software-uml-state-machines\/","title":{"rendered":"Specification of Software: UML State Machines"},"content":{"rendered":"

UML state machine<\/b>, also known as\u00a0UML statechart<\/b>, is an extension of the\u00a0mathematical<\/a>\u00a0concept of a\u00a0finite automaton<\/a>\u00a0in\u00a0computer science<\/a>\u00a0applications as expressed in the\u00a0Unified Modeling Language<\/a>\u00a0(UML) notation.<\/p>\n

The concepts behind it are about organizing the way a device, computer program, or other (often technical) process works such that an entity or each of its sub-entities is always in exactly one of a number of possible states and where there are well-defined conditional transitions between these states.<\/p>\n

UML state machine is an object-based variant of\u00a0Harel statechart<\/a>, adapted and extended by UML. The goal of UML state machines is to overcome the main limitations of traditional\u00a0finite-state machines<\/a>\u00a0while retaining their main benefits. UML statecharts introduce the new concepts of\u00a0hierarchically nested states<\/a>\u00a0and\u00a0orthogonal regions<\/a>, while extending the notion of\u00a0actions<\/a>. UML state machines have the characteristics of both\u00a0Mealy machines<\/a>\u00a0and\u00a0Moore machines<\/a>. They support\u00a0actions<\/a>\u00a0that depend on both the state of the system and the triggering\u00a0event<\/a>, as in Mealy machines, as well as\u00a0entry and exit actions<\/a>, which are associated with states rather than transitions, as in Moore machines.<\/sup><\/p>\n

The term “UML state machine” can refer to two kinds of state machines:\u00a0behavioral state machines<\/i>\u00a0and\u00a0protocol state machines<\/i>. Behavioral state machines can be used to model the behavior of individual entities (e.g., class instances), a subsystem, a package, or even an entire system. Protocol state machines are used to express usage protocols and can be used to specify the legal usage scenarios of classifiers, interfaces, and ports.<\/p>\n

Basic state machine concepts<\/span><\/h2>\n

Many software systems are\u00a0event-driven<\/a>, which means that they continuously wait for the occurrence of some external or internal\u00a0event<\/a><\/b>\u00a0such as a mouse click, a button press, a time tick, or an arrival of a data packet. After recognizing the event, such systems react by performing the appropriate computation that may include manipulating the hardware or generating \u201csoft\u201d events that trigger other internal software components. (That’s why event-driven systems are alternatively called\u00a0reactive systems<\/b>.) Once the event handling is complete, the system goes back to waiting for the next event.<\/p>\n

The response to an event generally depends on both the type of the event and on the internal\u00a0state<\/a><\/b>\u00a0of the system and can include a change of state leading to a\u00a0state transition<\/a><\/b>. The pattern of events, states, and state transitions among those states can be abstracted and represented as a\u00a0finite-state machine<\/a><\/b>\u00a0(FSM).<\/p>\n

The concept of a FSM is important in\u00a0event-driven programming<\/a> because it makes the event handling explicitly dependent on both the event-type and on the state of the system. When used correctly, a state machine can drastically cut down the number of execution paths through the code, simplify the conditions tested at each branching point, and simplify the switching between different modes of execution. Conversely, using event-driven programming without an underlying FSM model can lead programmers to produce error prone, difficult to extend and excessively complex application code.<\/sup><\/p>\n

Basic UML state diagrams<\/span><\/h3>\n

UML preserves the general form of the\u00a0traditional state diagrams<\/a>. The UML state diagrams are\u00a0directed graphs<\/a>\u00a0in which nodes denote states and connectors denote state transitions. For example, Figure 1 shows a UML state diagram corresponding to the computer keyboard state machine. In UML, states are represented as rounded rectangles labeled with state names. The transitions, represented as arrows, are labeled with the triggering events followed optionally by the list of executed actions. The\u00a0initial transition<\/b>\u00a0originates from the solid circle and specifies the default state when the system first begins. Every state diagram should have such a transition, which should not be labeled, since it is not triggered by an event. The initial transition can have associated actions.<\/p>\n

Events<\/span><\/h3>\n

An\u00a0event<\/b>\u00a0is something that happens that affects the system. Strictly speaking, in the UML specification,<\/sup>\u00a0the term event refers to the type of occurrence rather than to any concrete instance of that occurrence. For example, Keystroke is an event for the keyboard, but each press of a key is not an event but a concrete instance of the Keystroke event. Another event of interest for the keyboard might be Power-on, but turning the power on tomorrow at 10:05:36 will be just an instance of the Power-on event.<\/p>\n

An event can have associated\u00a0parameters<\/b>, allowing the event instance to convey not only the occurrence of some interesting incident but also quantitative information regarding that occurrence. For example, the Keystroke event generated by pressing a key on a computer keyboard has associated parameters that convey the character scan code as well as the status of the Shift, Ctrl, and Alt keys.<\/p>\n

An event instance outlives the instantaneous occurrence that generated it and might convey this occurrence to one or more state machines. Once generated, the event instance goes through a processing life cycle that can consist of up to three stages. First, the event instance is\u00a0received<\/b>\u00a0when it is accepted and waiting for processing (e.g., it is placed on the\u00a0event queue<\/a>). Later, the event instance is\u00a0dispatched<\/b>\u00a0to the state machine, at which point it becomes the current event. Finally, it is\u00a0consumed<\/b>\u00a0when the state machine finishes processing the event instance. A consumed event instance is no longer available for processing.<\/p>\n

States<\/span><\/h3>\n

Each state machine has a\u00a0state<\/b>, which governs reaction of the state machine to events. For example, when you strike a key on a keyboard, the character code generated will be either an uppercase or a lowercase character, depending on whether the Caps Lock is active. Therefore, the keyboard’s behavior can be divided into two states: the “default” state and the “caps_locked” state. (Most keyboards include an LED that indicates that the keyboard is in the “caps_locked” state.) The behavior of a keyboard depends only on certain aspects of its history, namely whether the Caps Lock key has been pressed, but not, for example, on how many and exactly which other keys have been pressed previously. A state can abstract away all possible (but irrelevant) event sequences and capture only the relevant ones.<\/p>\n

In the context of software state machines (and especially classical FSMs), the term\u00a0state<\/i>\u00a0is often understood as a single\u00a0state variable<\/i>\u00a0that can assume only a limited number of a priori determined values (e.g., two values in case of the keyboard, or more generally – some kind of variable with an\u00a0enum<\/i>\u00a0type in many programming languages). The idea of\u00a0state variable<\/i>\u00a0(and classical FSM model) is that the value of the\u00a0state variable<\/i>\u00a0fully defines the current state of the system at any given time. The concept of the state reduces the problem of identifying the execution context in the code to testing just the state variable instead of many variables, thus eliminating a lot of conditional logic.<\/p>\n

Extended states<\/span><\/h3>\n

State machines supplemented with\u00a0extended state<\/i>\u00a0variables are called\u00a0extended state machines<\/b>\u00a0and UML state machines belong to this category. Extended state machines can apply the underlying formalism to much more complex problems than is practical without including extended state variables. For example, if we have to implement some kind of limit in our FSM (say, limiting number of keystrokes on keyboard to 1000), without\u00a0extended state<\/i>\u00a0we’d need to create and process 1000 states – which is not practical; however, with an extended state machine we can introduce a\u00a0key_count<\/code>\u00a0variable, which is initialized to 1000 and decremented by every keystroke without changing\u00a0state variable<\/i>.<\/p>\n","protected":false},"excerpt":{"rendered":"

In practice, however, interpreting the whole state of the state machine as a single\u00a0state variable<\/i>\u00a0quickly becomes impractical for all state machines beyond very simple ones. Indeed, even if we have a single 32-bit integer in our machine state, it could contribute to over 4 billion different states – and will lead to a premature\u00a0state explosion<\/i>. This interpretation is not practical, so in UML state machines the whole\u00a0state<\/i>\u00a0of the state machine is commonly split into (a) enumeratable\u00a0state variable<\/i>\u00a0and (b) all the other variables which are named\u00a0extended state<\/i>. Another way to see it is to interpret enumeratable\u00a0state variable<\/i>\u00a0as a qualitative aspect and\u00a0extended state<\/i>\u00a0as quantitative aspects of the whole state. In this interpretation, a change of variable does not always imply a change of the qualitative aspects of the system behavior and therefore does not lead to a change of state.[7]<\/a><\/sup><\/p>\n