A visual model detection method, system, medium, device and processing terminal

Abstract

The present invention belongs to the technical field of system formal modeling and verification, and discloses a visual model detection method, system, medium, device and processing terminal. The system design model is established by using the visual modeling language xUML4MC, and the property characteristics of classes, methods, statement segments and statements in the design model are annotated by using OPSL; the design model is subjected to lexical and grammatical analysis to construct an abstract syntax tree with attached OPSL properties; each OPSL statement is converted into a PPTL property formula and then negated to construct a property non-automaton CFA; the abstract syntax tree is executed to dynamically generate the system state, and an AND operation is performed according to the OPSL statement constraint position and the corresponding CFA to construct a result automaton. If there is an acceptable path, it is a counterexample path where the property does not hold, otherwise the property holds. The present invention makes up for the direct model detection of the UML design model and promotes the popularization and use of model detection technology in the industry.

Description

Technical Field

[0001] The present invention belongs to the technical field of system formal modeling and verification, and in particular relates to a visual model detection method, system, medium, equipment and processing terminal. Background Art

[0002] In today's highly informationized world, computers have entered various fields of national economy and people's livelihood, such as military defense, industrial control, network communication, medical care, e-commerce, etc. However, with the increasing dependence of society on computer systems, especially some key systems such as aircraft control systems, banking business management systems, train ticketing systems, stock trading systems and traffic control and dispatching systems, once a failure occurs, it will cause huge property losses or even casualties. How to ensure the security and reliability of modern software systems is a serious problem faced by academia and engineering.

[0003] As a traditional means of software system verification, software testing can only prove that there are errors in the system but cannot prove that there are no errors, which is inherently insufficient. Formal verification uses mathematical methods to model and describe the properties of the system to be verified, and proves that the system meets the expected properties under the support of rigorous mathematical theories, providing an effective verification method to ensure the correctness, security and reliability of the software system.

[0004] Model checking is an important formal verification technology. During verification, it is first necessary to establish a finite state transition model of the system to be verified, and describe the property to be verified through a temporal logic formula. Then, with the support of the model checking tool, the execution path of the system is automatically traversed through the algorithm to detect whether the property is established. If the property is not established, a counterexample path can be given to help engineering and technical personnel locate and debug errors.

[0005] The verification of software design solutions mainly uses traditional model checking tools such as SPIN or NuSMV. During verification, the software design solutions described in modeling languages ​​such as UML (Unified Modeling Language) need to be converted into SPIN's Promela model or NuSMV's SMV model, and the properties to be verified are described as logical formulas such as Linear-time Temporal Logic (LTL) or Computation Tree Logic (CTL) for verification. Since the model description strategies of Promela and SMV are completely different from modeling languages ​​such as UML, the model conversion process often needs to be completed manually. As software systems become more and more complex and the expression capabilities of modeling languages ​​such as Promela and SMV are limited, it is difficult to ensure the consistency of the abstract model of the model checking system with the original software design solution.

[0006] At the same time, since the system modeling languages ​​of model checking tools such as SPIN and NuMSV are special scripting languages ​​such as Promela and MSV, engineers and technicians need to master the language to perform system modeling, and the built models do not have intuitive visibility. Modeling of complex systems is very difficult, and it is difficult to ensure the correctness of the model itself. In addition, the description of the properties to be verified mainly uses logical formulas such as LTL and CTL, which still requires engineers and technicians to master the syntax and semantics of the corresponding logical system, and combine the corresponding relationship between the established abstract model of the system to be verified and the system properties of the original software design solution to correctly define the properties to be verified. There is also a lack of a special property description method suitable for engineers and technicians to directly describe the object-oriented software system design solution. Therefore, it is urgent to design a new visual model checking method.

[0007] Through the above analysis, the problems and defects of the prior art are as follows:

[0008] (1) Promela and SMV are specialized script-based modeling languages ​​with limited expressive power. Engineering technicians need to master the modeling language in order to model the system to be verified. In addition, the built model is not intuitive and visible. Modeling complex systems is very difficult, and it is difficult to ensure the correctness of the system abstract model and its consistency with the original software design plan.

[0009] (2) The properties to be verified need to be described directly using logical formulas such as LTL and CTL. Engineering technicians are still required to be proficient in the syntax and semantics of the corresponding logical system. However, since the mathematical logic expertise of engineering technicians is often weak, it is difficult to use temporal logic formulas to accurately define them. There is also a lack of special property description methods suitable for engineering technicians to use to directly describe software system design solutions.

[0010] (3) Model checking requires the use of third-party verification tools such as SPIN and NuMSV. During verification, the verification tool's dedicated modeling language and property definition method must be used to abstractly model and describe the design scheme and system properties of the software system to be verified. This makes verification inefficient and prone to errors.

[0011] The difficulty of solving the above problems and defects is as follows: (1) It is necessary to introduce a visual modeling language that meets the needs of software system design modeling and model checking modeling, so that engineers and technicians can complete them together when designing the software system; (2) It is necessary to design a reasonable visual system property description method that allows engineers and technicians to conveniently and quickly mark the property characteristics of the software system directly in the design model of the software system; (3) It is necessary to automatically extract property statements from the design model and automatically convert them into semantically equivalent temporal logic formulas, and construct property non-automata; (4) It is necessary to design an efficient model checking method to automatically construct a finite state transition system for the system to be verified, and perform model checking and verification according to the constraint position and property non-automata.

[0012] The significance of solving the above problems and defects is as follows: the present invention uses the visual system modeling and property description method familiar to engineering and technical personnel, integrates the software system design modeling and model detection system modeling, and annotates the property characteristics of the system in the design model in an annotation manner, which is completed by engineering and technical personnel during system design; at the same time, the extraction of the properties to be verified and the automatic conversion to the temporal logic property formula are realized, and an efficient model detection algorithm is provided to realize the direct model detection and verification of the software design model. The present invention makes up for the shortcomings of model detection and verification of existing software design solutions, reduces the difficulty of modeling and property description of the system to be verified in model detection, and improves the efficiency of system model detection and verification. Based on the present invention, a computer-aided software engineering tool integrating software design and model detection and verification can be developed, so that general engineering and technical personnel can perform model detection and verification on software design solutions without having to master specialized modeling languages ​​and mathematical logic knowledge, laying a foundation for the promotion and application of model detection technology in the engineering community. Summary of the invention

[0013] In view of the problems existing in the prior art, the present invention provides a visual model detection method, system, medium, device and processing terminal, and in particular, relates to a visual model detection method, system, medium, device and processing terminal using xUML4MC as the modeling language of the system to be verified and OPSL as the system property description language.

