A method, device and electronic equipment for information system specification programming

Abstract

The application discloses a kind of information system standardization programming method, device and electronic equipment.The method comprises the following steps: step S1, requirement analysis;Step S2, specific specification conversion;Step S3, subfield code generation;Step S4, subfield code test;Step S5, field code generation;Step S6, field code test.The application realizes the full-link standardization and automatic development from requirement to operation by meta-specification driving, closed-loop verification and runtime intelligent repair, effectively solves the technical problems, such as requirement-implementation fault, specification loss, high artificial dependence and abnormal response lag, in traditional information system development, and significantly improves development efficiency, system reliability and maintainability.

Description

Technical Field

[0001] This invention relates to standardized programming of information systems, and in particular to a method, apparatus and electronic device for standardized programming of information systems. Background Technology

[0002] Traditional information system development typically employs a linear process of requirements analysis, design, coding, testing, and deployment. This process heavily relies on human experience, and in scenarios with vague requirements, lack of specifications, or frequent changes, it is highly susceptible to implementation deviations, logical flaws, and maintenance difficulties. Although low-code / no-code platforms and domain-specific languages ​​(DSLs) have alleviated the burden of manual coding to some extent in recent years, they still struggle to handle complex business logic and lack unified specifications, resulting in insufficient maintainability and consistency of the generated code.

[0003] Current technologies attempt to incorporate Natural Language Processing (NLP) or Large Language Modeling (LLM) to assist in requirement understanding and code generation. For example, some studies use LLM to directly convert user natural language requirements into code snippets. However, such methods generally suffer from semantic distortion, loose structure, and lack of validation loops, resulting in unexecutable or severely deviated from the original intent. Furthermore, existing systems generally lack explicit modeling of the specification layer, failing to ensure strict alignment between the generated code and business requirements at the semantic, structural, and behavioral levels.

[0004] On the other hand, although some tools introduce formal verification or static analysis to ensure code quality, they are usually applied in the later stages of development and are unlikely to detect design flaws during the specification phase. At the same time, runtime exception handling still relies mainly on manual intervention and lacks automatic repair capabilities based on log semantic understanding and context awareness, resulting in limited system availability and high maintenance costs. Summary of the Invention

[0005] To address the above problems, the present invention provides a method, apparatus, and electronic device for standardized programming of information systems.

[0006] The purpose of this invention is to provide a method for standardized programming of information systems. Through structured requirement analysis, LLM specification generation under meta-specification constraints, triple verification mechanism, AI Agent code generation, closed-loop testing, and runtime intelligent monitoring and repair, an end-to-end automated development pipeline from requirements to deployment and maintenance is formed, solving problems such as inaccurate understanding of requirements, lack of specifications, uncontrollable code quality, and delayed abnormal response in existing technologies.

[0007] This invention provides the following technical solution: a method for standardized programming of an information system, comprising the following steps:

[0008] Step S1: Receive the original requirements submitted by the user, parse the original requirements and generate several user stories;

[0009] Step S2: Under the constraints of the meta-specification, several user stories are converted into several subdomain-specific specifications to guide the generation of code in their respective subdomains and a domain-specific specification to guide the generation of event codes between subdomains through the large language model;

[0010] Step S3: Based on the specific specifications of several sub-domains, generate corresponding specific codes for several sub-domains through the code generation model. The specific codes for sub-domains include: specific codes for sub-domain entities, attributes, entity relationships, specific codes for sub-domain services, and corresponding test case codes.

[0011] Step S4: Test the specific code of the subdomain and obtain the specific code of the subdomain that has passed the test;

[0012] Step S5: Based on the specific domain specifications and several subdomain specific codes that have passed testing, generate specific domain code through the code generation model. The specific domain code includes: event code between subdomains and corresponding test case code.

[0013] Step S6: Test the test case code to obtain the domain-specific code after the test passes.

[0014] Furthermore, step S1 specifically includes:

[0015] (1) Receive the user's original request in natural language or in file format;

[0016] (2) Call the large language model to parse the original requirements into user stories, which include roles, activities and business value.

[0017] Furthermore, step S2 specifically includes:

[0018] (1) Using a large language model, several user stories are divided into several sub-domain user story sets and one domain user story set according to similarity / relevance;

[0019] (2) Load the predefined meta-specifications to provide format and semantic constraints for subsequent conversions; the meta-specifications include: subdomain model structure, service and event composition, rule and constraint writing format, and test case description template;

