Sinsing interpretation of Use case diagrams in UML modeling

First, the use case diagram concept

To understand the use cases diagram, first understand the use cases. What is a use case, in short, a description of the system's function without revealing the internal structure of the system when determining the project's requirements, but one case describes a part of the entire system function, which must logically be a relatively complete functional flow.

Use case diagram is one of the UML use case modeling, and also the basis of UML modeling, which is mainly used to describe the function demand and behavior of the user or the internal system. Flexible use case diagrams allow you to articulate the meaning of a description's needs or behavior.

A use case diagram is a function of the system from the outside of the system, and it does not describe the specific implementation of the functionality within the system, enabling the user to understand how to use these elements and to enable the developer to implement them. Use cases and participants in a use case diagram are located inside and outside the system.

A use case diagram is a model diagram of the system functionality that is known to the external user of the actor, and it presents the participants and some use cases, as well as the relationships between them, primarily for modeling the functions of the system, subsystem, and the latter class.

Use case diagram Warriors how to relate to each other between use cases and with use case participants. Use case diagrams are used to visualize the behavior of systems, subsystems, or classes, enabling users to understand how to use these elements and to enable developers to implement them.

Use case diagrams separate the users in the system from the properties and work of their working state, and facilitate modeling to prevent repetitive and redundant classes of functions. The use case diagram defines the functional requirements of the system, which is the system function from the outside of the system, and does not describe the specific implementation of the function within the system .

Second, use case-driven

In a real software project, the functionality that a software implements is obtained through use cases. Then all the analysis, design, implementation, testing are driven by use cases, that is, to achieve the use case as the goal, which is called the use case driver.

The use case-driven principle tells us that if we want to solve the problem area we need to sum up a reasonable abstract angle (use case), describe the possible specific scenarios for these use cases, and find out the things, rules and behaviors of these scenarios.

The requirements are expressed using use cases, and the interface is designed with the help of case, and many classes are found based on the use case, and the test instance is generated based on the use cases, including the management and assignment of the entire development, and is organized according to use cases.

Therefore, if an engineering use case drawing is not good, then the analysis, design, implementation, and testing will be affected to varying degrees, and the areas of our research problems will be limited.

Third, the level of the use case diagram

A use case diagram can be divided into three levels:

(1) Overview level: A description of the overall function

(2) User level: The system functions are divided into different function modules

(3) Sub-functional level: the requirements of the role, function modules more specific, more detailed division

The composition of the use case diagram

The use-case diagrams are composed of participants (actor), use cases, relationships, system boundaries

The concrete composition of the use case diagram

(1) Participant: The trigger of the use case, the trigger can be a user, or it can be an event agent. The so-called event agent is to give the system automatically set the timing function operation, when a certain time, the system will automatically perform the corresponding function.

(2) Use case: A description of the function of the system.

(3) Relationship: Describes a connection between a participant and a use case.

Six, the relationship

(1) Generalization: Starting, the same purpose, the implementation of different ways, using the hollow triangle, pointing to the public

(2) contains: Large use cases are divided into small use cases, small use cases are part of large use cases, using dashed arrows, large pointing small, that is, include

(3) Extension: Large use cases are divided into small use cases, but small use cases are not the basic composition of large use cases, using dashed arrows, small pointing large, that is, extend

Seventh, use case table

We can express it not only using use case diagrams, but also using use case tables. The Use case table does not belong to the UML specification, its function is to be able to elaborate the behavior of a use case in more detail, but the visual aspect is not as intuitive as use case diagram.

Here are a few table entries for the Use Case table:

(1) No.: Free fill

(2) Name: Use case name

(3) Active Person: User or role

(4) Priority: Free programming, can also use high school low this way to express

(5) Description: Simply describe the use case and focus on the purpose of the activity

(6) Preconditions: Lists the system state that must exist before performing the use case, such as what data must be entered, what permissions must be available, and so on. Be careful not to write preconditions that are almost always required for every use case, such as "Landing system", unless necessary.

(7) Basic flow: Describe the most commonly used process in normal situations, usually a textual description of the interaction between the active person and the system.

(8) End condition: Describes the use case results in the case of a normal end.

(9) Optional process 1-n: Description and other possible processes that differ from the basic process

(10) Exception Flow: Indicates the difference between the basic process and the error or other abnormal situation

(11) Description: Including other business specifications, etc.

Eighth, the basic format of the Use case table

(1) numbering with Arabic numerals

(2) Action shelf written by the active operator

(3) System operation empty two-pane write

Sinsing interpretation of Use case diagrams in UML modeling