[0014] The present invention is implemented as follows: a visual model detection method, the visual model detection method comprising: using xUML4MC to establish a system design model, using OPSL to annotate classes, methods, statement segments and property characteristics of statements in the system design model diagram; performing lexical and grammatical analysis on the xUML4MC model, and constructing an abstract syntax tree with OPSL properties attached; converting each OPSL statement in the abstract syntax tree into a PPTL property formula, and constructing a corresponding property non-automaton CFA after negating the PPTL formula; executing the abstract syntax tree to dynamically generate a system state, and performing an AND operation according to the OPSL statement constraint position and the corresponding CFA to construct a result automaton, if there is an acceptable path, it is a counterexample path where the property does not hold, otherwise the property holds.

[0015] Furthermore, the visual model detection method comprises the following steps:

[0016] Step 1: Use xUML4MC's class diagram and activity diagram to build a system model, and use OPSL to annotate the classes, methods, statement segments, and properties of statements in the system model diagram.

[0017] This step can achieve the following: provide engineering and technical personnel with a familiar visual system modeling and property description method, integrate software system design modeling and model detection system modeling through the xUML4MC modeling language with precise semantics and extended UML definition, and annotate the OPSL statements describing the system's properties and characteristics in the design model in the form of annotations, which can be completed by engineering and technical personnel during system design, thus reducing the modeling and property difficulty of model detection and improving the efficiency of model detection verification.

[0018] Step 2: Perform lexical and grammatical analysis on the xUML4MC model, construct an abstract syntax tree with OPSL properties, and perform integrity and consistency verification;

[0019] This step can achieve: constructing an abstract model of the system from the xUML4MC visual design model, and performing syntax checking, integrity and consistency checks on the model and OPSL property statements, laying the foundation for further model detection.

[0020] Step 3: Convert each OPSL statement in the abstract syntax tree into a PPTL property formula, and construct the corresponding property non-automaton CFA after negating the PPTL formula.

[0021] This step can achieve: converting each system property annotated with OPSL statements in the system into a semantically equivalent PPTL property formula (let it be pptl_prop), and further negating the PPTL property formula (i.e., )Construct a property non-automaton CFA for model checking.

[0022] Step 4: Execute the abstract syntax tree to dynamically generate the system state, and perform AND operations on the OPSL statement constraint position and the corresponding CFA to construct the result automaton. If there is no acceptable path in the result automaton, the property holds, otherwise the acceptable path is a counterexample path where the property does not hold. The system automaton is dynamically generated by executing the abstract syntax tree, and AND operations are performed on the constraint position of each OPSL in the design model and the corresponding property non-automaton CFA to construct the result automaton, and the model detection verification is completed by judging whether there is an acceptable path in the result automaton.

[0023] Furthermore, the OPSL property annotation rules in step 1 include:

[0024] Rule 1: Use OPSL statements to describe the properties that all objects of a class should have from the time they are created to the time they are destroyed, and annotate them on the corresponding class nodes in the class diagram using xUML4MC annotation symbols, referred to as "class properties";

[0025] Rule 2: Describe the properties of a function during execution using OPSL statements and annotate them on the starting node of the activity diagram corresponding to the function using xUML4MC annotation symbols, referred to as "function properties";

[0026] Rule 3: Use OPSL statements to describe the properties of a statement fragment in a function during execution, and annotate it on the start and end nodes of the corresponding statement fragment in the activity diagram corresponding to the function through xUML4MC annotation symbols, referred to as "statement fragment properties";

[0027] Rule 4: Use OPSL statements to describe the properties of a statement in a function before execution, and annotate it on the corresponding statement node in the function activity diagram using xUML4MC annotation symbols, referred to as "assertion properties".

[0028] Furthermore, the method for constructing an abstract syntax tree with OPSL properties in step 2 includes:

[0029] (1) Extract model elements and relationships from the class diagram and activity diagram of the xUML4MC visualization model.

[0030] (2) Perform lexical analysis and syntactic analysis on the model elements and create corresponding abstract syntax tree nodes.

[0031] (3) Based on the inheritance, association, combination, aggregation, annotation and other relationships of the visualization model elements, the abstract syntax tree nodes are constructed into an abstract syntax tree.

[0032] The integrity and consistency checking rules of the model include:

[0033] Rule 1: The consistency between the method activity diagram and the class diagram, including the method name, parameter type and number; the validity of the variable name inside the method, whether it is an inherited attribute of the class, a formal parameter of the method, or a defined local variable.

[0034] Rule 2: Verification of OPSL statements, including whether the syntax conforms to the OPSL syntax definition and whether the referenced variable names are correct. Class properties can only reference class-defined attributes or inherited attributes, and the other three can only reference class attributes, method parameters, and defined local variables.

[0035] Furthermore, in step 3, each OPSL statement in the abstract syntax tree is converted into a PPTL property formula as a tuple (pptl_prop, map), where pptl_prop is the PPTL property formula after the OPSL statement is converted, and map is a set of atomic proposition descriptions of the atomic propositions contained in pptl_prop and the predicate formulas represented by them. The specific conversion rules include:

[0036] Rule 1: If OPSL is a predicate formula e1[<|<=|==|>|>=]e2, the transformed property formula pptl_prop is a new atomic proposition p, and the map is {p:e1[<|<=|==|>|>=]e2};

[0037] Rule 2: If OPSL is a property statement SEQ(Prop1,...,Prop n ), first for each Prop i (1≤i≤n) is converted and the result is pptl_prop i and map1, the final converted property formula pptl_prop is pptl_prop1;...;pptl_prop n , the atomic proposition states that the set map is map1∪...∪map n ;

[0038] Rule 3: If OPSL is a property statement REPEAT(Prop1), first transform Prop1, and let the result be pptl_prop1 and map1. The final transformed property formula pptl_prop is (pptl_prop1)+, and the atomic proposition description set map is map1.

[0039] Rule 4: If OPSL is a property statement SOMETIMES(Prop1), first convert Prop1 and make the result pptl_prop 1,The property formula pptl_prop after the final conversion with map1 is ◇pptl_prop1, and the atomic proposition description set map is map1;

[0040] Rule 5: If OPSL is a property statement ALWAYS(Prop1), first transform Prop1, and let the result be pptl_prop1 and map1. The final transformed property formula pptl_prop is □pptl_prop1, and the atomic proposition description set map is map1.

[0041] Rule 6: If OPSL is a property statement PRE(Prop1), first transform Prop1, and let the results be pptl_prop1 and map1. The final transformed property formula pptl_prop is pptl_prop1, and the atomic proposition description set map is map1.

[0042] Rule 7: If OPSL is a property statement POST(Prop1), first transform Prop1, and let the results be pptl_prop1 and map1. The final transformed property formula pptl_prop is □(ε→pptl_prop1), and the atomic proposition description set map is map1.

[0043] Rule 8: If OPSL is a property statement! Prop1, first transform Prop1, let the result be pptl_prop1 and map1, and the final transformed property formula pptl_prop is The atomic proposition states that the set map is map1;

[0044] Rule 9: If OPSL is a property statement Prop1&&Prop2, first transform Prop1 and Prop2 respectively, and let the results be pptl_prop1, map1 and pptl_prop2, map2 respectively. The final transformed property formula pptl_prop is pptl_prop1∧pptl_prop2, and the atomic proposition description set map is map1∪map2;

