Microservice code automatic generation method, system and equipment based on multi-level model and medium

Abstract

The invention provides a micro-service code automatic generation method, system and equipment based on a multi-level model and a medium, and relates to the technical field of software development, the method comprises the following steps: according to system development stage characteristics and information dimensions, the system is subdivided into a multi-level model description framework comprising a demand model, an architecture model, a design model and a deployment model; and based on a mapping rule between a predefined model and a code, converting the multi-level model into an executable template code based on a Spring micro-service framework through a hierarchical code generation mechanism, so as to realize an automatic multi-level code generation process from demand to a final system. According to the method, the problems that in existing model driving code generation, input is not standard, generated codes are not complete, a complete information system is difficult to generate during large language model code automatic generation, and the codes are possibly inconsistent are solved, and a more efficient, standard and complete code automatic generation scheme is provided.

Description

TECHNICAL FIELD

[0001] The application relates to the technical field of software development, in particular to a micro-service code automatic generation method, system, device and medium based on a multi-level model. BACKGROUND

[0002] In the software development process, if the requirement analysis, architecture design and detailed design and other links completely rely on manual work, many systematic problems will be caused. First, the communication barrier of cross-domain cooperation, the understanding of project requirements, goals and technical implementation paths of different professional backgrounds such as business analysts, system architects and development engineers is easy to be different, which leads to the distortion and fracture of information transmission, and makes the project architecture inconsistent and lack of coherence. Secondly, the efficiency bottleneck of manpower intensive work, the manual completion of repetitive coding tasks in large projects will increase the time cost and error probability, and may also prolong the development cycle and push up the project cost. Finally, the semantic uncertainty of natural language description, the ambiguity and ambiguity in the requirement document make it difficult to accurately express the core logic of the information system. Therefore, exploring the application of automatic tools in the key stage is of great significance to reduce the communication cost, improve the development efficiency and enhance the semantic consistency of requirements and implementation.

[0003] In existing model-driven code generation solutions, (1) code is generated from a requirement model that covers both functional and non-functional requirements, including user requirements, business rules, and system constraints. This method directly generates code from high-level requirement models, ensuring consistency with the original requirements. However, existing methods are not complete solutions, and manual supplementation is still required later. The final generated code is often not sufficient for direct application in enterprise-level systems and is considered a rough prototype that needs further iteration and improvement. In addition, existing solutions with low customization level still need manual optimization before actual application to ensure effective deployment in specific environments. (2) Code is generated from design models that provide detailed structural and behavioral descriptions of the system, such as UML class diagrams, sequence diagrams, or state machine diagrams. This method generates code based on detailed system design models, such as UML class diagrams, sequence diagrams, or state machine diagrams. Design models are usually more specific and technology-oriented than requirement models. However, this method is not suitable for actual deployment. Most existing solutions start from design models, follow relevant industry standards, or require users to provide specific implementation details. Therefore, generating these codes is relatively straightforward and not particularly difficult. (3) Large language model code automatic generation: versions after GPT3.5 have the ability to solve problems with professional knowledge after large-scale corpus training, but designing effective prompts to fully utilize large language models to generate correct code or results is still a challenge. Currently, academia is expanding the capabilities of large language models by using new prompts to solve more problems and improve the reliability of results. Many technologies today are based on existing large models (such as ChatGPT-4) to achieve iterative, self-improving, and multi-process code generation.

[0004] Existing technologies can generate corresponding models for different input sources in model-driven aspects, but there are still several problems that have not been solved, including input irregularities, many systems rely on custom domain-specific languages, high learning costs, and lack of unified standards leading to interoperability issues; the completeness of generated code is insufficient, most current code generation tools mainly generate code snippets or code architectures, rather than complete information systems, lacking specific function implementation, error handling, logging, and integration logic. This incompleteness not only increases the workload of developers, but also may cause consistency and stability problems in the final system. In terms of large language model code automatic generation, although it can quickly generate code snippets, API calls, and basic program structures, it is difficult to generate complete and fully functional information systems, and the generated code lacks comprehensive function implementation, etc. and relies on statistical learning, which may produce code that does not meet actual requirements or is inconsistent, requiring manual adjustment and verification. SUMMARY

[0005] Therefore, the embodiment of the present application provides a micro-service code automatic generation method, system, device and medium based on a multi-level model, aiming to solve the problems of non-standard input, incomplete generated code, and difficulty in generating complete information system and inconsistent code in large language model code automatic generation, and provide a more efficient, standard and complete code automatic generation scheme.

[0006] The embodiment of the present application provides the following technical solutions: a micro-service code automatic generation method based on a multi-level model, comprising: According to the characteristics of the system development stage and the information dimension, the system is subdivided into a multi-level model description framework including a requirement model, an architecture model, a design model and a deployment model; wherein each level realizes the standardized expression of information through structured model elements and constraint rules, and adopts a dual description mechanism of structure diagram and behavior diagram, the structure diagram is used to describe the static structure of the system, and the behavior diagram is used to describe the behavior characteristics of the dynamic interaction process; Based on the pre-defined mapping rules between the model and the code, the multi-level model is respectively converted into executable template code based on the Spring micro-service framework through a layered code generation mechanism, so as to complete the automatic multi-level code generation process from the requirement to the final system.

[0007] According to an embodiment of the present application, the requirement model is constructed by using a standardized UML modeling method, the structure diagram in the requirement model includes a use case diagram and a concept class diagram, and the behavior diagram in the requirement model includes a system level sequence diagram; the use case diagram is used to visualize the interaction relationship between external participants and system functions, and to clearly define the service boundary of each function module of the system, the concept class diagram is used to define the core entity of the system and its association relationship, form an organizational logic framework, and the system level sequence diagram is used to describe the dynamic behavior between external participants and the system.

