Standardized project file generation method and device, electronic equipment and storage medium

Abstract

The invention discloses a standardized project file generation method and apparatus, an electronic device and a storage medium. The method comprises the steps of determining a plurality of design models corresponding to a target application service; according to a preset engineering structure specification, respectively establishing a mapping relation from the design model to the package directory, and obtaining an engineering structure of the target application service; converting each entity model into a corresponding code template file according to a preset coding specification, wherein the code template file is stored in an engineering package corresponding to a package directory corresponding to the entity model; obtaining model data of each design model; mapping all the model data into the code template file according to the mapping relation to obtain a code structure; and organizing the code structure into a corresponding package directory according to an engineering structure defined in the mapping relationship to form a project structure of the target application service. By analyzing the design model and establishing accurate mapping with the package directory, disorder of an engineering structure and a code structure is effectively prevented, and development efficiency and code correctness are greatly improved.

Description

Technical Field

[0001] This invention relates to the field of software development technology, and in particular to a method, apparatus, electronic device, and storage medium for generating standardized project documents. Background Technology

[0002] In current software engineering practices, especially in the fields of microservice architecture and distributed systems, development teams often need to quickly build and deliver a large number of microservice applications with similar functions but different business logic. Traditional development models heavily rely on developers manually creating project structures and writing basic code (such as controllers, service interfaces, data entities, etc.).

[0003] However, this development model based on manual operation has the following limitations:

[0004] First, consistency is difficult to guarantee. Different developers have different understandings and implementations of the specifications, which can easily lead to inconsistent project structures and mixed coding styles, greatly increasing subsequent maintenance costs and communication costs for team collaboration.

[0005] Secondly, development efficiency is low: creating directories and writing repetitive boilerplate code (such as the CRUD operations) consume a lot of development time, which restricts the speed of project startup and iteration.

[0006] Finally, architectural governance is difficult: as the project scales up and team members change, it becomes difficult to ensure that all services strictly follow the established architectural layers and design patterns, which can easily lead to architectural decay and affect the overall stability and scalability of the system. Summary of the Invention

[0007] This invention provides a method for generating standardized project documents to solve the problem of generating standardized project documents.

[0008] In a first aspect, the present invention provides a standardized project document generation method, comprising:

[0009] Obtain and parse the target application service to obtain multiple design models corresponding to the target application service. Each design model is one of the following: microservice model, application model, and entity model.

[0010] According to the preset engineering structure specifications, a mapping relationship from the design model to the package directory is established respectively, and the engineering structure of the target application service is obtained. Each package directory is set with hierarchical attributes.

[0011] Each entity model is converted into a corresponding code template file according to the preset coding specifications, and the code template file is stored in the project package corresponding to the package directory of the entity model;

[0012] Obtain the model data for each of the design models;

[0013] Based on the mapping relationship, all the model data is mapped to the code template file to obtain the code structure;

[0014] Based on the project structure defined in the mapping relationship, multiple code structures are organized into the corresponding package directories to form the project structure of the target application service.

[0015] Secondly, the present invention provides a standardized project document generation apparatus, comprising:

[0016] The design model acquisition module is used to acquire and parse the target application service to obtain multiple design models corresponding to the target application service. Each design model is one of the following: microservice model, application model, and entity model.

[0017] The mapping relationship determination module is used to establish mapping relationships from the design model to the package directory according to the preset engineering structure specifications, and to obtain the engineering structure of the target application service. Each package directory is set with a hierarchical attribute.

[0018] The code template file acquisition module is used to convert each entity model into a corresponding code template file according to a preset coding specification. The code template file is stored in the project package corresponding to the package directory of the entity model.

[0019] The model data acquisition module is used to acquire model data for each of the design models;

[0020] The code structure determination module is used to map all the model data to the code template file according to the mapping relationship to obtain the code structure;

[0021] The project structure generation module is used to organize multiple code structures into corresponding package directories according to the project structure defined in the mapping relationship, thereby forming the project structure of the target application service.

[0022] Thirdly, the present invention provides an electronic device, the electronic device comprising:

[0023] At least one processor; and

[0024] A memory communicatively connected to the at least one processor; wherein,

[0025] The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the standardized project document generation method described in the first aspect of the present invention.

[0026] Fourthly, the present invention provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the standardized project file generation method described in the first aspect of the present invention.