[0045] Rule 10: If OPSL is a property statement Prop1||Prop2, first transform Prop1 and Prop2 respectively, and let the results be pptl_prop1, map1 and pptl_prop2, map2 respectively. The final transformed property formula pptl_prop is pptl_prop1∨pptl_prop2, and the atomic proposition description set map is map1∪map2.

[0046] The method of constructing the corresponding property non-automaton CFA by negating the PPTL property formula includes:

[0047] (1) Preprocess the PPTL property formula and replace all subformulas □P contained therein with Subformula ◇P is replaced by (true; P), and subformula P1→P2 is replaced by sub formula Replace with P;

[0048] (2) Calculate the atomic proposition set Φ contained in the PPTL property formula and the alphabet of CFA

[0049] (3) Construct the CFA of the PPTL property formula P. The rules include:

[0050] Rule 1: If the property formula is an atomic proposition p, the CFA of p is A(p) = (∑, Q, δ, I, F, C), where the state set Q = {q0, q1}, the transition set δ = {<q0, p, q1>, <q0, true, q1>}, the initial state set I = {q0}, the finite acceptable set F = {q1}, and the infinite acceptable condition set C = {{q1}};

[0051] Rule 2: If the property formula is P1∨P2, first construct the CFA of P1 and P2 respectively, let them be A(P1)=(∑,Q1,δ1,I1,F1,C1) and A(P2)=(∑,Q2,δ2,I2,F2,C2), and the final CFA is A(P1 V P2)=(∑,Q1∪Q2,δ1∪δ2,I1∪I2,F1∪F2,C1∪C2);

[0052] Rule 3: If the property formula is P1∧P2, first construct the CFA of P1 and P2, let them be A(P1)=(∑,Q1,δ1,I1,F1,C1) and A(P2)=(∑,Q2,δ2,I2,F2,C2), respectively. The final CFA is A(P1∧P2)=(∑,Q,δ,I,F,C), where Q={[q 1 ,q 2 ]|q 1 ∈Q1,q 2 ∈Q2}, I={[q 1 ,q 2 ]|q 1 ∈I1,q 2 ∈I2}, F={[q 1 ,q 2 ]|q 1 ∈F1,q 2 ∈F2}, C={{[q12 ]|q 1 ∈Δ1,q 2 ∈Δ2}|Δ1∈C1,Δ2∈C2};

[0053] Rule 4: If the property formula is P1; P2, first construct the CFA of P1 and P2 respectively, let them be A(P1) = (∑, Q1, δ1, I1, F1, C1) and A(P2) = (∑, Q2, δ2, I2, F2, C2), and the final CFA is A(P1; P2) = (∑, Q1∪Q2, δ1∪δ2∪δ a , I1, F2, C2), where

[0054]

[0055] Rule 5: If the property formula is First construct the CFA of P1 A(P1) = (∑, Q1, δ1, I1, F1, C1), and the final CFA is in

[0056] and

[0057]

[0058] Rule 6: If the property formula is First construct the CFA of P1 A(P1) = (∑, Q1, δ1, I1, F1, C1), and use the subset construction method to convert A(P1) into a deterministic CFA The final CFA is

[0059] Furthermore, the execution abstract syntax tree in step 4 dynamically generates the system state, and performs AND operation according to the OPSL statement constraint position and the corresponding CFA to construct a result automaton. If there is no acceptable path in the result automaton, the property holds, otherwise the acceptable path is a counterexample path where the property does not hold. The specific process includes:

[0060] (1) Use the abstract syntax tree to specify the entry function fun of the model checking verification to initialize the result automaton rstCFA = (∑, Q, δ, I, F, C), the automaton state is a two-tuple (stmt, stateSet), stmt is the statement in the abstract syntax tree, stateSet is the state set of the corresponding property automaton, Q = {(fun, {})}, I = {(fun, {})}, Push the initial state of rstCFA (fun, {}) into the backtracking stack and specify fun as the current verification function;

[0061] (2) According to the OPSL statements annotated in the current verification function, the set CFASet of property non-automaton binary tuples (cfa, start:end) with constraint positions is calculated, where cfa is the property non-automaton, start and end are the starting and ending positions of the cfa constraint. The specific calculation rules include:

[0062] Rule 1: If the current class is annotated with the OPSL class property statement prop, construct a tuple (cfa, start:end) and add it to CFASet. The start of the tuple is equal to the position of the next statement of the statement annotated with prop, and the end is equal to the position of the statement before the object is destroyed.

[0063] Rule 2: If the current code snippet is annotated with the start property statement prop_start and the end property statement prop_end of the OPSL code snippet property, construct a tuple (cfa, start:end) and add it to CFASet. The start of the tuple is equal to the position of the next statement of the statement annotated with prop_start, and the end is equal to the position of the statement annotated with prop_end.

[0064] Rule 3: If the current code snippet is annotated with the OPSL assertion property statement prop, construct a tuple (cfa, start:end) and add it to CFASet. The start of the tuple is equal to the position of the statement annotated with prop, and the end is equal to the position of the statement annotated with prop.

[0065] Rule 4: If the current function is annotated with the OPSL function property statement prop, construct a tuple (cfa, start:end) and add it to CFASet, where cfa is the property non-automaton corresponding to prop, start is equal to the first statement position of the function, and end is equal to the last statement position of the function.

[0066] (3) Calculate the set CFASet of property non-automaton tuples (cfa, start: end) with constraint positions according to the annotated OPSL statements in the current verification function, where cfa is the property non-automaton corresponding to prop, start is equal to the first statement position of the function, and end is equal to the last statement position of the function;

[0067] (4) Take out the top element (stmt, stateSet) of the backtracking stack. For all non-automaton tuples (cfa, start:end) in CFASet, if start is equal to stmt, let stateSet = stateSet∪I, where I is the initial state set of cfa; execute the stmt statement of the top element of the stack, and let the result be rst. The specific execution rules include:

[0068] Rule 1: For a common statement node, select the successor node of the current node as the next statement node to be executed;

[0069] Rule 2: For an if statement node, calculate the value of the conditional expression in the if statement, and select the first node of the corresponding YES or NO branch as the next statement node to be executed based on the true or false result;

[0070] Rule 3: For a while statement node, calculate the value of the conditional expression in the while statement. If the result is true, select the first node of the YES branch as the next node to be executed. Otherwise, select the successor node of the while loop as the next statement node to be executed.

[0071] Rule 4: For a function call statement node, after calculating the value of each actual parameter expression and assigning it to the corresponding function formal parameter, the first statement of the called function is used as the next statement node to be executed.

[0072] (5) If Then go to step (8), otherwise take out each cfa state q in stateSet in turn, and enumerate the unsearched arcs starting from state q<q,α,q1> , go to step (6);

[0073] (6) Use the Z3 solver to calculate the satisfiability of the conjunction formula of rst and α. If the result is false, go to step (9); otherwise, according to the abstract syntax tree execution rules, take out the next statement to be executed stmt1 of the stmt statement and dynamically expand the result automaton rstCFA. The specific rules include:

[0074] Rule 1: If there is a state (stmt1, stateSet1) and an arc <(stmt0, stateSet0),rst,(stmt1, stateSet1)> in rstCFA and q1∈stateSet1, compute the union sset of all stateSets on the path from state (stmt1, stateSet1) to state (stmt, stateSet) in rstCFA, if there is a cfa in CFASet that satisfies an infinite acceptance condition c Add the state sequence in the backtracking stack to the counterexample path set CountExamPathSet and go to step (9).

[0075] Rule 2: If the condition of Rule 1 is not met, add a new state (stmt1,{q1}) to the state set Q of rstCFA, and add a new arc <(stmt,stateSet),rst,(stmt1,{q1})> to the transition set δ; if there exists a non-automaton tuple (cfa,start:end) in CFASet that satisfies stmt1 equals end and q1 is a finite acceptable state of cfa, that is, q1∈F, add the state sequence in the backtracking stack to the counterexample path set CountExamPathSet; push the state (stmt1,{q1}) into the backtracking stack and go to step (4).

[0076] (7) If there are unsearched arcs in stateSet<q,α,q1> , then go to step (5), otherwise go to step (9);

[0077] (8) According to the abstract syntax tree execution rules, the next statement to be executed, stmt1, of the stmt statement is taken out, and the result automaton rstCFA is dynamically constructed. The execution rules include:

[0078] Rule 1: If there is a state (stmt1, stateSet1) and an arc <(stmt0, stateSet0), rst, (stmt1, stateSet1)> in rstCFA, go to step (9);

[0079] Rule 2: If the condition of Rule 1 is not met, add state (stmt1,{}) to the state set Q of rstCFA, and add arc <(stmt,{}),rst,(stmt1,{})> to the transition set δ. Push state (stmt1,{}) into the backtracking stack and go to step (4).

[0080] (9) Pop the top element (stmt, stateSet) of the backtracking stack and delete the state (stmt, stateSet) and its associated arcs from rstCFA; if the backtracking stack is not empty, go to step (4), otherwise go to step (10);

[0081] (10) If the counterexample path set Output if the property to be verified is true, otherwise output the counterexample paths saved in CountExamPathSet one by one.

[0082] Another object of the present invention is to provide a visual model detection system for implementing the visual model detection method, the visual model detection system comprising:

[0083] Visual modeling module, which is used to build the design model of the software system using the class diagram and activity diagram of xUML4MC, and uses OPSL to describe the properties of classes, methods, code snippets, and statements in an annotation manner;

[0084] Abstract syntax tree construction module, used to perform lexical and grammatical analysis on xUML4MC models and annotated OPSL statements, construct an abstract syntax tree with additional OPSL properties, and perform integrity and consistency verification;

[0085] The OPSL conversion module is used to convert each OPSL statement in the abstract syntax tree into a PPTL property formula, and construct a corresponding property non-automaton CFA after negating the PPTL property formula;

[0086] The model checking module is used to execute the abstract syntax tree to dynamically generate the system state, and perform AND operations on the OPSL statement constraint positions and the corresponding CFA to construct the result automaton and detect whether there is a counterexample path.

[0087] Another object of the present invention is to provide a computer device, the computer device comprising a memory and a processor, the memory storing a computer program, and when the computer program is executed by the processor, the processor performs the following steps:

[0088] Use xUML4MC to build a system model, and use OPSL to annotate the classes, methods, statement segments and property characteristics of statements in the system model diagram; perform lexical and grammatical analysis on the xUML4MC model, and construct an abstract syntax tree with OPSL properties attached; convert each OPSL statement in the abstract syntax tree into a PPTL property formula, and construct the corresponding property non-automaton CFA after negating the PPTL formula; execute the abstract syntax tree to dynamically generate the system state, and perform AND operations on the OPSL statement constraint position and the corresponding CFA to construct the result automaton. If there is an acceptable path, it is a counterexample path where the property does not hold, otherwise the property holds.

[0089] Another object of the present invention is to provide a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor executes the following steps:

[0090] Use xUML4MC to build a system model, and use OPSL to annotate the classes, methods, statement segments and property characteristics of statements in the system model diagram; perform lexical and grammatical analysis on the xUML4MC model, and construct an abstract syntax tree with OPSL properties attached; convert each OPSL statement in the abstract syntax tree into a PPTL property formula, and construct the corresponding property non-automaton CFA after negating the PPTL formula; execute the abstract syntax tree to dynamically generate the system state, and perform AND operations on the OPSL statement constraint position and the corresponding CFA to construct the result automaton. If there is an acceptable path, it is a counterexample path where the property does not hold, otherwise the property holds.

[0091] Another object of the present invention is to provide an information data processing terminal, which is used to implement the visual model detection system.

[0092] In combination with all the above technical solutions, the advantages and positive effects of the present invention are as follows: the present invention uses the visual modeling language xUML4MC with precise semantics as the system modeling language, combines the software design model and the model detection system model into one, and is completed by engineering and technical personnel during software design, thereby avoiding the need for engineering personnel to learn a special modeling language and establish a special system abstract model for system model detection and verification. The model is intuitive and visible, and it is easy to ensure the correctness of the model for complex systems.

[0093] The OPSL for describing system properties in the present invention replaces traditional complex sequential logic formulas with similar methods such as assertions, pre-conditions and post-conditions that are familiar to developers, describes the properties that the software system needs to meet as OPSL statements associated with the design model, and annotates them in the system design model in the form of xUML4MC model annotations, avoiding the need for engineers to learn complex sequential logic. The property description is intuitive, easy to master, efficient and convenient, and can accurately describe the property characteristics of each component of the software system.

[0094] The present invention provides a method for converting OPSL properties to PPTL property formulas, which automatically converts system properties described by OPSL property statements into semantically equivalent PPTL formulas, and further provides a method for constructing PPTL property formulas into property non-automaton CFAs. The property non-automaton CFA constructed by the present invention for PPTL property formulas can describe finite and infinite models of PPTL formulas, solve the judgment problem of PPTL formulas, and make full use of the rich expression ability of PPTL to verify more complex system properties.

[0095] The present invention provides a method for dynamically generating system states by interpreting and executing a syntax tree, and constructing a result automaton by performing AND operations with a corresponding property non-automaton CFA according to the constraint positions of OPSL property statements. The method can realize comprehensive detection and verification of global and local properties, and has a low memory space occupancy rate, which can effectively alleviate the occurrence of the state space explosion problem. BRIEF DESCRIPTION OF THE DRAWINGS

[0096] In order to more clearly illustrate the technical solutions of the embodiments of the present invention, the following briefly introduces the drawings required for use in the embodiments of the present invention. Obviously, the drawings described below are only some embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on these drawings without creative work.

[0097] Figure 1 It is a flow chart of the visual model detection method provided by an embodiment of the present invention.

