Generative architecture decoupling function and service logic method, system, equipment and medium

Abstract

The invention relates to a generative architecture decoupling function and business logic method, system, device and medium, and relates to the technical field of software development automation, the method comprises the following steps: traversing product functions of software on the market, and dividing an architecture into a basic function component, a logical relationship component and a business process for decoupling; according to a text demand input by a user or a known database field structure and a demand document, separating a generation part which can be multiplexed by the architecture and needs to be generated by a large model, and obtaining a demand list generated on the basis of the decoupled basic function component and the logic relation component; and analyzing the demand list based on a large model, and converting the demand list into a business scene corresponding to the software product of the existing functional component combination through the large model. According to the invention, effective separation of business logic and function logic can be realized.

Description

Technical Field

[0001] This application relates to the field of software development automation, and particularly to a method, system, device, and medium for decoupling generative architecture functions and business logic. Background Art

[0002] In traditional software development, business logic and functional logic are often coupled together, which increases code complexity and reduces maintainability and extensibility. To solve this problem, the present invention proposes a generative architecture based on a large model to achieve decoupling between the two.

[0003] Currently, the architecture of software development mainly relies on manual coding. Although the architecture implemented by coding achieves a partial decoupling of business logic and functional logic, it does not completely decouple functional logic and business logic. These architectures usually can only be targeted at specific general functions, such as user login and registration, etc., lacking comprehensiveness and flexibility. In addition, when the requirements change in the existing technology architecture solutions, a large number of customized modifications are often required to achieve true decoupling.

[0004] Therefore, in the prior art, problems such as long manual coding time and easy errors leading to low efficiency are prone to occur. At the same time, the code quality written by different developers varies greatly, and existing code generation tools usually can only generate code in a fixed format and cannot be customized according to specific requirements, lacking flexibility. These problems limit the enterprise from fully leveraging the advantages of decoupling in practical applications, and there is an urgent need for a more efficient decoupling solution to address the above challenges. Summary of the Invention

[0005] The first objective of this application is to provide a method for decoupling generative architecture functions and business logic to achieve effective separation of business logic and functional logic.

[0006] In a first aspect, a method for decoupling generative architecture functions and business logic provided by this application adopts the following technical solution: A method for decoupling generative architecture functions and business logic includes: Traverse the product functions of software on the market, and decouple the architecture into basic function components, logical relationship components, and business processes; According to the text requirements input by the user or the known database field structure and requirements document, separate the generative parts that can be reused through the architecture and those that need to be generated by the large model, and obtain a requirements list generated based on the decoupled basic function components and logical relationship components; Parse the requirements list based on the large model, and transform it into the business scenarios corresponding to the software products composed of existing function components through the large model.

[0007] By adopting the above technical solutions, the software architecture is reformed according to the technical ability boundary of the large model, and a compatible and transitional architecture solution is provided, which can improve the ability to accelerate the migration from the original architecture to the new architecture. At the same time, after the migration, due to the decoupling of the functional logic and the business, the efficiency and quality of developing different business logics based on the same functional logic are effectively improved, and the degree of automation is increased.

[0008] In a preferred example of the present application, it can be further configured that: the step of traversing the product functions of the software on the market and decoupling the architecture into basic function components, logical relationship components, and business processes includes: Establish a basic function component library, and based on the method of inversion of control and abstract definition, express the configuration of the basic function components through a DSL configuration file; Establish a logical relationship component library, convert it into a JSON DSL format to assemble the business flow logic.

[0009] By adopting the above technical solutions, establishing a basic function component library and expressing it through a DSL configuration file enables each basic function component to be assembled through simple configuration, reducing the workload of manual coding and improving the development efficiency; converting the logical relationship components into a JSON DSL format facilitates the flexible assembly of the business flow logic, further enhancing flexibility and adaptability, and reducing the modification cost brought about by requirement changes.

[0010] In a preferred example of the present application, it can be further configured that: the step of separating the parts that can be reused through the architecture and the parts that need to be generated by the large model according to the text requirements input by the user or the known database field structure and requirement document, and obtaining a requirement list generated based on the decoupled basic function components and logical relationship components includes: Receive the text requirements input by the user, convert the text requirements into a JSON DSL configuration. If the received requirements are non-text requirements, then process the non-text requirements through multimodality, and convert the object token into the token corresponding to the text requirements through the Qformer multimodal compatibility network structure.

[0011] By adopting the above technical solutions, different types of input data are supported, which not only improves the diversity and accuracy of requirement collection, but also ensures that various forms of requirements can be effectively parsed and utilized, thereby enhancing the adaptability and flexibility of the system, improving the efficiency and quality of requirement processing, and further enhancing the decoupling effect of business logic and functional logic.

[0012] In a preferred example, the present application can be further configured as follows: receiving the text requirements input by the user, converting the text requirements into JSON DSL configurations. If the received requirements are non-text requirements, the step of converting the non-text requirements into tokens corresponding to the text requirements through the Qformer multimodal compatible network structure by means of multimodal joint processing includes: Construct a prompt engineering format, and through the formatted prompt engineering description interaction of the text requirements input by the user or the known database field structure and requirement documents, output the configuration definition file of the DSL definer, and perform reformatting in regular format, including: Verify the JSON format; Verify whether the configuration format of a certain database field is correct, and whether it can run normally in the subsequent rendering engine and meet the expected effect; If the format verification still fails or cannot run normally, perform regular matching, extract all the key fields and value values in the JSON format and verify them, and fill the correct KV into the new DSL JSON format; Record the missing key and value values, and fill in and complete the default values.

[0013] By adopting the above technical solutions, the configuration definition file of the DSL definer is output for the user requirements, thus realizing the accurate parsing and conversion of the user requirements; verifying the JSON format to avoid as much as possible the failure of subsequent processing due to incorrect format of the generated configuration file; further improving the quality and usability of the configuration file by verifying the normal operation of the database fields, and performing regular matching when the format verification fails or cannot run normally to keep the data consistent and accurate; making the generated configuration file more perfect by recording the missing keys and values and filling in and completing the default values, reducing the need for manual intervention, and improving the automation level.

