Knowledge-driven multi-agent system for automatic software architecture design

Abstract

The invention discloses a multi-agent system for knowledge-driven automatic software architecture design, and belongs to the technical field of computer aided design, and the multi-agent system comprises an analysis agent, a modeling agent, a design agent and an evaluation agent which are constructed based on a large language model, the analysis agent is used for extracting, screening and classifying requirements which influence the software architecture design from a software requirement specification and generating a requirement document; the modeling agent is used for generating a software architecture view according to a demand document and an external knowledge base; the design agent is used for generating a software architecture document according to the demand document and the software architecture view; and the evaluation agent is used for evaluating and analyzing the software architecture according to the demand document, the software architecture view and the software architecture document to generate an evaluation and analysis report. According to the method, through cooperation and interaction between the intelligent agents and prompt of external knowledge, the reliability, practicability and creativity of software architecture design can be effectively enhanced.

Description

Technical Field

[0001] This invention relates to the field of computer-aided design technology, and in particular to a knowledge-driven multi-agent system for automated software architecture design. Background Technology

[0002] Software architecture plays a crucial role in software development, serving as the foundation for ensuring system scalability, maintainability, and consistency with the business objectives defined in the Software Requirements Specifications (SRS). However, traditional architecture design processes rely excessively on human expertise, often proving time-consuming and prone to inconsistencies in design decisions. Therefore, automated architecture design is essential for achieving efficient end-to-end application-level software development, significantly improving development efficiency and reducing inconsistencies and errors caused by human intervention. The emergence of Large Language Models (LLMs) offers a new direction for automated architecture design. While existing technologies have attempted to apply LLMs to automated architecture design, these studies primarily rely on zero-shot hint strategies, which often lead to inaccurate or false content generated by the LLMs, thus affecting the reliability and usability of the architecture design results. Summary of the Invention

[0003] The purpose of this invention is to overcome the shortcomings of the prior art and provide a knowledge-driven automated software architecture design multi-agent system to solve the technical problems of time-consuming and labor-intensive manual software architecture design and poor accuracy when using large language models.

[0004] To achieve the above objectives, the present invention is implemented using the following technical solution: This invention provides a knowledge-driven multi-agent system for automated software architecture design, including an analytical agent, a modeling agent, and a design agent built based on a large language model. The analytical agent is used to extract, filter, and classify requirements that affect the software architecture design from the software requirements specification and generate a requirements document. The modeling agent is used to generate a software architecture view based on the requirements document and an external knowledge base. The design agent is used to generate a software architecture document based on the requirements document and the software architecture view.

[0005] Optionally, the requirements document includes an architecture requirements document, a functional requirements document, a non-functional requirements document, and a constraint requirements document; Architecture requirements are requirements that directly affect software architecture design. The architecture requirements document includes the original text of the architecture requirements, the relevant quality attribute text, and the architecture impact text. Functional requirements are the functional requirements that the software architecture should implement. The functional requirements document includes the original text of the functional requirements and the text of the subtasks. Non-functional requirements are the requirements for the software architecture's performance and environmental adaptability. The non-functional requirements document includes the original text of the non-functional requirements, the relevant quality attribute text, and the architectural impact text. Constraint requirements are the restrictions that a software architecture must follow during the design and implementation phases. The constraint requirement document includes the original text of the constraint requirements, the constraint type text, and the architecture impact text.

[0006] Optionally, the software architecture view includes a scenario view, a logical view, a development view, a process view, and a physical view; The scenario view includes use case diagrams, which are used to illustrate the functional requirements of the software architecture and user interaction methods; The logical view includes class diagrams, object diagrams, and state diagrams, which are used to show the internal structure of the software architecture and the relationships between objects. The development view includes package diagrams and component diagrams, which are used to show how the software architecture is organized at the code level; The process view includes activity diagrams, sequence diagrams, and collaboration diagrams, which are used to illustrate how the software architecture handles tasks, performs operations, and responds to events. The physical view includes deployment diagrams and container diagrams, which are used to show how the software architecture is deployed and runs on hardware nodes.

