Class model inspection method, electronic equipment, storage medium and product

Abstract

The invention discloses a class model inspection method, electronic equipment, a storage medium and a product. The method comprises the steps of obtaining context information of a target micro-service application in response to a class model check request from a client; performing class model compliance check based on the context information to generate a corresponding error check result; wherein the class model compliance check comprises at least one of the following items: class member reference validity check, interface and abstract method implementation integrity check, technical suite compatibility check, class name uniqueness check and request path uniqueness check; sending an error checking result to the client for visual display; receiving a correction instruction from the client; the correction instruction is associated with a target error item in the error checking result; and executing a response operation corresponding to the correction instruction. According to the scheme, the multi-dimensional compliance check is executed based on the micro-service context, and the class model design quality and efficiency are improved through visual interaction and intelligent response.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a class model checking method, electronic device, storage medium, and product. Background Technology

[0002] In the current software design and development model, after designers design or modify the class model in a microservice architecture, they typically need to manually perform specification checks using various independent tools. Existing technologies mainly focus on shallow checks such as syntax validation and infrastructure checks, which have the following obvious limitations: First, they lack the ability to deeply check design semantics and business logic, and cannot effectively identify key design defects such as unimplemented interface methods or invalid class references; second, the checking and correction stages are disconnected, and tools can only report errors but cannot provide quick location and one-click correction functions, resulting in low correction efficiency; third, existing solutions lack compatibility and scalability, making it difficult to adapt to the complex technology stack changes and customized specification requirements in enterprise-level R&D platforms. Summary of the Invention

[0003] This invention provides a class model checking method, electronic device, storage medium, and product to solve the problems of insufficient class model checking depth, low error correction efficiency, and poor compatibility with development platforms in the prior art.

[0004] According to one aspect of the present invention, a class model checking method is provided, the method comprising:

[0005] In response to a class model check request from the client, obtain the context information of the target microservice application; the context information includes a first set of identifiers for all class models under the target microservice application, and a second set of identifiers for all class models that the target microservice application depends on.

[0006] The class model compliance check is performed based on context information to generate corresponding error check results; the class model compliance check includes at least one of the following: class member reference validity check, interface and abstract method implementation integrity check, technology suite compatibility check, class name uniqueness check, and request path uniqueness check;

[0007] The error check results are sent to the client for visual display.

[0008] Receive correction instructions from the client; the correction instructions are associated with the target error item in the error check results;

[0009] Execute the response operation corresponding to the correction instruction.

[0010] According to another aspect of the present invention, a model checking apparatus is provided, the apparatus comprising:

[0011] The signal acquisition module is used to obtain the context information of the target microservice application in response to the class model check request from the client. The context information includes a first set of identifiers for all class models under the target microservice application, and a second set of identifiers for all class models that the target microservice application depends on.

[0012] The inspection module is used to perform class model compliance checks based on context information to generate corresponding error check results; wherein, the class model compliance checks include at least one of the following: class member reference validity check, interface and abstract method implementation integrity check, technology suite compatibility check, category name uniqueness check, and request path uniqueness check;

[0013] The results display module is used to send the error checking results to the client for visual display.

[0014] The instruction receiving module is used to receive correction instructions from the client; the correction instructions are associated with the target error item in the error check results.

[0015] The response execution module is used to execute the response operations corresponding to the correction instructions.

[0016] According to another aspect of the present invention, an electronic device is provided, the electronic device comprising:

[0017] At least one processor; and

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

[0019] 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 class model checking method according to any embodiment of the present invention.

[0020] According to another aspect of the present invention, a computer-readable storage medium is provided, the computer-readable storage medium storing computer instructions for causing a processor to execute and implement the class model checking method according to any embodiment of the present invention.

[0021] According to another aspect of the present invention, a computer program product is provided, the computer program product comprising a computer program that, when executed by a processor, implements the class model checking method described in any embodiment of the present invention.

[0022] The technical solution of this invention involves obtaining context information of the target microservice application in response to a class model check request from a client. The context information includes a first set of identifiers for all class models under the target microservice application and a second set of identifiers for all class models that the target microservice application depends on. Based on the context information, a class model compliance check is performed to generate corresponding error check results. The class model compliance check includes at least one of the following: class member reference validity check, interface and abstract method implementation integrity check, technology suite compatibility check, category name uniqueness check, and request path uniqueness check. The error check results are sent to the client for visualization. A correction instruction is received from the client. The correction instruction is associated with a target error item in the error check results. A response operation corresponding to the correction instruction is executed. This technical solution performs multi-dimensional compliance checks based on the microservice context, which can accurately identify semantic layer design defects that traditional tools cannot find. Through visual interaction and intelligent response, it completely changes the passive mode of traditional inspection tools that "only report errors and do not fix them", freeing designers from tedious manual investigation and forming a new quality control paradigm from "post-event discovery" to "in-event prevention and intelligent handling". At the same time, the inspection process is adapted to the rules of the current software development collaboration platform, and has good adaptability and scalability.

[0023] 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

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

[0025] Figure 1 This is a flowchart of a class model checking method provided by an embodiment of the present invention;

[0026] Figure 2 This is a visualization of the error checking results provided by an embodiment of the present invention;

[0027] Figure 3 This is a visualization of a class member reference error provided by an embodiment of the present invention;

[0028] Figure 4 This is a visualization of an unimplemented method error provided by an embodiment of the present invention;

[0029] Figure 5 This is a visualization of a technology kit mismatch error provided in an embodiment of the present invention;

[0030] Figure 6 This is a visualization of the error of duplicate category name or duplicate request path provided by an embodiment of the present invention;

[0031] Figure 7 This is a schematic diagram of a model checking device according to an embodiment of the present invention;

[0032] Figure 8 This is a schematic diagram of the structure of an electronic device that implements the class model checking method of this invention. Detailed Implementation

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

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this invention are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of the invention described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] Existing class model checking methods have the following main shortcomings:

[0036] (1) Lack of semantic logic detection: Existing tools and technologies can only verify simple syntax and structure based on general rules, and cannot detect whether the design intent and business logic are correct, nor can they be customized for different actual application scenarios, ultimately leading to inconsistencies between the visual appearance of the product and the required functionality. The lack of context-aware rule sets and the use of general rules cannot adapt to different scenario requirements. Developers need to write custom rules themselves, and these custom rules also need to be adapted to existing tools, which greatly increases the development time.

[0037] (2) Addressing Automation Shortcomings: Existing inspection tools only report problems without providing quick location, modification, and saving functions, requiring users to manually adjust the output, thus negating the value of automation. This results in higher maintenance costs, slower efficiency, and a poor user experience. A few tools that support automatic correction employ simplistic modification strategies, lack context awareness, and use hard-coded rules, making them unsuitable for complex scenarios and even introducing new problems.

[0038] (3) Insufficient technical compatibility and scalability: Existing SVG (Scalable Vector Graphics) inspection and correction technologies rely heavily on third-party tools. While these tools provide basic functionality, over-reliance on them leads to limited compatibility and insufficient scalability, affecting the flexibility and long-term maintenance of enterprise applications. Existing tools lack modular plugins, have fixed detection and optimization rules, and cannot flexibly integrate new features.

[0039] To solve the above problems, Figure 1 This is a flowchart illustrating a class model checking method provided in an embodiment of the present invention. This embodiment is applicable to the automated checking of class model design results for microservice applications. The method can be executed by a class model checking device, which can be implemented in hardware and / or software and can be configured in an electronic device. Figure 1 As shown, the class model checking method provided in this embodiment specifically includes the following steps:

[0040] S110. In response to a class model check request from the client, obtain the context information of the target microservice application; the context information includes a first set of identifiers for all class models under the target microservice application, and a second set of identifiers for all class models that the target microservice application depends on.

