System demand document real-time dynamic updating method and device, equipment and medium

Abstract

The invention discloses a system demand document real-time dynamic updating method and device, equipment and a medium, and relates to the technical field of computer document processing, and the method comprises the steps: monitoring a preset code annotation in real time after source code updating is carried out on a system according to a current demand document, so as to obtain a corresponding monitoring result; when the monitoring result is that code change exists in each level of method under the preset code annotation, monitoring all service classes under a target level of method with code change in the current system operation process through a Java agent tool and a byte code instrumentation tool to obtain a corresponding instrumentation log; analyzing the instrumentation log, and generating a corresponding topological graph according to analysis information; outputting a text description corresponding to the topological graph by utilizing the pre-training model and according to the current demand document, a current design document written based on the current demand document, a preset code annotation and the topological graph; and updating the original demand document of the system by using the text description to obtain a real-time demand document.

Description

Technical Field

[0001] The present invention relates to the technical field of computer document processing, and in particular to a method, device, equipment and medium for real-time dynamic updating of system requirement documents. Background Art

[0002] The standard application system process is that the product requirement document is first prepared, and then the application system is developed based on the product-level requirement document. Therefore, at the beginning of the application system development and launch, the product-level requirement document is consistent with the actual function of the application system. However, as the application system is continuously iterated and updated, if the product-level requirement document is not continuously updated with the application system's update and iteration requirements, the product requirement document will gradually become inconsistent with the application system, making it impossible for people who want to understand the application system to understand the application system through the product requirement document. It is too costly to arrange employees to maintain the product requirement document, and it is difficult to persist.

[0003] In summary, how to dynamically and automatically update the product requirement documents of the system in real time as the system is updated and iterated, and reduce labor costs is a technical problem that needs to be solved in this field. Summary of the invention

[0004] In view of this, the purpose of the present invention is to provide a method, device, equipment and medium for real-time dynamic update of system requirement documents, which can dynamically and automatically update the system's product requirement documents in real time as the system is updated and iterated, thereby reducing labor costs. The specific scheme is as follows:

[0005] In a first aspect, the present application discloses a method for real-time dynamic updating of a system requirement document, comprising:

[0006] Real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirement document to obtain corresponding monitoring results; wherein the preset code annotations are used to mark the entry functions of the system function points;

[0007] When the monitoring result shows that there are code changes in the methods at each level under the preset code annotation, all business classes under the target level methods with code changes during the current system operation are monitored by the Java agent tool and the bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein the instrumentation logs contain the execution path of the code in the business class and the calling relationship of the methods at each level;

[0008] Parsing the instrumentation log to generate a corresponding topology map according to the parsed information;

[0009] Outputting a text description corresponding to the topology map using a pre-trained model and based on the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map;

[0010] The text description is used to update the original requirement document of the system to obtain a real-time requirement document.

[0011] Optionally, before the real-time monitoring of the preset code annotation after the source code of the system is updated according to the current requirement document, the method further includes:

[0012] When there is a system establishment requirement, analyzing system requirements at all levels of the system establishment requirement to create an original requirement document;

[0013] Write the corresponding original design document according to the original requirement document;

[0014] A system is built according to the original design document.

[0015] Optionally, analyzing the system requirements at all levels of the system establishment requirements to create an original requirements document includes:

[0016] Analyze the system establishment requirements to obtain system requirements at all levels that have associated relationships;

[0017] Encode each requirement of each level of system requirements to obtain coding information corresponding to the order of requirement code, requirement name, system function point, and requirement content;

[0018] An original requirements document is created using the encoded information.

[0019] Optionally, the method for real-time dynamic updating of system requirement documents further includes:

[0020] The entry functions of the system function points of each requirement at each level of system requirements are marked through preset code annotations.

[0021] Optionally, the Java agent tool and the bytecode instrumentation tool are used to monitor all business classes under the target level method with code changes during the current system operation to obtain corresponding instrumentation logs, including:

[0022] Load the updated source code during the current system operation through the class loader to obtain bytecode;

[0023] The bytecode is intercepted by a Java proxy tool, and the first line of bytecode representing each level of method is instrumented by a bytecode instrumentation tool, so as to monitor whether there are code changes in the business classes under each level of method and obtain corresponding instrumentation logs.

[0024] Optionally, parsing the instrumentation log to generate a corresponding topology map according to parsing information includes:

[0025] Parse the instrumentation log and determine whether there is a conditional branch under the parent level method in the parsed information;

[0026] If the conditional branch does not exist, generating a corresponding topological map according to the parsed information;

[0027] If the conditional branch exists, the source code corresponding to the parsed information is processed according to a processing rule in which the syntax structure of the source code is a tree structure and the structural elements of the source code are tree nodes, so as to generate a corresponding abstract syntax tree;

[0028] Traversing the abstract syntax tree to determine tree nodes having conditional branches according to node types and node attributes;

[0029] The node information of the tree nodes is used as the nodes of the topological graph, and the logical relationships in the node information are used as the edges in the topological graph, so as to construct the corresponding topological graph.

[0030] Optionally, the using of the pre-trained model and outputting a text description corresponding to the topology map according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map includes:

[0031] Create a blank association mapping table;

[0032] Using the requirement code as a key, the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map are associated and stored in the blank association mapping table according to the requirement code dimension to obtain content information associated with each requirement code; wherein the content information is the associated requirement document information, the associated design document information, the code annotation corresponding to the code under the associated preset code annotation, and the associated topology map information;

[0033] The content information associated with each requirement code is input into the pre-trained model so as to output the corresponding text description through the pre-trained model.

[0034] In a second aspect, the present application discloses a real-time dynamic update device for a system requirement document, comprising:

[0035] A monitoring module, used for real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirement document, so as to obtain corresponding monitoring results; wherein the preset code annotations are used to mark the entry functions of the system function points;