[0007] Optionally, the software architecture document includes: Objective definition, detailed architecture design, component and connector specifications, key technologies, design decisions, design decision principles, and executable scaffolding prototype; The target definition includes defining the software architecture objectives based on requirements; Therefore, the detailed architecture design includes component division, interface design, data volume and control flow. The component division is used to clarify the responsibilities and functions of each module, the interface design is used to describe the interfaces and communication methods between modules, and the data flow and control flow are used to describe the flow of data and control logic. The component and connector specifications include communication protocols, data formats, error handling, and performance requirements. The communication protocol defines the data exchange protocol between modules, the data format is used to specify the format for data transmission between modules, the error handling is used to clarify the error handling mechanism, and the performance requirements are used to set performance targets for each module. The key technologies include infrastructure configuration, technology stack selection, and fault-tolerant design. Infrastructure configuration describes the allocation of computing and storage resources, technology stack selection is used to choose appropriate technology frameworks and tools based on requirements, and fault-tolerant design is used to select appropriate fault recovery technologies when a fault occurs. Therefore, design decisions include architectural patterns, technology selection, and the context of the decision. The design decision principles include the advantages and disadvantages of technology selection, the rationality of architectural pattern selection, and requirement response; The executable scaffolding prototype includes model code, interface definitions, and data flow implementation. The model code generates a preliminary code framework for the core modules, the interface definitions generate code definitions for the interaction between modules, and the data flow implementation is the preliminary data flow implementation code for the software framework.

[0008] Optionally, the multi-agent system further includes an evaluation agent, which is used to evaluate and analyze the software architecture based on the requirements document, the software architecture view, and the software architecture document to generate an evaluation and analysis report.

[0009] Optionally, the evaluation and analysis report includes a mismatch analysis report and an architecture evaluation report; The mismatch analysis report includes a description of the mismatch, an impact analysis, and recommendations. The mismatch description provides a brief explanation of the mismatch between the architecture and the requirements. The impact analysis analyzes the potential impact of the mismatch on the software architecture. The recommendations provide suggestions or steps to fix or mitigate the problem. The architecture assessment report is obtained by evaluating the software architecture using the ATAM method. It includes an architecture overview, a statement of business objectives, quality attribute requirements scenarios, risk and non-risk analysis, risk themes, mapping of architecture decisions to quality requirements, sensitivity points, and trade-off points.

[0010] Optionally, the role of the external knowledge base in the modeling agent is as follows: When the modeling agent receives the requirements document generated by the analysis agent, it enhances its understanding by initiating a vector search to an external knowledge base. Based on the document content, the search selects three most relevant and similar text fragments from the database and integrates these fragments into the prompts input to the modeling agent. By introducing this external knowledge, the modeling agent can adopt a broader perspective, ensuring that its generated architectural view is not only supported by the document but also incorporates additional, context-sensitive knowledge.

[0011] Optionally, the role of the external knowledge base in the design agent is as follows: Before generating software architecture documentation, the design agent performs a vector search in an external knowledge database to retrieve the three most relevant text snippets. These snippets serve as background knowledge to support the architecture design process. By referencing these external insights, the design agent can ensure that its design principles and decisions are consistent with industry standards and validated architectural patterns, thereby further improving the quality of the generated design documentation.

[0012] Compared with the prior art, the beneficial effects achieved by the present invention are as follows: This invention provides a knowledge-driven, automated software architecture design multi-agent system. Through the collaboration of four agents built on a large language model and the injection of external knowledge, software architecture design is achieved based on input requirement specifications. By leveraging the collaboration and interaction between agents and the prompts from external knowledge, the MAAD framework effectively enhances the reliability, practicality, and creativity of software architecture design, significantly reduces the risk of generating false results, and improves the overall quality of the architecture design output. Attached Figure Description

[0013] Figure 1 This is a schematic diagram of the structure of a multi-agent system for automated software architecture design provided in an embodiment of the present invention. Detailed Implementation

[0014] The present invention will be further described below with reference to the accompanying drawings. The following embodiments are only used to more clearly illustrate the technical solution of the present invention, and should not be used to limit the scope of protection of the present invention.

[0015] Example 1:

[0016] like Figure 1 As shown, this embodiment of the invention provides a knowledge-driven multi-agent system for automated software architecture design, including an analysis agent, a modeling agent, a design agent, and an evaluation agent built based on a large language model.

[0017] I. The analytical agent is used to extract, filter, and classify requirements that affect the software architecture design from the software requirements specification and generate requirements documents.

