Task acceptance criteria automatic generation method based on domain graph enhanced retrieval

Abstract

The application discloses a kind of based on field atlas enhanced search task acceptance criterion automatic generation method, belong to the intersection field of software engineering and artificial intelligence.The method fuses static code analysis and large language model, automatically generates three-section task acceptance criterion, core process is: parse Java source file and generate function abstract, identify domain driven design architecture level;Based on package hierarchical structure, delimit boundary context, filter domain concept class to construct general language glossary;Fusion static analysis and semantic reasoning, construct the field atlas containing dependency, combination, trigger and response relationship edge;Finally, the atlas topological structure is used to search candidate context, after being filtered by large language model, combined with general language glossary, traverse application service, automatically generate structured acceptance criterion.The application improves the precision and business relevance of criterion generation by enhanced retrieval of field atlas.

Description

Technical Field

[0001] This invention belongs to the interdisciplinary field of software engineering and artificial intelligence, and in particular relates to an automatic generation method for task acceptance criteria based on domain graph enhancement retrieval. Background Technology

[0002] Domain-Driven Design (DDD), as a mainstream architectural approach for complex business systems, explicitly maps business semantics into the code structure through building blocks such as bounded contexts, aggregates, entities, value objects, and domain services, effectively addressing business complexity. However, in the long-term evolution of DDD projects, the problem of requirement documents and user stories gradually being lost or becoming disconnected from the code is common. The lag in personnel turnover, organizational adjustments, and documentation maintenance means that a large amount of business knowledge remains only in the code, forming a typical technical debt of "code still exists, documentation is missing." Against this backdrop, how to reverse engineer business requirements from existing DDD codebases has become a crucial issue that urgently needs to be addressed in software engineering.

[0003] The current reverse engineering process faces three major technical challenges. First, the lack of requirements documentation makes it difficult to trace the original business intent. DDD projects typically have complete requirements specifications in their early stages, but as the system evolves, these documents are either lost or outdated. Furthermore, the legacy system code is massive and structurally complex, making it difficult to reconstruct the business motivation behind the design based solely on the code itself. Second, manual reverse engineering is costly. Traditional methods rely on senior architects reading code line by line, inferring business logic, and manually writing requirements documents. This process is time-consuming, labor-intensive, and highly dependent on individual experience, making it difficult to scale. A complete reverse engineering analysis of a medium-sized DDD project (hundreds of thousands of lines of code) often takes weeks or even months, significantly impacting project delivery efficiency. Third, there is a gap between program structure and business semantics. Source code exists in the form of classes, methods, interfaces, and dependencies, while acceptance criteria are centered on user behavior, business rules, and expected results. The mapping from low-level program structure to high-level business use cases inherently lacks a direct derivation path. Although static analysis tools can extract call relationships, they struggle to understand business intent, and general document generation tools cannot express domain-specific business semantics.

[0004] To address the aforementioned issues, existing technical solutions each have their limitations. While manual reverse engineering offers high-quality results, efficiency and consistency are difficult to guarantee. Static analysis tools (such as SonarQube and Structurizr) can reveal code structure, but their ability to extract business semantics is limited. General RAG document generation solutions based on retrieval enhancement lack a deep understanding of DDD-specific concepts (such as aggregate roots and domain events), resulting in superficial documentation. Tracing tools (such as R2Code) rely on existing requirement documents and cannot handle scenarios where documentation is missing. Therefore, establishing a mapping relationship between program structure and business semantics in a DDD codebase, and automatically generating standardized, semantically complete, and traceable acceptance criteria, has become a core challenge that urgently needs to be overcome. Summary of the Invention

[0005] The purpose of this invention is to solve the problem of reverse recovery of business requirements in legacy DDD systems in the prior art, and to provide an automatic generation method for task acceptance criteria based on domain graph enhancement retrieval, so as to achieve efficient and automated derivation from code structure to business intent, and provide a feasible technical path to reduce manual costs and improve the quality of reverse documentation.

[0006] To achieve the above-mentioned objectives, the present invention specifically adopts the following technical solution:

[0007] In a first aspect, the present invention provides a method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval, comprising the following steps:

[0008] S1. Perform static parsing and semantic analysis on each Java source file in the project source code, extract structured information for domain concept identification and domain graph construction, determine the level of the Java source file in the domain-driven design architecture, and submit the project directory tree and project source code to the large language model to generate a functional summary of each Java source file.

[0009] S2. Determine the level of the bounded context based on the package hierarchy, and then determine the bounded context of each class; take the class belonging to a certain domain concept as the domain concept class, obtain the relevant context of the domain concept class through the domain concept class context filtering algorithm, and submit the class name, member method signature, bounded context, and relevant context of each domain concept class to the large language model to generate a general language vocabulary composed of multiple concepts;

[0010] S3. By integrating static program analysis and semantic reasoning of large language models, a domain graph reflecting the deep relationship of business logic is constructed for each bounded context. The nodes in the domain graph are all concepts imported from the general language vocabulary, and the directed edges in the domain graph include dependency edges, composition edges, trigger edges, and response edges.

[0011] S4. Utilize the topological structure of the domain graph to retrieve the domain knowledge required for the task acceptance criteria as candidate contexts, and have the large language model select the most relevant contexts from the candidate contexts; traverse each application service, submit the selected contexts and general language vocabulary to the large language model, and generate a three-stage task acceptance criterion.

[0012] Based on the above scheme, each step can be implemented in the following preferred manner.

[0013] As a preferred embodiment of the first aspect mentioned above, in S1, a Java source code parser is used to traverse each Java source file in the project source code and extract structured information from the Java source files, including file paths, package names, class names, annotations, member variables, member method signatures, and dependencies.

[0014] As a preferred option of the first aspect mentioned above, in S1, the process of determining the level of the Java source file is as follows: the content of the Java source file is submitted to the large language model, which then determines and marks the Java source file as belonging to the presentation layer, application layer, domain layer, or infrastructure layer based on the package path and directory structure, the responsibilities of the class in the software engineering project, the dependencies, whether it contains framework-related code, whether it contains domain models, domain services, or business rules.

[0015] As a preferred embodiment of the first aspect mentioned above, in S1, for the Java source files of the domain layer, the large language model determines the domain category of the unique public class corresponding to the Java source file based on the class name, annotations, member variables, member method signatures, and the class's responsibilities in the software engineering project. The domain category includes entity classes, value objects, domain services, domain events, domain abstractions, domain specifications, and others. At the same time, the functional summary of the Java source file and the code snippets of the member methods in the class are submitted to the large language model. The large language model outputs the judgment result of whether the Java source file contains business rules, and if the Java source file contains business rules, it outputs the business rule type. Business rules include state constraints, condition judgments, business decision logic, and cross-object business logic.