[0008] According to an embodiment of the present application, the architecture model is constructed by using a standardized UML modeling method, the structure diagram in the architecture model includes a component diagram and an internal class diagram, and the behavior diagram in the architecture model includes a component level sequence diagram; the component diagram is used to describe the static architecture and information between different services, the internal class diagram is used to describe the entity information inside a single service and the system operation information provided by the service, and the component level sequence diagram is used to describe the calling sequence and message passing path between different services, and provide the behavior characteristics of the system runtime.

[0009] According to an embodiment of the present application, the design model is constructed by using a standardized UML modeling method, the structure diagram in the design model includes a class diagram, the behavior diagram in the design model includes an object-level sequence diagram, the class diagram is used to functionally extend an entity class by introducing a data transmission object, and the object-level sequence diagram is used to describe the timing and cooperation logic of method calls between entity classes.

[0010] According to an embodiment of the present application, the deployment model is constructed by using a standardized UML modeling method, the structure diagram in the deployment model includes a deployment diagram, the deployment diagram takes a node as a basic unit, and the physical topology structure and resource allocation mode of the system are described by using the topological relationship and component distribution between nodes.

[0011] According to an embodiment of the present application, the construction of the deployment model is based on the output of the architecture model and the design model; wherein the service components and databases defined in the architecture model are mapped to corresponding nodes in the deployment stage of the deployment model, and the runtime efficiency is ensured by using a resource allocation strategy; the dependency relationship between nodes in the deployment diagram is consistent with the interface call relationship in the design model.

[0012] According to an embodiment of the present application, the multi-level model is respectively converted into executable template code based on a Spring micro-service framework by using a hierarchical code generation mechanism, including: Based on a predefined mapping rule of the requirement model to system interface-level code, the system interface-level code is generated by taking the requirement model as input; the system interface-level code includes an interface path and entity information in a gateway; Based on a predefined mapping rule of the architecture model and component-level code, controller layer code, business logic code, data access layer code and entity layer code are respectively generated in each service unit of the micro-service system, and communication protocol code between service units is generated, so as to generate component-level code in the architecture model; The entity class in the design model is extended to generate a data transmission object, corresponding properties and methods are added to the existing entity class and data transmission object, and based on a sequence diagram and a predefined mapping rule of the design model and function-level code, business logic implementation code is generated; Configuration level code is generated in the deployment model to automatically configure service registration and discovery of the micro-service, connection of the database, and container resources for service deployment.

[0013] The present application also provides a micro-service code automatic generation system based on a multi-level model, including: A multi-level model construction unit is configured to subdivide a system into a multi-level model description framework including a requirement model, an architecture model, a design model, and a deployment model according to system development stage characteristics and information dimensions; each level implements standardized expression of information through structured model elements and constraint rules, and adopts a dual description mechanism of a structure diagram and a behavior diagram, the structure diagram is used to describe a static structure of the system, and the behavior diagram is used to describe behavior characteristics of a dynamic interaction process; A code generation unit is configured to convert the multi-level models into executable template codes based on a Spring microservice framework through a hierarchical code generation mechanism based on predefined mapping rules between the models and the codes, so as to implement an automatic multi-level code generation process from a requirement to a final system.

[0014] The application further provides a computer device including a memory, a processor, and a computer program stored in the memory and executable on the processor, and the processor implements the above-mentioned microservice code automatic generation method based on a multi-level model when executing the computer program.

[0015] The application further provides a computer readable storage medium storing a computer program for executing the above-mentioned microservice code automatic generation method based on a multi-level model.

[0016] Compared with the traditional method, the above-mentioned at least one technical solution adopted by the embodiments of the present application can achieve the beneficial effects at least including that the embodiments of the present application define hierarchical conversion rules of an interface level, a component level, a function level, and a configuration level based on a model-driven paradigm, and realize automatic mapping from a high-level model to deployable microservice codes in combination with a predefined code template and a formal verification mechanism, thereby solving the problems of non-standard input, incomplete generated codes, and difficulty in outputting complete information systems and inconsistent codes in the existing model-driven code generation, and providing a more efficient, standardized, and complete code automatic generation scheme for complex software engineering. BRIEF DESCRIPTION OF DRAWINGS

[0017] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application, and other drawings can be obtained by those skilled in the art without creative labor.

[0018] Figure 1 is a first schematic diagram of the microservice code automatic generation method based on a multi-level model of the embodiments of the present application; Figure 2FIG. 2 is a second schematic diagram of a microservice code automatic generation method based on a multi-level model according to an embodiment of the present application; Figure 3 FIG. 3 is a requirement model schematic diagram according to an embodiment of the present application; Figure 4 FIG. 4 is a microservice architecture model schematic diagram according to an embodiment of the present application; Figure 5 FIG. 5 is a microservice internal architecture model schematic diagram according to an embodiment of the present application; Figure 6 FIG. 6 is a design model schematic diagram according to an embodiment of the present application; Figure 7 FIG. 7 is a deployment model schematic diagram according to an embodiment of the present application; Figure 8 FIG. 8 is a code mapping schematic diagram according to an embodiment of the present application; Figure 9 FIG. 9 is a comparison and conversion process schematic diagram between a microservice system and a monolithic system according to an embodiment of the present application; Figure 10 FIG. 10 is a requirement model generation schematic diagram according to an embodiment of the present application; Figure 11 FIG. 11 is an architecture model microservice generation schematic diagram according to an embodiment of the present application; Figure 12 FIG. 12 is an architecture model service internal generation process schematic diagram according to an embodiment of the present application; Figure 13 FIG. 13 is a design model code generation process schematic diagram according to an embodiment of the present application; Figure 14 FIG. 14 is a design model internal code generation schematic diagram according to an embodiment of the present application; Figure 15 FIG. 15 is a microservice code automatic generation system schematic diagram based on a multi-level model according to an embodiment of the present application; Figure 16 FIG. 16 is a structural schematic diagram of a computer device according to an embodiment of the present application. DETAILED DESCRIPTION

[0019] The embodiments of the present application will be described in detail below with reference to the accompanying drawings.