[0018] Specifically: The Analyst Agent extracts, filters, and categorizes requirements that impact the architecture design from the Software Requirements Specification (SRS). Without human intervention, the Analyst Agent can identify various software requirements and generate requirement documents, providing a precise basis for subsequent architecture design. The Analyst Agent primarily outputs the following four types of artifacts: 1. Architecture Requirements Document The analytical agent extracts and identifies Architecturally Significant Requirements (ASRs) from software requirements documents. ASRs refer to requirements that directly affect system architecture design decisions, typically involving key quality attributes such as performance, scalability, availability, fault tolerance, and security. These requirements usually require coordination across multiple components to ensure the consistency and effectiveness of the system within the overall architecture. By analyzing the requirements documents, this function can identify requirements that meet these criteria and output structured results. The output of each ASR includes: (1) Original text: The original description text of the requirement. (2) Relevant quality attributes: Quality attributes directly related to the requirement, such as performance, scalability, and reliability. (3) Architectural impact: The specific impact of the requirement on the system architecture design, such as whether a distributed architecture is needed, whether to enhance system fault tolerance, or whether to introduce high availability design.

[0019] 2. Functional Requirements Document The analysis agent extracts and summarizes functional requirements from the software requirements document. Functional requirements define the functions, tasks, and behaviors that the system should implement, and usually describe the system's business processes and user interaction methods. The main purpose of this function is to help designers quickly identify the functional requirements in the document through automated processing and organize these requirements in a structured manner according to the task hierarchy. The output includes: (1) Original text: a complete description of each functional requirement extracted from the requirements document. (2) Subtasks: the specific operations or subtasks that each functional requirement may contain.

[0020] 3. Non-functional requirements document The analytical agent extracts all non-functional requirements from the requirements document. Non-functional requirements describe the system's quality attributes, performance standards, maintainability requirements, scalability requirements, etc. Non-functional requirements are crucial for architecture design because they define the system's performance and adaptability to the environment during runtime. This function identifies and extracts all non-functional requirements through in-depth analysis of the requirements document and ensures that they are properly mapped into the system architecture. The output includes: (1) Original text: A complete description of each non-functional requirement extracted from the requirements document. (2) Relevant quality attributes: Quality attributes related to the requirement (such as performance, reliability, response time, resource usage, etc.). (3) Architectural impact: The specific impact of the requirement on the architecture, such as the possibility of requiring system performance optimization, increasing load balancing, enhancing system reliability, etc.

[0021] 4. Constraint Requirements Document The analysis function generates design constraints from the requirements specification document for intelligent agent software. Design constraints refer to the limitations that the system needs to follow during the design and implementation phases. These constraints can be technical, resource-based, or regulatory. Design constraints directly affect key decisions such as the selection of system architecture, technology stack, and deployment environment. This function helps designers automatically identify and record design constraints in the requirements document, ensuring that the architecture design complies with all external and internal requirements. The output includes: (1) Constraint description: A detailed description of each design constraint, clarifying its specific content and background. (2) Constraint type: For example, technical constraints, compliance constraints, resource constraints, etc. (3) Impact analysis: The specific impact of the constraint on the architecture design, such as limiting the selection of technology stack and affecting the decision of deployment architecture.

[0022] II. The modeling agent is used to generate software architecture views based on requirements documents and external knowledge bases.

[0023] Specifically: The modeling agent is responsible for modeling the overall architecture of the system based on the detailed requirements provided by the analysis agent. Specifically, the modeling agent automatically generates different architectural views based on the requirements document generated by the analysis agent and relevant knowledge from external knowledge bases, and uses PlantUML syntax to generate corresponding UML diagrams, achieving automated text-to-image conversion. The modeling agent outputs various architectural view artifacts in the form of UML diagrams: 1. Scene View The modeling agent generates scenario views of the software based on refined requirements. These scenario views showcase the system's functional requirements and user interaction methods, helping the team understand how the system meets user needs. Scenario views include: Use Case Diagrams: illustrating how users interact with the system, including actors, use cases, and the relationships between them. 2. Logical View The modeling agent generates a logical view of the software based on the detailed software requirements. The logical view focuses on the internal structure of the system and the relationships between objects, specifically showing elements such as classes, objects, and state machines. The logical view includes the following: (1) Class diagram: defines classes, their attributes, methods, and relationships between classes, such as inheritance, association, composition, and aggregation. (2) Object diagram: shows objects and their specific values, as well as the relationships between objects. (3) State diagram: presents the behavior of objects in different states and their state transition processes.

