Synchronous reaction component-oriented software architecture model correctness verification method

Abstract

The invention discloses a software architecture model correctness verification method oriented to a synchronous reaction type component, and relates to the technical field of model verification, in the method, a source model in an XML format is analyzed by means of a Dom4j package, and model nodes, migration and global variable information are extracted, classified and stored. Then, a mapping rule from a software architecture model to PROMELA codes is designed, and conversion of a model structure, data and various elements is covered; security and activity verification attributes are defined by using an SPIN tool, and the branch accessibility of the control node is judged through a control variable and assertion. From the starting node, the model elements are sequentially converted into variables, channels and processes of PROMELA. And finally, generating a verification script, performing grammar check and attribute verification on the converted model, analyzing a verification report to obtain a result, and repeating operation if other attributes need to be verified. The method provides a systematic and effective means for ensuring the correctness of the software architecture model.

Description

Technical Field

[0001] The present invention relates to the technical field of model verification, and particularly relates to a method for verifying the correctness of a software architecture model for synchronous reactive components. Background Art

[0002] The use of a software architecture model for synchronous reactive components can improve the development efficiency of a software system. Therefore, in the design and development process of a software system, the importance of software system modeling has been highlighted. At the same time, new problems have also arisen, that is, whether the software architecture model established by this modeling method is correct. The correctness of a software architecture model for synchronous reactive components will directly affect the subsequent development process. If the model is established inaccurately or incorrectly, it will directly affect the function and even the security of the software system. Therefore, the correctness of the model is very important. Therefore, it is particularly important to invent a method for verifying the correctness of a software architecture model for synchronous reactive components.

[0003] The prior art, such as an invention patent application with the publication number CN110502211A, discloses a method for constructing an AADL model based on a SysML module diagram, including the following steps: Step 1, classifying modules based on the SysML module diagram; Step 2, constructing an ADDL component type declaration based on the SysML module diagram; Step 3, constructing an AADL component type implementation based on the SysML module diagram; Step 4, constructing the state of an AADL component based on the SysML state machine diagram; Step 5, constructing the state transition of an AADL component based on the SysML state machine diagram. Through the present invention, a user can realize the automatic construction of an AADL model based on a SysML module diagram, can take into account the non-functional attributes of the overall system model and the subsystem model on the basis of maintaining the embedded system architecture model and the association relationship of the subsystem model, complete the modeling and verification of the embedded system architecture from the software level to the hardware level, and can also verify the feasibility and correctness of the system architecture model in the early stage of software development, discover problems in the system architecture as early as possible, reduce the cost of system development, and achieve the goal of high reliability of the overall system.

[0004] The prior art also has the following defects, specifically reflected in: 1. In the prior art, when converting a software architecture model into code or a model supported by a model checking tool, a complete set of mapping rules cannot be established to complete the specific description of the model to be verified, resulting in difficulties in accurately and completely describing the detailed features, behavioral logic, and associations between various components of various models to be verified during the actual operation process, resulting in a chaotic code structure, which is difficult to meet the requirements of the model checking tool SPIN, unable to quickly and effectively verify the model, and reducing the verification efficiency and accuracy.

[0005] 2. In the prior art, when using SPIN to verify a model, it is impossible to intuitively obtain the execution status of each branch path. The description of the properties to be verified during the model verification process is overly dependent on researchers. It is necessary to manually write the verification conditions for the corresponding properties for each model. To effectively verify various system interaction behaviors such as branches, loops, and concurrency in a software architecture model for synchronous reactive components, the workload of manually writing verification properties is extremely large, and the verification efficiency is difficult to guarantee. Summary of the Invention

[0006] The purpose of the present invention is to provide a method for verifying the correctness of a software architecture model for synchronous reactive components, which solves the problems existing in the background technology.

[0007] To solve the above technical problems, the present invention adopts the following technical solutions: The present invention provides a method for verifying the correctness of a software architecture model for synchronous reactive components, including: Step 1: Parse the source model according to the XML data storage format of the software architecture model for synchronous reactive components, extract the model content, and design a data structure to store model information, including various model nodes and the relationships between the nodes in the model.

[0008] Step 2: Design the mapping rules from the software architecture model to PROMELA code, including the conversion of the model structure, data mapping rules, and mapping rules for various model elements.

