Case Model Guide

Use case is a method used to describe system requirements. The process of describing system requirements using use cases is case modeling. The use case method was first proposed by Dr. IVA jackboson and was later integrated into the UML specification to become a standardized requirement expression system. The use of use cases has been promoted in the RUP. The entire RUP process is called "use-case driven, various types of development activities, including project management, analysis and design, testing, and implementation, all take system use cases as the main input artifacts. the use case model lays the foundation for system software development.

1. What is a use case?
Before introducing the use case method, let's take a look at the traditional requirement expression-"Software Requirement Specification" (specification ). The traditional software requirement specification basically uses a Function Decomposition Method to describe system functions. In this expression, system functions are decomposed into various system function modules, we describe the functions of the subdivided system modules to describe the functions of the entire system.

This method is used to describe system requirements. It is very easy to confuse requirements and design boundaries. Such expressions actually include some designs. This often leads to the confusion: To what extent should system requirements be detailed? One extreme is that the demand can be detailed in the outline design, because such a demand statement includes both external requirements and internal design. In the development process of some companies, this requirement is called "internal requirement", and the original requirement corresponding to the user is called "external requirement ".

Another disadvantage of the Function Decomposition Method is that this method separates the application environment of various system functions, starting with various functional items, it is hard to understand how these functions are associated to implement a complete system service. Therefore, in traditional SRS documents, we often need other chapters to describe the overall structure of the system and the associations between various parts, which makes the SRS requirement more like a design document.

1.1 participants and Use Cases
From the perspective of users, they do not want to understand the internal structure and design of the system. They are concerned with 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 consists of the following model elements:

• Participant)
  A participant is a person or other system that exists outside the defined system and interacts with the system. They represent the user or use environment of the system.
• Use Case)
  Use Cases are used to represent the services provided by the system. They define how the system is used by participants, it describes a conversation between a participant and the system to use a complete function provided by the system.
• Communication Association)
  Communication Association is used to indicate the correspondence between participants and use cases. It indicates the services (use cases) in the system used by the participants, or the services (Use Cases) provided by the system) which participants are using them.

The three model elements are described in UML.

Taking a bank ATM as an example, its main functions can be shown in the following example. The main user of an ATM is a bank customer. The customer mainly uses an ATM to query, withdraw, and transfer bank accounts.

Communication associations represent the relationship between participants and use cases. Arrows indicate which party is the active initiator of the conversation in this relationship, and arrows indicate the passive receiver of the conversation; if you do not want to emphasize the active/passive relationship in the dialog, you can use the associated solid line without arrows. The information flow between participants and use cases is not expressed by communication Association. This information flow exists by default (the use case itself describes the dialogue between participants and the system ), in addition, the information flow is bidirectional, which is irrelevant to the direction indicated by the communication correlation arrow.

1.2 Content of Use Cases
The use case diagram gives us a holistic understanding of the functions of the system. We can know which participants will interact with the system and what services the system provides for each participant. The use case describes the dialog between the participant and the system, but the details of the dialog are not described in the use case diagram, for each use case, we can use the event stream to describe the details of this conversation. For example, the "withdrawal" case in the ATM system can be expressed as follows using the event stream:

Withdrawal-basic event stream

1. the user inserts a credit card

2. Enter the password

3. Enter the withdrawal amount

4. Cash withdrawal

5. Exit the system and retrieve the credit card

However, this only describes one of the most smooth withdrawal cases. As a practical system, we must consider other possible situations, for example, the credit card is invalid, the password is incorrect, and the cash balance in the user account is insufficient. All the possible situations (including normal and abnormal ones) are called use cases (scenario ), A scenario is also called an instance of a use case ). In various scenarios of use cases, the most common scenario is described using basic flow. Other scenarios are described using alternative flow. For the "withdrawal" Use Case in the ATM system, we can obtain the following alternative streams:

Withdrawal-Alternate event stream

Alternative stream 1: You can select to exit at any step in the basic stream and go to step 5 of the Basic stream.