[0014] In a preferred example, the present application can be further configured as follows: after the step of separating the generation part that can be reused through the architecture and the generation part that needs to be generated by the large model according to the text requirements input by the user or the known database field structure and requirement documents, and obtaining the requirement list generated based on the decoupled basic functional components and logical relationship components, the following steps are further included: Generate P0 automated test cases according to the requirement list; Generate P1 automated test cases through web crawlers; Correct the accuracy rate of the generated code through multiple rounds of self-verification results.

[0015] By adopting the above technical solution, the software has high quality in the initial stage of development. For the generated front-end pages and table field attributes, the platform will generate add, delete, modify, and query test cases for the table, providing strong guarantee for subsequent testing work.

[0016] In a preferred example of the present application, it can be further configured that: the step of generating P0 automated test cases according to the requirement list includes: Confirm the functions at the P0 level in the requirement document; For each function at the P0 level, design test cases; Select an automated test tool and write an automated test script according to the designed test cases; Integrate the automated test script into the continuous integration / continuous deployment CI / CD process; Regularly execute the automated test, monitor the test results, and set an alarm mechanism to automatically notify relevant personnel when the test fails.

[0017] By adopting the above technical solution, design test cases for each function at the P0 level, improve test coverage and accuracy, and use an automated test tool to write an automated test script to reduce manual intervention and improve test efficiency; integrate the automated test script into the continuous integration / continuous deployment CI / CD process to achieve real-time detection and quick feedback. At the same time, in the regular monitoring test, when the test fails, automatically notify relevant personnel to ensure that problems are discovered and solved in a timely manner.

[0018] In a preferred example of the present application, it can be further configured that: the step of generating P1 automated test cases through a crawler includes: Confirm the functions at the P1 level in the requirement document and list all P1-level functions that need to be automated; Install the library files required for the crawler, analyze the data captured in the P1-level functions, and identify the key elements that can be used to generate test cases; Based on the captured data, design a test case template and generate an automated test script according to the test case template; Integrate the automated test script into the continuous integration / continuous deployment CI / CD process; Regularly execute the automated test, monitor the test results, and set an alarm mechanism to automatically notify relevant personnel when the test fails.

[0019] By adopting the above technical solutions, the core functional points covered by testing are obtained through the confirmation of P1-level functions in the requirements document; key elements are identified by crawlers, improving the accuracy and efficiency of data processing; automated test scripts can greatly reduce the time and cost of manual writing; integrating the automated test scripts into the continuous integration / continuous deployment CI / CD process enables real-time detection and quick feedback; promptly notifying relevant personnel to handle test failures can improve the quality and stability of the software.

[0020] In a second aspect, the present application provides a generative architecture decoupling function and business logic system, adopting the following technical solutions: A generative architecture decoupling function and business logic system includes: An architecture layering module: used to traverse the product functions of software on the market and decouple the architecture into basic functional components, logical relationship components, and business processes; A requirements acquisition module: used to separate the generative parts that can be reused through the architecture and those that need to be generated by a large model according to the text requirements input by the user or the known database field structure and requirements document, and obtain a requirements list generated based on the decoupled basic functional components and logical relationship components; A business transformation module: used to parse the requirements list based on a large model and transform it into business scenarios corresponding to software products composed of existing functional components through the large model.

[0021] In a third aspect, the present application provides an electronic device, adopting the following technical solutions: An electronic device includes a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps of the above-mentioned generative architecture decoupling function and business logic method.

[0022] In a fourth aspect, the present application provides a computer storage medium, with the following technical solutions: A computer-readable storage medium stores a computer program. When the computer program is executed by a processor, it implements the steps of the above-mentioned generative architecture decoupling function and business logic method.

[0023] In summary, the present application includes at least one of the following beneficial technical effects: 1. By decoupling the architecture into basic functional components, logical relationship components, and business processes, the effective separation of business logic and functional logic is achieved, significantly improving the maintainability and extensibility of the software; 2. Parse the text requirements input by the user or the database field structure and requirements document based on the large model, and automatically generate the corresponding basic function components and logical relationship components, greatly reducing the workload of manual coding and improving the development efficiency; 3. Automatically generate test cases at the P0 and P1 levels and integrate them into the continuous integration / continuous deployment (CI / CD) process, improving the quality and stability of software products and shortening the test cycle. Description of the Drawings

[0024] Figure 1 It is a flowchart of a method for decoupling functions and business logic in a generative architecture according to an embodiment of the present application.

[0025] Figure 2 It is a flowchart of sub-steps of step S1 according to an embodiment of the present application.

[0026] Figure 3 It is a flowchart of sub-steps of step S2 according to an embodiment of the present application.

[0027] Figure 4 It is a flowchart of sub-steps of step S20 according to an embodiment of the present application.

[0028] Figure 5 It is a flowchart of steps added after step S2 according to an embodiment of the present application.

[0029] Figure 6 It is a flowchart of sub-steps of step S21 according to an embodiment of the present application.

[0030] Figure 7 It is a flowchart of sub-steps of step S22 according to an embodiment of the present application.

[0031] Figure 8 It is a schematic structural diagram of a system for decoupling functions and business logic in a generative architecture according to an embodiment of the present application.

[0032] Figure 9 It is a schematic block diagram of the principle of an electronic device according to an embodiment of the present application.

[0033] Reference numerals: 1, architecture layering module; 2, requirement acquisition module; 3, business transformation module. Detailed Description of the Embodiment

[0034] The following is a further detailed description of the present application in conjunction with the attached Figures 1-9 to further illustrate the present application in detail.

[0035] Refer to Figure 1 , a method for decoupling functions and business logic in a generative architecture, specifically including: A method for decoupling functions and business logic in a generative architecture, including: S1. Traverse the product functions of software on the market and decouple the architecture into basic function components, logical relationship components, and business processes.