[0041] The client can refer to the front-end interactive interface of the software design collaboration platform (such as the class model design canvas, project management page, etc.), which allows users to initiate class model inspection requests, view inspection results, and perform correction operations. It is the carrier for interaction between users and the server.

[0042] A class model check request can be a client-initiated instruction that triggers the server to perform a class model compliance check; it serves as the initiation signal for the entire class model check process. A class model, in object-oriented design, is a structured blueprint used to describe classes in a software system. It defines information such as class attributes, methods, inheritance relationships, and implemented interfaces. Class model types can include ordinary classes, data structure classes, service classes, and interface classes. Ordinary classes and data structure classes have attributes, while ordinary classes, service classes, and interface classes have methods.

[0043] The target microservice application can refer to the microservice unit that needs to undergo class model compliance checks. It is the core object of the check process, has a unique identifier, and can contain multiple business modules and corresponding class models.

[0044] Context information can refer to a set of data describing the scope and dependency boundaries of the class models of the target microservice application, providing basic data support for subsequent verification. Context information may include a first set of identifiers for all class models under the target microservice application (representing the complete scope of the class models to be checked), and a second set of identifiers for all class models that the target microservice application depends on (representing the scope of dependencies that the class models can legally reference).

[0045] In this embodiment of the invention, the server can continuously listen for class model check requests sent by the client. These requests carry a unique identifier (such as microservice ID, application code, etc.) of the target microservice application to be checked. Upon receiving the request, the server locates the specific target microservice application in the system metadata database (a database storing the relationships between applications, modules, and class models) or configuration center based on the parsed target microservice application identifier. It then determines the project, subsystem level, and all module information contained within the microservice. Within the located target microservice application, it queries all its class model definition files or database records, summarizing the unique identifiers (such as class model IDs) of the queried class models to form a first identifier set. Furthermore, by parsing the dependency management configuration file of the target microservice project or querying the inter-microservice dependencies registered in the platform, it obtains the unique identifiers of all external class models declared as dependencies (such as classes from other microservices, public libraries, third-party SDKs, etc.), summarizing them to form a second identifier set. Finally, the first and second identifier sets are integrated to form complete context information. This context information provides the core data foundation and scope definition for subsequent execution of various specific compliance checks.

[0046] S120. Perform class model compliance checks based on context information to generate corresponding error check results; wherein, the class model compliance checks include at least one of the following: class member reference validity check, interface and abstract method implementation integrity check, technology suite compatibility check, category name uniqueness check, and request path uniqueness check.

[0047] Class model compliance checks refer to the systematic and automated verification of class model design outcomes based on predefined software design specifications and architectural constraints. Class model compliance checks may include at least one of the following: class member reference validity checks, used to verify the legality of class models referenced by attributes and methods of the class model, determining whether they are within the second set of dependent identifiers, and filtering out class models with invalid references; interface and abstract method implementation integrity checks, used to verify whether the class model fully implements the abstract methods of the inherited abstract parent class and the unimplemented methods of the implemented interfaces (including parent interfaces); technology suite compatibility checks, used to verify whether the technology suite identifiers of the parent class or interface associated with the class model belong to the technology suite set bound to the project to which the target microservice application belongs, filtering out class models with mismatched suites; category name uniqueness checks, used to check whether there are duplicate category names of class models within a specified detection range; and request path uniqueness checks, used to verify whether the complete request path of the service interface method is duplicated for ordinary class models / service class models containing service interface methods.

[0048] Error checking results can refer to a structured data set generated after the server performs a class model compliance check. It systematically records all class model design defects found in the target microservice application. For example, error checking results can include: error metadata (such as error identifier, error severity level, error generation timestamp), error semantic information (such as error type classification identifier, specific error description text, error repair suggestion prompt), and location association information (such as associated class model ID, full path of class model, specific error location), etc.

[0049] In this embodiment of the invention, based on the aforementioned context information of the target microservice application, multi-dimensional and in-depth class model compliance checks can be performed, such as at least one of the following checks: class member reference validity check, interface and abstract method implementation integrity check, technology suite compatibility check, category name uniqueness check, and request path uniqueness check, and corresponding error check results can be generated to record all class model design defects found in the target microservice application.

[0050] S130. Send the error check results to the client for visual display.

[0051] In this embodiment of the invention, after completing all specified class model compliance checks, the server can send the generated error check results to the requesting client. This allows the client to render and display the received error check results in a multi-dimensional and visual manner on a designated display interface. For example, visualization methods may include, but are not limited to: ① Clearly categorizing and displaying all error items (error records) in a list format in a separate sidebar or panel, facilitating quick browsing of global issues; ② Automatically locating the erroneous class model primitives (graphical boxes representing class models) in the graphical design canvas and highlighting them by changing their visual style (e.g., red borders, flashing, or adding error icons), allowing designers to intuitively see the problem in the original design. Furthermore, each error item can be configured with a correction entry point for user correction operations. For example, a "One-Click Import" button can be displayed next to an unimplemented method error, triggering the subsequent automated correction process when clicked by the user.

[0052] S140, Receive a correction instruction from the client; the correction instruction is associated with the target error item in the error check results.

[0053] In this context, a correction instruction can refer to a structured data request generated by the client based on the user's action on a target error item, used to trigger a server-side correction action. For example, the instruction may contain information such as the unique identifier of the target error item, the error type, and user operation parameters, serving as the medium connecting user interaction and automated correction. The target error item can refer to a specific error record selected by the user from the error checking results that requires correction.

[0054] In this embodiment of the invention, the server can continuously listen for network requests from the client. When a correction instruction is received, it can quickly query and match the error check result set generated by this class model check based on the unique identifier of the target error item parsed from the instruction, and obtain the complete information of the error item, such as including but not limited to: error type (e.g., unimplemented method error), class model identifier where the error is located, and specific details of the error (e.g., a list of missing method signatures).

[0055] S150, Execute the response operation corresponding to the correction instruction.

[0056] The response operation can refer to a series of automated or auxiliary operations performed by the server after receiving the correction instruction, which are aimed at fixing defects in the class model, such as highlighting and locating the erroneous class model primitives or popping up a class editing window on the client.

[0057] In this embodiment of the invention, the server can perform corresponding response operations differently according to the type of the target error item in the correction instruction (such as class member reference error, unimplemented method error, kit mismatch error, duplicate category name or path error, etc.). For example, for class member reference errors, the system will locate the invalid class model referenced by the error item and send an instruction to the client, requiring it to highlight the primitive corresponding to the invalid class model in the graphical design canvas (such as highlighting in red or flashing), thereby guiding the user to manually repair the reference relationship. For kit mismatch errors, the system will send an instruction to the client to pop up a parent model batch configuration pop-up window. This pop-up window will list all class models with this problem. After the user performs the corresponding configuration operation in the pop-up window, the system will batch update the technology kit reference relationship of the parent class or interface of these class models to ensure that it is consistent with the project configuration.

[0058] The technical solution of this invention, by performing multi-dimensional compliance checks based on microservice context, can accurately identify semantic layer design defects that traditional tools cannot detect; by dynamically associating error items with graphical design elements and providing intelligent correction methods such as one-click import and batch configuration, it completely changes the traditional passive mode of "only reporting errors and not fixing them", freeing designers from tedious manual troubleshooting; at the same time, with built-in technology suite compatibility checks and an extensible inspection framework, it ensures the high adaptability and long-term maintainability of the solution in complex enterprise-level R&D environments, ultimately forming a new quality control paradigm from "post-event discovery" to "in-process prevention and intelligent handling".

[0059] Furthermore, based on the above embodiments of the invention, performing a class member reference validity check includes:

[0060] From the class models corresponding to the first set of identifiers, class models that meet the first preset filtering conditions are selected to generate a first type of error record; wherein, the first preset filtering conditions include at least: the type of the class model is a general class or a data structure class, and the class model contains at least one illegal reference attribute; the illegal reference attribute includes the attribute type is generic or class model, and the class model identifier referenced by the attribute type is not in the second set of identifiers;

[0061] From the class models corresponding to the first set of identifiers, class models that meet the second preset filtering conditions are selected to generate a second type of error record; wherein, the second preset filtering conditions include at least: the type of the class model is a normal class, a service class, or an interface class, and the class model contains at least one illegal reference method; the illegal reference method includes a method whose parameter type is generic or a class model, and the class model identifier referenced by the parameter type is not in the second set of identifiers, or a method whose return value type is generic or a class model, and the class model identifier referenced by the return value type is not in the second set of identifiers;

[0062] Based on the first type of error record and the second type of error record, generate a list of class member reference errors.

[0063] The first preset filtering condition can be understood as a predefined rule used to filter class models containing illegal reference properties, specifically designed to catch property reference errors.

[0064] The first type of error record can refer to a set of error data specifically recording class models containing illegal reference attributes. This set can record information such as the identifier of the erroneous class model, the illegal attribute name, and the invalid class model identifier referenced by the attribute.

[0065] An illegal reference property can refer to a property whose type is generic or class model, but the class model that the type specifically points to is not in the set of valid second identifiers, that is, it references an unauthorized or invalid class model.

[0066] The second preset filtering condition can be understood as a predefined rule used to filter class models that contain illegal method references, specifically designed to catch method reference errors.

[0067] The second type of error record can refer to a set of error data specifically recording class models that contain illegal method references. This set can record information such as the identifier of the erroneous class model, the illegal method name and signature, and the invalid class model identifier referenced by the method's parameters or return value.

[0068] An illegal method reference can refer to a method whose parameters or return values ​​are of generic or class model type, but the specific class model that the type points to is not in the valid second set of identifiers. In other words, the method's input / output references an unauthorized or invalid class model.

[0069] A class member reference error list can be a structured list that integrates the first type of error records and the second type of error records. Errors can be associated with class models in this list, and the error type and full path information can be marked.

[0070] In this embodiment of the invention, the specific execution process of class member reference validity checking includes:

[0071] (1) Extract the first set of identifiers (i.e., the unique set of identifiers of all class models under the target microservice application) from the context information to lock the scope of class models to be checked; simultaneously extract the second set of identifiers (i.e., the unique set of identifiers of all class models that the target microservice application has declared to depend on in the design phase) to define the scope of legal references.

[0072] (2) From all the class models to be checked, select the class models that meet the first preset filtering conditions and generate the first type of error record. Specifically, first select ordinary classes and data structure classes from all the class models to be checked (because only these two types of models have attributes); then, traverse each attribute of these class models and check its type; if the type of the attribute is generic or class model, the system will check whether the class model identifier referenced by the attribute exists in the second identifier set; if it does not exist, the attribute is determined to be an illegal reference attribute; finally, collect all class models containing illegal reference attributes, and mark each record with key information (such as the class model identifier that has an error, the name of the illegal reference attribute, the attribute type, the invalid class model identifier referenced, etc.) to form the first type of error record.

[0073] (3) From all the class models to be checked, select the class models that meet the second preset filtering conditions and generate the second type of error record. Specifically, first select ordinary classes, service classes and interface classes from all the class models to be checked (because only these three types of models have methods); then, traverse each method of these class models and check each parameter type and return value type in its parameter list; if these types are generics or class models, the system will check whether the class model identifiers referenced by these types exist in the second identifier set; if they do not exist, the method is determined to be an illegal reference method; finally, collect all class models containing illegal reference methods and mark each record with key information (such as class model identifier, illegal reference method name, parameter type / return value type, invalid class model identifier referenced, etc.) to form the second type of error record.

[0074] (4) Associate and integrate the first type of error records and the second type of error records according to the class model identifier. If the same class model has both attribute reference errors and method reference errors, merge the two types of errors into a unified entry under the class model. Add error type tags (such as illegal attribute reference, illegal method parameter reference, illegal method return value reference) to the integrated list, and supplement the full path information of the class model (such as project / subsystem / microservice / module / class name). Finally, generate a structured class member reference error list for subsequent visualization display to the client.

[0075] This invention, by performing class member reference validity checks, can accurately identify and warn of dependency errors such as "class not found," which are traditionally only exposed during code compilation or runtime, at the software design stage. By comparing the actual references of the class model with the scope of legal dependencies, it can effectively locate illegal reference attributes and methods caused by the deletion or movement of the class model or incorrect dependency configuration. This prevents the spread of design errors to downstream development stages from the source, significantly reduces later repair costs, and improves the accuracy of the software design model and the overall efficiency of the development process.

[0076] Furthermore, based on the above embodiments of the invention, the integrity check is implemented by performing interface and abstract method checks, including:

[0077] Obtain the inheritance and interface implementation relationships of all class models corresponding to the first set of identifiers; where the inheritance relationship includes a list of abstract parent classes of the class model, and the interface implementation relationship includes a list of implemented interfaces of the class model;

[0078] Iterate through each class model in the first set of identifiers, and perform the following operations based on the list of abstract parent classes and the list of implemented interfaces of the current class model:

[0079] Retrieve the implemented methods in the current class model and generate a set of signatures for the implemented methods;

[0080] If the abstract parent class list is not empty, extract all abstract methods declared by the abstract parent classes in the abstract parent class list to generate a set of abstract parent class methods to be implemented;

[0081] Iterate through each interface in the implementation interface list, recursively obtain all parent interfaces in the inheritance chain of each interface, and extract all methods to be implemented declared in each interface and each parent interface to generate a set of methods to be implemented for the interface.

[0082] Merge and deduplicate the set of methods to be implemented in the abstract parent class and the set of methods to be implemented in the interface to generate a set of method signatures to be implemented in the current class model;

[0083] The set of implemented method signatures is compared with the set of unimplemented method signatures to generate a list of unimplemented methods for the current class model.

[0084] Based on the list of unimplemented methods for all class models, generate a list of unimplemented method errors.

[0085] Inheritance relationship can refer to the parent-child inheritance relationship between a class model and an abstract parent class. Specifically, it can be represented by a list of abstract parent classes, which records the unique identifiers of all abstract parent classes inherited by the current class model and is the core basis for abstract method checking.

[0086] Interface implementation relationship can refer to the implementation association between a class model and an interface (i.e., the class model promises to implement all methods declared in the interface). Specifically, it can be represented by a list of implemented interfaces, which records the unique identifiers of all interfaces directly implemented by the current class model and is the core basis for interface method checking.

[0087] The set of implemented method signatures can refer to the collection of method signatures of all methods that have been written in the current class model. The method signature can be generated by combining the method name, parameter type, and return value type, and is the core basis for determining whether a method has been implemented.

[0088] The set of abstract parent class methods to be implemented can refer to the collection of signatures of all abstract methods gathered from all abstract parent classes of the current class model. These methods are the methods that the current class model must enforce.

[0089] An interface inheritance chain can refer to one or more inheritance paths that start from one interface and trace back to all its parent interfaces.

[0090] The set of methods to be implemented in an interface can refer to the collection of signatures of all methods declared in all interfaces that are implemented by the current class model and their entire inheritance chain (parent interfaces). These methods must also be implemented by the current class model.

[0091] The set of signatures for methods to be implemented can refer to the set obtained by merging the set of methods to be implemented in the abstract parent class and the set of methods to be implemented in the interface, and removing duplicate signatures. It represents all the methods that the current class model must implement according to the design rules, and serves as the benchmark for integrity checks.

[0092] The unimplemented method list can refer to a list of all missing method signatures found by comparing the set of signatures of methods to be implemented with the set of signatures of implemented methods. It records the integrity defects of the current class model, that is, the set of methods that the current class model has not yet implemented but must be implemented according to the rules.

