So, what is a Use Case? In the UML document, the definition of Use Case is: the definition and description of a coherent functional unit of a system or subsystem without showing the internal structure of a system or subsystem. A bit of a mouthful, right? In fact, Use Case is just a description of the system function, but a Use Case describes a part of the entire system function. This part must be a relatively complete functional process in logic. In the development process using UML, requirements are expressed using Use Case, the interface is designed with the assistance of Use Case, many classes are discovered based on Use Case, and test instances are generated based on Use Case, including the entire Development management and task allocation are also organized based on Use Case.

For different Actors, they need to use certain functions of the system differently. Therefore, when identifying and analyzing Use Case, we have to do it one by one for each Actor. For ToDo User, we can easily identify two Use Cases: Add Task and Remove Task. ToDo User actively uses the system functions described by these two Use Cases, so on our Use Case diagram, the relationship between ToDo User and these two Use Cases is represented by arrows emitted from ToDo User. For FileSystem, we identified the same two Use Cases, but this time the arrow points from Use Case to FileSystem, indicating that FileSystem is passive.

Use Case can be described in many ways. We can use natural language (English, Chinese, whatever you want), we can use formal language (Wow! How cool!), or we can use Various illustrations. In UML, two types of diagrams are usually used to describe Use Case, which are Sequence Diagram and Collaboration Diagram.

Use Case consists of the following elements:

Name

Brief description

Event flow

Relationship

Activity diagram and state diagram

Use Case diagram< /p>

Special requirements

Pre-conditions

Post-conditions 1.1 Participants and use cases From the user's point of view, they do not want to understand the internal structure and design of the system, they What is concerned is the services that the system can provide, that is, how the developed system will be used. This is the basic idea of ??the use case method. The use case model is mainly composed of the following model elements: Actor Participants refer to people or other systems that exist outside the defined system and interact with the system. They represent the users or usage environment of the system. Use case (Use Case) is used to represent the services provided by the system. It defines how the system is used by participants. It describes the interactions between participants and the system in order to use a complete function provided by the system. a conversation. Communication Association Communication Association is used to represent the correspondence between participants and use cases. It indicates which services (use cases) in the system are used by participants, or which services (use cases) are provided by the system. used by. Taking a bank automatic teller machine (ATM) as an example, its main functions can be represented by the following use case diagram. The main users of ATMs are bank customers, who mainly use automatic teller machines to conduct bank account inquiries, withdrawals and transfer transactions. Communication association represents the relationship between participants and use cases. The arrow indicates which party is the active initiator of the dialogue in this relationship, and the party pointed by the arrow is the passive recipient of the dialogue; if you do not want to emphasize the active and For passive relationships, you can use solid associated lines without arrows. The information flow between actors and use cases is not represented by communication associations. This information flow exists by default (the use case itself describes the dialogue between actors and the system), and the information flow is bidirectional. The direction of the communication association arrow is irrelevant.

1.2 Contents of use cases Use case diagrams give us an overall understanding of the functions of the system. We can know which participants will interact with the system and what each participant needs from the system. Such service. Use cases describe the dialogue between participants and the system, but the details of this dialogue are not expressed in the use case diagram. For each use case, we can use event flow to describe the details of this dialogue. For example, the withdrawal use case in the ATM system can be expressed as follows in the event flow:

1. The user inserts the bank card 2. Enters the password 3. Enters the withdrawal amount 4. Withdraws cash 5. Exits the system and gets it back Bank card, but this only describes the smoothest situation in the withdrawal use case. As a practical system, we must also consider various other situations that may occur, such as invalid bank card, wrong password input, cash in the user account The balance is not enough, etc. All these various situations that may occur (including normal and abnormal) are called the use case scenario (Scenario), and the scenario is also called the use case instance (Instance). Among the various scenarios of use cases, the most common scenario is described by Basic Flow, and other scenarios are described by Alternative Flow. For the withdrawal use case in the ATM system, we can get some alternative flows as follows:

Alternative flow one: The user can choose to exit at any step in the basic flow and go to step 5 of the basic flow.

Alternative flow two: In step 1 of the basic flow, the user inserts an invalid bank card, the system displays an error and exits the bank card, and the use case ends.

Alternative flow three: In step 2 of the basic flow, the user enters an incorrect password, the system displays an error and prompts the user to re-enter the password, and returns to step 2 of the basic flow; after entering the wrong password three times, the credit card is blocked. The system is confiscated and the use case ends. … Through the combination of basic flow and alternative flow, all possible scenarios of the use case can be clearly described. When we describe the event flow of a use case, we must describe all possible scenarios as much as possible to ensure the completeness of the requirements.

1.3 Advantages of the use case method The use case method describes the functions of the system entirely from the user's perspective (from outside the system). In the use case method, we regard the defined system as a black box, and we do not care about how the system performs the functions it provides. The use case method first describes the external users (abstracted as Actors) of the defined system who interact with the defined system; for each participant, the use case method also describes what kind of services the system provides for these participants. Service (abstracted as Use Case), or how the system is used by these participants. So from the use case diagram, we can get an overall impression of the system being defined. Compared with the traditional functional decomposition method, the use case method completely defines the function of the system from the outside, and it completely separates requirements from design. In the object-oriented analysis and design method, the use case model is mainly used to express the functional requirements of the system, and the design of the system is mainly recorded and expressed by the object model. In addition, use cases define the usage environment and context of system functions. Each use case describes a complete system service. The use case method is easier to understand by users than traditional SRS, and it can be used as an effective means of communicating system requirements between developers and users. In RUP, use cases are used as the basis of the entire software development process. Many types of development activities use use cases as a main input artifact (Artifact), such as project management, analysis and design, testing, etc. To test the target system according to the use case, a system service can be completely tested according to the environment and context described in the use case. Test cases can be designed according to each scenario (Scenario) of the use case. Various scenarios of the use case can be completely tested. Ensure the completeness of testing. Ivar Jacobson began writing usage scenarios in 1967 when he defined the architecture of the Ericsson AX system.

In the mid-1980s, Jacobson spent a lot of energy thinking about the working methods of the past ten years.

He coined the term anvendningsfall, which roughly means "situation of usage" or usage case. But when it was published in English, he found that "useage case" did not make sense in English, so he wrote use case "use case". A use case is a short article

A use case can be a scene, including actions and interactions.

A use case can be a set of scenarios that describe behavior in different scenarios. This writing format can describe variant behaviors at any time, such as black box requirements, business processes, and system design specifications.

No system design in the use case

No interface design in the use case

No feature list in the use case

No feature list in the use case Test

The use case should describe the behavioral requirements

The main scenario of the use case should not exceed nine steps. Subgoals and removal design instructions can be obtained at the appropriate level.

The greatest value of a use case lies not in the main scenario, but in the alternative behaviors. The main scene may only take up a quarter to a tenth of the length of the example. Use Case has a basic event flow (can be called an ideal path) and multiple exception flows, including:

Basic changes

Special cases

Handling error situations The exception event flow Use Case specification should include the following:

Function description

Availability

Reliability

Performance

Supportability

Design constraints trying to determine the size of a Use Case is an interesting topic. One way to deal with this is to relate the size of the Use Case to its intent and scope. On a really big scale, a Use Case doesn't deal with that much in one system, but these systems are all used in the same business area, called a Business Use Case, which treats the entire company as a black box and Actors about A statement of company goals. These Business Use Case scenarios do not allow for assumptions about any internal company structure; a customer would place an order with the company rather than the customer service department.

For system development, the scope of Use Case is limited to a single system. This is the most common form of Use Cases. We call it System Use Case, which treats the entire system as a black box. , which does not specify any internal structure and is limited only to a linguistic description of the problem domain.

Another scope of Use Cases is the design of subsystems and internal components of the system, called Implementation Use Cases. It treats the component as a black box, and these Actors are the members that distinguish it. For example: Implementation Use Cases may be used to describe the requirements for the email component in the application system.