[0020] Following make the application's implementation through specific concrete example, the person skilled in the art can easily understand the other advantages and efficacy of the application from the disclosure of this specification. Obviously, the described embodiments are only a part of the embodiments of the application, not all the embodiments. The application can also be implemented or applied by another different specific implementation, and the details in the specification can be based on different views and applications, various modifications or changes are made without departing from the spirit of the application. It should be noted that the following embodiments and features in the embodiments can be combined with each other without conflict. Based on the embodiments in the application, all other embodiments obtained by the person skilled in the art without creative labor belong to the scope of protection of the application.

[0021] As Figures 1-2 The embodiment of the application provides a micro-service code automatic generation method based on a multi-level model, and the method is characterized by comprising the following steps: 101. According to the characteristics of the system development stage and the information dimension, the system is subdivided into a multi-level model description framework including a requirement model, an architecture model, a design model and a deployment model; wherein each level realizes the standardized expression of information through structured model elements and constraint rules, and adopts a dual description mechanism of structure diagram and behavior diagram, the structure diagram is used to describe the static structure of the system, and the behavior diagram is used to describe the behavior characteristics of the dynamic interaction process; 102. Based on the pre-defined mapping rules between the model and the code, the multi-level model is respectively converted into executable template code based on the Spring micro-service framework through a layered code generation mechanism, so as to complete the automatic multi-level code generation process from the requirement to the final system.

[0022] In the system development process, the information description of different stages is significantly different, and a single model is difficult to comprehensively cover the whole life cycle characteristics of the system. Therefore, the embodiment of the application proposes a multi-level model description framework, which realizes the accurate expression and dynamic adaptation of the development stage by subdividing the system information in layers. According to the stage characteristics and information dimension of the system development, the system description is subdivided into four levels of requirement model, architecture model, design model and deployment model, and each level realizes the standardized expression of information through structured model elements and constraint rules. In the model representation form, the embodiment of the application adopts a dual description mechanism of structure diagram and behavior diagram: the structure diagram is used to describe the static structure of the system, and clearly shows the core elements such as classes, interfaces and components and their mutual relationship, for example, the object attributes and operations are defined by UML class diagram, and the dependency and cooperation between modules are described by component diagram; the behavior diagram focuses on the modeling of dynamic interaction process, and accurately describes the behavior characteristics of the system runtime through message passing sequence, object cooperation path and other elements.

[0023] In step 101, in the aspect of demand model construction, a prototype system is automatically generated by a standardized UML modeling method to support demand confirmation. As shown in Figure 3 , the demand model is composed of a use case diagram, a concept class diagram, and a system level sequence diagram, forming a complete functional demand description system. The use case diagram clearly defines the service boundary of each functional module for different user groups by visualizing the interaction relationship between external participants (such as users and other systems) and system functions. The concept class diagram further refines the core entities and their associated relationships within the system to present the organizational structure of system components in an abstract view, providing a comprehensible logical framework for developers. The system level sequence diagram focuses on the interaction process between users and the system, only retaining two core roles of actors and systems, and intuitively presents the system runtime behavior mode through message passing sequence and object collaboration path. Figure Three

[0024] In the aspect of architecture model, the embodiment of the application uses UML to standardize it. For external microservice architecture, as shown in Figure 4 , the static architecture of the system is represented by component diagrams and internal class diagrams, and the information exchange between different services is represented by component level sequence diagrams.

[0025] In the aspect of static architecture analysis, the component diagram and the internal class diagram jointly constitute the static architecture basis of the microservice system. The component diagram visualizes the dependency relationship and interface definition between different services, and clearly defines the static connection mode between services. For example, the arrow pointing relationship in the diagram intuitively shows the dependency level between services, providing a data basis for evaluating the coupling degree between services. The internal class diagram further refines the logical structure within a single service, revealing the cohesion of the internal responsibility division of the service. In the aspect of dynamic interaction analysis, the component level sequence diagram provides the behavior characteristics of the system runtime by describing the calling sequence and message passing path between services. These dynamic information can complement the limitations of static indicators, and further refine the dynamic evaluation of coupling degree by statistical service calling frequency and message passing path length.

[0026] In monolithic service architecture modeling, as shown in Figure 5 , the embodiment continues the layered modeling method, and cooperates the component diagram, the internal class diagram, and the component level sequence diagram to completely describe the static structure and dynamic behavior within the service.

[0027] ​In the static modeling aspect, the component diagram clearly defines the function and dependency of each component in a hierarchical architecture: the Controller layer serves as the external request entry, responsible for passing user instructions to the Service layer for business processing; the Service layer encapsulates the core logic (such as the queryForTravelInfo and queryForStationId methods in BasicService), and interacts with the Repository layer to achieve data interaction; the Repository layer directly operates the database to perform data access and persistence, while the Entity layer defines the structure specification of data objects. This hierarchical design not only clearly defines the dependency boundaries between components (such as the invocation dependency of Controller on Service, and the data access requirement of Service on Repository), but also further refines the implementation details of the Service layer through internal class diagrams, such as the function division of specific methods, ensuring clear and maintainable component responsibilities. In the dynamic modeling aspect, the component-level sequence diagram visually restores the request processing flow through the time sequence diagram. Taking the queryTravel request as an example, after Controller triggers the findStation, findTrainType, and other methods of the Service layer, these methods sequentially call the corresponding interfaces (such as getStationInfo) of the Repository layer to obtain data. This time sequence description not only shows the message passing path between components, but also reveals the execution order and collaboration mode of business logic, such as how the Service layer coordinates multiple Repository methods to complete a composite query. Through the combination of static and dynamic models, architecture designers can not only analyze the cohesion and coupling degree of components from the structural perspective, but also optimize the interface call efficiency and exception handling mechanism from the behavioral perspective, ultimately providing a visual basis for system performance tuning and architecture evolution.