Stream 2: in step 1 of basic flow, the user inserts an invalid credit card. The system displays an error and exits the credit card. The use case ends.

Stream 3: in step 2 of basic flow, the user enters the wrong password. The system displays an error and prompts the user to re-enter the password and return to basic flow step 2. After three wrong passwords, the credit card is confiscated by the system and the use case ends.

...

By combining the basic stream with the alternative stream, you can clearly describe all possible scenarios of the use case. When describing the event stream of use cases, we should describe all possible scenarios as much as possible to ensure the completeness of requirements.

1.3 advantages of the Use Case Method
The use case method describes the functions of the system from the user's perspective (from the outside of 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 completes the functions it provides. The use case method first describes the external users (abstracted as actor) of the defined system, which interact with the defined system. For each participant, the use case method also describes the services (abstracted as use case) provided by the system for these participants, or how the system is used by these participants. Therefore, from the use case diagram, we can get a general impression of the defined system.

Compared with the traditional functional decomposition method, the use case method completely defines the functions of the system from the external, and completely separates the requirements from the 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 system design is mainly recorded and expressed by the object model. In addition, use cases define the use environment and context of system functions. Each use case describes a complete system service. The use case method is easier to understand than the traditional SRS. It can be used as an effective means for developers and users to communicate with each other based on system requirements.

In RUP, use cases are used as the basis of the entire software development process. Many types of development activities use cases as a major input component (artifact ), such as project management, analysis and design, and testing. Test the target system based on the use case. You can test a system service based on the environment and context described in the use case. You can design a test case based on each scenario of the use case (scenario, the test cases can be fully tested in various scenarios to ensure the completeness of the test.

2. Create a case model
The process of describing the functional requirements of the system using the use case method is case modeling. the use case model mainly includes the following two parts:

• Use case diagram)
  Determine the ing between the participants, use cases and the two contained in the system. The use case diagram describes an overview of system functions.
• Use Case Specification)
  Each use case should have a document corresponding to the use case specification, which describes the details of the use case.

In the process of case modeling, we recommend that you first find the participants, then determine the use cases related to each participant based on the participants, and then refine the use case conventions of each use case.

2.1 search for participants
A participant is a person or other system that exists outside the system and interacts with the system. In layman's terms, participants are the users we want to define the system. To find participants, you can start with the following questions:

• After the system is developed, who will use the system?
• Who do the system need to obtain data from or from other systems?
• Who will the system provide data for or other systems?
• Which other systems are associated with the system?
• Who maintains and manages the system?

These questions help us abstract the participants of the system. For the example of an ATM, answering these questions allows us to find more participants: the operator is responsible for maintaining and managing the ATM system. The ATM also needs to communicate with the background server to obtain information about the user account.

2.1.1 system boundaries determine participants

Participants are determined by the boundaries of the system. If the boundaries of the system we want to define are limited to the ATM itself, the backend server is an external system and can be abstracted as a participant.

If the system boundary we want to define is extended to the entire banking system, both the ATM and the backend server are part of the entire banking system. At this time, the backend server is no longer abstracted as a participant.

It is worth noting that some system components should not be abstracted as participants during case modeling. For example, in the ATM system, printers are only an integral part of the system, it should not be abstracted into an independent participant. In a MIS Management System, the database system often serves only as an integral part of the system and generally does not abstract it into a single participant.

2.1.2 special participant-system clock

Sometimes we need to perform some operations on a regular basis within the system, such as checking system resource usage and generating statistical reports on a regular basis. On the surface, these operations are not triggered by external persons or systems. How can we use case methods to express such functional requirements? In this case, a system clock or timer participant can be abstracted to trigger this type of scheduled operation. Logically, this participant should be understood as an external system that triggers the case conversation provided by the system.

2.2 determine Use Cases
After finding the participants, we can determine the system use cases based on the participants, mainly to see what services the system provides for each participant, or how the participants use the system. Start with the following questions (for each participant ):

