Systematic conversion method from UML (Unified Modeling Language) to Event-B

Abstract

The invention discloses a systematic conversion method from UML (Unified Modeling Language) to Event-B. The systematic conversion method comprises the following steps of (1) establishing a visual UML model of a Web application system based on a use case diagram, a class diagram, a sequence diagram, a component diagram and a deployment diagram, and performing preprocessing; (2) mapping objects and basic activities in the UML model in the Event-B model; (3) refining the Event-B model after completing the basic mapping; (4) more details, states and control logics are introduced, and whether the refining process of the model meets the requirements or not is verified for invariants (invariants), event guards (guards) and prof obligations (prof obligations) in the Event-B; according to the method, the complex Web application is more stable, flexible and easy to expand in development.

Description

Technical Field

[0001] The present invention relates to the technical field of computer software engineering, and in particular to a systematic conversion method from UML to Event-B. Background Art

[0002] Unified Modeling Language (UML) is a graphical language that supports modeling and software system development. It provides modeling and visualization support for all stages of software development, including requirements analysis, specifications, construction and configuration. A complete system development process must start with system specifications and proceed according to the specifications. The problems implied in the requirements specifications will have a significant impact on the development process. However, as a semi-formal modeling language, UML has imprecision and is difficult to formally verify. Although 14 types of UML diagrams have been proposed, the diagrams required for application in Web application systems are not clearly specified. When designing a Web application system, diagrams may be repeated or lack associations. Some important information lacks connection in different diagrams or fails to form a complete system view, resulting in imperfect design or difficulty in understanding. Ensuring the consistency and integrity between various diagrams is crucial to the effective design and development of Web application systems.

[0003] Formal methods are mathematically based techniques used to verify high-security systems, eliminate specification ambiguities and inconsistencies, and ensure that system requirements are understood, modeled, and analyzed completely. Event-B is a popular and easy-to-use formal method with precise semantics and is the latest B method, but its rigorous mathematical logic makes it difficult for many software requirements analysts to understand and apply it. In contrast, although UML is intuitive and easy to understand, it lacks expressive power. Summary of the invention

[0004] Purpose of the invention: The purpose of the present invention is to provide a systematic conversion method from UML to Event-B, which systematically converts the UML model to the Event-B model in a Web application, thereby ensuring the correctness, security, consistency and maintainability of the system through formal modeling, verification and refinement.

[0005] Technical solution: A systematic conversion method from UML to Event-B described in the present invention comprises the following steps:

[0006] (1) Based on the use case diagram, class diagram, sequence diagram, component diagram, and deployment diagram, establish a visual UML model of the Web application system and perform preprocessing;

[0007] (2) Map the objects and basic activities in the UML model in the Event-B model;

[0008] (3) Refine the Event-B model that has completed the basic mapping;

[0009] (4) By introducing more details, states, and control logic, we verify whether the model refinement process meets the requirements of invariants, guards, and proof obligations in Event-B.

[0010] Furthermore, in step (1), the preprocessing is as follows: first, ensure the integrity of the model and its consistency between different diagrams, and delete redundant classes and objects; for use case diagrams, clarify functional requirements and system boundaries; in class diagrams, classes should be appropriately aggregated and decomposed, attributes and methods should be clarified, and inheritance and association relationships should be reasonably defined; sequence diagrams should refine message passing to ensure that object behavior conforms to business logic; component diagrams should reasonably divide components and define clear interfaces and dependencies; in deployment diagrams, nodes and communication paths should be reasonably planned; and consistency and integrity should be checked across diagrams.

[0011] Furthermore, step (2) includes the following steps:

[0012] (21) Use case diagram: In Event-B, users or external systems are represented as constants or collections;

[0013] (22) Class diagram: Convert the class into a set of Event-B to represent the entities in the system. If the class is dynamically changing, the attributes of the class are represented as variables or constants in Event-B. The relationships between classes are converted into relationships or functions in Event-B.

[0014] (23) Sequence diagram: Each message transfer in the sequence diagram is mapped to an event in Event-B; events represent the interaction between different objects; the lifeline in the sequence diagram describes the activity cycle of the object, and the event sequence and guards in Event-B can control the state transition;