[0020] (3) Under the constraints of the meta-specification, several sub-domain user story sets and one domain user story set are transformed into several sub-domain specific specifications and one domain specific specification through the large language model;

[0021] The specific specifications for a subdomain include: the definition and constraints of subdomain entities, attributes, and entity relationships; the description of subdomain services; and the description of test cases corresponding to subdomain services.

[0022] The domain-specific specifications include: event descriptions between subdomains, and corresponding test case descriptions for events between subdomains.

[0023] Further, step S4 specifically involves: executing all test case code corresponding to the specific code in several subdomains, and collecting all test results corresponding to the several subdomains;

[0024] If all test results for a subdomain are normal, the specific code output for that subdomain will be the specific code of the subdomain that passed the test.

[0025] If an anomaly occurs in the test results corresponding to the subdomain, the faulty test case is located, the specific code of the subdomain is repaired by generating a large model, and all test case code is re-executed until all test results corresponding to the subdomain are without anomalies. The output is the specific code of the subdomain that has passed the test.

[0026] Further, step S6 specifically involves: executing all test case code in the domain-specific code and collecting all test results;

[0027] If all test results are normal, the domain-specific code output will be the domain-specific code that passed the test.

[0028] If an anomaly is found in the test results, the faulty test case is located, the domain-specific code is repaired by generating a large model, and all test case code is re-executed until all test results are without anomalies. The output is the domain-specific code that has passed the test.

[0029] Furthermore, it also includes:

[0030] Step S7: Package the tested subdomain code and the tested domain code into deployable code and push it to the deployment environment to complete deployment and run, and collect runtime log files;

[0031] Step S8: Anomaly Repair. The large model analyzes and collects runtime log files, automatically repairs anomalies when they are found, and generates repair patches to resolve the anomalies.

[0032] An apparatus for standardized programming of an information system, comprising:

[0033] The parsing module is used to receive the original requirements submitted by users, parse the original requirements, and generate several user stories.

[0034] The transformation module is used to transform several user stories into several subdomain-specific specifications that guide the generation of code in their respective subdomains and a domain-specific specification that guides the generation of event code between subdomains, under the constraints of the meta-specific specification and through the large language model.

[0035] The first generation module is used to generate specific code for several sub-domains based on specific specifications of several sub-domains and through a large code generation model. The specific code for sub-domains includes: specific code for sub-domain entities, attributes, entity relationships, specific code for sub-domain services, and corresponding test case code.

[0036] The first testing module is used to test the specific code of the subdomain and obtain the specific code of the subdomain that has passed the test.

[0037] The second generation module is used to generate domain-specific code based on the domain-specific specifications and several tested subdomain-specific codes through a code generation model. The domain-specific code includes: event code between subdomains and corresponding test case code.

[0038] The second testing module is used to test the test case code and obtain the specific domain code after the test passes.

[0039] An electronic device, comprising:

[0040] One or more processors;

[0041] Memory, used to store one or more programs;

[0042] When the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0043] A computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of the method described above.

[0044] The beneficial effects of this invention are as follows:

[0045] This invention achieves standardized and automated development across the entire chain from requirements to operation and maintenance through meta-specification-driven, closed-loop verification, and runtime intelligent repair. It effectively solves technical problems in traditional information system development, such as the gap between requirements and implementation, lack of specifications, high dependence on manual intervention, and delayed response to anomalies, and significantly improves development efficiency, system reliability, and maintainability. Attached Figure Description

[0046] Figure 1 This is a flowchart illustrating a method for standardized programming of an information system according to the present invention;

[0047] Figure 2This is a module diagram of an information system standardization programming device according to the present invention. Detailed Implementation

[0048] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0049] This invention achieves standardized and automated development across the entire chain from requirements to operation and maintenance through meta-specification-driven, closed-loop verification, and runtime intelligent repair. It effectively solves technical problems in traditional information system development, such as the gap between requirements and implementation, lack of specifications, high dependence on manual intervention, and delayed response to anomalies, and significantly improves development efficiency, system reliability, and maintainability.

[0050] The embodiments of the present invention will be further described below with reference to several examples.

[0051] Example 1

[0052] This example requires generating a complete piece of project code based on user needs. Specifically, the user needs to generate an online e-commerce management system.