[0093] The unimplemented method error list can be a structured list that summarizes all unimplemented methods of all class models. This list can record the class model identifier and the details of the corresponding unimplemented method.

[0094] In this embodiment of the invention, the specific execution flow of the integrity check implemented by the interface and abstract method includes:

[0095] (1) Obtain the inheritance relationship and interface implementation relationship of all class models corresponding to the first identifier set, specifically including the list of abstract parent classes and the list of implemented interfaces declared by each type of model.

[0096] (2) Perform the following operations on each class model in the first set of identifiers:

[0097] ① Obtain all methods that have been written in the current class model, and generate a unique method signature based on the combination of method name + parameter class + return type, forming a set of implemented method signatures.

[0098] ② If the list of abstract parent classes of the current class model is not empty (i.e. there are abstract parent classes that need to be inherited), then extract all the abstract methods declared by the abstract parent classes in the list, and summarize the signatures of these abstract methods into a set of methods to be implemented by the abstract parent classes.

[0099] ③ Iterate through each (direct) interface in the current class model implementation interface list, and recursively trace the extension chain of each interface (i.e., all parent interfaces inherited by the interface), extract the methods to be implemented declared in the direct interface and all parent interfaces, and summarize them to generate a set of interface methods to be implemented.

[0100] ④ Merge the set of methods to be implemented in the abstract parent class with the set of methods to be implemented in the interface, and delete duplicate method signatures to form a set of method signatures that the current class model must implement.

[0101] ⑤ Compare the set of implemented method signatures with the set of unimplemented method signatures, filter out the method signatures that do not appear in the set of implemented method signatures, record the name, signature and the abstract parent class / interface to which these unimplemented methods belong, and form the list of unimplemented methods of the current class model.

[0102] (3) After traversing all class models, summarize the list of unimplemented methods of all class models. For example, it can be organized according to the structure of "class model identifier - details of unimplemented methods" to generate the corresponding list of unimplemented method errors, and use it as the final result of the interface and abstract method implementation integrity check for subsequent front-end display or automatic correction.

[0103] This invention implements integrity checks by executing interfaces and abstract methods. This allows for precise early warning and correction of unimplemented method errors, which are typically only exposed during code compilation or runtime, at the software design stage. The check recursively traces the entire inheritance chain of the interface, ensuring that all abstract methods to be implemented in the class model are calculated without omission and automatically compared with implemented methods. This completely solves the design flaws caused by ignoring deep interface contracts, fundamentally preventing errors from spreading to the development stage, significantly reducing rework costs, and realizing a paradigm shift from "post-event manual inspection" to "pre-event automatic prevention" in quality control.

[0104] Furthermore, based on the above embodiments of the invention, a technology kit compatibility check is performed, including:

[0105] Obtain the set of technology suite identifiers bound to the target project to which the target microservice application belongs;

[0106] Retrieve the technology suite identifier of the parent class or interface associated with each class model in the first identifier set;

[0107] Filter out class models whose technology kit identifiers are not in the technology kit identifier set, and generate a technology kit mismatch error list.

[0108] The target project can refer to the overall development project to which the target microservice application belongs, which includes multiple collaborative microservices and has a unified technology selection.

[0109] A technology suite identifier set can refer to a collection of unique identifiers for the technology suites that are pre-bound to and permitted by the target project, representing the range of technology components allowed by the project's technical specifications. A technology suite identifier can be a string or code used to uniquely identify a specific technology suite, such as springboot-2.7 or jdk-11.

[0110] The technology kit mismatch error list can be a structured data list that records all class model information that uses technology kits that are not allowed in the project. This list may include information such as class model identifier, associated parent class / interface name, and incompatible kit identifier.

[0111] In this embodiment of the invention, the specific execution process of the technology kit compatibility check includes:

[0112] (1) The server can determine the target project to which the target microservice application belongs based on its identifier; then it can query all the technology suite identifiers bound to the target project from the project's configuration data (such as the project configuration database) to form a set of technology suite identifiers. Among them, the technology suite identifier is used to uniquely identify a specific technology framework, version or platform specification.

[0113] (2) Based on the first set of identifiers, traverse all class models under the target microservice application. For each class model, obtain the parent class and interface information it inherits by analyzing its metadata, and then obtain the unique identifier of the technology suite to which these parent classes and interfaces belong. Record the technology suite identifier of the parent class / interface corresponding to each class model, and then establish the mapping relationship between class models and technology suites.

[0114] (3) Compare the technology kit identifier associated with each class model with the set of technology kit identifiers configured in the target project, and filter out those class models whose technology kit identifiers are not within the scope allowed by the project.

[0115] (4) For the detected incompatible class models, the key information such as the class model identifier, full path information, and incompatible technology kit identifier can be extracted, and a technology kit mismatch error list can be generated according to a predetermined format.

[0116] By performing technology suite compatibility checks, this invention ensures that all class models in a microservice application strictly adhere to the unified technical framework and version specifications of the project. It prevents component integration conflicts and runtime anomalies caused by inconsistent technology stacks from the design source. It exposes and resolves technical compatibility issues that are typically only discovered during coding, testing, or even deployment phases in traditional development processes, significantly reducing later repair costs and the risk of accumulating technical debt. At the same time, it provides a unified technical standard compliance guarantee for parallel development by multiple teams, effectively improving the consistency and maintainability of the system architecture.

[0117] Furthermore, based on the above embodiments of the invention, a uniqueness check of the category name is performed, including:

[0118] Determine the scope of the category name uniqueness check and obtain the corresponding global class model set based on the scope of the check; the scope of the check includes all class models under the target microservice application, as well as class models in all project-level common applications and subsystem-level common applications under the target project to which the target microservice application belongs;

[0119] Filter out class models with duplicate category names from the global class model collection and generate a duplicate category name error list.

[0120] Among them, project-level public applications can refer to basic public services or component applications that are shared and referenced by all other microservices or applications under a project.

[0121] Subsystem-level public applications refer to public platform services or core component applications that are shared and referenced by all projects within a specific subsystem (which may contain multiple projects). They are at a higher level than project-level public applications.

[0122] The global class model set can refer to the collection of all class models extracted from all public applications defined in the scope of the inspection. It is the data basis for performing class name uniqueness checks and request path uniqueness checks.

[0123] The category name duplicate error list can be a structured list that records all class models with duplicate category names. This list can contain information such as class model identifier, duplicate category name, and application / module to which it belongs. It is the output result of the category name uniqueness check.

[0124] In this embodiment of the invention, the specific execution process for category name uniqueness checking includes:

[0125] (1) First, define the boundaries of this inspection. Unlike inspecting only a single microservice application, the scope of the category name uniqueness inspection is expanded to the entire target project. Specifically, the inspection scope covers all class models under the target microservice application, as well as the class models in all project-level common applications and subsystem-level common applications under the target project to which the target microservice application belongs. These common applications are usually shared and referenced by all or multiple microservices within the project and are high-risk areas for naming conflicts.

[0126] (2) After clarifying the scope of inspection, a query can be initiated to the database based on the scope of inspection determined in the first step. The query will obtain all modules under all these specified public applications, and further obtain all class models defined in these modules. Finally, a global class model set is formed, which represents all class models that need to be inspected within the given scope of inspection.

[0127] (3) Perform database aggregation operations on the obtained global class model collection to find class models with duplicate category names.

[0128] (4) Integrate all the selected duplicate aliases and their corresponding class model information (such as class model identifier, full path, application, etc.), and generate a list of duplicate category names in a predetermined format. This list clearly indicates which category names have conflicted and all class models involved in the conflict, providing accurate data support for subsequent corrections.