[0028] In the design model construction aspect, the design model is constructed through the UML standardized method, as shown in Figure 6 The design model is composed of extended class diagrams and object-level sequence diagrams, which together achieve accurate description of the static structure and dynamic behavior of the system. In the static modeling aspect, the class diagram extends the entity class through the introduction of data transfer objects (DTO), which not only refines the interface specification of class collaboration, but also enhances the standardization and decoupling of data transmission between components through the introduction of DTO, avoiding direct exposure of internal entity structure, thereby improving the maintainability of system interfaces.

[0029] At the dynamic modeling level, the object-level sequence diagram focuses on the timing and collaboration logic of method calls between classes. For example, the BasicController receives a user request, which triggers the business processing flow by calling the method of the BasicService. Inside the BasicService, the system records the state and message by creating a Response object, and finally encapsulates the processing result into the TravelResult class to return to the controller. This step-by-step call and data flow visualization not only clearly shows the dependency relationship between class methods (such as the dependency of BasicService on Response and TravelResult), but also ensures the traceability of business logic through the explicit message passing path. For example, the setResult() method call between BasicService and TravelResult in the sequence diagram intuitively shows the complete link of data encapsulation and return. Through the cooperation of static and dynamic models, the design model not only inherits the functional constraints of the requirement model, but also provides a structured and verifiable design benchmark for subsequent code generation through the extension of DTO and the explicitness of the call flow.

[0030] At the deployment model construction level, the embodiment standardizes the physical architecture and resource allocation strategy of the system through the UML deployment diagram, as shown in Figure 7 The model takes the node (Node) as the basic unit, clearly defines the physical deployment location of system components (services, databases) and their resource requirements, and provides structured input for automatic deployment script generation. In terms of static information expression, the deployment diagram explicitly shows the physical topology structure and resource allocation mode of the system through the topological relationship and component distribution between nodes. This distributed deployment design separates different services and databases into independent nodes, which not only realizes the decoupling of computing and storage resources, but also improves the availability and horizontal expansion ability of the system through load balancing and fault tolerance mechanisms.

[0031] The construction of the deployment model needs to strictly follow the output of the architecture model and the design model. The service components and databases defined in the architecture model need to be mapped to specific nodes in the deployment stage, and the resource allocation strategy needs to be ensured to ensure the runtime performance. At the same time, the dependency relationship between nodes in the deployment diagram and the interface call relationship in the design model are consistent, avoiding runtime failures caused by the mismatch between deployment topology and logical architecture.

[0032] In step 102, after defining the multi-level model, the embodiment of the present application converts the abstract model into an executable information system through a layered code generation mechanism. This process strictly follows the mapping rules between models and codes, ensuring that each level of code not only independently assumes specific functions, but also seamlessly collaborates through model constraints. For example, Figure 8As shown, the system interface level code serves as a "bridge" for external interaction, and is automatically generated based on the user operation sequence (such as use cases, interaction sequence) and entity definition in the requirement model, to generate RESTful API interface specifications, message queue protocols and other communication mechanisms. After the system interface level code is laid, the component level code further deepens the collaboration mechanism within the system. According to the component design, interface dependency relationship and object distribution strategy in the architecture model, the code in this level generates the internal logic and collaboration framework of the component, and the code template of the communication protocol between components is dynamically generated based on the interaction path in the model. This hierarchical design not only ensures the high cohesion and low coupling of the components, but also maintains the version compatibility of the component interfaces through the code generation tool, supporting independent deployment and gray release of microservices. The function level code focuses on the precise implementation of business logic, and its generation strictly follows the data flow and state management specifications in the design model. Through the data transmission object definition and object collaboration information in the model, this level of code ensures that the input and output formats, thread safety and resource lock mechanism of each function operation meet the design constraints, thereby improving the quality of the code while freeing the developers from repetitive CRUD implementation, allowing them to focus on optimizing complex business logic. Finally, the configuration level code focuses on the environmental adaptation and operation management of the system, and through the automatic implementation of resource allocation, cluster control and life cycle management strategies, it ensures the stable operation of the system in a variety of deployment environments. This hierarchical generation mechanism not only reduces the risk of manual configuration errors, but also realizes full-link automation from development to operation through model-driven configuration synchronization, significantly improving the maintainability and elastic expansion capability of the system.

[0033] Throughout the integrated conversion process from the multi-level model to the final information system, the code generation engine plays a key role. It receives information from different levels of models, combines predefined code templates, and automatically generates system interface level, component level, function level, and configuration level code. This not only improves development efficiency and reduces repetitive labor, but also ensures code consistency and standardization. Ultimately, this method promotes the rapid construction of high-quality information systems.

[0034] To better demonstrate the generation rules, the present embodiment uses the microservice architecture Spring Cloud, and uses the Spring Boot framework inside the service. As shown in FIG. 4, the system architecture is divided into four levels: requirement model, architecture model, component model and code generation engine. The requirement model is the basis of the entire system, and is used to describe the system's external interaction and internal collaboration. The architecture model is used to describe the system's internal structure and interaction mechanism. The component model is used to describe the internal logic and collaboration mechanism of each component. The code generation engine is used to automatically generate the code of each level based on the information from the previous levels. Figure 9The diagram illustrates the comparison and transformation process between microservice and monolithic systems. First, in a microservice system, the gateway serves as the system's entry point, responsible for request routing and load balancing. Business services include components such as Controller, Service, Repository, and Entity, which handle HTTP requests, business logic, data access, and entity object definition, respectively. Database configuration, service communication configuration, container resources, management middleware, and architecture middleware provide infrastructure support for the entire system. In a monolithic system, functional modules such as system operations, data transfer objects, service interfaces, authorization management, and service interface implementation are integrated. ORM & JPA CRUD are used to handle data persistence, while entity attributes and entity operations define the behavior of the data model. Container resource scripts and container startup scripts ensure the system's normal operation in different environments.