[0036] The instrumentation log acquisition module is used to monitor all business classes under the target level method with code changes during the current system operation through the Java agent tool and the bytecode instrumentation tool when the monitoring result is that there are code changes in the methods of each level under the preset code annotation, so as to obtain the corresponding instrumentation log; wherein the instrumentation log contains the execution path of the code in the business class and the calling relationship of the methods of each level;

[0037] A topology generation module, used to parse the instrumentation log to generate a corresponding topology map according to the parsed information;

[0038] A text generation module, configured to use a pre-trained model and output a text description corresponding to the topology map according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map;

[0039] The document updating module is used to update the original requirement document of the system using the text description to obtain a real-time requirement document.

[0040] In a third aspect, the present application discloses an electronic device, comprising:

[0041] Memory, used to store computer programs;

[0042] The processor is used to execute the computer program to implement the steps of the above-mentioned method for real-time dynamic updating of system requirement documents.

[0043] In a fourth aspect, the present application discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the steps of the aforementioned disclosed method for real-time dynamic updating of system requirement documents are implemented.

[0044] It can be seen that the present application discloses a method for real-time dynamic updating of system requirement documents, including: real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirement document to obtain corresponding monitoring results; wherein the preset code annotations are used to mark the entry functions of system function points; when the monitoring result is that there are code changes in the methods at each level under the preset code annotations, all business classes under the target level methods with code changes during the current system operation are monitored by the Java agent tool and the bytecode plugging tool to obtain corresponding plugging logs; wherein the plugging log contains the execution path of the code in the business class and the calling relationship of the methods at each level; parsing the plugging log to generate a corresponding topology map according to the parsing information; using the pre-trained model and outputting the text description corresponding to the topology map according to the current requirement document, the current design document written based on the current requirement document, the preset code annotations, and the topology map; using the text description to update the original requirement document of the system to obtain a real-time requirement document. It can be seen that by real-time monitoring of the preset code annotations after the code update, it is ensured that changes in the system source code can be discovered in a timely manner. When the system is iteratively updated, the requirements document will no longer be inconsistent with the actual system functions due to lack of timely follow-up, and the requirements document can always accurately reflect the current status of the system. By pre-setting code annotations to mark the entry functions of system function points, the code parts directly related to the system functions can be monitored in a targeted manner to improve the accuracy and efficiency of monitoring. Using Java agent tools and bytecode instrumentation tools, only all business classes under the target level methods with code changes are monitored, avoiding unnecessary monitoring of non-business codes, reducing resource consumption, and accurately obtaining business-related code execution paths and method call relationships. Parsing instrumentation logs to generate topology maps provides a visual representation of the complex code structure and control flow of the system. Developers and related personnel can understand the logical structure of the system more intuitively, which helps to quickly locate problems and optimize the system. The text description corresponding to the topology map output by the pre-trained model further enhances the understanding of the system. The text description can explain the nodes and connection relationships in the topology map in more detail, so that people who are not familiar with the code can also understand the functions and processes of the system through the requirements document. In this way, the real-time automatic update of the requirement documents is achieved, and there is no need to arrange special personnel to manually maintain the requirement documents, which greatly reduces labor costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0045] In order to more clearly illustrate the embodiments of the present invention or the technical solutions in the prior art, the drawings required for use in the embodiments or the description of the prior art will be briefly introduced below. Obviously, the drawings described below are only embodiments of the present invention. For ordinary technicians in this field, other drawings can be obtained based on the provided drawings without paying creative work.

[0046] Figure 1 A flow chart of a method for real-time dynamic updating of system requirement documents disclosed in this application;

[0047] Figure 2 A design diagram of a requirement document disclosed in this application;

[0048] Figure 3 A schematic diagram of a loading process after Class bytecode modification using Java agent and Javassist disclosed in this application;

[0049] Figure 4 A log structure diagram disclosed in this application;

[0050] Figure 5 A topological diagram disclosed in this application;

[0051] Figure 6 Another topological diagram disclosed in this application;

[0052] Figure 7 A complete lunch eating topology diagram disclosed in this application;

[0053] Figure 8 A complete text flow chart of eating lunch disclosed in this application;

[0054] Fig. 9 A schematic diagram of the structure of a real-time dynamic updating device for system requirement documents disclosed in this application;

[0055] Fig.10 This is a structural diagram of an electronic device disclosed in this application. DETAILED DESCRIPTION

[0056] The following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of the present invention.

[0057] The standard application system process is that the product requirement document is first prepared, and then the application system is developed based on the product-level requirement document. Therefore, at the beginning of the application system development and launch, the product-level requirement document is consistent with the actual function of the application system. However, as the application system is continuously iterated and updated, if the product-level requirement document is not continuously updated with the application system's update and iteration requirements, the product requirement document will gradually become inconsistent with the application system, making it impossible for people who want to understand the application system to understand the application system through the product requirement document. It is too costly to arrange employees to maintain the product requirement document, and it is difficult to persist.

[0058] To this end, the present invention provides a real-time dynamic update solution for system requirement documents, which can dynamically and automatically update the system's product requirement documents in real time as the system is updated and iterated, thereby reducing labor costs.

[0059] Reference Figure 1 As shown, an embodiment of the present invention discloses a method for real-time dynamic updating of a system requirement document, comprising:

[0060] Step S11: real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirement document to obtain corresponding monitoring results; wherein the preset code annotations are used to mark the entry functions of the system function points.

[0061] In this embodiment, the real-time monitoring according to the current requirement document updates the system source code before the preset code annotation, and also includes: when there is a system establishment requirement, analyzing the system requirements of each level of the system establishment requirement to create an original requirement document; writing a corresponding original design document according to the original requirement document; and establishing the system according to the original design document. It can be understood that because the system establishment requirement contains various subsystem requirements, and each sub-requirement contains the subsystem requirements of the next level, the system requirements of each level are analyzed according to the system establishment requirement to create a corresponding original requirement document according to all levels of system requirements, wherein the original requirement document includes the following specific requirements:

[0062] Requirements Overview: A brief description of the system's objectives, scope, and main functions.

[0063] Functional requirements: List the functions of the system in detail, including function description, input and output, processing flow, etc.

[0064] User needs: Describe the needs and usage scenarios of different user groups.

[0065] Performance requirements: Clarify the performance indicators and requirements of the system.

[0066] Security requirements: List the system's security policies and measures.

[0067] Maintainability and scalability requirements: Describe the maintainability and scalability requirements of the system.

[0068] Correspondingly, after the original requirement document is created, the corresponding original design document is written according to the requirement document. The original design document is an important basis for system development, which converts the requirements into specific technical solutions and design architecture.

[0069] 1. System architecture design:

[0070] Determine the overall architecture of the system, including the system's hierarchy, module division, component relationships, etc.

[0071] Choose the right technology stack, such as programming language, database, server, etc.

[0072] Design the system's communication mechanism and interface to ensure effective data exchange and collaboration between different modules.

[0073] 2. Database design:

[0074] Design the database structure according to the functional requirements of the system, including table structure, field types, relationships, etc.

[0075] Consider data storage methods, index design, data backup and recovery strategies, etc.

[0076] 3. Interface design:

[0077] Design the system's user interface, including interface layout, color matching, interaction methods, etc.

[0078] Ensure that the interface is simple, beautiful, easy to use, and in line with user habits.

[0079] 4. Algorithm and process design:

[0080] For some complex functional modules, corresponding algorithms and processing flows need to be designed.

[0081] For example, search algorithms, sorting algorithms, data processing flows, etc.

[0082] 5. Safety design:

[0083] Implement the security policies and measures in the security requirements document and design the system's security architecture.

[0084] Including user authentication and authorization mechanisms, data encryption, access control, etc.

[0085] Among them, the original design document should include the following:

[0086] Design Overview: Describes the design goals, principles, and overall architecture of the system.

[0087] System architecture diagram: graphically displays the system's hierarchy and module division.

[0088] Database design: Describe the structure and design of the database in detail.

[0089] Interface design: Display the system’s user interface design renderings and interaction processes.

[0090] Algorithm and process design: Explain the algorithm and processing flow of complex functional modules.

[0091] Security design: Describe the system's security architecture and security measures.

[0092] After the original design document is written, the system is built according to the design document. This process includes the following steps:

[0093] 1. Development environment construction:

[0094] Install and configure the required development tools and software, such as programming language development environment, database management system, server, etc.

[0095] Establish version control tools, such as Git (Global Information Tracker, distributed version control system) or SVN (Apache Subversion, centralized version control system), to manage and collaborate on code.

[0096] 2. Code development:

[0097] According to the architecture and module division in the design document, code development is carried out. Developers write corresponding code modules according to their respective task division.

[0098] During the development process, follow good programming standards and coding styles to ensure the readability, maintainability and scalability of the code.

[0099] Use code commenting and documentation tools to comment and document your code so other developers can understand the functionality and logic of your code.

[0100] 3. Test:

[0101] While the code is being developed, unit testing, integration testing, and system testing are performed to ensure that each code module and function can work properly and that the overall performance and stability of the system meet the requirements.

[0102] Use automated testing tools and frameworks to improve testing efficiency and coverage.

[0103] 4. Deployment:

[0104] When the system passes the test, it is deployed. Select the appropriate server and deployment environment and deploy the system to the production environment.

[0105] Perform post-deployment verification and monitoring to ensure that the system can operate normally and that possible problems are discovered and resolved in a timely manner.

[0106] Through the above steps, the system is established according to the original design documents to achieve the functional requirements and design goals of the system. During the system establishment process, the requirements and design should be continuously verified and adjusted to ensure that the system can meet the actual needs and expectations of users.

[0107] In this embodiment, the analysis of the system requirements at all levels of the system establishment requirements to create an original requirements document includes: analyzing the system establishment requirements to obtain the system requirements at all levels with associated relationships; encoding each requirement of the system requirements at all levels to obtain the encoding information corresponding to the order of requirement code, requirement name, system function point, and requirement content; and using the encoding information to create the original requirements document. It can be understood that the overall goal and main functions of the system are first clarified. For example, the goal of an online education system may be to provide a high-quality course learning platform, and the main functions include course display, online learning, homework submission, exam evaluation, etc. The overall goal is gradually disassembled into specific sub-goals and functional modules, which constitute the system requirements at all levels. For example, the course display module can be further disassembled into sub-functional requirements such as course list display, course details display, and course search. Further, the business process is combed: the business processes involved in the system are analyzed to determine the requirements of each link. Taking the e-commerce system as an example, the business process includes product listing, user ordering, payment settlement, logistics distribution, etc., and each link has corresponding system requirements. Consider the interaction and dependency between different business processes to ensure the coordination and consistency between system requirements at all levels. For example, after a user places an order, payment settlement is required, and logistics delivery can only be carried out after the payment settlement is successful. There is a clear sequence and correlation between these requirements. For online education systems that rely more on the roles of different users in the system, further user role analysis is performed to determine the different user roles of the system, such as administrators, teachers, students, parents, etc. (taking the online education system as an example). Analyze the needs and usage scenarios of each user role to determine the corresponding system functions. Consider the interaction and permission management between different user roles to ensure that the system can meet the needs of different users and ensure the security and privacy of data. For example, administrators can perform operations such as course management and user management, teachers can upload courses and correct homework, and students can study courses and submit homework. Then encode the system requirements at all levels obtained from the analysis to better organize and manage the requirement information. The encoding process is carried out in the order of requirement code, requirement name, system function point, and requirement content. Specifically, requirement coding: assign a unique code to each requirement for quick location and identification in the requirement document. The coding can adopt certain rules and formats, refer to Figure 2As shown in the figure, the requirements are coded in the form of "SR-year-serial number", where "SR" represents the system requirement, "year" represents the year in which the requirement is proposed, and "serial number" is numbered in the order in which the requirements are proposed. The requirement coding should be readable and extensible so that it can be easily managed in subsequent requirement changes and expansions. Requirement name: Give each requirement a concise and clear name that can accurately summarize the main content of the requirement. The requirement name should be unique to avoid confusion caused by the same name. For example, for the course display function in the online education system, it can be named "course display requirement". System function point: Clarify the system function point corresponding to each requirement. System function point is a further refinement and concretization of the requirement, which can help developers better understand how to implement the requirement. For example, for the "course display requirement", the system function points can include course list display, course details display, and course search. Requirement content: Describe the specific content and requirements of each requirement in detail. The requirement content should include information on the input, output, processing flow, constraints, etc. of the requirement so that developers can accurately implement the requirement. For example, for the "course list display function point", the requirements may include displaying the course name, introduction, pictures, price and other information, supporting sorting by course category, popularity, etc., providing paginated browsing functions, etc.