[0098] Figure 2 and Figure 3 It is a schematic diagram of the abstract syntax tree (OOAST) structure with additional OPSL properties provided in an embodiment of the present invention.

[0099] Figure 4 It is a conversion flow chart of an OPSL property statement to a property non-automaton CFA provided by an embodiment of the present invention.

[0100] Figure 5 It is a flow chart of model detection operation of an embodiment of the present invention.

[0101] Figure 6 It is a structural block diagram of a visual model detection system provided by an embodiment of the present invention.

[0102] Figure 7 and Figure 8 It is a schematic diagram of a xUML4MC system design solution with OPSL properties marked provided by an embodiment of the present invention.

[0103] Fig. 9 It is a schematic diagram of an abstract syntax tree generated by converting the xUML4MC design model provided by an embodiment of the present invention.

[0104] Fig.10 It is a schematic diagram of a property non-automaton CFA constructed according to the PPTL property formula provided in an embodiment of the present invention.

[0105] Fig.11 It is a schematic diagram of the model detection result automaton and counterexample path provided by an embodiment of the present invention. DETAILED DESCRIPTION

[0106] In order to make the purpose, technical solution and advantages of the present invention more clearly understood, the present invention is further described in detail below in conjunction with the embodiments. It should be understood that the specific embodiments described herein are only used to explain the present invention and are not used to limit the present invention.

[0107] In view of the problems existing in the prior art, the present invention provides a visual model detection method, system, medium, device and processing terminal, and the present invention is described in detail below with reference to the accompanying drawings.

[0108] like Figure 1 As shown, the visual model detection method provided by the embodiment of the present invention includes the following steps:

[0109] S101, use xUML4MC class diagram and activity diagram to build system model, use OPSL to annotate the class, method, statement segment and property characteristics of the statement in the system model diagram;

[0110] S102, perform lexical and grammatical analysis on the xUML4MC model, construct an abstract syntax tree (OOAST) with OPSL properties, and perform integrity and consistency verification. OOAST contains all the information of class diagrams, activity diagrams, and OPSL property statements. The structure of OOAST is as follows: Figure 2 and Figure 3 ;

[0111] S103, convert each OPSL statement in OOAST into a PPTL property formula tuple (pptl_prop,map), and construct the corresponding property non-automaton CFA after negating the PPTL formula pptl_prop. The processing flow is as follows: Figure 4 As shown;

[0112] S104, execute OOAST to dynamically generate system status, and perform AND operation on the OPSL statement constraint position and the corresponding CFA to construct the result automaton. If there is no acceptable path in the result automaton, the property holds. Otherwise, the acceptable path is a counterexample path where the property does not hold. The processing flow is as follows: Figure 5 shown.

[0113] The visual model detection system provided by the embodiment of the present invention is composed as follows: Figure 6 As shown, specifically including:

[0114] Visual modeling module 101, which uses xUML4MC class diagrams and activity diagrams to build a design model of the software system, and uses OPSL to describe the properties of classes, methods, code snippets, and statements in an annotation manner;

[0115] OOAST construction module 102, used to perform lexical and grammatical analysis on the xUML4MC model and the annotated OPSL statements, construct an abstract syntax tree with additional OPSL properties, and perform integrity and consistency verification;

[0116] The OPSL conversion module 103 is used to convert each OPSL statement in the abstract syntax tree into a PPTL property formula tuple (pptl_prop, map), and construct a corresponding property non-automaton CFA after negating the PPTL property formula pptl_prop;

[0117] The model detection module 104 is used to execute the abstract syntax tree to dynamically generate the system state, and perform AND operations on the OPSL statement constraint positions and the corresponding CFA to construct the result automaton and detect whether there is a counterexample path.

[0118] The technical solution of the present invention is further described below in conjunction with specific embodiments.

[0119] The system modeling and verification process in the present invention uses a model checking tool based on xUML4MC.

[0120] The tool operating environment is as follows:

[0121] System: Windows 7 and above;

[0122] Memory: 2GB;

[0123] CPU:Inter i5 and above;

[0124] Software: JVM1.7 or later, JRE1.7 or later, Windows SDK 9.0 or later.

[0125] The technical solution adopted by the present invention involves the following technologies:

[0126] In terms of modeling of the system to be verified, xUML4MC (Extending UML for Model Checking) is used to describe the design model of the system. xUML4MC is a visual modeling language defined based on UML (Unified Modeling Language), an international standard modeling language in the field of software engineering. It extends the definition of UML activity diagrams based on the extensibility of the UML language, adds more detailed syntax and semantics, and has complete symbols, data types, syntax, and formal definitions to meet the system modeling requirements of model checking technology. The rest of the content is consistent with UML. xUML4MC unifies software system design modeling and model checking system modeling into one model, allowing software engineering technicians to complete them together during software design.

[0127] In terms of properties to be verified, OPSL (Object Property Specification Language) is used to annotate the xUML4MC design model with visual annotation symbols to describe the system properties. Special symbols are used to hide the complexity of describing the properties to be verified in traditional sequential logic. Different marking positions can be designed to flexibly control the constraint range of the properties expected by the system. Its statement structure is simple, the complexity is low, and it is easy for engineers to learn and use, which effectively reduces the difficulty for engineers to describe the properties that the program expects to meet.

[0128] The syntax definition of OPSL is shown in Table 1. OPSL statements (OPSL_Stmt) are in the form of xUML4MC comments and are identified by the keyword @OPSL. SEC_BEGIN and SEC_END are used to identify code snippets that need to be annotated and must appear in pairs. The definitions and meanings of OPSL keywords and operators are shown in Tables 2 and 3, respectively.

[0129] Table 1 OPSL definition

[0130]

[0131]

[0132] Table 2 OPSL keywords

[0133]

[0134] Table 3 OPSL operators

[0135]

[0136] The present invention extracts the OPSL statements in the xUML4MC design model and converts them into PPTL (Propositional Projection Temporal Logic) property formulas to complete model detection and verification. PPTL has the expressive power of a completely regular language and can verify more complex system properties than LTL, such as the closure property of repeated execution. It has been applied to software design solutions and program verification of typical systems such as communication protocols, memory management, and process schedulers. PPTL projection temporal logic is a common technology in this direction and will not be explained here.

[0137] The present invention relates to a method for converting a PPTL formula into a CFA (Complete Finite Automata). A complete finite automata is a six-tuple A = (Σ, Q, δ, I, F, C), where Σ is an alphabet, Q is a state set, and δ: Σ×Q→2 Qis a set of state transitions; I∈Q represents the set of initial states; is a finite set of acceptable states; In particular, if |I|=1 and δ is Σ×Q→Q, then A is called a deterministic total finite automaton (abbreviated as: deterministic CFA), otherwise it is a non-deterministic total finite automaton.