[0027] The standardized project file generation method provided in this invention obtains and parses a target application service to obtain multiple design models corresponding to the target application service. Each design model is one of a microservice model, an application model, and an entity model. According to preset engineering structure specifications, a mapping relationship from the design model to the package directory is established to obtain the engineering structure of the target application service. Each package directory has hierarchical attributes. According to preset coding specifications, each entity model is converted into a corresponding code template file, which is stored in the project package corresponding to the package directory of the entity model. Model data for each design model is obtained. All model data is mapped to the code template file according to the mapping relationship to obtain the code structure. According to the engineering structure defined in the mapping relationship, the code structure is organized into the corresponding package directory to form the project structure of the target application service.

[0028] Its beneficial effects include at least:

[0029] First, by analyzing the design model (microservices, applications, entities) and establishing a precise mapping with the package directory, the engineering structure standard is enforced from the source, effectively preventing engineering structure disorder.

[0030] Second, the pre-defined coding standards are transformed into executable code template files, and the final code is automatically generated by populating the model data. This process frees developers from repetitive boilerplate code writing, greatly improving development efficiency, shortening project start-up and delivery cycles, and avoiding basic errors caused by manual coding, thus significantly improving the inherent quality of the code and work efficiency.

[0031] Third, this method can transform abstract software design models into concrete code implementations, ensuring a high degree of consistency between design and implementation. Through standardization and automation, it guarantees the predictability and maintainability of the software deliverables.

[0032] It should be understood that the description in this section is not intended to identify key or essential features of the embodiments of the present invention, nor is it intended to limit the scope of the invention. Other features of the invention will become readily apparent from the following description. Attached Figure Description

[0033] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0034] Figure 1 This is a flowchart of a standardized project document generation method provided by an embodiment of the present invention;

[0035] Figure 2 This is a schematic diagram illustrating the mapping relationship between a design model and a package directory, provided in an embodiment of the present invention.

[0036] Figure 3 This is a schematic diagram illustrating the mapping relationship between a design model and a coding standard provided in an embodiment of the present invention;

[0037] Figure 4 This is a schematic diagram illustrating how an engineering structure and code structure are obtained through a conversion engine, as provided in an embodiment of the present invention.

[0038] Figure 5 This is an overall flowchart of a standardized project document generation method provided by an embodiment of the present invention;

[0039] Figure 6 This is a schematic diagram of the structure of a standardized project document generation device provided in an embodiment of the present invention;

[0040] Figure 7 This is a schematic diagram of the structure of the electronic device provided in an embodiment of the present invention. Detailed Implementation

[0041] To enable those skilled in the art to better understand the present invention, the technical solutions of the present invention will be clearly and completely described below with reference to the accompanying drawings of the embodiments of the present invention. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present invention.

[0042] To facilitate understanding of the technical solutions of this application, some of the terms used in this application are explained below:

[0043] Project structure: A modular architecture is used to manage all development assets, such as independent service directories under a microservice architecture, and CI / CD pipelines are defined through Jenkinsfile to achieve automated deployment.

[0044] Code structure: Contains only the implementation code of a single function, and requires dependency declaration and interface specification definition at the project level. For example, it is mandatory to store all API interfaces in the / api / v1 directory to avoid scattering.

[0045] Figure 1 This is a flowchart illustrating a method for generating standardized project documents according to an embodiment of the present invention. This embodiment is applicable to situations where standardized project documents are automatically generated based on existing standard specifications and model data. This method can be executed by a standardized project document generation device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the method for generating standardized project documents includes:

[0046] S101. Obtain the target application service and parse it to obtain multiple design models corresponding to the target application service. Each design model is one of the microservice model, application model and entity model.

[0047] Obtain the abstract design definition of the target application service and parse it. After parsing, output multiple design models corresponding to the application service. These design models are the basis for subsequent engineering structure and code structure generation. In this embodiment, they are specifically defined as microservice model, application model, and entity model.

[0048] The microservice model describes the global boundaries and configuration of services, such as service name (UserService), service group (member-group), service port (8080), and required database type (MySQL).

[0049] The application model defines the business components within the service. For example, this user service includes two business application modules: UserRegistrationApp (user registration application) and UserQueryApp (user query application).