[0108] Furthermore, when coding the requirement document version, it also includes: marking the entry function of the system function point of each requirement of each level of system requirements through preset code annotations. It can be understood that when a certain system requirement is: requirement number: SR-2024-01-001; requirement name: loan; function point: FP1; requirement content: XXXX. It is necessary to mark the entry function of each system function point through annotations, and set the annotation to @FunctionPoint(name="FP1",SR={"SR-2024-01-001","SR-2024-01-002",...}). The annotation is used to mark the method. Name represents the name of the function point, which corresponds to the function point name of the requirement document and the design document. Because one function point may correspond to multiple requirements, SR needs to support filling in multiple. Then complete the association between the requirement document, design document, and code.

[0109] In this embodiment, the corresponding system is created for the original requirement document and the original design document proposed according to the above steps. Therefore, when adding or updating requirements to the system, the new requirements are often written by writing a new current requirement document instead of the original original requirement document, because one requirement may involve multiple systems, so it is necessary to parse the requirements content involving the system through coding. When a new requirement is needed, a new function point needs to be added, and a method entry for the function point needs to be created. The method entry is marked with @FunctionPoint to establish the association between its requirement document, design document and code; if the original requirement is updated, the method entry remains unchanged, and the method code can be updated. Therefore, the @FunctionPoint after the source code of the system is updated according to the current requirement document is monitored in real time, and the monitoring results of the @FunctionPoint during the normal operation of the system are monitored.

[0110] Step S12: When the monitoring result shows that there are code changes in the methods at each level under the preset code annotation, all business classes under the target level methods with code changes during the current system operation are monitored through the Java agent tool and the bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein the instrumentation logs contain the execution path of the code in the business class and the calling relationships of the methods at each level.

[0111] In this embodiment, the code is managed with version control tools, such as SVN, Git, etc. Therefore, when it is monitored that all parent-child level methods under the function point entry annotated by @FunctionPoint have code changes, the flowchart and flowchart description content of the relevant SR requirements in the @FunctionPoint annotation are updated. Among them, when code changes are detected, the updated source code in the current system operation process is loaded through the class loader to obtain bytecode; the bytecode is intercepted by the Java agent tool, and the first line of bytecode representing each level of method is instrumented through the bytecode instrumentation tool, so as to monitor whether there are code changes in the business classes under each level of method and obtain the corresponding instrumentation log. Figure 3As shown in the figure, Java agent and Javassist (Java bytecode manipulation library) tools are used to perform bytecode instrumentation, monitor the execution of each method, and generate logs. Java agent and Javassist will monitor all Class classes with specific naming rules in the code (generally, the class name of the business code is "com. company English abbreviation. system name abbreviation") and only monitor business classes with such naming rules. This can avoid unnecessary monitoring of non-business code, improve efficiency, and accurately obtain business-related code execution information. It should be noted that when producing the flowchart of the requirement document, only the methods of the business class need to be generated. Therefore, the Java source code is parsed into bytecode through the Class loader. The Java agent can intercept and obtain the bytecode before the Jvm (Java Virtual Machine) loads the bytecode into the JAR (Java Archive) package, and then the bytecode is modified by Javassist and returned to the Java agent. Finally, the Java agent returns it to the JAR package. Through bytecode instrumentation, you can obtain a topological diagram of the code execution process. For example, you can insert a log in the first line of each method through bytecode instrumentation, print method information, and then obtain the corresponding instrumentation log.

[0112] Step S13: parse the instrumentation log to generate a corresponding topology map according to the parsed information.

