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

Most people do not understand the knowledge points of this "UML requirements case Analysis" article, so the editor summarizes the following content, detailed content, clear steps, and has a certain reference value. I hope you can get something after reading this article. Let's take a look at this "UML requirements case Analysis" article.

Based on UML requirement analysis

Under the premise that the preliminary business requirements description has been formed, the requirements analysis based on UML can be roughly divided into the following steps:

(1) use use cases and use case diagrams to represent requirements. Obtain executors and scenarios from business requirements description; summarize, classify and abstract scenarios; form use cases; determine the relationship between executors and use cases, use cases and use case diagrams, and generate use case diagrams.

(2) the overall framework of the target software system is represented by package diagram and class diagram. Design the top-level architecture of the target software system according to domain knowledge, business requirement description and past experience; extract "key concepts" from the business requirement description to form a domain conceptual model; starting from the conceptual model and use cases, study the relationship between the main classes in the system and generate class diagrams.

The above two steps have no timing relationship, and they can be expanded in parallel, as shown in figure 5-3-1.

Figure 5-3-1 UML requirements analysis process

This section introduces the UML language mechanism involved in the above steps in turn, and illustrates the method of requirements analysis based on UML in each step with an example of "Family Security system".

Development scenario

Scenario refers to observing the function and external behavior of the target software system from the point of view of a single executor. This function is characterized by the interaction between the system and the user. Therefore, it can also be said that a scene is a set of specific actions that interact between the user and the system. Relative to the use case, the scenario is the instance of the use case, and the use case is the common abstraction of some kind of scenario.

A complete description of the scene should include the scene name, executor instance, pre-condition, event flow, and post-condition.

For example, the preliminary requirements description of the "home security system": the software of the "home security system" allows the user to configure the system during installation, monitor the sensor and exchange information with the user through the control panel.

Configuration actions include:

(1) specify the type and number of each sensor

(2) set the password for turning on and off the computer.

(3) specify the code of the alarm phone

(4) specify alarm delay and phone redial delay time (in seconds)

When the software system receives the data sent by the sensor, it determines whether there is an abnormal event. If so, the alarm phone number is dialed within the specified delay time, and the dialing operation will be repeated according to the redial delay until the phone is connected. The software system is then responsible for reporting the time, place, and nature of the abnormal event.

After power on, the software system is responsible for displaying the current working status, receiving and processing user instructions.

According to the above description, the system has "system configuration", "boot", "shutdown", "door and window monitoring", "smoke monitoring" and "reset" scenarios. The monitoring scenarios for doors and windows are described as follows:

Scene name: door and window monitoring.

Examples of participators: alarms, alarm calls, monitors and door and window monitors.

Pre-condition: the system is powered on.

Event flow:

(1) the door and window monitor detects the abnormal movement of the door or window and reports abnormal events to the software system.

(2) the software system starts the alarm and dials the alarm phone number.

(3) after the alarm call is connected, the software system broadcasts voice and reports the time, place and nature of the abnormal event (abnormal movement of doors and windows).

(4) the system displays the alarm time and current status on the display of the control panel (alarm: abnormal movement of doors and windows).

Post-condition: the system is in the "alarm" state.

According to the role of scenarios in the process of UML requirements analysis, it can be divided into the following types:

(1) actual scene. A description of the actual business process or its optimization process. The actual scenario is an important part of user requirements.

(2) imagine the scene. The analyst's description of the business process that has been improved or optimized after the target software system has been put into application. This scenario can be seen as a paper prototype and is mainly used to help analysts mine potential user requirements.

(3) evaluate the scene. A description of a business process whose primary purpose is to identify requirements or make recommendations for improvement. Evaluation scenarios can be instantiated after the use case is generated, so that users can evaluate or improve the use case.

(4) training scene. A business process description that explains the functions and external behavior of the system for developers and users.

Answers to the following questions are helpful for analysts to conduct UML requirements analysis to obtain scenarios:

(1) who are the executors of the target software system?

(2) what tasks does the executor want the system to perform?

(3) what information does the executor want to obtain? Who generated this information? By whom?

(4) what events does the executor need to notify the system? What external behavior does the system exhibit in response to these events?

(5) what events will be notified to the executor by the system?

In summary, the key to determining the executor and scenario is to understand the business domain and the preliminary requirements description document. The scenario will lead to a common understanding of the business process and the functional scope of the target software system by both developers and users. After the scene is determined, the use case can be formed by summarizing, classifying, merging and abstracting the scene.

The above is about the content of this article "UML demand case Analysis". I believe we all have a certain understanding. I hope the content shared by the editor will be helpful to you. If you want to know more related knowledge, please pay attention to 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.