[0009] Step 3: Define the properties to be verified for the model to be verified, and for various control nodes, solve the verification problem of the reachability of branch nodes by generating control variables and adding assertions.

[0010] Step 4: Convert the model to PROMELA code sequentially from the start node, and generate variables, channels, and processes in the PROMELA code.

[0011] Step 5: Generate a verification script based on the verification properties, and use a model checker to detect the model to be verified, find the error path, and parse the verification report at the same time.

[0012] Preferably, for Step 1, the specific implementation method is: Step 1-1: Parse the XML file storing the software architecture model information of synchronous reactive components with the help of the Dom4j package.

[0013] Step 1-2: Classify the extracted model node information. The nodes are divided into three categories: activity nodes, state nodes, and control nodes.

[0014] Step 1-3: Process the extracted migration information. For each Transition, save the information including: id, sourceName, targetId, specification.

[0015] Step 1-4: During the parsing process of the model, save the nodes and migrations, and save the existing global model variables.

[0016] Preferably, for Step 2, the specific implementation method is as follows: Step 2-1: Perform the conversion of the model structure. Convert each model node individual of the software architecture model into a process in PROMELA, and according to the read migration relationship between the corresponding activities and states, convert the migration relationship into a channel in the PROMELA model. For the model attributes such as variables, constants, structures, operations, etc. defined by the user during modeling in the software architecture model, convert them into data types supported in the PROMELA model according to the rules.

[0017] Step 2-2: Design data mapping rules, including variable mapping rules, constant mapping rules, event mapping rules, operation mapping rules, and structure mapping rules.

[0018] Step 2-3: Design various model element mapping rules, including transition mapping rules, activity node mapping rules, state node mapping rules, and control node mapping rules.

[0019] Preferably, for Step 2-2, the specific implementation method is as follows: Step 2-2-1: For the variable mapping rules, the software architecture model supports 5 basic data types, including integer, real, string, boolean, void, which are correspondingly converted to int, int, byte[], bool, void in PROMELA.

[0020] Step 2-2-2: For the constant mapping rules, the data type mapping is the same as that of the variable mapping. Replace the keyword "const" for defining constants in the software architecture model with "#define" in the PROMELA model.

[0021] Step 2-2-3: For the event mapping rules, map the events in the software architecture model to two variables in the PROMELA model. One bool-type variable is used to identify whether the event is called, and the type of the other variable is mapped according to the variable mapping rules for the event type.

[0022] Step 2-2-4: For the operation mapping rules, construct PROMELA variables through the variable mapping rules, process the variables through processes, and finally define the channels in PROMELA to return the variable values.

[0023] Step 2-2-5: For the structure mapping rule, the definition of the structure in the software architecture model starts with the struct keyword and ends with scoppend. When converting to PROMELA code, it is defined with the typedef struct keyword and declared with the struct keyword when used. For the variables or constants within the structure, they are mapped according to the methods in Steps 2-2-1 and 2-2-2.

[0024] Preferably, for Step 2-3, the specific implementation method is as follows: Step 2-3-1: For the transition mapping, when converting to the PROMELA model, the transition mapping is converted to a channel, and the guard condition is converted to the judgment logic or assertion in PROMELA and added before the channel.

[0025] Step 2-3-2: For the active node mapping, the process is defined with the keyword active proctype plus the id of the activity. According to the number of transitions connected to the activity, PROMELA channels are generated and added to the process. The content in the activity specification is filled into the middle part of the process to complete the conversion of the active node.

[0026] Step 2-3-2: For the state node mapping, it is defined with the atomic keyword and converted to the atomic structure in PROMELA. The migration information is converted to a channel and placed in the atomic structure.

[0027] Step 2-3-3: For the control node mapping, the mapping rule for converting the control node to the PROMELA process framework is the same as that in Step 2-3-1. After obtaining the process framework, it is processed according to the classification and added to the process to complete the conversion of the control node.

[0028] Preferably, for Step 3, the specific implementation method is as follows: Step 3-1: With the help of the model checking tool SPIN, focus on verifying the security and liveness of the software architecture model. Among them, the security includes two attributes: deadlock and assertion conflict, and the liveness includes two attributes: reachability of activities and livelock.