[0113] In this embodiment, the instrumentation log with changes in the monitoring result is parsed, and it is determined whether there is a conditional branch in the parsed information. If there is no conditional branch, a corresponding topological map is directly generated according to the parsed information. If there is a conditional branch, the AST (Abstract Syntax Tree) technology is used to determine and parse the syntax structure of the source code corresponding to the parsed information, etc. Specifically, the parsing of the instrumentation log to generate a corresponding topological map according to the parsed information includes: parsing the instrumentation log, and determining whether there is a conditional branch under the parent level method in the parsed information; if there is no conditional branch, generating a corresponding topological map according to the parsed information; if there is a conditional branch, processing the source code corresponding to the parsed information according to a processing rule in which the syntax structure of the source code is a tree structure and the structural elements of the source code are tree nodes to generate a corresponding abstract syntax tree; traversing the abstract syntax tree to determine the tree node with the conditional branch according to the node type and the node attribute; using the node information of the tree node as the node of the topological map, and using the logical relationship in the node information as the edge in the topological map to construct the corresponding topological map. It is understandable that the business code of the system is parsed using a suitable AST parsing tool to generate an abstract syntax tree representation. These business codes are usually classes that are monitored by bytecode stubs and conform to specific naming rules (such as "com. company English abbreviation. system name abbreviation"). The generated abstract syntax tree is traversed in depth first. During the traversal process, the type and attributes of each node are checked to determine whether it is a node related to a branch statement. For example, in Java or other programming languages, nodes representing conditional judgment statements (such as if, switch, etc.) are found. When a node is encountered, it is determined whether it is a branch statement node based on its type and attributes. If the node type corresponds to the branch statement type in a specific programming language, such as the node type corresponding to statements such as if, else, switch in Java, it can be determined that this is a branch statement. For branch statement nodes, their conditional expressions are further analyzed. Information such as variables, constants, and operators in the conditional expression is extracted to better understand the branch conditions. At the same time, the branch body of the branch statement, that is, the AST node corresponding to the code block executed when the condition is true or false, is determined. The nodes in the topology graph are constructed based on the information of the branch statement. Each branch statement can correspond to a node in the topology graph. The attributes of the node can include information such as the conditional expression of the branch statement, the name of the related variable, the type of branch (such as if-else, switch-case, etc.). For complex branch structures, it may be necessary to merge multiple related branch statements into a higher-level node to better represent the structure of the entire branch logic. The connections between the topology graph nodes are established according to the logical relationship of the branch statements in the code.For example, if an if statement is followed by an else statement, then a connection is established between the corresponding if node and else node in the topology diagram. For switch-case statements, each case node is connected to the switch node, and the existence of a default branch and the connection relationship with other nodes are determined based on the logic of the code. By establishing these connections, the control flow and logical relationship between branch statements in the code can be clearly represented. The generated topology diagram can be optimized to remove unnecessary nodes or connections to improve the readability and simplicity of the topology diagram. The layout of the topology diagram can be adjusted to make the distribution of nodes more reasonable and the connections clearer. Add appropriate annotations and instructions to the topology diagram to better understand the meaning of each node and connection.

[0114] Through the above steps, AST technology can be used to accurately determine branch statements from the system source code, and parse to obtain a topology diagram that can clearly represent the code branch logic, providing important visualization support for subsequent requirement document updates and system understanding.

[0115] For example, when the monitoring result shows that there is a code change in the class under the "eating" method, the code of the printed method information is displayed as follows:

[0116] package com.hncy58.handler;

[0117] / **File function description: eating** /

[0118] public class Eat {

[0119] public static void main(String[] args){

[0120] System.out.println("Eat lunch");

[0121] Person r = new Person (region: "Southerner");

[0122] eat luncheat = new eat lunch(r);

[0123] eat.Eat lunch();

[0124] }

[0125] }.

[0126] Correspondingly, the display results of the above code after bytecode instrumentation are as follows:

[0127] package com.hncy58.handler;

[0128] / **File function description: Eat lunch 2024 / 8 / 14 9:52** /

[0129] class Eat lunch {

[0130] peopler;

[0131] public eatlunch(person r){

[0132] this.r=r;

[0133] }

[0134] public void eatlunch(){

[0135] if(r.equals("Southerner")){

[0136] eatrice();

[0137] Eat vegetables();

[0138] }else{

[0139] EatNoodles();

[0140] drinkSoup();

[0141] }

[0142] }

[0143] public void eatrice(){}{...}

[0144] public void eatnoodles(){}{...}

[0145] public void eatvegetable(){}{...}

[0146] public void drink soup(){ System.out.println("Drink soup");}

[0147] }.

[0148] From the above code, we can see that if the person eating is from the south, the stub log can be printed as shown in the figure:

[0149] - void com.hncy58.handler.Eat lunch#Eat lunch()

[0150] -- void com.hncy58.handler.Eat lunch#Eat rice()

[0151] -- void com.hncy58.handler.Eat lunch#eat vegetables().

[0152] The instrumentation log structure is as follows Figure 4 As shown, the structure from left to right is package name, class name, and method name. Taking the eating function in the above code as an example, "com.hncy58.handler" is the package name, "eat lunch" is the class name, and "eat lunch" is the method name.

[0153] It can be understood that according to the above-printed instrumentation log, the corresponding topology diagram is obtained from the log information "eat lunch#eat lunch, eat lunch#eat rice, eat lunch#eat vegetables" parsed from the eating for southerners. Figure 5 According to the above code information, if the person eating is not from the south, the instrumentation log can be printed as follows:

[0154] - void com.hncy58.handler.Eat lunch#Eat lunch()

[0155] -- void com.hncy58.handler.Eat lunch#eat noodles()

[0156] -- void com.hncy58.handler.Eat lunch#drink soup()

[0157] Among them, the corresponding topology diagram generated after analysis is as follows Figure 6 It should be noted that there are two branches in the lunch, that is, there are conditional branches. The conditional branches need to be merged to obtain a complete topology diagram. The complete topology diagram is as follows: Figure 7 As shown in the figure, the bytecode instrumentation is implemented through Java agent and Javassist to obtain the topology map. Figure 7 From the topology diagram, we can find that the "eat lunch" method has two branches, each executing different logics, so there must be a branch statement in the method. By using AST to analyze the code, we can find out whether there are branch statements such as if-else and switch before the method in the class is called, so as to establish the logical relationship between each method. Finally, the calling logic relationship of the method in the system is established, as shown below Figure 8 shown.

[0158] Step S14: using the pre-trained model and according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map, outputting a text description corresponding to the topology map.