[0016] As a preferred option of the first aspect mentioned above, in S1, for Java source files in the application layer, the large language model outputs the classification result of whether the unique public class in the Java source file is an application service based on the class's responsibilities, member method signatures, and dependencies in the software engineering project.

[0017] As a preferred embodiment of the first aspect mentioned above, in S2, the bounded context level is determined by the following method: by statically analyzing and traversing all package nodes in the i-th level of the package hierarchy, if there is a cross-context dependency relationship between the sub-packages of each package node in the i-th level, then traversing all package nodes in the (i-1)-th level of the package hierarchy to gradually narrow down the range of the package hierarchy level where the bounded context is located, until there is no cross-context dependency relationship between the sub-packages of each package node in a certain level, and the current package hierarchy is taken as the bounded context level, and all package nodes in this package hierarchy are regarded as a bounded context; i is the package hierarchy index.

[0018] As a preferred embodiment of the first aspect mentioned above, in S2, the bounded context to which each class belongs is determined by the following method: package nodes identified as bounded contexts are taken as candidate packages, the functional summaries of the candidate packages are submitted to the large language model, the large language model judges the semantic boundaries between package nodes based on domain-driven design principles, identifies bounded contexts from the perspective of business semantics, and outputs the bounded context name and definition; then, according to the relationship between the class and the candidate package, the bounded context to which each class belongs is determined.

[0019] As a preferred embodiment of the first aspect above, in S2, obtaining the relevant context of a domain concept class through the domain concept class context filtering algorithm specifically involves: for any domain concept class, selecting the Top-K other domain concept classes with the highest comprehensive scores from all other domain concept classes that depend on this domain concept class as relevant contexts; the comprehensive score is a weighted sum of the functional relevance score and the dependency relevance score; the functional relevance score is the score output by the large language model after evaluating the relevance of this domain concept class to other domain concept classes in terms of functional responsibilities; the dependency relevance score is a weighted sum of the category score, the distance score, and the citation score; the category score is the score set for other domain concept classes of a certain category according to expert experience; the distance score is negatively correlated with the directory distance between this domain concept class and other domain concept classes; the citation score is used to quantify the activity of this domain concept class being cited by other domain concept classes, and the citation score is positively correlated with the number of citations.

[0020] As a preferred option for the first aspect mentioned above, in S3, the node types include entity classes, domain services, application services, domain events, domain abstractions, domain specifications, and others; the node attributes include specification names, concept definitions, class names in code mappings, domain concepts, member variables belonging to value objects, the judgment result of whether a certain entity class is an aggregate root, and the aggregate to which it belongs.

[0021] As a preferred option of the first aspect mentioned above, in S3, the following method is used to determine whether an entity class is a aggregate root: First, obtain the list of all member entity classes, the list of application services or domain services that depend on the entity class, and the signatures of the member methods contained in the entity class as the context information of the entity class through static analysis. Submit the context information to the large language model, and the large language model outputs the judgment result of whether the entity class is an aggregate root.

[0022] As a preferred embodiment of the first aspect mentioned above, in S3, after determining the aggregate root, a composite edge is established between an entity class that is an aggregate root and another entity class that is not an aggregate root. In the domain graph after establishing the composite edge, starting from the entity class that is not an aggregate root, or the domain abstraction or value object, the nearest aggregate root is searched along the composite edge towards the parent node: if only one aggregate root is reachable, the entity class is assigned to the aggregate corresponding to that aggregate root; if multiple aggregate roots are reachable, the entity class is assigned to the aggregate corresponding to a randomly selected aggregate root; if no aggregate root is reachable, the user provides the aggregation partitioning result for the entity class.

[0023] As a preferred embodiment of the first aspect mentioned above, in S3, the method for establishing trigger edges and response edges is as follows: All aggregate roots, domain services, and application services that have dependencies on a certain domain event are identified through static analysis, and source code fragments at the dependencies are extracted; the class belonging to the domain event is designated as the domain event class, and the domain event class name and source code fragment are submitted to the large language model. If the large language model determines that the dependency is a trigger relationship, a trigger edge is established pointing from the aggregate root, domain service, and application service to the domain event. If the large language model determines that the dependency is a response relationship, a response edge is established pointing from the domain event to the aggregate root, domain service, and application service.

[0024] As a preferred embodiment of the first aspect above, in S3, the method for establishing dependency edges is as follows: If a member method of an application service has a dependency relationship with a core domain component, then a dependency edge is established from the application service to the core domain component, where the core domain component is a domain service, entity class, or domain specification; for a domain service that depends on a domain entity or domain specification, then a dependency edge is established from the domain service to the domain entity or the domain specification; for a member method of a domain entity that depends on a domain specification, then a dependency edge is established from the domain entity to the domain specification; for other types of nodes that depend on a domain concept class, then a dependency edge is established from other types of nodes to the domain concept class; each dependency edge contains a dependency list; for a dependency edge with a member method dependency, then the dependency list of the dependency edge contains the correspondence between the dependent member method and the member method of the dependent domain concept class.

[0025] As a preferred embodiment of the first aspect above, in S4, the candidate context includes a business rule description and an acceptance criterion context. The method for retrieving the business rule description and the acceptance criterion context is as follows:

[0026] S41. Starting from the member methods of each class identified as containing business rules, perform an n-hop traversal along the dependency edges of the domain graph, and take all nodes that can be reached by at most n dependency edges as candidate nodes, and obtain the domain concept class and functional summary corresponding to the candidate nodes as the business rule context; n is the preset maximum number of dependency edges to traverse.

[0027] S42. Submit the code snippets, business rule context, and general language vocabulary of the business rules obtained from the Java source files to the large language model to generate a business rule description containing the code snippets;

[0028] S43. For each application service, first start from each domain concept class belonging to the application service, traverse along the dependency edges to obtain the aggregate root, the method code snippet of the domain service, and the business rule code snippet of the domain specification; then start from the obtained aggregate root, traverse along the composition edge to obtain the code snippet corresponding to the member variable definition of the entity class and value object; then start from the application service and the obtained aggregate root, traverse along the trigger edge or response edge to obtain the domain event code snippet; use all the obtained code snippets as task acceptance criteria to generate the required acceptance criterion context.