Given these categories, the topic of use case sizing becomes easier, designing the scope of these items to adjust the overall size. To help system designers, each Use Case describes only a single thread of behavior without large branches. Against this rule, Use Case often seems inaccurate or vague, and it is difficult to use as a resource and reference for test instructions. The advantage of using Cases is that some plots can be described in different degrees of formalized text. Each plot involves a single path in Use Cases, the details of which are groups of conditions.

Irregular text descriptions can also be used, but they are difficult to follow when there are many conditions and possible failures. An informal narrative style is also very useful when initially trying to understand the requirements. However, as the use cases progress, it is useful to use a more formal mechanism to describe the use cases.

The following is a rough outline of the customer's "order" for Use Case:

"Identify the customer, find out what items are needed and are still in the warehouse, and check whether the customer's credit is sufficient Using the "

structured narrative format has proven to be very effective. What this format does is describe the actors in each plot: the target sentences describe the sequence.

In this sequence, each actor:goal statement pair assumes that the previous goal was successful. Here is a simple example:

Use Cases assume that the system we are designing is a single In a black box, no internal structure is recorded at all, and it is considered to be the purpose of a plot and correspond to a single actor. These Use Cases do not indicate anything about the internals of the system, but only indicate what goals the system will achieve and what (people or other systems) will operate and be responsible for it. Use Cases has been used more and more widely. Compared with other requirement capture techniques, the reasons for its success are:

1 Use Cases treats the system as a black box

2 Use Case makes it easier to see implementation decisions in the requirements

The last point is a complement to the first point. A Use Case does not specify any of the internal structure of the system related to these requirements, so , if this Use Case states submitting changes to the order database, displaying results to a Web page, etc., then the internal structure is obvious and creates potential constraints on the design.

The reason why these requirements do not specify internal structure is that the specified internal structure imposes additional constraints on the designer. Without these constraints, the designer is more free to build a system that correctly implements objectively observable behavior. system, and there is the possibility of a breakthrough solution. Here is the graphical notation description of Use Cases. A single Stick-Man symbol in UML marks the actor (Actor), and the use case is marked with an ellipse. Figures such as these are for you who want to see the big picture of how Use Cases are related and get the system. A general description of the context is very important.

Use Cases diagrams do not show different scenarios, their intention is to show the relationship between characters and Use Cases. Therefore, Use Cases diagrams need to be supplemented with structured narrative text. UML provides some optional diagrams to display different scenarios. These conventional diagrams include interaction diagrams, activity diagrams, sequence diagrams, state diagrams, etc. (this article will not discuss these diagrams for the time being). The main disadvantage of using these diagrams is that they are not as dense as text, but they can be used to give the overall feel of the Use Case. Does every Use Case include at least one actor?

Is each Use Case independent of other Use Cases?

Does each Use Case have a simple behavior or event flow?

Whether each Use Case has a unique, intuitive, and extensible name so that it will not be confused later.

Whether it is easy for users to understand the name and description of the Use Case. The Use Case model shows the Use Cases and Actors in the system and their interrelationships. The evaluation criteria are:

Is the Use Case model understandable?

Whether we can have a clear concept of system functions through studying the Use Case model.

Are all actors defined? Are all functional requirements met?

Use Case whether the model has redundant behavior.

Whether the division from model to Use Case package is appropriate. Because of its simple graphical symbols and easy-to-understand natural language instructions, Use Case has become an increasingly popular technology in the field of documentation systems and software requirements. Use Cases are extremely attractive to development teams, even if the team members have no experience with formal requirements documents, but their simplicity can be deceptive. Even if the project team has no trouble getting started using Use Cases, when they apply it to the larger Many of the same problems often arise when working on projects.

1 Ten major misunderstandings in using use cases

1. The system boundary is not defined or changes frequently;

2. Define Use Case from a system perspective rather than an actor perspective;

3. Actor names are inconsistent;

4. Use Case has too many definitions;

