Model Guide
Author: Junichi Fu Source: IBM http://www.csai.cn December 16, 2004
1. What is the case? Before the interpolation case method, we first look at the traditional demand expression - "Software Requirement Specification). The traditional software demand statute basically uses the functional decomposition to describe system functions, in which system functions are decomposed into each system function module, we reach a description by describing the function of the subdivision system module. The purpose of the entire system function. A typical software demand specification may have the following form:
This method is used to describe system requirements, which is very easy to confuse the demand and design, so that the representation already contains partial design. This often leads to such confusion: What extent should the system demand be in detail? One extreme is that the demand can be detailed to the profile, as such a demand represents both external demands and an internal design. In some companies' development processes, this demand is called "internal demand", and the original requirements corresponding to the user are called "external demand."
Another disadvantage of the functional decomposition method is that this method is divided into the application environment of each system function. From various function items, it is difficult to understand how these function items are interrelated to implement a completed system service. So in the traditional SRS document, we often need another chapter to describe the integration of the overall structure between the system and the interrelationships of each part, which makes the SRS demand is more like a design document.
1.1 Participants and Users From the user's point of view, they do not want to understand the internal structure and design of the system, what they care about is how the system can provide, which is how to be used, this The basic idea of using the case method. The use case model is mainly composed of the following model elements:
Participants (actor) participants are people or other systems externally defined outside the system and interact with the system, they represent the system's user or use environment. Use case use case to represent the service provided by the system, which defines how the system is used by participants, which is described in order to use the participant in order to use a complete function provided by the system. A dialogue. Communication Association Communication Association is used to represent the correspondence between participants and use cases, which means which services (use cases) in the system, or the services provided by the system (use case) are involved It is used.
The present three model elements are shown in the UML as shown below.
Taking the bank's automated billboard (ATM) as an example, its main function can be represented by the example drawings below. The main user of ATM is bank customers, and customers mainly use the automatic bill of money to conduct bank account queries, withdraws, and transfer transactions.
Communication associations represent the relationship between participants and use cases, arrows indicate which part is the initiator of the dialogue, the arrow is a passive recipient of the conversation; if you don't want to emphasize the initiative in the conversation Passive relationships, you can use an associated solid line without arrows. The information flow between the participant and the use case is not represented by the communication association, the information flow is default (the use case itself is described in the participant and the system), and the information flow is two-way, it There is no relationship with the direction referred to in communication associated arrows.
1.2 Contents of the use case The example map allows us to have a whole cognition for the system's function, we can know which participants will interact with the system, each participant needs the system what kind of service it provides. The use examples are conversations between participants and systems, but the details of this conversation are not expressed in the example diagram. For each case, we can describe the details of this dialog in the event stream. If the "withdrawal" in the ATM system can be expressed as follows: withdraw - basic event stream 1. User Insert Credit Card 2. Enter the password 3. Enter the withdrawal amount 4. Extract the cash 5. Exit the system, retrieve the system credit card
However, this will only describe the most smooth cases in the withdrawal case. As a practical system, we must also consider the possible various situations, such as credit card invalid, enter the password, and the cash balance in the user account is not enough. All of these may occur (including normal and abnormal) scenarios, Scenario, and scenes are also referred to as an instance of the use case (INSTANCE). In various scenarios of the use case, the most common scene is described in Basic Flow, and other scenarios are described by Alternative Flow. For "withdrawals" in the ATM system, we can get some alternative streams:
Withdrawal - alternative event stream
Alternative flow 1: Users can exit any one of the basic streams to the basic stream step 5.
Alternate flow: In the basic stream step 1, the user inserts an invalid credit card, the system displays an error and exits the credit card, and the use case ends.
Alternative flow 3: In the basic stream step 2, the user enters the error password, the system displays the error and prompts the user to re-enter the password, returned to the basic stream step 2; After entering the password error three times, the credit card is confiscated by the system, and the use case ends.
...
The various scenarios of the use case may occur clearly through the combination of basic streams and alternative flows. When we describe the exemption flow of the use case, we have to describe all possible scenes as much as possible to ensure the completeness of the demand.
1.3 Advantage of the use case method is completely the functionality of the system stands entirely on the user's perspective (from the outside of the system). In the use case method, we regard the defined system as a black box, we don't care about how the system does the features it provides. Using an example method first describes which external users (abstraction becoming an actor) of the defined system, these users interact with the defined system; for each participant, the use case method also describes what the system provides these participants? Services (abstract becoming use case), or how the system is used by these participants. So from the example of the example, we can get an overall impression on the defined system.
Compared to the traditional functional decomposition mode, the use case method is completely from the outside to define the functionality of the system, which is completely separated from the design and the design. In an object-oriented analysis 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 used by the object model. In addition, the use case defines the use environment of the system function and context, each with a complete system service. The use case method is more easier to be understood by the user than the traditional SRS, which can be used as an effective means for communicating with system requirements between developers and users.
In RUP, the use case is based on the basis of the entire software development process, many types of development activities use cases as a primary input workpiece, such as project management, analysis design, testing, etc. According to the use case, the target system is tested, and a system service can be completely tested according to the environment and context described in the use case, and the test case can be designed according to the various scenes of the use case, and various scenes of the use case can be used. Guarantee the completeness of the test. 2. Establishing a method of using the use case using the method of use cases to describe the functionality of the system is to model the model, the use case model mainly includes the following two parts:
With an example (Use Case Diagram) Determine the correspondence between the participants, the use cases, and the correspondence between the systems, and the example diagram is described with an overview of the system function. Use the case specification (USE Case Specification) should have an example of using an example of the decisions corresponding to the details of the details of the use case.
In the process of modeling, we recommend step gathering first to find the participant, and then determine the use case related to each participant according to the participants, and finally refine the use case regulation of each use case.
2.1 Searching for participants The so-called participants refer to people or other systems that externally outside the system and interact with the system. Popularly, participants is the user we have to define the system. Finding participants can start with the following questions:
After the system development is complete, what people will use this system? Who or other systems do you need to get data from other systems? Who or other systems will be provided to provide data? Which other systems will the system? Who is the system to maintain and manage?
These issues help us abstract the system's participants. For examples of the ATM machine, answering these questions allow us to find more participants: operators are responsible for maintaining and managing ATM machine systems, and the ATM machine also needs to communicate with the background server to obtain information about user accounts.
2.1.1 The system boundary determines the participant
Participants are determined by the boundaries of the system. If the boundary we have to define is limited to the ATM machine itself, the background server is an external system that can be abstracted as a participant.
If we want to define the system boundary to the entire banking system, both the ATM machine and the background server are part of the entire bank system, which is no longer abstraction to become a participant.
It is worth noting that do not use the example mode to make an abstraction as a participant, such as in the ATM machine system, the printer is only an integral part of the system, and it should not abstract it into an independent participant; In an MIS management system, the database system is often only an integral part of the system, generally not abstracting it into a participant.
2.1.2 Special Participants - System Clock
Sometimes we need to perform some operations within the system, such as detection system resource usage, regularly generate statistical reports, etc. From the surface, these operations are not triggered by external people or systems, how should I use this type of functional demand? In this case, we can abstract a system clock or timer participant that uses the participant to trigger this type of timing operation. From logically, this participant should be understood to be external to the system, which triggers the use case dialog provided by the system.
2.2 Determining the use case After finding the participant, we can determine the use case of the system according to the participants, mainly to see what kind of services are required to provide systems, or how participants use the system. Looking for use can be started from the following issues (for each participant):
Why do participants use this system? Does participants will create, modify, delete, access, and store data in the system? If so, how does the participant do these operations? Will participants notify the external event to the system? Will the system notify the participant in some events? As described above, the example example of the ATM system can be represented as follows.
During the extraction of the use case, it must be noted that the use case must be a activity that is triggered by a protagonist, i.e., each use case should be at least a protracant. If there is a use case that does not interact with the protagonist, it can be considered to be incorporated into other use cases; or check if the participant corresponding to the use case is missing, if so, make up the participant. Conversely, each participant must also involve at least one case, if it is found that there is a participant associated with any case, it should be considered how the participant is talking to the system, or determines a new one by the participant. Use case, or the participant is a redundant model element, it should be deleted.
One of the main purposes of visual modeling is to enhance team communication, and the use model model must be easy to understand. Use example modeling is often a team development process, and system analysts must pay attention to the name of participants and use cases in the modeling process. The entire use model model can meet a certain style. If the name of the participant is generally noun, the name of the case is generally a mobile philosophy.
For the same system, different people may have different abstractions for participants and use cases, thus obtaining different use models. We need to select a "best" (or "preferred" result in multiple use case models, a good use case model should be easily understood by different involvement, and different involved in the same use case The understanding of the model should be consistent.
2.3 Description Use Equal Regulatory should avoid such misunderstandings, considered by participants and use cases, use examples of the use case model, with example examples only describe the various services that the system can provide, allowing us to function for the system There is an overall understanding. In addition, we also need to describe the details of each have, including in the case of the case, the use case model is made up of the example of the example map and each of the usage examples - use case regions. A template for use in RUP is provided. The use case regions of each use case should contain the following:
Brief Description briefly introduces the role and purpose of this use case. Flow of Event includes basic streams and alternative flows, and event streams should indicate all scenes. The use case scenario includes a successful scene and failed scene, and the scene is mainly composed of basic streams and alternative flow. Special Requirement describes non-functional needs (including performance, reliability, availability, and scalability, etc.) related to this use case) and design constraints (operating systems, development tools, etc.). Pre-condition executive before the system must be in the state. Post-condition use case execution, the system may be in a set of states.
The use case regions are basically expressed by text, and the event stream can be selected for more clearly describing the event stream, and the state diagram, an active diagram, or sequence diagram can also be selected. As long as it contributes to the expression of expressions, the graphical display mode of the user interface and the process can be attached anywhere, or other graphics. If the activity map helps describe complex decision flows, status transfer graphs help to describe system behavior related to status, and sequence diagrams are adapted to describe time-based messaging.
2.3.1 Basic Flow
The basic stream describes the most normal scenario of this use case, and performs a series of activity steps in the basic stream system to respond to the service requests raised by the participant. We recommend using the following format to describe the basic stream:
(1) Each step requires the number number to clearly mark the order of the steps. (2) To summarize the main content of each step by browsing the title by browsing the title to quickly understand the main steps of the use case. In the early days of modeling model, we also need to describe the layer of the event stream step to avoid going out to the details described in the examples prematurely.
(3) After the entire use case model is basically stable, we will detail the interaction between participants and systems for each step. It is recommended to use a two-way (Roundtrip) method to ensure the integrity of the description, that is, each step needs to be described from the two aspects: (1) What information is submitted to the system; (2) What is the system? Sample response. For details, please refer to the appendix.
When describing the information between the participant and the system, the specific information passed back is required. For example, it is not clear enough to express the participant to entering the customer information, it is best to clearly say that the participant has entered the customer name and address. It is usually possible to keep the complexity of the vocabulary to maintain the content of the use case, and the customer information can be defined in the vocabulary, and the use case is not to fall into excessive details.
2.3.2 Alternative flow
Alternative flow is responsible for describing some of the abnormal or occasionally occurring during the execution of the use case, the combination of alternative flow and basic streams should be able to overwrite the scenario that may occur. When describing alternative flows, the following elements should be included:
(1) Starting point: Which step of the presentation stream is starting;
(2) Conditions: This will trigger the presentation current under what conditions;
(3) Action: What actions will be taken under this optional stream;
(4) Recovery: How should this use will continue to execute after the alternate stream ends.
The description format of the alternative stream can be consistent with the format of the basic stream, and it is also required to be numbered and the contents of its content are summarized, and the alphanuative A (AlternATIVE) can be applied to the basic flow steps.
2.3.3 A case scene
The use case will have a lot of different situations when actually executed, called the use case scene; it can also be said that the scene is an example of the use case. We will overwrite all the case scenes when describing the use case, otherwise it is possible to lead to the omission of demand . In the case of the case, the description of the scene can be represented by a combination of basic streams and alternative flows. Scene can help us prevent the omissions of demand, and can also help subsequent development work: developers must implement all scenarios, testers can design test cases based on the scenario in accordance with the example.
2.3.4 Special needs
Special demand is usually non-functional demand, which is proprietary, but is not suitable for explaining in the event stream text of the use case. Examples of special needs include legal or regulatory requirements, application standards, quality properties of the build system (including availability, reliability, performance or supportive requirements). In addition, other design constraints such as operating systems and environment, compatibility requirements, etc., can also be recorded in this section.
It should be noted that this record is a special requirement to which the use case is recorded; for some global non-functional needs and design constraints, they are not proprietary, and they should be recorded in the "Supplementary Statute".
2.3.5 Front and back conditions
The front condition is a system state that must be present before performing the use case, and the rear condition is a set of states that may be in the system after execution.
2.4 Checking the Case Model Use case model is completed, you can check the usage model to see if there is an omissit or error. It can be checked by the following aspects:
The complete existing use case model of functional requirements completely describes system functions, which is the flag we determine whether the model is used to end. If there is still a system feature that is not recorded in an existing usage model, then we need to abstract some new use cases to record these needs, or induct them in some existing cases. The biggest advantage of the model is easy to understand the use case model is that it should be readily understood by different involvement, so the most important guidelines for modeling is its understandability. The relationship between the particle size, number of models, and the model element should be determined by the guiding principle. Whether there is an inconsistency system is done by multiple system analysts, the model itself is also composed of multiple workpieces, so we must pay special attention to whether there is a place where there is a contradiction or conflict before and after different workpieces, avoiding models. Internal inconsistency. Inconsisons will directly affect the accuracy of demand definitions. Avoiding an unrestricted semantic demand definition should be ignorant, that is, different people should be consistent with the understanding of the same needs. In the description of the case, it should be avoided to define the need for ambiguity, that is, there is no meaning. 3. System requirements RUP divided system requirements into the following categories:
FunctionAlity Availability ("preformance) Contribution (Supportability) design constraints, etc.
In addition to other needs other than the first functional demand, it is non-functional demand.
3.1 The demand workpiece set Model is mainly used to describe the functional needs of the system, and other documents need to be used for other non-functionality. The following demand workpiece collection is defined in RUP.
Model model: record functional needs
Model Declaration Declaration between Participants and Use Examples: Describe the details of each use case, record some global functional requirements, non-functional requirements and design constraints: Record some system requirements related the term
In practical applications, in addition to these workpieces, we can also add other forms of documentation based on actual demand. Not all system requirements are suitable for use case models, such as compilers, we are difficult to use the use case method to express the method rules of the language it processed, in which case the traditional BNF paradigm is used to express More appropriate. In the telecommunications software industry, many telecom standards are described in the SDL language. We don't have to use UML to write these standards (UML has such compatibility with SDL), just use the SDL form in the form of telecommunications standards as a demand workpiece One, you can quote it in other workpieces. In short, it should be flexible to use the strengths of various ways in the form of model modeling.
3.2 Supplementary Statute Supplementary Statute Records the system requirements that are not easy to express in the use case model, mainly including the following.
Functional functionality is primarily portrayed in the use case model, but some demand is not suitable for expressing in use. Some functional needs are global, suitable for all use cases, such as error handling, I18N support, etc., we don't need to describe these functional needs in all use cases, just need to be unified in the supplementary protocol. Availability Records All availability-related needs, such as the training time required by the user, whether there is some common usability standards such as Windows interface style. Reliability definition of various indicators related to system reliability, including:
Availability: Indicates the percentage of available time (xx.xx%), the system is in use, maintenance, downgrade mode, etc., the number of hours of operation, the average failure time (MTBF): usually expressed as a small number, but can also be represented as the number of days, the number of months Or number of years; an average repair time (MTTR): The system can suspend the time after the fault; accuracy: points out the precision (resolution) and accuracy required by the system output (according to a certain standard); Error or defect rate: usually expressed as bugs / kloc (number of errors per thousand row code) or bugs / function-point (number of errors for each function point). Performance record system performance related various indicators, including: response time (average, maximum); throughput (such as the number of transactions per second); capacity (such as the system can accommodate customer or transaction); Mode (when the system can be accepted when the system is degraded); resource utilization: memory, disk, communication, etc. Supportable definitions All related needs related to the system's supportability or maintainability, including coding standards, naming, class libraries, how to maintain operations and corresponding maintenance utilities for systems. Design constraints design constraints have been approved and must follow design decisions, including software development processes, development tools, system architecture, programming languages, third-party component libraries, run platforms, and database systems.
3.3 Vocabulary Glossary is mainly used to define project-specific terms that help developers have uniform understanding and use of the terms used in the project, and it is also the basis for object abstraction in subsequent phases.
4. Adjust the case model In the general case of example, we only express the relationship between the participants and the use case, that is, the communication between them. In addition, we can also describe the generalization, extension, and generization relationship between participants and participants. We use these relationships to adjust existing use case models, extract some public information, so that the use model model is easier to maintain. But carefully choose these relationships in the application, generally, these relationships increase the number of use cases and relationships, thereby increasing the complexity of the use case model. Moreover, it is generally adjusted after the use case model is completed, so it is unnecessary to the relationship between the abstract use case in the initial stage of use case modeling.
4.1 The relationship between participants can have a generalization relationship (or "inheritance" relationship). For example, privilege control issues (as shown below) in demand analysis (as shown below), the general user can only use some regular operations, and the administrator needs some system management in addition to routine operations, and the operator can perform regular Operation can also make some configuration operations.
In this example we will find that administrators and operators are a special user, they have all permissions owned by ordinary users, and they have their own permissions. Here we can further put the relationship between ordinary users and administrators and operators, the Generalization relationship, the administrator and operator can inherit the full characteristics of ordinary users (including permissions), they can have their own unique Features (such as operation, permissions, etc.). This can significantly reduce the number of communication associations in the example of the example, simplify the use case model, making it easier to understand.
4.2 The relationship between the use case is described in the external visible behavior, which is a complete service provided by the system for a certain or several participants. In principle, the use cases are parallel, and there is no dependency between them. However, from the perspective of ensuring the maintenanceability and consistency of the use case model, we can abstract the relationship between the use of (including ", expande (Extend) and generalization. These relationships are extracted from the public information from the existing usage, and then reuse this public information through different methods to reduce the workload of model maintenance. 4.2.1 Include (include)
The relationship is represented by the application << include >> constructed in the association relationship, as shown below. The semantics it representative refers to the basic use case (BASE), which is included, in particular, is in an event stream that will be included in the event stream that is included.
The relationship is an expression in UML1.3. In UML1.1, the same semantic relationship is expressed as used (Uses), as shown below.
In the ATM machine, if you queries, cash, the three use cases need to print a receipt to the customer, we can extract the part of the print receipt, abstract, becoming a separate use case "print receipt", and the original Inquiries, cash, and transfer three cases will contain this use case. Whenever you want to modify the requirements of the print receipt section, you only need to change one case, without having to modify each use case, which increases the maintenanceability of the use case model.
In the event stream of the basic use case, we only need to reference the included cases.
Query - basic event stream
1. User inserts a credit card
2. Enter the password
3. Select the query
4. View account balance
5. Contains use case "print receipt"
6. Exit the system, retrieve the credit card
In this example, multiple use cases require the same paragraph, we can use this common behavior alone into a use case, then let other use cases to include this use. Thus, the same paragraph behavior can be repeatedly described in a plurality of use examples, or may prevent the description of the segment behavior from being inconsistencies in a plurality of use cases. When you need to modify this public demand, we only need to modify a use case to avoid inconsistencies and repeatability of multiple use cases simultaneously.
Sometimes when an event stream of a certain use case is too complicated, in order to simplify the description of the use case, we can also abbreviate a certain event stream into an example of being included. This situation is similar to in the process designs language, package a segment algorithm of the program into one process, and then call this sub-process from the main program.
4.2.2 Expansion (Extend)
Extend relationships As shown in the following figure, there is an up to multiple named extension points in the Basic Case (BASE), and the extended relationship refers to the insertion of the event stream of the extension in a certain extension point. In the Basic Case (BASE). For the relationship, the event stream in the sub-case is always inserted into the base case, and only one insertion point is only one. The extended relationship can determine whether the event stream of the extension is inserted into the base use case event stream according to certain conditions, and there can be multiple insertion points.
For example, for telephone services, some value-added services can be extended on the Basic Call service such as call waiting and call transfers. We can use the extension relationship to describe the usage models of these services as follows.
In this example, the call waiting and call transfer are extension to basic calls, but these two use cases will only flow in the event of expanded cases only under certain conditions (such as the answer to the front of the response). Embed the extension point of the basic call us, and reuse the event streams in the basic call example.
It is worth noting that the event stream of the expansion can also be abstracted as an alternative stream of the basic use case, as the call waiting and call transfer in the above example can be present as alternative flows of basic calls. However, basic call usage is already a very complex use. Selecting extended relationships Become value-added business abstraction into individual use cases to avoid basic use cases are too complex, and some optional operation is individually encapsulated in additional use cases. 4.2.3 Generalization
When multiple use cases have a similar structure and behavior, we can use their commonly abstraction into a parent example, and other use cases are sub-cases in the generalization relationship. In the generalization relationship of the use case, the child use is a special form of the parent example, and the child use case inherits all of the structural, behaviors and relationships of the father. In practical applications, the general application is rarely used, and special behaviors in the child use can be present as alternative flows in the parent example.
The following is an example of using an extensive relationship, and the implementation of the transaction is a transaction abstraction, the implementation of real estate transactions and the implementation of securities transactions are a special form of trading.
The event flow in an example extensive relationship is as follows:
4.3 Adjusting the model model model model model is completed, we can review the use case model to see if the use case model can be further simplified, improve the degree of reuse, and increase the maintenanceability of the model. Mainly start from the following checkpoints:
Is the use case independent of each other? If the two use cases are always activated in the same order, they may need to be merged into one case. Is there a very similar behavior or event stream between multiple use cases? If so, consider combining them into one use case. Has a part of the use case event stream has been built as another case? If so, the use case can be included in another case. Should I insert an exemplary event stream into the event stream of another use case? If so, this model is established using the extension relationship (extend) with another use case.
5. Manage the use case model complexity is generally small system, the participants and use cases included in the use case model do not have too much, one use case map can accommodate all participants, all participants and use cases can also be used in the same Hierarchical structure. For more complex large and medium-sized systems, participants and use cases in the model model will greatly increase, and we need some ways to effectively manage complexity due to scale rises.
5.1 Package is the most commonly used management model complexity in UML, and the package is also the simplest model element in the UML, which is a container that can accommodate other model elements in the package. Includes other packages). In the case model, we can extend the semantics of the standard UML package with a strodype << Use copy >>, which is used in the classification model model. Model elements.
We can classify them according to the characteristics of participants and use cases, which are placed under different cases of use case management. For example, for a large enterprise management information system, we can focus on human resources, finance, procurement, sales, and guest service, based on the content of participants and use cases. In this way, we will divide the entire use case model into two levels. We see the first level is that the system features are divided into five parts. At the second level, we can see participants and use cases inside each used case.
How many cases need to be used to manage the complexity of the use model model (including the number of participants and the number of use cases). The package in the UML is actually similar to the directory in the file system. When the number of files does not require additional directory, the number of files need to have multiple directories to classify management, and the same set of files will create different The directory structure is managed. The key is to ensure that each file is easy to access under the directory structure. The same truth exists in the modeling, how to create an example package and the number of cases used depending on different systems and system analysts, but to ensure that the entire use case model is easy to understand. 5.2 How many use cases do I need to use? This is a doubt that many people will produce when using example modeling. Describe the same system, different people will produce different use case models. For example, for a "maintenance user" use case in various systems, it contains adding users, modifying user information, deleting users, etc., which can express sub-event streams that become basic streams (Subflow) .
Maintain users - basic event stream
This basic stream consists of three sub-event streams:
(1) Add user sub-event stream ...
(2) Modify the user sub-event stream ...
(3) Delete user sub-event streams ...
However, you can also abstract it into three use cases based on the specific operation in this use, and the system requirements and the model of single-use cases are exactly the same.
How should I determine the particle size of the use case? At a technical seminar, some people ask about Dr. Ivar Jacoboson, how many use cases do you need? The ahead of the master is 20, of course, he means that it is best to control the size of the model model in dozens of use cases, which is relatively easy to manage the complexity of the use model model. Under the conditions of the case, we can easily determine the size of the size of the case. For more complex systems, we need to control the complexity of the use case model level, so you can properly move the complexity to the inside of each use case, that is, let a use case contain more demand information. For a relatively simple system, we can use the complexity to moderately expose the model level, that is, we can break more complex use cases into multiple use cases.
The particle size of the use case not only determines the complexity of the use case model level, but also determines the complexity of each with an internal use. We should be based on the specific situation of each system, while the complexity of each hierarchy is considered to ensure that the size and number of the entire use case model will be determined as much as possible.
5.3 The main role of the example example example is to describe the relationship between the participant and the use case, and only one case map can be described in a simple system. All the relationships can be described clear. Multiple examples of examples can be used in complex systems, such as each use case, can have an independent model diagram to describe all participants and use cases in this case.
In a use case model, there is a multi-to-many relationship between the participant and the use case, and the relationship between them is more complicated. If all participants and use cases are not clear enough in the same example example, this is not clear enough. When we can create multiple cases to represent various relationships, respectively.
If you want to emphasize a participant and multiple use cases, you can use this participant as a center, and use an example to express the relationship between the participant and multiple use cases. In this case, we emphasize which services are available in this participant.
If you want to emphasize the relationship between a certain use case and multiple participants, you can use an example to express the relationship between the use case and multiple participants in this way. In this example, we emphasize which participants are involved in the use case, or which users are used by the system services represented by the use case.