[0029] In a second aspect, the present invention provides a computer program product, including a computer program / instruction, which, when executed by a processor, can realize the automatic generation method for task acceptance criteria based on domain graph enhancement retrieval as described in any of the solutions of the first aspect above.

[0030] Thirdly, the present invention provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method for automatically generating task acceptance criteria based on domain graph enhancement retrieval as described in any of the solutions of the first aspect above.

[0031] Fourthly, the present invention provides a computer electronic device, which includes a memory and a processor;

[0032] The memory is used to store computer programs;

[0033] The processor is configured to, when executing the computer program, implement the automatic generation method for task acceptance criteria based on domain graph enhancement retrieval as described in any of the solutions of the first aspect above.

[0034] Compared with the prior art, the present invention has the following advantages:

[0035] This invention addresses the task of generating acceptance criteria based on source code by constructing a domain-driven semantic graph, transforming semantic information such as aggregation structures, bounded contexts, and domain events in the source code into graph nodes and edges. Building upon this, and combining GraphRAG technology, a context scoring mechanism that integrates business semantics and source code structure is proposed. This mechanism accurately selects the most helpful information for generating acceptance criteria from the large-scale context of the project repository. This approach ensures context integrity while effectively reducing context length and avoiding noise interference from a large amount of code unrelated to business semantics in the entire repository, effectively solving the context anxiety problem commonly encountered in long-context tasks in existing large models. Furthermore, in the output of acceptance criteria, by constructing a mapping from domain-layer Java classes to a general language vocabulary, consistency in the expression of the same concept is ensured across all acceptance criteria. Therefore, this invention, based on GraphRAG and a context scoring mechanism that integrates business semantics and source code structure, can effectively improve the performance of acceptance criterion generation. Attached Figure Description

[0036] Figure 1 This is a flowchart of the steps of the present invention;

[0037] Figure 2 This is a schematic diagram of the comprehensive scoring components of the present invention;

[0038] Figure 3 This is a schematic diagram of the directed edge types included in the domain map of the present invention;

[0039] Figure 4 This is a flowchart illustrating the process of retrieving candidate contexts in this invention;

[0040] Figure 5 This is a schematic diagram of a computer electronic device provided by the present invention. Detailed Implementation

[0041] To make the above-mentioned objects, features, and advantages of the present invention more apparent and understandable, the specific embodiments of the present invention will be described in detail below with reference to the accompanying drawings. Many specific details are set forth in the following description to provide a thorough understanding of the present invention. However, the present invention can be practiced in many other ways different from those described herein, and those skilled in the art can make similar modifications without departing from the spirit of the present invention. Therefore, the present invention is not limited to the specific embodiments disclosed below. Technical features in the various embodiments of the present invention can be combined accordingly without mutual conflict.

[0042] In the description of this invention, it should be understood that the terms "first" and "second" are used only for descriptive purposes and should not be construed as indicating or implying relative importance or implicitly specifying the number of indicated technical features. Therefore, a feature defined with "first" and "second" may explicitly or implicitly include at least one of those features.

[0043] like Figure 1 As shown, in a preferred embodiment of the present invention, the above-mentioned method for automatically generating task acceptance criteria based on domain graph enhancement retrieval includes the following steps S1 to S4. The specific implementation process of each step will be described in detail below.

[0044] S1. Perform static parsing and semantic analysis on each Java source file in the project source code, extract structured information for domain concept identification and domain graph construction, determine the level of the Java source file in the domain-driven design architecture, and submit the project directory tree and project source code to the Large Language Model (LLM) to generate a functional summary of each Java source file.

[0045] It should be noted that in S1, a Java source code parser (such as Spoon) is used to traverse each Java source file in the project source code and extract structured information from the Java source files, including file paths, package names, class names, annotations, member variables, member method signatures, and dependencies.

[0046] It should be noted that in S1, the process of determining the layer of a Java source file is as follows: The Java source file content is submitted to the large language model, which then determines and marks the Java source file as belonging to the presentation layer, application layer, domain layer, or infrastructure layer based on the package path and directory structure, the class's responsibilities in the software engineering project, dependencies, whether it contains framework-related code, whether it contains domain models, domain services, or business rules.

[0047] In this embodiment, the following prompt words are used to guide the large language model to determine the level of the Java source file in the domain-driven design architecture:

[0048] "Task: Determine the level of the Java file's source code within the Domain-Driven Design architecture. Possible levels include: Presentation Layer; Application Layer; Domain Layer; Infrastructure Layer."

[0049] Please make your judgment based on the following clues: package path and directory structure; class responsibilities (e.g., Controller, Application Service, Domain Entity, Repository implementation, etc.); dependencies (imported classes, called classes); whether it contains framework-related code (e.g., Spring MVC, database access, etc.); whether it contains domain models, domain services, or business rules.

[0050] It should be noted that in S1, for Java source files in the domain layer, the large language model determines the domain category of the unique public class in the Java source file based on the class name, annotations, member variables, member method signatures, and the class's responsibilities in the software engineering project. The domain category includes entity classes, value objects, domain services, domain events, domain abstractions, domain specifications, and others. At the same time, the functional summary of the Java source file and the code snippets of the member methods in the class are submitted to the large language model. The large language model outputs the judgment result of whether the Java source file contains business rules. If the Java source file contains business rules, it outputs the business rule type. Business rules include state constraints, condition judgments, business decision logic, and cross-object business logic.

[0051] In this embodiment, when the large language model determines the domain category of the corresponding unique public class in the Java source file, it also outputs the confidence level and the basis for the determination. Specifically, this embodiment uses the following prompt words to guide the large language model in determining the domain category of the aforementioned unique public class:

[0052] "You are a software architecture analysis expert familiar with Domain-Driven Design (DDD). Given the source code of a Java class and the overall directory hierarchy of the project, please determine the category of this class in domain modeling. Possible categories include: 1. Entity: Has a unique identifier (ID), lifecycle, mutable state, and carries business invariants; 2. Value Object: Has no unique identifier, immutable state, and defines equivalence through attribute values; 3. Domain Service: A stateless object that encapsulates business logic involving multiple aggregates or entities; 4. Domain Event: Represents the fact that a business has occurred, typically used to notify other aggregates; 5. Domain Abstraction: An interface or abstract class that defines behavioral contracts or commonalities of aggregate roots / entities; 6. Specification: Encapsulates reusable business rules that can be combined to determine whether an object meets certain conditions; 7. Other: Does not belong to any of the above categories, but is located in the domain layer."

[0053] Task: 1. Determine which category this type of data most likely belongs to; 2. Provide the confidence level of your judgment (0-1); 3. Briefly explain the basis for your judgment; 4. Determine whether manual intervention is necessary.

