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

Today, I will talk to you about how to understand the UML sequence diagram. Many people may not understand it very well. In order to make you understand better, the editor has summarized the following contents for you. I hope you can get something according to this article.

To introduce UML sequence diagrams, like collaboration diagrams and activity diagrams, UML sequence diagrams are a dynamic modeling method, so what's so special about it? let's take a look at the detailed introduction of UML sequence diagrams.

UML sequence Diagram of UML Modeling style

Like collaboration diagrams and activity diagrams, UML sequence diagrams (Rumbaugh, Jacobson, and booch,1999) are dynamic modeling methods. UML sequence diagrams are generally used to confirm and enrich the logic of a usage situation. A usage scenario is a description of the underlying use of the system, which is what its name is intended to describe. A logic that uses a situation may be part of a use case, or an alternative line; a complete process that runs through a single use case, such as a logical description of the basic process of an action, or a logical description of part of the basic process of an action plus one or more alternate scenarios. Or the process included in several use cases, such as a student enrolling in three classes immediately after enrollment.

Study your design because they provide you with a way to visually invoke class-defined operations. Detect bottlenecks in object-oriented design. By observing what messages are sent to an object, and by observing roughly how long it takes to run the called method, you can quickly understand that the design there needs to change in order to balance the load within the system. In fact, some CASE tools even allow you to simulate these features of the software.

The class that enables you to feel that your application is going to become complex is a signal that you need to draw a state diagram for those classes.

General criteria

Try to keep the messages in order from left to right.

The message flow of an UML sequence diagram starts at the top left, and message B is in a lower position than message A, which means that message B is ordered later than message B. Because the western reading habit is from left to right, you should try to arrange classifiers (roles, classes, objects, and use cases) from left to right in the same way as describing message flows. You can see in figure 1 that the classifiers have been arranged in this way, and if the Seminar object is on the left side of the controller, the arrangement is not standard. Note that sometimes it is impossible for message flows to be arranged from left to right, such as when a pair of objects invokes operations with each other.

Layer the classifier

Layering is a general approach to object-oriented design. Generally speaking, systems are always organized into userinterface, process/controller, business, persistence, and system layers (Ambler2001). When the system is designed in this way, it usually strengthens the cooperation of the classifiers belonging to the same layer and reduces the coupling degree of the classifiers of different layers. So it makes sense to layer your sequence diagram in a similar way. In the case of this usage scenario, one hierarchical approach is to first indicate the human role, then the controller class that represents the logic of the context, then the userinterface class, then the business class, and then the related technology class, which encapsulates access to databases and system resources. Layering your sequence diagram in this way makes the sequence diagram easier to read and easier to find hierarchical logic problems. Figure 1 takes this approach.

Picture ⒈ a student registration.

Name the role with the same name as your use case diagram.

When you are modeling a usage scenario, your sequence diagram usually involves one or more roles. For consistency, the names of the roles displayed in the sequence diagram should be the same as those on the use case diagram.

Name the class with the same name as your class diagram. The classes in the UML sequence diagram are the same as the classes in the class diagram, so they should have the same name.

The name of a role can be the same as the name of the class.

In figure 1 you can see a role named student and a class named student. This makes sense because the two classifiers represent two different concepts, roles represent students in real life, and classes represent students in the business application you are building.

Contains a logical narrative description.

Figure 1 can be difficult to understand-- especially for people who are not familiar with reading UML sequence diagrams-- because it is very close to the actual source program. It is common to include a description of business logic in your model, especially when the sequence diagram describes a usage scenario, as seen on the left side of the diagram ⒉, which increases the understandability of the diagram, and Rosenberg and Scott (1999) point out that this also provides important information for tracking information between use cases and sequence diagrams.

Picture ⒉ online order payment.

Place human and organizational roles on the far left of the diagram.

For business applications, in most cases, the main role is a person or an organization. These roles are often the initiator of the situation and the reading focus of the UML sequence diagram, so they should be placed at the "visible beginning" of the model.

Place the role of the reaction system on the far right of the diagram.

The role of the response system is the system you interact with and should be placed on the far right of the diagram. Because in many business applications, these roles are often referred to as "backendentities", that is, systems that your system interacts with through access technologies, such as CAPIs, CORBAIDL, message queues, or webservice. In other words, put the back-end system in the location of the figure.

Place the system role on the far left of the diagram.

The pilot system role is the system that interacts with your system, and should be placed on the far left of the diagram according to the principle of trying to arrange messages and classifier layers from left to right.

Avoid modeling object Destruction

Although memory management is an important issue, especially when objects are destroyed at the appropriate time, many modelers are reluctant to model object destruction operations on UML sequence diagrams, but instead use an "X" symbol at the bottom of the activation bar (the vertical bar that represents the object's life cycle), or use a versioned message. Comparing figure 1 with figure 2, note that figure 1 introduces the destruction of objects, which does not bring obvious benefits, but messes up the layout of the diagram. Figure 2 does not indicate that the object is destroyed. Remember to follow the practice of Agile Modeling (AM) to simply describe the model.

The significance of this guide lies in two reasons, ∶ first of all, many languages have a technology called garbage collection to implement automatic memory management, such as Java and Smalltalk. Second, in languages where you need to explicitly manage memory, such as Cellular memory, your programmers generally know what to do and don't need the additional information in the model. Note that in real-time systems, memory management is usually a key issue, and you may need to model the destruction of objects.

After reading the above, do you have any further understanding of how to understand the UML sequence diagram? If you want to know more knowledge or related content, please follow the industry information channel, thank you for your support.

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.