Generative architecture decoupling functions and business logic methods, systems, devices and media

Abstract

The present application relates to a method, system, device and medium for decoupling functions and business logic of a generative architecture, and relates to the field of software development automation technology. The method includes: traversing the product functions of software on the market, dividing the architecture into basic functional components, logical relationship components and business processes for decoupling; separating the generated parts that can be reused through the architecture and need to be generated by a large model based on the text requirements input by the user or the known database field structure and requirement documents, and obtaining a requirement list generated based on the decoupled basic functional components and logical relationship components; parsing the requirement list based on the large model, and converting it into the business scenario corresponding to the software product with the existing functional component combination through the large model. The present application can achieve the effective separation of business logic and functional logic.

Description

Technical Field

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

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

[0003] Currently, software development architectures primarily rely on manual coding. While these coded architectures achieve a small degree of decoupling between business logic and functional logic, they fail to fully decouple functional logic from business logic. These architectures typically only address specific, general-purpose functions, such as user login and registration, lacking comprehensiveness and flexibility. Furthermore, existing technical architectures often require extensive customization and modification to achieve true decoupling when requirements change.

[0004] Therefore, existing technologies are prone to the problem that manual coding is time-consuming and error-prone, resulting in low efficiency. At the same time, the quality of code written by different developers varies, and existing code generation tools can usually only generate code in a fixed format and cannot be customized according to specific needs. The lack of flexibility limits enterprises from fully leveraging the advantages of decoupling in actual applications. A more efficient decoupling solution is urgently needed to meet the above challenges. Summary of the Invention

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

[0006] In the first aspect, the present application provides a method for decoupling functions and business logic using a generative architecture, which adopts the following technical solutions:

[0007] A generative architecture that decouples functionality and business logic, including:

[0008] Traverse the product functions of software on the market and decouple the architecture into basic functional components, logical relationship components, and business processes;

[0009] Based on 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 require large model generation, and obtain a requirement list generated based on the decoupled basic functional components and logical relationship components;

[0010] 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.

[0011] By adopting the above technical solutions, the software architecture is transformed according to the technical capability boundaries of the large model, providing a compatible transition architecture solution, 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 functional logic from business, the efficiency and quality of developing different business logic based on the same functional logic are effectively improved, thereby increasing the degree of automation.

[0012] In a preferred example, the present application may be further configured as follows: the step of traversing the product functions of software on the market and decoupling the architecture into basic functional components, logical relationship components, and business processes includes:

[0013] 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.

[0014] Create a logical relationship component library and convert it into JSON DSL format to assemble business flow logic.

[0015] By adopting the above technical solution, a basic functional component library is established and expressed through DSL configuration files, so that each basic functional component can be assembled through simple configuration, reducing the workload of manual coding and improving development efficiency. The logical relationship components are converted into JSON DSL format to facilitate the flexible assembly of business flow logic, further enhance flexibility and adaptability, and reduce the modification costs caused by changing requirements.

[0016] In a preferred example, the present application may be further configured as follows: the step of separating the generated parts that can be reused through the architecture and require large-scale model generation based on the text requirements input by the user or the known database field structure and requirements document, and obtaining the requirements list generated based on the decoupled basic functional components and logical relationship components, includes:

[0017] Receive text requirements input by the user and convert the text requirements into JSON DSL configuration. If the received requirement is a non-text requirement, the non-text requirement is processed through multimodal joint processing and the object token is converted into the token corresponding to the text requirement through the Qformer multimodal compatible network structure.

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

[0019] In a preferred example, the present application may be further configured as follows: the step of receiving a text requirement input by a 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 multimodal joint processing of the non-text requirement using a Qformer multimodal compatible network structure, includes:

[0020] 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:

[0021] Verify the JSON format;

[0022] 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;

[0023] If the format verification still fails or does not work properly, perform regular expression matching, extract and verify all key fields and values ​​in the JSON format, and then fill the correct key and value into the new DSL JSON format.

[0024] Record missing key and value values ​​and fill them with default values.

[0025] By adopting the above technical solution, user requirements are output to the configuration definition file of the DSL definer, thereby achieving accurate parsing and conversion of user requirements; the JSON format is verified to minimize subsequent processing failures caused by format errors in the generated configuration file; the quality and usability of the configuration file are further improved by verifying the normal operation of the database fields, and regular matching is performed when the format verification fails or the normal operation cannot be performed to ensure data consistency and accuracy; by recording missing keys and values ​​and filling in default values, the generated configuration file is made more complete, reducing the need for manual intervention and improving the level of automation.

[0026] In a preferred example, the present application may be further configured as follows: after the step of separating the generated parts that can be reused by the architecture and need to be generated by a large model based on the text requirements input by the user or the known database field structure and requirements document, and obtaining the requirements list generated based on the decoupled basic functional components and logical relationship components, the step further includes:

[0027] Generate P0 automated test cases based on the requirements list;

[0028] Generate P1 automated test cases through crawlers;

[0029] The accuracy of the generated code is corrected through multiple rounds of self-verification results.

