UML reference manual
Part II Based Overview
Chapter 6 Status Chart 6.1 Overview The State Chart describes the dynamic behavior of the object over time by establishing a model for the survival cycle of class objects. Each object is considered to be an independent entity that communicates with the outside of the event by detecting and responding to the event. The event represents a motion change of the object that can detect - such as a call or signal from an object to another object, the change of certain values or the end of a period of time. Anything that affects the object can be an event, the model of things that occurred in the real world is built from the external world to the system. The status is a set of attribute values for the object of the object, which has the same properties of the event. In other words, the object in the same state has the same manner on the same event, so when multiple objects in a given state are performed, the same operation is performed, but the object in different states will pass Different movements have different reactions to the same event. For example, different reactions are made differently when the automatic reply is in a transaction or idle state. The state machine is used to describe the behavior of the class, but they also describe the dynamic behavior of the use case, collaboration and method. For these objects, a state represents a step in the execution. We usually use classes and objects to describe the state machine, but it can also be applied directly by other elements. 6.2 State Machine State Machine is a diagram showing status and state transition. Typically, a state machine is attached to a class and describes the react that occurs in an instance of a class. The state machine can also be included in operation, use cases, and collaborate and describe their execution processes. The state machine is a model of all possible life history. The object is isolated and examined from the system isolated, and any effect from the outside is an event. When an object detects an event, it responds in accordance with the current state, and the reaction includes performing an action and transition to a new state. The state machine can be constructed into inheritance conversion, and can also be established as a model. The state machine is a partial view of an object, one to separate the object with its external world and independently examine its behavior. Behavior can be accurately described using the state machine, but it is not suitable for integrated understanding of the system execution operation. If you want to better understand the influence of behavior within the entire system, then the interaction view will be more useful. However, the state machine helps to understand the control machine such as a user interface and the device controller. 6.3 Event event is a little worthwhile in time and space. It happened at a time, there is no duration. If a thing is affected, it is an event in the state machine model. When we use events, it is usually referred to as a description symbol of an event, that is, a description of all independent events that have the same form, just like the term of the class represents all independent classes with the same structure. An example of a particular occurrence of an event called an event. Events may have parameters to distinguish each instance, just like class properties to identify each object. For classes, signals are tissue using generalization relationships to share common structures. Events can be divided into several species of clear or implicit: signal events, call events, repair events, time events, etc. Table 6-1 is a variety of event types and descriptions. 6-1 Type of Event 1. The signal event signal is a naming entity as a communication medium between the two objects, and the reception of the signal is an event of the signal acceptance object. The send object explicitly creates and initializes a signal instance and sends it to one or a set of objects. The most basic signal is asynchronous single-channel communication, and the sender will not wait for the recipient how to process the signal but independently do its own work. In the dual communication model, multiple signals are used, ie, at least there is a signal in each direction. The sender and recipient can be the same object. The signal can be declared in the class diagram as a class, and the keyword "signal" is represented, the parameters of the signal are declared as attributes. As with the same type, the signal can have an extensive relationship, and the signal can be a sub-signal of other signals, which inherit the parameters of the parent signal, and can trigger a conversion dependent on the parent signal (as shown in Figure 6-1). Figure 6-1 Riegele Tissue 2. Calling Event Call Event is an object to the call to the call, the transition of this object is used instead of implementation with a fixed processing process.
For the caller, ordinary calls (calls implemented by ways) will not be discerned by the event. The recipient is not using a method to implement the operation is to trigger a state transition to implement this operation. The parameters of the operation are the parameters of the event. Once the called reception object is completed by the transition of the event, the control returns to the calling object by the conversion of the event triggered. However, different from ordinary calls, the recipient calling the event will continue its own execution process, and the caller is in parallel. 3. Modifying event modification events is satisfied by the condition of the Boolean expression that relies on the specific attribute value. This is a declaration path that is satisfied to a particular condition, but be careful to use it because it expresses a time sustainability and may be a global calculation process (it is a long distance action because The value of the test may be long distance). This has benefits and bad place, it is the advantage that it focuses on real dependencies - a role that occurs when the conditions are met - rather than concentrated on test conditions. A disadvantage is that it makes the causal relationship between the potential value of the system and the final effect be blurred. Testing the cost of modifying events may be large, as in principle, modifying events are continuous. In fact, there is a method of avoiding unnecessary calculations. Modifying events should be used only when a communication form having more clear expression is unnatural. Please pay attention to the difference between monitoring conditions and modification events. The guard is only assigned when the transformed trigger event is triggered and the event recipient is assigned once. If it is a false, the conversion will not be excited, and the conditions will not be assigned. The modification event is assigned multiple times until the condition is true, and the conversion will be excited. 4. Time event time event represents the passage of time. The time event can be specified as an absolute form (days), or may be specified as a relative form (the time experienced from a specified event). In high-level models, time events can be considered from events from the entire world; in implementing models, they are caused by some specific objects, which may be an operating system or an object in an application. 6.4 Status Status Describes a period of time in a class object life. It can be described in three additional modes: a set of object values similar to some of the nature; an object waits for some time when some event occurs; the object is time to perform continuous activity. Although the state is usually anonymous and only an activity description performed when the object is in this state, it can also have a name. In the state machine, a set of states are connected by a conversion. Although the conversion is coupled to two states (or multiple states, if the branches and combined controls are included), the conversion is only by the state of the transition. When the object is in a certain state, it is very sensitive to trigger events that trigger state conversion. The state is represented by a rectangular shape having a circular corner. As shown in Figure 6-2. Figure 6-2 Status 6.5 Conversion of the transition from the state defines the reaction made by the object in this state to the event. Typically, a conversion must be converted to a trigger event, a monitoring condition, a conversion of a monitoring, and a conversion of the conversion. Table 6-2 lists several conversions and implicit operations caused by the conversion. Table 6-2 Type and implicit action 1. External conversion external conversion is a conversion that changes the active state, it is the most common conversion. It is represented by an arrow from the source state to the target state, and other attributes are attached to the arrow in the text string (as shown in Figure 6-3). Figure 6-3 External conversion 2. Trigger event trigger event is an event that causes a conversion. The event can have parameters to use the action for converting. If a signal has a descendant, then any of the processes in the signal can cause conversion. For example, if the transformation will use the Mouse Button as a trigger, then Mouse Button Down can trigger this conversion (as shown in Figure 6-1). The event is not continuous, it only occurs at a point.
When an object receives an event, if it does not have free time to handle the event, save the event. Objects only handle an event at a time, the conversion must be excited when the object is handled, and the incident will not be remembered (except for some special delay events, such an event is triggered or delayed before the delay is released. Save it). If two events occur simultaneously, they are processed each time. Events that do not trigger any conversion are simply ignored or abandoned. This is not an error. It is much more easier to ignore unwanted events than in detail. 3. Monitoring condition conversion may have a guard condition, and the guard condition is a Boolean expression. Monitoring conditions can reference objects of attribute values and parameters for triggering events. When a trigger event is triggered, the guard condition is assigned. If the value of the Boolean expression is "true", then trigger the event to make the conversion are valid. If the value of the Boolean expression is "false", it will not cause conversion. The condition can only be assigned once when the trigger event occurs. If the monitor condition is changed by the original "false" after the 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 guards are met, the trigger event causes the corresponding conversion. Typically, the setting of the monitoring conditions should take into account the various possible situations to ensure that the occurrence of a trigger event should be capable of causing some conversions. If some cases are not considered, a trigger event does not cause any conversion, then this event is ignored in the status machine view. An event can only cause a conversion (in a control thread). If an event may cause multiple conversions, only one conversion is valid. If two mutual contradictory conversions are valid, it is impossible to determine which conversion occurs. These two conversions randomly occur, or which one is determined by the implementation details of the system, but the consequences of this conversion cannot be expected to the modeling. 4. Complete the conversion without indicating that the transformation of the trigger event is caused by the completion of the activity in the state (ie, completion conversion). Completion of conversion can also take a guard condition that is assigned when the activity is completed in the state (not completed). 5. Action When the conversion is caused, its corresponding action is executed. The action is atomic, generally a short calculation process, usually an assignment operation or arithmetic calculation. There are also some actions, including sending a message to another object, calling an operation, setting the return value, creates and destroying objects, without defined control action external language for a detailed description. The action can also be a single range of action, namely a series of simple actions. The execution of the action or action sequence does not have other actions or termination of the simultaneous occurrence. According to the concept in UML, the execution time of the action is very short, and it is negligible compared to the time experienced by the external event, so other events cannot be inserted during the execution of the action. However, in fact, any action is taken for a certain period of time, and the new event must be placed in a queue. The entire system can perform multiple actions at the same time. We said that action is atomic, not to mention the entire system is atomic. The system can handle the interrupt of hardware and the time sharing of multiple actions. Action is atomic in its control thread. Once started, it must perform in the end and cannot interact with the active action at the same time. But the action cannot be used to express a long way to process the process. The execution process of the action should be very concise compared to the reaction time required to handle external events, otherwise the system cannot be real-time response. An action can use the parameters of the trigger event and the attribute value of the object as part of the expression. Table 6-3 lists various actions and descriptions. Table 6-3 Type 6. Status change When the action is executed, the target state of the conversion is activated, and the execution of the outlet action or the inlet action is triggered.
7. The nested state state can be nested within other constituent states (see next). The conversion from an external state can be applied to all internal nested status of this state. When any internal nested state is activated, the conversion may occur. The constituent state can be used to express exceptions and exceptions because the transitions on the constituent state apply to all of its nested states, and no exception is explicitly processed separately each nested state. 8. Entrance and exit Action A conversion across multiple nested hierarchies may leave or enter a state. This state may contain the action to be executed as long as the transition is entered or left a state. Entering a state may execute an inlet action attached to the state. If the conversion leaves the initial state, the outlet action of the state is executed before the converted action and the inlet operation of the new state are executed. The inlet action is usually used to perform internal initialization required by the state. Because an inlet action cannot be avoided, the action within any state can assume that the initialization of the status is completed before execution, and does not need to consider how to enter this state. Similarly, the post-processing work is performed by performing an outlet action from one state away from one state. When the high-level conversion representing the error condition causes the nested state to terminate, the outlet action is particularly useful. The outlet action can handle this situation to keep the status of the object before and after. The entrance action and exit action are in principle attached to the incoming and outgoing conversion, but they declare them as special actions can make the state definition of non-dependent state transitions, thus acting as a package. 9. Internal conversion internal conversion has a source state but there is no target state. The internal conversion of the excitation rules and the transition of the changed state are the same. Since the internal conversion has no target state, the result of the transition excitation does not change the state. If an internal conversion is actions, it is also executed, but there is no state change, so it is not necessary to perform portal and outlet action. Internal conversion is used to establish a model for insertion actions that do not change the state (eg, the number of events that occur or established a help information screen). Although the implementation of the inlet action and the outlet action is caused by external conversion of entering or leaving a certain state, the inlet and outlet action use the same representation as the internal conversion in addition to the triggering event name, in place of the triggering event name. A self-transfer will motivate the execution of the inlet action and outlet action (from the concept, it will go back from one state), so it is not equivalent to internal conversion. Figure 6-4 illustrates inlet action, outlet action, and internal conversion. Figure 6-4 Internal rotation, inlet action and outlet action 6.6 Composition Status A simple state has no sub-structure, with a set of conversions and possible portions and outlet actions. The constituent state is a state in which a sub-state being decomposed into sequence is decomposed. Table 6-4 lists various states. Table 6-4 The species of the state decomposes the status of a state in which a state is a specialization process. An external state is subjected to a plurality of internal sub-states, each of which inherits the conversion of external states. Only one sub-state at a certain time is active. The external state expresses the conditions for each internal state. Transitions entering or leaving a constituent state cause an inlet action or an outlet action. If there are multiple constituent states, transitions across multiple hierarchies cause multiple entry actions (outermost layers performed to execute) and outlet action (the innermost performed performed). If the conversion has an action, then this action is executed before the inlet action is executed. The constituent state may also have an initial state inside. The conversion of the constituent state boundary is implicitly converted to the initial state. A new object starts with the initial state of its outermost layer. If an object reaches the termination status of its outermost state, the object will be destroyed. The initial state, termination state, inlet action, and outlet motion encapsulate the state definition, so that the state definition is independent of the conversion of the input state. Figures 6-5 show a sequential decomposition of a state, including an initial state. This is the state machine model of the ticketing system. Figure 6-5 The state machine decomposes a plurality of sub-states representing a concurrent parallel processing process independently.