[0015] (24) Component diagram: Each component in the component diagram is mapped to a machine or sub-machine in Event-B, representing different functional modules of the system; the interface between components describes the interaction between components; it is mapped to events or operations in Event-B; the dependency between components is represented by events or guards;

[0016] (25) Deployment diagram: The physical nodes in the deployment diagram are represented as constants in Event-B; the communication links between nodes are mapped to events, representing the data transfer between different physical nodes; the resources involved in the deployment diagram define the system constraints through invariants and events.

[0017] Furthermore, step (3) includes the following steps:

[0018] (31) Decompose an abstract event into multiple sub-events or increase the execution steps of the event, introduce new operation steps or data verification;

[0019] (32) Replace abstract variables or collections with more detailed data structures;

[0020] (33) Add more control logic during refinement;

[0021] (34) Introduce new state variables or operation variables to describe more details of the system;

[0022] (35) Each refinement must be verified. When refining the model, each newly introduced detail needs to be verified step by step to ensure that the correctness of the previous system is not destroyed.

[0023] Further, step (4) includes the following steps:

[0024] (41) In the process of refining the five UML diagrams, invariants are introduced to ensure that each entity or operation remains consistent throughout the system operation and to avoid the occurrence of illegal states. Specifically, in the use case diagram, it is used to verify that the execution of each use case does not violate business rules; in the class diagram, it is used to verify whether the state of attributes, relationships, inheritance, etc. in the class is consistent; in the sequence diagram, it is necessary to verify that the order of message transmission between objects complies with the agreement; in the component diagram, it is necessary to verify whether the data transmitted by the interface between components meets the interface protocol; in the deployment diagram, it is necessary to verify that the network connection or physical resource allocation does not violate the system constraints;

[0025] (42) Guards are introduced to ensure that events are executed only when certain conditions are met, thus preventing illegal operations. Specifically, in the use case diagram, ensure that user operations are allowed only when certain business conditions are met; in the class diagram, ensure that class attributes can only be changed in a legal state; in the sequence diagram, ensure that the object state must meet the conditions before the message is transmitted; in the component diagram, ensure that the interface interaction between components only occurs when the dependency conditions are met; in the deployment diagram, ensure that communication is triggered only when the physical resources meet the conditions;

[0026] (43) In the five diagrams, the behavior of the system depends on the sequential execution of events. The introduction of event sequence verification ensures that the system executes operations according to the correct process and does not cause inconsistent states or process interruptions;

[0027] (44) Introducing termination verification ensures that each operation in the system has a termination condition to prevent the system from falling into an infinite loop or becoming unresponsive; introducing liveness verification ensures that each part of the system can continue to run and avoid deadlock; specifically as follows: in the use case diagram, it can be verified that each use case can complete the operation and return the result; in the class diagram, it can be verified that the state change of the class instance can be completed normally; in the sequence diagram, it can be verified that the message passing process can be completed smoothly; in the component diagram, it can be verified that the interaction between components can be executed smoothly without being stuck in waiting or blocking; in the deployment diagram, it can be verified that network communication can be completed smoothly to avoid deadlock or timeout caused by bandwidth, delay or error.

[0028] The present invention provides a UML to Event-B systematic conversion system, comprising:

[0029] UML module: used to build and preprocess the visual UML model of the Web application system based on use case diagrams, class diagrams, sequence diagrams, component diagrams, and deployment diagrams;

[0030] Mapping module: used to map objects and basic activities in the UML model in the Event-B model;

[0031] Refinement module: used to refine the Event-B model that has completed the basic mapping;

[0032] Verification module: It is used to verify whether the model refinement process meets the requirements by introducing more details, states and control logic, invariants, guards and proof obligations in Event-B.

[0033] Furthermore, in the UML module, the preprocessing is as follows: first, ensure the integrity of the model and its consistency between different diagrams, and delete redundant classes and objects; for the use case diagram, clarify the functional requirements and system boundaries; in the class diagram, classes should be appropriately aggregated and decomposed, attributes and methods should be clarified, and inheritance and association relationships should be reasonably defined; the sequence diagram should refine message passing to ensure that object behavior conforms to business logic; the component diagram should reasonably divide components and define clear interfaces and dependencies; in the deployment diagram, nodes and communication paths should be reasonably planned; and consistency and integrity should be checked across diagrams.