[0036] Among them, sort out mainstream and common apps and websites.

[0037] After traversing these mainstream functions, at the design level, the architecture is divided into three layers, specifically: Basic function components, which have nothing to do with business logic and are completely general-purpose.

[0038] Logical relationship components, which are related to business. However, due to the limited traversability, generality is achieved through configuration combination, and 16 arbitrarily splittable logical relationships are designed.

[0039] Business processes, which are strongly related to business, but can be divided into three categories according to their scope of application: highly reusable, partially general-purpose, and non-general-purpose.

[0040] Therefore, transform the software architecture according to the technical ability boundary of the large model, and then provide an architecture solution for compatibility and transition to achieve the ability to improve and accelerate the migration from the original architecture to the new architecture.

[0041] At the same time, after migration, due to the decoupling of functional logic and business, the efficiency and quality of developing different business logics based on the same functional logic are effectively improved and are close to being completed automatically.

[0042] S2. According to the text requirements input by the user or the known database field structure and requirement document, separate the parts that can be reused through the architecture and the parts that need to be generated by the large model, and obtain a requirement list generated based on the decoupled basic function components and logical relationship components.

[0043] Specifically, the large model only needs to provide the standardized interface required by the GPT model to normalize various concept variants in the input into one entity.

[0044] Before being put into use, the code large model needs to be built, trained, and optimized.

[0045] Among them, for the construction of the code large model, on the one hand, collect and analyze the requirements, clarify the goals and requirements for building the code large model and conduct analysis and review, specifically including: First, identify all relevant stakeholders, including the development team, data scientists, product managers, and end-users, etc. Through meetings, interviews, questionnaires, etc., understand the specific requirements of all parties for the code large model. Secondly, classify the collected requirements according to aspects such as functionality, performance, and security. Prioritize the requirements based on importance and urgency for subsequent resource allocation planning. Then invite all stakeholders to participate in the requirements review meeting, discuss and confirm the preliminary requirements list. Record the opinions and suggestions put forward during the review process and form a document for subsequent reference. At the same time, based on the existing requirements analysis results, clarify the overall goals of the project, such as improving code generation efficiency, enhancing code quality, etc. For each requirement point, further refine its specific requirements, including but not limited to functional details, performance indicators, data requirements, and interface specifications. Use a requirements matrix table to map the relationship between each requirement point and the project goals to help better understand the relevance between requirements. Finally, integrate the above analysis results into a formal requirements document as the basis for subsequent design, coding, and other work. As the project progresses, requirements may change, and the requirements document needs to be updated in a timely manner to maintain its accuracy and timeliness. Also, after the requirements document is completed, organize a final review meeting to ensure that all stakeholders reach a consensus on the requirements. After obtaining the signature approval of the key decision-makers, the requirements document comes into force formally and becomes the basis for project implementation.

[0046] Secondly, collect and clean the data required by the model, removing duplicate, incorrect, or sensitive data, specifically including: First, refer to the previous requirements analysis document to clarify the specific requirements for the data needed. Determine the data sources, types (such as text, code snippets), quantities, etc. Secondly, select appropriate data sources. The data can come from open-source projects on platforms such as GitHub, GitLab, Bitbucket, code datasets provided on platforms such as Kaggle, Hugging Face, or historical code repositories and project codes within the company. Then, choose an appropriate data collection method. You can use crawler tools to scrape code data from websites, utilize the GitHub API or API interfaces of other code platforms to obtain code data, purchase high-quality code datasets from third-party data providers, or export code data from the company's internal database or file system. Next, delete duplicate code snippets to ensure the uniqueness of the data. Ensure that all code snippets have the same format for subsequent processing. Remove unnecessary comment information to avoid interfering with model learning. Correct syntax errors or other obvious errors in the code. Then, use statistical methods or machine learning algorithms to identify and handle outliers and remove irrelevant or redundant data, convert data from different sources into a unified standard format, and then fill in or delete missing values according to the actual situation. Further, randomly select a portion of the data for manual inspection to ensure data quality, and then verify the consistency and integrity of the data to ensure that the data meets the expected standards. Test the model performance using a small-scale dataset to evaluate the impact of data quality. Next, select an appropriate storage method (such as a local hard drive, cloud storage service, etc.) according to the data volume and access frequency, establish a data backup mechanism to prevent data loss. Set reasonable access permissions to ensure data security. Finally, record in detail the information such as the source and collection date of each batch of data. Record the detailed steps of data preprocessing and cleaning for subsequent maintenance and auditing.

[0047] Thirdly, design and select the model. Choose an appropriate model architecture according to the project goals and data characteristics, and design the basic structure of the model, specifically including: First, clarify the type of task that the model needs to complete, such as: classification, generation, translation, filling in the blanks, etc. Define the specific problems that the model needs to solve, such as code completion, error detection, code generation, etc. Secondly, conduct research on existing models, read relevant papers, and understand the current state-of-the-art models and their performance. Check open-source models on platforms such as GitHub and evaluate their applicability. Then, select a suitable architecture for design. For example, the BERT model based on Transformer is more suitable for natural language processing tasks and can be fine-tuned to adapt to tasks such as code completion. Next, adjust the hyperparameters of the model, including the learning rate, the number of model layers, the hidden layer dimension, and the attention mechanism. Appropriately add specific modules, such as adding positional encoding in the self-attention mechanism to improve the model's ability to understand positional information. Then, perform pre-training on a large amount of unlabeled data and fine-tune on a small amount of labeled data for specific tasks to adapt to specific application scenarios. At the same time, select appropriate evaluation metrics for evaluation and use the cross-validation method to evaluate the generalization ability of the model. Finally, select a suitable deployment environment, monitor the model performance regularly, and update the model in a timely manner to cope with new situations.

[0048] In the pre-training stage, the platform adopted a 4M context and a 7B pre-training model to deeply understand and analyze each requirement. This in-depth understanding ensures that the platform can accurately grasp the user's intention and provide strong support for subsequent code generation.