[0035] The specific implementation includes the following steps: (1) Automatic generation of system interface level code like Figure 10 As shown, the system-level code covers multiple aspects, including gateways, internal interface operations, and entity information. Information from system operations is used to generate gateway-related information within the microservice system. The gateway, as the system's entry point, is responsible for request routing and load balancing. Simultaneously, information about Spring Cloud middleware can be generated based on different templates, including management middleware such as the registry center and disaster recovery / degradation mechanisms. Since the requirement model currently focuses on the overall system, this embodiment does not explicitly specify the information within different services. Based on the mapping relationship, this embodiment defines the mapping rules from the requirement model to the system interface level code. R1(3.1) describes the specifics of gateway generation, noting that in addition to basic configuration information, the gateway also needs to generate entry URLs for system operations based on human-system interactions. This means that the dynamic information represented in the Requirement Model, especially the sequence diagram of human-system interactions, needs to be mapped to the gateway's entry URLs.

[0036] Specifically, the sequence diagram in the requirement model provides a detailed description of the interaction flow between the user and the system, including different system operations and their triggering conditions and execution order. These operations not only define how the user interacts with the system, but also explicitly specify the collaboration between various components within the system. To map these dynamic interactions to the gateway level, the embodiment analyzes the request paths corresponding to each system operation and assigns them unique URL addresses. This process ensures that all requests from the user are correctly routed to the corresponding backend services or functional modules.

[0037] (3.1) In R2 (3.2) and R3 (3.3), the specific conversion process from the conceptual class diagram to the entity class is described. This process includes generating corresponding entity classes based on the class diagram and generating specific attributes in the code based on the attributes in the class diagram. Each conceptual class is mapped to an entity class, and its attributes are defined through appropriate programming language data types and annotations to ensure data validity and consistency. For example, fields such as id, name, etc. in the class diagram will be converted to attributes in the entity class, and appropriate constraints (such as non-empty, uniqueness) will be added. At the same time, the association relationship (such as one-to-many, many-to-many) in the class diagram is mapped to the entity class through JPA annotations (such as @OneToMany, @ManyToOne), ensuring the correct interaction between components within the system. This mapping mechanism not only improves the consistency and maintainability of the code, but also makes the architecture of the entire system clearer and easier to understand.

[0038] (3.2) (3.3) In addition to the specific conversion rules, the embodiment defines the mapping templates for Gateway, Entity, and the configuration templates used for service registration and discovery in sequence.

[0039] The algorithm takes the requirement model as input and generates the system interface-level code, including the interface paths in the Gateway and entity information. First, the algorithm parses the system sequence diagram in the requirement model and identifies the interactive operations between the user and the system. These operations include various requests initiated by the user and their corresponding system responses. According to the rules and Gateway templates, the algorithm automatically generates the system operation paths in the Gateway. Next, the algorithm further parses the conceptual class diagram in the requirement model and generates specific entity classes and enumeration classes based on R2 (3.2) and R3 (3.3). The Entity template provides two different class templates: for ordinary classes defined in the class diagram, the algorithm generates the corresponding entity classes. Each entity class contains attributes, methods, and necessary annotations. For enumeration types defined in the class diagram, the algorithm generates the corresponding enumeration classes.

[0040] (2) Component-level code generation As shown in Figure 11 , the embodiment generates the corresponding component-level code according to the architecture model of microservices. The microservices architecture divides the system into multiple modules, each responsible for a specific responsibility and interface. This means that during the design phase, based on the requirement model, specific path mapping and routing logic can be implemented in the Gateway. As the system is divided into smaller service units, code generation can be performed for each internal service, targeting Controller, Service, Repository, and Entity. These parts are responsible for handling different tasks: the Controller layer (controller layer code) is mainly responsible for handling requests from the client and forwarding them to the corresponding business logic layer; the Service layer (business logic layer) contains the actual business logic; the Repository layer (data access layer) is responsible for data access operations, while the Entity layer (entity layer) defines the data structure. In addition, since each service needs to communicate with each other under the microservices architecture, some code for inter-service calls needs to be generated. This part of the code can be written according to the sequence diagram between services through the Openfeign call code template. This not only improves development efficiency, but also ensures the decoupling and flexibility between services, making the entire system more maintainable and extensible.

[0041] For each internal service, according to the architecture model in the multi-level model, the embodiment defines specific Controller, Service, and Repository components, and defines specific methods in these components. As shown in Figure 12As shown, the monolithic system is split into multiple components, including system operations, data transfer objects, service interfaces, authorization management, service interface implementations, ORM & JPA CRUD, etc. First, in the component diagram, the interfaces and methods are defined, which correspond to system operations and service interfaces. Next, in the class diagram, the method classes are defined, which correspond to service interface implementations. Then, in the sequence diagram, the message passing between components is demonstrated, which involves entity attributes and entity operations. In actual development, the Controller layer is responsible for handling external requests, converting request parameters into data transfer objects, and calling the Service layer for business logic processing. The Service layer then calls the Repository layer for data access operations according to business requirements, and may also need to perform security controls such as authorization management. The Repository layer interacts with the database through ORM (Object-Relational Mapping) technology to perform CRUD (Create, Read, Update, Delete) operations.

[0042] According to the mapping relationship, the embodiment defines the mapping rules from the architecture model to the component-level code.

[0043] For rule R4 (3.4), its main function is to generate the corresponding Controller code from the method classes in the component diagram. In microservice architecture, the Controller layer plays a crucial role, as it not only handles external requests but also manages the input and output of these requests. Specifically, rule R4 (3.4) creates the corresponding Controller interface according to the method classes in each component diagram. This means that each operation defined in the method class and its operation signature will be mapped to an interface in the Controller layer. For example, if there is an operation called "getUserInfo" in a method class that accepts a user ID as a parameter and returns the user's detailed information, there will be a corresponding interface in the Controller layer that receives the same parameter and returns the data in a specified format.