[0024] 3. Development View The modeling agent generates a development view of the software based on the detailed software requirements. The development view focuses on the modular structure of the system, showing how the system is organized at the code level, and helps developers understand the system components and their interdependencies. The development view includes (1) Package diagram: showing the modular structure of the system and the dependencies between packages. (2) Component diagram: showing the software components in the system and their interaction relationships.

[0025] 4. Process View The modeling agent generates a process view of the software based on the detailed software requirements. The process view emphasizes the dynamic behavior of the system during runtime, showing how the system handles tasks, performs operations, and responds to events. The process view includes (1) Activity diagrams: showing dynamic workflows or business processes. (2) Sequence diagrams: showing the temporal sequence of interactions between system components. (3) Collaboration diagrams: showing object roles and the message exchanges between them.

[0026] 5. Physical View The modeling agent generates a physical view of the software based on the detailed software requirements. The physical view shows how system components are deployed and run on hardware nodes, helping the team understand the physical architecture of the system. The physical view includes (1) Deployment diagram: showing the physical deployment of system components on hardware nodes. (2) Container diagram: showing the containers in the software architecture and their interaction methods.

[0027] 3. Design an intelligent agent to generate software architecture documents based on requirements documents and software architecture views.

[0028] Specifically: The design agent takes the architectural critical requirements (ASRs), functional requirements, non-functional requirements, design constraints, and architectural design views (output by the modeling agent) extracted by the analysis agent as input artifacts, and outputs an architecture document. Through an automated design process, the design agent proposes system architecture design decisions and generates key technical solutions, providing clear guidance for architecture implementation. The architecture document output by the design agent includes the following: 1. Goals Definition The design agent defines the main objectives of the system architecture based on the input requirements. These objectives encompass business needs, technical requirements, and user experience, ensuring that the design meets the system's expected functionality and quality standards.

[0029] 2. Detailed Architecture Design The design of the intelligent agent generates a detailed architecture design, specifically describing the system's components, modules, and their interactions. This design helps developers understand the overall structure of the system and the functions of each module, ensuring the maintainability and scalability of the system design. The detailed architecture design includes: (1) Component partitioning: Modular design of system functions, clarifying the responsibilities and functions of each module. (2) Interface design: Describing the interfaces and communication methods between modules to ensure effective collaboration between modules. (3) Data flow and control flow: Describing the flow of data and control logic in detail to ensure smooth operation of the system.

[0030] 3. Component & Connector Specifications The design of the intelligent agent details the interaction protocol between system components to ensure efficient collaboration among them. Component and connector specifications include: (1) Communication protocol: Define the data exchange protocol between system modules, such as RESTAPI, message queues, etc. (2) Data format: Specify the format of data transmitted between modules, such as JSON, XML, etc. (3) Error handling: Design an error handling mechanism to ensure the system's fault tolerance under abnormal conditions. (4) Performance requirements: Set performance targets for each component, such as response time, throughput, etc.

[0031] 4. Key Technologies The design of the intelligent agent proposes key technology selections for the system, helping the team understand the impact of technology stack selection on system performance, scalability, and fault tolerance. Key technologies include: (1) Infrastructure configuration: describing the allocation of computing and storage resources to ensure the system can operate efficiently in various environments. (2) Technology stack selection: selecting appropriate technology frameworks and tools based on requirements to ensure the technology stack can meet the system's expansion needs and performance requirements. (3) Fault-tolerant design: ensuring the system can remain stable when a fault occurs and selecting appropriate fault recovery technologies.

[0032] 5. Design Decisions Designing intelligent agents records key decisions in architecture design, including the chosen architectural pattern, technology selection, and the rationale behind those decisions. These decisions help the team understand the advantages and potential risks of the choices. Design decisions include: (1) Architectural pattern: the chosen architectural style, such as distributed architecture, microservice architecture, etc. (2) Technology selection: why a specific technology stack and tools are chosen, such as databases, programming languages, etc. (3) Decision context: the background and analysis of each decision, helping the team understand the rationale for the technology choices.