[0050] Entity models correspond to the core data objects in the business domain. For example, they identify two entities: User and Role. The User entity might contain attributes such as userId, username, and password; the Role entity might contain attributes such as roleId and roleName.

[0051] S102. Obtain the target application service and parse it to obtain multiple design models corresponding to the target application service. Each design model is one of the microservice model, application model and entity model.

[0052] Based on predefined engineering structure specifications, a mapping relationship is established between each design model parsed in step S101 and a specific package directory. An example is shown below:

[0053] Microservice model: src / main / java / com / example / service;

[0054] Entity model: src / main / java / com / example / domain / entity.

[0055] Each package directory has hierarchical attributes, such as "root directory", "source code directory", "resource file directory", etc., or "first-level package directory", "second-level package directory", "third-level package directory", etc. Through the collection of these mapping relationships, a complete and standardized blueprint for the target application service engineering structure is finally formed.

[0056] For a microservices model, these can be mapped to the project's root directory and configuration directory, for example:

[0057] / user-service (root directory);

[0058] / user-service / src / main / resources (configuration file directory).

[0059] For application models, they can be mapped to the package directory of the application service layer, for example:

[0060] / user-service / src / main / java / com / example / user / service (service layer package).

[0061] For entity models, they can be mapped to package directories in the data model layer and data access layer, for example:

[0062] / user-service / src / main / java / com / example / user / domain / entity (entity class package);

[0063] / user-service / src / main / java / com / example / user / repository (data access layer package).

[0064] S103. Convert each entity model into a corresponding code template file according to the preset coding specifications. The code template file is stored in the project package corresponding to the package directory of the entity model.

[0065] According to predefined coding standards (such as naming conventions, class structure, annotation usage, etc.), each entity model is converted into a corresponding executable code template file. These code template files contain skeleton code of variable placeholders, such as a User.java template file corresponding to the "User" entity model. The generated code template files are stored in the physical or logical project package corresponding to the package directory mapped to in step S102 for that entity model.

[0066] S104. Obtain the model data for each design model.

[0067] Retrieve the specific model data for each design model (including microservice model, application model, and entity model). This data is the substantial content that populates the code template file. For example, for the entity model, its model data might include the entity name "User", the attribute list "id, name, email", etc.

[0068] S105. Map all model data to the code template file according to the mapping relationship to obtain the code structure.

[0069] Based on the mapping relationship established in step S102, all model data obtained in step S104 are automatically filled and replaced in the corresponding variable placeholders in the code template file generated in step S103. This process instantiates the abstract template into a concrete, compileable, and runnable code structure, which is the code file.

[0070] S106. Based on the project structure defined in the mapping relationship, organize the code structure into the corresponding package directory to form the project structure of the target application service.

[0071] Based on the project structure defined by the mapping relationship in step S102, all code files generated in step S105 are automatically and systematically organized and placed into the corresponding package directories. Ultimately, this results in a project structure for the target application service that is complete, clearly hierarchical, and can be directly imported into the integrated development environment for subsequent development.

[0072] The standardized project file generation method provided in this invention obtains and parses a target application service to obtain multiple design models corresponding to the target application service. Each design model is one of a microservice model, an application model, and an entity model. According to preset engineering structure specifications, a mapping relationship from the design model to the package directory is established to obtain the engineering structure of the target application service. Each package directory has hierarchical attributes. According to preset coding specifications, each entity model is converted into a corresponding code template file, which is stored in the project package corresponding to the package directory of the entity model. Model data for each design model is obtained. All model data is mapped to the code template file according to the mapping relationship to obtain the code structure. According to the engineering structure defined in the mapping relationship, the code structure is organized into the corresponding package directory to form the project structure of the target application service.

[0073] Its beneficial effects include at least:

[0074] First, by analyzing the design model (microservices, applications, entities) and establishing a precise mapping with the package directory, the engineering structure standard is enforced from the source, effectively preventing engineering structure disorder.

[0075] Second, the pre-defined coding standards are transformed into executable code template files, and the final code is automatically generated by populating the model data. This process frees developers from repetitive boilerplate code writing, greatly improving development efficiency, shortening project start-up and delivery cycles, and avoiding basic errors caused by manual coding, thus significantly improving the inherent quality of the code and work efficiency.

[0076] Third, this method can transform abstract software design models into concrete code implementations, ensuring a high degree of consistency between design and implementation. Through standardization and automation, it guarantees the predictability and maintainability of the software deliverables.