[0159] In this embodiment, a blank association mapping table is created; with the requirement code as the key, the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map are associated and stored in the blank association mapping table according to the requirement code dimension to obtain the content information associated with each requirement code; wherein the content information is the associated requirement document information, the associated design document information, the code annotation corresponding to the code under the associated preset code annotation, and the associated topology map information; the content information associated with each requirement code is input into the pre-training model so that the corresponding text description is output through the pre-training model. It can be understood that a data structure, such as an association mapping table, is created, with the requirement code as the key, to store the current requirement document, the current design document, the code annotation fragment, and the flowchart information related thereto, because in the current requirement document, the code of each requirement is clearly marked. When the content of the requirement document is sorted out and prepared to be input into the pre-training model, the corresponding requirement description, function point, requirement content and other information are extracted in sequence according to the requirement code, and placed in the corresponding position in the association mapping table. For the current design document, it is also searched and extracted according to the requirement code. Ensure that the parts of the design document related to the specific requirement coding, such as architecture design, module design, etc., are accurately associated with the requirement coding and added to the association mapping table. In the code, scan and find comments related to the specific requirement coding. For example, by finding the code part with the "@FunctionPoint" annotation with the specific requirement coding, extract the relevant code comment content and add it to the corresponding requirement coding position in the association mapping table. For the flowchart, determine its correspondence with the specific requirement coding. It may be possible to mark the requirement coding in the title, annotation or metadata of the flowchart so that the flowchart can be accurately associated with the specific requirement. Add the flowchart information to the corresponding position in the association mapping table. Through the above steps, the requirement documents, design documents, code comments and flowcharts are organized with the requirement coding as the dimension, so that the relevant information of each requirement can be centrally and accurately associated together, which is convenient for subsequent input into the pre-trained model for comprehensive analysis. Input the organized requirement documents, design documents, code comments and flowcharts into the AI ​​(Artificial Intelligence) big model or the self-built AI middle platform. These AI big models or self-built AI middle stations have powerful language understanding and generation capabilities, and can perform in-depth analysis of complex input information. Based on the input content, they can understand the logical relationship between system requirements, design, and code implementation, and use their powerful language processing capabilities to generate accurate and clear flowchart text descriptions. Therefore, if the above-mentioned content related to eating is input into the AI ​​big model, the corresponding output is the text description of "1. If a person is from the south, he only eats rice and vegetables for lunch; 2. If he is not from the south, he only eats noodles and soup."

[0160] Step S15: using the text description to update the original requirement document of the system to obtain a real-time requirement document.

[0161] In this embodiment, the generated flowchart text description is obtained from the AI ​​big model or the self-built AI middle station. This description should accurately reflect the business process and control flow of the system, correspond to the flowchart, and provide detailed instructions for updating the requirements document. Integrate the generated flowchart and flowchart text description into the existing original requirements document. You can add a flowchart and its text description to the corresponding part of the original requirements document, or create a special chapter to display the flowchart and instructions to ensure that the requirements document can fully and accurately reflect the current state of the system.

[0162] In this way, the requirements document is updated in real time according to the code. Whenever the system code changes, after a series of monitoring, analysis and AI processing steps, the requirements document can reflect these changes in a timely manner, so that people who want to understand the application system can accurately understand the system's functions and implementation methods through the latest requirements document, avoiding the difficulty of understanding caused by the inconsistency between the requirements document and the application system.

[0163] It can be seen that the present application discloses a method for real-time dynamic updating of system requirement documents, including: real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirement document to obtain corresponding monitoring results; wherein the preset code annotations are used to mark the entry functions of system function points; when the monitoring result is that there are code changes in the methods at each level under the preset code annotations, all business classes under the target level methods with code changes during the current system operation are monitored by the Java agent tool and the bytecode plugging tool to obtain corresponding plugging logs; wherein the plugging log contains the execution path of the code in the business class and the calling relationship of the methods at each level; parsing the plugging log to generate a corresponding topology map according to the parsing information; using the pre-trained model and outputting the text description corresponding to the topology map according to the current requirement document, the current design document written based on the current requirement document, the preset code annotations, and the topology map; using the text description to update the original requirement document of the system to obtain a real-time requirement document. It can be seen that by real-time monitoring of the preset code annotations after the code update, it is ensured that changes in the system source code can be discovered in a timely manner. When the system is iteratively updated, the requirements document will no longer be inconsistent with the actual system functions due to lack of timely follow-up, and the requirements document can always accurately reflect the current status of the system. By pre-setting code annotations to mark the entry functions of system function points, the code parts directly related to the system functions can be monitored in a targeted manner to improve the accuracy and efficiency of monitoring. Using Java agent tools and bytecode instrumentation tools, only all business classes under the target level methods with code changes are monitored, avoiding unnecessary monitoring of non-business codes, reducing resource consumption, and accurately obtaining business-related code execution paths and method call relationships. Parsing instrumentation logs to generate topology maps provides a visual representation of the complex code structure and control flow of the system. Developers and related personnel can understand the logical structure of the system more intuitively, which helps to quickly locate problems and optimize the system. The text description corresponding to the topology map output by the pre-trained model further enhances the understanding of the system. The text description can explain the nodes and connection relationships in the topology map in more detail, so that people who are not familiar with the code can also understand the functions and processes of the system through the requirements document. In this way, the real-time automatic update of the requirement documents is achieved, and there is no need to arrange special personnel to manually maintain the requirement documents, which greatly reduces labor costs.

[0164] Reference Fig. 9 As shown, the present invention also discloses a device for real-time dynamic updating of system requirement documents, including:

[0165] The monitoring module 11 is used to monitor in real time the preset code annotations after the source code of the system is updated according to the current requirement document to obtain corresponding monitoring results; wherein the preset code annotations are used to mark the entry functions of the system function points;

[0166] The instrumentation log acquisition module 12 is used to monitor all business classes under the target level method with code changes during the current system operation through the Java agent tool and the bytecode instrumentation tool when the monitoring result is that there are code changes in the methods of each level under the preset code annotation, so as to obtain the corresponding instrumentation log; wherein the instrumentation log contains the execution path of the code in the business class and the calling relationship of the methods of each level;

[0167] A topology generation module 13, used for parsing the instrumentation log to generate a corresponding topology map according to the parsed information;

[0168] A text generation module 14 is used to use a pre-trained model and output a text description corresponding to the topology map according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map;