[0129] This invention extends the scope of category name uniqueness checks from individual microservice applications to all public applications at the project and subsystem levels. By using aggregated query technology, it automatically and accurately detects category name duplication conflicts globally, thereby preventing integration and runtime errors that may result from naming conflicts in the early design phase. This fundamentally improves the efficiency of multi-team collaborative design, as well as the overall stability and maintainability of the system.

[0130] Furthermore, based on the above embodiments of the invention, performing a request path uniqueness check includes:

[0131] Retrieve the global class model set obtained when performing a uniqueness check on the class name;

[0132] Select class models of type ordinary class or service class that contain service interface methods from the global class model set to generate a subset of class models to be checked;

[0133] Iterate through each class model in the subset of class models to be checked and perform the following operations:

[0134] Extract the class-level request path defined in the current class model, and the method-level request path defined in each service interface method under the current class model;

[0135] The class-level request path is concatenated with the corresponding method-level request path to generate the complete request path for each service interface method.

[0136] Filter out duplicate paths from all complete request paths and generate a list of duplicate path errors.

[0137] Among them, service interface methods can refer to interface methods marked in the class model as providing services to the outside world, which at least include REST interface methods.

[0138] The subset of class models to be checked can refer to the set of class models selected from the global class model set that are of type ordinary class / service class and contain service interface methods. It is the direct processing object for request path uniqueness checking.

[0139] A class-level request path can refer to the basic request path defined at the class model level, serving as the path prefix for all service interface methods under that class.

[0140] Method-level request paths can refer to sub-request paths defined at the service interface method level. These paths are concatenated with class-level request paths to form a complete access path, used to distinguish different interface methods under the same class.

[0141] The path duplication error list can be a structured list that records all duplicate complete request paths. This list can contain information such as duplicate path content, corresponding class model identifier (to which application / module), and service interface method name. It is the output result of the request path uniqueness check.

[0142] In this embodiment of the invention, the specific execution process for request path uniqueness checking includes:

[0143] (1) Obtain the global class model set generated during the execution of the class name uniqueness check, which covers all class models under the target microservice application, project-level public application, and subsystem-level public application.

[0144] (2) Select class models that meet the following two conditions from the global class model set to generate a subset of class models to be checked: ① The type of the class model is a normal class or a service class; ② The class model contains service interface methods, such as REST interface methods.

[0145] (3) Traverse each class model in the subset of class models to be checked and perform the following operations respectively:

[0146] ① Obtain the class-level request path defined in the design phase of the current class model, and extract the method-level request path defined individually for each service interface method under the current class model.

[0147] ② Concatenate the class-level request path and the method-level request path corresponding to the same service interface method according to the rules to generate the complete request path for each service interface method.

[0148] (4) Collect the complete request paths of all service interface methods and filter out the duplicate complete request paths; organize all the detected duplicate paths, along with their corresponding class models and method information, to generate a detailed list of duplicate path errors.

[0149] This invention, by performing a unique request path check, can proactively prevent and eliminate service routing conflicts caused by duplicate API paths during the software design phase, thereby fundamentally avoiding serious failures such as unavailability of related microservices at runtime. At the same time, this check ensures the standardization and uniqueness of API paths globally through automation, freeing developers from tedious and error-prone manual verification, and significantly improving the quality, consistency, and efficiency of interface design and development processes.

[0150] Furthermore, based on the above embodiments of the invention, the response operation corresponding to the correction instruction is performed, including at least one of the following:

[0151] If the target error is an error generated by the class member reference validity check, then the primitive corresponding to the class model associated with the target error will be highlighted in the client's graphical design canvas.

[0152] If the target error is an error generated by the interface and abstract method implementation integrity check, a class editing pop-up window will pop up on the client side. In response to the user's selection of importing unimplemented methods in the class editing pop-up window, the unimplemented methods will be imported into the class model corresponding to the target error.

[0153] If the target error is an error generated by the technology suite compatibility check, a parent model batch configuration pop-up window will appear on the client, and in response to the user's configuration operation in the parent model batch configuration pop-up window, the parent class configuration information of the class model associated with the target error will be adjusted in batches.

[0154] If the target error is an error generated by a category name uniqueness check or a request path uniqueness check, then the corresponding primitive of the class model associated with the target error will be highlighted in the client's graphical design canvas.

[0155] The graphical design canvas refers to the area in the client user interface used for visually displaying and editing class model design drawings, and can support operations such as dragging, editing, and marking errors in class models.

[0156] Primitives can refer to visual graphic elements that represent a class model (such as a class or interface) in a graphical design canvas.

[0157] Highlighting can refer to a technique in graphical design canvases that uses visual enhancement methods (such as special borders or background colors) to highlight the class model primitives associated with the target error item, helping users quickly locate the error position.

[0158] A class editing pop-up can refer to a client-side interactive interface that appears when there is an error in the implementation completeness of an interface or abstract method. Within this pop-up, users can choose the method to be imported.

[0159] The parent model batch configuration pop-up can refer to a client-side interactive interface that pops up in response to a technology suite compatibility error. This pop-up allows users to configure the parent class information of class models in batches.

[0160] In this embodiment of the invention, after receiving a specific correction instruction from the client, the corresponding response operation can be executed precisely according to different error types. Specifically, the response operation may include at least one of the following:

[0161] (1) If the target error is identified as an error found by the class member reference validity check, for example, a class references another class that has been deleted or does not exist, then in the client's graphical design canvas, the primitives corresponding to the class model directly related to the target error will be highlighted (e.g., turned red or flashing), so as to accurately indicate the error location to the user and assist them in making manual corrections.

[0162] (2) If the error is identified as an error found by the interface and abstract method implementation integrity check, such as a class not implementing all the methods declared in its interface or abstract parent class, a specific class editing window will be triggered in the client. In the pop-up window, the system will list all the methods that the current class has not implemented. The user can select the methods to be imported by checking boxes or other means. After the user confirms, the system will automatically generate these methods and add them to the method list of the class model corresponding to the target error, thereby achieving one-click quick correction.

[0163] (3) If the error is identified as an error found by the technology suite compatibility check, such as the technology suite to which the parent class of the class inherits does not conform to the project specifications, the server will trigger the client to pop up a parent model batch configuration pop-up window. This window will centrally display all class models with such problems. Users can select a unified and correct technology suite in the interface. After the user confirms, the system will automatically and in batches update the parent class reference configuration of these class models and switch them to the specified technology suite, thereby efficiently solving the technology suite compatibility problem.

[0164] (4) If the error is identified as an error found by the category name uniqueness check or the request path uniqueness check, such as the existence of duplicate category names or request paths, the primitives corresponding to the class model that caused the duplicate error will be highlighted in the client's graphical design canvas, thereby quickly guiding the user to locate the source of the conflict so that the category name or request path can be manually modified.

[0165] This invention, through its embodiments, intelligently executes corresponding response operations based on the error type of the target error item, transforming design correction from a manual search and scattered processing approach into a focused, one-stop, seamless experience, greatly improving the efficiency of problem-solving and user experience during the software design phase.

[0166] In one embodiment, this technical solution provides an automated verification and correction technique based on a software design collaboration platform, applicable to real-world design scenarios. This technique focuses on microservices and class model method attributes, accurately detecting problems in the class model and promptly alerting the user. It efficiently and quickly fixes these problems, ensuring the correctness of the final output. This improves upon the traditional "post-event discovery" and "human-assisted investigation" methods by shifting to "prevention" and "intelligent processing," effectively enhancing the efficiency of design collaboration. The specific steps of this technical solution are as follows:

[0167] S1. Obtain the list of class members affected when moving or deleting a class model:

[0168] S1.1 Obtain all class model IDs (i.e., class model IDs to be checked) under the target microservice application to obtain the first set of identifiers;

[0169] S1.2 Obtain all class model IDs that the target microservice application depends on, and obtain the first set of identifiers;