[0033] 6. Design Decision Rationale The design agent provides detailed justifications for each decision, explaining why a particular technology or architectural pattern was chosen. Design decision justifications include: (1) Advantages and disadvantages of technology selection: detailing the pros and cons of each technology choice to help the team assess its suitability. (2) Justification of architectural pattern selection: explaining how the architectural pattern meets system requirements and how it addresses specific challenges. (3) Requirement response: explaining how each design decision responds to critical architectural requirements and non-functional requirements.

[0034] 7. Executable Prototype Skeleton Design the code framework for the key modules of the intelligent agent generation system as the starting point for prototype development. The scaffolding code includes: (1) Module code: Generate a preliminary code framework for the core functional modules of the system. (2) Interface definition: Generate code definitions for the interaction between modules to help developers understand the communication methods between modules. (3) Data flow implementation: Generate preliminary data flow implementation code for the system based on the design document to ensure the correctness of data transmission.

[0035] IV. The evaluation agent is used to evaluate and analyze the software architecture based on the requirements document, software architecture view, and software architecture document, and generate an evaluation and analysis report.

[0036] Specifically: The evaluation agent conducts a detailed assessment and analysis of the system architecture to ensure that the architecture design meets all project requirements and identifies potential risks or areas for improvement. The evaluation agent takes the original requirements document, architecture view (generated by the modeling agent), and architecture document (generated by the design agent) as input. Based on the ATAM architecture quality assessment methodology (which uses thought chains to form prompts for the evaluation agent), it performs a comprehensive analysis of the architecture, helping the team understand the relationship between architectural decisions and quality attributes, and identify potential defects or optimization opportunities. The evaluation agent will output the following two types of evaluation reports: 1. Mismatch Analysis Report The assessment agent can identify any mismatches, discrepancies, or omissions between requirements and architectural design based on requirements documents and architectural views. Each mismatch is described in detail, its potential impact, and recommendations for resolution or mitigation. This report helps the team identify potential flaws in the architecture and provide targeted improvements. The report includes the following: (1) Mismatch description: A brief description of the mismatch between the architecture and requirements. (2) Impact analysis: An analysis of the potential impact of the mismatch on the system. (3) Recommendations: Recommendations or steps to fix or mitigate the problem.

[0037] 2. Architecture Evaluation Report The evaluation agent assesses the architecture using the ATAM (Architecture Tradeoff Analysis Method). By analyzing the architecture design, the evaluation agent helps the team understand how architectural decisions affect quality attributes (such as performance, scalability, security, etc.), identify risky and non-risky decisions, and provide solutions to ensure that the architecture meets project objectives. The report includes the following: (1) Architecture Overview: A concise and clear presentation of the architecture, usually easy to understand. (2) Statement of Business Objectives: Clarifying how the architecture supports or affects the achievement of business objectives. (3) Quality Attribute Requirement Scenarios: Quality attribute requirements based on priority, used to evaluate the architecture. (4) Risk and Non-Risk Analysis: Identifying decisions that may affect the architecture's quality attributes and assessing their potential risks. (5) Risk Themes: Analyzing the identified risks and summarizing the main issues or trends that may affect the architecture. (6) Mapping of Architectural Decisions to Quality Requirements: Describing how architectural decisions support or hinder the achievement of quality attribute requirements. (7) Sensitivity Points and Trade-offs: Identifying architectural decisions that have a significant impact on the response to quality attributes, and the trade-offs involved in quality attributes.

[0038] In this implementation, an agent-driven configuration based on an external knowledge base is introduced. External knowledge injection is the core mechanism for improving the agent performance of the MAAD framework. The complexity of the software architecture necessitates knowledge injection. During the architecture design process, the agent not only needs requirement documents but also needs to integrate multi-domain knowledge bases to construct a cross-source knowledge graph for scientific decision-making. This knowledge fusion mechanism gives the technical documents generated by the agent the following advantages: accurate context adaptability, strict specification compliance, and deep professional representation for specific domains, ultimately forming a systematic solution that conforms to the laws of architecture evolution. In the MAAD framework, the design agent and the evaluation agent guide their document generation process through the injection of external knowledge. The specific knowledge injection process is as follows: Modeling Agent: Upon receiving a document generated by the analysis agent, the modeling agent enhances its understanding by initiating a vector search of an external knowledge base. This search selects three most relevant and similar text snippets from the database based on the document content and integrates these snippets into the prompts input to the modeling agent. By incorporating this external knowledge, the modeling agent can adopt a broader perspective, ensuring that its generated architectural views are not only supported by the document but also incorporate additional, context-sensitive knowledge.