[0029] Step 3-2: For the verification of the reachability of the control node, during the execution of SPIN, by judging the correctness of the assertion, the execution situation of each branch in the control node is obtained, so as to determine its reachability.

[0030] Preferably, the specific implementation method of step 4 is as follows: Step 4-1: Determine whether global variables are defined in the software architecture model. For the defined global variables, according to the mapping rules in step 2-2, convert them into variables in the PROMELA model. At the same time, declare a set of channels, and all channels used in the subsequent model conversion process need to be added to this set.

[0031] Step 4-2: Traverse the software architecture model starting from InitialActivity, generate PROMELA processes for the model nodes, define process declarations according to the names of the activities, generate the framework of the processes according to the types of the nodes and the mapping rules in step 2-3, and define channels according to the ids of the transitions and add them to the set of channels. After obtaining the process framework, generate logical code according to the specification parsed from the activity before and fill it into the process.

[0032] Step 4-3: Repeat the operation in step 4-2 to convert each node in the software architecture model until the conversion of FinalActivity is completed and then end.

[0033] Preferably, the specific implementation method of step 5 is as follows: Step 5-1: Before using the model checker to verify the converted PROMELA model, perform a syntax check and modify the places with syntax errors.

[0034] Step 5-2: Perform the verification of model properties, select the properties for single verification, including deadlock, assertion conflict, livelock, reachability, and possibly existing LTL formulas. After selecting the properties to be verified, generate verification scripts according to different combination methods, automatically complete the setting of verification parameters in the scripts, as well as the setting of the save paths of the verification intermediate files and verification reports. After the scripts are generated, execute the scripts through the command line and use SPIN to verify the model.

[0035] Step 5-3: Parse the verification report, extract the verification results. If other properties need to be verified, repeat step 5-2.

[0036] The beneficial effects of the present invention are as follows: 1. In the present invention, the software architecture model is converted into a PROMELA model as the input language of the model checker SPIN to verify relevant properties of the model. A mapping rule from the software architecture model based on synchronous reactive components to the PROMELA model and an automatic PROMELA code generation method are proposed; the generated code has a clear structure, can meet the requirements of the model checker SPIN, and can achieve the effect of quickly verifying the model.

[0037] 2. In the present invention, in view of the problem that the execution status of each branch path cannot be intuitively obtained through SPIN traversal, a verification method for control node reachability is proposed. By adding control variables and assertions to the control nodes XorSplit, AndSplit, XorJoin, and AndJoin, and verifying whether the assertion expression holds, the execution status of conditional branches is fed back. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] In order to more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the following will briefly introduce the drawings required for the description of the embodiments or the prior art. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0039] Figure 1 It is a schematic flowchart of the implementation steps of the method of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0040] The following will clearly and completely describe the technical solutions in the embodiments of the present invention with reference to the drawings in the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, rather than all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those of ordinary skill in the art without creative efforts belong to the scope of protection of the present invention.

[0041] Refer to Figure 1 As shown, the present invention provides a method for verifying the correctness of a software architecture model for synchronous reactive components, including: Step 1: Parse the source model according to the XML data storage format of the software architecture model for synchronous reactive components, extract the model content, and design a data structure to store the model information, including various types of model nodes and the relationships between the nodes in the model.

[0042] In a specific embodiment, the implementation method of the said Step 1 is: Step 1-1: Parse the XML file storing the software architecture model information of synchronous reactive components with the help of the Dom4j package. In the XML file, <sgraph:statechart>The data under the label is a collection of all the contents of the entire model. Among them, the data of each node is stored in <vertices>In the label, the migrated data in the model is stored in <outgoingtransitions>In the label.

[0043] Step 1-2: Classify the extracted model node information. The nodes are divided into three categories: activity nodes, state nodes, and control nodes. Activity nodes include InitialActivity, SimpleActivity, CompositeActivity, and FinalActivity. State nodes include InitialState, State, and FinalState. Control nodes include XorSplit, XorJoin, AndSplit, and AndJoin. For activity nodes, save the information such as name, id, type, Specification, and transition within their labels. The information saving method for state nodes is similar to that of activity nodes. For control nodes, there may be multiple transition states, so multiple transition states need to be saved during saving.