[0170] S1.3 Obtaining the class model attribute problem to be checked: Since only ordinary class models and data structure class models have attributes, we can first filter out ordinary class models and data structure class models from the class models corresponding to the first identifier set by constructing an aggregate function to query the database; then, by adding filtering conditions: the attribute type is generic and class model, and the dependent class model ID is not in the second identifier set, we can filter out class models containing illegal reference attributes and obtain the first type of error record;

[0171] S1.4 Obtaining the class model method to be checked: Since ordinary class models, service class models, and interface class models have methods, we can first filter out these three types from the class models corresponding to the first identifier set by constructing an aggregate function to query the database; then, by adding filtering conditions: the parameter and return value types are generic and class model, and the dependent class model ID is not in the second identifier set, we can filter out the class models containing illegal reference methods and obtain the second type of error record;

[0172] S1.5 Integrate the first type of error records and the second type of error records, and add the full path of the class to generate a list of class member reference errors for front-end page display.

[0173] S2. Obtain the class model of unimplemented interfaces and parent class abstract methods:

[0174] S2.1. Based on the microservice application where the target class is located, obtain all class model information under that microservice application;

[0175] S2.2 Based on the class set, construct an aggregate function to query the database, filter out the inherited abstract parent classes, interfaces, and implementation classes inherited by the parent classes, and obtain the list of abstract parent classes and the list of implementation interfaces of the class model;

[0176] S2.3. Based on the query results from the previous step, construct a list of unimplemented methods:

[0177] S2.3.1. Traverse all methods of the current class model, record the signature IDs of the implemented methods, and generate a set of implemented method signatures;

[0178] S2.3.2 If the list of abstract parent classes is not empty and the parent class of the current class is an abstract class, then calculate the abstract methods of all abstract parent classes and generate a set of abstract parent class methods to be implemented.

[0179] S2.3.3 If the parent class of the current class model is a regular class, no processing is required;

[0180] S2.3.4. Traverse the list of implemented interfaces of the current class model, query the parent interfaces of all interfaces to be implemented, extract the methods that all parent interfaces need to implement, and generate a set of interface methods to be implemented.

[0181] S2.3.5. Compare the set of implemented method signatures with the set of unimplemented method signatures, filter out the method signatures that do not appear in the set of implemented method signatures, and form a list of unimplemented methods for the current class model;

[0182] S2.4 Summarize the list of unimplemented methods for all class models and construct an error list of unimplemented methods for display on the front-end page.

[0183] S3. The queried data is associated with parent class information that is not in the current project suite:

[0184] S3.1 Obtain the set of technology suite identifiers bound to the target project to which the target microservice application belongs;

[0185] S3.2. Based on the retrieved set of technology kit identifiers, construct an aggregate function to query the database and retrieve the class models whose parent class and interface kit IDs are not in the set of technology kit identifiers;

[0186] S3.3 Integrate all incompatible class models from all kits and add the full path of the class to generate a list of technology kit mismatch errors for front-end page display.

[0187] S4. Retrieve class models with duplicate aliases based on the class model ID set:

[0188] S4.1 Since the validation of category name and path needs to take into account all class models under the current microservice application, as well as all class models under the project-level common application and subsystem-level common application, it is necessary to first query all project-level common applications and subsystem-level common applications under the current project to generate a set of application IDs.

[0189] S4.2. Based on the retrieved set of application IDs, query the set of all modules under each application;

[0190] S4.3 Extract the module ID set from the retrieved module set, and query all class models under each module to generate a global class model set;

[0191] S4.4. Perform "$group" and "$match" aggregation queries on the database to filter out class models with duplicate category names;

[0192] S4.5 Integrate all class models with duplicate category names, add the full path of the class, and generate a list of duplicate category name errors for front-end page display.

[0193] S5. Retrieve the class model with duplicate request paths based on the class model ID set:

[0194] S5.1 Based on the global class model set generated by S4.3, the class models containing REST interfaces are first filtered out through database aggregation operations. Since only ordinary class models and service class models have methods, ordinary class models and service models are further filtered out from the above filtering results to generate a subset of class models to be checked.

[0195] S5.2 Continue filtering out class models containing REST methods from the subset of class models to be checked;

[0196] S5.3. Concatenate the class-level request path of the class model filtered out in S5.2 with the corresponding method-level request path to generate the corresponding complete request path (i.e., full path), and filter out duplicate full paths.

[0197] S5.4 Integrate all class models with duplicate complete request paths, add the full path of the class, and generate a list of duplicate path errors for front-end page display.

[0198] S6. Send the generated error check results to the client for visualization.

[0199] The error checking results specifically include the aforementioned list of class member reference errors, list of unimplemented methods errors, list of technology suite mismatch errors, list of duplicate category names errors, and list of duplicate paths errors. In one embodiment, the visualization effect is as follows: Figure 2 As shown.

[0200] S7. If a user clicks on a detection error indicating that a parameter-type class model has been deleted or is outside the dependency scope, the corresponding class model's primitive will be highlighted in red on the client's canvas. The specific effect is as follows: Figure 3 As shown.

[0201] S8. If a user clicks on a check for unimplemented interfaces, a class editing pop-up will appear on the client side, allowing the user to select the unimplemented methods to import for quick location and correction. The specific effect is as follows: Figure 4 As shown.

[0202] S9. If a user clicks on the error detection indicating that the parent model's suite has been switched, a batch configuration pop-up window for the parent model will be triggered on the client side. This pop-up displays all class models with this problem and allows users to batch adjust the parent model's configuration information, thus greatly improving work efficiency. The specific effect is as follows: Figure 5 As shown.

[0203] S10. If a user clicks on a duplicate category name or request path, the corresponding incorrect class model primitive will be highlighted in red on the canvas. This allows the user to quickly locate and correct the error before continuing with the design. The specific effect is as follows: Figure 6 As shown.

[0204] This technical solution has at least the following beneficial effects:

[0205] (1) Enhanced semantic logic detection capabilities: It can perform more comprehensive and timely detection of different attributes of class models according to the specific requirements of the application design of the software development collaboration platform. Based on the specific relationship patterns between models, it performs aggregated query detection from the syntax layer to the design intent layer, making the logic more rigorous and improving the efficiency of the user design process.

[0206] (2) Complete closed loop of automated detection and correction: This technical solution provides rapid location and jump to different detection problems, as well as batch correction function. From simple optimization to intelligent modification of logic preservation, it greatly reduces manual debugging time and the error rate of the model design results is also reduced.

[0207] (3) Comprehensive coverage of technical compatibility: It is more compatible with the rules of the current software development collaboration platform, changing from "fragmented" verification to "unified and adapted" verification, with a wider coverage and a more complete verification system. At the same time, the scalability has also changed from the previous "closed" to the easily modifiable "plug-in", allowing developers to more easily and quickly access more verification rules.

[0208] Figure 7 This is a schematic diagram of a model checking device provided in an embodiment of the present invention. Figure 7 As shown, the device includes:

[0209] The signal acquisition module 21 is used to obtain the context information of the target microservice application in response to the class model check request from the client; the context information includes a first set of identifiers of all class models under the target microservice application, and a second set of identifiers of all class models that the target microservice application depends on.

[0210] The inspection module 22 is used to perform class model compliance checks based on context information to generate corresponding error check results; wherein, the class model compliance checks include at least one of the following: class member reference validity check, interface and abstract method implementation integrity check, technology suite compatibility check, category name uniqueness check, and request path uniqueness check;

[0211] The result display module 23 is used to send the error check results to the client for visual display;

[0212] The instruction receiving module 24 is used to receive correction instructions from the client; the correction instructions are associated with the target error item in the error check results;

[0213] The response execution module 25 is used to execute the response operation corresponding to the correction instruction.