[0053] A method for standardized programming of information systems includes the following steps:

[0054] Step S1: Requirements Analysis

[0055] Receive the original requirements submitted by users, parse the original requirements and generate several user stories;

[0056] Step S1 is as follows:

[0057] (1) Receive the user's original request in natural language or in file format;

[0058] (2) Call the large language model to parse the original requirements into user stories, which include roles, activities and business value.

[0059] In this embodiment, the DeepSeek-R1 model is used to generate user stories with the prompt: "Please extract the user stories corresponding to the input requirements document. The user stories include roles, activities, and business value. The user story template is: As… (role), I want… (activity) in order to… (business value). Please strictly follow the user story template to generate the stories, and ensure that the extracted user stories fully cover the content of the requirements document."

[0060] In this embodiment, the role of user stories is to transform the vague and scattered business demands in the original requirements into a series of standardized, clearly defined, and directly executable and deliverable units for the development team. Through a three-part structure of "role-activity-business value," it forcibly clarifies the origin and development of requirements, ensuring that each functional point is directly associated with a specific user role and measurable business objectives, thereby establishing a clear and traceable value alignment channel between requirements and development. In this embodiment, the user stories extracted from user requirements are as follows:

[0061] "As an administrator, I want to update the types and quantities of products in the backend in real time so that I can flexibly adjust the product structure of the mall, quickly respond to market demand or inventory changes, and thus improve operational efficiency and sales accuracy."

[0062] As a buyer, I want to add items to my cart and generate an order with one click so that I can quickly complete the payment process and save shopping time.

[0063] As a system, I want to automatically reduce the inventory of the corresponding product when an order is generated in order to prevent the same product from being sold repeatedly and to ensure the consistency of inventory data.

[0064] As a buyer, I would like to cancel my order free of charge within 30 minutes of payment to correct any mistakes or change my purchase intentions and reduce the risk of making a purchase.

[0065] As a system, I want to automatically increase the inventory of the corresponding products after an order is cancelled, so that the products can be sold again and the inventory turnover rate can be improved.

[0066] As a buyer, I want to view my order history to quickly find items I want to repurchase.

[0067] In some embodiments, the original requirements can also be parsed into user journey maps, workshops, or tasks to obtain a clear, structured description of business requirements.

[0068] Step S2: Specific Specification Conversion

[0069] Under the constraints of the meta-specification, several user stories are transformed into several subdomain-specific specifications to guide the generation of code in their respective subdomains and a domain-specific specification to guide the generation of event code between subdomains through a large language model;

[0070] Step S2 is as follows:

[0071] (1) Using a large language model, several user stories are divided into several sub-domain user story sets and one domain user story set according to similarity / relevance;

[0072] (2) Load the predefined meta-specifications to provide format and semantic constraints for subsequent conversions; the meta-specifications include: subdomain model structure, service and event composition, rule and constraint writing format, and test case description template;

[0073] (3) Under the constraints of the meta-specification, several sub-domain user story sets and one domain user story set are transformed into several sub-domain specific specifications and one domain specific specification through the large language model;

[0074] The specific specifications for a subdomain include: the definition and constraints of subdomain entities, attributes, and entity relationships; the description of subdomain services; and the description of test cases corresponding to subdomain services.

[0075] The domain-specific specifications include: event descriptions between subdomains, and corresponding test case descriptions for events between subdomains.

[0076] In this embodiment, a subdomain user story set refers to a set of user stories that can be fully implemented by an independent subdomain, where all operations revolve around data entities within the same subdomain, without requiring intervention from other subdomains in the business logic. For example, in a meeting management system, the addition and deletion of meeting room entities are entirely implemented independently by the meeting room management subdomain. A domain user story set refers to a set of user stories that require collaboration from multiple subdomains to complete. This typically manifests as an operation triggering or depending on state changes of entities within multiple different subdomains, reflecting cross-module business processes. For example, in a meeting management system, if a meeting data entity is created, the "availability status" attribute of the meeting room entity it uses will change.

[0077] In this embodiment, the user is prompted with the message, "Based on the user stories I provide, please divide them into several sub-domain user story sets according to their similarity / relevance. These user stories should be fully implementable by a single sub-domain; for user stories that cannot be implemented by a single sub-domain, they should be divided into a domain user story set." The DeepSeek-R1 model then generates several sub-domain user story sets and one domain user story set. In this embodiment, the generated result is:

[0078] "User Stories Collection in the Order Sub-domain:"

[0079] As a buyer, I want to view my order history so I can quickly find items I want to repurchase.

[0080] As a buyer, I want to add items to my cart and generate an order with one click so that I can quickly complete the payment process and save shopping time.

[0081] As a buyer, I would like to cancel my order free of charge within 30 minutes of payment to correct any mistakes or change my purchase intentions and reduce the risk of making a purchase.

[0082] User stories in the product inventory subdomain:

[0083] As an administrator, I want to update the types and quantities of products in the backend in real time so that I can flexibly adjust the product structure of the online store, quickly respond to market demands or inventory changes, and thus improve operational efficiency and sales accuracy.

[0084] A collection of user stories from the online marketplace sector:

[0085] As a system, I want to automatically reduce the inventory of the corresponding product when an order is generated in order to prevent the same product from being sold repeatedly and to ensure the consistency of inventory data.

[0086] As a system, I want to automatically increase the inventory of the corresponding products after an order is cancelled, so that the products become available for sale again and improve inventory turnover.

[0087] A meta-specification is a higher-level specification or framework used to define, describe, generate, or constrain other specific specifications. In this embodiment, the meta-specification consists of four parts: the subdomain model structure, the composition of services and events, the rule and constraint writing format, and the test case description template. In this embodiment, the subdomain model structure adopts the layered modeling paradigm of Domain-Driven Design (DDD), clearly distinguishing between entities, value objects, and domain services to ensure cohesive domain logic and decoupling from the technical infrastructure. The service and event composition adopts the command-event separation pattern to ensure behavior encapsulation and asynchronous collaboration. The rule and constraint writing format must be structured. The test case description template uses a Given-When-Then template to explicitly cover business rules and expected events.

[0088] In this embodiment, the meta-specification and several previously generated sub-domain user story sets and one domain user story set are input into the Deepseek-r1 model. The model is prompted with the following: "Please use the meta-specification as a guiding document for generating sub-domain specific specifications and domain specific specifications. Convert different sub-domain user story sets into corresponding sub-domain specific specifications. The sub-domain specific specifications should include: definitions and constraints of sub-domain entities, attributes, and entity relationships; descriptions of sub-domain services; and descriptions of test cases corresponding to sub-domain services. Then, convert the domain user story sets into domain specific specifications. The domain specific specifications should include: descriptions of events between sub-domains; and descriptions of test cases corresponding to events between sub-domains." The input is analyzed to obtain several sub-domain specific specifications and one domain specific specification, such as "Order Sub-domain Specific Specification" and "Online Mall Domain Specific Specification." The "Order Sub-domain Specific Specification" contains the "Order" sub-domain entity, which includes attributes such as "Order Number," "Creation Time," "Current Status," and "Order Amount." The "Order Sub-domain Specific Specification" also includes the "Create Order" sub-domain service and the "Test Create Order" test case description.

[0089] Step S3: Subdomain code generation

[0090] Based on specific specifications of several subdomains, corresponding specific code for several subdomains is generated through a large code generation model. The specific code for subdomains includes: specific code for subdomain entities, attributes, entity relationships, specific code for subdomain services, and corresponding test case code.

[0091] In this embodiment, several subdomain-specific Python codes are generated using deepseek-coder-v2. These subdomain-specific Python codes should fully define the subdomain entities, attributes, and entity relationships contained in the corresponding subdomain specification. For example, the "Order" subdomain entity in the "Order Subdomain Specification" has attributes such as "Order Number," "Creation Time," "Current Status," "Order Amount," and "Item Number." The Python code fully defines the "Order" class, which has attributes such as "order_id," "created_time," "status," "total_amount," and "item_id." The subdomain-specific code should also fully implement the descriptions of the subdomain services and corresponding test cases contained in the corresponding subdomain specification. For example, the "Order Subdomain Specification" contains the "Create Order" subdomain service and the "Test Create Order" test case description. The order subdomain-specific code contains the "create_order()" method definition and the "test_create_order()" test case code, which respectively fully implement the "Create Order" service and the "Test Create Order" test case.

[0092] Step S4: Subdomain code testing

[0093] Test the specific code of the subdomain and obtain the specific code of the subdomain that has passed the test;

