10. Status machine diagram state machines diagram
A state machine diagram is a common technique for describing a system's behavior. In an object-oriented approach, a state machine diagram is drawn for a single class to demonstrate the life cycle behavior of a single object.
See Figure 10.1
The diagram shows a state machine diagram of the control class that manages my unusual security system. It starts with the state that the control object was created: Wait for state wait. The figure implies that this is the initial pseudo-state initial pseudostate, although not a state but another arrow pointing to the initial state.
The figure shows that the controller can be in 3 states: Wait, lock, and open. The graph also provides rules that represent changes between States, in the form of transition: the line of the connected state.
The transfer represents from one state to another state. Each transfer has a three-part label: Trigger signal Trigger-signature [guard condition guard]/activity. These sections are optional. A trigger signal is often a single event that triggers a potential state change. Guard If
There is a Boolean condition that must be true for this transfer to take place. Activity activities are some of the behaviors that are performed during the transfer process (behavior executed during the transition), which can be arbitrary behavior descriptions behavioral expression.
If there is no trigger signal, the transfer occurs immediately, which is often seen in the active state of activity.
When an event occurs in a state, you can only make one transfer. If you make multiple transfers to the same event, the guard condition must be mutually exclusive mutually exclusive. If an event occurs but no transfer is valid, the event is ignored.
The final state indicates the completion of the state machine, implying the deletion of the control object. Remember that the state machine can only show things that the object directly observes or activates.
"Internal activity" internal activities
The state can respond to events without transferring the can react to events without transitions, using an internal activity internal activity: Putting events, guards, and activities inside the State box.
See Figure 10.2
An internal interaction is analogous to a self-transferring self-transition: a loop back to the same state of transfer.
Also shows two special events: Entry or exit. The entry activity is performed when you enter a state, and the exit activity is performed when you leave. Internal activities do not punish entry or exit activities, which is the difference between internal activities and self-transfer.
"Active status"
In the state I described earlier, the object is quiet quiet and waits for the next event to do something. However, you can also allow the object to do some uninterrupted ongoing work in certain States.
See Figure 10.3
The search status in the figure is such an activity state: the continuous activity is marked with do/, followed by the do-activity. Once the search is complete, any transfer without an activity will be performed. If the cancel time appears in the activity, the do-activity is aborted.
Do activities and general activities indicate some behavior. The key difference is that the general activity occurs immediately and is not interrupted by a normal event. The do activity takes a limited number of events and can be interrupted.
The action action in UML1 represents the general activity, while the activity actitity only represents the do activity.
"Super State Superstate"
You will often find that some states share the same transitions and internal activities, and you can turn them into sub-states and move the shared behavior to a hyper state. For example, if you don't use a sub-state, you will draw a cancel transfer for all 3 states.
See Figure 10.4.
"Concurrency Status Concurrent State"
The state can be divided into several complementary state graphs to be carried out simultaneously.
See Figure 10.5
The historical pseudo-state history pseudostate is also shown in the figure. This means that when the clock is turned on, RADIO/CD returns to the state when the clock is turned off. The historical pseudo-state arrows indicate which state is in the first time without history.
"Implementing a state diagram"
It can be implemented in 3 ways: nested switch, state mode, state table.
The state pattern creates a hierarchy of state classes to handle the behavior of the state. Each state in the diagram has a status subclass. The controller has a method that corresponds to each event.
See Figure 10.7
The state table method takes the information of the state graph as data.
See Figure 10.1
"When to use"
The state machine excels at representing the behavior of an object in several use cases and is not good at describing the behavior of introducing multiple objects to collaborate. For example, the interaction diagram (Chapter 4) is good at describing the behavior of several objects in a use case, while the activity diagram (Chapter 11) specializes in displaying the timing of multiple activities for multiple objects or use cases.
UML pristine--10. State machine Diagram