[0214] Furthermore, based on the above embodiments of the invention, performing a class member reference validity check includes:

[0215] From the class models corresponding to the first set of identifiers, class models that meet the first preset filtering conditions are selected to generate a first type of error record; wherein, the first preset filtering conditions include at least: the type of the class model is a general class or a data structure class, and the class model contains at least one illegal reference attribute; the illegal reference attribute includes the attribute type is generic or class model, and the class model identifier referenced by the attribute type is not in the second set of identifiers;

[0216] From the class models corresponding to the first set of identifiers, class models that meet the second preset filtering conditions are selected to generate a second type of error record; wherein, the second preset filtering conditions include at least: the type of the class model is a normal class, a service class, or an interface class, and the class model contains at least one illegal reference method; the illegal reference method includes a method whose parameter type is generic or a class model, and the class model identifier referenced by the parameter type is not in the second set of identifiers, or a method whose return value type is generic or a class model, and the class model identifier referenced by the return value type is not in the second set of identifiers;

[0217] Based on the first type of error record and the second type of error record, generate a list of class member reference errors.

[0218] Furthermore, based on the above embodiments of the invention, the integrity check is implemented by performing interface and abstract method checks, including:

[0219] Obtain the inheritance and interface implementation relationships of all class models corresponding to the first set of identifiers; where the inheritance relationship includes a list of abstract parent classes of the class model, and the interface implementation relationship includes a list of implemented interfaces of the class model;

[0220] Iterate through each class model in the first set of identifiers, and perform the following operations based on the list of abstract parent classes and the list of implemented interfaces of the current class model:

[0221] Retrieve the implemented methods in the current class model and generate a set of signatures for the implemented methods;

[0222] If the abstract parent class list is not empty, extract all abstract methods declared by the abstract parent classes in the abstract parent class list to generate a set of abstract parent class methods to be implemented;

[0223] Iterate through each interface in the implementation interface list, recursively obtain all parent interfaces in the inheritance chain of each interface, and extract all methods to be implemented declared in each interface and each parent interface to generate a set of methods to be implemented for the interface.

[0224] Merge and deduplicate the set of methods to be implemented in the abstract parent class and the set of methods to be implemented in the interface to generate a set of method signatures to be implemented in the current class model;

[0225] The set of implemented method signatures is compared with the set of unimplemented method signatures to generate a list of unimplemented methods for the current class model.

[0226] Based on the list of unimplemented methods for all class models, generate a list of unimplemented method errors.

[0227] Furthermore, based on the above embodiments of the invention, a technology kit compatibility check is performed, including:

[0228] Obtain the set of technology suite identifiers bound to the target project to which the target microservice application belongs;

[0229] Retrieve the technology suite identifier of the parent class or interface associated with each class model in the first identifier set;

[0230] Filter out class models whose technology kit identifiers are not in the technology kit identifier set, and generate a technology kit mismatch error list.

[0231] Furthermore, based on the above embodiments of the invention, a uniqueness check of the category name is performed, including:

[0232] Determine the scope of the category name uniqueness check and obtain the corresponding global class model set based on the scope of the check; the scope of the check includes all class models under the target microservice application, as well as class models in all project-level common applications and subsystem-level common applications under the target project to which the target microservice application belongs;

[0233] Filter out class models with duplicate category names from the global class model collection and generate a duplicate category name error list.

[0234] Furthermore, based on the above embodiments of the invention, performing a request path uniqueness check includes:

[0235] Retrieve the global class model set obtained when performing a uniqueness check on the class name;

[0236] Select class models of type ordinary class or service class that contain service interface methods from the global class model set to generate a subset of class models to be checked;

[0237] Iterate through each class model in the subset of class models to be checked and perform the following operations:

[0238] Extract the class-level request path defined in the current class model, and the method-level request path defined in each service interface method under the current class model;

[0239] The class-level request path is concatenated with the corresponding method-level request path to generate the complete request path for each service interface method.

[0240] Filter out duplicate paths from all complete request paths and generate a list of duplicate path errors.

[0241] Furthermore, based on the above embodiments of the invention, the response execution module 25 includes:

[0242] The first response execution unit is used to highlight the corresponding primitive of the class model associated with the target error item in the client's graphical design canvas if the target error item belongs to the error generated by the class member reference validity check.

[0243] The second response execution unit is used to pop up a class editing pop-up window on the client if the target error item belongs to the error generated by the interface and abstract method implementation integrity check, and to import the unimplemented method into the class model corresponding to the target error item in response to the user's selection and import operation of the unimplemented method in the class editing pop-up window.

[0244] The third response execution unit is used to pop up a parent model batch configuration pop-up window on the client if the target error item belongs to the error generated by the technology suite compatibility check, and to adjust the parent class configuration information of the class model associated with the target error item in batches in response to the user's configuration operation in the parent model batch configuration pop-up window.

[0245] The fourth response execution unit is used to highlight the corresponding primitive of the class model associated with the target error item in the client's graphical design canvas if the target error item belongs to the error generated by the category name uniqueness check or the request path uniqueness check.

[0246] The class model checking device provided in the embodiments of the present invention can execute the class model checking method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of the method execution.

[0247] Figure 8 A schematic diagram of an electronic device 30 that can be used to implement embodiments of the present invention is shown. The electronic device is intended to represent various forms of digital computers, such as laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The electronic device can also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices (e.g., helmets, glasses, watches, etc.), and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely illustrative and are not intended to limit the implementation of the invention described and / or claimed herein.

[0248] like Figure 8As shown, the electronic device 30 includes at least one processor 31 and a memory, such as a read-only memory (ROM) 32 or a random access memory (RAM) 33, communicatively connected to the at least one processor 31. The memory stores computer programs executable by the at least one processor. The processor 31 can perform various appropriate actions and processes based on the computer program stored in the ROM 32 or loaded from storage unit 38 into the RAM 33. The RAM 33 can also store various programs and data required for the operation of the electronic device 30. The processor 31, ROM 32, and RAM 33 are interconnected via a bus 34. An input / output (I / O) interface 35 is also connected to the bus 34.

[0249] Multiple components in electronic device 30 are connected to I / O interface 35, including: input unit 36, such as keyboard, mouse, etc.; output unit 37, such as various types of monitors, speakers, etc.; storage unit 38, such as disk, optical disk, etc.; and communication unit 39, such as network card, modem, wireless transceiver, etc. Communication unit 39 allows electronic device 30 to exchange information / data with other devices through computer networks such as the Internet and / or various telecommunications networks.

[0250] Processor 31 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 31 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various processors running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 31 performs the various methods and processes described above, such as class model checking methods.

[0251] In some embodiments, the class model checking method may be implemented as a computer program tangibly contained in a computer-readable storage medium, such as storage unit 38. In some embodiments, part or all of the computer program may be loaded and / or mounted on electronic device 30 via ROM 32 and / or communication unit 39. When the computer program is loaded into RAM 33 and executed by processor 31, one or more steps of the class model checking method described above may be performed. Alternatively, in other embodiments, processor 31 may be configured to perform the class model checking method by any other suitable means (e.g., by means of firmware).

[0252] Various embodiments of the systems and techniques described above herein can be implemented in digital electronic circuit systems, integrated circuit systems, field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload-programmable logic devices (CPLDs), computer hardware, firmware, software, and / or combinations thereof. These various embodiments may include implementations in one or more computer programs that can be executed and / or interpreted on a programmable system including at least one programmable processor, which may be a dedicated or general-purpose programmable processor, capable of receiving data and instructions from a storage system, at least one input device, and at least one output device, and transmitting data and instructions to the storage system, the at least one input device, and the at least one output device.