• Why do participants use this system?
• Will participants create, modify, delete, access, and store data in the system? If so, how do participants complete these operations?
• Will participants notify the system of some external events?
• Will the system notify the participant of some internal events?

As described above, the use case diagram of the ATM system can be expressed as follows,

In the extraction process of use cases, you must note that use cases must be triggered by a leading role, that is, each use case should involve at least one leading role. If there is a use case that does not interact with the main character, you can consider incorporating it into other use cases; or check whether the participants corresponding to the use case are missed; if so, add the participant. On the contrary, each participant must also involve at least one use case. If any participant not associated with any use case exists, you should consider how the participant interacts with the system, A new use case is determined by the participant, or the participant is a redundant model element and should be deleted.

One of the main purposes of visual modeling is to enhance the communication between teams. The Use Case model must be easy to understand. Case modeling is often a process developed by a team. During the modeling process, system analysts must note that the names of participants and cases must comply with certain naming conventions, in this way, the entire use case model can conform to a certain style. For example, the name of a participant is generally a noun, and the name of a case is generally a verb-object phrase.

For the same system, different people may have different abstract results for participants and use cases, so they can get different use case models. We need to select an "Optimal" (or "better") result from multiple use case models. A good use case model should be easily understood by different stakeholders, different stakeholders should have the same understanding of the same case model.

2.3 description of Use Case conventions
Avoid the misunderstanding that the use case diagram composed of participants and use cases is the use case model. The use case diagram only roughly describes the various services that the system can provide, let us have a general understanding of the system functions. In addition, we also need to describe the detailed information of each example, which is included in 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. The Use Case specification of each use case should contain the following content:

• Brief Description)
  This section briefly introduces the functions and objectives of this use case.
• Flow of events)
  Including basic streams and alternative streams, event streams should represent all scenarios.
• Use Case (use-case scenario)
  This includes the success and failure scenarios. The scenarios are mainly composed of basic streams and alternative streams.
• Special requirements (special requirement)
  Describe the non-functional requirements (including performance, reliability, availability, and scalability) and design constraints related to this case (the operating system and development tools used ).
• Pre-condition)
  The status that the system must be in before executing the use case.
• 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 describe the event stream more clearly, you can also use the status chart, activity diagram, or sequence diagram to assist in the description. As long as the expression is concise and clear, you can paste the graphical display mode of the user interface and process, or other images in the use case. For example, the activity diagram helps to describe complex decision-making processes, and the state transition diagram helps to describe system behaviors related to the State. The sequence diagram is suitable for describing time-order message transmission.

2.3.1 basic stream

The basic stream describes the most normal scenario of this use case. In the basic stream, the system executes a series of activity steps to respond to the service request put forward by the participant. We recommend that you use the following format to describe the basic stream:

1) Each step must be numbered with numbers to clearly indicate the sequence of steps.

2) use a short title to summarize the main content of each step, so that readers can quickly understand the main steps of the case by browsing the title. In the early stages of case modeling, we only need to describe the title of the event stream step, so as not to fall into the details of the case description too early.

3) when the entire use case model is stable, we will describe the interaction between participants and the system in detail for each step. It is recommended to use a two-way (roundtrip) description method to ensure the integrity of the description, that is, each step needs to be described in two aspects: (1) what information the participant has submitted to the system; (2) what kind of response does the system have. For specific examples, see the appendix.

When describing the information exchange between participants and the system, it is necessary to point out the specific information transmitted back and forth. For example, it is not clear to indicate that only the participant has entered the customer information. It is better to say that the participant has entered the customer name and address. Generally, you can use a vocabulary to keep the complexity of the use case controllable. You can define customer information and other content in the vocabulary, so that the use case will not fall into too many details.

2.3.2 alternate stream

The alternative stream describes abnormal or occasional situations during case execution. The combination of the alternative stream and the basic stream should cover all possible scenarios of the case. When describing alternative streams, it should include the following elements:

1) starting point: Start from the event stream;

2) condition: under what conditions will this alternative stream be triggered;

3) Action: what actions the system will take in this alternative flow;