[0030] By adopting the above technical solutions, the software can have a high quality at the early stage of development. For the generated front-end pages and table field attributes, the platform will generate test cases for the addition, deletion, modification and query of the table, providing strong support for subsequent testing work.

[0031] In a preferred example, the present application may be further configured as follows: the step of generating P0 automated test cases according to the requirements list includes:

[0032] Confirm that the requirements document has P0-level functionality;

[0033] Design test cases for each P0-level function;

[0034] Select an automated testing tool and write automated testing scripts based on the designed test cases;

[0035] Integrate the automated test scripts into the continuous integration / continuous deployment CI / CD process;

[0036] Perform automated tests regularly, monitor test results, and set up an alarm mechanism to automatically notify relevant personnel when a test fails.

[0037] By adopting the above technical solutions, test cases are designed for each P0-level function to improve test coverage and accuracy. Automated testing tools are used to write automated test scripts to reduce manual intervention and improve testing efficiency. Automated test scripts are integrated into the continuous integration / continuous deployment CI / CD process to achieve real-time detection and rapid feedback. At the same time, during regular monitoring tests, relevant personnel are automatically notified when test failures occur to ensure that problems are discovered and resolved in a timely manner.

[0038] In a preferred example, the present application may be further configured as follows: the step of generating P1 automated test cases by crawling includes:

[0039] Confirm that the requirements document contains P1-level functions and list all P1-level functions that need to be automated;

[0040] Install the library files required by the crawler, analyze the data captured by the P1 level function, and identify key elements that can be used to generate test cases;

[0041] Design test case templates based on the captured data and generate automated test scripts based on the test case templates;

[0042] Integrate the automated test scripts into the continuous integration / continuous deployment CI / CD process;

[0043] Perform automated tests regularly, monitor test results, and set up an alarm mechanism to automatically notify relevant personnel when a test fails.

[0044] By adopting the above technical solutions, the P1-level functions in the requirement documents are confirmed and the core functional points covered by the test are obtained; the accuracy and efficiency of data processing are improved by identifying key elements through crawlers; automated test scripts can greatly reduce the time and cost of manual writing; integrating automated test scripts into the continuous integration / continuous deployment CI / CD process to achieve real-time detection and rapid feedback; timely notification of relevant personnel to handle test failures can improve the quality and stability of the software.

[0045] In a second aspect, the present application provides a generative architecture decoupling function and business logic system, which adopts the following technical solutions:

[0046] A generative architecture decouples functionality and business logic systems, including:

[0047] 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;

[0048] Requirements acquisition module: used to separate the generated parts that can be reused through the architecture and generated by the large model based on the text requirements input by the user or the known database field structure and requirements documents, and obtain the requirements list generated based on the decoupled basic functional components and logical relationship components;

[0049] Business conversion module: used to parse the requirements list based on the big model and convert it into the business scenario corresponding to the software product with existing functional component combination through the big model.

[0050] In a third aspect, the present application provides an electronic device, which adopts the following technical solution:

[0051] 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, the steps of the above-mentioned generative architecture decoupling function and business logic method are implemented.

[0052] In a fourth aspect, the present application provides a computer storage medium, including the following technical solutions:

[0053] A computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the above-mentioned generative architecture decoupling function and business logic method.

[0054] In summary, this application includes at least one of the following beneficial technical effects:

[0055] 1. By decoupling the architecture into basic functional components, logical relationship components, and business processes, we effectively separate business logic from functional logic, significantly improving the maintainability and scalability of the software.

[0056] 2. Based on the large model, the system parses the text requirements or database field structure and requirement documents entered by the user, and automatically generates the corresponding basic functional components and logical relationship components, significantly reducing the workload of manual coding and improving development efficiency;

[0057] 3. Automatically generate P0 and P1 level test cases and integrate them into the continuous integration / continuous deployment (CI / CD) process, improving the quality and stability of software products and shortening the testing cycle. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] Figure 1 This is a flowchart of a method for decoupling functions and business logic using a generative architecture in one embodiment of the present application.

[0059] Figure 2 This is a flowchart of the sub-steps of step S1 in one embodiment of the present application.

[0060] Figure 3 This is a flowchart of the sub-steps of step S2 in one embodiment of the present application.

[0061] Figure 4 This is a flowchart of the sub-steps of step S20 in one embodiment of the present application.

[0062] Figure 5 This is a flowchart of the steps added after step S2 in one embodiment of the present application.

[0063] Figure 6 This is a flowchart of the sub-steps of step S21 in one embodiment of the present application.

[0064] Figure 7 This is a flowchart of the sub-steps of step S22 in one embodiment of the present application.

[0065] Figure 8 This is a structural diagram of a generative architecture decoupling function and business logic system in one embodiment of the present application.

[0066] Figure 9 It is a principle block diagram of an electronic device in one embodiment of the present application.

[0067] Figure numerals: 1. Architecture layering module; 2. Demand acquisition module; 3. Business transformation module. DETAILED DESCRIPTION