[0034] Furthermore, the mapping module includes the following steps:

[0035] (21) Use case diagram: In Event-B, users or external systems are represented as constants or collections;

[0036] (22) Class diagram: Convert the class into a set of Event-B to represent the entities in the system. If the class is dynamically changing, the attributes of the class are represented as variables or constants in Event-B. The relationships between classes are converted into relationships or functions in Event-B.

[0037] (23) Sequence diagram: Each message transfer in the sequence diagram is mapped to an event in Event-B; events represent the interaction between different objects; the lifeline in the sequence diagram describes the activity cycle of the object, and the event sequence and guards in Event-B can control the state transition;

[0038] (24) Component diagram: Each component in the component diagram is mapped to a machine or sub-machine in Event-B, representing different functional modules of the system; the interface between components describes the interaction between components; it is mapped to events or operations in Event-B; the dependency between components is represented by events or guards;

[0039] (25) Deployment diagram: The physical nodes in the deployment diagram are represented as constants in Event-B; the communication links between nodes are mapped to events, representing the data transfer between different physical nodes; the resources involved in the deployment diagram define the system constraints through invariants and events.

[0040] Furthermore, the refinement module includes the following steps:

[0041] (31) Decompose an abstract event into multiple sub-events or increase the execution steps of the event, introduce new operation steps or data verification;

[0042] (32) Replace abstract variables or collections with more detailed data structures;

[0043] (33) Add more control logic during refinement;

[0044] (34) Introduce new state variables or operation variables to describe more details of the system;

[0045] (35) Each refinement must be verified. When refining the model, each newly introduced detail needs to be verified step by step to ensure that the correctness of the previous system is not destroyed.

[0046] Furthermore, the verification module includes the following steps:

[0047] (41) In the refinement process of the five UML diagrams, invariants are used to ensure that each entity or operation remains consistent throughout the system operation to avoid the occurrence of illegal states; specifically, in the use case diagram, it is used to verify that the execution of each use case does not violate business rules; in the class diagram, it is used to verify whether the state of attributes, relationships, inheritance, etc. in the class is consistent; in the sequence diagram, it is necessary to verify that the order of message transmission between objects complies with the agreement; in the component diagram, it is necessary to verify whether the data transmitted by the interface between components meets the interface protocol; in the deployment diagram, it is necessary to verify that the network connection or physical resource allocation does not violate the system constraints;

[0048] (42) Guards ensure that events are executed only when certain conditions are met, preventing illegal operations. Specifically, they are as follows: in the use case diagram, they ensure that user operations are allowed only when certain business conditions are met; in the class diagram, they ensure that class attributes can only be changed in a legal state; in the sequence diagram, they ensure that the object state must meet the conditions before the message is transmitted; in the component diagram, they ensure that the interface interaction between components only occurs when the dependency conditions are met; in the deployment diagram, they ensure that communication is triggered only when the physical resources meet the conditions;

[0049] (43) In the five diagrams, the behavior of the system depends on the sequential execution of events. Event sequence verification ensures that the system executes operations according to the correct process and does not cause inconsistent states or process interruptions;

[0050] (44) Termination verification ensures that each operation in the system has a termination condition to prevent the system from falling into an infinite loop or becoming unresponsive; liveness verification ensures that each part of the system can continue to run to avoid deadlock; specifically, it is verified in the use case diagram that each use case can complete the operation and return the result; in the class diagram, it is verified that the state change of the class instance can be completed normally; in the sequence diagram, it is verified that the message passing process can be completed smoothly; in the component diagram, it is verified that the interaction between components can be executed smoothly without being stuck in waiting or blocking; in the deployment diagram, it is verified that network communication can be completed smoothly to avoid deadlock or timeout caused by bandwidth, delay or error.

