Chapter 2 state machine View 6.1 Overview
The state machine view creates a model for the lifecycle of a Class Object to describe the dynamic behavior of the object over time. Each object is seen as an independent entity that communicates with other parts of the outside world by detecting and responding to events. An event indicates a kind of motion change of a thing that an object can detect-for example, receiving a call or signal from an object to another object, a change in some values, or the end of a time period. All things that affect objects can be events. Models of things that occur in the real world are built by signals from the external world to the system.
A State is a set of attribute values of an object of a given class. This group of attribute values have the same response to the event. In other words, objects in the same state have the same response to the same event. Therefore, when multiple objects in a given State receive the same event, the same action will be executed, however, objects in different States will respond differently to the same event through different actions. For example, when the automatic reply server is in the transaction processing or idle state, it will respond differently to the cancel key.
State machines are used to describe the behavior of classes, but they also describe the dynamic behavior of use cases, collaboration, and methods. For these objects, a State represents a step in execution. We usually use classes and objects to describe the state machine, but it can also be directly applied by other elements.
6.2 state machine
A state machine is a graph of state and state transition. Generally, a state machine is attached to a class and describes the response of an event that occurs when an instance of a class is docked. State machines can also be attached to operations, use cases, and collaboration and describe their execution processes.
A state machine is a model of all possible lifecycles of A Class Object. Objects are isolated from the system, and any external influences are outlined as events. After an event is detected, the object responds to the current state, including executing an action and switching to a new state. A state machine can be constructed as an inheritance transformation or a model for concurrent behaviors.
A state machine is a local view of an object. It separates an object from its external world and examines its behavior independently. The state machine can accurately describe the behavior, but it is not suitable for a comprehensive understanding of the system's operations. To better understand the impact of behaviors across the system, the interactive view is more useful. However, state machines help you understand controllers such as user interfaces and device controllers.
6.3 events
Events are worth noting in terms of time and space. It occurs at a point in time, with no duration. If an event is affected, it is an event in the state machine model. When we use the word "Event", it usually refers to an event description symbol, that is, the description of all independent events with the same form, just as the word "class" indicates all independent classes with the same structure. An event is called an event instance. The event may have parameters to identify each instance, just as the class uses properties to identify each object. For classes, signals are organized using generalized relationships so that different classes share the common structure. Events can be divided into specific or hidden types: signal events, call events, repair events, and time events. Table 6-1 contains several event types and their descriptions. 6-1 event types
1. Signal events
A signal is the entity named after the communication media between two objects. receiving a signal is an event of the receiving object. The sending object explicitly creates and initializes a signal instance and sends it to one or more objects. The most basic signal is asynchronous single-channel communication. The sender does not wait for the receiver to process the signal but does his/her own work independently. In the dual-channel communication model, a multi-channel signal is required, that is, at least one signal must exist in each direction. The sender and receiver can be the same object.
The signal can be declared as a class Element in the class diagram and expressed with the keyword signal. The signal parameters are declared as attributes. Like similar elements, signals can have a general relationship, and signals can be subsignals of other signals. They inherit the parameters of the parent signal, it can trigger conversion dependent on the parent signal (6-1 ).
Figure 6-1 Classification of Signals
2. Call events
A call event is an object receiving a call. This object uses state conversion instead of a fixed processing process to perform operations. For callers, common calls (calls implemented by methods) are not identified by call events. The receiver either uses a method to implement the operation or triggers a state transition to implement the operation. The operation parameter is the event parameter. Once the receiving object of the call completes the processing of the call event or the call fails without performing any state conversion through the event-triggered conversion, the control returns to the call object. However, unlike a normal call, the receiver of the call event will continue its own execution process, in parallel with the caller.
3. Modify events
Modifying an event depends on the condition indicated by a Boolean expression of a specific attribute value. This is a declarative way to wait until a specific condition is met, but you must use it with caution, because it represents a time-sustained and possibly global computing process (a long-distance action because the tested value may be long-distance ). This has both advantages and disadvantages, its advantage is that it focuses the model on the true dependency-a role that occurs when a given condition is met-rather than the mechanism of the test condition. The disadvantage is that it blur the causal relationship between the activity that modifies the potential value of the system and the final effect. The cost of modifying the test event may be high because, in principle, the modification event continues. In fact, there are ways to avoid unnecessary computation. Modification events should only be used when a communication form with a clearer expression is not natural.
Note the differences between the monitoring condition and the event modification. The monitoring condition is assigned only once when the trigger event that causes the conversion is triggered and when the event receiver processes the event. If it is false, the conversion will not be stimulated, and the condition will not be assigned a value. The modification event is assigned multiple times until the condition is true, and the conversion is also triggered.
4. Time event
Time events represent the passage of time. A time event can be specified as an absolute event (number of days) or a relative event (the time that has elapsed since the occurrence of a specified event ). In the high-level model, time events can be considered events from the whole world. In the implementation model, they are caused by signals of specific objects, these objects can be either the operating system or the objects in the application.
Status 6.4
Status describes a time period in the life cycle of a Class Object. It can be described in three additional methods: A group of object values with similar properties in some aspects, an object waiting for a period of time when some events occur, and an object executing a continuous activity for a period of time. Although the State is usually anonymous and only describes the activity of the object in this state, it can also have a name.
In a state machine, a group of States are connected by a switch. Although the switch is connected to two States (or multiple States, if the graph contains branches and combined control), the switch is only processed by the status starting from the switch. When an object is in a certain state, it is very sensitive to trigger events that trigger state conversion.
The status is represented by a rectangle with a circular corner. 6-2.
Figure 6-2 status
6.5 Conversion
The transition from the State defines the response of an object in this state to an external event. Generally, define a conversion trigger event, monitoring condition, conversion action, and conversion target State. Table 6-2 lists several conversions and implicit actions caused by conversions.
Table 6-2 conversion types and implicit actions
1. External Conversion
External conversions are the most common conversions that change the active state. It is represented by an arrow from the source status to the target status. Other attributes are appended with a text string (6-3 ).
Figure 6-3 External Conversion
2. trigger events
A trigger event is a conversion event. The event can have parameters for conversion. If a signal has a descendant, any descendant of the signal can cause conversion. For example, if the mouse button is used as the trigger for conversion, the mouse button down can trigger this conversion (6-1 ).
Events do not occur continuously. They only occur at a point in time. When an object receives an event, if it does not have free time to process the event, it will save the event. The object only processes one event at a time, and the conversion must be triggered when the object processes the event. It will not be remembered after the event (except for some special delay events, such events are saved before or before a conversion is triggered ). If two events occur at the same time, they are processed each time. Events that do not trigger any conversions are simply ignored or abandoned. This is not an error. It is much easier to ignore unwanted events than to specify all events in detail.
3. Monitoring conditions
Conversion may have a monitoring condition, which is a Boolean expression. The monitoring condition can reference the property value of an object and the parameters of the trigger event. When a trigger event is triggered, the monitoring condition is assigned a value. If the Boolean expression value is true, the event is triggered to make the conversion valid. If the value of a Boolean expression is "false", conversion is not triggered. The monitoring condition can only be assigned once when an event is triggered. If the monitoring condition changes from "false" to "true" after conversion, the conversion cannot be triggered because the assignment is too late.
Multiple conversions from a State can have the same trigger event, but each conversion must have different monitoring conditions. When one of the monitoring conditions is met, the trigger event will cause a conversion. Generally, the setting of the monitoring condition takes into account various possible situations to ensure that the occurrence of a trigger event can cause certain conversions. If a trigger event does not cause any conversion, ignore the event in the state machine view. An event can only cause one conversion (in a control thread) at the same time ). If one event may cause multiple conversions, only one of them is valid. If the two conflicting conversions are valid at the same time, you cannot determine which one has taken place. Either of these conversions happens randomly, or the Implementation Details of the system determine which one occurs, but the consequences of such conversions cannot be predicted by the modeler.
4. Complete Conversion
It is not indicated that the conversion of trigger events is caused by the completion of activities in the status (that is, the completion of the conversion ). Conversion can also be completed with a monitoring condition, which is assigned when the activity in the status is completed (rather than after completion ).
5. Action
When the conversion is caused, the corresponding action is executed. An action is atomic. It is generally a brief computing process, usually a value assignment operation or arithmetic calculation. There are also some actions, including sending messages to another object, calling an operation, setting the return value, creating and destroying the object. unspecified control actions are described in detail in external languages. An action can also be an action sequence, that is, a series of simple actions. The execution of an action or action sequence is not affected or terminated by other actions at the same time. According to the concept in UML, the execution time of an action is very short, which can be ignored compared with the time experienced by external events. Therefore, other events cannot be inserted during the execution of an action. However, in fact, the execution of any action takes some time, and new events must be placed in a queue.
The entire system can execute multiple actions at the same time. We say that actions are atomic, not that the entire system is atomic. The system can handle hardware interruptions and time sharing of multiple actions. Action is atomic in its control line. Once the execution starts, it must be executed to the end and cannot interact with the action in the active status at the same time. However, actions cannot be used to express things that process a long time. Compared with the response time required by the system to process external events, the action execution process should be concise; otherwise, the system cannot respond in real time.
An action can use the trigger event parameters and object attribute values as part of the expression.
Table 6-3 lists various actions and descriptions.
Table 6-3 Action types
6. Status Change
After an action is executed, the target State is activated, and the exit action or entry action is triggered.
7. nesting status
The status can be nested in other composition states (see the next section ). Conversion from an external State can be applied to all internal nested states in this state. Conversion may occur when any internal nesting status is activated. The composition status can be used to express exceptions and exceptions, because the transition in the composition status applies to all the States it is nested in, and each nested status does not need to explicitly handle exceptions separately.
8. Entry and exit actions
A transformation that spans multiple nested layers may exit or enter a certain state. As long as the switch enters or leaves a certain status, the status may contain the action to be executed. Entering a status may execute an entry action that is attached to this status. If the switch is out of the initial state, the export action in this state is executed before the switch action and the new State entry action are executed.
The entry action is usually used for internal initialization required by the State. Because you cannot avoid an entry action, before any action in the status is executed, you can assume that the initialization of the status has been completed, and you do not need to consider how to enter this status. Similarly, you must execute an exit action to perform post-processing whenever you exit from a status. The exit action is particularly useful when a high-level switch that represents an error causes the nested State to terminate abnormally. The export action can handle this situation to make the object state consistent. In principle, the entry action and exit action are dependent on the incoming and outgoing conversions, but declaring them as special actions can enable the State definition to be independent of the State Conversion and thus play the role of encapsulation.
9. Internal Conversion
Internal Conversion has a source status but no target status. The internal conversion excitation rules are the same as those for changing the status. Because there is no target State for internal conversion, the result of conversion excitation does not change this state. If an internal switch has an action, it will also be executed, but no status change occurs, so you do not need to execute the entry and exit actions. Internal conversion is used to create a model for the insert action that does not change the status (for example, to record the number of events or to create a help information screen ).
Although the execution of Entry and Exit actions is caused by an external switch that enters or leaves a certain State, besides using the reserved word entry and exit to replace the trigger event name, the entry and exit actions use the same notation as internal conversions.
A self-transfer will trigger the entry action and exit action in the State (in terms of concept, the self-transition starts from one state and then changes to its own State). Therefore, self-conversion is not equivalent to internal conversion. Figure 6-4 shows the entry action, exit action, and internal conversion.
Figure 6-4 internal rotation, entry action, and exit action
6.6 composition status
A simple state has no sub-structure and only contains a set of conversion and possible entry and exit actions. The component State is the State of a substate that is divided into sequential or concurrent states. Table 6-4 lists various statuses. Table 6-4 states
Splitting a State into mutually exclusive sub-states is a specialized processing of the State. An external State is subdivided into multiple internal sub-States. Each sub-State inherits the conversion of the external state. At a time, only one sub-state is active. The external State represents the conditions that each internal state has.
The conversion of the entry or exit status will lead to the execution of the entry or exit action. If there are multiple states, the conversion across multiple layers will lead to the execution of multiple entry actions (the first execution of the outermost layer) and exit actions (the first execution of the innermost layer. If the conversion has an action, this action is executed after the entry action is executed and before the exit action is executed.
The composition status may also have an initial status inside it. The transition on the composition state boundary is implicitly the transition on the initial state. A new object starts from the initial State of its outermost layer. If an object reaches the termination state of its outermost layer, the object will be destroyed. The initial status, termination status, entry action, and exit action encapsulate the definition of the State, so that the definition of the State is irrelevant to the conversion of the inbound and outbound states.
Figure 6-5 shows the sequential decomposition of a State, including an initial state. This is the state machine model of the ticketing system.
Figure 6-5 State Machine
Splitting a State into multiple sub-states of concurrency represents an independent parallel processing process. When a concurrent superstate is entered, the number of control threads increases. When a concurrent superstate is left, the number of control threads decreases. For each State, concurrency is usually implemented by different objects, however, the concurrent substate can also represent a logical concurrency relationship in a separate state. Figure 6-6 shows the concurrent decomposition of an elective university course.
Figure 6-6 state machine with concurrent Composition
Figure 6-7 sub-machine status
In general, you can use a part of another state machine in a state machine. This reusability will bring some convenience. A state machine can be named and can reference one or more other state machines by name. The target state machine is a sub-machine. The state of referencing this sub-machine is called the sub-machine reference state. It means to replace the original content with a state machine where it needs to be referenced. A state machine can contain an activity, that is, a processing process, a sustained process that takes time to complete, or an event that can be interrupted, the sub-machine cannot be referenced in Figure 6-7.
Switching to a sub-machine reference state activates the initial state of the target sub-machine. To enter a sub-machine in another state, you must place one or more sub-machines in the sub-machine reference state. The pile status is used to identify the status in the sub-machine.
|
