Analysis of UML case modeling (1)

UML (Unified Modeling Language) is one of the most widely used modeling technologies in software development. By using UML, You can construct the Demand Model (Use Case Model) of the software system) static model, dynamic model, and architecture model. UML describes a system through graphics and text symbols. It is the standard language for Drawing Software blueprints. Mastering the UML modeling technology is one of the essential skills for an excellent software practitioner. More and more software enterprises need to have a certain degree of knowledge base and practical experience in UML.

As a beginner of UML, many people are also trying to use the diagrams in UML to describe a software system and construct a blueprint for a software system. However, when using UML, some people do not have a deep understanding of the role of these diagrams and some skills in the drawing process. I will continue to use several articles to help you learn UML faster and better, and rationally use UML in software projects to improve software development efficiency and standardize software development processes.

In this article, I will use the inventory management system to describe the first model in UML modeling-the construction of the demand model, that is, Case modeling, this includes how to draw a standardized use case diagram, how to write a concise and clear use case document, and how to construct a demand model for the software system through the use case diagram and use case document.

In UML, the demand model is also called the case model. It is mainly used to describe the functional requirements of the system, that is, the functions that can be implemented by the software, such as logon, registration, warehouse receiving, warehouse picking, viewing inventory reports, and adding employee information. General case modeling generally consists of two parts: drawing a use case diagram and compiling a use case document.

 

1. Draw a Use Case chart

A use case diagram is a relatively simple form in UML. It contains two main components: the performer and the use case ). The performer is also called a participant or role, and the use case is also called a use case or case. In the use case diagram, the performer uses a "villain" symbol, and the use case is represented by an "elliptical" symbol. Therefore, the use case diagram has another name "villain elliptical diagram ". The simplest example is shown below:

In this example, the "repository administrator" indicates the executor, and the "warehouse receiving" indicates a use case, which is a function of the system.

 

Executors are a type of thing that interacts directly with the system. executors mainly have the following three types:

(1) users who directly use the system, such as warehouse administrators and warehouse managers of an inventory management system, can perform warehouse receiving and warehouse picking operations through the system, the storage department manager can view various reports through the system, such as inventory reports and financial reports;

(2) Other systems related to the system. For example, if a payment operation is involved in the inventory management system, another software-payment system needs to be used. At this time, the payment system is one of the executors of inventory management;

(3) Automatic events, such as time and temperature. If the inventory management system requires a Data Summary operation to be executed at every night, the time will become the executor of the operation.

Identifying the executors of a system is the first step in case modeling. After identifying the executors of a system, you need to find the system's use cases, that is, functional requirements. A use case is a sequence of actions performed by the performer on the system. Each use case corresponds to a complete operation flow performed by the performer on the system. For example, in the inventory management system, the Warehouse administrator can log on to the system and perform operations such as warehouse receiving and warehouse picking. Here, login, warehouse receiving and warehouse picking are all use cases. They all correspond to a function provided by the system. The performer performs the corresponding work by executing the use case. The use case reflects the interaction process between executors and the software system. Therefore, it is too simple to use a simple "elliptical" to indicate that the use case is too simple. For each use case, you need to write a detailed use case document, the next section describes how to compile the use case document.

 

[Author: Liu Wei http://blog.csdn.net/lovelion]