[0054] In this embodiment, similarly, when the large language model determines whether a Java source file contains business rules, it will also output the confidence level and the basis for the judgment. Specifically, this embodiment uses the following prompt words to guide the large language model in determining whether a Java source file contains business rules:

[0055] "You are an expert in Domain-Driven Design (DDD) and code semantic analysis. Based on the content of the provided Java source code file, please determine whether the file may contain business rules, and provide the basis and confidence level for your judgment."

[0056]

Definition of Business Rules

[0057] The following should not be considered business rules: 1. Technical validation (e.g., null checks, parameter empty checks, log printing); 2. Simple getters / setters; 3. Data transformation (DTO ↔ Entity); 4. Persistence operations (repository.save / query); 5. Framework code (Controller routes, configuration classes); 6. Pure utility classes (string processing, time processing, etc.).

[0058] It should be noted that in S1, for Java source files in the application layer, the large language model outputs the classification result of whether the unique public class in the Java source file is an application service based on the class's responsibilities, member method signatures, and dependencies in the software engineering project.

[0059] In this embodiment, when determining whether a unique public class is an application service, the large language model also refers to the typical characteristics of application services, such as being located in the application layer, coordinating domain objects to complete use cases, orchestrating business processes rather than implementing core business rules, and outputting confidence levels and judgment criteria. Specifically, this embodiment uses the following prompt words to guide the large language model in determining whether a unique public class is an application service:

[0060] "You are a software architecture analysis expert familiar with Domain-Driven Design (DDD). Given the source code of a Java class, please determine whether the class belongs to an Application Service."

[0061] Typical characteristics of an Application Service include: it resides in the application layer and is used to coordinate domain objects to complete use cases; its primary responsibility is to orchestrate business processes rather than implement core business rules; it typically calls Domain Entity, Domain Service, and Repository; its methods often correspond to a single business use case; it generally does not contain complex business rules; and common naming conventions include `*ApplicationService`, `*AppService`, `*Service`, and `*UseCase`.

[0062] It is important to distinguish between the following cases that are not Application Services: Controller / API layer (presentation layer); Domain Service (containing core business rules); Repository or Repository implementation; InfrastructureAdapter; Utility class.

[0063] Tasks: 1. Determine if the class is an Application Service; 2. Provide the confidence level (0-1); 3. Determine if manual intervention is required; 4. Briefly explain the basis for the judgment.

[0064] It should be noted that in S1, when the large language model generates a functional summary of a Java source file, the functional summary focuses on the responsibilities of classes in the software engineering project and their potential roles in the domain-driven design (DDD) context, rather than code implementation details. Specifically, this embodiment uses the following prompts to guide the large language model in generating a functional summary of the Java source file:

[0065] "The current project uses Domain-Driven Design (DDD). Please provide a functional summary of the classes involved in the Java source code, based on the context information provided by the project directory structure, highlighting the responsibilities of these classes in the system and their potential roles in the DDD context."

[0066] Requirements: Summarize based solely on observable information from the code; avoid excessive speculation. The summary should focus on "responsibilities" and "business semantics," rather than code implementation details.

[0067] S2. Based on the package hierarchy, determine the level of the bounded context, and then determine the bounded context of each class; take the class belonging to a certain domain concept as the domain concept class, obtain the relevant context of the domain concept class through the domain concept class context filtering algorithm, and submit the class name, member method signature, bounded context, and relevant context of each domain concept class to the large language model to generate a general language vocabulary composed of multiple concepts, so as to establish a traceable mapping from concepts to Java source files.

[0068] It should be noted that in S2, the core rule for determining the bounded context level is: for classes classified as application services, the directly referenced entity classes and domain services must be in the same bounded context. Therefore, this invention determines the bounded context level using the following method: Through static analysis, traverse all package nodes in the i-th level of the package hierarchy. If there are cross-context dependencies between the sub-packages of each package node in the i-th level, then traverse all package nodes in the (i-1)-th level of the package hierarchy to gradually narrow down the range of the bounded context levels until a certain level is found where there are no cross-context dependencies between the sub-packages of each package node. This current package level is then taken as the bounded context level, and all package nodes in this package level are considered a bounded context; i is the package level index.

[0069] After determining the level of the bounded context, this invention determines the bounded context to which each class belongs through the following method: package nodes identified as bounded contexts are taken as candidate packages, and the functional summaries of the candidate packages are submitted to the large language model. The large language model judges the semantic boundaries between package nodes based on domain-driven design principles, identifies the bounded context from the perspective of business semantics, and outputs the bounded context name and definition; then, according to the relationship between the class and the candidate package, the bounded context to which each class belongs is determined.

[0070] like Figure 2As shown, the relevant context of a domain concept class is obtained through a domain concept class context filtering algorithm as follows: For any domain concept class, the top-K other domain concept classes with the highest comprehensive scores are selected from all other domain concept classes that depend on this domain concept class as relevant contexts; the comprehensive score is a weighted sum of the functional relevance score and the dependency relevance score; the functional relevance score is the score output by the large language model after evaluating the relevance of this domain concept class with other domain concept classes in terms of functional responsibilities; the dependency relevance score is a weighted sum of the category score, the distance score, and the citation score; the category score is the score set for other domain concept classes of a certain category according to expert experience; the distance score is negatively correlated with the directory distance between this domain concept class and other domain concept classes; the citation score is used to quantify the activity of this domain concept class being cited by other domain concept classes, and the citation score is positively correlated with the number of citations.

[0071] In this embodiment, the overall score is controlled between 0 and 10. For domain concept classes... Dependent on domain concept classes Other domain concept classes Overall rating Calculate using the following formula:

[0072]

[0073] in, Dependency relevance score; Scoring for functional relevance.

[0074] Furthermore, the above dependency relevance score is calculated using the following formula:

[0075]

[0076] in, Rate the category; Rate the distance; Rate the reference.

[0077] Furthermore, the above distance score is calculated using the following formula:

[0078]

[0079]

[0080] in, The exponential decay coefficient is... For attenuation rate control parameters, and All of these can be set by those skilled in the art according to actual needs, and no restrictions are imposed in this invention; Distance between directories; Domain concept class The length of the package directory tree path; Concepts for other domains The length of the package directory tree path; Domain concept class Other domain concept classes The longest common prefix length between them; specifically, in this embodiment, in the domain concept class... Other domain concept classes In their respective package directory tree paths, the comparison starts from the first element. If starting from the first element... If the starting paths of the two package directory trees are different for each element, then... As a domain concept class Other domain concept classes The length of the longest common prefix; For element index.