[0039] The design agent, similarly, performs a vector search on the same external knowledge database before generating the architecture document, retrieving the three most relevant text snippets. These snippets serve as background knowledge, supporting the architecture design process. By referencing these external insights, the design agent ensures that its design principles and decisions align with industry standards and validated architectural patterns, further improving the quality of the generated design document.

[0040] In summary, this invention proposes a knowledge-driven automated software architecture design multi-agent system (MAAD framework). Through the cooperation of four agents within the framework, the automation of software architecture design is fully realized. The protection point of this invention lies in the proposed software architecture design method based on multi-agent collaboration. Specifically, the complete process of a multi-agent collaborative automatic architecture design method is as follows: (1) In the MAAD framework, the architecture design process begins with the analysis agent. The agent first analyzes the input Software Requirements Specification (SRS) and extracts key requirements (functional requirements, non-functional requirements, and important architectural requirements) and constraints, providing a foundation and guidance for subsequent design.

[0041] (2) Based on the output of the analytical agent, the modeling agent is responsible for two core tasks: 1) Design the “4+1” architecture view of the software architecture design according to the parsed requirements and constraints, including several UML diagram models (such as class diagrams, sequence diagrams and deployment diagrams); 2) Formulate high-level architecture decisions (generate architecture decision documents) to establish a clear direction for system design.

[0042] (3) Based on this, design an intelligent agent generation architecture, record the architecture design content in an architecture design document, and use it as a blueprint for subsequent code development to ensure the executability of the architecture design.

[0043] (4) Finally, the evaluation agent assesses the quality of the generated architecture design based on the original requirements document and the artifacts previously generated by the agent, and identifies and resolves any potential mismatches. The final result is an architecture quality assessment report based on the ATAM architecture evaluation method, and an architecture mismatch analysis report.

[0044] The MAAD framework supports the injection of external knowledge to assist in software architecture design. This external knowledge can come from existing software project documentation, authoritative publications, ISO international standards, and architecture experts. This external knowledge text is vectorized and stored in a vector database, serving as the input context to provide external knowledge support for the modeling and design agents. Sources of external knowledge include: (1) Knowledge from existing architectural designs: First, a comprehensive dataset of open-source or publicly available projects from various fields is collected, from which architectural designs are extracted. An architectural recovery tool is used to extract the architectural design of each selected project, and static or dynamic analysis tools are combined to evaluate the project's quality attributes, such as performance, scalability, and maintainability. By correlating the recovered architecture with quality metrics, valuable knowledge about the impact of architectural design is obtained. This knowledge is applied to tasks such as design trade-offs, resource allocation, and quality attribute optimization.

[0045] (2) Knowledge from authoritative literature: A wealth of knowledge was extracted through the analysis of textbooks, academic papers, and industry standards focusing on architectural principles, patterns, and frameworks. Furthermore, these documents provide frameworks on risk mitigation, modularization, and evaluation, which have been distilled into actionable guidelines. Generalized methodologies for designing and evaluating architectures, such as the ISO / IEC 42010 standard, were externally retrieved and adapted to improve the quality of agent output artifacts, particularly in the description of architectural styles and patterns, trade-off analysis, and applicability in different scenarios. In addition, agent design utilized guidelines for modular design, design principles, and standards for interface design and communication modeling.

[0046] (3) Knowledge from architecture experts: Professional insights into the architecture field were gained through interviews, workshops, and questionnaires with experienced architecture experts. Experts conducted in-depth discussions on specific architectural challenges, development trends, and best practices from practical experience. This process effectively captured tacit knowledge and practical trade-offs that are difficult to obtain from literature and project data. Expert insights further enhanced the capabilities of intelligent agents, especially in adapting architectural styles and patterns to specific scenarios, module design, interface design, and resource optimization.

