A traceability graph-driven multi-agent automated software development method

Abstract

The application provides a traceability diagram-driven multi-agent automated software development method, belonging to the technical field of software engineering, and receiving an original use case as input. The original use case can include fields such as use case name, description, participant, entry condition, event flow, exit condition and quality requirement. The framework first processes the original use case by a requirement refinement agent to obtain a refined use case with clear semantics and unified fields. Then, a design agent generates a class diagram and a sequence diagram according to the refined use case. Next, a development agent generates warehouse-level code according to the design model. Subsequently, a test agent generates and executes test cases. The entire process is checked for consistency between requirements, design and code by a verification agent, and problems found are fed back to the corresponding agent for iterative correction. The application is suitable for complex development scenarios and helps to improve the integrity, reliability and subsequent maintainability of the generation from requirements to code.

Description

Technical Field

[0001] This invention belongs to the field of software engineering technology, specifically, it relates to a traceability graph-driven multi-agent automated software development method. Background Technology

[0002] As the complexity of modern software systems continues to increase, traditional software development faces enormous challenges. The lengthy process from requirements analysis and system design to coding and testing is not only time-consuming and labor-intensive but also prone to errors. In recent years, large language models, represented by Gemini and DeepSeek, have developed rapidly, bringing a revolutionary paradigm shift to the field of software engineering. These technologies are increasingly making the vision of "requirements as code" a reality. Therefore, the research focus of industry and academia is gradually shifting from simple code completion to code generation from natural language requirements to repository-level code generation.

[0003] Existing research primarily focuses on code generation based on large language models and multi-agent collaborative software development. One type of research, represented by benchmarks such as HumanEval and MBPP, mainly focuses on generating single function-level implementations from short function descriptions or incomplete code snippets. Another type of research, represented by ChatDev and MetaGPT, simulates the requirements analysis, system design, code implementation, and testing processes in the software development lifecycle by assigning roles such as product manager, architect, developer, and tester to different agents. ChatDev uses communicable agents and dialogue chains to organize multi-agent collaboration, while MetaGPT uses standardized operating procedures (SOPs) to constrain collaborative development among different roles. While these methods have promoted the automation of the process from natural language requirements to code generation, they still have the following two limitations when facing real-world software development scenarios.

[0004] (1) Simplified Development Scenarios. In actual software development, requirements are usually documented in a structured, fine-grained form, with use cases being one of the most commonly used forms of requirement specification. An empirical study of requirement specifications from 12 companies found that 33% of respondents used use cases as requirement specifications, indicating that use cases are widely used in actual software projects. Requirements described by such use cases usually contain multiple functional points and rich semantic constraints. However, most existing code generation research is still based on inputs with relatively simple semantics and structure. For example, HumanEval and MBPP are mainly geared towards function-level programming tasks, with each task typically covering only a single function; the SRDD dataset used by ChatDev and the SoftwareDev dataset used by MetaGPT are also mostly coarse-grained task descriptions, such as "create a snake game" or "implement a shooting game". These inputs are difficult to fully reflect the complexity of multi-step, multi-constraint, and cross-component collaboration in real requirements.

[0005] (2) Lack of traceability. In software development and maintenance, there are complex relationships between software artifacts such as requirements, design models, test cases, and source code. Traceability can link requirements with corresponding designs and code implementations, helping developers understand the relationships between different artifacts and supporting change impact analysis, defect localization, and subsequent maintenance. Traditional requirements engineering has researched numerous automated traceability recovery methods, such as VSM based on information retrieval, probabilistic models, and traceability recovery methods based on BERT, prompt engineering, and RAG in recent years. However, most of these studies restore the tracing links between artifacts such as requirements, documents, and code after they have been generated, essentially constituting "post-event recovery." They do not treat traceability as an inherent constraint in the code generation process and struggle to promptly detect semantic deviations and functional omissions during the cross-stage transformation from requirements to design and from design to code. This problem is even more pronounced for multi-agent code generation systems. While methods like ChatDev and MetaGPT simulate the software development process through role-based division of labor, they primarily focus on whether functional code can be generated and executed, lacking mechanisms to continuously check whether "every requirement has been covered by the design model" and "every design element has been truly implemented in the code." When requirements are continuously transformed at different stages, without clear traceability, the system struggles to determine whether a precondition, abnormal process, or quality requirement has been overlooked. This deficiency weakens the completeness, reliability, and maintainability of repository-level code generation.