[0169] The document updating module 15 is used to update the original requirement document of the system using the text description to obtain a real-time requirement document.

[0170] It can be seen that the present application discloses real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirement document to obtain corresponding monitoring results; wherein, the preset code annotation is used to mark the entry function of the system function point; when the monitoring result is that there are code changes in the methods at each level under the preset code annotation, all business classes under the target level method with code changes during the current system operation are monitored by the Java agent tool and the bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein, the instrumentation log contains the execution path of the code in the business class and the calling relationship of the methods at each level; parse the instrumentation log to generate a corresponding topology map according to the parsing information; use the pre-trained model and output the text description corresponding to the topology map according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map; use the text description to update the original requirement document of the system to obtain a real-time requirement document. It can be seen that by real-time monitoring of the preset code annotations after the code update, it is ensured that changes in the system source code can be discovered in a timely manner. When the system is iteratively updated, the requirements document will no longer be inconsistent with the actual system functions due to lack of timely follow-up, and the requirements document can always accurately reflect the current status of the system. By pre-setting code annotations to mark the entry functions of system function points, the code parts directly related to the system functions can be monitored in a targeted manner to improve the accuracy and efficiency of monitoring. Using Java agent tools and bytecode instrumentation tools, only all business classes under the target level methods with code changes are monitored, avoiding unnecessary monitoring of non-business codes, reducing resource consumption, and accurately obtaining business-related code execution paths and method call relationships. Parsing instrumentation logs to generate topology maps provides a visual representation of the complex code structure and control flow of the system. Developers and related personnel can understand the logical structure of the system more intuitively, which helps to quickly locate problems and optimize the system. The text description corresponding to the topology map output by the pre-trained model further enhances the understanding of the system. The text description can explain the nodes and connection relationships in the topology map in more detail, so that people who are not familiar with the code can also understand the functions and processes of the system through the requirements document. In this way, the real-time automatic update of the requirement documents is achieved, and there is no need to arrange special personnel to manually maintain the requirement documents, which greatly reduces labor costs.

[0171] Furthermore, the present application also discloses an electronic device. Fig.10 This is a structural diagram of an electronic device 20 according to an exemplary embodiment. The content in the diagram cannot be regarded as any limitation on the scope of use of the present application.

[0172] Fig.10A schematic diagram of the structure of an electronic device 20 provided in an embodiment of the present application. The electronic device 20 may specifically include: at least one processor 21, at least one memory 22, a power supply 23, a communication interface 24, an input / output interface 25, and a communication bus 26. The memory 22 is used to store a computer program, which is loaded and executed by the processor 21 to implement the relevant steps in the method for real-time dynamic update of the system requirement document disclosed in any of the aforementioned embodiments. In addition, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0173] In this embodiment, the power supply 23 is used to provide working voltage for each hardware device on the electronic device 20; the communication interface 24 can create a data transmission channel between the electronic device 20 and the external device, and the communication protocol it follows is any communication protocol that can be applied to the technical solution of the present application, and is not specifically limited here; the input and output interface 25 is used to obtain external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs and is not specifically limited here.

[0174] Among them, the processor 21 may include one or more processing cores, such as a 4-core processor, an 8-core processor, etc. The processor 21 can be implemented in at least one hardware form of DSP (Digital Signal Processing), FPGA (Field-Programmable Gate Array), and PLA (Programmable Logic Array). The processor 21 may also include a main processor and a coprocessor. The main processor is a processor for processing data in the awake state, also known as a CPU (Central Processing Unit); the coprocessor is a low-power processor for processing data in the standby state. In some embodiments, the processor 21 may be integrated with a GPU (Graphics Processing Unit), which is responsible for rendering and drawing the content to be displayed on the display screen. In some embodiments, the processor 21 may also include an AI (Artificial Intelligence) processor, which is used to process computing operations related to machine learning.

[0175] In addition, the memory 22, as a carrier for storing resources, can be a read-only memory, a random access memory, a disk or an optical disk, etc. The resources stored thereon can include an operating system 221, a computer program 222, etc., and the storage method can be temporary storage or permanent storage.

[0176] Among them, the operating system 221 is used to manage and control the hardware devices and computer programs 222 on the electronic device 20, so as to realize the operation and processing of the massive data 223 in the memory 22 by the processor 21, which can be Windows Server, Netware, Unix, Linux, etc. In addition to including a computer program that can be used to complete the real-time dynamic update method of the system requirement document executed by the electronic device 20 disclosed in any of the aforementioned embodiments, the computer program 222 can further include a computer program that can be used to complete other specific tasks. In addition to data transmitted from an external device received by the electronic device, the data 223 can also include data collected by its own input and output interface 25, etc.

[0177] Furthermore, the present application also discloses a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, the real-time dynamic update method of the system requirement document disclosed above is implemented. The specific steps of the method can refer to the corresponding contents disclosed in the above embodiments, and will not be repeated here.

[0178] In this specification, each embodiment is described in a progressive manner, and each embodiment focuses on the differences from other embodiments. The same or similar parts between the embodiments can be referred to each other. For the device disclosed in the embodiment, since it corresponds to the method disclosed in the embodiment, the description is relatively simple, and the relevant parts can be referred to the method part.

[0179] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented with electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described in terms of function in the above description. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel may use different methods to implement the described functions for each specific application, but such implementation should not be considered to be beyond the scope of this application. The steps of the method or algorithm described in conjunction with the embodiments disclosed herein can be implemented directly with hardware, a software module executed by a processor, or a combination of the two. The software module can be placed in a random access memory RAM (Random Access Memory), memory, read-only memory ROM (Read Only Memory), electrically programmable EPROM (Electrically Programmable Read Only Memory), electrically erasable programmable EEPROM (ElectricErasable Programmable Read Only Memory), register, hard disk, removable disk, CD-ROM (CompactDisc-Read Only Memory), or any other form of storage medium known in the technical field.