[0068] The following is combined with Figure 1-9 This application is described in further detail.

[0069] refer to Figure 1 , a generative architecture decoupling functionality and business logic approach, specifically including:

[0070] A generative architecture that decouples functionality and business logic, including:

[0071] S1. Traverse the product functions of the software on the market and decouple the architecture into basic functional components, logical relationship components and business processes.

[0072] Among them, we sort out the mainstream and common apps and websites.

[0073] After traversing these mainstream functions, the design level divides the architecture into three layers, specifically:

[0074] Basic functional components are independent of business logic and are fully universal.

[0075] The logical relationship component is related to the business, but because it can be traversed in a limited way, it achieves universality through configuration combination. 16 logical relationships that can be arbitrarily split are designed.

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

[0077] Therefore, the software architecture is transformed according to the technical capability boundaries of the large model, and a compatible transition architecture solution is provided to improve the ability to accelerate the migration from the original architecture to the new architecture.

[0078] At the same time, after the migration, due to the decoupling of functional logic from business, the efficiency and quality of developing different business logic based on the same functional logic have been effectively improved, and it is close to being completed automatically.

[0079] S2. Based on 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 architecture and require large model generation, and obtain the requirement list generated based on the decoupled basic functional components and logical relationship components.

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

[0081] Before it can be put into use, a large model of the code needs to be built, trained, and optimized.

[0082] Among them, for the construction of the code big model, the first aspect is to collect and analyze the requirements, clarify the goals and requirements of building the code big model, and conduct analysis and review, including:

[0083] First, identify all relevant stakeholders, including the development team, data scientists, product managers, and end users. Through meetings, interviews, and questionnaires, understand each party's specific requirements for the code master model. Next, categorize the collected requirements by functionality, performance, and security. Prioritize requirements based on importance and urgency to facilitate subsequent resource allocation planning. Then, invite all stakeholders to a requirements review meeting to discuss and confirm the preliminary requirements list. Record the comments and suggestions raised during the review process and document them for future reference. Based on the existing requirements analysis results, clarify the overall project goals, such as improving code generation efficiency and code quality. For each requirement, further refine the specific requirements, including but not limited to functional details, performance metrics, data requirements, and interface specifications. Use a requirements matrix to map the relationship between each requirement and the project goals to better understand the interrelationships between requirements. Finally, integrate the above analysis results into a formal requirements document, which will serve as the basis for subsequent design and coding work. As the project progresses, requirements may change, and the requirements document needs to be updated promptly to maintain its accuracy and timeliness. After the requirements document is completed, a final review meeting is held to ensure that all stakeholders have reached a consensus on the requirements. Once the requirements document is signed and approved by key decision makers, it becomes official and becomes the basis for project implementation.

[0084] Secondly, collect and clean the data required by the model to remove duplicate, erroneous, or sensitive data. Specifically,

[0085] First, refer to the previous requirements analysis document to clarify the specific data requirements. Determine the data source, type (e.g., text, code snippets), and quantity. Next, select an appropriate data source. Data can come from open source projects on platforms such as GitHub, GitLab, and Bitbucket; code datasets available on platforms such as Kaggle and Hugging Face; or internal historical code repositories and project code. Next, choose an appropriate data collection method. You can use crawlers to scrape code data from websites, access code data using the GitHub API or other code platform APIs, purchase high-quality code datasets from third-party data providers, or export code data from internal databases or file systems. Next, remove duplicate code snippets to ensure data uniqueness. Ensure all code snippets have the same format to facilitate subsequent processing. Remove unnecessary comments 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 address outliers and remove irrelevant or redundant data. Convert data from different sources to a unified, standardized format, and fill in or remove missing values ​​as needed. Furthermore, randomly sample a portion of the data for manual review to ensure data quality, and then verify the data's consistency and completeness to ensure it meets expected standards. Use small-scale datasets to test model performance and assess the impact of data quality. Next, select an appropriate storage method (such as a local hard drive or cloud storage service) based on the data volume and access frequency, and establish a data backup mechanism to prevent data loss. Set appropriate access permissions to ensure data security. Finally, carefully record information such as the source and collection date of each batch of data. Document detailed steps for data preprocessing and cleaning to facilitate subsequent maintenance and auditing.

[0086] The third aspect is to design and select the model. According to the project goals and data characteristics, choose the appropriate model architecture and design the basic structure of the model, including:

[0087] First, clarify the task types the model needs to perform, such as classification, generation, translation, and completion. Identify the specific problems the model needs to solve, such as code completion, error detection, and code generation. Second, research existing models and read relevant papers to understand the state-of-the-art models and their performance. Review open-source models on platforms like GitHub and assess their applicability. Then, select an appropriate architecture for design. For example, the Transformer-based BERT model is well-suited for natural language processing tasks and can be fine-tuned to adapt to tasks like code completion. Next, adjust the model's hyperparameters, including the learning rate, number of layers, hidden layer dimensions, and attention mechanism. Appropriately add specific modules, such as positional encoding in the self-attention mechanism, to improve the model's understanding of positional information. Then, pre-train the model on large-scale unlabeled data and fine-tune it on small-scale labeled data for specific tasks to adapt it to specific application scenarios. Finally, select appropriate evaluation metrics and use cross-validation to assess the model's generalization ability. Finally, select a suitable deployment environment, regularly monitor model performance, and promptly update the model to adapt to new situations.