[0077] In an optional embodiment, the package directory includes a first-level package directory, a second-level package directory, and a code structure package directory, with the code structure package directory being a subdirectory of the second-level package directory. Based on a preset engineering structure specification, mapping relationships from the design model to the package directory are established, including: establishing a mapping relationship from the microservice model to the first-level package directory; establishing a mapping relationship from the application model to the second-level package directory; and establishing a mapping relationship from the entity model to the code structure package directory. The engineering structure of the target application service is obtained based on the mapping relationships between the microservice model, application model, entity model, and package directory.

[0078] In software engineering, a clear and standardized package directory structure is crucial for maintaining the readability and maintainability of a project. Traditional code generation tools may have a coarse-grained approach to directory hierarchy, failing to accurately map design models at different levels of abstraction to their corresponding physical directories. This invention solves this problem by introducing a hierarchical package directory mapping mechanism.

[0079] In this optional embodiment, the project package directory is divided into more refined hierarchical levels, specifically defined as follows:

[0080] The first-level package directory represents the top-level directory in a project, typically corresponding to a microservice module or the root directory of the top-level project. It defines the physical boundaries of the services. The second-level package directory is a subdirectory of the first-level package directory, typically corresponding to application modules or core business components. It organizes the main functional modules under the first-level directory. The code structure package directory is a subdirectory of the second-level package directory and is the direct storage location for specific code files (such as entity classes, controllers, etc.). It corresponds to specific layers in the architecture (such as the data layer, service layer, and control layer).

[0081] The microservice model represents a global concept of the entire service and is the highest level of design abstraction. Mapping it to a first-level package directory ensures that each microservice has an independent and complete physical space in the file system, achieving service-level physical isolation.

[0082] The application model defines the core business capabilities (i.e., application modules) within a microservice. Mapping these to secondary package directories ensures that each core business module has its own clearly defined namespace within the code structure, facilitating modular development and maintenance.

[0083] Entity models are concrete business data objects that need to be placed in packages at a specific architectural level. Mapping them to code structure package directories allows for the precise location of business concepts to their specific technical implementations, ensuring strict adherence to architectural layering.

[0084] After establishing the mapping relationship between the design model and the package directory, the hierarchical relationship between each package directory and the table directory determines the engineering structure of the target application service.

[0085] In an optional embodiment, a startup project directory is created under the first-level directory project corresponding to each microservice model. The startup project directory contains service configuration files, startup configuration information, and unified service publishing configuration.

[0086] In microservice development, a complete service requires not only business logic code but also a series of infrastructure code and configuration files to support its independent operation, configuration, and management. In traditional development, these startup classes and configuration files need to be manually created and maintained by developers, a cumbersome process prone to errors or omissions, resulting in an incomplete project structure that cannot be started directly. This optional embodiment solves the above problems by automatically creating a standardized startup project directory in the microservice's first-level directory. This startup project directory is a pre-configured, directly executable module.

[0087] In an optional embodiment, based on the project structure defined in the mapping relationship, the code structure is organized into the corresponding package directories to form the project structure of the target application service, including:

[0088] Based on the mapping relationship, determine the package directory corresponding to each entity model; inject the model data into the code template file under the package directory to obtain a standardized code structure; organize the code structure according to the project structure to form the project structure of the target application service.

[0089] The core of this embodiment lies in using the established mapping relationship as an "assembly blueprint" to guide the entire project structure generation process. It clarifies three key actions: locating the catalog, filling the template, and overall assembly, ensuring that the final output project structure is accurate, complete, and conforms to specifications.

[0090] In an optional embodiment, the model data is injected into a code template file in the package directory to obtain a standardized project file, including:

[0091] The model data is injected into the code template file in the package directory; the model conversion engine performs template rendering on the code template file to generate a standardized code structure.

[0092] First, the model data is injected into the code template file in the package directory; this step is the rendering initialization phase. The system first performs location, that is, finds the specific code template file in the target package directory based on the mapping relationship. Then, data preparation is performed, establishing a connection between the acquired structured model data (usually JSON, XML, or specific data objects) and the found template file. At this point, the data and the template are two independent parts to be merged.

[0093] Then, the model conversion engine performs template rendering on the code template file to generate standardized project files. The model conversion engine is an independent processing module that can understand and execute complex logic instructions embedded in the template.