[0180] Finally, it should be noted that, in this article, relational terms such as first and second, etc. are only used to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Moreover, the terms "include", "comprise" or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article or device including a series of elements includes not only those elements, but also other elements not explicitly listed, or also includes elements inherent to such process, method, article or device. In the absence of further restrictions, the elements defined by the sentence "comprise a ..." do not exclude the presence of other identical elements in the process, method, article or device including the elements.

[0181] The scheme provided by the present invention is introduced in detail above. Specific examples are used in this article to illustrate the principle and implementation mode of the present invention. The description of the above embodiments is only used to help understand the method of the present invention and its core idea. At the same time, for those skilled in the art, according to the idea of ​​the present invention, there will be changes in the specific implementation mode and application scope. In summary, the content of this specification should not be understood as limiting the present invention.

Claims

1. A method for real-time dynamic updating of system requirement documents, characterized in that: include: Real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirement document to obtain corresponding monitoring results; wherein the preset code annotations are used to mark the entry functions of the system function points; When the monitoring result shows that there are code changes in the methods at each level under the preset code annotation, all business classes under the target level methods with code changes during the current system operation are monitored by the Java agent tool and the bytecode instrumentation tool to obtain corresponding instrumentation logs; wherein the instrumentation logs contain the execution path of the code in the business class and the calling relationship of the methods at each level; Parsing the instrumentation log to generate a corresponding topology map according to the parsed information; Outputting a text description corresponding to the topology map using a pre-trained model and based on the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map; The text description is used to update the original requirement document of the system to obtain a real-time requirement document.

2. The method for real-time dynamic updating of system requirement documents according to claim 1, characterized in that: Before the preset code annotation after the source code of the system is updated according to the current requirement document, the real-time monitoring also includes: When there is a system establishment requirement, analyzing system requirements at all levels of the system establishment requirement to create an original requirement document; Write the corresponding original design document according to the original requirement document; A system is built according to the original design document.

3. The method for real-time dynamic updating of system requirement documents according to claim 2, characterized in that: The analysis of system requirements at all levels of the system establishment requirements to create an original requirements document includes: Analyze the system establishment requirements to obtain system requirements at all levels that have associated relationships; Encode each requirement of each level of system requirements to obtain coding information corresponding to the order of requirement code, requirement name, system function point, and requirement content; An original requirements document is created using the encoded information.

4. The method for real-time dynamic updating of system requirement documents according to claim 3, characterized in that: Also includes: The entry functions of the system function points of each requirement at each level of system requirements are marked through preset code annotations.

5. The method for real-time dynamic updating of system requirement documents according to claim 1, characterized in that: The Java agent tool and the bytecode instrumentation tool are used to monitor all business classes under the target level method with code changes during the current system operation to obtain corresponding instrumentation logs, including: Load the updated source code during the current system operation through the class loader to obtain bytecode; The bytecode is intercepted by a Java proxy tool, and the first line of bytecode representing each level of method is instrumented by a bytecode instrumentation tool, so as to monitor whether there are code changes in the business classes under each level of method and obtain corresponding instrumentation logs.

6. The method for real-time dynamic updating of system requirement documents according to claim 5, characterized in that: The parsing of the instrumentation log to generate a corresponding topology map according to the parsed information includes: Parse the instrumentation log and determine whether there is a conditional branch under the parent level method in the parsed information; If the conditional branch does not exist, generating a corresponding topological map according to the parsed information; If the conditional branch exists, the source code corresponding to the parsed information is processed according to a processing rule in which the syntax structure of the source code is a tree structure and the structural elements of the source code are tree nodes, so as to generate a corresponding abstract syntax tree; Traversing the abstract syntax tree to determine tree nodes having conditional branches according to node types and node attributes; The node information of the tree nodes is used as the nodes of the topological graph, and the logical relationships in the node information are used as the edges in the topological graph, so as to construct the corresponding topological graph.

7. The method for real-time dynamic updating of system requirement documents according to any one of claims 1 to 6, characterized in that: The method of using the pre-trained model and outputting a text description corresponding to the topology map according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map includes: Create a blank association mapping table; Using the requirement code as a key, the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map are associated and stored in the blank association mapping table according to the requirement code dimension to obtain content information associated with each requirement code; wherein the content information is the associated requirement document information, the associated design document information, the code annotation corresponding to the code under the associated preset code annotation, and the associated topology map information; The content information associated with each requirement code is input into the pre-trained model so as to output the corresponding text description through the pre-trained model.

8. A real-time dynamic updating device for system requirement documents, characterized in that: include: A monitoring module, used for real-time monitoring of preset code annotations after the source code of the system is updated according to the current requirement document, so as to obtain corresponding monitoring results; wherein the preset code annotations are used to mark the entry functions of the system function points; The instrumentation log acquisition module is used to monitor all business classes under the target level method with code changes during the current system operation through the Java agent tool and the bytecode instrumentation tool when the monitoring result is that there are code changes in the methods of each level under the preset code annotation, so as to obtain the corresponding instrumentation log; wherein the instrumentation log contains the execution path of the code in the business class and the calling relationship of the methods of each level; A topology generation module, used to parse the instrumentation log to generate a corresponding topology map according to the parsed information; A text generation module, configured to use a pre-trained model and output a text description corresponding to the topology map according to the current requirement document, the current design document written based on the current requirement document, the preset code annotation, and the topology map; The document updating module is used to update the original requirement document of the system using the text description to obtain a real-time requirement document.

9. An electronic device, characterized in that: include: Memory, used to store computer programs; A processor is used to execute the computer program to implement the steps of the real-time dynamic update method of the system requirement document as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: Used to store computer programs; wherein, when the computer program is executed by a processor, the steps of the real-time dynamic update method of the system requirement document as described in any one of claims 1 to 7 are implemented.

Images