[0088] During the pre-training phase, the platform uses 4M context and 7B pre-training models to deeply understand and analyze each requirement. This deep understanding ensures the platform can accurately grasp user intent and provide strong support for subsequent code generation.

[0089] Fourthly, the model's data is labeled and preprocessed to help the model better understand and process the data. Specifically, this includes:

[0090] Before data labeling, ensure that the data has been cleaned. For a small amount of high-quality data, manual labeling 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 the program, such as prefixes and suffixes in code completion tasks. Secondly, convert the text and each character into a vector representation. Then, replace synonyms or similar operations in the code to increase data diversity. Insert some random grammatical structures or logical errors in the code to train the robustness of the model. Then, extract statistical features from the code snippet, such as code length, number of variables, number of functions, etc. Use static analysis tools to extract semantic information of the code. Finally, perform data normalization to scale the numerical features to the same range, such as between 0 and 1. To make the data conform to the normal distribution, Z-score normalization is usually used.

[0091] For training a large code model, the first step is to initialize the model and set initial parameter values ​​for the newly designed model. Specifically, the following steps are required:

[0092] First, define the model architecture, including the type of neural network used, the number of layers, the activation function 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 that they meet expectations.

[0093] Secondly, divide the data set into training set, test set and validation set, and determine the data partitioning strategy and cleaning optimization strategy, including:

[0094] First, load the data into memory, for example, by storing it in a CSV file. Next, remove missing values ​​and outliers from the data. Next, split the data into training, validation, and test sets. A typical split is 80% training, 10% validation, and 10% test. Finally, perform feature processing, such as normalization and standardization, based on the model's requirements.

[0095] Third, use the training data to train the model to learn the characteristics and patterns of the code. Then adjust the training parameters based on the performance of the model, including:

[0096] First, import all necessary libraries and prepare the required data files, ensuring they are formatted correctly. Next, define a complete neural network model, setting an appropriate loss function and optimizer. Then, begin model training, logging the results of each round. Adjust training parameters based on model performance. Finally, evaluate model performance on the validation set, followed by a final test on the test set.

[0097] Fourth, monitor the model training process to promptly identify and address any problems that arise during training. Specifically,

[0098] First, import all necessary libraries to ensure the model can train properly. Next, initialize some variables to record key metrics during training. Then, train the model and record the loss at each epoch. Finally, identify and address any issues that arise during model training, such as overfitting and underfitting. Visualize the results to facilitate analysis.

[0099] For tuning large code models, the first step is to evaluate the trained model using a test set and adjust the model structure or parameters based on the evaluation results. This includes:

[0100] First, ensure that you have available test and validation sets, and load a pretrained model or the best model you've saved. Next, define evaluation metrics based on your task, such as accuracy or BLEU score. Then, evaluate the model on the validation and test sets. Finally, plot the loss curve or other visualization of the evaluation results.

[0101] Secondly, we tune the model's hyperparameters, including:

[0102] First, identify the hyperparameters that need to be tuned and their reasonable 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 training and validation functions to train the model under each hyperparameter configuration and record the validation loss. Then, save the best-performing model and its corresponding hyperparameters during training. Finally, use the test set to evaluate the model with the final selected hyperparameter configuration.

[0103] Third, regularization methods are used to prevent model overfitting and optimization algorithms are used to improve model training efficiency, including:

[0104] First, import all necessary libraries and prepare the required data files (ensuring they are formatted correctly). Next, define a complete neural network model, setting an appropriate loss function and optimizer. Then, train the model, logging the training results for each round. Adjust the training parameters based on model performance. Finally, evaluate the model performance on the validation set, followed by a final test on the test set.

[0105] The fourth aspect is to integrate and fuse the prediction results of multiple models, including:

[0106] First, multiple models are generated by selecting different model architectures or using different initialization parameters for the same architecture. Next, these models are trained separately and their weights are saved. Then, during the prediction phase, the predictions from each model are combined. Finally, the performance of the ensemble model is evaluated to ensure that it outperforms the individual models.

[0107] Fifth, continue to learn and update the model, including:

[0108] Continuously collect new data and preprocess it so the model can understand it. Next, fine-tune or continue training the model using the new data to adapt it to the characteristics of the new data. Regularly save the updated model weights for subsequent use or further training. Finally, continuously monitor the model's performance to ensure it can adapt to the new data distribution.

[0109] S3. Analyze the requirements list based on the big model and convert it into the business scenarios corresponding to the software products with existing functional component combinations through the big model.

[0110] Among them, it is necessary to use the trained large model to generate corresponding software code according to user needs, and then perform static analysis and dynamic testing on the generated code to ensure that it meets user needs and quality standards.