[0051] Beneficial effects: Compared with the prior art, the present invention has the following significant advantages: Event-B's formal verification tool provides automated verification capabilities to ensure that the system does not have logical errors and state conflicts during development and refinement. And the systematic conversion method ensures that each step from the design to the implementation of the Web application is strictly verified, greatly improving the correctness, security and maintainability of the system, making complex Web applications more robust, flexible and easy to expand in development. BRIEF DESCRIPTION OF THE DRAWINGS

[0052] Figure 1 It is a schematic diagram of the overall process of the present invention.

[0053] Figure 2It is the conversion process of the basic diagram of the use case diagram of the present invention to the Event-B model;

[0054] Figure 3 It is the conversion process of the basic diagram of the class diagram of the present invention to the Event-B model;

[0055] Figure 4 It is the conversion process of the basic diagram of the sequence diagram of the present invention to the Event-B model;

[0056] Figure 5 It is the conversion process of the basic diagram of the component diagram of the present invention to the Event-B model;

[0057] Figure 6 It is the conversion process of the basic diagram of the deployment diagram of the present invention to the Event-B model; DETAILED DESCRIPTION

[0058] The technical solution of the present invention is further described below in conjunction with the accompanying drawings.

[0059] General Web application systems are usually classified as medium-sized systems, with code volumes ranging from 5,000 to 50,000 lines. Such systems use UML use case diagrams, class diagrams, sequence diagrams, component diagrams, and deployment diagrams. Figure 5 By using these graphics, we can effectively model the system and clearly express the structure and behavior of the system. By systematically converting the UML model into the Event-B model, we can reduce errors in the conversion and improve the quality and practicality of the model by clarifying the mapping relationship between the UML diagram and the Event-B elements and establishing unified conversion rules.

[0060] like Figure 1 As shown, an embodiment of the present invention provides a systematic conversion method from UML to Event-B, comprising the following steps:

[0061] S1. Based on the use case diagram, class diagram, sequence diagram, component diagram and deployment diagram, a visual UML model of the Web application system is established. According to the analysis, the basic elements required for the general Web application UML model are shown in Table 1.

[0062] Table 1 Basic elements of UML model

[0063]

[0064]

[0065] S2. UML model preprocessing: Before converting the UML model of the Web application system to the Event-B model, effective preprocessing is required to ensure the clarity, consistency and completeness of the model. First, ensure the integrity of the model and its consistency between different diagrams, and delete redundant classes and objects. For the use case diagram, clarify the functional requirements and system boundaries; in the class diagram, classes should be appropriately aggregated and decomposed, properties and methods should be clarified, and inheritance and association relationships should be reasonably defined; the sequence diagram should refine message passing to ensure that object behavior conforms to business logic; the component diagram should reasonably divide components, define clear interfaces and dependencies; in the deployment diagram, nodes and communication paths should be reasonably planned. Check consistency and completeness across diagrams to ensure that all use cases are implemented in other diagrams. Comments and documentation are essential for complex parts, and the mapping between requirements and model elements needs to be clarified. Use UML tools and automated checking functions to further verify the integrity and consistency of the model. These steps help improve the efficiency and accuracy of UML to Event-B conversion and ensure that the model is correct and without omissions.

[0066] S3. Map the objects and basic activities in the UML model to the Event-B model according to the model elements in the table in step S1. In the corresponding mapping process, it is necessary to keep the abstract level consistent between the UML and Event-B models to ensure that the key business logic and scenarios of the Web application are fully represented in the Event-B model. The initial model can be relatively abstract and gradually refined and expanded as development progresses.

[0067] (3.1) Use case diagram: In Event-B, actors represent external entities in the system, such as users or external systems, which can be represented as constants or sets. For example: 'actor' → constant 'Actor' or set 'ACTOR'; Each use case describes the system function and can be converted into an event in Event-B. Events describe the functional behavior and interaction in the use case. The specific conversion is shown in Table 2.

[0068] Table 2 Event descriptions of functional behaviors and interactions in use cases

[0069]

[0070]

[0071] (3.2) Class diagram: Classes can be converted into sets of Event-B, representing entities in the system; attributes of a class can be represented as variables or constants in Event-B, depending on whether it is dynamically changing; relationships between classes can be converted into relationships or functions in Event-B, for example, 'User' → 'Order': relationship The inheritance relationship can be expressed by the containment relationship of the set. For example, Admin inherits User, which can be expressed as The specific conversion steps are shown in Table 3.

