Shulou(Shulou.com)06/02 Report--

Editor to share with you what you need to pay attention to in the process of creating a UML state chart, I believe most people do not know much about it, so share this article for your reference. I hope you will gain a lot after reading this article. Let's learn about it together.

Create a hierarchical UML state diagram for complex entities

While this method of expressing substates is very useful, the final diagram can become quite complex-- just imagine what figure 2 would look like if BeingTaught states had substates. An alternative is to create a hierarchical UML state diagram. For example, figure 3 shows a high-level view, while figure 1 depicts a detail view. The advantage of this approach is that if necessary, you can immediately create a detailed diagram to study the BeingTaught state.

Figure ⒊ Seminar's high-order state diagram.

The state diagram of order * always has the initial state and the final state.

A high-level UML state diagram, as depicted in figure 2, should represent the complete life cycle of the entity, including "birth" and "death". Low-level diagrams do not necessarily contain initial and final states, especially those that model the "intermediate state" of an entity's life cycle.

Transformation and action

A transition is a sequence from one state to another, which may be triggered by an event. In short, it is the internal or external behavior of the entity being modeled. For a class, transitions are generally the result of operation calls that will lead to important changes in state, so it is important to understand that not all method calls cause transformations. An action is something, which is an operation for a class, an operation called by the entity being modeled.

Name software actions with the naming rules of the implementation language

The action in figure 1 follows the naming convention (Vermeulenet.2000) of the Java operation, because the system uses a character action named with narrative text

UML state diagrams can be used to model the lifecycle of non-software entities, especially the roles on UML diagrams. For example, student roles may have states such as Accepted, FullTime, PartTime, Graduated, Masters, Doctoral, and Post-Doctoral to show different behaviors of each person. When you are modeling real-world roles, unlike the Student class in software, transitions between states are described using narrative words, such as dropseminar and payfees, rather than dropSeminar () and payFees (), because real-life people do things, not perform operations.

The entry action is indicated only if it is appropriate for all entry changes.

You can see in figure 1 that the operation notifyInstructor () in the entry of the ClosedToEnrollment state is called through the entry/ action tag. This implies that the operation needs to be called every time you enter the state, and if you don't want it to happen every time, associate the action with a specific entry transformation. For example, the addStudent () action occurs when you transform from studentenrolled to OpenForEnrollment, but not to opened, because you don't have to add one student each time you enter the state.

The exit action is indicated only when it is suitable for all exit changes.

The exit action, represented by the exit/ tag, works in a manner similar to the entry action.

Model recursive transformations only when you want to stop and re-enter the state

A recursive transition in a UML state diagram 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 its original state, so that all operations that are invoked due to entry/ or exit/ action tags may be invoked automatically. The OpenForEnrollment state of figure 1 is an example of this recursive transformation, so the current class size is recorded at the entrance.

Name the conversion event in the past tense

The transformation events in figure 1, such as seminarsplit and cancelled, are named in 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.

Put the transition tag close to the source state

Although figure 1 is complex, transform tags are placed as close to the source as possible, such as seminarsplit and studentenrolled. Furthermore,thelabelswerejustified (leftandrightrespectively) tohelpvisuallyplacethemclosetothesourcestate.

Place a transform marker based on the conversion direction

To make it easier to determine which tag goes with the transformation, place the transform tag according to the following rules:

From left to right on the changing lines.

From right to left under the changing line.

Change the one on the right of the line down.

Change the one on the left of the line up.

Warning point

A warning point is a condition that must be true in order to pass through a transformation.

Warning points should not overlap

The warning points on the similar transformation of the UML state diagram leaving the state must be consistent with each other. For example, the warning points of x0 are consistent, while those of xzero are not, because they overlap, and he does not specify what will happen when x is zero. In figure 1, you can see the consistency of the warning points. The warning points on the underlined transformation of the student starting from the registration form activity do not overlap, and the warning points on the decision points are the same.

The joint point is introduced to visually locate the warning point.

In figure 2, you can see that there are two transformations for the studentdropped event triggered from BeingTaught, while there is only one in figure 3, and the transformations are merged, so we need a join point (filled circle). The advantage of this method is that the two warning points on the map are closer to each other, making it easier to see whether the warning points overlap.

Warning points do not need to be matched.

The warning point of a state change may be incomplete. For example, a bankaccount object may transition from the Open state to the NeedsAuthorization state, requiring a warning point for large deposits of "largedeposit". However, a deposit transformation with a "smalldeposit" warning point may not need to be modeled, it is implied, and we follow the practice of AM-- a simple description model and only relevant information.

Consistent named warning point

Figure 1 contains warning points such as seatavailable and noseatavailable, which are described in the same way. However, descriptions such as seatsleft, noseatleft, noseatsleft, noseatsavailable, seatunavailable are inconsistent and difficult to understand.

These are all the contents of the article "what should be paid attention to in the process of creating UML state diagrams". Thank you for reading! I believe we all have a certain understanding, hope to share the content to help you, if you want to learn more knowledge, welcome to follow the industry information channel!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.