[0094] Template rendering: The engine takes over the template files and data models prepared in the previous step, and its workflow is as follows:

[0095] 1. Parsing: The engine parses the template file and identifies the static text and dynamic instructions within it.

[0096] 2. Data Binding and Execution: The engine binds the data model to template instructions. For variables, they are directly replaced; for logical instructions, they are executed based on the actual data. For example, if the data contains a list, the engine will execute a loop instruction to generate a corresponding code snippet for each item in the list.

[0097] 3. Output Synthesis: The engine combines the processed static text and the dynamic content generated by the executed instructions into a complete, correctly formatted plain text file, which is the final standardized project file.

[0098] In an optional embodiment, the entity model includes at least one of a class model, a service model, an interface model, an enumeration model, an exception model, a data structure model, and an association class model.

[0099] The class model represents core data objects or "nouns" in the business domain, such as User and Product. They are the carriers of business data. The service model represents specific business capabilities or "verbs," such as UserService and PaymentService. They encapsulate core business logic. The interface model defines the contract between services or components, emphasizing abstraction and decoupling, such as IUserFacade. The enumeration model represents a fixed, predefined set of values, such as OrderStatusEnum, enhancing code readability and type safety. The exception model represents specific error conditions in the system, such as UserNotFoundException, implementing fine-grained error handling. The data structure model can be used for DTOs or VOs in API transmission, such as UserVO, optimizing the structure of internal and external data exchange. The association class model represents supporting components such as configuration classes and factory classes.

[0100] Beneficial effects: Through this diversified definition, the code generation capability of this invention extends from generating a single data layer to all structural parts of the entire application. This means that the system can simultaneously generate a complete set of immediately usable standardized code for a business concept (such as "user"), including data objects, service interfaces, business implementations, exception definitions, and state enumerations, achieving truly comprehensive and three-dimensional code generation, significantly improving the completeness and efficiency of development.

[0101] In an optional embodiment, the entity model includes at least one structure selected from the control layer, business logic layer, data layer, and model layer.

[0102] The controller layer contains classes such as UserController, which are responsible for receiving external requests, processing parameters, and invoking business logic. The controller layer is mapped to the ... / controller / directory.

[0103] The business logic layer is responsible for implementing core business rules and processes. The business logic layer is mapped to the ... / facade / directory.

[0104] The data layer contains interfaces such as UserAppService and its implementation classes, responsible for interacting with the database. The data layer is mapped to the ... / appservice / directory.

[0105] The model layer contains the class model, enumeration model, etc., from Embodiment 1 above, serving as objects for data transfer and sharing between layers. The model layer is mapped to the ... / domain / or ... / model / directory.

[0106] The implementation example defines the entity model from a software layered architecture perspective, which ensures that the generated code is not just an independent unit, but a whole that conforms to the predetermined architectural specifications, has clear layers, and distinct responsibilities.

[0107] To clearly illustrate the process and technical effects of the standardization project document generation method in this application, the following example is used for explanation:

[0108] Step 1: Analyze and solidify the company's engineering and code structures.

[0109] 1. Solidify Engineering Relationship Standards: By reviewing the company's engineering structure standards and combining them with the microservice model and application model in application service design, we confirmed that the microservice engineering structure is a multi-level engineering structure. The microservice model corresponds to the first-level directory project of the code project, and the application model corresponds to the second-level directory project of the code project. To ensure that the microservice is deployed as a whole, all projects are uniformly published as services. A startup project is added under the first-level directory project of each microservice. The startup project contains the relevant service configuration files and startup configuration information required by the service. Figure 2 This is a schematic diagram illustrating the mapping relationship between a design model and package directories. The first-level directory project is... Figure 2 The microservice project directory in the document, the second-level directory project is... Figure 2 Application project directory.

[0110] 2. Solidify Code Structure Standards: By reviewing the company's code structure standards and considering the module models, classes, services, interfaces, data structures, exceptions, enumerations, and related class models in application service design, a multi-layered code structure pattern conforming to company standards was confirmed. The main code structure consists of a control layer, business logic layer, data layer, and model layer. Different layers correspond to different code package standard names, such as... Figure 2 As shown, the control layer is called controller, the business logic layer is called facade, the data layer is called appservice, and the model layer is called model. Different model types also differ in their included layers and corresponding package paths according to the specification, as detailed below:

[0111] The class model includes a controller layer, a business logic layer, a data layer, and a model layer, with corresponding code project package directory names controller, facade, appservice, and model;

[0112] The service model includes a control layer and a business logic layer, with the corresponding code project package directory names being controller and facade;

[0113] The interface model includes a business logic layer, and the corresponding code project package directory name is facade;

[0114] The related class model includes a data layer and a model layer, and the corresponding code project package directory names are appservice and model;

[0115] The data structure model includes a model layer, and the corresponding code project package directory name is model;

[0116] The exception model includes a model layer, and the corresponding code project package directory name is exception.

[0117] The enumeration model contains a model layer, and the corresponding code project package directory name is enumeration;

[0118] Step 2: Streamline the company's coding standards and solidify them into code templates.

[0119] By reviewing the company's coding standards and combining them with the relevant models of classes, services, interfaces, data structures, exceptions, enumerations, and related classes in application service design, the coding standards are solidified into code templates to ensure their effective implementation. Figure 3 This is a schematic diagram illustrating the mapping relationship between a design model and coding standards, such as... Figure 3 As shown, different models correspond to different coding standards, and the specific application of these standards is as follows:

[0120] Class and Interface Naming Conventions: Based on the code structure above, different model types correspond to different naming conventions. The specific mapping relationship is as follows: Class model naming convention is Class model name + Controller, Class model name + Facade, Class model name + AppService, Class model name + VO; Service model naming convention is Service model name + Controller, Service model name + Facade; Interface model naming convention is I + Interface model name + Facade; Exception model naming convention is Exception model name + Exception; Enum model naming convention is Enum model name + Enum.

[0121] Variable naming rules: These mainly include naming rules for constants, class variables, local variables, and parameters. The specific implementation involves setting the naming rules for constants, class variables, local variables, and parameters directly in the code template. For example, constants are configured directly in the code template as `public static final String constant_name=constant_value`.

[0122] Scope rules mainly include the scope of classes, methods, properties, and local variables. The specific implementation of these rules involves setting the scope rules for classes, methods, properties, and local variables directly in the code template. For example, if a VO object's property variable must use the `private` scope modifier, it will be configured directly in the code template as `private + property type + property name in English`.

[0123] Code formatting rules: These mainly include rules for code alignment (starting at the top), copyright statement, indentation, curly braces, blank lines, spaces, import statements, and numbers. These rules can also be configured directly in the code template. For example, the copyright statement can be entered as a fixed statement starting from the first line of the code template.

[0124] Step 3: Design model output integration, outputting an engineering structure and code structure that conforms to company specifications. In the application service design, microservices, applications, modules, classes, services, interfaces, enumerations, exceptions, data structures, and related classes are integrated with the engineering structure and code structure defined above according to company specifications. Through the design model data and standard templates, a standardized and normalized code engineering structure and code structure are output through the model conversion engine. Figure 4 This is a schematic diagram illustrating how a conversion engine can transform an engineering structure and a code structure.

[0125] Figure 5 A general flowchart generated for a standardized project document, in general, such as Figure 5As shown, the specific solution of this application is to define the relationship between enterprise-level microservices, applications, and development engineering structures, as well as the relationship between modules, classes, services, interfaces, exceptions, enumerations, data structures, and related classes and code templates, by taking over the model data of the design model of microservices, applications, modules, classes, services, interfaces, exceptions, enumerations, data structures, and related classes in the application service design. Furthermore, code inspection rules and code hierarchical specifications are built into the code templates to achieve the output of engineering code that meets code control requirements from the design model to the development engineering code. This achieves the following technical effects:

[0126] 1. It standardizes the output of engineering and code structures required by enterprises, making it easier for developers to understand and develop, and reducing the problems of software maintenance difficulties and errors caused by differences in code structure.

[0127] 2. Improved the efficiency of converting design models into development project structures and code, facilitating rapid writing of business logic and reducing the time spent on project structure construction, project dependency construction, and project code coding.

[0128] 3. It standardized the application of coding standards in enterprise code engineering, effectively reducing errors in code style during development.

[0129] 4. It improves the correctness and effectiveness of the design model, allowing for quick previewing of development code and early verification of the design model's correctness. It can also serve as a "bridge" for communication between designers and developers, improving communication efficiency.