[0044] This mapping relationship ensures that each part of the system can clearly know how to receive and respond to specific types of requests. In this way, the Controller layer becomes a bridge between the external world and the internal business logic of the system. It first parses the request from the client, then calls the appropriate Service layer method for processing according to the request content, and finally returns the processing result to the client in an easy-to-understand format.

[0045] (3.4) Through rules R5 (3.5) and R6 (3.6), the corresponding code is generated based on the components Service and Repository in the monolithic architecture model. This process not only covers the transformation from design to implementation, but also ensures the coordination and functional integrity between the internal layers of the system. The Service layer is responsible for handling core business logic in the microservices architecture. According to rule R5 (3.5), the method class in the monolithic architecture model is mapped to the concrete implementation of the Service layer. This means that each operation defined in the method class and its operation signature will be translated into a method of the Service interface. For example, if a "processOrder" operation is defined in the method class, which may contain a series of complex business logic such as order verification, inventory checking, and payment processing, there will be a corresponding processOrder method in the Service layer, which encapsulates these business logic and provides a clear calling interface. The Repository layer is mainly responsible for interacting with databases or other persistent storage, providing basic operation support for data. According to rule R6 (3.6), the method class in the monolithic architecture model is mapped to the concrete implementation of the Repository layer. This includes defining methods for performing CRUD operations (create, read, update, delete), as well as custom query methods as needed. For example, suppose a "findUserById" operation is defined in the method class, which is used to find user information based on user ID, then there will be a corresponding findUserById method in the Repository layer, which uses ORM technology to interact with the database and obtain the required data.

[0046] (3.5) (3.6) In the microservices architecture, inter-service communication is a crucial step. Rule R6 (3.7) focuses on extracting this interaction information from the sequence diagram at the component level of the architecture model. The sequence diagram describes in detail how different services communicate, call and respond to each other, including the role of each service, the time point of interaction, and the direction of data flow, etc. Key details. For example, in an e-commerce application, the order service may need to interact with the inventory service and the payment service to complete an order processing process. The sequence diagram will show the specific interaction steps between these services, such as the order service first calling the inventory service to check the inventory, then calling the payment service to process payment, and finally updating the order status.

[0047] (3.7) In addition to the specific transformation rules, this embodiment defines templates for Controller, Service, Repository, and service invocation OpenFeign in turn.

[0048] Generating the basic code for components in the architectural model is a multi-layer process. First, the Controller layer RESTful interfaces for services are created based on the method interfaces within each component. This means that for each operation defined in the component (such as getting user information, updating order status, etc.), a corresponding RESTful interface is automatically generated. These interfaces not only define the HTTP request method type (GET, POST, etc.) and path (such as / api / v1 / users / {userId}), but also specify the input parameters and returned data format.

[0049] Next, for different layers within a single service (Service, Repository), this embodiment will apply rules R4 and R5, and supplement the information in the Controller template and Service template. For the Service layer, through rules R4 and the Repository template, the code for the business logic layer is generated. This includes implementing all business operations defined in the component and handling related business logic, such as data validation, transaction management, etc. For example, the processOrder method may contain a series of complex business logic such as inventory checking, payment processing, etc. For the Repository layer, using rules R5 and the service invocation template, code for interacting with the database is generated for each component. This mainly involves the implementation of CRUD operations and possibly complex query logic.

[0050] Finally, to support inter-service calls, the information in the service invocation graph is traversed to generate the corresponding RestTemplate method for each call operation. This step ensures that the service initiating the call can correctly communicate with other microservices. For example, if the order service needs to call the inventory service to check the inventory of goods, a piece of code will be generated in the order service using RestTemplate to send an HTTP request to the inventory service and handle the response result. In this way, each service can access the functionality of other services through simple API calls, enabling seamless collaboration between services.

[0051] (3) Function-level code generation For example, Figure 13As shown, the design model mainly describes the detailed operations of the system. The previous requirement and architecture models implement the framework of the model, and the specific function operations can be realized through the design model. At the same time, the design model will further expand the previous concept class diagram, which is reflected in the expansion of the methods of the class. In the requirement stage, this embodiment clearly defines the functions and target user requirements that the system needs to implement. Subsequently, in the architecture model, the overall structure of the system and the interaction mode between the various components are defined. However, these models are relatively abstract and lack specific implementation details. The design model further refines on this basis and converts abstract concepts into specific code implementation. For example, in the microservice architecture, the design model will describe the specific functions and responsibilities of each microservice in detail. Mainly the implementation of the specific methods in the Service. Through the design model, add necessary attributes and methods to the entity class to support the implementation of business logic.

[0052] Through the design model, not only can the high-level requirements be converted into specific software implementation schemes, but also the low coupling degree between various components can be ensured, so that any modification or expansion of the system in the future will not affect other unrelated parts.

[0053] The design model mainly describes the detailed operations of the service inside and the expansion of the class, from Figure 14 As can be seen, the design model will supplement the data transfer objects in the springboot architecture, and on the basis of the architecture model, it will describe the service interface implementation in the Service and the specific operations of the entity in the Entity. The design model will supplement the data transfer objects (DTO) in the Spring Boot architecture. DTO is an object used to transfer data between different system components, usually containing properties and simple access methods. Through the design model, add necessary attributes and methods to the DTO to ensure that they can effectively carry and transfer business data. The design model will describe the service interface implementation in the Service layer on the basis of the architecture model. The Service layer is the core part of the business logic, responsible for handling specific business operations. The design model will define the specific method implementation for each service interface, including the input parameters, output results and internal business logic of the method, and the design model will describe the specific implementation steps of these methods to ensure that they can correctly handle business requirements.

[0054] According to the mapping relationship, the embodiment defines the mapping rules of the design model to the function level code.

[0055] According to the R8 rule, the design model defines the data transfer objects (DTOs) and methods in entity classes when generating or extending class diagrams based on specific business requirements and architectural principles. This process not only involves extending existing conceptual class diagrams but also includes adding necessary attributes and methods to each class to support the implementation of business logic. Common methods added to the class diagram, such as property Get and Set or class constructor functions, can be addressed through annotations in springboot, eliminating the need to generate specific code.

