What Is a State Diagram?
Statechart Diagram describes the dynamic behavior of an entity based on event response, showing how the entity reacts to different events based on the current state. Usually we create a UML state diagram for the following research purposes: to study the complex behavior of a class, role, subsystem, or component.
State diagram for display
A state is a condition when an object performs an activity or waits for an event. The object may remain in a certain state for a limited length of time. Status has the following characteristics:
name | A text string that distinguishes one state from another; the state may also be anonymous, which means that it has no name. |
Enter / exit operation | What to do when entering and exiting a state. |
Internal transfer | A transition without changing the state. |
Substate | A nested structure of states, including unconnected (sequentially active) or parallel (simultaneously active) substates. |
Delayed event | A series of events that are not processed in this state but delayed (that is, queued to be processed by an object in another state). |
A transition is a relationship between two states, which means that when a specified event occurs and the specified conditions are met, the objects in the first state will perform some operations and enter the second state. When this state change occurs, the transition is "triggered". Before the transfer is triggered, the object can be considered to be in the "source" state; after the transfer is triggered, the object can be considered to be in the "target" state. Transfer has the following characteristics:
Source state | The state affected by the transition; if the object is in the source state, the output transition may be triggered when the object receives a trigger event for the transition and the alert condition (if any) is met. |
Event trigger | An event that causes a transition to meet a trigger condition. When the object in the source state receives the event (assuming its alert conditions have been met), a transfer may be triggered. |
Guard condition | A Boolean expression. When an event trigger is received to trigger a transition, the expression is evaluated; if the expression evaluates to True, the transition meets the trigger condition; if the expression evaluates to False, the transition is not triggered . If no other transfer can be triggered by the same event, the event is discarded. |
operating | Executable and indivisible calculation process. The calculation may directly affect the object that owns the state machine, or it may indirectly affect other objects visible to the object. |
Target state | The state that is activated after completing the transfer. |
A transition may have multiple source states, in which case it will appear as a join point starting from multiple parallel states; a transition may also have multiple target states, in which case it will appear as Fork graph with one or more concurrent states.
Unless otherwise
State machines are most commonly used to model the behavior of objects during their lifetime. When an object has state-dependent behavior, a state machine is especially needed. Objects that may have state machines include: classes, subsystems,
When given a choice, use the visual semantics of the state machine instead of writing detailed transition code. For example, don't trigger a transition with several signals, and then use detailed code to manage the control flow that depends on the signals in different ways. A separate transfer triggered by a separate signal should be used. Avoid conditional logic in transition code where additional behavior is hidden.
Name states based on what is waiting during the state or what is happening. Remember, a state is not a "point in time"; it is the period of time the state machine waits for an event to occur. For example, the name "waitingForEnd" is better than "end"; "timingSomeActivity" is better than "timeout". Don't make the name of the state look like an operation name.
Uniquely name all states and transitions within a state machine; this will facilitate source-level debugging.
Use state variables with care; do not use them when creating new states. You can use state variables if there are not many states, with or without state-dependent behavior, and with little or no behavior that may be parallel or independent from the state machine-containing package. Consider using if there are complex, state-dependent potential parallel behaviors, or if the events that must be processed may come from outside the package containing the state machine
For the aforementioned types of improvements, the ability to "continue" input and output transfers at the same time is a basic capability. A combination of entry points, termination states, and continued transitions seems to be sufficient to provide these semantics. However, this does not work if there are multiple different transitions that need to be expanded.
In this case, what the abstract behavior pattern requires is a way to link two or more transition segments that are all executed in a single run to the end step. This means that to enter
State diagrams are created when behavior changes are related to states.
State is a certain stage of an entity's behavioral pattern. The state is represented by the attribute value of the entity. For example, in Figure 1, when seminar is marked as open and there are vacancies, seminar is in the state of Open For Enrollment.
State names should be simple but descriptive.
State names such as Open For Enrollment and PropOSed are easy to understand, which enhances the communication value of Graph. In theory, the state name should be the present tense, but a name written in the past tense such as Proposed is better than a name written in the present tense such as Is Proposed.
Avoid "black holes".
A black hole state is a state where only transformations come in but no transformations are emitted. This is either because the state is a final state or you have missed one or more transformations.
Avoid "miracle" states.
A miracle state is a state where only transformations are issued but no transformations come in. This is either because the state is a starting point or you have missed one or more transformations.
State diagram modeling substates
The UML state diagram shown in Figure 1 is incomplete because it does not model the PoST-enrollment (post-registration) state of Seminar. Figure 2 models the complete life cycle of a Seminar. Figure 1 is described as a new composite state of the Enrollment that includes a set of substates, also called the superstate. Note that it stands to reason that you would process the labels like the model in Figure 1, but for simplicity, the labels on the original transformation are not included. When an existing state exhibits complex behavior, it makes sense to model the substates, prompting you to study its substates. When several existing states share a common entry or exit condition (DouglASs 1999), it makes sense to introduce superstates. In Figure 1, you can see that all states share a common closed transformation to reach the final status.
State graph substate transition
Different from Figure 1, each substate has a canceled transition. In Figure 2, you can see that the canceled transition is only used to describe the Enrollment superstate, which simplifies the graph. If the substates all share an entry transition or exit transition, you can use the same method. The guard points and actions (if any) on the transformation should also be made equal.
Create a layered state diagram for complex entities
Although this method of expressing substates is very good, the final graph may become quite complicated-we only need to imagine what Figure 2 will look like if the Being Taught state also has substates. An alternative approach is to create a hierarchical UML state diagram. For example, Figure 3 represents a high-level view, while Figure 1 depicts a detail view. The advantage of this method is that if needed, you can immediately build a detailed map to study the Being Taught state.
The highest order state diagram always has initial and final states
A high-level UML state diagram, such as that depicted in Figure 2, should represent the complete life cycle of an entity, including "birth" and finally "death". Low-level diagrams do not necessarily include initial and final states, especially those that model the "intermediate state" of the life cycle of an entity.
State diagram transitions and actions
A transition is a sequence from one state to another, and it may be triggered by an event. In short, it is the internal or external behavior of the modeled entity. For a class, transformation is generally the result of an operation call that will cause a significant change in state, so we need to understand that not all method calls will cause a transformation, which is very important. An action is something, an operation for a class, an operation invoked by a modeled entity.
Name software actions with naming conventions for implementation languages
The actions in Figure 1 follow the naming rules for Java operations (Vermeulen et. 2000) because the system uses
Name character actions with narrative text
UML state diagrams can be used to model the life cycle of non-software entities, especially roles on UML diagrams. For example, student roles may have statuses such as Accepted, Full Time, Part Time, Graduated, Masters, Doctoral, and Post-Doctoral to show the different behaviors of each person. When you are modeling a real-world role, unlike the Student class in software, the transition between states is best described using narrative text, such as drop seminar and pay fees, rather than dropSeminar () and payFees () Because in real life people do things, not perform actions.
Indicate entry actions only if all entry transitions are appropriate
In Figure 1, you can see that the notifyInstructor () operation in the Closed To Enrollment state entry is called via the entry / action tag. This implies that the operation needs to be called every time the state is entered. If you don't want to happen every time, then associate the action with a specific entry transform. For example, the addStudent () action occurs when the student enrolled transform to the Open For Enrollment transform, and it does not occur after the open to transform, because you do not need to add a student each time you enter the state.
Indicate exit actions only if appropriate for all exit transformations
Exit actions are represented by exit / tags, which work similarly to entry actions.
Recursive transformations are modeled only when you want to terminate and re-enter the state
A recursive transformation is one in which both endpoints have the same state. An important hint is that the entity comes out of the state and returns to the original state, so any operation that is called due to the entry / or exit / action flag may be automatically called. The Open For Enrollment state in Figure 1 is an example of this recursive transformation, so the current class size is recorded at the entrance.
Convert events in past tense
The transition events in Figure 1, such as seminar split and canceled, are named using the past tense, reflecting the fact that the transformation is the result of the event-because the event occurs before the transformation, it should be named in the past tense.
Place transition markers close to the source state
Although Figure 1 is more complicated, the transformation markers are placed as close to the source as possible, such as seminar split and student enrolled. Furthermore, the labels were justified (left and right respECtively) to help visually place them close to the source state.
To make it easier to determine which mark is associated with the transformation, place the transformation mark according to the following rules:
From left to right on the transformation line.
Right to left under the transformed line.
Transform the line down to the right.
Transform the line up to the left.
Guard point: A guard point is a condition that must be true in order to pass through a transition.
Guard points should not overlap
The guard points on similar transformations of leaving states must agree with each other. For example, the guard points of x <0, x = 0, and x> 0 are the same, and the guard points of x <= 0 and x> = 0 are not the same, because they overlap, it is not clear Indicates what happens when x is 0. In Figure 1, you can see the consistency of the guard points. The guard points on the student s dash-line transformation starting from filling in the registration activity do not overlap, and the guard points on decision points are the same.
Introduce joints for visual positioning of guard points.
In Figure 2 you can see that there are two transforms that trigger the student dropped event from Being Taught, but there is only one transform in Figure 3. The transforms are merged, so we need a junction (filled circle). The advantage of this method is that the two guard points on the map are now closer to each other, and it is easier to see whether the guard points overlap.
There is no need to set up guard spots
A state transition alert point may be incomplete. For example, a bank account object may change from the Open state to the Needs Authorization state. At this time, a warning point of "large deposit" is required. However, a deposit transformation with a guard point of "small deposit" may not need modeling, it is implied, we follow the practice of AM-simple description model and include only relevant information.
Consistently named guard points
Figure 1 contains guard points such as seat avAIlable and no seat available. The descriptions of the two guard points are consistent. However, descriptions such as seats left, no seat left, no seats left, no seats available, and seat unavailable are inconsistent and difficult to understand.