[0138] The model detection intersection operation process of the present invention uses the Z3 solver. The Z3 solver is a high-performance theorem prover developed by Microsoft Research. The Z3 solver is actually commonly used in software verification, program analysis, etc. in industrial applications. Due to the powerful functions of the Z3 solver, it is also used in many other fields, including software / hardware verification and testing, hybrid system analysis, security, biology (computer simulation analysis) and mathematical problems. In the field of network security, Z3 can be used to solve cryptographic problems, binary reversal, symbolic execution, fuzzing fuzz testing and other problems. In addition, the famous binary analysis framework Angr also has a modified version of the Z3 solver built in. The present invention uses the Z3 solver to solve the satisfiability problem after the intersection of the system state and the property non-automaton state.

[0139] The technical solution and application effects of the present invention are further described below in conjunction with the accompanying drawings.

[0140] This example is to model, describe the properties and verify the model of the "electric water heater system". A small water storage electric water heater, the critical temperature is 50℃, the preset temperature is 75℃, the water storage capacity is 80L, and the critical water level is 20L. When the water temperature is lower than 50℃ and the water level is greater than 20L, the water heater starts to heat until the water temperature reaches the preset temperature (the set temperature is 75℃), and enters the heating state when the temperature drops by 5℃; when the water level is lower than 20L, the automatic water filling mode is turned on until the maximum capacity is reached; and the cycle continues.

[0141] First, use xUML4MC in the model checking tool to create a system design solution, and annotate the system properties in the design model through OPSL statements.

[0142] The design class diagram of the electric water heater system is as follows Figure 7 As shown. The electric water heater is abstracted into the System class, which has two member variables, heater and water. The OPSL class property statement @OPSL ALWAYS (! (water.vol<20)) is marked on the System class, indicating that the water level of the water heater is always greater than or equal to 20L.

[0143] The constructor System() of the System class is the execution entry function of the electric water heater. The design scheme of the System() function and the constructor Heater() of the Heater class established by the activity diagram is as follows: Figure 8 In the Heater() function, the OPSL statement segment property statement @OPSL SEC_BEGIN REPEAT (state = 0, state = 1) and the annotation @OPSLSEC_END are used to mark a property of the statement segment, indicating that the statement segment allows the electric water heater to always be in a state of repeated heating and non-heating.

[0144] Then, the xUML4MC model is subjected to lexical and grammatical analysis, an object-oriented abstract syntax tree with OPSL properties is constructed, and a complete and consistent check is performed. The specific process is as follows:

[0145] (1) Extract model elements and relationships from the class diagram and activity diagram of the xUML4MC visualization model;

[0146] (2) Perform lexical and grammatical analysis on the classes, attributes, functions, statements, annotation elements and relationships of the xUML4MC model and create corresponding abstract syntax tree nodes;

[0147] (3) According to the logical relationship of the visualization model (inheritance, association, combination, aggregation, annotation, etc.), the abstract syntax tree nodes are constructed into an abstract syntax tree;

[0148] (4) OPSL statements are extracted from the annotations of the class and activity diagrams of the xUML4MC visual design model, and lexical and grammatical ,analysis is performed to construct the syntax tree of the OPSL statements and ,attach them to the corresponding nodes of the abstract syntax tree according to the OPSL ,constraint positions.

[0149] (5) Verify according to the abstract syntax tree integrity and consistency verification rules.

[0150] The abstract syntax tree constructed in this embodiment is shown in Fig. 9 .

[0151] Next, each OPSL statement in OOAST is converted into a PPTL property formula tuple (pptl_prop,map), and the corresponding property non-automaton CFA is constructed by negating the PPTL formula pptl_prop.

[0152] by Figure 7 Taking the OPSL properties marked on the System class in the class diagram as an example, the original OPSL properties are:

[0153] @OPSLALWAYS(!(water.vol<20))

[0154] The converted PPTL property formula binary is:

[0155]

[0156] in, The atomic proposition p represents the predicate formula water.vol<20. After finding the negative, we can construct a property non-automaton A(◇p)=(Σ,Q,δ,I,F,C) as Fig.10 As shown, where Q = {q1, q2, q3}, δ = {<q1,true,q2> ,<q2,true,q2> ,<q2,p,q3> ,<q3,true,q3>}, I = {q1}, F = {q3}, C = {{q3}}, that is, q3 is a finite acceptable state of the automaton, and there exists an infinite acceptable condition {q3}.

[0157] Finally, OOAST is executed to dynamically generate the system state, and the OPSL statement constraint position and the corresponding CFA are ANDed to construct the result automaton. The main process is described as follows:

[0158] (1) Take the System() function of the System class as the verification execution entry, initialize the result automaton rstCFA = (Σ, Q, δ, I, F, C), the automaton state is a two-tuple (stmt, stateSet), stmt is the abstract syntax tree statement, stateSet is the corresponding property automaton state set, Q = {(System(), {})}, I = {(System(), {})}, Push the initial state of rstCFA (System(),{}) into the backtracking stack and specify System() as the current verification function.

[0159] (2) Search for OPSL statements in the syntax tree of the System() function and calculate the set CFASet of non-automaton binary tuples (cfa, start:end) with constraint positions. The System class is annotated with the OPSL statement @OPSLALWAYS(!(water.vol<20)), which is applicable to all functions within the object lifetime. According to constraint range calculation rule 3, start is equal to the first statement of the System() function, end is equal to the last statement of the System() function, and cfa is Fig.10 CFA shown.

[0160] (3) Take out the top element (System(),{}) of the backtracking stack, traverse and interpret each statement stmt2 of the System() function according to the depth-first strategy, and use the interpretation and execution result rst2 of the current statement as the state q2 of the system automaton to perform an AND operation according to the constraint position and the corresponding state of the corresponding CFA in rstCFA (i.e. rst2∧q2), and then use the Z3 solver to solve rst1∧q2. If the solution result is "unsatisfiable", the current path search ends, and the next search path is popped from the backtracking stack for verification; if the solution result is "satisfiable", further judgment is made:

[0161] (a) If the result automaton rstCFA already has the state (stmt2,stateSet2) and the arc <(stmt0,stateSet0),rst2,(stmt2,stateSet2)> and q2∈stateSet2, then add a new arc <(stmt1,{q1}),rst2,(stmt2,stateSet2)> to the transition set δ of rstCFA, and check if the newly generated loop of rstCFA corresponds to an infinite acceptance condition of a non-automaton cfa of a certain property in CFASet, then the state sequence in the backtracking stack is a counterexample path that has not been found, and is added to the set CountExamPathSet, and the next search path is popped from the backtracking stack for verification.

[0162] (b) If the condition in (a) is not met, add a new state (stmt2,{q2}) to the state set Q of rstCFA, add a new arc <(stmt1,{q1}),rst2,(stmt2,{q2})> to the transition set δ, and push (stmt2,{q2}) into the backtracking stack. If there is a non-automaton tuple (cfa,start:end) in CFASet that satisfies stmt2 equals end and q2 is a finite acceptable state of cfa (i.e., q2∈F), add the state sequence in the backtracking stack to the counterexample path set CountExamPathSet, and pop the next search path from the backtracking stack for verification; otherwise, push the state (stmt2,{q2}) into the backtracking stack, and continue verification in this way until all paths are searched.