[0072] Table 3

[0073]

[0074] (3.3) Sequence diagram: Each message transfer in the sequence diagram can be mapped to an event in Event-B; events represent the interaction between different objects; lifelines in the sequence diagram describe the activity cycle of an object. The event sequence and guards in Event-B can control the state transition. For example, the active state of an object can be represented as: state transition 'Active→Inactive'; the order of messages in the sequence diagram is represented by the order of event execution in Event-B. The specific conversion steps are shown in Table 4.

[0075] Table 4

[0076]

[0077] (3.4) Component diagram: Each component in the component diagram can be mapped to a machine or sub-machine in Event-B, representing different functional modules of the system; the interfaces between components describe the interactions between components. These interfaces can be mapped to events or operations in Event-B; the dependencies between components can be represented by events or guards. For example, if a component needs to be executed after another component is completed, this can be achieved through event dependencies. The specific conversion steps are shown in Table 5 below.

[0078] Table 5

[0079]

[0080] (3.5) Deployment diagram: The physical nodes (such as servers and clients) in the deployment diagram can be represented as constants in Event-B; the communication links between nodes can be mapped to events, representing the data transfer between different physical nodes; the resources involved in the deployment diagram (such as computing resources, storage resources, etc.) can be used to define the constraints of the system through invariants and events, for example: 'Resource Allocation' → invariant 'Resource_Constraint'. The specific conversion steps are shown in Table 6.

[0081] Table 6

[0082]

[0083] S4. Refine the Event-B model after completing the basic mapping; in all five diagrams, the event is initially just a high-level functional description, and after refinement, it needs to include more details.

[0084] (4.1) Decompose the abstract event into multiple sub-events or increase the execution steps of the event, introduce new operation steps or data verification; take the user login event as an example, give a refined Event-B model for user identity authentication.

[0085]

[0086] (4.2) Replace abstract variables or sets with more detailed data structures; taking the user management system as an example, the abstract user set is replaced with a more specific user data structure.

[0087]

[0088] (4.3) When refining, you can add more control logic, such as conditional judgment, loop structure, etc.; the following uses product purchase as an example to show how to refine control logic in a Web application system.

[0089] (4.4) Introduce new state variables or operation variables to describe more details of the system; the following takes online order management as an example to show how to introduce new state variables and operation variables. By introducing new state variables and operation variables (such as userId, orderItems, and paymentStatus), more detailed user and order information is described in the Event-B model.

[0090]

[0091] (4.5) Each refinement must be verified. When refining the model, each newly introduced detail needs to be verified step by step to ensure that the correctness of the previous system is not destroyed. Use automated tools (such as Rodin) to check the model to ensure the consistency and correctness of the model. After each round of verification, the model can be continuously refined until all requirements are met.

[0092] S5. Verify that the model refinement process meets the requirements by introducing more details, states and control logic, invariants in Event-B, event guards, and proof obligations.

[0093] (5.1) In the refinement process of the five UML diagrams, invariants ensure that each entity or operation remains consistent throughout the system operation to avoid the occurrence of illegal states. In the use case diagram, it can be used to verify that the execution of each use case does not violate business rules; in the class diagram, it is used to verify whether the state of attributes, relationships, inheritance, etc. in the class is consistent; in the sequence diagram, it is necessary to verify that the order of message transmission between objects complies with the agreement; in the component diagram, it is necessary to verify whether the data transmitted by the interface between components meets the interface protocol; in the deployment diagram, it is necessary to verify that the network connection or physical resource allocation does not violate the system constraints.

[0094] (5.2) Guards ensure that events are executed only when certain conditions are met, preventing illegal operations. In the use case diagram, ensure that user operations are allowed only when certain business conditions are met; in the class diagram, ensure that class attributes can only be changed in a legal state; in the sequence diagram, ensure that the object state must meet the conditions before the message is passed; in the component diagram, ensure that the interface interaction between components only occurs when the dependency conditions are met; in the deployment diagram, ensure that communication is triggered only when the physical resources meet the conditions.