4) Recovery: After the alternative stream ends, how should the use case continue to be executed.

The description format of the alternative stream can be the same as that of the basic stream. You also need to number the stream and give the title an overview of its content. Before the number, You Can prefix it with a (alternative) it is different from the basic flow step.

2.3.3 Use Cases

In actual execution, use cases may occur in many different situations, which are called use case scenarios. It can also be said that the use case is an instance. We need to cover all use case scenarios when describing use cases, otherwise, the request may be omitted. In the use case protocol, the scenario description can be expressed by the combination of the basic stream and the alternative stream. The scenario can not only help us avoid missing requirements, but also help us in the future development work: developers must implement all scenarios and testers can design test cases according to the use case scenario.

2.3.4 SPECIAL REQUIREMENTS

Special requirements are usually non-functional requirements. They are proprietary to a use case, but are not suitable for being described in the event stream Text of the use case. Examples of special requirements include legal or regulatory requirements, application standards, and quality attributes of the built system (including availability, reliability, performance, or support requirements ). Other design constraints, such as the operating system and environment, and compatibility requirements, can also be recorded in this section.

It should be noted that what is recorded here is special requirements specific to this use case. For some global non-functional requirements and design constraints, they are not proprietary to this use case, they should be recorded in the supplemental statute.

2.3.5 pre-and post-Conditions

The preconditions are the system states that must exist before the execution of the use case. The latter is the group of States that the system may be in after the execution of the use case.

2.4 check case model
After the use case model is complete, you can check the use case model to see if there are any omissions or errors. You can perform the following checks:

• Completeness of functional requirements
  Whether the existing use case model fully describes the system functions is also a sign for us to determine whether the case modeling work is complete. If we find that other system functions are not recorded in the existing use case model, we need to abstract some new use cases to record these requirements, or summarize them into some existing use cases.
• Easy to understand Model
  The biggest advantage of the case model is that it should be easily understood by different stakeholders. Therefore, the main guiding principle of case modeling is its comprehensibility. This guiding principle determines the granularity, number, and complexity of the relationship between model elements.
• Inconsistency?
  The Use Case model of the system is completed by multiple system analysts, and the model itself is composed of Multiple artifacts, therefore, we should pay special attention to whether there are conflicts or conflicts between different artifacts before, to avoid inconsistency within the model. Inconsistency directly affects the accuracy of the requirement definition.
• Avoid ambiguity Semantics
  A good requirement definition should be unambiguous, that is, different people should have the same understanding of the same requirement. In the description of the use case specification, you should avoid the need to have vague definitions, that is, no ambiguity.

3. System Requirements
According to the furps + model, the system requirements are divided into the following categories in the RUP:

• Function (functionality)
• Availability)
• Reliability)
• Performance)
• Supportability)
• Design Constraints

All requirements except the first functional requirement are considered non-functional requirements.

3.1 requirement artifacts
The Use Case model is mainly used to describe the functional requirements of the system. Other documents are required to record other non-functional requirements. The following collection of requirement artifacts is defined in RUP.

• Case model: Record functional requirements
  • Use case diagram: describes the relationship between participants and use cases.
  • Use Case Conventions: Describe the details of each use case
• Supplementary Conventions: records global functional requirements, non-functional requirements, and design constraints.
• Glossary: records some System Requirements Related Terms

In practical applications, in addition to these artifacts, we can also flexibly choose other forms of documents to add instructions based on actual needs. Not all system requirements are described by the use case model. For example, in the compiler, it is difficult for us to use the use case method to express the method rules of the language it processes, in this case, it is more appropriate to use the traditional BNF paradigm. In the telecommunications software industry, many telecommunications standards are described in the SDL language, and we do not need to use UML to rewrite these standards (UML has such compatibility with SDL ), you only need to use the SDL-form telecommunications standard as one of the requirement artifacts and reference it in other artifacts. In short, we should not stick to the use case modeling form, but should use the advantages of various methods flexibly.

3.2 supplement the Statute
Supplement the statute to record system requirements that are not easily described in the use case model, including the following.