[0111] Static analysis and dynamic testing of 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 based on requirements:

[0112] First, to implement static analysis, you must first choose the appropriate static analysis tool based on the programming language.

[0113] Secondly, configure the analysis tool according to project requirements and set the analysis rules and scope, including:

[0114] Clarify the project requirements, including the type of code to be generated, the programming language to be used, and specific coding standards. Then, select the appropriate code generation tool based on your needs. Next, install and configure the selected static analysis tool. Run the static analysis tool on the code, review the results, and make appropriate code improvements based on the findings. Furthermore, integrate static analysis into your CI / CD process to ensure that static analysis is performed on every code commit.

[0115] Finally, use static analysis tools to analyze the code and generate an analysis report. Then, relevant personnel will read the analysis report carefully to identify potential problems in the code and fix them according to the severity and priority of the problems.

[0116] Secondly, to implement dynamic testing, we must first select the appropriate dynamic testing tool based on the programming language.

[0117] Secondly, write test cases that cover the main functions of the code according to the requirements, and ensure that the test cases can trigger the critical paths and boundary conditions in the code, including:

[0118] Identify the function or module to be tested and the primary objective of the test. Next, thoroughly understand the requirements document to determine which functions need to be tested. Clarify the function's operating principles, inputs and outputs, and boundary conditions. Then, develop specific test cases based on the test scenario.

[0119] Then, use the dynamic testing tool to run the test cases and observe the program's execution process and output results. Specifically, this includes: executing the test step by step according to the test case, recording all information during the test process, including input data, actual output, and problems encountered. Then, record the execution results of each test case and generate a test report.

[0120] Finally, based on the test results, identify problems and defects in the code and fix them, then rerun the test cases to verify the repair effects.

[0121] Thirdly, by generating automated test cases and performing multiple rounds of self-verification to correct the accuracy of the generated code, the coverage and accuracy of the generated code can be continuously improved.

[0122] Furthermore, the rendering platform automatically creates data tables based on the JSON DSL and generates corresponding front-end pages. This functionality is easily implemented by the user, significantly lowering the development barrier. Ultimately, the generated software product is deployed to the user's specified environment, and subsequent maintenance and upgrade services are provided to ensure stable operation and complete software deployment and maintenance.

[0123] The platform also includes a comprehensive workflow maintenance system, seamlessly integrating every step from requirements generation (sales) to product definition (requirements refinement), R&D (backend, frontend, testing), and delivery (operations and maintenance), ensuring smooth software development. Furthermore, the platform supports incremental iteration and responsive services, enabling continuous optimization of software performance based on user feedback.

[0124] To further improve software quality, the platform also introduces an agent mechanism, which performs multiple rounds of interaction, scheduling, and state control with the model. Through the ReACT strategy (reasoning, execution, and consistency check between results and objectives), the platform continuously optimizes generated code to ensure that the software meets user expectations.

[0125] refer to Figure 2 Furthermore, in one embodiment, step S1 is further divided into the following sub-steps:

[0126] S10. Establish a basic functional component library. Based on the inversion of control and abstract definition, express the configuration of basic functional components through DSL configuration files.

[0127] Basic functional components include building a component library, such as search, lists, page turning and page numbering, editing, and details. Building a basic functional component library and expressing it through DSL configuration files allows each basic functional component to be assembled through simple configuration, reducing the workload of manual coding and thereby improving development efficiency.

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

[0129] The platform supports modeling libraries and tables, converting these models into JSON DSL. Subsequently, combining the front-end interface, libraries and tables, and detailed user requirements (after additional details), the platform automatically generates the corresponding back-end interaction logic for the front-end interface, also expressed in JSON DSL. This step greatly simplifies the development process and improves efficiency.

[0130] At the top-level logic, a unified behavior node tree is generated, covering the behavior paths corresponding to all business processes of the user. Each node contains four dimensions: database, backend logic, page, and front-end and back-end logical relationships.

[0131] In terms of specific database and table design, a three-tier structure is used to uniformly describe the functional logic required for all businesses:

[0132] Create a base table with fields completely unrelated to the business. For example, the 11 digits starting with a mobile phone number (1) are defined. Once defined, the front-end and back-end logic are consistent in any business scenario. Similar fields include gender, age, address, and ID.

[0133] Establish three common tables for top-level business logic: user table, user behavior object table, and context table, to abstractly describe any business logic. Define the business flow as the general database state at the previous moment, and change it to the abstract state of the database at the next moment [upstream node - current node - next node].

[0134] When a requirement is input and parsed into a DSL definition of a table structure, taking the e-commerce shopping cart business requirement as an example, it is divided into the following steps:

[0135] First, select quantity, price, title, etc. from the base table as fields for the user behavior object table.

[0136] Then, select the user name, user id, etc. from the base table as the fields of the user table