[0130] Corresponding to the above-described method for generating standardized project documents, this application also provides a device for generating standardized project documents. Figure 6 This is a schematic diagram of a standardized project document generation device provided in an embodiment of the present invention. Figure 6 As shown, the standardized project document generation device includes:

[0131] The design model acquisition module 601 is used to acquire and parse the target application service to obtain multiple design models corresponding to the target application service. Each design model is one of a microservice model, an application model, and an entity model.

[0132] The mapping relationship determination module 602 is used to establish mapping relationships from the design model to the package directory according to the preset engineering structure specifications, and to obtain the engineering structure of the target application service. Each package directory is set with a hierarchical attribute.

[0133] The code template file acquisition module 603 is used to convert each entity model into a corresponding code template file according to a preset coding specification. The code template file is stored in the project package corresponding to the package directory of the entity model.

[0134] The model data acquisition module 604 is used to acquire model data for each of the design models;

[0135] The code structure determination module 605 is used to map all the model data to the code template file according to the mapping relationship to obtain the code structure;

[0136] The project structure generation module 606 is used to organize multiple code structures into corresponding package directories according to the project structure defined in the mapping relationship, thereby forming the project structure of the target application service.

[0137] Optionally, the package directory includes a first-level package directory, a second-level package directory, and a code structure package directory, wherein the code structure package directory is a subdirectory of the second-level package directory;

[0138] The mapping relationship determination module 602 is used for:

[0139] Establish a mapping relationship from the microservice model to the first-level package directory;

[0140] Establish a mapping relationship from the application model to the secondary package directory;

[0141] Establish a mapping relationship from the entity model to the code structure package directory;

[0142] The engineering structure of the target application service is obtained based on the mapping relationship between the microservice model, the application model, the entity model, and the package directory.

[0143] Optionally, the standardized project document generation device further includes:

[0144] The startup project directory creation module is used to create a startup project directory under the first-level directory project corresponding to each microservice model. The startup project directory contains service configuration files, startup configuration information, and unified service release configuration.

[0145] Optionally, the project structure generation module 606 includes:

[0146] The package directory determination submodule is used to determine the package directory corresponding to each entity model based on the mapping relationship;

[0147] The code structure determination submodule is used to inject the model data into the code template file under the package directory to obtain a standardized code structure.

[0148] The project structure generation submodule is used to organize the code structure according to the project structure to form the project structure of the target application service.

[0149] Optionally, the code structure defines submodules for:

[0150] Inject the model data into the code template file in the package directory;

[0151] The code template file is rendered using a model conversion engine to generate standardized project files.

[0152] Optionally, the entity model includes at least one of the following: class model, service model, interface model, enumeration model, exception model, data structure model, and association class model.

[0153] Optionally, the entity model includes at least one structure selected from the control layer, business logic layer, data layer, and model layer.

[0154] The standardized project document generation device provided in this embodiment of the invention can execute the standardized project document generation method provided in any embodiment of the invention, and has the corresponding functional modules and beneficial effects of the method.

[0155] Reference Figure 7 The diagram illustrates an electronic device according to an embodiment of the present invention. Figure 7 As shown, the electronic device in this embodiment of the invention includes: a processor, a memory, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the steps in the above-described embodiment of the standardized project document generation method. Alternatively, when the processor executes the computer program, it implements the functions of each module in the above-described embodiment of the standardized project document generation apparatus.

[0156] For example, the computer program may be divided into one or more modules, which are stored in the memory and executed by the processor to complete this application. The one or more modules may be a series of computer program instruction segments capable of performing a specific function, which can be used to describe the execution process of the computer program in the electronic device.

[0157] The electronic device may be a desktop computer, a cloud server, or other computing device. The electronic device may include, but is not limited to, a processor and memory. Those skilled in the art will understand that... Figure 7 This is merely one example of an electronic device and does not constitute a limitation on the electronic device. It may include more or fewer components than illustrated, or combine certain components, or different components. For example, the electronic device may also include input / output devices, network access devices, buses, etc.

[0158] The processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0159] The memory can be an internal storage unit of the electronic device, such as a hard drive or RAM. Alternatively, it can be an external storage device, such as a plug-in hard drive, Smart Media Card (SMC), Secure Digital (SD) card, Flash Card, etc. Furthermore, the memory can include both internal and external storage units. The memory is used to store the computer program and other programs and data required by the electronic device. The memory can also be used to temporarily store data that has been output or will be output.