• Functionality
  Functional requirements are mainly described in the case model, but some requirements are not suitable for presentation in the case. Some functional requirements are global and applicable to all use cases, such as error handling and i18n support. We do not need to describe these functional requirements in all use cases, you only need to unify the description in the supplementary statute.
• Availability
  Record all availability-related requirements, such as the training time required by system users, and whether common availability standards such as Windows interface style should be included.
• Reliability
  Define various metrics related to system reliability, including:
  • Availability: Specifies the percentage of available time (xx. xx %). The number of hours when the system is in use, maintenance, or downgrade mode;
  • Average interval (MTBF): generally expressed as the number of hours, but can also be expressed as the number of days, number of months, or number of years;
  • Average repair time (MTTR): the time when the system can be paused after a fault occurs;
  • Precision: indicates the precision (resolution) and accuracy required by the system output (according to a known standard );
  • Highest error or defect rate: Generally, it is represented as Bugs/kloc (number of errors per thousands of lines of code) or bugs/function-point (number of errors per function point ).
• Performance
  Records various metrics related to system performance, including:
  • Response time to the transaction (average, longest );
  • Throughput (for example, the number of transactions processed per second );
  • Capacity (for example, the number of customers or transactions that the system can accommodate );
  • Downgrade mode (acceptable run mode when the system is downgraded in some form );
  • Resource Utilization: memory, disk, and communication.
• Supportability
  Define all requirements related to the system's support or maintainability, including coding standards, naming conventions, class libraries, how to maintain the system, and related maintenance tools.
• Design Constraints
  Design constraints represent design decisions that have been approved and must be followed, including software development processes, development tools, system architecture, programming languages, third-party component libraries, operating platforms and database systems.

3.3 vocabulary
A vocabulary is mainly used to define project-specific terms. It helps developers to have a unified understanding and use of the terms used in the project. It is also the basis for object abstraction in subsequent stages.

4. Adjust the use case model
In a general use case diagram, we only express the relationship between participants and use cases, that is, the communication relationship between them. In addition, we can also describe the generalization relationship between the participants and the participants, the include, extend, and generalization relationships between the use cases and the use cases. We use these relationships to adjust the existing use case model and extract some public information for reuse, making the use case model easier to maintain. However, be careful when using these relationships in applications. Generally, these relationships increase the number of Use Cases and relationships, thus increasing the complexity of the use case model. Generally, the use case model is adjusted only after the use case model is completed. Therefore, you do not need to rush to abstract the relationship between use cases at the initial stage of case modeling.

4.1 relationship between participants
There can be generalized relationships (or "inheritance" relationships) between participants ). For example, for permission control problems frequently encountered in Requirement Analysis (as shown in), general users can only use some general operations, while administrators also need to perform some system management work in addition to general operations, the operator can perform both regular operations and some configuration operations.

In this example, we will find that administrators and operators are both special users who have all the permissions of common users and their own unique permissions. Here, we can further abstract the relationships between common users, administrators, and operators into general relationships. administrators and operators can inherit all the features (including permissions) of common users ), they can also have their own unique features (such as operations and permissions ). This can significantly reduce the number of communication associations in the use case diagram, simplify the use case model, and make it easier to understand.

4.2 relationship between Use Cases
The use case describes the behaviors that are visible outside the system and is a complete service provided by the system for one or more participants. In principle, use cases are tied, and there is no subordination between them. However, from the perspective of ensuring the maintainability and consistency of the use case model, we can abstract the include, extend, and generalization relationships between use cases. All these relationships extract the public information from the existing use cases, and reuse the public information through different methods to reduce the workload of model maintenance.

4.2.1 include)

The include link is represented by applying the <include> constructor on the link, as shown in. The meaning of this parameter indicates that the basic Use Case (base) will be used to include the use case. Specifically, inserts the event stream containing the use case into the event stream of the basic use case.

The inclusion relation is expressed in uml1.3. In uml1.1, the equivalent semantic relation is expressed as use (uses), for example.