[0137] Next, the context table contains user behaviors: corresponding to shopping cart behaviors such as adding, deleting, changing quantity, and checking out, and the input and output mapping translation of common behaviors such as adding, deleting, changing, and confirming in the shopping cart scenario. Simply convert the DSL configuration after the requirements definition into the business logic for the shopping cart scenario.

[0138] For example, adding to a shopping cart is to configure the general "add" behavior and its upstream node to depend on the logged-in user. The current node is the shopping cart list, and the next node is to add a new item to the shopping cart list.

[0139] Finally, by assembling the top-level business logic behavior nodes, each node contains [upstream node, current node, downstream node], the entire tree can be spliced ​​together to form the correct dependency and business flow logic.

[0140] The business flow logic is assembled from 16 common logical relationship components across seven categories: verification logic (whether the actor and resource exist, whether the current actor has permission), horizontal lists without strong logical flow (parallel relationships, explanatory relationships, progressive relationships, sequential relationships, and comparative relationships), judgment branches (verification logic for single cause and effect, complex multi-branch logic with multiple / one cause and multiple / one effect), hierarchical relationships (including nested logic and inductive relationships), loop relationships, mapping relationships, and decision logic. In one embodiment, the configuration of the logical relationship components is expressed as follows:

[0141] logic_type: logic type, one of 16 types;

[0142] logic_exp: such as a&b | c;

[0143] __logic_exec Generic expansion execution logic for logical expressions.

[0144] In addition, the design logic relationship is universal, that is, based on the functional logic, typical application scenarios can be assembled from the finest granularity to the logical relationship and then to the business logic relationship to traverse it, so that the functions and logical components below the business layer are guaranteed to be universal.

[0145] Converting logical relationship components into JSON DSL format facilitates flexible assembly of business flow logic, further enhances flexibility and adaptability, and reduces modification costs due to changing requirements.

[0146] In addition, reference Figure 3 Furthermore, in one embodiment, step S2 is further divided into the following sub-steps:

[0147] S20. Receive the text requirement input by the user and convert the text requirement into a JSON DSL configuration. If the received requirement is a non-text requirement, the non-text requirement is processed through multimodal joint processing and the object token is converted into a token corresponding to the text requirement through the Qformer multimodal compatible network structure.

[0148] Specifically, the platform first receives textual requirements entered by users and, after internal processing, converts them 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.

[0149] In one embodiment, after a user enters a textual requirement, the first step is to thoroughly understand the scenarios, essential elements, and related domain information contained in the page requirements, component requirements, and user requirements. Next, the meaning of each field value in the tag file is understood. The tag file value is an interpretation of the key, and the meaning of the key is the same as in the subsequent configuration file. Then, based on the interpretation of the field in the tag, the corresponding field value in the configuration is modified to meet the requirements (including matching the text content, color, etc.). Finally, the modified configuration JSON is output.

[0150] The platform also supports different types of input data. For example, if the input type is pictures and / or videos, it is first converted into tokens corresponding to text requirements to achieve data unification and standardization. This not only improves the diversity and accuracy of demand collection, but also enables various forms of user input requirements to be effectively parsed and utilized, thereby enhancing the system's adaptability and flexibility, improving the efficiency and quality of demand processing, and enhancing the decoupling effect of business logic and functional logic.

[0151] In addition, reference Figure 4 Furthermore, in one embodiment, step S20 is further divided into the following sub-steps:

[0152] S200: Constructing a prompt project format, transforming the text requirements input by the user or the known database field structure and requirement document into a formatted prompt project description, outputting a configuration definition file of the DSL definer, and reformatting the file in a regular format, including:

[0153] Verify the JSON format. Specifically, DSL uses a special JSON format. If the JSON format is correct, the result passes. If it is incorrect, locate the error area, such as the number of matches for special syntax symbols, such as curly braces {}, single quotes, and double quotes. Verify that they match exactly. Then, attempt to fix the problem and retry three times. This reduces the risk of subsequent processing failures caused by format errors in the generated configuration file.

[0154] 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, so that the database field maintains consistency and accuracy and can run after configuration.

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

[0156] Record missing key and value values ​​and fill in the default values ​​to make the generated configuration file more complete, reduce the need for manual intervention, and improve the level of automation.

[0157] In addition, reference Figure 5 Furthermore, in one embodiment, after step S2, steps S21, S22, and S23 are added:

[0158] S21. Generate P0 automated test cases based on the requirements list.

[0159] Specifically, the platform supports generating P0 test cases and UI interfaces (static) based on the required JSON DSL. Combining the database table structure and required details, the platform can generate complete backend logic, and continuously complete the details desired by users through multiple rounds of interaction, and verify and ensure code quality.

[0160] S22. Generate P1 automated test cases through crawlers.

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

[0162] Specifically, we first conduct the first round of verification, which involves preliminary running and testing the generated code. This includes:

[0163] Check the input data to ensure it conforms to the expected format and requirements. Next, verify logical consistency to ensure consistency and logical relationships between the input data. Then, perform basic functional testing to ensure that basic functions are functioning properly. Furthermore, check dependencies to ensure that all dependencies are correctly installed and configured. Finally, record any issues and error messages found during this first round of verification for subsequent processing and debugging.