[0253] In some embodiments, the class model checking method may be implemented as a computer program, which is implicitly included in a computer program product. When executed by a processor, the computer program implements the class model checking method of the present invention. The computer program product can be understood as a software product that primarily implements its solution through a computer program. The computer program used to implement the method of the present invention may be written in any combination of one or more programming languages. These computer programs may be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing device, such that when executed by the processor, the computer program causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The computer program may be executed entirely on a machine, partially on a machine, partially on a remote machine as a standalone software package, or entirely on a remote machine or server.

[0254] In the context of this invention, a computer-readable storage medium can be a tangible medium that may contain or store a computer program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable storage medium may include, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination thereof. Alternatively, a computer-readable storage medium may be a machine-readable signal medium. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0255] To provide interaction with a user, the systems and techniques described herein can be implemented on an electronic device having: a display device (e.g., a CRT (cathode ray tube) or LCD (liquid crystal display) monitor) for displaying information to the user; and a keyboard and pointing device (e.g., a mouse or trackball) through which the user provides input to the electronic device. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback); and input from the user can be received in any form (including sound input, voice input, or tactile input).

[0256] The systems and technologies described herein can be implemented in computing systems that include backend components (e.g., as data servers), or middleware components (e.g., application servers), or frontend components (e.g., user computers with graphical user interfaces or web browsers through which users can interact with implementations of the systems and technologies described herein), or any combination of such backend, middleware, or frontend components. The components of the system can be interconnected via digital data communication of any form or medium (e.g., communication networks). Examples of communication networks include local area networks (LANs), wide area networks (WANs), blockchain networks, and the Internet.

[0257] A computing system can include clients and servers. Clients and servers are generally located far apart and typically interact through communication networks. The client-server relationship is created by computer programs running on the respective computers and having a client-server relationship with each other. The server can be a cloud server, also known as a cloud computing server or cloud host, which is a hosting product within the cloud computing service system to address the shortcomings of traditional physical hosts and VPS services, such as high management difficulty and weak business scalability.

[0258] It should be understood that the various forms of processes shown above can be used, with steps reordered, added, or deleted. For example, the steps described in this invention can be executed in parallel, sequentially, or in different orders, as long as the desired result of the technical solution of this invention can be achieved, and this is not limited herein.

[0259] The specific embodiments described above do not constitute a limitation on the scope of protection of this invention. Those skilled in the art should understand that various modifications, combinations, sub-combinations, and substitutions can be made according to design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this invention should be included within the scope of protection of this invention.

Claims

1. A class model checking method, characterized in that, The method includes: In response to a class model check request from a client, obtain the context information of the target microservice application; the context information includes a first set of identifiers for all class models under the target microservice application, and a second set of identifiers for all class models that the target microservice application depends on; Based on the context information, a class model compliance check is performed to generate a corresponding error check result; wherein, the class model compliance check includes at least one of the following: class member reference validity check, interface and abstract method implementation integrity check, technology suite compatibility check, category name uniqueness check, and request path uniqueness check; The error check results are sent to the client for visualization. Receive a correction instruction from the client; the correction instruction is associated with a target error item in the error check result; Execute the response operation corresponding to the correction instruction.

2. The method according to claim 1, characterized in that, Performing the class member reference validity check includes: From the class models corresponding to the first set of identifiers, class models that meet the first preset filtering conditions are selected to generate a first type of error record; wherein, the first preset filtering conditions include at least: the type of the class model is a general class or a data structure class, and the class model contains at least one illegal reference attribute; the illegal reference attribute includes an attribute type of generic or class model, and the class model identifier referenced by the attribute type is not in the second set of identifiers; From the class models corresponding to the first set of identifiers, class models that meet the second preset filtering conditions are selected to generate a second type of error record; wherein, the second preset filtering conditions include at least: the type of the class model is a normal class, a service class, or an interface class, and the class model contains at least one illegal reference method; the illegal reference method includes a method whose parameter type is generic or a class model, and the class model identifier referenced by the parameter type is not in the second set of identifiers, or a method whose return value type is generic or a class model, and the class model identifier referenced by the return value type is not in the second set of identifiers; Based on the first type of error record and the second type of error record, a list of class member reference errors is generated.

3. The method according to claim 1, characterized in that, The integrity check is implemented by executing the interface and abstract method, including: Obtain the inheritance relationship and interface implementation relationship of all class models corresponding to the first identifier set; wherein, the inheritance relationship includes a list of abstract parent classes of the class model, and the interface implementation relationship includes a list of implemented interfaces of the class model; Iterate through each class model in the first identifier set and perform the following operations according to the abstract parent class list and the implementation interface list of the current class model: Retrieve the implemented methods in the current class model and generate a set of signatures for the implemented methods; If the list of abstract parent classes is not empty, then extract all abstract methods declared by the abstract parent classes in the list of abstract parent classes to generate a set of methods to be implemented in the abstract parent classes; Iterate through each interface in the implementation interface list, recursively obtain all parent interfaces in the inheritance chain of each interface, and extract all methods to be implemented declared in each interface and each parent interface to generate a set of interface methods to be implemented; The set of methods to be implemented in the abstract parent class and the set of methods to be implemented in the interface are merged and deduplicated to generate a set of method signatures to be implemented in the current class model; The set of implemented method signatures is compared with the set of method signatures to be implemented to generate a list of unimplemented methods for the current class model; Based on the list of unimplemented methods for all the class models, a list of unimplemented method errors is generated.

4. The method according to claim 1, characterized in that, Performing the technology suite compatibility check includes: Obtain the set of technology suite identifiers bound to the target project to which the target microservice application belongs; Obtain the technology suite identifier of the parent class or interface associated with each class model in the first identifier set; Filter out class models whose technology suite identifiers are not in the technology suite identifier set, and generate a technology suite mismatch error list.

5. The method according to claim 1, characterized in that, Perform the category name uniqueness check, including: Determine the scope of the category name uniqueness check, and obtain the corresponding global class model set based on the scope of the check; wherein, the scope of the check includes all class models under the target microservice application, as well as class models in all project-level common applications and subsystem-level common applications under the target project to which the target microservice application belongs; The system filters out class models with duplicate category names from the global class model set and generates a duplicate category name error list.

6. The method according to claim 1, characterized in that, Performing the uniqueness check of the request path includes: Obtain the global class model set obtained when performing the category name uniqueness check; From the global class model set, select class models of type ordinary class or service class that contain service interface methods to generate a subset of class models to be checked; Iterate through each class model in the subset of class models to be checked and perform the following operations: Extract the class-level request path defined in the current class model, and the method-level request path defined in each service interface method under the current class model; The class-level request path is concatenated with the corresponding method-level request path to generate the complete request path for each service interface method. Filter out duplicate paths from all the complete request paths and generate a path duplicate error list.

7. The method according to claim 1, characterized in that, The execution of the response operation corresponding to the correction instruction includes at least one of the following: If the target error item belongs to the error generated by the class member reference validity check, then in the graphical design canvas of the client, the primitive corresponding to the class model associated with the target error item is highlighted and located. If the target error item belongs to the error generated by the interface and abstract method implementation integrity check, then a class editing pop-up window will pop up on the client, and in response to the user's selection and import operation of the unimplemented method in the class editing pop-up window, the unimplemented method will be imported into the class model corresponding to the target error item; If the target error item belongs to the error generated by the technology suite compatibility check, a parent model batch configuration pop-up window will pop up on the client, and in response to the user's configuration operation in the parent model batch configuration pop-up window, the parent class configuration information of the class model associated with the target error item will be adjusted in batches. If the target error item belongs to the error generated by the category name uniqueness check or the request path uniqueness check, then in the client's graphical design canvas, the corresponding primitive of the class model associated with the target error item will be highlighted.

8. 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 class model checking method according to any one of claims 1-7.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores computer instructions that cause a processor to execute the class model checking method according to any one of claims 1-7.

10. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the class model checking method according to any one of claims 1-7.

Images