In the ATM, if you need to print a receipt to the customer for the query, withdrawal, and transfer cases, we can extract the part of the printed receipt, abstract into a separate use case "Print receipt", and the original query, cash withdrawal, transfer three examples will contain this use case. When you need to modify the print receipt part in the future, you only need to modify one use case instead of modifying each use case. This improves the maintainability of the use case model.

In the event stream of the basic Use Case, you only need to reference the included use case.

Query-basic event stream

1. the user inserts a credit card

2. Enter the password

3. SELECT query

4. View account balance

5. Include the use case "Print receipt"

6. Exit the system and retrieve the credit card

In this example, multiple use cases need to use the same behavior. We can separate the common behavior into a use case, and then let other use cases include this use case. This avoids repeated descriptions of the same behavior in multiple use cases, and prevents inconsistency in descriptions of the behavior in multiple use cases. To modify this public requirement, we only need to modify one use case to avoid inconsistency and repetitive work caused by modifying multiple use cases at the same time.

Sometimes, when an event in a use case flows through a complex process, we can abstract an event stream into an included use case to simplify the description of the use case. This is similar to encapsulating an algorithm of a program into a sub-process in a process design language, and then calling this sub-process from the main program.

4.2.2 extended (extend)

As shown in the extended relationship, there are at most named extension points defined in the basic Use Case (base). The extended relationship refers to the extension) under certain conditions, the event stream is inserted into the base based on the corresponding extension points. For the inclusion relationship, the event stream in the subuse case must be inserted into the basic use case, and there is only one insertion point. The extension relationship can determine whether to insert the event stream of the extension case into the basic case event stream based on certain conditions, and there can be multiple insertion points.

For example, for the telephone business, some value-added services such as call waiting and call transfer can be expanded on the basic call business ). The Use Case model of these businesses can be described as follows using the extended relationship.

In this example, call wait and call transfer are both extensions to basic call cases, but these two use cases are only available under certain conditions (for example, the response to founder is busy or the respondent has no response) to embed the event stream of the extended use case into the extended point of the Basic Call case, and reuse the event stream in the Basic Call case.

It is worth noting that the event stream of the extended use case can also be abstracted as the alternative stream of the basic use case, in the preceding example, call wait and call transfer can both be used as alternative flows for basic call cases. However, basic call cases are already very complex. Using extended relationships to abstract value-added services into separate use cases can avoid the complexity of basic use cases, in addition, some optional operations are independently encapsulated in other use cases.

4.2.3 Generalization)

When multiple use cases share a similar structure and behavior, we can abstract their commonalities into Parent use cases, and other use cases as subuse cases in a general relationship. In the general relationship of a use case, a sub-use case is a special form of the parent case. The sub-Use Case inherits all the structures, behaviors, and relationships of the parent case. Generalization is rarely used in practical applications. Special behaviors in subcases can be used as alternative streams in the parent case.

The following is an example of a general relationship between use cases. transaction execution is an abstraction of transactions. Both real estate transactions and securities transactions are special transactions.

An example of the event stream in the case generalization relationship is as follows:

4.3 adjust the use case model
After the use case model is built, we can view the use case model to see if it can further simplify the use case model, increase the degree of reuse, and increase the maintainability of the model. You can start with the following checkpoints:

• Are examples independent of each other? If the two use cases are always activated in the same order, you may need to combine them into a use case.
• Are there similar behavior or event streams between multiple use cases? If they exist, consider combining them into a use case.
• Have some of the use case event streams been constructed as another use case? If yes, you can include another use case.
• Should the event stream of one use case be inserted into the event stream of another use case? If yes, use the extended relationship (extend) with another use case to establish this model.

5. Complexity of the Management Case Model
Generally, for a small system, the use case model does not contain too many participants and use cases. A use case diagram can accommodate all participants, all participants and use cases can coexist in the same hierarchy. For complicated large and medium-sized systems, the participants and regular meetings in the case model are greatly increased. We need some methods to effectively manage the complexity caused by the increase in scale.