[0006] To address the aforementioned issues, TraceDev differs from existing work primarily in that it doesn't rely solely on single task descriptions or function-level specifications as input. Instead, it uses structured use cases containing multiple functionalities and complex semantic constraints as requirement input, thus more closely resembling real-world software development scenarios. Furthermore, instead of restoring traceability links after code generation, it proactively builds and maintains a heterogeneous traceability graph between requirements, design models, and code during development. Specifically, TraceDev comprises five types of agents: requirement refiner, designer, developer, tester, and verifier, responsible for requirement refinement, system design, code generation, testing and verification, and traceability maintenance, respectively. The verifier agent connects requirement nodes, design nodes, and code nodes by constructing a traceability graph to detect requirements not covered by the design, design elements not implemented in the code, and semantic inconsistencies during cross-stage transitions.

[0007] Therefore, compared to existing work, TraceDev's advantages are mainly reflected in two aspects. Firstly, it targets complex development scenarios driven by structured use cases, generating repository-level code from complete use cases, rather than just generating isolated functions or simple scripts. Secondly, it introduces traceability into the entire code generation process, providing a structured context and shared memory for multi-agent collaboration through a traceability graph, enabling the system to continuously perform consistency checks and iterative corrections between requirements, design, and code. Overall, TraceDev addresses the shortcomings of existing multi-agent code generation methods in complex requirement modeling and traceability maintenance, helping to improve the completeness, reliability, and subsequent maintainability of requirement-to-code generation. Summary of the Invention

[0008] To address the shortcomings of existing technologies, this invention proposes a traceability graph-driven multi-agent automated software development method. It uses energy sources such as electron accelerators, ultraviolet sources, and X-ray sources to charge lunar dust in order to study the charged characteristics of lunar dust. Based on this, it further studies the impact of charged lunar dust on various devices.

[0009] This invention is achieved through the following technical solution: A traceability graph-driven approach to developing multi-agent automated software: The method specifically includes the following steps: S1. Obtain the original use cases, and perform normalization on the original use cases to obtain refined use cases with clear structure and explicit semantics; S2. Generate a class diagram to describe the static structure of the target software system and a sequence diagram to describe the runtime interaction order of objects based on the refined use cases; S3. Generate repository-level code for the target software system based on the class diagram and the sequence diagram, ensuring that the generated code maintains consistency with the class diagram and sequence diagram in terms of overall structure and execution logic; S4. Construct test cases based on the detailed test cases and the repository-level code, compile and execute the test cases, extract error information and report it if errors are found, and drive the code repair process. S5. Construct a heterogeneous traceability graph, extract requirement nodes from detailed use cases, extract design nodes from class diagrams and sequence diagrams, extract code nodes from repository-level code, and establish directed tracing relationships between requirement nodes and design nodes, and between design nodes and code nodes. S6. Traverse the heterogeneous traceability graph, automatically identify missing links and abnormal links, and generate a quality report; if a requirement node fails to be associated with the corresponding design node, or a design node fails to be associated with the corresponding code node, the defect information will be fed back to drive the regeneration or correction process of the corresponding workpiece until the preset termination condition is met.

[0010] Furthermore, in S1, the original use case is the original requirement of the target software system described in the form of a use case; it includes fields such as use case name, description, actors, entry conditions, event flow, exit conditions, and quality requirements. The specific steps for normalizing the original use cases are as follows: S1.1 Standardization of Terminology: Standardize the fields for participants, entry conditions, event flow, exit conditions, and quality requirements from different data sources into a standardized format; S1.2 Subject Inference: Inferring the subject of execution in a natural language sentence based on the context, and rewriting ambiguous statements into atomized expressions with clear subjects, actions, and objects; S1.3 Formal Validation: Check the structural integrity of the refined test cases according to the preset syntactic constraints; if the check fails, the regeneration process is triggered.