[0095] (5.3) In the five diagrams, the behavior of the system depends on the sequential execution of events. Event sequence verification ensures that the system executes operations according to the correct process, which will not cause inconsistent states or process interruptions.

[0096] (5.4) Termination verification ensures that each operation in the system has a termination condition to prevent the system from falling into an infinite loop or becoming unresponsive; liveness verification ensures that each part of the system can continue to run to avoid deadlock.

[0097] 5.4.1 In the use case diagram, it can be verified that each use case can complete the operation and return the result;

[0098] Taking the bank balance query as an example, the balance query operation must be performed after the user logs in, so we need to verify whether the user has successfully logged in. In the check balance event, we provide a condition to ensure that the balance can only be checked if the current user exists.

[0099]

[0100] 5.4.2 Verify in the class diagram that the state changes of the class instances can be completed normally;

[0101] Take the state change of user registration as an example. User instances are created and stored in the system. Confirm that after each user registration, the user collection is updated and no exceptions occur. Use model checking tools (such as Rodin) to verify whether the state change of each class meets expectations after each event occurs, ensuring that there is no deadlock state and abnormal exit.

[0102]

[0103] 5.4.3 Verify that the message delivery process can be completed smoothly in the sequence diagram. Take user shopping as an example. By submitting the order, confirming the order, and processing the order, ensure that the user's shopping can be completed smoothly. By executing each event, ensure the consistency of the shopping cart status, order status, and user status. Verify that each user message such as "purchase goods", "submit order", "generate order", etc. can be delivered normally and the status update is in line with expectations.

[0104] 5.4.4 In the component diagram, verify that the interaction between components can be executed smoothly without being stuck in waiting or blocking; take the information transmission between the front-end and back-end of the user login request as an example. Through Event-B, we can verify that the system will not fall into a deadlock, that is, no state will remain in the waiting process; the request sent by the front-end can always be processed by the back-end in time, and the result can be returned in time after the back-end processing is completed.

[0105] 5.4.5 Verify in the deployment diagram that network communication can be completed smoothly to avoid deadlock or timeout caused by bandwidth, delay or error. When the network status is delayed (delayed) and error (error), the client's request will be delayed or lost. If the network status is delayed or error for a long time, the client will trigger a timeout and enter the error state. If the response fails to return in time due to network delay or error, the client will trigger a timeout to avoid indefinite waiting. Through formal modeling, we can discover potential network communication problems in advance, ensure that the system can operate normally in various environments, and avoid deadlock, blocking or timeout problems.

Claims

1. A systematic conversion method from UML to Event-B, characterized in that: The following steps are involved: (1) Based on the use case diagram, class diagram, sequence diagram, component diagram, and deployment diagram, establish a visual UML model of the Web application system and perform preprocessing; (2) Map the objects and basic activities in the UML model in the Event-B model; (3) Refine the Event-B model that has completed the basic mapping; (4) By introducing more details, states, and control logic, we verify whether the model refinement process meets the requirements of invariants, guards, and proof obligations in Event-B.

2. A method for systematically converting UML to Event-B according to claim 1, characterized in that: In step (1), the preprocessing is as follows: first, ensure the integrity of the model and its consistency between different diagrams, and delete redundant classes and objects; for use case diagrams, clarify functional requirements and system boundaries; in class diagrams, classes should be appropriately aggregated and decomposed, attributes and methods should be clarified, and inheritance and association relationships should be reasonably defined; sequence diagrams should refine message passing to ensure that object behavior conforms to business logic; component diagrams should reasonably divide components and define clear interfaces and dependencies; In the deployment diagram, plan nodes and communication paths reasonably; Check consistency and completeness across graphs.