[0094] Step S4 specifically involves: executing all test case code corresponding to the specific code in several subdomains, and collecting all test results corresponding to the several subdomains;

[0095] If all test results for a subdomain are normal, the specific code output for that subdomain will be the specific code of the subdomain that passed the test.

[0096] If an anomaly occurs in the test results corresponding to the subdomain, the faulty test case is located, the specific code of the subdomain is repaired by generating a large model, and all test case code is re-executed until all test results corresponding to the subdomain are without anomalies. The output is the specific code of the subdomain that has passed the test.

[0097] In this embodiment, all test cases corresponding to the specific code in several subdomains are run one by one. When an error occurs in a certain test case, the error message and all the corresponding specific code in the subdomain are input into the deepseek-coder-v2 model. The prompt message is "Please analyze the cause and location of the error based on the error message and related code, and fix the relevant code." This prompts the model to fix all the corresponding specific code in the subdomain, including modifications to the test case code. Then, all test cases are re-executed. For example, when running the test method "test_create_order()" in the order subdomain code, the error message "AttributeError: 'Order' object has noattribute 'orderid'" occurs. The error message and the specific code in the order subdomain are then input into the deepseek-coder-v2 model. The model analyzes the cause and finds that the test method "test_create_order()" has an error, and then fixes the relevant code in the test method "test_create_order()". If all test results for a subdomain are normal, then the specific code for that subdomain will be output as the subdomain code that has passed the test. Ultimately, all subdomain code should be implemented. For example, the specific code for the order subdomain and the specific code for the product inventory subdomain should both be the subdomain code that has passed the test.

[0098] Step S5: Domain Code Generation

[0099] Based on the specific domain specifications and several subdomain specific codes that have passed testing, the specific domain code is generated through a large code generation model. The specific domain code includes: event code between subdomains and corresponding test case code.

[0100] In this embodiment, the input domain-specific specification and all tested subdomain-specific code are used to generate domain-specific Python code using deepseek-coder-v2. This domain-specific Python code should fully implement the event descriptions between subdomains contained in the domain-specific specification, with corresponding test case descriptions for each event. For example, the "Online Mall Domain-Specific Specification" includes the event "Purchase Success: When an order is created and successfully purchased, the purchased product inventory should decrease accordingly, involving the order subdomain and the product inventory subdomain," along with corresponding test case descriptions. The online mall domain-specific code contains the "order_success()" method definition and the "test_order_success()" test case code. These two methods fully implement the subdomain event "Purchase Success" and its corresponding test case.

[0101] Step S6: Domain Code Testing

[0102] Test the test case code to obtain the specific domain code after the test passes.

[0103] Step S6 specifically involves: executing all test case code in the domain-specific code and collecting all test results;

[0104] If all test results are normal, the domain-specific code output will be the domain-specific code that passed the test.

[0105] If an anomaly is found in the test results, the faulty test case is located, the domain-specific code is repaired by generating a large model, and all test case code is re-executed until all test results are without anomalies. The output is the domain-specific code that has passed the test.

[0106] In this embodiment, test cases contained in the domain-specific code are run one by one. When an error occurs in a test case, the error message, the test case code that caused the error, the event code between the corresponding subdomains, and all relevant subdomain-specific code are input into the deepseek-coder-v2 model. The model is prompted with the message, "Based on the error message and related code, analyze the cause and location of the error, and repair the relevant code. Note: Do not modify the subdomain-specific code, only modify the domain-specific code." This prompts the model to repair the domain-specific code, including modifications to the test case code. Then, all test cases are re-executed. For example, when running the test method "test_order_success()" in the online store domain-specific code, the error message "AttributeError: InventoryQueryError: Cannot resolve identifier mapping" occurs. The error message and code are then input into the deepseek-coder-v2 model. The model analyzes the cause and finds that the mapping error is due to different naming conventions for the product ID attribute between the order subdomain code and the product inventory subdomain code. The model then repairs the relevant code, enabling successful mapping between the two subdomains. If all test results are normal, the output will be the specific code of the domain that passed the test.

[0107] Also includes:

[0108] Step S7: Code Deployment and Log Acquisition

[0109] Package the tested subdomain code and the tested domain code into deployable code and push it to the deployment environment to complete deployment and run, and collect runtime log files;