[0056] (3.8) According to the R9 rule, the sequential operation in the design model guides the implementation of CRUD operations for specific classes, ensuring efficient and accurate data management. This includes: creating (Create) objects through constructor functions or factory methods and performing necessary data validation; reading (Read) objects from data storage through defined methods, supporting single or multiple entity queries; updating (Update) provides methods to modify existing objects, ensuring data consistency and transaction integrity; and deleting (Delete) allows safe removal of objects, considering soft deletion mechanisms to preserve historical records and maintain data association. These operations collectively ensure the robustness and maintainability of the system.

[0057] Sequence diagrams are primarily used to describe the interaction sequence between objects in a system, particularly suitable for showing the calling process and message passing between objects. However, it has limitations in describing numerical calculations, algorithm operations, and other details, as these operations usually focus more on internal logic and data processing processes rather than object interactions, especially when complex logic or numerical calculations are involved, which often cannot provide sufficient details. To overcome this limitation, a separate third-party tool class can be built to implement common algorithm and numerical calculation operations. This approach not only clearly separates business logic and algorithm logic but also improves code maintainability and reusability. For example, encapsulating sorting algorithms, array operations, and other operations into a tool class can make business logic code more concise and clear, focusing on the implementation of core functions.

[0058] (3.9) This embodiment successively defines the pseudo code of the transmission data and methods.

[0059] For the specific operations of the functions, the specific implementation of the component-level code generation service is supplemented, which needs to inject the repository class of the entity according to the use of the repository component by the service component of the previous architecture model. Then for each operation, there is a class-level sequence diagram, which is divided into three types for each operation. The first is the numerical filling operation of the class, which is directly completed through the set and get operations. The second is the operation on the entity, which includes the add, delete, modify and query operations, which need to call the operation of the repository class according to the operation name. The third is the call to other services, which needs to use the code insertion of the component code level generation for the service call.

[0060] In summary, the generation of function-level code in the design model is a complex but systematic process, mainly divided into two core parts. First, traverse the newly added classes in the entire design model and convert these classes into data transfer objects (DTO). This step ensures that each component of the system can effectively transfer and process data. Specifically, this embodiment analyzes each newly defined class, extracts its attributes and methods, and then automatically generates corresponding data transfer classes according to certain rules and templates. These data transfer classes not only simplify the data transfer process, but also enhance the modularity and maintainability of the system. Next, when processing the operations in the sequence diagram, three different cases need to be distinguished to generate the corresponding code implementation. For those operations involving CRUD on classes, directly generate the specific class operations according to the pre-set rules 9 and the corresponding specific method templates. When encountering the case of calling other services, the relevant algorithms for service calls need to be written by referring to the R7 guiding principles in the architecture model and the Repository template. Finally, for some special operations such as array search, sorting or mathematical calculation, the methods in the third-party tool class defined in advance can be used to implement them.

[0061] (4) Configuration-level code automatic generation In the process of implementing the basic code of the architecture model generation component, in addition to automatically generating the Controller, Service and Repository code at the business logic level, code generation at the configuration level is also crucial. The configuration level mainly covers two key aspects: one is the service registration and discovery of microservices and the connection configuration of the database; the other is the container resource configuration of service deployment. Each service in the microservice architecture needs to be able to discover and communicate with each other. Therefore, the automated configuration generation should include the configuration of the service registry, which in this embodiment uses nacos. This usually involves adding necessary configuration items in the application.yml or application.properties file. At the same time, the configuration of the database, which in this embodiment uses mysql, also needs to be added to the configuration file.

[0062] In addition, in order to support the containerized deployment of services, a Dockerfile and related startup scripts need to be generated to ensure the smooth startup of the system. First, this embodiment creates a Dockerfile to define how to build an image of the application. This Dockerfile is based on a suitable base image (such as OpenJDK), copies the compiled application package to a specified location in the image, and sets the working directory. It also exposes the port that the application listens to, and specifies the command to run when the container is started through the ENTRYPOINT instruction. Next, to simplify the image building process, this embodiment generates a build script. This script is responsible not only for compiling the code, but also for building the Docker image according to the Dockerfile, and tagging it for future use. When the application is ready to be deployed to a production environment, another startup script is used to start the containerized application.

[0063] This embodiment defines hierarchical conversion rules at the interface level, component level, function level and configuration level based on the model-driven paradigm, and realizes the automatic mapping from high-level models to deployable microservice code by combining pre-defined code templates and formal verification mechanisms.

[0064] As shown in Figure 15 The embodiment of the application also provides a multi-level model-based microservice code automatic generation system 200, which comprises: A multi-level model construction unit 201 is used to subdivide the system into a multi-level model description framework comprising a requirement model, an architecture model, a design model and a deployment model according to the system development stage characteristics and information dimensions; wherein each level realizes the standardized expression of information through structured model elements and constraint rules, and adopts a dual description mechanism of structure diagram and behavior diagram, the structure diagram is used to describe the static structure of the system, and the behavior diagram is used to describe the behavior characteristics of the dynamic interaction process; The code generation unit 202 is configured to convert the multi-level model into executable template code based on a Spring micro-service framework by using a hierarchical code generation mechanism based on a predefined mapping rule between the model and the code, so as to realize an automatic multi-level code generation process from a requirement to a final system.

[0065] In an embodiment, a computer device is provided, comprising a memory 301, a processor 302, and a computer program stored in the memory 301 and executable on the processor 302, wherein the processor 302 implements the above-mentioned micro-service code automatic generation method based on a multi-level model when executing the computer program. Figure 16

[0066] Specifically, the computer device can be a computer terminal, a server, or a similar computing device.

[0067] In an embodiment, a computer readable storage medium is provided, which stores a computer program for implementing the above-mentioned micro-service code automatic generation method based on a multi-level model.