[0164] After fixing any issues in the first round of validation, perform a second round of validation and repeat the process until the code performs stably and accurately across multiple validations.

[0165] Then, external validation was introduced to further confirm the accuracy and reliability of the code, including:

[0166] Use static code analysis tools, introduce unit testing frameworks, and use continuous integration / continuous deployment (CI / CD) tools. Also introduce third-party services for API verification and integrate third-party libraries or tools.

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

[0168] Through the above steps, the platform will generate test cases for the generated front-end pages and table field attributes, providing strong support for subsequent testing. Ultimately, automated testing will be triggered every time the code is submitted, making the final code generation more accurate.

[0169] In addition, reference Figure 6 Furthermore, in one embodiment, step S21 is further divided into the following sub-steps:

[0170] S210. Confirm the P0 level functions of the requirement document.

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

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

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

[0174] S212. Select an automated testing tool and write an automated testing script based on the designed test cases.

[0175] Specifically, select automated testing tools based on the project's technology stack and team familiarity, and write automated testing scripts to ensure that the scripts can cover all critical paths and boundary conditions.

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

[0177] Specifically, the goal of triggering automated testing every time a code is submitted is achieved.

[0178] S214. Regularly perform automated testing, monitor test results, and set up an alarm mechanism to automatically notify relevant personnel when a test fails.

[0179] In addition, reference Figure 7 Furthermore, in one embodiment, step S22 is further divided into the following sub-steps:

[0180] S220. Confirm the P1-level functions in the requirement document and list all P1-level functions that need to be automated.

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

[0182] Specifically, by identifying key elements through crawlers, the accuracy and efficiency of data processing are improved; automated test scripts can greatly reduce the time and cost of manual writing.

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

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

[0185] Specifically, the goal of triggering automated testing every time a code is submitted is achieved.

[0186] S224. Regularly perform automated testing, monitor test results, and set up an alarm mechanism to automatically notify relevant personnel when a test fails.

[0187] It should be understood that the size of the serial numbers of the steps in the above embodiments does 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 on the implementation process of the embodiments of this application.

[0188] The embodiment of the present application also provides a generative architecture decoupling function and a business logic system, which have a one-to-one correspondence with the generative architecture decoupling function and the business logic method in the embodiment.

[0189] refer to Figure 8 A generative architecture decoupling function and business logic system includes: architecture layering module 1, demand acquisition module 2, and business transformation module 3. The detailed description of each functional module is as follows:

[0190] 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;

[0191] Requirements Acquisition Module 2: Used to separate the generated parts that can be reused through architecture and require large-scale model generation based on the text requirements input by the user or the known database field structure and requirements documents, and obtain the requirements list generated based on the decoupled basic functional components and logical relationship components;

[0192] Business transformation module 3: used to parse the requirements list based on the big model and transform it into the business scenario corresponding to the software product with existing functional component combinations through the big model.

[0193] The Architecture Layering Module 1 traverses the functionality of existing software products on the market and decouples them into basic functional components, logical relationship components, and business processes. The Requirements Acquisition Module 2 allows users to input text requirements or leverage known database field structures and requirements documents to automatically separate reusable basic functional components from those requiring large-scale model generation, thereby automatically generating a detailed requirements list. The Business Transformation Module 3 parses the requirements list based on the large-scale model and translates the results into specific business scenarios based on existing functional component combinations. Through the integration of these modules, the effective separation of business logic and functional logic is achieved, leading to a highly automated design process. This significantly shortens the development cycle from requirements to product, reduces the likelihood of human error, and improves development quality and efficiency.

[0194] For the specific definition of the generative architecture decoupling function and the business logic system, please refer to the definition of the generative architecture decoupling function and the business logic method in the context, which will not be repeated here. The modules 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 combination. The above-mentioned modules can be embedded in or independent of the processor in the electronic device in the form of hardware, or can be stored in the memory of the electronic device in the form of software, so that the processor can call and execute the operations corresponding to the above modules. In one embodiment, an electronic device is provided, which is a user terminal. Reference Figure 9 , the electronic device includes a processor, a memory, a network interface and a database connected through a system bus. 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 a detection data table. The network interface of the electronic device is used to communicate with an external terminal through a network connection. When the computer program is executed by the processor, a generative architecture decoupling function and business logic method is implemented.

[0195] In one embodiment, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, the following steps are performed:

[0196] S1. Traverse the product functions of the software on the market and decouple the architecture into basic functional components, logical relationship components and business processes.

[0197] S2. Based on 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 architecture and require large model generation, and obtain the requirement list generated based on the decoupled basic functional components and logical relationship components.

[0198] S3. Analyze the requirements list based on the big model and convert it into the business scenarios corresponding to the software products with existing functional component combinations through the big model.

[0199] In one embodiment, the sub-steps of step S1 include:

[0200] S10. Establish a basic functional component library. Based on the inversion of control and abstract definition, express the configuration of basic functional components through DSL configuration files.

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