[0011] Furthermore, in S2, generating class diagrams and sequence diagrams includes static structure modeling and dynamic interaction modeling, specifically: S2.1 Static Structure Modeling: Based on the noun phrases and business objects in the detailed use cases, identify the inheritance, association, and usage relationships between classes, attributes, methods, and objects, and generate a class diagram; S2.2 Dynamic Interaction Modeling: Identify the object interaction sequence, message call relationship, conditional branches and exception paths based on the event flow of the detailed use cases, and generate a sequence diagram.

[0012] Furthermore, in S3, generating repository-level code specifically involves: S3.1 Design Analysis: Analyze the structural and behavioral information in the class diagram and sequence diagram; S3.2 Code Generation: Generate multiple collaborative code files based on the parsing results; S3.3 Code Repair: Modify the generated code files based on the error information from S4 and the quality report from S6.

[0013] Furthermore, in S4, constructing and executing test cases specifically involves: S4.1, Construct Tests: Generate test cases that cover the main execution path, exception handling path, and key functional points in the test cases; S4.2 Execute the test: Compile and run the test cases, and record the test results; S4.3 Error Feedback: Extract the reasons for failure from the runtime logs and feed them back to the code repair process.

[0014] Furthermore, in S5, the construction of the heterogeneous traceability graph is specifically as follows: S5.1 Node Extraction: Extract traceable entities as nodes of corresponding types from detailed use cases, class diagrams and sequence diagrams, and repository-level code, respectively; S5.2 Link Establishment: Establish a directed tracing relationship from requirement nodes to design nodes to represent the design coverage relationship of requirements; establish a directed tracing relationship from design nodes to code nodes to represent the code implementation relationship of the design.

[0015] Furthermore, in S6, traversing the heterogeneous traceability graph and generating a quality report specifically involves: S6.1 Graph Traversal: Use graph traversal algorithms to traverse all nodes and edges of the heterogeneous traceability graph; identify requirement nodes that are not associated with any design nodes and design nodes that are not associated with any code nodes; S6.2 Generate Quality Report: Generate a quality report containing the defect location, related requirements, affected workpieces, and correction direction; feed the quality report back to the design correction process or code correction process according to the defect type.

[0016] A traceability graph-driven multi-agent automated software development system. The system includes a requirements refinement agent, a design agent, a development agent, a testing agent, and a verification agent. The requirement refinement agent is used to standardize the original use cases and output refined use cases; The design agent is used to generate class diagrams and sequence diagrams based on the refined use cases; The development agent is used to generate repository-level code based on the class diagram and the sequence diagram, and to repair the repository-level code based on feedback information; The test agent is used to generate and execute test cases and to feed back test failure information to the code generation unit; The verification agent is used to construct and maintain a heterogeneous traceability graph of associated requirement nodes, design nodes and code nodes, and to perform consistency verification and iterative correction based on the heterogeneous traceability graph.

[0017] Compared with the prior art, the beneficial effects of the present invention are as follows: (1) It can handle complex requirement scenarios. This invention takes use cases containing multiple functional points and rich semantic constraints as input, rather than relying solely on single-sentence requirement descriptions or short function specifications, which is closer to the requirement expression methods in real software development.

[0018] (2) It can explicitly maintain the traceability relationship between requirements, design and code. By constructing a traceability graph, the present invention can automatically discover problems such as requirements not being covered by design and designs not being implemented by code, thereby reducing functional omissions and semantic deviations.

[0019] (3) It can improve the functional correctness and executability of the generated code. The test agent and the development agent form a test feedback loop, and the verification agent, the design agent, and the development agent form a traceability correction loop. Both types of loops work together to improve code quality.

[0020] (4) It can improve the structure and maintainability of the generated code. The design agent establishes the system structure and interaction logic before code generation, making it easier for the generated code to form multiple collaborative modules, rather than a simple single-file script.