[0047] The specific implementation process of this invention is as follows: I. Implementation of Intelligent Agents The MAAD framework comprises four agents: an analysis agent, a modeling agent, a design agent, and an evaluation agent. Specifically, this invention designs more complex and functionally complete agents based on the MetaGPT framework. MetaGPT is a framework designed based on Large Language Models (LLMs) to enhance the collaboration and self-optimization capabilities among different AI agents. Its main goal is to achieve more flexible and intelligent automated tasks through the collaborative work of multiple intelligent agents. In the MAAD framework designed in this invention, four internal agents are developed using MetaGPT, decomposing the task of automated software modeling and distributing it to multiple agents for processing. MetaGPT's internal mechanisms enable agents developed based on it to handle more complex tasks and coordinate between different agents.

[0048] The agents in the MAAD framework require the support of a large language model. This invention chooses the domestically developed open-source large language model DeepSeek-R1 for implementation. DeepSeek-R1 inherits advanced AI architecture, demonstrating significant improvements in processing power and inference efficiency, especially in large-scale data processing and multi-task processing, where it offers extremely high cost-effectiveness. Furthermore, DeepSeek-R1 is completely open-source, promoting the popularization and transparency of AI technology, allowing developers and enterprises to customize and optimize it according to actual needs, offering flexibility and scalability. Therefore, we chose the DeepSeek-R1 model as the large language model supporting the MAAD framework. Secondly, the MAAD framework can also load other large language models to achieve flexible custom configurations, such as GPT-4o and Llama 3.3.

[0049] II. Building and Using External Knowledge Bases Both modeling and designing intelligent agents require external knowledge indexes for context. The MAAD framework employs three different sources of external knowledge: knowledge from existing architectural designs, knowledge from authoritative literature, and knowledge from architectural experts. This knowledge, after manual collection and filtering, is directly read from documents (such as PDF files) and stored in a vector database for convenient subsequent knowledge retrieval. This invention uses the LanceDB vector database to construct the external knowledge base. LanceDB is an open-source serverless vector database developed based on Rust and built on the Lance columnar data format. Designed specifically for artificial intelligence applications, it efficiently stores and manages multimodal data (such as text, images, and audio) and provides high-performance random access and query capabilities. In this invention, external knowledge text is first vectorized and written into LanceDB. During agent modeling or runtime, vector similarity retrieval extracts the three most relevant knowledge fragments to the current problem from the database, which are then used as context input to the intelligent agent. This ensures the accuracy of knowledge retrieval and improves the overall efficiency of the system.

[0050] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0051] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0052] These computer program instructions may also be stored in a computer readable memory that can direct a computer or other programmable data processing device to work in a specific manner, so that the instructions stored in the computer readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0053] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operational steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing the instructions executed on the computer or other programmable device for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 A step that specifies a function in one or more boxes.

[0054] The above description is only a preferred embodiment of the present invention. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the technical principles of the present invention, and these improvements and modifications should also be considered within the scope of protection of the present invention.

Claims

1. A multi-agent system for knowledge-driven automated software architecture design, characterized in that, This includes analytical agents, modeling agents, and design agents built upon large language models; The analytical agent is used to extract, filter, and classify requirements that affect the software architecture design from the software requirements specification and generate a requirements document. The modeling agent is used to generate a software architecture view based on the requirements document and an external knowledge base. The design agent is used to generate a software architecture document based on the requirements document and the software architecture view.

2. The multi-agent system for knowledge-driven automated software architecture design according to claim 1, characterized in that, The requirements documents include architectural requirements documents, functional requirements documents, non-functional requirements documents, and constraint requirements documents. Architecture requirements are requirements that directly affect software architecture design. The architecture requirements document includes the original text of the architecture requirements, the relevant quality attribute text, and the architecture impact text. Functional requirements are the functional requirements that the software architecture should implement. The functional requirements document includes the original text of the functional requirements and the text of the subtasks. Non-functional requirements are the requirements for the software architecture's performance and environmental adaptability. The non-functional requirements document includes the original text of the non-functional requirements, the relevant quality attribute text, and the architectural impact text. Constraint requirements are the restrictions that a software architecture must follow during the design and implementation phases. The constraint requirement document includes the original text of the constraint requirements, the constraint type text, and the architecture impact text.

