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

This article is about the use of UML use case diagrams. The editor thinks it is very practical, so share it with you as a reference and follow the editor to have a look.

1.UML use case diagram

(1) use case Model (Usecasemodel)

For a long time, in object-oriented development and traditional software development, people understand requirements according to typical usage scenarios. However, these usage scenarios are informal, and although they are often used, it is difficult to establish formal documents. The use case model was first used by IvarJacobson in the development of AXE systems and was added to the OOSE and Objectory methods advocated by him. The use case method has attracted great attention in the object-oriented field. Since the publication of IvarJacobson's work in 1994, the concept of use case has been widely accepted in the object-oriented field and regarded as the symbol of the second generation of object-oriented technology.

The use case model describes the system functions understood by the external executor (Actor). The use case model is used in the requirements analysis stage, and its establishment is the result of repeated discussions between system developers and users, which shows the consensus reached by developers and users on the requirements specifications. First of all, it describes the functional requirements of the system to be developed; secondly, it regards the system as a black box and understands the system from the perspective of external executors; third, it drives the development work of all stages after requirements analysis, which not only ensures the realization of all functions of the system in the development process, but also is used to verify and test the developed system, thus affecting all stages of development work and each model of UML. In UML, a use case model is described by several use case diagrams, and the main elements of the use case diagram are use cases and implementers.

(2) use case (usecase)

In essence, a use case is a typical interaction between the user and the computer. Take word processing software as an example, "boldface some text" and "create an index" are two typical use cases. In UML, a use case is defined as a series of actions performed by the system, and the result of the action execution can be perceived by the designated executor.

In UML, the use case is represented as an ellipse. Figure 1 shows a UML use case diagram of a financial and trading system. Among them, "risk analysis", "transaction valuation", "trading", "setting boundaries", "transactions beyond boundaries", "evaluating trade" and "updating accounts" are all examples of use cases. In a nutshell, use cases have the following characteristics:

Use cases capture some user-visible requirements to achieve a specific user goal.

The use case is activated by the executor and provides the exact value to the executor.

The use case can be large or small, but it must be a complete description of the achievement of a specific user goal.

(3) executor (Actor)

The executor in the UML use case diagram refers to the role played by the user in the system. Its graphical representation is a villain. There are four executors in figure 1: trade managers, marketers, salespeople, and accounting systems. There are likely to be many marketers in some organizations, but as far as the system is concerned, they all play the same role and play the same role, so they are expressed as an executor. A user can also play multiple roles (executor). For example, a senior marketer can be either a trade manager or an ordinary marketer; a marketer can also be a salesperson. When dealing with the executor, it is important to consider its role, not the name of the person or job.

In figure 1, the line segment without arrows connects the executor with the use case, indicating the exchange of information between the two, called communication. The executor triggers the use case and exchanges information with the use case. A single executor can be associated with multiple use cases; in turn, a use case can be associated with multiple implementers. Different implementers have different roles for the same use case: they can take values from the use case or participate in the use case.

It should be noted that the executor is represented by a human-like figure in the use case diagram, although the executor is not necessarily a human being. For example, the executor may also be an external system that may need to obtain information from the current system and interact with the current system. In figure 1, we can see that the accounting system is an external system that needs to update the accounts.

Through practice, we find that executors are very useful in providing use cases. In the face of a large system, it is often difficult to make a list of use cases. At this point, you can make a list of executors, and then list its use cases for each executor, and the problem becomes much easier.

(4) use and extension (UseandExtend)

In figure 1, in addition to the connection between the executor and the use case, there are two other types of connections that represent the usage and extension relationships between the use cases. Usage and extension are two different forms of inheritance. Extended relationships can be used when one use case is similar to another, but does more. For example, in figure 1, the basic use case is "trade." Everything may be going well in the transaction, but there may also be factors that disrupt the smooth conduct of the transaction. One of them is the case that certain boundary values are exceeded. For example, a trade organization will specify the volume of trade for a particular customer, and instead of performing the regular actions provided by a given use case, some changes will be made. We can make changes in the "trade" use case. However, this will mix the use case with a lot of special judgment and logic, making the normal process obscure. Figure 1 places regular actions in the "trade" use case and unconventional actions in the "transaction beyond boundaries" use case, which is the essence of the extended relationship. Usage relationships can be used when there is a large chunk of similar action in several use cases and you do not want to describe the action repeatedly. For example, in reality, both risk analysis and transaction valuation need to evaluate trade, for which a separate use case, "evaluate trade", can be defined, while the "risk analysis" and "transaction valuation" use cases will use it.

Please note the similarities and differences between expansion and use. Both of them mean extracting those common behaviors from several use cases and putting them into a separate use case, which is used or extended by several other use cases. But the purpose of use and extension is different.

(5) acquisition of use case model in UML use case diagram

Use cases are used in almost any case. Use cases are used to capture requirements, plan, and control projects. The acquisition of use cases is one of the main tasks in the requirements analysis phase, and it is the first work to be done. Most use cases will be generated during the requirements analysis phase of the project, and more use cases will be found as the work progresses, which should be added to the existing use case set in a timely manner. Each use case in the use case set is a potential requirement.

a. Get executor

The first way to get a use case is to find out the executor of the system. The executor can be identified by the user's answers to some questions. The following questions can be used for reference:

Who uses the main functions of the system (primary users).

Who needs a system to support their daily work.

Who will maintain and manage to make the system work properly (assist the user).

What hardware does the system need to manipulate.

Which other systems the system needs to interact with, including other computer systems and other applications.

A person or thing that is interested in the results produced by the system.

b. Get use cases

Once you have acquired the executor, you can ask each executor a question to obtain the use case.

The following questions can be used for reference:

What functions does the executor require the system to provide (what does the executor need to do)?

What types of information the executor needs to read, generate, delete, modify, or store.

What are the system events that must be alerted to the executor? Or what are the events that the executor must remind the system? How do you represent these events as functions in a use case?

In order to fully describe the use case, it is also necessary to know whether some typical functions of the executor can be implemented automatically by the system.

There are also some issues that are not specific to the executor (that is, for the entire system):

What kind of input and output does the system need? Where does the input come from? Where does the output go?

The main problem with the current running system (perhaps some manual operations rather than computer systems)?

It should be noted that the two problems do not mean that there can be use cases without the executor, but the fashion of obtaining the use case does not know what the executor is. A use case must be associated with at least one executor. It is also important to note that different designers use use cases to different degrees. For example, IvarJacobson says he needs twenty use cases for a ten-person-year project. In a project of the same size, MartinFowler used more than a hundred use cases. We believe that any suitable use case can be used, and the process of determining the use case is a process of refining and summarizing the acquired use cases. For a ten-person-year project, twenty use cases seem to be too few, and more than 100 use cases are too many. Need to maintain a relative balance between the two.

Thank you for reading! This is the end of this article on "what is the use of UML use case diagram". I hope the above content can be of some help to you, so that you can learn more knowledge. if you think the article is good, you can share it for more people to see!

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.