[0021] (5) It can support subsequent maintenance and understanding. The traceability diagram is not only used for verification during the generation process, but also as a structured description during the maintenance phase, helping developers to quickly understand the design and code location corresponding to a certain requirement and reduce the cognitive cost of system maintenance. Attached Figure Description

[0022] Figure 1 This is a schematic diagram of the overall process of the TraceDev invention. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0024] Unless otherwise specified, the experimental methods used in the following examples are conventional methods. Unless otherwise specified, the materials, reagents, methods, and instruments used are all conventional materials, reagents, methods, and instruments in the art, and can be obtained commercially by those skilled in the art.

[0025] like Figure 1 This invention proposes a traceability graph-driven multi-agent automated software development method and system; 1) Suitable for complex development scenarios. This framework is specifically designed for complex development scenarios, using use cases containing multiple functionalities as requirements, rather than simple descriptions. It achieves repository-level code generation by understanding the full scope of the use cases, rather than generating isolated functions.

[0026] 2) Construction and Application of Traceability Graph. This framework constructs a heterogeneous traceability graph linking requirements, design models, and code artifacts during development. This traceability graph can automatically detect unimplemented or incorrectly implemented requirements, supporting reliable repository-level code generation in complex development scenarios. Simultaneously, it serves as a structured context for managing software artifacts, providing an efficient memory management mechanism for multi-agent systems.

[0027] I. Overall Process The system receives an initial use case as input. This initial use case may include fields such as use case name, description, actors, entry conditions, event flow, exit conditions, and quality requirements. This invention first uses a requirements refinement agent to process the initial use case, resulting in semantically clear and field-consistent refined use cases. Then, a design agent generates class diagrams and sequence diagrams based on the refined use cases. Next, a development agent generates repository-level code based on the design model. Finally, a testing agent generates and executes test cases. Throughout the process, a verification agent constructs a traceability graph to check the consistency between requirements, design, and code, and feeds back any issues found to the corresponding agents for iterative correction.

[0028] II. Refined Intelligent Agent Requirements In real-world projects, the naming of use case fields varies across different systems. For example, some use cases use "preconditions" to describe the entry state, while others use "entry conditions" to describe similar information; some use cases use "event sequence," while others use "event flow." The requirements refinement agent first standardizes these terms into standard fields based on preset field templates.

[0029] For statements in natural language that lack an executing subject, the requirement refinement agent infers the subject based on the context. For example, if a use case step only states "check username and password length," the agent needs to determine that this check should be performed by the system and rewrite it as "the system checks whether the username and password length meet the requirements." Through this process, each step in the refined use case has a clear subject, action, and object, facilitating subsequent design and modeling.

[0030] After the requirements are refined, the formal validation module checks whether the refined test cases meet the preset syntactic constraints. If the refined test cases lack necessary fields, the field order does not meet the requirements, or the statement structure is incomplete, the module generates feedback information to drive the requirement refinement agent to be regenerated until the output meets the constraints.

[0031] III. Designing Intelligent Agents The design of intelligent agents takes refined use cases as input, first identifying the business entities, system roles, operation objects, and state information in the use cases, and then generating class diagrams. Class diagrams are used to represent the core classes, attributes, methods, and their relationships in the system, giving the system a clear structure before coding begins.

[0032] The design of the intelligent agent also generates sequence diagrams based on the use case event flow. Sequence diagrams represent the message passing relationships between participants, interface objects, business processing objects, and data access objects in chronological order, and express branches such as confirmation, cancellation, failure, and exception interruption. Through sequence diagrams, the development of the intelligent agent can more accurately understand the execution sequence of the business process.

[0033] IV. Developing and Testing Intelligent Agents After reading the class diagram and sequence diagram, the intelligent agent generates multiple collaborative code files. The generation process not only focuses on individual function implementations but also ensures that the dependencies between classes, the order of method calls, and exception handling logic remain consistent with the design model.