5.1 case packages
Package is the most commonly used mechanism for managing model complexity in UML. package is also the simplest semantic model element in UML. It is a container, the package can contain any other model elements (including other packages ). In the case model, we can use the constructors <Use Case> to expand the semantics of standard UML packages. This new package is called the use case package ), used to manage model elements in a case model.

We can classify participants and use cases based on their characteristics and place them under different use case packages. For example, for a large enterprise management information system, we can classify the participants and use cases under the use case packages of human resources, finance, procurement, sales, and customer service respectively. In this way, we divide the entire case model into two layers. At the first level, we can see that the system functions are divided into five parts in total, in the second round of Yi qiqiang shoyuan straight forward, blow and throw the United States and the United States? /P>

The number of case packages required for a case model depends on how you want to manage the complexity of the case model (including the number of participants and cases, and the relationship between them ). The packages in UML are actually similar to directories in the file system. When the number of files is small, no additional directories are required. If the number of files is large, multiple directories are required for classified management, different users of the same set of files will create different directory structures for management. The key is to ensure that each file under the directory structure is easy to access. The same principle exists in case modeling. How to Create case packages and the number of case packages depends on different systems and system analysts, but the entire case model should be easy to understand.

5.2 granularity of Use Cases
How many use cases does my system need? This is a problem that many people may have when using case modeling. Describe the same system. Different people will generate different use case models. For example, for common "maintenance user" cases in various systems, it contains operations such as adding users, modifying user information, and deleting users, these operations can be expressed as subflow In the event stream of this case ).

Maintenance user-basic event stream

The basic stream consists of three subevent streams:

1) Add User subevent streams
...

2) modify user subevent streams
...

3) delete user subevent streams
...

However, you can also abstract it into three use cases based on the specific operations in the case. The system requirements expressed by it are exactly the same as those of a single use case model.

How should we determine the granularity of use cases? At a technical seminar, someone asked Dr. Ivar Jacob boson how many use cases are required for a system? The answer from the master is 20. Of course, he means that it is better to control the scale of the case model to dozens of cases, which makes it easier to manage the complexity of the case model. When the number of use cases is roughly determined, we can easily determine the granularity of the use cases. For complex systems, we need to control the complexity at the case model level. Therefore, we can appropriately move the complexity to the inside of each case, that is, to make a case contain a large amount of required information. For a relatively simple system, we can expose the complexity to the model level appropriately, that is, we can break down complicated use cases into multiple use cases.

The granularity of use cases not only determines the complexity of the use case model, but also determines the internal complexity of each use case. We should properly grasp the complexity of each layer based on the specific situation of each system, and determine the size and number of use cases while ensuring the comprehensibility of the entire use case model as much as possible.

5.3 use case diagram
The main function of a use case diagram is to describe the relationship between participants and use cases. In a simple system, you only need to have a use case diagram to clearly describe all the relationships. Complex systems can have multiple use case diagrams. For example, each use case package can have an independent use case diagram to describe the relationship between all participants and use cases in the use case package.

In a case model, if there is a many-to-many relationship between the participants and the case, and the relationship between them is complex, if it is not clear to describe all the participants and use cases in the same use case diagram, we can create multiple use case diagrams to represent various relationships respectively.

If you want to emphasize the relationship between a participant and multiple use cases, you can take the participant as the center and express the relationship between the participant and multiple use cases in a use case diagram. In this example, we emphasize what services the participant uses.

If you want to emphasize the relationship between a use case and multiple participants, you can use the use case as the center to express the relationship between the use case and multiple participants in a use case diagram. In this use case diagram, we emphasize the participants involved in the regular use case, or the users of the system service indicated by the use case.

In short, you can create any number of Use Case Diagrams as needed during case modeling, and use different use cases to emphasize the different relationships between participants and use cases. But the most important thing is to consider the comprehensibility of the entire use case model. If you can use a use case diagram to clearly express the meaning, do not use the second one, because the more concise the model, the easier to understand.