3. A systematic conversion method from UML to Event-B according to claim 1, characterized in that: Step (2) comprises the following steps: (21) Use case diagram: In Event-B, users or external systems are represented as constants or collections; (22) Class diagram: Convert the class into a set of Event-B to represent the entities in the system. If the class is dynamically changing, the attributes of the class are represented as variables or constants in Event-B. The relationships between classes are converted into relationships or functions in Event-B. (23) Sequence diagram: Each message transfer in the sequence diagram is mapped to an event in Event-B; events represent the interaction between different objects; the lifeline in the sequence diagram describes the activity cycle of the object, and the event sequence and guards in Event-B can control the state transition; (24) Component diagram: Each component in the component diagram is mapped to a machine or sub-machine in Event-B, representing different functional modules of the system; the interface between components describes the interaction between components; it is mapped to events or operations in Event-B; the dependency between components is represented by events or guards; (25) Deployment diagram: The physical nodes in the deployment diagram are represented as constants in Event-B; the communication links between nodes are mapped to events, representing the data transfer between different physical nodes; the resources involved in the deployment diagram define the system constraints through invariants and events.

4. A method for systematically converting UML to Event-B according to claim 1, characterized in that: Step (3) comprises the following steps: (31) Decompose an abstract event into multiple sub-events or increase the execution steps of the event, introduce new operation steps or data verification; (32) Replace abstract variables or collections with more detailed data structures; (33) Add more control logic during refinement; (34) Introduce new state variables or operation variables to describe more details of the system; (35) Each refinement must be verified. When refining the model, each newly introduced detail needs to be verified step by step to ensure that the correctness of the previous system is not destroyed.

5. A systematic conversion method from UML to Event-B according to claim 1, characterized in that: Step (4) comprises the following steps: (41) In the process of refining the five UML diagrams, invariants are introduced to ensure that each entity or operation remains consistent throughout the system operation and to avoid the occurrence of illegal states. Specifically, in the use case diagram, it is used to verify that the execution of each use case does not violate business rules; in the class diagram, it is used to verify whether the state of attributes, relationships, inheritance, etc. in the class is consistent; in the sequence diagram, it is necessary to verify that the order of message transmission between objects complies with the agreement; in the component diagram, it is necessary to verify whether the data transmitted by the interface between components meets the interface protocol; in the deployment diagram, it is necessary to verify that the network connection or physical resource allocation does not violate the system constraints; (42) Guards are introduced to ensure that events are executed only when certain conditions are met, thus preventing illegal operations. Specifically, in the use case diagram, ensure that user operations are allowed only when certain business conditions are met; in the class diagram, ensure that class attributes can only be changed in a legal state; in the sequence diagram, ensure that the object state must meet the conditions before the message is transmitted; in the component diagram, ensure that the interface interaction between components only occurs when the dependency conditions are met; in the deployment diagram, ensure that communication is triggered only when the physical resources meet the conditions; (43) In the five diagrams, the behavior of the system depends on the sequential execution of events. The introduction of event sequence verification ensures that the system executes operations according to the correct process and does not cause inconsistent states or process interruptions; (44) Introducing termination verification ensures that each operation in the system has a termination condition to prevent the system from falling into an infinite loop or becoming unresponsive; introducing liveness verification ensures that each part of the system can continue to run and avoid deadlock; specifically as follows: in the use case diagram, it can be verified that each use case can complete the operation and return the result; in the class diagram, it can be verified that the state change of the class instance can be completed normally; in the sequence diagram, it can be verified that the message passing process can be completed smoothly; in the component diagram, it can be verified that the interaction between components can be executed smoothly without being stuck in waiting or blocking; in the deployment diagram, it can be verified that network communication can be completed smoothly to avoid deadlock or timeout caused by bandwidth, delay or error.

6. A systematic conversion system from UML to Event-B, characterized in that: include: UML module: used to build and preprocess the visual UML model of the Web application system based on use case diagrams, class diagrams, sequence diagrams, component diagrams, and deployment diagrams; Mapping module: used to map objects and basic activities in the UML model in the Event-B model; Refinement module: used to refine the Event-B model that has completed the basic mapping; Verification module: It is used to verify whether the model refinement process meets the requirements by introducing more details, states and control logic, invariants, guards and proof obligations in Event-B.