5. The relationship between Use Case and actor is as intricate as a spider web;

6. The description of Use Case is too long;

7. The description of Use Case is unclear;

8. Use Case does not correctly describe functional requirements;

9. Users cannot understand Use Case;

10. Use Case cannot be ended normally.

2 How to avoid the above problems

Clearly determine the boundary of the system.

To put it simply, the boundary of the system is like a labeled box, actor Outside the box, while Use Case is inside the box. What exactly is this box we call a system? A computer system? An application system? Or a complete business? …Use Case can be used to reasonably describe any system. But it can only be used to describe one system at a time. If actors and Use Cases are properly defined in one system, errors will occur if they are used in a different system.

Use standard templates to write Use Case specifications

Use Case graphical notations have been standardized and made part of the Object Management Group's UML, but natural language Use Case specifications have not yet been standardized. In order to successfully write Use Case instructions, we need a standard template to ensure the consistency of Use Cases.

Focus on the true purpose of the actor and name the Use Case from the actor's point of view rather than the system's point of view

The most significant difference between Use Case-oriented requirements and traditional functional system requirements From the actor perspective, the system exists because actors want to achieve certain goals through the system. Actors interact with the system to achieve their goals. We define these interactions as Use Case.

Don’t confuse Use Case specifications with user interface design

There is a very popular view now: Since Use Case is the interaction between actors and the system, all users It is a good idea to put the interface design diagram in the Use Case manual. At first glance, this is indeed useful because it represents the interaction between actors/systems described in the specification in the form of a diagram, which is very intuitive. But the negative effects of this far outweigh its benefits. The user interface design may change over time. We should not let the system requirements depend on the user interface design. On the contrary, the user interface design should meet the Use Case requirements. If we place the user interface design in a use case specification, when the requirements need to be recognized and baselined, it is natural that these design elements may still be changing, which makes the user interface design incomplete and incorrect. and/or inconsistent.

Placing the user interface design in the Use Case specification also presents another problem. In order to establish one-to-one communication between Use Cases and interfaces, we will choose Use Case blocks that reflect the user interface. Instead of using Use Case blocks that reflect user goals, in order to express a complete user goal, we use interactive Use Case relationships to connect different user interface-based Use Cases. As a result, in the Use Case model, we get A diagram of relationships that resembles a spider web. In fact, this picture is a user interface description diagram. Although it is an important part of the system document, it belongs to the user interface design document, not the Use Case requirements document.

Achieve loose coupling between user interface and Use Case interaction

Loose coupling is more appropriate. Low-fidelity user interface diagrams help understand Use Case, but be careful Don't overdo it by linking basic interactions to user interface mechanics; the user interface is likely to change. In the functional specification, pay attention to what the actor does (such as submitting a request) rather than how the interaction is completed (such as double-clicking the submit button).

Do not establish communication between the Use Case and the user interface

Attempting to establish communication between the Use Case and the user interface may result in potentially incorrect functional operation. Use Cases are associated not only with actors that only have access to an interface, but also with actors that can update that interface (which may be exception flows), resulting in incorrect functionality. We should split Use Cases based on actual user goals and functional operations, rather than combining Use Cases based on user interfaces. Only in this way can we get the correct Use Case model.

Reviewing the Use Case model and Use Case specification, if you cannot prevent all misunderstandings, you should recognize the problem and determine the problem as early as possible

This point of view is not new, regarding code inspection The classic algorithm has been around for about 25 years, but how to apply it to Use Case? First, review the Use Case model and review the simple description of Use Case (Use Case name, goal, brief description). This work should be performed as early as possible while sketching, and before writing the detailed Use Case specification. Next is to review the Use Case sketch to ensure that the drawing is correct and that the detailed Use Case instructions are complete. Finally, there is a formal review of the final Use Case diagram and Use Case instructions.

We found that this three-stage review is more effective than a single Big Bang review. Many substantive problems in the Use Case diagram can be discovered before we spend a lot of time writing instructions. This approach reduces the duplication of work that needs to be done when requirements change. There is no connection between the main actor (Actor) and the Use Case