3. The multi-agent system for knowledge-driven automated software architecture design according to claim 1, characterized in that, The software architecture view includes a scenario view, a logical view, a development view, a process view, and a physical view; The scenario view includes use case diagrams, which are used to illustrate the functional requirements of the software architecture and user interaction methods; The logical view includes class diagrams, object diagrams, and state diagrams, which are used to show the internal structure of the software architecture and the relationships between objects. The development view includes package diagrams and component diagrams, which are used to show how the software architecture is organized at the code level; The process view includes activity diagrams, sequence diagrams, and collaboration diagrams, which are used to illustrate how the software architecture handles tasks, performs operations, and responds to events. The physical view includes deployment diagrams and container diagrams, which are used to show how the software architecture is deployed and runs on hardware nodes.

4. The multi-agent architecture for knowledge-driven automated software architecture design according to claim 1, characterized in that, The software architecture document includes: Objective definition, detailed architecture design, component and connector specifications, key technologies, design decisions, design decision principles, and executable scaffolding prototype; The target definition includes defining the software architecture objectives based on requirements; Therefore, the detailed architecture design includes component division, interface design, data volume and control flow. The component division is used to clarify the responsibilities and functions of each module, the interface design is used to describe the interfaces and communication methods between modules, and the data flow and control flow are used to describe the flow of data and control logic. The component and connector specifications include communication protocols, data formats, error handling, and performance requirements. The communication protocol defines the data exchange protocol between modules, the data format is used to specify the format for data transmission between modules, the error handling is used to clarify the error handling mechanism, and the performance requirements are used to set performance targets for each module. The key technologies include infrastructure configuration, technology stack selection, and fault-tolerant design. Infrastructure configuration describes the allocation of computing and storage resources, technology stack selection is used to choose appropriate technology frameworks and tools based on requirements, and fault-tolerant design is used to select appropriate fault recovery technologies when a fault occurs. Therefore, design decisions include architectural patterns, technology selection, and the context of the decision. The design decision principles include the advantages and disadvantages of technology selection, the rationality of architectural pattern selection, and requirement response; The executable scaffolding prototype includes model code, interface definitions, and data flow implementation. The model code generates a preliminary code framework for the core modules, the interface definitions generate code definitions for the interaction between modules, and the data flow implementation is the preliminary data flow implementation code for the software framework.

5. The multi-agent system for knowledge-driven automated software architecture design according to claim 1, characterized in that, The multi-agent system further includes an evaluation agent, which is used to evaluate and analyze the software architecture based on the requirements document, the software architecture view, and the software architecture document to generate an evaluation and analysis report.

6. The multi-agent system for knowledge-driven automated software architecture design according to claim 5, characterized in that, The assessment and analysis report includes a mismatch analysis report and an architecture assessment report; The mismatch analysis report includes a description of the mismatch, an impact analysis, and recommendations. The mismatch description provides a brief explanation of the mismatch between the architecture and the requirements. The impact analysis analyzes the potential impact of the mismatch on the software architecture. The recommendations provide suggestions or steps to fix or mitigate the problem. The architecture assessment report is obtained by evaluating the software architecture using the ATAM method. It includes an architecture overview, a statement of business objectives, quality attribute requirements scenarios, risk and non-risk analysis, risk themes, mapping of architecture decisions to quality requirements, sensitivity points, and trade-off points.

7. The multi-agent system for knowledge-driven automated software architecture design according to claim 1, characterized in that, The role of the external knowledge base in the modeling agent is as follows: When the modeling agent receives the requirements document generated by the analysis agent, it enhances its understanding by initiating a vector search to an external knowledge base. Based on the document content, the search selects three most relevant and similar text fragments from the database and integrates these fragments into the prompts input to the modeling agent. By introducing this external knowledge, the modeling agent can adopt a broader perspective, ensuring that its generated architectural view is not only supported by the document but also incorporates additional, context-sensitive knowledge.

8. The multi-agent system for knowledge-driven automated software architecture design according to claim 1, characterized in that, The role of the external knowledge base in the design agent is as follows: Before generating software architecture documentation, the design agent performs a vector search in an external knowledge database to retrieve the three most relevant text snippets. These snippets serve as background knowledge to support the architecture design process. By referencing these external insights, the design agent can ensure that its design principles and decisions are consistent with industry standards and validated architectural patterns, thereby further improving the quality of the generated design documentation.

Images