[0160] This invention also discloses an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the standardized project file generation method as described in the foregoing embodiments.

[0161] This invention also discloses a computer-readable storage medium storing a computer program that, when executed by a processor, implements the standardized project file generation method as described in the foregoing embodiments.

[0162] This invention also discloses a computer program product that, when run on a computer, causes the computer to execute the standardized project file generation method described in the foregoing embodiments.

[0163] The embodiments described above are only used to illustrate the technical solutions of this application, and are not intended to limit it. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. A method for generating standardized project documents, characterized in that, include: Obtain and parse the target application service to obtain multiple design models corresponding to the target application service. Each design model is one of the following: microservice model, application model, and entity model. According to the preset engineering structure specifications, a mapping relationship from the design model to the package directory is established respectively, and the engineering structure of the target application service is obtained. Each package directory is set with hierarchical attributes. Each entity model is converted into a corresponding code template file according to the preset coding specifications, and the code template file is stored in the project package corresponding to the package directory of the entity model; Obtain the model data for each of the design models; Based on the mapping relationship, all the model data is mapped to the code template file to obtain the code structure; Based on the project structure defined in the mapping relationship, multiple code structures are organized into the corresponding package directories to form the project structure of the target application service.

2. The method as described in claim 1, characterized in that, The package directory includes a first-level package directory, a second-level package directory, and a code structure package directory, wherein the code structure package directory is a subdirectory of the second-level package directory; The step of establishing mapping relationships from the design model to the package directory according to preset engineering structure specifications includes: Establish a mapping relationship from the microservice model to the first-level package directory; Establish a mapping relationship from the application model to the secondary package directory; Establish a mapping relationship from the entity model to the code structure package directory; The engineering structure of the target application service is obtained based on the mapping relationship between the microservice model, the application model, the entity model, and the package directory.

3. The method as described in claim 2, characterized in that, Also includes: Create a startup project directory under the first-level directory project corresponding to each microservice model. The startup project directory contains service configuration files, startup configuration information, and unified service publishing configuration.

4. The method according to claim 1, characterized in that, The step of organizing multiple code structures into corresponding package directories according to the project structure defined in the mapping relationship to form the project structure of the target application service includes: Based on the mapping relationship, determine the package directory corresponding to each entity model; The model data is injected into the code template file under the package directory to obtain a standardized code structure; The code structure is organized according to the engineering structure to form the project structure of the target application service.

5. The method according to claim 4, characterized in that, The step of injecting the model data into the code template file under the package directory to obtain a standardized code structure includes: Inject the model data into the code template file in the package directory; The code template file is rendered using a model conversion engine to generate a standardized code structure.

6. The method according to any one of claims 1-5, characterized in that, The entity model includes at least one of the following: class model, service model, interface model, enumeration model, exception model, data structure model, and association class model.

7. The method according to any one of claims 1-5, characterized in that, The entity model includes at least one structure of the control layer, business logic layer, data layer, and model layer.

8. A standardized project document generation device, characterized in that, include: The design model acquisition module is used to acquire and parse the target application service to obtain multiple design models corresponding to the target application service. Each design model is one of the following: microservice model, application model, and entity model. The mapping relationship determination module is used to establish mapping relationships from the design model to the package directory according to the preset engineering structure specifications, and to obtain the engineering structure of the target application service. Each package directory is set with a hierarchical attribute. The code template file acquisition module is used to convert each entity model into a corresponding code template file according to a preset coding specification. The code template file is stored in the project package corresponding to the package directory of the entity model. The model data acquisition module is used to acquire model data for each of the design models; The code structure determination module is used to map all the model data to the code template file according to the mapping relationship to obtain the code structure; The project structure generation module is used to organize multiple code structures into corresponding package directories according to the project structure defined in the mapping relationship, thereby forming the project structure of the target application service.

9. An electronic device, characterized in that, The electronic device includes: At least one processor; and A memory communicatively connected to the at least one processor; wherein, The memory stores a computer program that can be executed by the at least one processor, the computer program being executed by the at least one processor to enable the at least one processor to perform the standardized project document generation method according to any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the standardized project document generation method according to any one of claims 1-7.

Images