[0110] In this embodiment, Docker container technology is used to encapsulate the tested subdomain code, the tested domain code, and the third-party libraries, runtime environment, and system dependencies required for their operation, generating a standardized, deployable container image. This image is then pushed to the deployment environment via an image repository. In this embodiment, the deployment environment is a cloud server environment based on the Linux operating system. The corresponding service instance is started using container execution instructions, enabling the system to enter a running state capable of providing functional services and collecting log files generated during system operation.

[0111] Step S8: Runtime Monitoring and Automatic Repair

[0112] The system analyzes and collects runtime log files for anomaly repair, automatically repairs anomalies when they are detected, and generates repair patches to resolve the anomalies.

[0113] In this embodiment, the collected log files are input into the deepseek-coder-v2 model. The prompt message is "Please analyze the contents of the runtime log files to determine if there are any anomalies. If there are anomalies in the log files, automatically analyze the cause of the anomalies and generate a patch code." The patch code generated by the model is then added to the deployable code and the service is restarted.

[0114] Example 2

[0115] An apparatus for standardized programming of an information system, comprising:

[0116] Parsing module 1 is used to receive the original requirements submitted by users, parse the original requirements, and generate several user stories;

[0117] Transformation module 2 is used to transform several user stories into several subdomain-specific specifications that guide the generation of code in their respective subdomains and a domain-specific specification that guides the generation of event code between subdomains, under the constraints of the meta-specific specification and through the large language model.

[0118] The first generation module 3 is used to generate corresponding specific code for several sub-domains based on specific specifications of several sub-domains and through a large code generation model. The specific code for the sub-domains includes: specific code for sub-domain entities, attributes, entity relationships, specific code for sub-domain services, and corresponding test case code.

[0119] The first test module 4 is used to test the specific code of the subdomain and obtain the specific code of the subdomain that has passed the test.

[0120] The second generation module 5 is used to generate domain-specific code based on the domain-specific specification and several tested subdomain-specific codes through a code generation model. The domain-specific code includes: event code between subdomains and corresponding test case code.

[0121] The second test module 6 is used to test the test case code and obtain the specific domain code after the test passes.

[0122] Regarding the apparatus in the above embodiments, the specific manner in which each module performs its operation has been described in detail in the embodiments related to the method, and will not be elaborated upon here.

[0123] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this application according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0124] Accordingly, this application also provides an electronic device, including:

[0125] One or more processors;

[0126] Memory, used to store one or more programs;

[0127] When the one or more programs are executed by the one or more processors, the one or more processors perform the methods described above.

[0128] Accordingly, this application also provides a computer-readable storage medium having computer instructions stored thereon, which, when executed by a processor, implement the steps of any of the above methods.

[0129] In the embodiments provided in this application, it should be understood that the disclosed methods and systems can also be implemented in other ways. The method and system embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and systems, methods, and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing a specified logical function. It should also be noted that in some alternative implementations, the functions marked in the blocks may occur in a different order than those marked in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in a block diagram and / or flowchart, and combinations of blocks in block diagrams and / or flowcharts, can be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0130] In addition, the functional modules in the various embodiments of this application can be integrated together to form an independent part, or each module can exist independently, or two or more modules can be integrated to form an independent part.

[0131] On the other hand, a computer-readable storage medium stores computer instructions thereon, which, when executed by a processor, implement the steps of the above-described method. When the computer program is executed by the processor, it implements the method as described in any of the first aspects above. If the function is implemented as a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0132] The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A standardized programming method for information systems, characterized in that, Includes the following steps: Step S1: Requirements Analysis Receive the original requirements submitted by users, parse the original requirements and generate several user stories; Step S2: Specific Specification Conversion Under the constraints of the meta-specification, several user stories are transformed into several subdomain-specific specifications to guide the generation of code in their respective subdomains and a domain-specific specification to guide the generation of event code between subdomains through a large language model; Step S2 is as follows: (1) Using a large language model, several user stories are divided into several sub-domain user story sets and one domain user story set according to similarity / relevance; (2) Load the predefined meta-specifications to provide format and semantic constraints for subsequent conversions; the meta-specifications include: subdomain model structure, service and event composition, rule and constraint writing format, and test case description template; (3) Under the constraints of the meta-specification, several sub-domain user story sets and one domain user story set are transformed into several sub-domain specific specifications and one domain specific specification through the large language model; The specific specifications for a subdomain include: the definition and constraints of subdomain entities, attributes, and entity relationships; the description of subdomain services; and the description of test cases corresponding to subdomain services. The specific specifications for a domain include: descriptions of events between subdomains, and descriptions of test cases corresponding to the events between subdomains; Step S3: Subdomain code generation Based on specific specifications of several subdomains, corresponding specific code for several subdomains is generated through a large code generation model. The specific code for subdomains includes: specific code for subdomain entities, attributes, entity relationships, specific code for subdomain services, and corresponding test case code. Step S4: Subdomain code testing Test the specific code of the subdomain to obtain the specific code of the subdomain that passes the test; Step S5: Domain Code Generation Based on the specific domain specifications and several subdomain specific codes that have passed testing, the specific domain code is generated through a large code generation model. The specific domain code includes: event code between subdomains and corresponding test case code. Step S6: Domain Code Testing Test the domain-specific code to obtain the domain-specific code that passes the test.