[0081] Furthermore, the above citation score is calculated using the following formula:

[0082]

[0083] in, Concepts for other domains The Java source file contains the domain concept class. The number of references, i.e., when there are no references. ; Domain concept class The maximum number of references is determined by first traversing the domain concept classes. All other domain concept classes, and then obtain the Java source files for each of these other domain concept classes. The maximum reference count is the maximum number of references obtained from all the reference counts.

[0084] It should be noted that in S2, each concept contains four core elements: a canonical name, a concept definition (describing its business meaning in natural language), and a code mapping (the corresponding class name and member method signatures). After the large language model outputs a general language vocabulary, it needs to be manually reviewed and confirmed.

[0085] S3. By integrating static program analysis and semantic reasoning of a large language model, a domain graph reflecting the deep relationship of business logic is constructed for each bounded context. The nodes in the domain graph are all concepts imported from a general language vocabulary, and the directed edges in the domain graph include dependency edges, composition edges, trigger edges, and response edges.

[0086] It should be noted that in S3, the domain map established by this invention corresponds one-to-one with the bounded context, and all subsequent operations are performed within the same bounded context. All dependencies that cross bounded contexts are not considered.

[0087] It should be noted that in S3, node types include entity classes, domain services, application services, domain events, domain abstractions, domain specifications, and others; node attributes include specification name, concept definition, class name in code mapping, domain concept, member variables belonging to value objects, the result of the judgment of whether a certain entity class is an aggregate root, and the aggregate to which it belongs.

[0088] In this embodiment, the node types and descriptions are shown in Table 1. For nodes belonging to the entity class type, this embodiment uses dependencies and the domain concept types obtained above to filter which member variables in the entity class are value objects and populates them into the attributes of the entity class node. For classes that do not belong to the above types but contain business rules (such as factory classes), a new "Other" type node is added.

[0089] Table 1. Node Types and Descriptions

[0090] It should be noted that in standardized Domain-Driven Design (DDD) engineering, dependency relationships directly indicate whether an entity class is a aggregate root. Aggregate roots should only be referenced by IDs; when one class holds the ID of another class as a member variable, the relationship between the two classes is an ID reference relationship. However, in actual engineering, code rarely strictly adheres to this rule. Therefore, this invention uses the following method to determine whether an entity class is a aggregate root: First, static analysis is used to obtain a list of all member entity classes, a list of application services or domain services that depend on the entity class, and the signatures of the member methods contained in the entity class as context information for the entity class. This context information is submitted to the large language model, which outputs the result of determining whether the entity class is a aggregate root. The aforementioned list of member entity classes refers to: if the class to which a member variable belongs is an entity class, then the class to which this member variable belongs is defined as a member entity class, and all member entity classes are collected to obtain the list of member entity classes.

[0091] In this embodiment, when context information is submitted to the large language model, the large language model performs analysis according to the following logic and outputs the final judgment result based on the analysis results:

[0092] 1) For an application service that belongs to the application service list or a domain service that belongs to the domain service list, if its parameter or return value type is the entity class, then the entity class is likely to be the aggregate root.

[0093] 2) If the entity class holds other entity classes, and the source code of the member methods of the entity class contains code logic to maintain the data consistency of the entity class, then the entity class is likely to be the aggregate root.

[0094] 3) If an entity class only appears in the member variables of other entity classes and is not depended on by any application service or domain service, then the entity class is not an aggregate root.

[0095] 4) If the entity class has business invariants in its source code that are not getter or setter methods, then the entity class is an aggregate root.

[0096] After determining the aggregate root, this embodiment further establishes a composite edge between an entity class that is an aggregate root and another entity class that is not an aggregate root. The establishment method is as follows: if a member variable of an entity class contains another entity class or domain abstraction or value object, and the other entity class contained in the entity class is not an aggregate root, then a composite edge is established from the containing entity class to the contained entity class.

[0097] In the domain graph after the composite edges are established, starting from the entity class, domain abstraction, or value object that is not the aggregate root, search for the nearest aggregate root along the composite edge to the parent node: if only one aggregate root is reachable, then the entity class is assigned to the aggregate corresponding to that aggregate root; if multiple aggregate roots are reachable, then the entity class is assigned to the aggregate corresponding to a randomly selected aggregate root; if no aggregate root is reachable, then the user provides the aggregate partitioning result for the entity class.

[0098] In this embodiment, when no aggregate root is reachable, the user needs to determine whether the entity class belongs to an aggregate corresponding to an aggregate root, whether the entity class should be treated as a new aggregate root independently, or whether the entity class does not belong to any aggregate. After the user completes the determination, the aggregate partitioning result for the entity class is provided. It is worth noting that in this stage, in the domain graph, entity classes determined to be aggregate roots are labeled with an aggregate root tag, and the entity class, domain abstraction, and value object are marked with their respective aggregates. The name of the aggregate is named after the aggregate root class representing that aggregate. The above aggregate establishment process ensures that each aggregate corresponds to a unique aggregate root.

[0099] It should be noted that domain events, within the domain layer, are generally triggered by domain services or aggregate roots and responded to by domain services. However, in actual engineering, domain events and integrated events are often used interchangeably, therefore this invention does not make a distinction. This invention further identifies event directions and establishes triggering and response edges by combining static analysis with large language model judgment.

[0100] The method for establishing trigger edges and response edges is as follows: Static analysis is used to identify all aggregate roots, domain services, and application services that have dependencies on a specific domain event, and source code snippets at the dependencies are extracted. The class belonging to that domain event is designated as the domain event class, and the domain event class name and source code snippet are submitted to the large language model. If the large language model determines that the dependency is a trigger relationship, a trigger edge is established pointing from the aggregate root, domain service, and application service to the domain event. If the large language model determines that the dependency is a response relationship, a response edge is established pointing from the domain event to the aggregate root, domain service, and application service.

[0101] In this embodiment, when the large language model determines whether a dependency relationship is a triggering relationship or a response relationship, the criteria are as follows: triggering relationships are usually accompanied by calls to publish(), apply(), addDomainEvent(), etc., or direct instantiation of events; response relationships are usually accompanied by the @EventListener annotation, implementation of the Handle interface, and the method parameters containing the event.