In some cases, there is no connection between the actor (Actor) who takes the value from the Use Case and the actor (Actor) who actively participates in this Use Case. There is no clear link. For example: the financial manager can become the actor of "invoice confirmation", but he may not be the one who creates the invoice. This is not a problem, the Use Case is still correct, it illustrates the relationship between the actor's value and the initialization that occurs outside the scope of the Use Case of the designed system. The primary actor is useful because this person plays the role of the person you need to talk to when describing the Use Case.

Plot steps do not need to be consecutive

The order of steps in a plot is fine, there are mechanisms to highlight possible parallel steps. Activity diagrams are the preferred mechanism in UML. By informally looking at the plot of a Use Case you can notice possible parallel steps; you can look at some adjacent steps within the Use Case; you can also have the same actor (Actor) for the steps. Responsible. In the example we gave before, the confirmed quantity and confirmed credit amount may be parallel. Sometimes it is useful to mark these possible parallel steps in the Use Case documentation.

Sizing of Use Cases

There is an obvious danger when starting to make Use Cases that it will either have many steps or very few. If there are more than 15 steps in the Use Case, it may contain some implementation details. If it has very few steps then check if its goal is to reach a single thread of activity without many branches.

Fewer human actors (Actors)

If the Use Case has fewer human actors and most of the actors are other systems, the usual approach is to modify the Use Case. Looking for events that the system must react to or recognize is better than meeting these actors.

Requirements Capture and System Complexity

In summary, these plots capture the simultaneous actors of system complexity: the target statement pair allows large systems to be specified in a relatively compressed format. The function of the Use Case format is that users and developers can identify actors and then confirm the goals that these actors' job responsibilities correspond to (or do not correspond to), instead of a large and difficult to read functional specification.

Only in this way, users and developers will be interested enough to study the details of those plots.

The system not only has the functional requirements it deserves

Some Use Cases do not capture all objective requirements, but only those functional requirements for how the system is used. However, there are still many aspects of demand that need to be captured. Some of the non-functional requirements are so related that they can also belong to individual Use Cases, such as performance requirements and system capacity requirements. Others, which are not related but need to be captured separately, are the following requirements:

System scope

System user goals

User interface prototype

· General rules

· Constraints

· Algorithm

Comparison of requirements during runtime and establishment period

An important factor to remember is that the system's sponsors are larger than the user community. There are many risk holders in the system, and Use Cases only capture the needs of some of them. Specifically, Use Cases only capture the needs of the system during runtime and ignore the needs of the risk holders as the system development organization. The development organization most Of interest is the description of the requirements during the establishment period.

Run-time requirements include: system scope, user organization's expectations and goals for the product, Use Cases, and other non-functional requirements.

Establishment period requirements include: reduced development costs, less change processing, and reuse of existing components.

The requirements during the establishment period can be partially grasped by Use Cases. But many aspects need to be handled by the development organization.

· Project Scope and Objectives: What the project must deliver. (The difference from system-wide is that it commits things for all projects)

· Growth and change requests: These can be captured as "Change Cases" in the regular Use Cases format

< p>· Constraints of the development leader: including standards, habits, tools, quality metrics, quality assurance principles, and quality assurance habits. Use Cases are first used for systems that need to respond to objective events. They can be used in an environment that provides a clear actor with easily understood goals. Use Cases cannot be used when the result is undefinable or unclear. This means that if the success or failure of the goal cannot be clearly defined, then Use Cases cannot be used to capture requirements.

However, when it comes to this, most object methods now use Use Cases. Because Use Cases have proven to be a very effective mechanism for capturing requirements. Use Case is a function block provided by the system. In other words, Use Case demonstrates how people use the system. Observing the system through Use Case can separate the system implementation from the system goals, which helps to understand the most important part-meeting user requirements and expectations without being immersed in implementation details. Through Use Case, users can see the functions provided by the system, first determine the scope of the system and then carry out in-depth project work.