[0049] Fourthly, label and preprocess the data of the model to facilitate the model to better understand and process the data. Specifically, it includes: Before data annotation, ensure that data cleaning has been carried out. For a small amount of high-quality data, the manual annotation method can be used. Use a small amount of labeled data combined with a large amount of unlabeled data for training. For some tasks, labels can be automatically generated by a program, such as prefixes and suffixes in the code completion task. Secondly, convert the text and each character into vector representations. Then, replace synonyms or similar operations in the code to increase data diversity. Insert some random syntactic structures or logical errors in the code to train the robustness of the model. Then, extract statistical features in the code snippet, such as code length, the number of variables, the number of functions, etc. Use static analysis tools to extract the semantic information of the code. Finally, perform data standardization operations to scale the numerical features to the same range, such as between 0 and 1. Make the data conform to the normal distribution, usually using Z-score standardization.

[0050] For the training of the code large model, first, initialize the model and set the initial parameter values for the newly designed model. Specifically, it includes: First, define the model architecture, including the type and number of neural networks used, activation functions used, etc. Then, initialize the model parameters using a specific initialization method, such as Xavier initialization. Finally, check the distribution of the model parameters to ensure they meet expectations.

[0051] In the second aspect, divide the dataset into a training set, a test set, and a validation set, and determine the data division strategy and cleaning and optimization strategy, specifically including: First, load the data into memory, for example, store the data in a CSV file. Then, remove missing values and outliers from the data. Next, divide the data into a training set, a validation set, and a test set. Usually, the ratio of 80% training set, 10% validation set, and 10% test set is adopted. Finally, perform feature processing according to the model requirements, such as normalization, standardization, etc.

[0052] In the third aspect, use the training data to train the model and learn the features and patterns of the code. Then, adjust the training parameters according to the performance of the model, specifically including: First, import all necessary library files, prepare the required data files, and ensure the format is correct. Secondly, define a complete neural network model and set appropriate loss functions and optimizers. Then, start training the model and record the model training result logs for each round. Adjust the training parameters according to the model performance. Finally, evaluate the model performance on the validation set and then conduct the final test on the test set.

[0053] In the fourth aspect, monitor the training process of the model, and promptly discover and handle problems that occur during the training process, specifically including: First, import all necessary library files to ensure that the model can be trained normally. Secondly, initialize some variables to record key metrics during the training process. Then, start training the model and record the loss value for each epoch. Finally, discover and handle problems that occur during the model training, such as overfitting and underfitting. Plot the visualization results for easy problem analysis.

[0054] For the optimization of the code large model, in the first aspect, use the test set to evaluate the trained model and adjust the structure or parameters of the model according to the evaluation results, specifically including: First, ensure that the available test set and validation set are prepared, and load the pre-trained model or the best model saved previously. Secondly, define the evaluation metrics according to the task, such as accuracy, BLEU score, etc. Then, evaluate the model on the validation set and the test set. Finally, plot the loss curve or other visualization charts of the evaluation results.

[0055] In the second aspect, optimize the hyperparameters of the model, specifically including: First, determine the hyperparameters to be adjusted and their reasonable value ranges. Common hyperparameters include learning rate, batch size, optimizer type, number of layers, number of hidden units, etc. Then, design an experimental plan to systematically adjust the hyperparameters. Use grid search, random search, or more advanced methods such as Bayesian optimization. Next, define the training and validation functions to train the model under each hyperparameter configuration and record the validation loss. Then, save the model with the best performance during training and its corresponding hyperparameters. Finally, evaluate the model under the final selected hyperparameter configuration using the test set.

[0056] In the third aspect, use regularization methods to prevent the model from overfitting, and use optimization algorithms to improve the training efficiency of the model, specifically including: First, import all necessary library files and prepare the required data files (ensure the format is correct). Then, define a complete neural network model and set appropriate loss functions and optimizers. Then start model training and record the model training result logs for each round. Adjust the training parameters according to the model performance. Finally, evaluate the model performance on the validation set and then conduct the final test on the test set.

[0057] In the fourth aspect, integrate and fuse the prediction results of multiple models, specifically including: First, select different model architectures or use different initialization parameters of the same architecture to generate multiple models. Then, train the above models separately and save the weights of the corresponding models. Then, in the prediction stage, fuse the prediction results of each model. Finally, evaluate the performance of the integrated model to ensure it is better than a single model.

[0058] In the fifth aspect, continuously learn and update the model, specifically including: Continuously collect new data and preprocess this data so that the model can understand it. Then, use the new data to fine-tune or continue training the model to adapt to the characteristics of the new data. Regularly save the updated model weights for subsequent use or further training. Finally, continuously monitor the performance of the model to ensure it can adapt to the new data distribution.

[0059] S3. Parse the requirements list based on the large model and transform it into the business scenarios corresponding to the software products composed of existing functional components through the large model.

[0060] Among them, according to the user requirements, use the trained large model to generate the corresponding software code, and then conduct static analysis and dynamic testing on the generated code to ensure it meets the user requirements and quality standards.

[0061] Performing static analysis and dynamic testing on the generated code are important steps to ensure code quality and accuracy. The following is a detailed description of static analysis, dynamic testing, automated test case generation, and multiple rounds of self-verification and correction according to requirements: In the first aspect, to implement static analysis, first, select a suitable static analysis tool according to the programming language.

[0062] Secondly, configure the analysis tool according to the project requirements, set the analysis rules, scope, etc., specifically including: Clarify the project requirements, including the type of code to be generated, the programming language used, specific coding specifications, etc. Then, select a suitable code generation tool according to the requirements. Next, install and configure the selected static analysis tool. After running the static analysis tool to analyze the code, view the analysis results and make corresponding code improvements according to the results. Further, integrate static analysis into the CI / CD process to ensure that static analysis can be performed every time code is committed.