[0102] The dependency edges are established as follows: If a member method of an application service has a dependency relationship with a core domain component, a dependency edge is established pointing from the application service to the core domain component, where the core domain component is a domain service, entity class, or domain specification; for a domain service that depends on a domain entity or domain specification, a dependency edge is established pointing from the domain service to the domain entity or the domain specification; for a member method of a domain entity that depends on a domain specification, a dependency edge is established pointing from the domain entity to the domain specification; for other types of nodes that depend on domain concept classes, a dependency edge is established pointing from other types of nodes to the domain concept class; each dependency edge contains a dependency list; for a dependency edge with a member method dependency, the dependency list of the dependency edge contains the correspondence between the dependent member method and the member method of the depended domain concept class.

[0103] It should also be noted that, in addition to the aforementioned dependency edges, combination edges, triggering edges, and response edges, the domain graph of this invention also includes generalization edges, such as... Figure 3 As shown. The method for establishing generalized edges is existing technology. This embodiment directly establishes generalized edges between subclasses and parent classes, or between subclasses and interfaces, based on Java's implements / extends relationship.

[0104] S4. Utilize the topological structure of the domain graph to retrieve the domain knowledge required for the task acceptance criteria as candidate contexts, and have the large language model select the most relevant contexts from the candidate contexts; traverse each application service, submit the selected contexts and general language vocabulary to the large language model, and generate a three-stage task acceptance criterion.

[0105] It should be noted that in S4, such as Figure 4 As shown, the candidate context includes a business rule description and an acceptance criterion context. The method for retrieving the business rule description and acceptance criterion context is as follows:

[0106] S41. Starting from the member methods of each class identified as containing business rules, perform an n-hop traversal along the dependency edges of the domain graph, and take all nodes that can be reached by at most n dependency edges as candidate nodes, and obtain the domain concept class and functional summary corresponding to the candidate nodes as the business rule context; n is the preset maximum number of dependency edges to traverse.

[0107] In this embodiment S41, to prevent context explosion of the large language model, when there are too many business rule contexts, domain services / application services are selected first, and the relevance scores between the classes containing business rules and the domain concept classes corresponding to these candidate nodes are calculated. The top-10 business rule contexts with the highest relevance scores are selected.

[0108] S42. Submit the code snippets, business rule context, and general language vocabulary of the business rules obtained from the Java source files to the large language model to generate a business rule description containing the code snippets.

[0109] In this embodiment S42, when generating business rule descriptions, the tasks of the large language model include: extracting core business rules from the above code snippets and ignoring technical details; mapping variables and classes in the code snippets to concepts in the general language vocabulary, prioritizing the use of standard names in the general language vocabulary; labeling rule types, such as preconditions, state constraints, business decisions, calculation rules, qualification judgments, etc.; outputting confidence scores, and triggering manual review when the confidence score is lower than the threshold.

[0110] S43. For each application service, first start from each domain concept class belonging to the application service, traverse along the dependency edges to obtain the aggregate root, the method code snippet of the domain service, and the business rule code snippet of the domain specification; then start from the obtained aggregate root, traverse along the composition edge to obtain the code snippet corresponding to the member variable definition of the entity class and value object; then start from the application service and the obtained aggregate root, traverse along the trigger edge or response edge to obtain the domain event code snippet; use all the obtained code snippets as task acceptance criteria to generate the required acceptance criterion context.

[0111] In this embodiment S43, the traversal depth of dependent edges is 1-hop, and the traversal depth of combined edges is the traversal to the leaf node.

[0112] It should be noted that in S4, since the candidate contexts may exceed the context limitations of the large language model, these candidate contexts need to be filtered. In this embodiment, the above business rule description includes code snippets, and the acceptance criterion context is composed of code snippets. Therefore, this embodiment uses the large language model to score the code snippets retrieved in the previous step, and the large language model uses the score to filter out the code snippets that are most helpful in generating the task acceptance criteria for a certain application service, and uses these as the filtered context.

[0113] When a large language model scores code snippets, the scoring points include:

[0114] 1. Rule relevance: Does it include business rules and business decision-making logic?

[0115] 2. State change information: Does the source code contain information on changes to state fields, lifecycle changes, or updates to key member variables of a certain entity class?

[0116] 3. Precondition information: Does the source code contain condition check logic or status check logic that a certain member method of the application service depends on?

[0117] 4. Side effect information: whether it triggers or responds to domain events, initiates external requests, updates the database, or has other external impacts.

[0118] 5. The strength of association with the target application service, whether it is directly called, whether it belongs to the same aggregate as the dependent domain entity, and whether it is a domain concept class that the application service depends on.

[0119] It should be noted that in S4, when the large language model generates the Given / When / Then three-stage task acceptance criteria, the rules must specify that the generated task acceptance criteria cover scenarios including: the main success path in the business scenario, paths explicitly checked in the source code such as unmet preconditions, invalid states, and failures of key business rules. The principles for generating task acceptance criteria include: each acceptance criterion must be an independently verifiable business assertion; Given only contains necessary preconditions and uses natural language to describe the business states; When corresponds to the behavior triggered by the application service and the triggering object, and is described using natural language; Then must include state changes, business results, or side effects; all terms must come from a general language vocabulary; and technical details such as null, DTO, repository, and exception should not appear. Each generated task acceptance criterion corresponds to its application service Java source file, and the source information of the associated business rules (such as Java source file, method name, and line number) is recorded.

[0120] To better demonstrate the specific implementation and technical effects of the present invention, the method for automatically generating task acceptance criteria based on domain graph enhancement retrieval shown in steps S1 to S4 of the above preferred implementation is applied to a specific example.

[0121] Example

[0122] The specific implementation process of the task acceptance criterion automatic generation method based on domain graph enhancement retrieval used in this embodiment is as described above and will not be repeated here.

[0123] This embodiment selects five domain-driven design (DDD) projects from within a financial enterprise as experimental subjects. Based on whether the main functions of the projects are strongly related to the business, they are divided into two categories: general-purpose projects unrelated to the business (e.g., login, access control), and business-related projects (e.g., payment, credit approval, risk control). To demonstrate the differences in the effectiveness of this embodiment in different scenarios, statistics are collected separately for each of these two categories.

[0124] Table 2 lists the basic scale information of the five evaluation items. Among them, the aggregate root and application services, as important intermediate results affecting the generation of acceptance criteria, are of reasonable quantity and unlikely to be ambiguous; therefore, they are annotated in this embodiment to measure the accuracy of the map construction. All items are based on existing acceptance criterion documents and manual annotations as the Ground Truth.

[0125] Table 2. Basic Scale Information of the Evaluation Project