[0044] Step 1-3: Process the extracted transition information. For each Transition, the saved information includes: id, sourceName, targetId, and specification.

[0045] It should be noted that sourceName is the starting node of the transition, targetId is the target node id, and specification is the conversion condition.

[0046] Step 1-4: During the model parsing process, save the nodes and transitions, and save the existing model global variables. Through parsing <regions>Labels can extract all global variable information.

[0047] Step 2: Design the mapping rules from the software architecture model to PROMELA code, including the conversion of the model structure, data mapping rules, and mapping rules for various model elements.

[0048] In the present invention, the software architecture model is converted into a PROMELA model, which serves as the input language for the model checker SPIN. Relevant property verification is performed on the model. A mapping rule from the software architecture model based on synchronous reactive components to the PROMELA model and an automatic PROMELA code generation method are proposed. The generated code has a clear structure, can meet the requirements of the model checker SPIN, and can achieve the effect of quickly verifying the model.

[0049] In a specific embodiment, the specific implementation method of Step 2 is as follows: Step 2-1: Perform the conversion of the model structure. Each model node individual of the software architecture model is converted into a process in PROMELA. According to the read migration relationship between corresponding activities and states, the migration relationship is converted into a channel in the PROMELA model. For model attributes such as variables, constants, structures, and operations defined by users during modeling in the software architecture model, they are converted into data types supported in the PROMELA model according to the rules.

[0050] The storage of the software architecture model oriented to synchronous reactive components mainly depends on the storage of data definitions, activities, states, control elements, and transitions. The storage of the PROMELA model mainly includes three parts: channels, data objects, and processes. The change modes of each part during the conversion process are as follows: First, perform the conversion of the model node structure. Each model node individual of the software architecture model is converted into a process in PROMELA. According to the read migration relationship between corresponding activities or states, the migration relationship is converted into a channel in the PROMELA model. For model attributes such as variables, constants, structures, and operations defined by users during modeling in the software architecture model, they are converted into data types supported in the PROMELA model according to the rules.

[0051] Step 2-2: Design data mapping rules, including variable mapping rules, constant mapping rules, event mapping rules, operation mapping rules, and structure mapping rules.

[0052] Step 2-3: Design mapping rules for various model elements, including transition mapping rules, activity node mapping rules, state node mapping rules, and control node mapping rules.

[0053] In a specific embodiment, the specific implementation method of step 2-2 is as follows: Step 2-2-1: For the variable mapping rule, there are 5 basic data types supported in the software architecture model, including integer, real, string, boolean, and void, which are correspondingly converted to int, int, byte[], bool, and void in PROMELA.

[0054] Since the string and floating-point types are not supported in the PROMELA language, during the conversion, the floating-point type will be multiplied and converted to an integer type. For the string type, the corresponding characters will be converted to numbers according to the ASCII code values and put into a byte array.

[0055] Step 2-2-2: For the constant mapping rule, the mapping of data types is the same as that of variable mapping. The keyword "const" for defining constants in the software architecture model is replaced by "#define" in the PROMELA model.

[0056] Step 2-2-3: For the event mapping rule, the events in the software architecture model are mapped to two variables in the PROMELA model. A bool-type variable is used to identify whether the event is called, and the type of the other variable is mapped according to the variable mapping rule for the event type.

[0057] Step 2-2-4: For the operation mapping rule, PROMELA variables are constructed through the variable mapping rule, and the variables are processed through processes. Finally, a channel in PROMELA is defined to return the variable values. Since the operations in the software architecture model are usually used to interact with the external environment, there is information transfer and function calls. Channels are used in the PROMELA model to transfer variables, and functions can be converted into processes. Therefore, after mapping, two parts are generated. First, for the operation return type, PROMELA variables are constructed through the variable mapping rule, and the variables are processed through processes. Finally, a channel in PROMELA is defined to return the variable values.

[0058] Step 2-2-5: For the structure mapping rule, the definition of the structure in the software architecture model starts with the struct keyword and ends with scoppend. When converting to PROMELA code, it is defined with the typedefstruct keyword and declared with the strcut keyword when used. For the variables or constants within the structure, the mapping methods in steps 2-2-1 and 2-2-2 are followed.