[0202] In one embodiment, the sub-steps of step S2 include:

[0203] S20. Receive the text requirement input by the user and convert the text requirement into a JSON DSL configuration. If the received requirement is a non-text requirement, the non-text requirement is processed through multimodal joint processing and the object token is converted into a token corresponding to the text requirement through the Qformer multimodal compatible network structure.

[0204] In one embodiment, the detailed sub-steps of step S20 include:

[0205] S200: Constructing a prompt project format, transforming the text requirements input by the user or the known database field structure and requirement document into a formatted prompt project description, outputting a configuration definition file of the DSL definer, and reformatting the file in a regular format, including:

[0206] Verify the JSON format.

[0207] 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.

[0208] If the format verification still fails or does not work properly, perform regular expression matching, extract and verify all key fields and values ​​in the JSON format, and fill the correct KV into the new DSL JSON format.

[0209] Record missing key and value values ​​and fill them with default values.

[0210] In one embodiment, the steps added after step S2 include:

[0211] S21. Generate P0 automated test cases based on the requirements list.

[0212] S22. Generate P1 automated test cases through crawlers.

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

[0214] In one embodiment, the sub-steps of step S21 include:

[0215] S210. Confirm the P0 level functions of the requirement document.

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

[0217] S212. Select an automated testing tool and write an automated testing script based on the designed test cases.

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

[0219] S214. Regularly perform automated testing, monitor test results, and set up an alarm mechanism to automatically notify relevant personnel when a test fails.

[0220] In one embodiment, the sub-steps of step S22 include:

[0221] S220. Confirm the P1-level functions in the requirement document and list all P1-level functions that need to be automated.

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

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

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

[0225] S224. Regularly perform automated testing, monitor test results, and set up an alarm mechanism to automatically notify relevant personnel when a test fails.

[0226] Those skilled in the art will appreciate that all or part of the processes in the above-described method embodiments can be implemented by instructing the relevant hardware through a computer program. The computer program can be stored in a non-volatile computer-readable storage medium. When executed, the computer program can include the processes of the above-described method embodiments. Any reference to memory, storage, database, or other media used in the various embodiments provided herein may include non-volatile and / or volatile memory. Non-volatile memory may include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory may 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 (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), RAMbus direct RAM (RDRAM), direct RAMbus dynamic RAM (DRDRAM), and RAMbus dynamic RAM (RDRAM).

[0227] Those skilled in the art will clearly understand that for the sake of convenience and brevity of description, only the division of the above-mentioned functional units and modules is used as an example. In actual applications, the above-mentioned functions can be distributed and completed by different functional units and modules as needed, 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 by: include: We traversed the product functions of software available on the market and decoupled the architecture into basic functional components, logical relationship components, and business processes. This included: establishing a basic functional component library, expressing the configuration of these basic functional components through DSL configuration files based on inversion of control and abstract definition; establishing a logical relationship component library, converting it into JSON DSL format, and assembling the business flow logic; Based on the text requirements input by the user or the known database field structure and requirement documents, the generated parts that can be reused through the architecture and need to be generated by the large model are separated, and a requirement list generated based on the decoupled basic functional components and logical relationship components is obtained. This includes: building a prompt project format, interacting with the text requirements input by the user or the known database field structure and requirement documents through the formatted prompt project description, outputting the configuration definition file of the DSL definer, and reformatting 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 verification still fails or does not work properly, perform regular expression matching, extract and verify all key fields and value values ​​in the JSON format, and then fill the correct key fields and value values ​​into the new JSON DSL format. Record missing key fields and value values, and fill in the default values; 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 After the steps of separating the generated parts that can be reused through the architecture and require large-scale model generation based on the text requirements input by the user or the known database field structure and requirements document, and obtaining the requirements 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.

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

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

5. A generative architecture decouples functions and business logic systems, characterized by: 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, including: establishing a basic functional component library, expressing the configuration of the basic functional components through DSL configuration files based on control inversion and abstract definition; establishing a logical relationship component library and converting it into JSON DSL format to assemble business flow logic; Requirements acquisition module (2): used to separate the generated parts that can be reused by the architecture and generated by the large model based on the text requirements input by the user or the known database field structure and requirement documents, and obtain the requirements list generated based on the decoupled basic functional components and logical relationship components, including: building a prompt project format, interacting with the text requirements input by the user or the known database field structure and requirement documents through the formatted prompt project description, outputting the configuration definition file of the DSL definer, and reformatting the 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 verification still fails or does not work properly, perform regular expression matching, extract and verify all key fields and value values ​​in the JSON format, and then fill the correct key fields and value values ​​into the new JSON DSL format. Record missing key fields and value values, and fill in the default values; Business transformation module (3): used to parse the requirements list based on the big model and transform the requirements list into a business scenario corresponding to the software product with the existing functional component combination through the big model.

6. An electronic device, characterized in that: The invention comprises a memory and a processor, wherein the memory stores a computer program that 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 4.

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

Images