[0126] The reason this embodiment specifically selects application services and aggregate roots as the two core concepts for precise evaluation is that application services carry the main business process orchestration logic, while aggregate roots determine the boundary division of the domain model. Both play a major role in the quality of subsequent acceptance criterion generation. Recall and precision are calculated based on manual annotation. Table 3 shows the recognition precision and recall of aggregate roots and application services in general and business scenarios, respectively.

[0127] Table 3. Experimental Results of the Evaluation Project

[0128] This embodiment generates 1719 Given / When / Then format acceptance criteria for all application services across 5 projects. The effectiveness of the generated acceptance criteria is evaluated from two perspectives. First, coverage: This embodiment uses existing project acceptance criteria as the ground truth and compares them with the closest generated criteria, scoring each criterion based on three dimensions: Given condition coverage, When behavior consistency, and Then result coverage. Second, accuracy: The correct operational state of the project should not contradict the acceptance criteria; in other words, the behavior described by an acceptance criterion should be permissible by the system.

[0129] Regarding the assessment method for coverage, this embodiment first groups the acceptance criteria in Ground Truth and the generated acceptance criteria by application service. For any acceptance criterion in Ground Truth, the evaluator will browse all generated acceptance criteria under the application service to which that acceptance criterion belongs and select the most similar generated acceptance criterion. For the matching acceptance criteria, each dimension is scored according to the standards listed in Table 4. The score for a single criterion is (Given + When + Then) / 3. The average score for the application service is the average of the scores for all single criteria, and the overall score for all services is the average of the average scores for each service. Table 5 lists the generated acceptance criteria and compares them with the evaluation results of Ground Truth.

[0130] Table 4. Acceptance Criteria Scoring Sheet

[0131] Table 5. Evaluation Results of Acceptance Criteria

[0132] The following is an example of an application service called "User Login" to demonstrate the acceptance criteria generated in this embodiment:

[0133] Guideline 1 (Main Success Path):

[0134] Given that the user account status is "normal" and the user has provided a valid username and password.

[0135] When a user initiates a login request

[0136] The system then issues an access token, updates the last login time, and returns a login success message.

[0137] Guideline 2 (Business Rule Failure - Account Lockout):

[0138] Given that a user account is in "normal" status, and the account has failed to log in 3 times in the last 5 minutes.

[0139] When the user initiates a login request again

[0140] The system then refuses login, changes the account status to "locked," and records the lockout time.

[0141] The terms used in the above guidelines are all derived from a general language lexicon. Therefore, this invention can automatically construct a domain semantic graph and generate acceptance criteria from domain-driven project code even in the absence of original requirements documents. It achieved 80.13% coverage and 97.61% accuracy in general-purpose projects, and 72.68% coverage and 90.23% accuracy in business-purpose projects, verifying the feasibility of the proposed technical solution.

[0142] It is understood that the automatic generation method for task acceptance criteria based on domain graph enhancement retrieval described in S1-S4 above can essentially be implemented by a computer program. Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer program product corresponding to the automatic generation method for task acceptance criteria based on domain graph enhancement retrieval provided in the above embodiments. This product includes a computer program / instruction, which, when executed by a processor, can implement the automatic generation method for task acceptance criteria based on domain graph enhancement retrieval as described in the above embodiments.

[0143] Similarly, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer electronic device corresponding to the automatic generation method for task acceptance criteria based on domain map enhancement retrieval provided in the above embodiments, such as... Figure 5 As shown, it includes a memory and a processor;

[0144] The memory is used to store computer programs;

[0145] The processor is configured to, when executing the computer program, implement the method for automatically generating task acceptance criteria based on domain graph enhancement retrieval in the above embodiments.

[0146] Furthermore, the logical instructions in the aforementioned memory can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0147] Therefore, based on the same inventive concept, another preferred embodiment of the present invention also provides a computer-readable storage medium corresponding to the automatic generation method for task acceptance criteria based on enhanced domain graph retrieval provided in the above embodiments. The storage medium stores a computer program, which, when executed by a processor, can realize the automatic generation method for task acceptance criteria based on enhanced domain graph retrieval in the above embodiments.

[0148] Specifically, in the computer-readable storage medium of the above three embodiments, the stored computer program is executed by a processor, which can perform the aforementioned steps S1 to S4.

[0149] It is understood that the aforementioned storage media may include random access memory (RAM) or non-volatile memory (NVM), such as at least one disk storage device. Furthermore, the storage media may also be various media capable of storing program code, such as USB flash drives, external hard drives, magnetic disks, or optical discs.

[0150] It is understood that the processors mentioned above can be general-purpose processors, including central processing units (CPUs), network processors (NPs), etc.; they can also be digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, or discrete hardware components.

[0151] The embodiments described above are merely preferred embodiments of the present invention and are not intended to limit the invention. Those skilled in the art can make various changes and modifications without departing from the spirit and scope of the invention. Therefore, all technical solutions obtained through equivalent substitution or transformation fall within the protection scope of the present invention.

Claims

1. A method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval, characterized in that, Includes the following steps: S1. Perform static parsing and semantic analysis on each Java source file in the project source code, extract structured information for domain concept identification and domain graph construction, determine the level of the Java source file in the domain-driven design architecture, and submit the project directory tree and project source code to the large language model to generate a functional summary of each Java source file. S2. Determine the level of the bounded context based on the package hierarchy, and then determine the bounded context to which each class belongs; Classes belonging to a certain domain concept are taken as domain concept classes. The relevant context of the domain concept class is obtained through the domain concept class context filtering algorithm. The class name, member method signature, bounded context, and relevant context of each domain concept class are submitted to the large language model to generate a general language vocabulary composed of multiple concepts. S3. By integrating static program analysis and semantic reasoning of large language models, a domain graph reflecting the deep relationship of business logic is constructed for each bounded context. The nodes in the domain graph are all concepts imported from the general language vocabulary, and the directed edges in the domain graph include dependency edges, composition edges, trigger edges, and response edges. S4. Utilize the topological structure of the domain graph to retrieve the required domain knowledge as candidate contexts based on the task acceptance criteria, and then use the large language model to select the most relevant contexts from the candidate contexts. Iterate through each application service, submit the selected context and general language vocabulary to the large language model, and generate a three-stage task acceptance criterion.

2. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 1, characterized in that, In S1, the Java source code parser is used to traverse each Java source file in the project source code and extract the structured information in the Java source file, including file path, package name, class name, annotation, member variables, member method signature and dependency relationship; The process of determining the layer of a Java source file is as follows: The content of the Java source file is submitted to the large language model. The large language model determines whether the Java source file belongs to the presentation layer, application layer, domain layer, or infrastructure layer based on the package path and directory structure, the responsibilities of the class in the software engineering project, the dependencies, whether it contains framework-related code, whether it contains domain models, domain services, or business rules, and marks it accordingly.

3. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 2, characterized in that, In S1, for Java source files in the domain layer, the large language model determines the domain category of the unique public class in the Java source file based on the class name, annotations, member variables, member method signatures, and the class's responsibilities in the software engineering project. Domain categories include entity classes, value objects, domain services, domain events, domain abstractions, domain specifications, and others. At the same time, the functional summary of the Java source file and the code snippets of the member methods in the class are submitted to the large language model. The large language model outputs the judgment result of whether the Java source file contains business rules. If the Java source file contains business rules, it outputs the business rule type. Business rules include state constraints, condition judgments, business decision logic, and cross-object business logic. For Java source files in the application layer, the large language model outputs a classification result based on the class's responsibilities, member method signatures, and dependencies in the software engineering project, determining whether the unique public class in the Java source file is an application service.

4. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 3, characterized in that, In S2, the bounded context level is determined as follows: Through static analysis, all package nodes at level i in the package hierarchy are traversed. If there are cross-context dependencies between the sub-packages of each package node at level i, then all package nodes at level i-1 in the package hierarchy are traversed to gradually narrow down the range of the bounded context levels until a certain level is reached where there are no cross-context dependencies between the sub-packages of each package node. The current package level is then taken as the bounded context level, and all package nodes at this level are considered a bounded context; i is the package level index. The bounded context of each class is determined by the following method: package nodes identified as bounded contexts are taken as candidate packages, the functional summary of the candidate packages is submitted to the large language model, the large language model judges the semantic boundaries between package nodes based on domain-driven design principles, identifies bounded contexts from the perspective of business semantics, and outputs the name and definition of the bounded context. Then, based on the relationship between the class and the candidate package, the bounded context to which each class belongs is determined.

5. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 4, characterized in that, In S2, the relevant context of a domain concept class is obtained through a domain concept class context filtering algorithm as follows: For any domain concept class, the top-K other domain concept classes with the highest comprehensive scores are selected from all other domain concept classes that depend on this domain concept class as relevant contexts; the comprehensive score is a weighted sum of the functional relevance score and the dependency relevance score; the functional relevance score is the score output by the large language model after evaluating the relevance of this domain concept class and other domain concept classes in terms of functional responsibilities; the dependency relevance score is a weighted sum of the category score, the distance score, and the citation score; the category score is the score set for other domain concept classes of a certain category according to expert experience; the distance score is negatively correlated with the directory distance between this domain concept class and other domain concept classes; the citation score is used to quantify the activity of this domain concept class being cited by other domain concept classes, and the citation score is positively correlated with the number of citations.

6. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 5, characterized in that, In S3, node types include entity classes, domain services, application services, domain events, domain abstractions, domain specifications, and others; node attributes include specification name, concept definition, class name in code mapping, domain concept, member variables belonging to value objects, the result of the judgment that a certain entity class is the aggregate root, and the aggregate to which it belongs; The following method is used to determine whether an entity class is a aggregate root: First, obtain the list of all member entity classes, the list of application services or domain services that depend on the entity class, and the signatures of the member methods contained in the entity class as the context information of the entity class through static analysis. Submit the context information to the large language model, and the large language model outputs the judgment result of whether the entity class is an aggregate root.

7. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 6, characterized in that, In S3, after determining the aggregate root, a composite edge is established between an entity class that is an aggregate root and another entity class that is not an aggregate root. In the domain graph after the composite edge is established, starting from the entity class that is not an aggregate root, or the domain abstraction or value object, the nearest aggregate root is searched along the composite edge towards the parent node: if only one aggregate root is reachable, the entity class is assigned to the aggregate corresponding to that aggregate root; if multiple aggregate roots are reachable, the entity class is assigned to the aggregate corresponding to a randomly selected aggregate root. If no aggregate root is reachable, the user shall provide the aggregate partitioning result for that entity class.

8. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 7, characterized in that, In S3, the methods for establishing trigger edges and response edges are as follows: Static analysis is used to identify all aggregate roots, domain services, and application services that have dependencies on a specific domain event, and source code snippets at the dependencies are extracted. The class belonging to that domain event is designated as the domain event class, and the domain event class name and source code snippet are submitted to the large language model. If the large language model determines that the dependency is a trigger relationship, a trigger edge is established pointing from the aggregate root, domain service, and application service to the domain event. If the large language model determines that the dependency is a response relationship, a response edge is established pointing from the domain event to the aggregate root, domain service, and application service.

9. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 8, characterized in that, In S3, dependency edges are established as follows: If a member method of an application service has a dependency relationship with a core domain component, a dependency edge is established pointing from the application service to the core domain component, where the core domain component is a domain service, entity class, or domain specification; for a domain service that depends on a domain entity or domain specification, a dependency edge is established pointing from the domain service to the domain entity or the domain specification; for a member method of a domain entity that depends on a domain specification, a dependency edge is established pointing from the domain entity to the domain specification; for other types of nodes that depend on domain concept classes, a dependency edge is established pointing from other types of nodes to the domain concept class; each dependency edge contains a dependency list; for a dependency edge with a member method dependency, the dependency list of the dependency edge contains the correspondence between the dependent member method and the member method of the depended domain concept class.

10. The method for automatically generating task acceptance criteria based on domain graph-enhanced retrieval as described in claim 9, characterized in that, In S4, the candidate context includes a business rule description and an acceptance criterion context. The method for retrieving the business rule description and acceptance criterion context is as follows: S41. Starting from the member methods of each class identified as containing business rules, perform an n-hop traversal along the dependency edges of the domain graph, and take all nodes that can be reached by at most n dependency edges as candidate nodes, and obtain the domain concept class and functional summary corresponding to the candidate nodes as the business rule context; n is the preset maximum number of dependency edges to traverse. S42. Submit the code snippets, business rule context, and general language vocabulary of the business rules obtained from the Java source files to the large language model to generate a business rule description containing the code snippets; S43. For each application service, first start from each domain concept class belonging to the application service, traverse along the dependency edges to obtain the aggregate root, the method code snippet of the domain service, and the business rule code snippet of the domain specification; then start from the obtained aggregate root, traverse along the composition edge to obtain the code snippet corresponding to the member variable definition of the entity class and value object; then start from the application service and the obtained aggregate root, traverse along the trigger edge or response edge to obtain the domain event code snippet; use all the obtained code snippets as task acceptance criteria to generate the required acceptance criterion context.

Images