[0059] In a specific embodiment, the specific implementation method of step 2-3 is as follows: Step 2-3-1: For the transition mapping, in the conversion to the PROMELA model, it is defined through the keyword chan. For example, "chantrans = [n] of {int}" converts the transition mapping into a channel, and converts the guard condition into a judgment logic or assertion in PROMELA and adds it before the channel. The basic elements to which all activities of the transition are connected play a role in describing the control flow in the model. Usually, a transition also includes a guard condition.

[0060] Step 2-3-2: For the activity node mapping, the process is defined through the keyword activeproctype plus the id of the activity. According to the number of transitions connected to the activity, PROMELA channels are generated and added to the process, and the content in the activity specification is filled into the middle part of the process to complete the conversion of the activity node.

[0061] Specifically, for complex activity nodes, only the process framework and the corresponding channels need to be generated first. For the states in complex activities, after being converted according to the state node mapping rules, they are filled into the process after the conversion of the complex activity node.

[0062] Step 2-3-2: For the state node mapping, it is defined through the atomic keyword and converted into an atomic structure in PROMELA. The migration information is converted into a channel and placed in the atomic structure. The mapping rule of the state node is similar to that of the activity node, but the difference is that the state node must exist in the complex activity node, so there is no need to generate a process framework. The information specification contained in the state node is filled into the middle part of the atomic after parsing to complete the conversion of the state node.

[0063] Step 2-3-3: For the control node mapping, the mapping rule for converting the control node into the PROMELA process framework is the same as that in step 2-3-1. After obtaining the process framework, it is processed according to the classification and added to the process to complete the conversion of the control node. Since the control node often contains multiple migrations, the control node mapping mainly focuses on the processing of migrations. For a branch node, the migrations related to this node are converted into the form of conditional branches plus channels in PROMELA code, such as: "if guard condition -> channel... fi". For an aggregation node, the AndJoin type can directly convert each migration into a channel and fill them into the process in sequence, while the XorJoin type needs to be converted into the form of a loop plus channels in PROMELA code, such as "do guard condition -> break... od".

[0064] Step 3: Define the properties to be verified for the model to be verified, and for each type of control node, solve the verification problem of the reachability of branch nodes by generating control variables and adding assertions.

[0065] In a specific embodiment, the specific implementation method of the said Step 3 is as follows: Step 3-1: With the help of the model checking tool SPIN, focus on verifying the safety and liveness of the software architecture model, where the safety includes two properties: deadlock and assertion conflict, and the liveness includes two properties: reachability of activities and livelock.

[0066] Step 3-2: For the verification of the reachability of control nodes, during the execution of SPIN, by judging the correctness of assertions, obtain the execution situation of each branch in the control node, so as to determine its reachability.

[0067] In the present invention, aiming at the problem that the execution situation of each branch path cannot be intuitively obtained through SPIN traversal, a verification method for the reachability of control nodes is proposed. By adding control variables and assertions in the control nodes XorSplit, AndSplit, XorJoin, and AndJoin, and verifying whether the assertion expression holds, the execution situation of the conditional branch is fed back.

[0068] For the verification of the reachability of control nodes, the execution situation of each branch path cannot be intuitively obtained through SPIN traversal. Therefore, it is necessary to add control variables and assertions, and verify whether the assertion expression holds to feed back the execution situation of the conditional branch. Add control variables to the control nodes with branches XorSplit and AndSplit, and the control variable set of this node is defined as BC = {branch 0 , branch 1 ,..., branch n}, and the maintenance of the variables is managed by the corresponding conditional branches. Each time this path is executed, the variable is incremented. Add an assertion expression assert(exp) for the property to be verified in the aggregation node. For example, add an assertion assert(branch 0 + branch 1 +... + branch n == 0) to the XorJoin node.

[0069] Step 4: Sequentially perform the conversion from the model to PROMELA code starting from the start node, and generate variables, channels, and processes in the PROMELA code.

[0070] In a specific embodiment, the specific implementation method of step 4 is as follows: Step 4-1: Determine whether global variables are defined in the software architecture model, and convert the defined global variables into variables in the PROMELA model according to the mapping rules of step 2-2. At the same time, declare a channel set, and all channels used in the subsequent model conversion process need to be added to the set.