[0034] The test agent constructs test cases after code generation. Test cases should cover normal paths, boundary conditions, and abnormal paths. For example, for a test case involving deleting a business object, the test case needs to cover scenarios such as user confirmation of deletion, user cancellation of deletion, deletion failure, connection interruption, and prevention of duplicate submissions. After executing the tests, if the test agent finds compilation failures, runtime errors, or results that do not meet expectations, it extracts error logs, failure assertions, and relevant context, and feeds this information back to the development agent. The development agent then fixes the code based on the feedback and re-enters the testing process.

[0035] V. Verification of Intelligent Agents and Traceability Graph The verification agent is responsible for building and maintaining the traceability graph. This graph includes three types of nodes: requirement nodes, design nodes, and code nodes. Requirement nodes are derived from the actors, entry conditions, event steps, exit conditions, and quality requirements in the detailed use cases; design nodes are derived from classes, methods, relationships, and messages in class diagrams and sequence diagrams; and code nodes are derived from the generated code files and their main implementation structure.

[0036] The verification agent first establishes a traceability relationship from requirements to design. For each requirement node, the verification agent determines whether a corresponding design representation exists in the class diagram or sequence diagram. If a requirement does not have a corresponding design node, it indicates that the requirement may have been omitted during the design phase.

[0037] The verification agent further establishes a traceability relationship between design and code. For each design node, the verification agent uses syntactic structure analysis to determine whether it has been implemented in the generated code. If a design node does not have a corresponding code node, it indicates that the design may not have been actually implemented.

[0038] When the verification agent detects missing or inconsistent links, it generates a quality report. This report specifies the location of the defect, the relevant requirements, the potentially affected design or code artifacts, and provides directions for correction. If the problem occurs in the requirements-to-design phase, it is reported to the design agent; if the problem occurs in the design-to-code phase, it is reported to the development agent.

[0039] Heterogeneous traceability graphs also serve as a structured context management mechanism, organizing key semantic elements, structural elements, and code files into nodes and edges. This compact graph structure preserves core dependencies, reduces context redundancy, and improves the efficiency of multi-agent collaboration.

[0040] VI. Iterative Correction Mechanism To avoid infinite loops, this invention sets a maximum number of iterations. For traceability issues, the verification agent drives design or code correction within a limited number of iterations; for test failures, the testing agent drives code repair within a limited number of iterations. If the maximum number of attempts is reached and the test still fails, the latest version and corresponding warning messages are output for further human review.

[0041] Through the aforementioned iterative correction mechanism, this invention constrains the code generation process from both semantic coverage and execution correctness perspectives. The traceability graph ensures the integrity of the relationships between requirements, design, and code; test feedback ensures that the generated code can be compiled, run, and meet functional requirements.

[0042] VII. Experimental Examples In one experimental embodiment, the present invention uses two real-world requirement engineering datasets for evaluation, corresponding to a tourism system and an education management system respectively, containing a total of 125 use cases. Each use case is implemented by multiple code files, reflecting a repository-level code generation scenario in real software development.

[0043] Automatic evaluation considers both semantic coverage and success rate. Semantic coverage measures whether the generated code semantically covers the target functionality; success rate measures whether test cases that have passed semantic verification can execute correctly on the generated code. Human evaluation further assesses the executableness of the generated code to determine whether it can run and meets the requirements. Statistical analysis focuses on the number of code files, the number of effective lines of code, and the number of code tags to distinguish between minimal and more complete implementations.

[0044] Experimental results show that on the tourism system dataset, the semantic coverage of the proposed solution reaches 71.72%, and the success rate reaches 53.63%; on the education management system dataset, the success rate reaches 56.82%. Compared with existing multi-agent methods, the proposed solution exhibits higher stability in automatic evaluation, manual evaluation, and code statistical analysis.

[0045] Ablation experiments show that the verification agent, testing agent, and design agent all play important roles in overall performance. Removing the verification agent significantly reduces semantic coverage, indicating that the traceability graph is crucial for maintaining requirement integrity; removing the testing agent significantly reduces the success rate, indicating that test feedback is crucial for execution correctness; removing the design agent leads to a significant decrease in the number of code files and code size, indicating that design modeling is crucial for structured and modular implementation.