2. The method according to claim 1, characterized in that, Step S1 is as follows: (1) Receive the user's original request in natural language or in file format; (2) Call the large language model to parse the original requirements into user stories, which include roles, activities and business value.

3. The method according to claim 1, characterized in that, Step S4 is as follows: Execute all test case code corresponding to specific code in several subdomains, and collect all test results corresponding to several subdomains; If all test results for a subdomain are normal, the specific code output for that subdomain will be the specific code of the subdomain that passed the test. If an anomaly occurs in the test results corresponding to the subdomain, the faulty test case is located, the specific code of the subdomain is repaired by generating a large model, and all test case code is re-executed until all test results corresponding to the subdomain are without anomalies. The output is the specific code of the subdomain that has passed the test.

4. The method according to claim 1, characterized in that, Step S6 specifically involves: executing all test case code in the domain-specific code and collecting all test results; If all test results are normal, the domain-specific code output will be the domain-specific code that passed the test. If an anomaly is found in the test results, the faulty test case is located, the domain-specific code is repaired by generating a large model, and all test case code is re-executed until all test results are without anomalies. The output is the domain-specific code that has passed the test.

5. The method according to claim 1, characterized in that, Also includes: Step S7: Code Deployment and Log Acquisition Package the tested subdomain code and the tested domain code into deployable code and push it to the deployment environment to complete deployment and run, and collect runtime log files; Step S8: Runtime Monitoring and Automatic Repair The system analyzes and collects runtime log files for anomaly repair, automatically repairs anomalies when they are detected, and generates repair patches to resolve the anomalies.

6. A standardized programming device for an information system, characterized in that, include: The parsing module is used to receive the original requirements submitted by users, parse the original requirements, and generate several user stories. The conversion module is used to convert several user stories into several subdomain specific specifications for guiding the generation of code in their respective subdomains and a domain specific specification for guiding the generation of event code between subdomains under the constraints of the meta-specification and the large language model. Specifically, it is used to: (1) divide several user stories into several subdomain user story sets and a domain user story set according to similarity / relevance through the large language model; (2) load the predefined meta-specification to provide format and semantic constraints for subsequent conversion; the meta-specification includes: subdomain model structure, service and event composition, rule and constraint writing format, and test case description template; (3) under the constraints of the meta-specification, convert several subdomain user story sets and a domain user story set into several subdomain specific specifications and a domain specific specification through the large language model; the subdomain specific specification includes: the definition and constraints of subdomain entities, attributes, and entity relationships, the description of subdomain services, and the test case description corresponding to the subdomain services; the domain specific specification includes: the event description between subdomains and the test case description corresponding to the events between subdomains. The first generation module is used to generate specific code for several sub-domains based on specific specifications of several sub-domains and through a large code generation model. The specific code for the sub-domains includes: specific code for sub-domain entities, attributes, entity relationships, specific code for sub-domain services, and corresponding test case code. The first testing module is used to test the specific code of the subdomain and obtain the specific code of the subdomain that passes the test; The second generation module is used to generate domain-specific code based on the domain-specific specifications and several tested subdomain-specific codes through a code generation model. The domain-specific code includes: event code between subdomains and corresponding test case code. The second testing module is used to test the domain-specific code and obtain the domain-specific code that passes the test.

7. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in any one of claims 1-5.

8. A computer-readable storage medium storing computer instructions thereon, characterized in that, When executed by the processor, this instruction implements the steps of the method as described in any one of claims 1-5.

Images