Use Cases for a Unified Modeling Language (UML)

At present, in the internal version of "The Condor Heroes", Yang Guo and the little dragon girl have an unknown tacit understanding and romance, that is, the side-by-side villain they have drawn. Such a villain is part of the UML use case diagram and is called a participant.

2.1 use cases and Use Cases

Use Cases are the most important concepts in demand analysis. requirements represent the design features, features, and behaviors of a system, to describe a system requirement means to describe the contract between things outside the system and the system. The contract expresses what the system is expected to do.

Requirement Elicitation is the main body of the demand project. Its main task is to establish a model of the system to be developed, and use cases are good methods for establishing this model. The use case was first proposed by Dr. Ivar Jackboson and then integrated into the UML specification to become a standardized system for demand expression. As mentioned above, the entire RUP process is "case-driven". Various types of development activities include project management, analysis, design, testing, and implementation. Use Cases are the main input artifacts, the Use Case model lays the foundation for the entire system software development. The use case is recognized as the symbol of the second generation of object-oriented technology. It can be seen that its importance is extraordinary.

Let's first give a specific and simple use case diagram, that is, the "Library Management System" use case diagram, 2.1. The use case diagram mainly involves participants (also called roles and executors), use cases, and communication associations between them.

Figure 2.1 examples of the Library Management System

Participants

A participant is an external user, process, or other system that interacts with the system, subsystem, or category. Participants can be people, another computer system, or some processes that can run. In figure 2.1, "Reader" and "Administrator" are participants.

There can be a general relationship between participants. For example, in the library management system example diagram shown in figure 2.1, we can think that "Reader" is the generalization of "Student reader" and "instructor reader, "Student Readers" can also be embodied as "Undergraduate readers" and "graduate readers". Similarly, "Book Management Personnel" is also a generalization of "purchasers", "cataloguing personnel", and "borrowing personnel. Figure 2.2 shows the general relationship between participants.

Figure 2.2 General Relations of participants

Use Cases

Use Cases are externally visible system functions provided by the system and expressed by exchanging messages with participants. The purpose of a use case is to define a behavior sequence without revealing the internal structure of the system. It treats the system as a black box to express the behavior that the entire system can see to external users.

Given the characteristics of use cases, use cases are generally named as a group of dynamic nouns that can indicate the target. In 2.1, "borrow books", "Return books", and "manage books" are all nouns.

There can also be relations between use cases, such as inclusion, extension, and generalization:

(1) Inclusion relationship: A use case can simply contain the behaviors of other use cases and Use Case behaviors contained in it as part of its own behaviors. This is called an inclusion relationship.

(2) extended relationship: the extended relationship is the relationship from the extended case to the basic case. It shows how the behavior defined for the extended case is inserted into the behavior defined for the basic case. It is inserted in implicit form, that is, the extended use case is not displayed in the basic use case. You can use extended use cases in the following situations:

A. indicates that a part of the use case is an optional system action (in this way, you can separate the optional and mandatory actions in the model );

B. indicates the branch stream that is executed only under certain conditions (such as exceptions;

C. It indicates that there may be a group of behavior segments, one or more of which can be inserted at the extension points in the basic use case. The inserted behavior segments and Insertion Sequence depend on the interaction with the main character when executing the basic use case.

Figure 2.3 provides an example of an extended relationship. In the course of returning a book, the branch stream of the lost book will be compensated only when the exception (the reader loses the book) occurs.

Figure 2.3 extended relationship of Use Cases

(3) Generalization relationship: Use Cases can be specifically listed as one or more sub-use cases, which are called generalization of use cases. When a parent use case can be used, any child use case can also be used. For example, in Figure 2.4, ticket booking is an abstraction of telephone booking and online booking.

 

Figure 2.4 General Relationship of Use Cases

Communication Association

Communication associations are used to indicate the mappings between participants and use cases. They indicate the use cases in the system used by the participants (or the use cases provided by the system used by the participants ).

Communication associations are represented by arrows or solid wires. If the arrow is used, the arrow indicates the passive receiver of the conversation. If the active and passive relationships in the conversation are not emphasized, the associated solid line without the arrow can be used.

2.2 create case model

Knowing the concepts of Use Cases and Use Case Diagrams, we also need to know how to build a use case model, that is, how to find participants, use cases, and define use cases. Generally, the steps for creating a case model are as follows:

(1) determine who will use the system directly, that is, the participant (Actor). To discover the participants, we can try to ask the following questions:

A. WHO/What system is used?

B. WHO/what information is obtained from the system?

C. WHO/what information should be provided to the system?

D. WHO/what support and maintenance system?

E. Which other systems use this system?

F. Which department of the company uses the system?

...

(2) select one of the participants;

(3) define what the participant wants the system to do and everything the participant wants the system to do is a use case. To discover the use case, we can try to ask the following questions:

A. Why does the participant want to use this system?

B. Do participants need to create, save, change, move, or read system data? If so, why?

C. Should the participant notify the system of external events or changes?

D. Do the participants need to know specific events in the system?

...

(4) for each case, when the participants will use the system, what usually happens is the basic process of the case;

(5) describes the basic process of the case;

(6) Consider some variable situations and create them as extension cases;

(7) Review the descriptions of different use cases, identify the similarities among them, and extract the similarities as common use cases;

(8) Repeat steps 2-7 to find each use case.

The reference criteria for participants are as follows:

(1) Have you found all participants? That is to say, have you explained and modeled all the participants in the system environment?

(2) Does each participant involve at least one use case?

(3) Can you list at least two persons who can serve as specific participants?

(4) Are there similar system-related participants? If yes, you should merge them into one participant.

The reference criteria for case check are as follows:

(1) The introduction section of the case model provides a brief and clear overview of the purpose and functions of the system;

(2) All use cases have been determined, and these use cases jointly describe all necessary actions;

(3) All functional requirements must be mapped to at least one use case;

(4) the use case model does not include redundant behaviors. All use cases can be traced back to a functional requirement to prove its rationality.

The use case diagram roughly describes the various services that the system can provide. This gives us a general understanding of the functions of the system, we also need to describe the details of each use case, that is, the use case specification. The Use Case Model consists of the use case diagram and the detailed description of each use case-the use case specification. The Use Case specification template is provided in the RUP, including the following:

(1) Brief Description: briefly introduces the role and purpose of this case;

(2) Event stream (Flow of Event): includes basic streams and alternative streams. The Event stream should represent all scenarios;

(3) Use Case Scenario (Use-Case Scenario): includes the success and failure scenarios, which are mainly composed of the basic stream and the alternative stream;

(4) Special requirements (Special Requirement): Describe the non-functional requirements related to the case (including performance, reliability, availability and scalability) and design constraints (the operating system and development tools used );

(5) Pre-Condition: the state that the system must be in before the case is executed;

(6) Post-Condition: a group of states that the system may be in after the use case is executed.

The Use Case conventions are basically expressed in text. To better describe the event stream, you can also use a status chart, activity diagram, or sequence diagram to help describe the system behavior related to the status. The activity diagram helps describe the complex decision-making process, the sequence diagram is suitable for describing time-order-based message transmission ). In addition, as long as it is helpful for the concise and clear expression of the use case, We can paste the user interface, the graphical display mode of the process, and other graphics in the use case.