[0163] The corresponding relationship between the result automaton and the property automaton constructed in this embodiment and the OOAST execution state is as follows: Fig.11 As shown, since the last statement of the System() function is executed and it just corresponds to Fig.10There is a finite acceptable state q3 of cfa in the experiment, so a counterexample path where the property does not hold is found, indicating that the current design of the water heater cannot meet the minimum water volume requirement of 20L in the heating mode.

[0164] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When the use is implemented in whole or in part in the form of a computer program product, the computer program product includes one or more computer instructions. When the computer program instructions are loaded or executed on a computer, the process or function described in the embodiment of the present invention is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium, or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions may be transmitted from one website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL) or wireless (e.g., infrared, wireless, microwave, etc.) mode) to another website site, computer, server or data center. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk Solid State Disk (SSD)), etc.

[0165] The above description is only a specific implementation mode of the present invention, but the protection scope of the present invention is not limited thereto. Any modifications, equivalent substitutions and improvements made by any technician familiar with the technical field within the technical scope disclosed by the present invention and within the spirit and principle of the present invention should be covered by the protection scope of the present invention.

Claims

1. A visual model detection method, characterized in that: The visual model detection method uses xUML4MC to establish a system model, and uses OPSL to annotate the class, method, statement segment and property characteristics of the statement in the system model; Perform lexical and grammatical analysis on the system model, construct an abstract syntax tree with OPSL properties, and perform integrity and consistency checks; Convert each OPSL statement in the abstract syntax tree into a PPTL property formula and then negate it to construct the corresponding property non-automaton CFA; execute the abstract syntax tree to dynamically generate the system state, and perform AND operations on the OPSL statement constraint position and the corresponding CFA to construct the result automaton. If there is an acceptable path, it is a counterexample path where the property does not hold, otherwise the property holds; The rules for using OPSL to annotate system properties in the xUML4MC system model include: Rule 1: Use OPSL statements to describe the properties that all objects of a class should have from the time they are created to the time they are destroyed, and annotate them on the corresponding class nodes in the class diagram using xUML4MC annotation symbols, referred to as "class properties"; Rule 2: After describing the properties of a function during execution using OPSL statements, mark them on the starting node of the activity diagram corresponding to the function using the xUML4MC annotation symbol, referred to as "function properties"; Rule 3: Use OPSL statements to describe the properties of a statement fragment in a function during execution, and annotate it on the start and end nodes of the corresponding statement fragment in the activity diagram corresponding to the function through xUML4MC annotation symbols, referred to as "statement fragment properties"; Rule 4: Use OPSL statements to describe the properties of a statement in a function before execution, and annotate it on the corresponding statement node in the function activity diagram using xUML4MC annotation symbols, referred to as "assertion properties"; The method for constructing an abstract syntax tree with additional OPSL properties includes: (1) Extract model elements and relationships from the class diagram and activity diagram of the xUML4MC system model; (2) Perform lexical analysis and grammatical analysis on the model elements and create corresponding abstract syntax tree nodes; (3) According to the inheritance, association, combination, aggregation, and annotation relationships of the visual model elements, the syntax tree nodes are constructed into a syntax tree; (4) Extract OPSL statements from the annotations of the class diagram and interaction diagram of the xUML4MC system model, perform lexical and grammatical,analysis, construct the syntax tree of the OPSL statements, and attach them to the corresponding nodes of the,abstract syntax tree according to the constraint positions of the OPSL; The integrity and consistency checking rules of the abstract syntax tree include: Rule 5: The consistency between the method activity diagram and the class diagram, including the method name, parameter type and number; the validity of the internal variable name of the method, or the class contains inherited attributes, or the method formal parameters, or the defined local variables; Rule 6: Verification of OPSL statements, including whether the syntax conforms to the OPSL syntax definition and whether the referenced variable names are correct. Class properties can only reference class-defined attributes or inherited attributes, and the other three can only reference class attributes, method parameters, and defined local variables; The method of negating the PPTL property formula and constructing the corresponding property non-automaton CFA comprises: (1.1) Preprocess the PPTL property formula and replace all subformulas □P contained therein with Subformula ◇P is replaced by (true; P), and subformula P1→P2 is replaced by sub formula Replace with P; (1.2) Calculate the atomic proposition set Φ contained in the PPTL property formula and the alphabet of CFA (1.3) Construct the CFA of the PPTL property formula P. The rules include: Rule 1.3.1: If a property formula is an atomic proposition p, the CFA of p is A(p) = (∑, Q, δ, I, F, C), where the state set Q = {q0, q1}, the transition set δ = {<q0,p,q1> ,<q0,true,q1>}, initial state set I = {q0}, finite acceptable set F = {q1}, infinite acceptable condition set C = {{q1}}; Rule 1.3.2: If the property formula is P1∨P2, first construct the CFA of P1 and P2 respectively, let them be A(P1)=(∑,Q1,δ1,I1,F1,C1) and A(P2)=(∑,Q2,δ2,I2,F2,C2), and the final CFA is A(P1∨P2)=(∑,Q1∪Q2,δ1∪δ2,I1∪I2,F1∪F2,C1∪C2); Rule 1.3.3: If the property formula is P1∧P2, first construct the CFA of P1 and P2, let them be A(P1)=(∑,Q1,δ1,I1,F1,C1) and A(P2)=(∑,Q2,δ2,I2,F2,C2), respectively. The final CFA is A(P1∧P2)=(∑,Q,δ,I,F,C), where Q={[q 1 ,q 2 ]|q 1 ∈Q1,q 2 ∈Q2}, I={[q 1 ,q 2 ]|q 1 ∈I1,q 2 ∈I2}, F={[q 1 ,q 2 ]|q 1 ∈F1,q 2 ∈F2}, C={{[q 1 ,q 2 ]|q 1 ∈Δ1,q 2 ∈Δ2}|Δ1∈C1,Δ2∈C2}; Rule 1.3.4: If the property formula is P 1； P2, first construct the CFA of P1 and P2 respectively, let them be and A(P2)=(Σ,Q2,δ2,I2,F2,C2), the final CFA is A(P1;P2)=(Σ,Q1∪Q2,δ1∪δ2∪δ a I1, F2, C2), where Rule 1.3.5: If the property formula is First construct the CFAA(P1)=(∑,Q1,δ1,I1,F1,C1) of P1, and the final CFA is in and Rule 1.3.6: If the property formula is First construct the CFA of P1 A(P1) = (∑, Q1, δ1, I1, F1, C1), and use the subset construction method to convert A(P1) into a deterministic CFA The final CFA is The execution abstract syntax tree dynamically generates the system state, and performs AND operation according to the OPSL statement constraint position and the corresponding CFA to construct a result automaton. If there is no acceptable path in the result automaton, the property holds, otherwise the acceptable path is a counterexample path where the property does not hold. The specific method includes: (2.1) Use the abstract syntax tree to specify the entry function fun of the model checking verification to initialize the result automaton rstCFA=(Σ,Q,δ,I,F,C), the automaton state is a two-tuple (stmt,stateSet), stmt is the statement in the abstract syntax tree, stateSet is the state set of the corresponding property automaton, Q={(fun,{})}, I={(fun,{})}, Push the initial state of rstCFA (fun,{}) into the backtracking stack and specify fun as the current verification function; (2.2) Calculate the set CFASet of property non-automaton binary tuples (cfa, start:end) with constraint positions according to the OPSL statements annotated in the current verification function, where cfa is the property non-automaton, start and end are the starting and ending positions of the cfa constraint; (2.3) If the current function is annotated with the OPSL function property statement prop, construct a tuple (cfa, start:end) and add it to CFASet, where cfa is the property non-automaton corresponding to prop, start is equal to the first statement position of the function, and end is equal to the last statement position of the function; (2.4) Take out the top element (stmt, stateSet) of the backtracking stack. For all non-automaton tuples (cfa, start:end) in CFASet, if start is equal to stmt, let stateSet = stateSet∪I, where I is the initial state set of cfa; execute the stmt statement of the top element of the stack, and let the result be rst; (2.5) If Then go to step (2.8), otherwise take out each cfa state q in stateSet in turn, and enumerate the unsearched arcs starting from state q<q,α,q1> , go to step (2.6); (2.6) Use the Z3 solver to calculate the satisfiability of the conjunction formula of rst and α. If the result is false, go to step (2.9); otherwise, according to the abstract syntax tree execution rules, take out the next statement to be executed stmt1 of the stmt statement, and dynamically expand the result automaton rstCFA. The rules include: Rule 2.6.1: If there is a state (stmt1, stateSet1) and an arc <(stmt0, stateSet0),rst,(stmt1, stateSet1)> in rstCFA and q1∈stateSet1, compute the union sset of all stateSets on the path from state (stmt1, stateSet1) to state (stmt, stateSet) in rstCFA, if there is a cfa in CFASet that satisfies an infinite acceptance condition c Add the state sequence in the backtracking stack to the counterexample path set CountExamPathSet, and go to step (2.9); Rule 2.6.2: If the condition of Rule 2.6.1 is not met, add a new state (stmt1,{q1}) to the state set Q of rstCFA, and add a new arc <(stmt,stateSet),rst,(stmt1,{q1})> to the transition set δ; if there is a non-automaton tuple (cfa,start:end) in CFASet that satisfies stmt1 equals end and q1 is a finite acceptable state of cfa, that is, q1∈F, add the state sequence in the backtracking stack to the counterexample path set CountExamPathSet; push the state (stmt1,{q1}) into the backtracking stack, and go to step (2.4); (2.7) If there are unsearched arcs in stateSet<q,α,q1> , then go to step (2.5), otherwise go to step (2.9); (2.8) According to the abstract syntax tree execution rules, the next statement to be executed, stmt1, of the stmt statement is taken out, and the result automaton rstCFA is dynamically expanded. The rules include: Rule 2.8.1: If there is a state (stmt1, stateSet1) and an arc <(stmt0, stateSet0), rst, (stmt1, stateSet1)> in rstCFA, go to step (2.9); Rule 2.8.2: If the condition of Rule 2.8.1 is not met, add the state (stmt1,{}) to the state set Q of rstCFA, add the arc <(stmt,{}),rst,(stmt1,{})> to the transition set δ; push the state (stmt1,{}) into the backtracking stack, and go to step (2.4); (2.9) Pop the top element (stmt, stateSet) of the backtracking stack and delete the state (stmt, stateSet) and its associated arcs from rstCFA; if the backtracking stack is not empty, go to step (2.4), otherwise go to step (2.10); (2.10) If the set of counterexample paths Output the property to be verified if it is true, otherwise output the counterexample paths saved in CountExamPathSet one by one; In the step (2.2), a set CFASet of property non-automaton binary tuples (cfa, start: end) with constraint positions is calculated according to the OPSL statements marked on the function, and each statement of the function is traversed according to the depth-first strategy to calculate the property non-automaton binary tuples with constraint positions and add them to CFASet. The specific rules include: Rule 2.2.1: If the current class is annotated with the OPSL class property prop, construct a tuple (cfa, start:end) and add it to CFASet. The start of the tuple is equal to the position of the next statement of the statement annotated with prop, and the end is equal to the position of the statement before the object is destroyed. Rule 2.2.2: If the current code snippet is annotated with the start property statement prop_start and the end property statement prop_end of the OPSL code snippet property, construct a tuple (cfa, start:end) and add it to CFASet. The start of the tuple is equal to the position of the next statement of the statement annotated with prop_start, and the end is equal to the position of the statement annotated with prop_end. Rule 2.2.3: If the current code snippet is annotated with the OPSL assertion property prop, construct a tuple (cfa, start:end) and add it to CFASet. The start of the tuple is equal to the position of the statement annotated with prop, and the end is equal to the position of the statement annotated with prop. In the step (2.4), the stmt statement of the top element of the stack is executed, and the result is rst; the execution rules include: Rule 2.4.1: For a common statement node, select the successor node of the current node as the next statement node to be executed; Rule 2.4.2: For an if statement node, calculate the value of the conditional expression in the if statement, and select the first node of the corresponding YES or NO branch as the next statement node to be executed according to the true or false result; Rule 2.4.3: For a while statement node, calculate the value of the conditional expression in the while statement. If the result is true, select the first node of the YES branch as the next node to be executed. Otherwise, select the successor node of the while loop as the next statement node to be executed. Rule 2.4.4: For a function call statement node, after calculating the value of each actual parameter expression and assigning it to the corresponding function formal parameter, the first statement of the called function is used as the next statement node to be executed.

2. A visual model detection system for implementing the visual model detection method according to claim 1, characterized in that: The visual model detection system comprises: Visual modeling module, used to build system models based on xUML4MC class diagrams and activity diagrams, and use OPSL to describe the properties of classes, methods, code snippets, and statements in annotated form; Abstract syntax tree construction module, used to perform lexical and grammatical analysis on the xUML4MC system model and annotated OPSL statements, construct an abstract syntax tree with OPSL properties, and perform integrity and consistency verification; The OPSL conversion module is used to convert each OPSL statement in the abstract syntax tree into a PPTL property formula, and construct a corresponding property non-automaton CFA after negating the PPTL property formula; The model checking module is used to execute the abstract syntax tree to dynamically generate the system state, and perform AND operations on the OPSL statement constraint positions and the corresponding CFA to construct the result automaton and detect whether there is a counterexample path.

3. A computer device, characterized in that: The computer device comprises a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor executes the steps of the method according to claim 1 .

4. A computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, the processor executes the steps of the method according to claim 1.

5. An information data processing terminal, characterized in that: The information data processing terminal is used to implement the visual model detection system as claimed in claim 2.

Images