[0068] Specifically, the computer readable storage medium includes permanent and non-permanent, removable and non-removable media, which can be implemented by any method or technology to store information. The information can be computer readable instructions, data structures, program modules or other data. Examples of computer readable storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassette, magnetic tape disk storage or other magnetic storage devices, or any other non-transmission medium that can be used to store information accessible by a computing device. According to the definition herein, the computer readable storage medium does not include transitory computer readable media, such as modulated data signals and carriers.

[0069] ​Obviously, those skilled in the art should understand that each module or each step of the above-mentioned embodiments of the present application can be realized by a general computing device, which can be centralized on a single computing device or distributed on a network composed of multiple computing devices, and optionally, each module or each step can be realized by program codes executable by a computing device, so that each module or each step can be stored in a storage device and executed by a computing device, and in some cases, the steps shown or described can be executed in different order, or each module can be manufactured as an individual integrated circuit module, or multiple modules or steps can be manufactured as a single integrated circuit module. Thus, the embodiments of the present application are not limited to any specific combination of hardware and software.

[0070] The above merely illustrates the specific embodiments of the present application, but the protection scope of the present application is not limited to this. Any modification or replacement within the technical scope disclosed by the present application can be easily thought by those skilled in the art, which should be covered by the protection scope of the present application. Thus, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for microservice code automatic generation based on a multi-level model, characterized in that, Comprising: Subdivide the system into a multi-level model description framework including requirement model, architecture model, design model and deployment model according to the system development stage characteristics and information dimensions; wherein each level realizes the standardized expression of information through structured model elements and constraint rules, and adopts a dual description mechanism of structure diagram and behavior diagram, the structure diagram is used to describe the static structure of the system, and the behavior diagram is used to describe the behavior characteristics of the dynamic interaction process; Based on the pre-defined mapping rules between the model and the code, the multi-level model is respectively converted into executable template code based on the Spring micro-service framework through the hierarchical code generation mechanism, so as to complete the automatic multi-level code generation process from requirement to final system. 2.The microservice code automatic generation method of claim 1, wherein, Comprising: The structure diagram in the requirement model includes use case diagram and concept class diagram, and the behavior diagram in the requirement model includes system level sequence diagram; the use case diagram is used to visualize the interaction relationship between external participants and system functions, and to clearly define the service boundary of each functional module of the system, the concept class diagram is used to define the core entity of the system and its association relationship, forming an organizational logical framework, and the system level sequence diagram is used to describe the dynamic behavior between external participants and the system. 3.The microservice code automatic generation method of claim 1, wherein, Comprising: The structure diagram in the architecture model includes component diagram and internal class diagram, and the behavior diagram in the architecture model includes component level sequence diagram; the component diagram is used to describe the static architecture and information between different services, the internal class diagram is used to describe the entity information inside a single service and the system operation information provided by the service, and the component level sequence diagram is used to describe the calling sequence and message passing path between different services, providing the behavior characteristics of the system runtime.

4. The microservice code auto-generation method of claim 1, wherein, Comprising: The structure diagram in the design model includes class diagram, and the behavior diagram in the design model includes object level sequence diagram; the class diagram is used to extend the functionality of the entity class by introducing data transmission object, and the object level sequence diagram is used to describe the timing and cooperation logic of method calling between entity classes.

5. The microservice code auto-generation method of claim 1, wherein, Comprising: The structure diagram in the deployment model includes deployment diagram, which takes node as the basic unit, describes the physical topology structure and resource allocation mode of the system through the topological relationship and component distribution between nodes.

6. The microservice code auto-generation method of claim 5, wherein, The construction of the deployment model is based on the output of the architecture model and the design model; wherein the service components and databases defined in the architecture model are mapped to corresponding nodes in the deployment stage of the deployment model, and the runtime efficiency is ensured through resource allocation strategy; the dependency relationship between nodes in the deployment diagram is consistent with the interface calling relationship in the design model.

7. The microservice code auto-generation method of claim 1, wherein, The multi-level model is respectively converted into executable template code based on the Spring micro-service framework through the hierarchical code generation mechanism, comprising: Based on a predefined mapping rule of a requirement model to system interface level code, system interface level code is generated as input of the requirement model; the system interface level code includes interface paths in the gateway and entity information; Based on a predefined mapping rule of an architecture model and component level code, controller layer code, business logic layer code, data access layer code and entity layer code are respectively generated in each service unit of the microservice system, and communication protocol code between service units is generated, to generate component level code in the architecture model; The entity classes in the design model are extended to generate data transfer objects, and corresponding properties and methods are added to the existing entity classes and data transfer objects, based on a sequence diagram and a predefined mapping rule of the design model and function level code, business logic implementation code is generated; In the deployment model, configuration level code is generated to automatically configure service registration and discovery of microservices, connection of databases and container resources for service deployment.

8. A multi-tier model based microservice code auto-generation system, characterized in that, Comprise: A multi-level model construction unit is configured to subdivide a system into a multi-level model description framework including a requirement model, an architecture model, a design model and a deployment model according to system development stage characteristics and information dimensions; each level is implemented by structured model elements and constraint rules to standardize information expression, and a structure diagram and a behavior diagram are used to describe static structure and dynamic interaction process behavior characteristics; A code generation unit is configured to convert the multi-level models into executable template code based on a predefined mapping rule between models and code through a hierarchical code generation mechanism, to realize an automatic multi-level code generation process from requirements to a final system based on a Spring microservice framework.

9. A computer device comprising a memory, a processor, and a computer program stored on the memory and executable on the processor, characterized in that, The processor implements the multi-level model based microservice code automatic generation method of any one of claims 1 to 7 when executing the computer program.

10. A computer-readable storage medium, characterized in that, The computer readable storage medium stores a computer program for implementing the multi-level model based microservice code automatic generation method of any one of claims 1 to 7.

Images