[0063] Finally, use the static analysis tool to analyze the code and generate an analysis report for relevant personnel to carefully read the analysis report, identify potential problems in the code, and repair them according to the severity and priority of the problems.

[0064] In the second aspect, to implement dynamic testing, first, select a suitable dynamic testing tool according to the programming language.

[0065] Secondly, write test cases that cover the main functions of the code according to the requirements to ensure that the test cases can trigger the critical paths and boundary conditions in the code, specifically including: Clarify the function or module to be tested and what the main goal of the test is. Then, deeply understand the requirements document to determine which functions need to be tested. Clarify the working principle, input and output, and boundary conditions of the function. Then, write specific test cases according to the test scenarios.

[0066] Then, use the dynamic testing tool to run the test cases and observe the execution process and output results of the program, specifically including: Execute the test step by step according to the test cases, record all information during the test, including input data, actual output, problems encountered, etc. Then, record the execution results of each test case and generate a test report.

[0067] Finally, find problems and defects in the code according to the test results and repair them, and then re-run the test cases to verify the repair effect.

[0068] In the third aspect, by generating automated test cases and performing multiple rounds of self-verification result correction to generate the accuracy rate of the code, and then continuously improve the code coverage and accuracy rate of the generated code.

[0069] Meanwhile, using the rendering platform, the platform can automatically create data tables according to the JSON DSL and generate corresponding front-end pages. Users only need to set it up simply to achieve this function, which greatly reduces the development threshold. Finally, the generated software product is deployed to the environment specified by the user, and subsequent software maintenance and upgrade services are provided to ensure the stable operation of the software product and complete the deployment and maintenance of the software.

[0070] Moreover, the platform also includes a complete workflow maintenance system. From requirement submission (sales) to product clarification (requirement refinement), then to R & D (backend, front-end, testing) and delivery (operation and maintenance), each link is closely connected to ensure the smooth progress of software development. In addition, the platform also supports incremental iteration and responsive services, and can continuously optimize software performance according to user feedback.

[0071] To further improve software quality, the platform also introduces the Agent mechanism for multi-round interaction, scheduling and status control with the model. Through the ReACT strategy (reasoning and thinking, execution, and consistency check of thinking results and goals), the platform can continuously optimize the effect of the generated code to ensure that the software meets user expectations.

[0072] Reference Figure 2 , further, in one embodiment, step S1 is refined into the following sub-steps: S10. Establish a basic function component library. Based on the method of inversion of control and abstract definition, express the configuration of basic function components through a DSL configuration file.

[0073] Among them, the basic function components include establishing a component library, such as search function, list, paging and page number, editing, details, etc. Establishing a basic function component library and expressing it through a DSL configuration file enables each basic function component to be assembled through simple configuration, reducing the workload of manual coding and thus improving development efficiency.

[0074] S11. Establish a logical relationship component library and convert it into the JSON DSL format to assemble business flow logic.

[0075] Among them, the platform supports the modeling of library tables and also converts these models into the JSON DSL format. Subsequently, combined with the front-end interface, library tables and detailed information of user requirements (after detailed supplementation), the platform automatically generates the backend interaction logic corresponding to the front-end interface, also expressed in the form of JSON DSL. This step greatly simplifies the development process and improves development efficiency.

[0076] Logically at the top level, a unified behavior node tree is generated, covering the behavior paths corresponding to all business processes of users. Each node contains four dimensions: database, backend logic, page, and the logical relationship between the front-end and backend.

[0077] In the specific database table design, a three-layer structure is adopted to uniformly describe the functional logic required for all services: A base table, the Base table, is established. The fields in the table have nothing to do with the business. For example, the mobile phone number starts with 1 and has 11 digits. After its definition, the front-end and back-end logics are the same in any business scenario. Similarly, there are gender, age, address, id, etc.

[0078] Three general tables for the top-level business logic are established: the user table, the user behavior object table, and the context table, to abstractly describe any business logic, and define the business process as the state of the general database at the previous moment, which is abstracted as the state change from the previous node - the current node - the next node of the database at the next moment.

[0079] When a requirement is input and parsed into the DSL definition of the table structure, taking the e-commerce shopping cart business requirement as an example, it is divided into the following steps: First, select quantity, price, title, etc. from the base table base as the fields of the user behavior object table.

[0080] Then, select the user name, user id, etc. from the base table base as the fields of the user table Next, the context table contains user behaviors: the input-output mapping translation of general behaviors such as addition, deletion, quantity change, settlement, etc. corresponding to shopping cart behaviors such as adding to the cart, deleting, changing the quantity, and settlement in the shopping cart scenario. Just transfer the DSL configuration after the requirement definition into the behavior of refining the general context to the business logic in the shopping cart scenario.

[0081] For example, adding to the cart is to configure the general "addition" general behavior, with its upstream node depending on the logged-in user, the current node being the shopping cart list, and the next node being a new entry added to the shopping cart list.

[0082] Finally, through the assembly of the top-level business logic behavior nodes, each node contains [upstream node, current node, downstream node], and the entire tree can be spliced together to form the correct dependency and business process logic.

[0083] The assembly of the business process logic is composed of 16 common logical relationship components in 7 categories: verification logic (whether the actor and the resource exist, whether the current actor has the permission), horizontal listing without strong logical flow (parallel relationship, explanatory relationship, progressive relationship, sequential relationship, contrast relationship), judgment branch (single-cause verification logic, complex multi-branch logic of multiple / one cause and multiple / one effect), hierarchical relationship (nested logic including logic, inductive relationship), loop relationship, mapping relationship, decision logic. In one embodiment, the configuration expression of the logical relationship components is as follows: logic_type: One of 16 types of logical types; logic_exp: Such as a&b | c; __logic_exec is the general expansion execution logic of logical expressions.

[0084] Moreover, the generality of the design logic relationship is considered, that is, based on the functional logic, typical application scenarios from the finest granularity to the logical relationship and then to the business logical relationship can be assembled and traversed, so as to ensure the generality of the functions and logical components below the business layer.