[0071] Step 4-2: Traverse the software architecture model from InitialActivity, generate PROMELA processes from model nodes, define process declarations according to the name of the activity, generate the framework of the process according to the node type and the mapping rules of step 2-3, and define channels according to the ID of the transition, add them to the channel collection, and after obtaining the process framework, generate logic code and fill it into the process according to the specification obtained by parsing the activity before. In particular, for control nodes, it is necessary to add control variables to different branch paths according to step 3-2, and add assertions at aggregation nodes.

[0072] Step 4-3: Repeat the operation in step 4-2 to convert each node in the software architecture model until the FinalActivity conversion is completed.

[0073] Step 5: Generate a verification script based on the verification properties, and use the model detection tool to detect the model to be verified, find the error path, and parse the verification report.

[0074] In a specific embodiment, the step 5 is specifically implemented as follows: Step 5-1: Before using the model checking tool to verify the converted PROMELA model, a syntax check is performed and syntax errors are corrected.

[0075] Step 5-2: Verify the model attributes and select the attributes for single verification, including deadlock, assertion conflict, livelock, reachability and possible LTL formulas. After selecting the attributes to be verified, generate a verification script according to different combinations. The script automatically completes the setting of verification parameters, verification intermediate files, and the save path of the verification report. After the script is generated, execute the script through the command line and verify the model with the help of SPIN.

[0076] Step 5-3: Parse the verification report and extract the verification results. If other attributes need to be verified, repeat step 5-2.

[0077] The above content is only an example and illustration of the concept of the present invention. Those skilled in the art of the present technology can make various modifications or supplements to the described specific embodiments or use similar methods for substitution, as long as they do not deviate from the concept of the invention or exceed the scope defined by the present invention, they shall fall within the protection scope of the present invention.< / regions> < / outgoingtransitions> < / vertices> < / sgraph:statechart>

Claims

1. A method for verifying the correctness of a software architecture model for synchronous reactive components, characterized in that: include: Step 1: Parse the source model according to the XML data storage format of the software architecture model for synchronous reactive components, extract the model content, and design a data structure to store the model information, including various model nodes and the relationship between the nodes in the model; Step 2: Design the mapping rules from the software architecture model to the PROMELA code, including the conversion of the model structure, data mapping rules, and mapping rules of various model elements; Step 3: Define the attributes that need to be verified for the model to be verified, and solve the verification problem of branch node reachability by generating control variables and adding assertions for various control nodes; Step 4: Convert the model to PROMELA code sequentially from the starting node to generate variables, channels, and processes in the PROMELA code; Step 5: Generate a verification script based on the verification properties, and use the model detection tool to detect the model to be verified, find the error path, and parse the verification report.

2. According to the method for verifying the correctness of a software architecture model for synchronous reactive components according to claim 1, it is characterized in that: The specific implementation method of step 1 is as follows: Step 1-1: Use the Dom4j package to parse the XML file storing the synchronous reactive component software architecture model information; Step 1-2: Classify the extracted model node information into three categories: active nodes, state nodes, and control nodes; Step 1-3: Process the extracted migration information. For each Transition, save the following information: id, sourceName, targetId, and specification. Steps 1-4: During the parsing process of the model, save the nodes and migrations, and save the existing model global variables.

3. According to a method for verifying the correctness of a software architecture model for synchronous reactive components according to claim 1, it is characterized in that: The specific implementation method of step 2 is as follows: Step 2-1: Convert the model structure, convert each model node of the software architecture model into a process in PROMELA, and convert the migration relationship between the corresponding activities and states into a channel in the PROMELA model. For the model attributes such as variables, constants, structures, operations, etc. defined by the user in the software architecture model during modeling, convert them into data types supported by the PROMELA model according to the rules; Step 2-2: Design data mapping rules, including variable mapping rules, constant mapping rules, event mapping rules, operation mapping rules and structure mapping rules; Step 2-3: Design various model element mapping rules, including transition mapping rules, activity node mapping rules, state node mapping rules, and control node mapping rules.

