Nature of Use Cases

 Many people may feel familiar with the use cases in UML. If you ask a question about the use case, many answers are an elliptic in the use case diagram. Is the use case just an elliptic in the example diagram? Of course not. What is the nature of the use case?

1. Development History of Use Cases

In order to understand the nature of the use case, we should first understand the development history of the use case technology. The concept of use case in UML is that Ivar Jacob, the father of UML60Proposal. Later, Alistair Cockburn learned the use cases from Ivar Jacob, inherited and developed the use cases based on his own practices, and proposed a "target-based use case ". When UML is formed, the use case UML is incorporated into the UML as an important part.Use Cases are considered to be signs of the second generation of object-oriented technology.

2. Nature of Use Cases
The nature of use cases is notUMLIt is an elliptical symbol in the system. It is used to describe the contract between various related personnel about the system's behavior, use text to express the functional requirements of the system. InUMLIn order to visualize the use of an elliptic representation, the specific content of the use case is expressed by using the use case template.Case technology is the most profound, accurate, and effective way to describe system functional requirements so far.

The Use Case technology has the following features:A use case is a half-shaped method. Instead of a formal language, it uses a natural language to describe a requirement. However, it explicitly puts forwardConcepts of roles and use cases, rules for communicating roles and use cases, and the main content of the use case template.Strict structures and forms will harden and useless requirements,There is no need for structure and form, and it is not easy to communicate. This semi-formal structure enables people to make full use of their creativity and enables end users of the system to easily read;In each use case and all description layers, the system handles errors. Most of the complexity of the system is to handle errors. In this way, relevant problems can be detected during the demand analysis phase for analysis, rather than later stages. This is the most profound point in the process of using use cases. When writing requirements, we only describe the correct user requirements and seldom mention errors;Use Cases provide the skeleton on which other project information can be processed, so as to implement case-driven.

3. Use Cases and requirements
Many people use cases to describe the requirements, which leads to the question about the relationship between the use cases and requirements. Use Cases are requirements, but not all requirements of the system. Use Cases describe only functional requirements. Do not try to express all requirements in the form of use cases. Some people think that use cases can represent all system requirements, so they useUMLTo indicate the requirements that are actually difficult to express using use cases. This is wrong.Use Case analysis requirements have the following features:

1.Use Cases describe the information in the system from the perspective of using the system, that is, viewing the functions of the system from outside the system, without considering the specific implementation methods of this function within the system.

2.Use Cases describe some of the user's possible requirements and correspond to a specific user goal. Use Cases can facilitate communication with the user and understand the correct requirements, it can also be used to divide the boundaries between the system and external entities. It is the starting point of object-oriented system design and the source of classes, objects, and operations.

3.Use Cases are dynamic descriptions of system behavior.

4. Case-driven
Many people may have heard of such words as data-driven and case-driven. Why use UML?Is it case-driven for software development? Because use cases represent the contract between various related personnel in the system regarding system behavior, the development of a software starts from analyzing these tasks. The software development process is divided into requirements analysis, design, implementation, testing, and other stages. The Use Cases bind all of these together, the results of case analysis also provide a basis for predicting the development time and budget of the system, ensuring the smooth development of the project. In summary, software development is case-driven.

5. Use Case Template
The use case diagram is a simple visual description of the system. We also need to describe the use case in detail. To clearly describe the use case, we need a use case template, but so far there is no unified use case template. The content of the use case template generally includes: Brief description, pre-condition, post-condition, basic event stream, and alternative event stream.
Brief description: a brief description of the role and purpose of the use case.
Prerequisites: conditions that must be met or in the system before the use case is executed.
Post condition: the status of the system after the use case is executed.
Basic event stream: describes the basic process of this case. It refers to what happens when every process is "normal". There is no alternative stream, but only the most likely event stream.
Alternative event stream: indicates that this action or process is optional or optional, and does not always need to be executed.

The following is an example of a use case template:

Use Case:<No.> <Name>

Feature Information:

Purpose of the use case in the system (description of the use case objective)

Scope (which system is currently under consideration)

Level (summary task/Primary task/Sub-function)

Prerequisites (the status of the system Appliances Before the use case execution)

Successful successor condition (status that should be obtained after successful execution of the Use Case)

Failure successor condition (the status of the target is not completed in the Use Case)

Primary Role (the primary role associated with the Use Case)

Trigger (the system action to start the use case)

Main steps:

<Step No.> <Action Description>

Extension:

<Step number for change> <Condition>:<Action or another use case>

Variation:

<Step or change ID> <Variation list>

Related information: (optional)

Priority (this case is critical to the system organization)

Performance Objective (the execution time of this case is consumed)

Frequency (the frequency of execution of this case)

Subordinate use cases: (optional)

Subordinate use cases:

Contact channels with primary roles (including interactive, static files, databases, etc)

Public question: (optional)

List unsolved issues about this case