[0085] Convert the logical relationship components into JSON DSL format, which is convenient for the flexible assembly of business flow logic, further enhances flexibility and adaptability, and reduces the modification cost brought by requirement changes.

[0086] In addition, referring to Figure 3 , further, in one embodiment, step S2 is refined into the following sub-steps: S20. Receive the text requirements input by the user, convert the text requirements into JSON DSL configuration. If the received requirements are non-text requirements, then through multimodal joint processing, the non-text requirements are converted into tokens corresponding to the text requirements through the Qformer multimodal compatible network structure.

[0087] Specifically, the platform first receives the text requirements input by the user, and through internal processing, converts these requirements into a unified and standardized JSON DSL (Domain Specific Language) configuration. This process ensures the accuracy and consistency of the requirements, laying a solid foundation for subsequent software development.

[0088] In one embodiment, after the user inputs text requirements, it is first necessary to deeply understand the scenarios, necessary elements, and relevant domain information included in the page requirements, component requirements, and user requirements. Then, understand the meaning of each field value in the label file. The value of the label file is an explanation of the key, and the meaning of the key is the same as that in the subsequent configuration file. Then, according to the explanation of the fields in the label, modify the corresponding field values in the configuration to make them meet the requirements (including matching the text content, color, etc. of the requirements). Finally, output the modified configuration JSON.

[0089] The platform also supports different types of input data. For example, if the input type is a picture and / or video, it is first converted into tokens corresponding to the text requirements to achieve the unity and standardization of the data. This not only improves the diversity and accuracy of requirement collection, but also enables various forms of requirements input by users to be effectively parsed and utilized, thereby enhancing the adaptability and flexibility of the system, achieving the improvement of the efficiency and quality of requirement processing, and enhancing the decoupling effect of business logic and functional logic.

[0090] In addition, referring to Figure 4 , further, in one embodiment, step S20 is refined into the following sub-steps: S200. Construct a prompt engineering format, and through the formatted prompt engineering description interaction of the text requirements input by the user or the known database field structure and requirement documents, output the configuration definition file of the DSL definer, and perform reformatting in regular format, including: Perform JSON format verification. Specifically, DSL is a special JSON format. For JSON format verification, if it is correct, it passes; if it is incorrect, the error area needs to be located, such as the matching number of special syntax symbols, such as the curly braces {}, single quotes, double quotes, etc., which are verified by the stack to ensure complete matching. Then try to repair and retry 3 times. Reduce the risk of subsequent processing failure caused by incorrect configuration file formats generated.

[0091] Verify whether the configuration format of a certain database field is correct, and whether it can run normally in the subsequent rendering engine and meet the expected effect, so as to keep the database field consistent and accurate and can run after configuration.

[0092] If the format verification still fails or cannot run normally, perform regular matching, extract all the key fields and value values in the JSON format and verify them, and fill the correct KV into the new DSL JSON format to ensure it can run.

[0093] Record the missing key and value values, and perform default value filling and completion to make the generated configuration file more perfect, reduce the need for manual intervention, and improve the automation level.

[0094] In addition, referring to Figure 5 , further, in one embodiment, after step S2, steps S21, S22, and S23 are added: S21. Generate P0 automated test cases according to the requirements list.

[0095] Specifically, the platform supports generating P0 test cases and UI interfaces (static) according to the requirements JSON DSL. Combining the database table structure and requirement details, the platform can generate complete backend logic, and continuously complement the details desired by the user through multiple rounds of interaction, and verify and ensure the code quality.

[0096] S22. Generate P1 automated test cases through web scraping.

[0097] S23. Correct the accuracy of the generated code through multi-round self-verification results.

[0098] Specifically, first perform the first-round verification, that is, use the generated code for preliminary running and testing, specifically including: Check the input data to ensure that the input data conforms to the expected format and requirements. Then, verify the logical consistency to ensure the consistency and logical relationship between the input data. Next, perform basic function tests to ensure that the basic functions can work properly. Further, check the dependencies to ensure that all dependencies have been correctly installed and configured. Finally, record all the problems and error messages found in the first-round verification for subsequent processing and debugging.

[0099] After fixing the problems in the first-round verification, perform the second-round verification and repeat the process until the code performs stably and accurately in multiple verifications.

[0100] Then, introduce external verification to further confirm the accuracy and reliability of the code, specifically including: Use static code analysis tools, introduce unit test frameworks, and use continuous integration / continuous deployment (CI / CD) tools. At the same time, introduce third-party services for API verification and integrate third-party libraries or tools.

[0101] Finally, continuously optimize and improve the quality and performance of the code to continuously increase the test coverage and accuracy.

[0102] Through the above steps, for the generated front-end page and table field attributes, the platform will generate add, delete, modify, and query test cases for the table, providing strong guarantee for subsequent testing work. Finally, every time the code is submitted, it can trigger automated testing, and the automated testing can make the generation of the final code more accurate.

[0103] In addition, referring to Figure 6 , further, in one embodiment, step S21 is refined into the following sub-steps: S210. Confirm the functions at the P0 level in the requirements document.

[0104] Specifically, fully understand the requirements document, determine which functions are at the P0 level, and list all the P0-level functions that need to be automated.

[0105] S211. Design test cases for each P0-level function.

[0106] Specifically, design detailed test cases to ensure coverage of various boundary and exception cases.

[0107] S212. Select an automated testing tool and write automated test scripts according to the designed test cases.

[0108] Specifically, select an automated testing tool based on the project's technology stack and team familiarity. The written automated test script ensures that it can cover all critical paths and boundary conditions.

[0109] S213. Integrate the automated test script into the continuous integration / continuous deployment CI / CD process.

[0110] Specifically, the purpose of triggering automated tests every time code is committed is achieved.

[0111] S214. Regularly execute automated tests, monitor the test results, and set an alarm mechanism to automatically notify relevant personnel when the tests fail.