4. The method for verifying the correctness of a software architecture model for synchronous reactive components according to claim 3 is characterized in that: The specific implementation method of step 2-2 is as follows: Step 2-2-1: For variable mapping rules, the software architecture model supports 5 basic data types, including integer, real, string, boolean, and void, which are converted to int, int, byte[], bool, and void in PROMELA; Step 2-2-2: For the constant mapping rules, the mapping of data types is the same as that of variables. Replace the keyword "const" that defines constants in the software architecture model with "#define" in the PROMELA model. Step 2-2-3: For the event mapping rules, the events in the software architecture model are mapped to two variables in the PROMELA model. One bool type variable is used to identify whether the event is called, and the type of the other variable is mapped to the event type according to the variable mapping rules; Step 2-2-4: For the operation mapping rules, construct PROMELA variables through variable mapping rules, process variables through processes, and finally define the channel in PROMELA to return the variable value; Step 2-2-5: For the structure mapping rules, the definition of the structure in the software architecture model starts with the struct keyword and ends with scoppend. When converted to PROMELA code, it is defined with the typedefstruct keyword and declared with the strcut keyword when used. For variables or constants in the structure, they are mapped according to the methods in steps 2-2-1 and 2-2-2.

5. The method for verifying correctness of a software architecture model for synchronous reactive components according to claim 3, characterized in that: The specific implementation method of steps 2-3 is as follows: Step 2-3-1: For transition mapping, when converting to PROMELA model, convert the transition mapping into a channel, and convert the guard condition into judgment logic or assertion in PROMELA, and add it before the channel; Step 2-3-2: For activity node mapping, define the process by adding the keyword activeproctype to the activity id. Generate a PROMELA channel based on the number of transitions connected to the activity, add it to the process, and fill the content in the activity specification into the middle part of the process to complete the conversion of the activity node. Step 2-3-2: For the state node mapping, define it through the atomic keyword, convert it into the atomic structure in PROMELA, and convert the migration information into a channel and put it into the atomic structure; Step 2-3-3: For control node mapping, the mapping rules for converting control nodes to PROMELA process frames are the same as step 2-3-1. After obtaining the process frame, it is processed according to the classification and added to the process to complete the conversion of the control node.

6. The method for verifying correctness of a software architecture model for synchronous reactive components according to claim 1, characterized in that: The specific implementation method of step 3 is as follows: Step 3-1: Use the model checking tool SPIN to focus on verifying the safety and activity of the software architecture model. Safety includes two properties: deadlock and assertion conflict. Activity includes two properties: activity reachability and livelock. Step 3-2: Verify the reachability of the control node. During the execution of SPIN, the correctness of the assertion is judged to obtain the execution status of each branch in the control node, thereby determining its reachability.

7. The method for verifying correctness of a software architecture model for synchronous reactive components according to claim 1, characterized in that: The specific implementation method of step 4 is as follows: Step 4-1: Determine whether global variables are defined in the software architecture model, and convert the defined global variables into variables in the PROMELA model according to the mapping rules in step 2-2. At the same time, declare the channel set, and all channels used in the subsequent model conversion process need to be added to this set; Step 4-2: Traverse the software architecture model from InitialActivity, generate PROMELA processes from model nodes, define process declarations based on the name of the activity, generate process frameworks based on the node type and the mapping rules of step 2-3, and define channels based on the transition IDs and add them to the channel set. After obtaining the process framework, generate logic code based on the specification obtained from previously parsed activities and fill it into the process. Step 4-3: Repeat the operation in step 4-2 to convert each node in the software architecture model until the FinalActivity conversion is completed.

8. The method for verifying correctness of a software architecture model for synchronous reactive components according to claim 1, characterized in that: The specific implementation method of step 5 is as follows: Step 5-1: Before using the model checking tool to verify the converted PROMELA model, perform a syntax check and modify any syntax errors; Step 5-2: Verify the model attributes and select the attributes to be verified once, including deadlock, assertion conflict, livelock, reachability, and possible LTL formulas. After selecting the attributes to be verified, generate a verification script according to different combinations. The script automatically completes the setting of verification parameters, verification intermediate files, and the saving path of the verification report. After the script is generated, execute the script through the command line to verify the model with the help of SPIN. Step 5-3: Parse the verification report and extract the verification results. If other attributes need to be verified, repeat step 5-2.

Images