[0046] A computer device system includes a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the steps of the above-described method. A computer-readable storage medium having a computer program / instructions stored thereon, which, when executed by a processor, implement the steps of the above-described method.

[0047] A computer program product includes a computer program / instructions that, when executed by a processor, implement the steps of the method described above.

[0048] The memory in the embodiments of this application can be volatile memory or non-volatile memory, or may include both volatile and non-volatile memory. Non-volatile memory can be read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory can be random access memory (RAM), which is used as an external cache. By way of example, but not limitation, many forms of RAM are available, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate synchronous DRAM (DDR SDRAM), enhanced synchronous DRAM (ESDRAM), synchronous linked DRAM (SLDRAM), and direct rambus RAM (DR RAM). It should be noted that the memory of the methods described in this invention is intended to include, but is not limited to, these and any other suitable types of memory.

[0049] In the above embodiments, implementation can be achieved entirely or partially through software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented entirely or partially in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center via wired means such as coaxial cable, optical fiber, digital subscriber line, DSL, or wireless means such as infrared, wireless, microwave, etc. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that integrates one or more available media. The available medium can be a magnetic medium such as a floppy disk, hard disk, magnetic tape; an optical medium such as a high-density digital video disc, DVD; or a semiconductor medium such as a solid-state disk, SSD, etc.

[0050] In implementation, each step of the above method can be completed by integrated logic circuits in the processor's hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly implemented by a hardware processor, or by a combination of hardware and software modules in the processor. The software modules can reside in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory, and the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above method. To avoid repetition, detailed descriptions are omitted here.

[0051] It should be noted that the processor in the embodiments of this application can be an integrated circuit chip with signal processing capabilities. During implementation, each step of the above method embodiments can be completed by the integrated logic circuits in the processor's hardware or by instructions in software form. The processor can be a general-purpose processor, a digital signal processor (DSP), an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components. It can implement or execute the methods, steps, and logic block diagrams disclosed in the embodiments of this application. The general-purpose processor can be a microprocessor or any conventional processor. The steps of the methods disclosed in the embodiments of this application can be directly embodied as execution by a hardware decoding processor, or as execution by a combination of hardware and software modules in the decoding processor. The software modules can be located in random access memory, flash memory, read-only memory, programmable read-only memory, electrically erasable programmable memory, registers, or other mature storage media in the art. This storage medium is located in memory; the processor reads information from the memory and, in conjunction with its hardware, completes the steps of the above methods.

[0052] The foregoing has provided a detailed description of the traceability graph-driven multi-agent automated software development method proposed in this invention, and has elucidated the principles and implementation methods of this invention. The descriptions of the above embodiments are only for the purpose of helping to understand the method and core ideas of this invention. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this invention. Therefore, the content of this specification should not be construed as a limitation of this invention.

Claims

1. A traceability graph-driven method for developing multi-agent automated software, characterized in that: The method specifically includes the following steps: S1. Obtain the original use cases, and perform normalization on the original use cases to obtain refined use cases with clear structure and explicit semantics; S2. Generate a class diagram to describe the static structure of the target software system and a sequence diagram to describe the runtime interaction order of objects based on the refined use cases; S3. Generate repository-level code for the target software system based on the class diagram and the sequence diagram, ensuring that the generated code maintains consistency with the class diagram and sequence diagram in terms of overall structure and execution logic; S4. Construct test cases based on the detailed test cases and the repository-level code, compile and execute the test cases, extract error information and report it if errors are found, and drive the code repair process. S5. Construct a heterogeneous traceability graph, extract requirement nodes from detailed use cases, extract design nodes from class diagrams and sequence diagrams, extract code nodes from repository-level code, and establish directed tracing relationships between requirement nodes and design nodes, and between design nodes and code nodes. S6. Traverse the heterogeneous traceability graph, automatically identify missing links and abnormal links, and generate a quality report; if a requirement node fails to be associated with the corresponding design node, or a design node fails to be associated with the corresponding code node, the defect information will be fed back to drive the regeneration or correction process of the corresponding workpiece until the preset termination condition is met.