[0112] In addition, referring to Figure 7 , further, in one embodiment, step S22 is refined into the following sub-steps: S220. Confirm the functions at the P1 level in the requirements document and list all P1-level functions that need to be automated.

[0113] S221. Install the library files required for the crawler, analyze the data crawled in the P1-level functions, and identify the key elements that can be used to generate test cases.

[0114] Specifically, identifying key elements through the crawler improves the accuracy and efficiency of data processing; the automated test script can greatly reduce the time and cost of manual writing.

[0115] S222. Based on the crawled data, design a test case template and generate an automated test script according to the test case template.

[0116] S223. Integrate the automated test script into the continuous integration / continuous deployment CI / CD process.

[0117] Specifically, the purpose of triggering automated tests every time code is committed is achieved.

[0118] S224. Regularly execute automated tests, monitor the test results, and set an alarm mechanism to automatically notify relevant personnel when the tests fail.

[0119] It should be understood that the magnitudes of the sequence numbers of the steps in the above embodiments do not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation to the implementation process of the embodiments of the present application.

[0120] The embodiments of the present application also provide a generative architecture decoupling function and business logic system, which corresponds one-to-one with the generative architecture decoupling function and business logic method in the embodiments.

[0121] Referring toFigure 8 , a generative architecture decoupling function and business logic system includes: an architecture layering module 1, a requirement acquisition module 2, and a business transformation module 3. The detailed description of each functional module is as follows: Architecture layering module 1: used to traverse the product functions of software on the market and decouple the architecture into basic function components, logical relationship components, and business processes; Requirement acquisition module 2: used to separate the generative parts that can be reused through the architecture and those that need to be generated by the large model according to the text requirements input by the user or the known database field structure and requirement documents, and obtain a requirement list generated based on the decoupled basic function components and logical relationship components; Business transformation module 3: used to parse the requirement list based on the large model and transform it into the business scenarios corresponding to the software products composed of existing function components through the large model.

[0122] Among them, the architecture layering module 1 traverses the functions of existing software products on the market and decouples them into basic function components, logical relationship components, and business processes; the requirement acquisition module 2 supports the user to input text requirements or utilize the known database field structure and requirement documents to automatically separate the reusable basic function components and the parts that need to be generated by the large model to automatically generate a detailed requirement list; the business transformation module 3 parses the requirement list based on the large model and transforms the parsing result into the specific business scenarios of the existing function component combinations. Through the combination of each module, the effective separation of business logic and functional logic and a highly automated design process are realized, greatly shortening the development cycle from requirements to products, reducing the possibility of human errors, and improving the development quality and efficiency.

[0123] For the specific limitations of the generative architecture decoupling function and business logic system, reference can be made to the limitations of the generative architecture decoupling function and business logic method in the context, which will not be elaborated here. Each module in the above-mentioned generative architecture decoupling function and business logic system can be implemented in whole or in part by software, hardware, and their combinations. The above-mentioned modules can be embedded in the processor of the electronic device in hardware form or independent of it, or stored in the memory of the electronic device in software form to facilitate the processor to call and execute the operations corresponding to the above-mentioned modules. In one embodiment, an electronic device is provided, and this electronic device is a user terminal. Refer to Figure 9, the electronic device includes a processor, a memory, a network interface, and a database connected via a system bus. Among them, the processor of the electronic device is used to provide computing and control capabilities. The memory of the electronic device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and the computer program in the non-volatile storage medium. The database of the electronic device is used to store detection data tables. The network interface of the electronic device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, it realizes a generative architecture decoupling function and a business logic method.

[0124] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored on the memory and executable on the processor. When the processor executes the computer program, the following steps are implemented: S1. Traverse the product functions of software on the market, and decouple the architecture into basic function components, logical relationship components, and business processes.

[0125] S2. According to the text requirements input by the user or the known database field structure and requirement document, separate the generative parts that can be reused through the architecture and those that need to be generated by the large model, and obtain a requirement list generated based on the decoupled basic function components and logical relationship components.

[0126] S3. Parse the requirement list based on the large model, and transform it into the business scenarios corresponding to the software products composed of existing function components through the large model.

[0127] In one of the embodiments, the sub-steps refined in step S1 include: S10. Establish a basic function component library, and based on the method of inversion of control and abstract definition, express the configuration of the basic function components through a DSL configuration file.

[0128] S11. Establish a logical relationship component library, and transform it into the JSON DSL format to assemble the business flow logic.

[0129] In one of the embodiments, the sub-steps refined in step S2 include: S20. Receive the text requirements input by the user, and transform the text requirements into JSON DSL configurations. If the received requirements are non-text requirements, then through multimodal joint processing, the non-text requirements are transformed into tokens corresponding to the text requirements through the Qformer multimodal compatible network structure.

[0130] In one of the embodiments, the refined sub-steps of step S20 include: S200. Construct the prompt engineering format. Through the formatted prompt engineering description interaction of the text requirements input by the user or the known database field structure and requirement documents, output the configuration definition file of the DSL definer, and perform reformatting in regular format, including: Perform JSON format verification.

[0131] Verify whether the configuration format of a certain section of database fields is correct, and whether it can run properly in the subsequent rendering engine and meet the expected effect.

[0132] If the format verification still fails or cannot run properly, perform regular matching, extract all the key fields and value values in the JSON format and verify them, and fill the correct KV into the new DSL JSON format.

[0133] Record the missing key and value values, and fill and complete the default values.

[0134] In one embodiment, the steps added after step S2 include: S21. Generate P0 automated test cases according to the requirements list.

[0135] S22. Generate P1 automated test cases through web scraping.

[0136] S23. Correct the accuracy rate of the generated code through multiple rounds of self-verification results.

[0137] In one embodiment, the sub-steps refined in step S21 include: S210. Confirm the P0-level functions in the requirements document.

[0138] S211. Design test cases for each P0-level function.

[0139] S212. Select an automated test tool and write an automated test script according to the designed test cases.

[0140] S213. Integrate the automated test script into the continuous integration / continuous deployment CI / CD process.