7. A UML to Event-B systematic conversion system according to claim 6, characterized in that: In the UML module, the preprocessing is as follows: first, ensure the integrity of the model and its consistency between different diagrams, and delete redundant classes and objects; for the use case diagram, clarify the functional requirements and system boundaries; in the class diagram, classes should be appropriately aggregated and decomposed, attributes and methods should be clarified, and inheritance and association relationships should be reasonably defined; the sequence diagram should refine message passing to ensure that the object behavior conforms to the business logic; the component diagram should reasonably divide the components and define clear interfaces and dependencies; In the deployment diagram, plan nodes and communication paths reasonably; Check consistency and completeness across graphs.

8. A UML to Event-B systematic conversion system according to claim 6, characterized in that: The mapping module includes the following steps: (21) Use case diagram: In Event-B, users or external systems are represented as constants or collections; (22) Class diagram: Convert the class into a set of Event-B to represent the entities in the system. If the class is dynamically changing, the attributes of the class are represented as variables or constants in Event-B. The relationships between classes are converted into relationships or functions in Event-B. (23) Sequence diagram: Each message transfer in the sequence diagram is mapped to an event in Event-B; events represent the interaction between different objects; the lifeline in the sequence diagram describes the activity cycle of the object, and the event sequence and guards in Event-B can control the state transition; (24) Component diagram: Each component in the component diagram is mapped to a machine or sub-machine in Event-B, representing different functional modules of the system; the interface between components describes the interaction between components; it is mapped to events or operations in Event-B; the dependency between components is represented by events or guards; (25) Deployment diagram: The physical nodes in the deployment diagram are represented as constants in Event-B; the communication links between nodes are mapped to events, representing the data transfer between different physical nodes; the resources involved in the deployment diagram define the system constraints through invariants and events.

9. A UML to Event-B systematic conversion system according to claim 6, characterized in that: The refinement module includes the following steps: (31) Decompose an abstract event into multiple sub-events or increase the execution steps of the event, introduce new operation steps or data verification; (32) Replace abstract variables or collections with more detailed data structures; (33) Add more control logic during refinement; (34) Introduce new state variables or operation variables to describe more details of the system; (35) Each refinement must be verified. When refining the model, each newly introduced detail needs to be verified step by step to ensure that the correctness of the previous system is not destroyed.

10. A UML to Event-B systematic conversion system according to claim 6, characterized in that: The verification module includes the following steps: (41) In the refinement process of the five UML diagrams, invariants are used to ensure that each entity or operation remains consistent throughout the system operation to avoid the occurrence of illegal states; specifically, in the use case diagram, it is used to verify that the execution of each use case does not violate business rules; in the class diagram, it is used to verify whether the state of attributes, relationships, inheritance, etc. in the class is consistent; in the sequence diagram, it is necessary to verify that the order of message transmission between objects complies with the agreement; in the component diagram, it is necessary to verify whether the data transmitted by the interface between components meets the interface protocol; in the deployment diagram, it is necessary to verify that the network connection or physical resource allocation does not violate the system constraints; (42) Guards ensure that events are executed only when certain conditions are met, preventing illegal operations. Specifically, they are as follows: in the use case diagram, they ensure that user operations are allowed only when certain business conditions are met; in the class diagram, they ensure that class attributes can only be changed in a legal state; in the sequence diagram, they ensure that the object state must meet the conditions before the message is transmitted; in the component diagram, they ensure that the interface interaction between components only occurs when the dependency conditions are met; in the deployment diagram, they ensure that communication is triggered only when the physical resources meet the conditions; (43) In the five diagrams, the behavior of the system depends on the sequential execution of events. Event sequence verification ensures that the system executes operations according to the correct process and does not cause inconsistent states or process interruptions; (44) Termination verification ensures that each operation in the system has a termination condition to prevent the system from falling into an infinite loop or becoming unresponsive; liveness verification ensures that each part of the system can continue to run to avoid deadlock; specifically, it is verified in the use case diagram that each use case can complete the operation and return the result; in the class diagram, it is verified that the state change of the class instance can be completed normally; in the sequence diagram, it is verified that the message passing process can be completed smoothly; in the component diagram, it is verified that the interaction between components can be executed smoothly without being stuck in waiting or blocking; in the deployment diagram, it is verified that network communication can be completed smoothly to avoid deadlock or timeout caused by bandwidth, delay or error.

Images