2. The method according to claim 1, characterized in that: In S1, the original use case is the original requirement of the target software system described in the form of a use case; it includes fields such as use case name, description, actors, entry conditions, event flow, exit conditions, and quality requirements. The specific steps for normalizing the original use cases are as follows: S1.1 Standardization of Terminology: Standardize the fields for participants, entry conditions, event flow, exit conditions, and quality requirements from different data sources into a standardized format; S1.2 Subject Inference: Inferring the subject of execution in a natural language sentence based on the context, and rewriting ambiguous statements into atomized expressions with clear subjects, actions, and objects; S1.3 Formal Validation: Check the structural integrity of the refined test cases according to the preset syntactic constraints; if the check fails, the regeneration process is triggered.

3. The method according to claim 2, characterized in that: In S2, generating class diagrams and sequence diagrams includes static structure modeling and dynamic interaction modeling, specifically: S2.1 Static Structure Modeling: Based on the noun phrases and business objects in the detailed use cases, identify the inheritance, association, and usage relationships between classes, attributes, methods, and objects, and generate a class diagram; S2.2 Dynamic Interaction Modeling: Identify the object interaction sequence, message call relationship, conditional branches and exception paths based on the event flow of the detailed use cases, and generate a sequence diagram.

4. The method according to claim 3, characterized in that: In S3, generating repository-level code specifically involves: S3.1 Design Analysis: Analyze the structural and behavioral information in the class diagram and sequence diagram; S3.2 Code Generation: Generate multiple collaborative code files based on the parsing results; S3.3 Code Repair: Modify the generated code files based on the error information from S4 and the quality report from S6.

5. The method according to claim 4, characterized in that: In S4, constructing and executing test cases specifically involves: S4.1, Construct Tests: Generate test cases that cover the main execution path, exception handling path, and key functional points in the test cases; S4.2 Execute the test: Compile and run the test cases, and record the test results; S4.3 Error Feedback: Extract the reasons for failure from the runtime logs and feed them back to the code repair process.

6. The method according to claim 5, characterized in that: In S5, constructing a heterogeneous traceability graph specifically involves: S5.1 Node Extraction: Extract traceable entities as nodes of corresponding types from detailed use cases, class diagrams and sequence diagrams, and repository-level code, respectively; S5.2 Link Establishment: Establish a directed tracing relationship from requirement nodes to design nodes to represent the design coverage relationship of requirements; establish a directed tracing relationship from design nodes to code nodes to represent the code implementation relationship of the design.

7. The method according to claim 6, characterized in that: In S6, traversing the heterogeneous traceability graph and generating a quality report specifically involves: S6.1 Graph Traversal: Use graph traversal algorithms to traverse all nodes and edges of the heterogeneous traceability graph; identify requirement nodes that are not associated with any design nodes and design nodes that are not associated with any code nodes; S6.2 Generate Quality Report: Generate a quality report containing the defect location, related requirements, affected workpieces, and correction direction; based on the defect type, feed the quality report back to the design correction process or code correction process.

8. A traceability graph-driven multi-agent automated software development system, characterized in that: The system is used to execute the traceability graph-driven multi-agent automated software development method according to any one of claims 1 to 7. The system includes a requirements refinement agent, a design agent, a development agent, a testing agent, and a verification agent. The requirement refinement agent is used to standardize the original use cases and output refined use cases; The design agent is used to generate class diagrams and sequence diagrams based on the refined use cases; The development agent is used to generate repository-level code based on the class diagram and the sequence diagram, and to repair the repository-level code based on feedback information; The test agent is used to generate and execute test cases and to feed back test failure information to the code generation unit; The verification agent is used to construct and maintain a heterogeneous traceability graph of associated requirement nodes, design nodes and code nodes, and to perform consistency verification and iterative correction based on the heterogeneous traceability graph.

9. A computer device system, comprising a memory, a processor, and a computer program stored in the memory, characterized in that, The processor executes the computer program to implement the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium having a computer program / instructions stored thereon, characterized in that, When the computer program / instructions are executed by the processor, they implement the steps of the method according to any one of claims 1 to 7.

Images