[0141] S214. Regularly execute the automated test, monitor the test results, and set an alarm mechanism to automatically notify relevant personnel when the test fails.

[0142] In one embodiment, the sub-steps refined in step S22 include: S220. Confirm the P1-level functions in the requirements document, and list all the P1-level functions that need to be automated.

[0143] S221. Install the library files required for the crawler, analyze the data crawled in the P1-level function, and identify the key elements that can be used to generate test cases.

[0144] S222. Design a test case template based on the crawled data, and generate an automated test script according to the test case template.

[0145] S223. Integrate the automated test script into the continuous integration / continuous deployment CI / CD process.

[0146] S224. Regularly execute the automated test, monitor the test results, and set an alarm mechanism to automatically notify relevant personnel when the test fails.

[0147] Those of ordinary skill in the art can understand that all or part of the processes in the methods of the above embodiments can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When the computer program is executed, it can include the processes of the embodiments of the above methods. Among them, any reference to the memory, storage, database, or other media used in the various embodiments provided in the present application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double data rate SDRAM (DDR SDRAM), enhanced SDRAM (ESDRAM), synchronous link (Synchlink) DRAM (SLDRAM), memory bus (Rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0148] Those skilled in the art can clearly understand that for the convenience and simplicity of description, only the above division of each functional unit and module is used as an example. In actual applications, the above functions can be allocated to different functional units and modules according to needs, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

Claims

1. A generative architecture decoupling function and business logic method, characterized in that: include: Traverse the product functions of software on the market, and decouple the architecture into basic functional components, logical relationship components, and business processes; According to the text requirements input by the user or the known database field structure and requirement documents, separate the generated parts that can be reused through the architecture and need to be generated by a large model, and obtain the requirement list generated based on the decoupled basic functional components and logical relationship components; The requirements list is parsed based on the big model and converted into business scenarios corresponding to software products with existing functional component combinations through the big model.

2. The method according to claim 1, characterized in that The steps of traversing the product functions of the software on the market and decoupling the architecture into basic functional components, logical relationship components and business processes include: Establish a basic functional component library, and express the configuration of the basic functional components through DSL configuration files based on inversion of control and abstract definition; Create a logical relationship component library and convert it into JSON DSL format to assemble business flow logic.

3. The method according to claim 1, characterized in that The step of separating the generated parts that can be reused through the architecture and need to be generated by a large model according to the text requirements input by the user or the known database field structure and requirement documents, and obtaining the requirement list generated based on the decoupled basic functional components and logical relationship components, includes: Receive the text requirements input by the user, convert the text requirements into JSON DSL configuration, and if the received requirements are non-text requirements, convert the object token into the token corresponding to the text requirement through multimodal joint processing of the non-text requirements through the Qformer multimodal compatible network structure.

4. The method according to claim 3, characterized in that include: The step of receiving the text requirement input by the user, converting the text requirement into a JSON DSL configuration, and if the received requirement is a non-text requirement, converting the object token into a token corresponding to the text requirement through a Qformer multimodal compatible network structure by multimodal joint processing of the non-text requirement, includes: Build the prompt project format, transform the text requirements entered by the user or the known database field structure and requirement documents into a formatted prompt project description, output the configuration definition file of the DSL definer, and reformat it in a regular format, including: Verify the JSON format; Verify whether the configuration format of a certain database field is correct, and whether it can run normally and meet the expected effect in the subsequent rendering engine; If the format check still fails or cannot run normally, perform regular expression matching, extract and check all key fields and value values ​​in the JSON format, and fill the correct KV into the new DSL JSON format; Record missing key fields and value values, and fill in the default values.

5. The method according to claim 1, characterized in that After the step of separating the generated parts that can be reused through the architecture and need to be generated by a large model according to the text requirements input by the user or the known database field structure and requirement documents, and obtaining the requirement list generated based on the decoupled basic functional components and logical relationship components, the method further includes: Generate P0 automated test cases based on the requirements list; Generate P1 automated test cases through crawlers; The accuracy of the generated code is corrected through multiple rounds of self-verification results.

6. The method according to claim 5, characterized in that The step of generating a P0 automated test case according to the requirements list includes: Confirm that the requirements document has P0-level functions; Design test cases for each P0-level function; Select an automated testing tool and write an automated testing script based on the designed test cases; Integrate the automated test scripts into the continuous integration / continuous deployment CI / CD process; Perform automated tests regularly, monitor test results, and set up an alarm mechanism to automatically notify relevant personnel when a test fails.

7. The method according to claim 5, characterized in that The steps of generating P1 automated test cases by crawling include: Confirm the P1-level functions in the requirement document and list all P1-level functions that need to be automated; Install the library files required by the crawler, analyze the data captured in the P1 level function, and identify the key elements that can be used to generate test cases; Design test case templates based on captured data and generate automated test scripts based on the test case templates; Integrate the automated test scripts into the continuous integration / continuous deployment CI / CD process; Perform automated tests regularly, monitor test results, and set up an alarm mechanism to automatically notify relevant personnel when a test fails.

8. A generative architecture decouples functions and business logic systems, characterized in that: include: Architecture layering module (1): used to traverse the product functions of software on the market and decouple the architecture into basic functional components, logical relationship components, and business processes; Requirements acquisition module (2): used to separate the generated parts that can be reused through the architecture and generated by the large model according to the text requirements input by the user or the known database field structure and requirements document, and obtain the requirements list generated based on the decoupled basic functional components and logical relationship components; Business transformation module (3): used to parse the requirements list based on the big model and transform the requirements list into business scenarios corresponding to the software product with existing functional component combinations through the big model.

9. An electronic device, characterized in that: The invention comprises a memory and a processor, wherein the memory stores a computer program which can be loaded by the processor and executes the method for decoupling functions and business logic of a generative architecture as claimed in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that: A computer program is stored which can be loaded by a processor and execute the method for decoupling functions and business logic of a generative architecture as claimed in any one of claims 1 to 7.

Images