A meta-model and model processing method, device and computing device cluster

Abstract

A method for processing a metamodel and a model includes: using a first warehouse to carry the content of the metamodel, and using a warehouse group including at least one warehouse to carry the content of at least one model, wherein one warehouse in the warehouse group is used to carry the content of one model, and the first warehouse and warehouses in the warehouse group are code warehouses that can be managed and / or tracked using a version control system; and using the association relationship between the first warehouse and warehouses in the warehouse group to represent the version matching relationship between the metamodel and at least one model. This method can improve the flexibility of metamodel and model management, and improve development efficiency.

Description

Technical Field

[0001] The present application relates to the field of information technology (IT) technology, and in particular to a metamodel and a model processing method, device, and computing device cluster. Background Art

[0002] In the computer field, model and metamodel technology are widely used in software development and other fields. Models and metamodels are both abstract concepts. In software engineering, they are used to describe objects, relationships, behaviors, and rules in software systems. Among them, a model is a description of a system or part of a system, which can be in the form of text, graphics, or code. The metamodel is a description of the model itself, which defines the elements contained in the model and the relationships between them.

[0003] Generally, the development, delivery, and operation and maintenance of complex software systems is a long-term, multi-link, and cross-domain process. In this process, if there is no model service to unify the models of each stage, each field, and each scenario, then the modeling of each point will lead to inconsistent model languages ​​for the entire system. Model data conversion will be required during internal interaction, and even contradictions will occur, affecting the efficiency of the development, delivery, and operation and maintenance of the entire software system. For example, in the process of cloud vendors providing cloud solutions to the outside world, they must provide both the cloud platform base and a large number of cloud services, and provide version-matching software as well as the delivery and operation and maintenance capabilities of such software. Model services can play an important role in this process, defining unified models at the solution, cloud platform, cloud service, and microservice levels, and applying models to various links such as development, testing, release, delivery, and operation and maintenance, so that each scenario and each link can be described in a unified language, greatly improving the efficiency of the entire cloud life cycle. In the implementation of model services, metamodels and models are often needed. In the process of using models and metamodels, unified management of the two is very important. Because when managing models and metamodels in the same model service, the model can be checked within the service according to the metamodel specifications, and grammatical problems can be discovered and corrected in a timely manner. However, managing metamodels or models separately cannot achieve unified version management.

[0004] In the related art, relational databases are often used to manage models and metamodels. However, since relational databases are based on tables to implement data storage and management, the connections between tables are fixed, and each table can only store specific types of data. This leads to a lack of flexibility in the data storage and management process. When the data changes, the database needs to be redesigned and reconstructed, which will waste a lot of time and resources. In addition, since relational databases need to establish connections between multiple tables when managing models, multiple connection operations are required when querying and retrieving data, which will result in low query and read and write efficiency of the database, especially in big data scenarios, the efficiency is even lower. Summary of the invention

[0005] The present application provides a metamodel and model processing method, apparatus, computing device cluster, computer storage medium and computer product, which can improve the flexibility of metamodel and model management and improve development efficiency.

[0006] In a first aspect, the present application provides a method for processing a metamodel and a model, comprising: using a first warehouse to carry the content of a metamodel, and using a warehouse group comprising at least one warehouse to carry the content of at least one model, wherein a warehouse in the warehouse group is used to carry the content of a model, and the first warehouse and the warehouses in the warehouse group are both code warehouses that can be managed and / or tracked using a version control system; using the association relationship between the first warehouse and the warehouses in the warehouse group to represent the version matching relationship between the metamodel and at least one model.

[0007] In this way, by carrying the content of the metamodel and the model through a code repository that can be managed and / or tracked using a version control system, when planning the version of the model, by pulling branches in the corresponding code repository, the new versions of the model and the metamodel can inherit data from the old version without having to copy the data in full, thereby improving the development efficiency of the model. At the same time, by representing the version matching relationship between the metamodel and the model through the association relationship between the repository that carries the metamodel and the repository that carries the model, when the data in the metamodel changes, there is no need to redesign and reconstruct the entire metamodel, only the branch of the metamodel needs to be modified, and the modified branch is associated with the model branch, and the changes in the metamodel specification are passed to the model design, which greatly improves the flexibility of model and metamodel management. In addition, since the model and metamodel are stored in the form of files in this embodiment, this allows direct query and retrieval from the file system when querying and retrieving data, greatly improving the query and retrieval efficiency.

[0008] In a possible implementation, the content of the metamodel is carried by a branch / Tag of the first warehouse. At least one model includes a first model, and the warehouse group includes a second warehouse, and the content of the first model is carried by a branch / Tag of the second warehouse. The version matching relationship between the metamodel and the first model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the second warehouse.

[0009] In a possible implementation, at least one model also includes a second model, the warehouse group also includes a third warehouse, and the content of the second model is carried by the branch / Tag of the third warehouse. The version matching relationship between the metamodel and the second model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the third warehouse.

[0010] In a possible implementation, the method further includes: in the case of planning a new version of the model, pulling a new first branch from the first warehouse, and pulling a new second branch from the warehouse that carries the model, and associating the first branch with the second branch; in the case of publishing a new version of the model, converting the first branch to a first tag of the same name, and using the first tag as a release of the new version of the metamodel, and typing a second tag of the warehouse that carries the model based on the second branch, and using the second tag as a release of the new version, and associating the first tag with the second tag. Exemplarily, the association relationship between the first tag and the second tag can be recorded through a relational database, or through a relational record file. In this way, the development of a new version can be achieved, and the developed metamodel and the new version of the model can both be carried by the corresponding warehouse, and the version matching relationship between the metamodel and the model can be represented by the association relationship between the corresponding warehouses.

[0011] In a possible implementation, the method further includes: in the case of planning a new version of the model, pulling a new first branch from the first warehouse, and pulling a new second branch from the warehouse that carries the model, and associating the first branch and the second branch; in the case of releasing a new version of the model, typing a first tag of the warehouse that carries the model based on the second branch, and using the first tag as the release item of the new version, and associating the first tag and the first branch. Exemplarily, the association relationship between the first tag and the first branch can be recorded through a relational database, or the association relationship between the first tag and the first branch can be recorded through a relational record file. In this way, the development of a new version can be achieved, and the developed metamodel and the new version of the model can be carried by the corresponding warehouse, and the version matching relationship between the metamodel and the model can be represented by the association relationship between the corresponding warehouses.

[0012] In a possible implementation, the method further includes: obtaining a modification command for a target object input by a user, the target object being a model or a metamodel, and the modification command being related to a version control system; and modifying the target object in response to the modification command. Thus, the target object can be modified directly by a modification command related to a version control system (such as a Git command, etc.), without modifying objects associated with the target object, which greatly improves development efficiency.

[0013] In a second aspect, the present application provides a device for processing metamodels and models, including: a first processing module and a second processing module. The first processing module is used to use a first warehouse to carry the content of the metamodel, and to use a warehouse group including at least one warehouse to carry the content of at least one model, wherein a warehouse in the warehouse group is used to carry the content of a model, and the first warehouse and the warehouses in the warehouse group are code warehouses that can be managed and / or tracked using a version control system. The second processing module is used to use the association relationship between the first warehouse and the warehouses in the warehouse group to characterize the version matching relationship between the metamodel and at least one model.

[0014] In a possible implementation, the content of the metamodel is carried by a branch / Tag of the first warehouse. At least one model includes a first model, and the warehouse group includes a second warehouse, and the content of the first model is carried by a branch / Tag of the second warehouse. The version matching relationship between the metamodel and the first model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the second warehouse.

[0015] In a possible implementation, at least one model also includes a second model, the warehouse group also includes a third warehouse, and the content of the second model is carried by the branch / Tag of the third warehouse. The version matching relationship between the metamodel and the second model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the third warehouse.

[0016] In a possible implementation, the device also includes: a third processing module, which is used to: when planning a new version of the first model, pull a new first branch from the first warehouse, and pull a new second branch from the second warehouse, and associate the first branch with the second branch; when the new version is released, type out the first tag of the first warehouse based on the first branch, and use the first tag as the release of the new version; convert the second branch into a second tag with the same name, and use the second tag as the release of the new version of the meta-model, and associate the first tag with the second tag.

[0017] In a possible implementation, the device also includes: a third processing module, which is used to: when planning a new version of the first model, pull a new first branch from the first warehouse, and pull a new second branch from the second warehouse, and associate the first branch with the second branch; when the new version is released, type out the first tag of the first warehouse based on the first branch, use the first tag as the release item of the new version, and associate the first tag with the second branch.

[0018] In a possible implementation, the device also includes: a fourth processing module, used to: obtain a modification command input by a user for a target object, the target object is a model or a metamodel, and the modification command is related to a version control system; and modify the target object in response to the modification command.

[0019] In a third aspect, the present application provides a computing device cluster, comprising at least one computing device, each computing device comprising a processor and a memory; the processor of at least one computing device is used to execute instructions stored in the memory of at least one computing device, so that the computing device cluster performs the method described in the first aspect or any possible implementation of the first aspect.

[0020] In a fourth aspect, the present application provides a computer-readable storage medium, including computer program instructions, when the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method described in the first aspect or any possible implementation of the first aspect. Exemplarily, the computing device cluster may include one or more computing devices.

[0021] In a fifth aspect, the present application provides a computer program product including instructions, which, when executed by a computing device cluster, enables the computing device cluster to perform the method described in the first aspect or any possible implementation of the first aspect. Exemplarily, the computing device cluster may include one or more computing devices.

[0022] It can be understood that the beneficial effects of the second to fifth aspects mentioned above can be found in the relevant description of the first aspect mentioned above, and will not be repeated here. BRIEF DESCRIPTION OF THE DRAWINGS

[0023] Figure 1 It is a schematic diagram of the architecture of a management system of a model and a meta-model provided in an embodiment of the present application;

[0024] Figure 2 It is a schematic diagram of the architecture of a model service for managing models and metamodels provided in an embodiment of the present application;

[0025] Figure 3 It is a schematic diagram of the association relationship between a warehouse of a meta-model and warehouses of multiple models provided in an embodiment of the present application;

[0026] Figure 4 It is a schematic diagram of a management process of a metamodel and a model when planning a new version provided by an embodiment of the present application;

[0027] Figure 5 It is another schematic diagram of the management process of metamodels and models when planning a new version provided by an embodiment of the present application;

[0028] Figure 6 This is another schematic diagram of a management process of a metamodel and a model when planning a new version provided by an embodiment of the present application;

[0029] Figure 7 It is a schematic diagram of a process of checking a model according to the specification of a metamodel provided by an embodiment of the present application;

[0030] Figure 8 It is another schematic diagram of a process of checking a model according to the specification of a metamodel provided by an embodiment of the present application;

[0031] Fig. 9 It is a flowchart of a metamodel and a model processing method provided in an embodiment of the present application;

[0032] Fig.10 It is a structural schematic diagram of a metamodel and a model processing device provided in an embodiment of the present application;

[0033] Fig.11 is a schematic diagram of the structure of a computing device provided in an embodiment of the present application;

[0034] Fig.12 is a schematic diagram of the structure of a computing device cluster provided in an embodiment of the present application;

[0035] Fig.13 It is a structural diagram of another computing device cluster provided in an embodiment of the present application. DETAILED DESCRIPTION

[0036] The term "and / or" in this article is a description of the association relationship of associated objects, indicating that there can be three relationships. For example, A and / or B can represent: A exists alone, A and B exist at the same time, and B exists alone. The symbol " / " in this article indicates that the associated objects are in an or relationship, for example, A / B means A or B.

[0037] The terms "first" and "second" in the specification and claims herein are used to distinguish different objects rather than to describe a specific order of the objects. For example, a first response message and a second response message are used to distinguish different response messages rather than to describe a specific order of the response messages.

[0038] In the embodiments of the present application, words such as "exemplary" or "for example" are used to indicate examples, illustrations or descriptions. Any embodiment or design described as "exemplary" or "for example" in the embodiments of the present application should not be interpreted as being more preferred or more advantageous than other embodiments or designs. Specifically, the use of words such as "exemplary" or "for example" is intended to present related concepts in a specific way.

[0039] In the description of the embodiments of the present application, unless otherwise specified, "multiple" means two or more than two. For example, multiple processing units refer to two or more processing units, etc.; multiple elements refer to two or more elements, etc.

[0040] First, some technical terms involved in the embodiments of the present application are introduced.

[0041] (1) Model and metamodel

[0042] A model is an abstraction of the real world, a simplified description of a thing, process, system or phenomenon. It can be a mathematical model, a computer model, a conceptual model, etc., used to represent the structure, behavior and properties of a specific problem or phenomenon in a certain field. Models can be represented in the form of symbols, graphs, charts, equations, etc., to help understand and analyze problems and provide a basis for prediction, decision-making and design. In computer science, a model can be an abstract representation of a software system, such as a data model, a software architecture model, a process model, etc. A model can describe the components of a system, their relationships, behaviors and characteristics.

[0043] A metamodel is a model used to describe other models. It is a way to abstract and generalize the elements and relationships of a model. The metamodel describes the elements such as classes, attributes, relationships, and the constraints and rules between them in the model. The metamodel defines a specific modeling language and specifies the syntax and semantics in the language. Metamodels are used to formalize and standardize modeling languages, such as the unified modeling language (UML) and business process model and notation (BPMN). Models can be analyzed, verified, and transformed through metamodels, so that complex models can be better understood and managed, and the reuse and standardization of models can be promoted.

[0044] In summary, a model is an abstract description of the real world, while a metamodel is an abstract and general description of the model itself. A model is an expression of a specific problem domain, while a metamodel is an abstract description of the elements, relationships, and rules of the model, which is used to formalize and standardize modeling languages.

[0045] (2) Version Control System

[0046] A version control system (VCS) is a software tool for managing file and code versions. It can track the modification history of files, record changes, coordinate multi-person collaborative development, and restore, compare and merge files of different versions. Common version control systems include: Git, Mercurial, Bazaar, Subversion (SVN), etc. For the convenience of description, the technical solution provided by the embodiment of the present application will be introduced below by taking Git as an example of the version control system. It should be understood that the technical solution when the version control system is replaced by a system other than Git is still within the scope of protection of the present application.

[0047] (3) A repository with features for using version control management software

[0048] A repository with the feature of using version control management software refers to a code repository that can be managed and tracked using a version control system. It provides functions such as version control, branch management, conflict resolution, remote collaboration, tags, and history records to help developers better manage and collaborate on code development. For example, when the version control system is Git, the repository with the feature of using version control management software can be a Git repository.

[0049] Next, the technical solution provided by the embodiments of the present application is introduced.

[0050] For example, Figure 1 FIG. 1 shows a schematic diagram of the architecture of a management system for a model and a meta-model provided in an embodiment of the present application. Figure 1As shown, the management system of the model and metamodel mainly includes a model service 100 based on Git. The model service 100 provides architects with metamodel management capabilities and provides developers with model management capabilities. Architects achieve normalization and standardization of models by maintaining metamodels to ensure the consistency and rationality of models. For example, architects can define a metamodel to describe elements, relationships and constraints in the model, and / or design a model language to describe models in specific fields, etc. Under this system architecture, the management of models and metamodels depends on the version control system inside the model service. In this embodiment, the model and metamodel are both managed through the Git repository, and the version matching relationship between the model and the metamodel is managed through the association relationship between the Git repository of the model and the Git repository of the metamodel. That is to say, the content of the model and the metamodel is carried respectively through the branches / tags of the Git repository, and the version matching relationship between the model and the metamodel is carried through the association relationship between the branches / tags of the model Git repository and the branches / tags of the metamodel Git repository. For example, the branch / Tag of the Git repository can also be understood as being carried through the Git repository. Figure 1 Under the system architecture shown, when the peripheral system needs to obtain the metamodel and the model, the peripheral system can obtain them through the application programming interface (API) or the model package / metamodel package. In some embodiments, the Git warehouse carries the content of the model, which can be understood as: the content of the model is physically stored in the Git warehouse, or the content of the model belongs to the Git warehouse logically, such as: the content of the model is actually stored in a file system, etc. Similarly, the Git warehouse carries the content of the metamodel, which can be understood as: the content of the metamodel is physically stored in the Git warehouse, or the content of the metamodel is logically attributed to the Git warehouse, such as: the content of the metamodel is actually stored in a file system, etc. And the version matching relationship between the model and the metamodel is carried by the association relationship between the branch / Tag of the model Git warehouse and the branch / Tag of the metamodel Git warehouse, which can be understood as: the version matching relationship between the model and the metamodel is characterized / described by the association relationship between the branch / Tag of the model Git warehouse and the branch / Tag of the metamodel Git warehouse.

[0051] Below Figure 1 The model service 100 shown is described in detail.

[0052] For example, Figure 2 The schematic diagram of the architecture of a model service for managing models and metamodels provided in an embodiment of the present application is shown. Figure 2As shown, the model service 100 may include a Console microservice 110, a management microservice 120, a Git microservice 130, a relational database 140, and a file storage database 150. Among them, the Console microservice 110 is mainly used to provide external page access capabilities. The management microservice 120 is mainly responsible for the management of models and metamodels. The Git microservice 130 mainly carries the Git system to provide model warehouses and metamodel warehouses, as well as warehouse branch / Tag management capabilities. The management microservice 120 can be used in conjunction with a relational database 140 to store information describing model and metamodel management, such as the name, introduction, creator, creation time, and other information of the metamodel and model. The Git microservice 130 is used in conjunction with a file storage database 150 to implement distributed storage of files in the Git warehouse to meet high availability requirements.

[0053] The bottom layer of the metamodel management module in the management microservice 120 can be connected to the specific metamodel repository provided by the Git microservice 130, and the bottom layer of the model management module can be connected to the specific model repository provided by the Git microservice 130. In addition, the metamodel management module in the management microservice 120 can manage specific metamodel versions through branches or tags of the metamodel repository, and the model management module can manage specific model versions through branches or tags of the model repository.

[0054] The branches / tags in the metamodel repository provided by the Git microservice 130 can carry the content of the metamodel, and the branches / tags in the model repository can carry the content of the model. The association between the branches / tags in the metamodel repository and the branches / tags in the model repository carries the version matching relationship between the model and the metamodel. In addition, a branch / tag in a metamodel repository can have an association relationship with a branch / tag in at least one model repository to achieve version mapping between the metamodel and the model. For example, Figure 3 As shown in the figure, the developer developed three models, namely Model A, Model B and Model C. Different models are hosted in different Git repositories, and the versions of each model are managed through the branches / tags of the repositories hosting the models. The architect designed a metamodel, which is hosted in a Git repository, and the versions of the metamodel are managed through the branches / tags of the repositories hosting the metamodel. Figure 3 In the example, the branch / Tag2 of the Git repository of models A, B, and C are all associated with the branch / Tag1 of the Git repository of the metamodel, thus achieving version mapping between the metamodel and the model.

[0055] To facilitate understanding, the following describes the process of managing metamodels and models through the Git system in different scenarios.

[0056] (1) Scenario 1

[0057] like Figure 4 As shown, in this scenario, the model has multiple iterative versions in a version development stage, and these multiple iterative versions correspond to branches of the Git repository of a model. For example, when developing version A, the iterative versions in this process all correspond to branch 1 of the Git repository of the model. In the process of model development, when a certain iterative version is released, the tag of the Git repository of the model can be typed from the branch of the Git repository where the model corresponding to the version is located, and released to the outside; while the tags of the Git repository of the model typed based on other iterative versions can be not released. And, the tag of the Git repository typed when the model is released is used as the final release of the model release version. And, the branches and tags of the Git repository of the model are associated with the branches of the Git repository of a metamodel, so as to match the release version corresponding to the metamodel. When a certain iterative version is released, the metamodel associated with the branch of the Git repository corresponding to the iterative version can also be released, and the branch of the Git repository of the metamodel is converted to a tag with the same name and used as the final release of the metamodel release version. In addition, since the branch of the model's Git repository may continue to release patch versions, the branch of the Git repository can be deleted at the end of the life cycle of the model release version and not after the patch version is released. In this scenario, the management of the model and metamodel is relatively strict, and the Git repository tags are used to carry the content of the model and metamodel, and the association between the model's Git repository tags and the metamodel's Git repository tags is used to carry the version matching relationship between the model and the metamodel. In addition, Figure 4 In the planning of the next version (i.e., version B), you can pull the new branch 2 from the tag of the Git repository corresponding to version A, and develop version B through branch 2. In this way, version B is developed through version data inheritance without the need to fully copy data, which greatly improves development efficiency. At the same time, when planning the next version, you can pull the new branch 2 from the tag of the Git repository corresponding to version A of the metamodel.

[0058] exist Figure 4When version A of the model is released, the model content can be carried by Tag1 of the model's Git repository, the metamodel content can be carried by Tag1 of the metamodel's Git repository, and the version matching relationship between the model and the metamodel can be carried by the association between Tag1 of the model's Git repository and Tag1 of the metamodel's Git repository. When version B of the model is released, the model content can be carried by Tag2 of the model's Git repository, the metamodel content can be carried by Tag2 of the metamodel's Git repository, and the version matching relationship between the model and the metamodel can be carried by the association between Tag2 of the model's Git repository and Tag2 of the metamodel's Git repository.

[0059] (2) Scenario 2

[0060] like Figure 5 As shown, a model has multiple iterative versions in a version development stage, and these multiple iterative versions correspond to branches of a model's Git repository. For example, when developing version A, the iterative versions in this process all correspond to branch 1 of the model's Git repository. During the model development process, when a certain iterative version is released, the tag of the model's Git repository can be typed from the branch of the Git repository where the model corresponding to the version is located, and released to the outside; while the tags of the model's Git repository typed based on other iterative versions can be not released. And, the tag of the Git repository typed when the model is released is used as the final release of the model release version. In addition, the branches and tags of the model's Git repository are associated with the branches of a meta-model's Git repository, so as to match the release version corresponding to the meta-model. When a certain iterative version is released, the meta-model associated with the branch of the Git repository corresponding to the iterative version can also be released, but after the meta-model version is released, the branch of the meta-model's Git repository will not be converted to a tag with the same name, but will be restricted from modification through manual management means. After the metamodel version is released, only field description changes, such as changes that do not affect the logic, can be made to the branch of the metamodel Git repository. This scenario can be applied to scenarios where the metamodel version data will not be used by customers on site, that is, the metamodel version data is only kept within the R&D organization, and customers on site will only use the model version data. Figure 5 In the planning of the next version (i.e., version B), you can pull a new branch 2 from the tag of the Git repository corresponding to version A, and develop version B through branch 2. In this way, version B is developed through version data inheritance without the need to fully copy data, which greatly improves development efficiency. At the same time, when planning the next version, you can pull a new branch 2 from the branch of the Git repository corresponding to version A of the metamodel.

[0061] exist Figure 5In the example, when version A of the model is released, the model content can be carried by Tag1 of the model's Git repository, the metamodel content can be carried by branch 1 of the metamodel's Git repository, and the version matching relationship between the model and the metamodel can be carried by the association relationship between Tag1 of the model's Git repository and branch 1 of the metamodel's Git repository. When version B of the model is released, the model content can be carried by Tag2 of the model's Git repository, the metamodel content can be carried by branch 2 of the metamodel's Git repository, and the version matching relationship between the model and the metamodel can be carried by the association relationship between Tag2 of the model's Git repository and branch 2 of the metamodel's Git repository.

[0062] (3) Scenario 3

[0063] like Figure 6 As shown, in this scenario, the model has multiple iterations in a version development stage, and these multiple iterations correspond to different sub-branches on a main branch in the Git repository of a model. For example, when developing version A, the iteration version 1 in this process corresponds to the sub-branch 11 in the main branch 1 of the Git repository of the model, and the iteration version 2 corresponds to the sub-branch 12 in the main branch 1 of the Git repository of the model. In this scenario, when developing each iteration version, a sub-branch needs to be pulled from the main branch of the Git repository, and the sub-branch needs to synchronize the content from the previously pulled sub-branch. At this time, the previously pulled sub-branch carries the content of the model. For example, when developing version A of the model, when developing iteration version 2, it is necessary to newly pull sub-branch 12, and synchronize the content of iteration version 1 from sub-branch 11. At this time, sub-branch 11 carries the content of iteration version 1. When an iterative version is released, the tag of the model's Git repository can be typed out from the branch of the Git repository where the model corresponding to the version is located, and released to the public; while for unreleased iterative versions, it is not mandatory to type out the tag of the model's Git repository branch. Also, the tag of the Git repository corresponding to the last iterative version of the model's Git repository is used as the final release of the model release version. In addition, the branch and tag of the model's Git repository are associated with a branch of the Git repository of a metamodel to match the release version corresponding to the metamodel. When an iterative version is released, the metamodel associated with the branch of the Git repository corresponding to the iterative version can also be released. However, after the metamodel version is released, the branch of the Git repository of the metamodel will not be converted to a tag with the same name, but will be restricted from modification through manual management. In addition, in Figure 6In the planning of the next version (i.e., version B), you can pull the new branch 2 from the branch of the Git repository corresponding to version A, and develop version B through branch 2. In this way, version B is developed through version data inheritance without the need to fully copy data, which greatly improves development efficiency. At the same time, when planning the next version, you can pull the new main branch 2 from the main branch 1 of the Git repository corresponding to version A of the metamodel.

[0064] exist Figure 6 In the example, when version A of the model is released, the model content can be carried by Tag1 of branch 1n of the model's Git repository, the metamodel content can be carried by branch 1 of the metamodel's Git repository, and the version matching relationship between the model and the metamodel can be carried by the association relationship between Tag1 of branch 1n of the model's Git repository and branch 1 of the metamodel's Git repository. When version B of the model is released, the model content can be carried by Tag2 of branch 2n of the model's Git repository, the metamodel content can be carried by branch 2 of the metamodel's Git repository, and the version matching relationship between the model and the metamodel can be carried by the association relationship between Tag2 of branch 2n of the model's Git repository and branch 2 of the metamodel's Git repository.

[0065] From the above three scenarios, we can see that the content of the model and metamodel is carried by the branch / tag of the Git repository. When planning the model version, by pulling branches in the Git repository, the new version of the model can inherit data from the old version without copying the data in full, thereby improving the development efficiency of the model.

[0066] In addition, by carrying the version matching relationship between the metamodel and the model through the association relationship between the branch / Tag of the Git repository of the metamodel and the branch / Tag of the Git repository of the model, when the data in the metamodel changes, there is no need to redesign and reconstruct the entire metamodel. It is only necessary to modify the branch of the metamodel, and the modified branch is associated with the model branch, and the changes in the metamodel specification are passed to the model design, which greatly improves the flexibility of model and metamodel management. In addition, since the model and metamodel are stored in the form of files in this embodiment, it is possible to directly query and retrieve from the file system when querying and retrieving data, which greatly improves the query and retrieval efficiency.

[0067] The above is an introduction to managing metamodels and models through the Git system. Next, based on the above content, based on the storage form of the association relationship between the warehouse branches / tags of the model and the warehouse branches / tags of the metamodel, the model is checked according to the specifications of the metamodel.

[0068] (1) The relationship between the branches / tags of the warehouse of the relational database association model and the branches / tags of the warehouse of the metamodel.

[0069] like Figure 7 As shown, the content of the model and the content of the metamodel are both carried in the Git repository in the form of files, and the association between the branches / tags of the model's repository and the branches / tags of the metamodel's repository is associated through a relational database. For example, the association between the branches / tags of the model's repository and the branches / tags of the metamodel's repository can be recorded through a relational database. The management module in the management microservice 120 can read the metamodel file and the model file from the Git repository respectively, and check the standardization of the model file through the metamodel file when the model is modified or periodically (such as every 1 minute, 10 minutes, etc.), and put the generated model standardization check results into the relational database 140.

[0070] (2) The relationship between the branches / tags of the model's warehouse and the branches / tags of the metamodel's warehouse is associated in the form of a relationship record file, and is carried by the model's warehouse.

[0071] like Figure 8 As shown, the content of the model and the content of the metamodel are both carried in the Git repository in the form of files, and the association between the branches / tags of the model's repository and the branches / tags of the metamodel's repository is carried in the model's Git repository in the form of a relationship record file. The relationship record file does not need to be directly presented in the model management page provided by the Console service 110, and can be stored only as a hidden file in the background. In addition, the relationship record file depends on the repository of the metamodel. The management module in the management microservice 120 can read the metamodel file and the model file from the Git repository respectively, and check the standardization of the model file through the metamodel file when the model is modified or periodically (such as every 1 minute, 10 minutes, etc.), and put the generated model standardization check results into the relational database 140.

[0072] The above is an introduction to managing metamodels and models through the Git system, and checking models according to the specifications of the metamodel. Next, based on the above content, a method for processing a metamodel and a model provided in an embodiment of the present application is introduced. It can be understood that the method is proposed based on the content described above, and part or all of the content of the method can be referred to the relevant description above.

[0073] For example, Fig. 9A schematic diagram of a process flow of a metamodel and a model processing method provided in an embodiment of the present application is shown. It can be understood that the method can be executed by any device, equipment, platform, or device cluster with computing and processing capabilities.

[0074] like Fig. 9 As shown, the metamodel and the model processing method may include the following steps:

[0075] S901. Use the first warehouse to carry the content of the metamodel, and use a warehouse group including at least one warehouse to carry the content of at least one model, wherein one warehouse in the warehouse group is used to carry the content of one model, and the first warehouse and the warehouses in the warehouse group are both code warehouses that can be managed and / or tracked using a version control system.

[0076] S902: Use the association relationship between the first warehouse and the warehouses in the warehouse group to represent the version matching relationship between the meta-model and at least one model.

[0077] In this way, by carrying the content of the metamodel and the model through a code repository that can be managed and / or tracked using a version control system, when planning the version of the model, by pulling branches in the corresponding code repository, the new versions of the model and the metamodel can inherit data from the old version without having to copy the data in full, thereby improving the development efficiency of the model. At the same time, by representing the version matching relationship between the metamodel and the model through the association relationship between the repository that carries the metamodel and the repository that carries the model, when the data in the metamodel changes, there is no need to redesign and reconstruct the entire metamodel, only the branch of the metamodel needs to be modified, and the modified branch is associated with the model branch, and the changes in the metamodel specification are passed to the model design, which greatly improves the flexibility of model and metamodel management. In addition, since the model and metamodel are stored in the form of files in this embodiment, this allows direct query and retrieval from the file system when querying and retrieving data, greatly improving the query and retrieval efficiency.

[0078] In some embodiments, the content of the metamodel can be carried by a branch / Tag of the first warehouse. The aforementioned at least one model includes a first model, and the warehouse group includes a second warehouse. The content of the first model can be carried by a branch / Tag of the second warehouse. The version matching relationship between the metamodel and the first model can be represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the second warehouse.

[0079] In addition, the aforementioned at least one model also includes a second model, and the warehouse group also includes a third warehouse. At this time, the content of the second model is carried by the branch / Tag of the third warehouse. The version matching relationship between the metamodel and the second model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the third warehouse.

[0080] In some embodiments, in the case of planning a new version of the model, a new first branch can be pulled from the first warehouse that carries the metamodel, and a new second branch can be pulled from the warehouse that carries the model, and the first branch and the second branch can be associated. In the case of releasing a new version of the model, the first branch can be converted to a first tag of the same name, and the first tag can be used as a release of the new version of the metamodel, and the second tag of the warehouse that carries the model can be typed out based on the second branch, and the second tag can be used as a release of the new version. In addition, the first tag and the second tag can be associated. Exemplarily, the association relationship between the first tag and the second tag can be recorded through a relational database, or the association relationship between the first tag and the second tag can be recorded through a relational record file. In this way, the development of a new version can be achieved, and the developed metamodel and the new version of the model can be carried by the corresponding warehouse, and the version matching relationship between the metamodel and the model can be represented by the association relationship between the corresponding warehouses.

[0081] In some embodiments, in the case of planning a new version of the first model, in the case of planning a new version of the model, a new first branch is pulled from the first warehouse, and a new second branch is pulled from the warehouse that carries the model, and the first branch and the second branch are associated; in the case of releasing a new version of the model, a first tag of the warehouse that carries the model is typed based on the second branch, and the first tag is used as the release item of the new version, and the first tag and the first branch are associated. Exemplarily, the association relationship between the first tag and the first branch can be recorded through a relational database, or the association relationship between the first tag and the first branch can be recorded through a relational record file. In this way, the development of a new version can be achieved, and the developed metamodel and new versions of the model can be carried by the corresponding warehouses, and the version matching relationship between the metamodel and the model can be represented by the association relationship between the corresponding warehouses.

[0082] In some embodiments, the user can modify the target object (such as a metamodel or a model). At this time, after the modification command related to the version control system issued by the user, the modification command for the target object input by the user can be obtained. After that, the target object can be modified in response to the modification command. In this way, the target object can be modified directly through the modification command related to the version control system without modifying the objects associated with the target object, which greatly improves the development efficiency.

[0083] It is understandable that the size of the sequence number of each step in the above embodiment does not mean the order of execution, and the execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiment of the present application. In addition, in some possible implementations, each step in the above embodiment can be selectively executed according to actual conditions, and can be partially executed or fully executed, which is not limited here.

[0084] The above is an introduction to the metamodel and the model processing method provided by the embodiment of the present application. Next, based on the method in the above embodiment, a metamodel and a model processing device provided by the embodiment of the present application are introduced.

[0085] For example, Fig.10 FIG. 1 is a schematic diagram showing a structure of a metamodel and a model processing device provided in an embodiment of the present application. Fig.10 As shown, the processing device 1000 for the metamodel and the model may include: a first processing module 1001 and a second processing module 1002. The first processing module 1001 is used to use the first warehouse to carry the content of the metamodel, and to use the warehouse group containing at least one warehouse to carry the content of at least one model, wherein one warehouse in the warehouse group is used to carry the content of one model, and the first warehouse and the warehouses in the warehouse group are all code warehouses that can be managed and / or tracked using a version control system. The second processing module 1002 is used to use the association relationship between the first warehouse and the warehouses in the warehouse group to represent the version matching relationship between the metamodel and at least one model.

[0086] In some embodiments, the content of the metamodel is carried by a branch / Tag of the first warehouse. At least one model includes a first model, and the warehouse group includes a second warehouse, and the content of the first model is carried by a branch / Tag of the second warehouse. The version matching relationship between the metamodel and the first model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the second warehouse.

[0087] In some embodiments, at least one model also includes a second model, the warehouse group also includes a third warehouse, and the content of the second model is carried by the branch / Tag of the third warehouse. The version matching relationship between the metamodel and the second model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the third warehouse.

[0088] In some embodiments, the device also includes: a third processing module (not shown in the figure), which is used to: in the case of planning a new version of the first model, pull a new first branch from the first warehouse, and pull a new second branch from the second warehouse, and associate the first branch with the second branch; in the case of releasing a new version, based on the first Tag of the first warehouse typed out by the first branch, and use the first Tag as the release of the new version; convert the second branch into a second Tag with the same name, and use the second Tag as the release of the new version of the meta-model, and associate the first Tag with the second Tag.

[0089] In some embodiments, the device also includes: a third processing module (not shown in the figure), which is used to: in the case of planning a new version of the first model, pull a new first branch from the first warehouse, and pull a new second branch from the second warehouse, and associate the first branch with the second branch; in the case of releasing a new version, based on the first tag of the first warehouse typed out from the first branch, and use the first tag as the release of the new version, and associate the first tag with the second branch.

[0090] In some embodiments, the device also includes: a fourth processing module (not shown in the figure), which is used to: obtain a modification command input by the user for the target object, the target object is a model or a metamodel, and the modification command is related to the version control system; in response to the modification command, modify the target object.

[0091] In some embodiments, Fig.10 The first processing module 1001 and the second processing module 1002 shown in the figure can be implemented by software or by hardware. Exemplarily, the implementation of the first processing module 1001 is described below by taking the first processing module 1001 as an example. Similarly, the implementation of the second processing module 1002 can refer to the implementation of the first processing module 1001.

[0092] As an example of a software functional unit, the first processing module 1001 may include code running on a computing instance. Among them, the computing instance may include at least one of a physical host (computing device), a virtual machine, and a container. Further, the above-mentioned computing instance may be one or more. For example, the first processing module 1001 may include code running on multiple hosts / virtual machines / containers. It should be noted that the multiple hosts / virtual machines / containers used to run the code can be distributed in the same region (region) or in different regions. Furthermore, the multiple hosts / virtual machines / containers used to run the code can be distributed in the same availability zone (AZ) or in different AZs, each AZ including a data center or multiple data centers with similar geographical locations. Among them, usually a region can include multiple AZs.

[0093] Similarly, multiple hosts / virtual machines / containers used to run the code can be distributed in the same virtual private cloud (VPC) or in multiple VPCs. Usually, a VPC is set up in a region. For cross-region communication between two VPCs in the same region and between VPCs in different regions, a communication gateway needs to be set up in each VPC to achieve interconnection between VPCs through the communication gateway.

[0094] As an example of a hardware functional unit, the first processing module 1001 may include at least one computing device, such as a server, etc. Alternatively, the first processing module 1001 may also be a device implemented using an application-specific integrated circuit (ASIC) or a programmable logic device (PLD). The PLD may be a complex programmable logical device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL) or any combination thereof.

[0095] The multiple computing devices included in the first processing module 1001 can be distributed in the same region or in different regions. The multiple computing devices included in the first processing module 1001 can be distributed in the same AZ or in different AZs. Similarly, the multiple computing devices included in the first processing module 1001 can be distributed in the same VPC or in multiple VPCs. The multiple computing devices can be any combination of computing devices such as servers, ASICs, PLDs, CPLDs, FPGAs, and GALs.

[0096] It should be noted that, in other embodiments, the first processing module 1001 can be used to execute any step in the processing method of the metamodel and model described in the above embodiment, and the second processing module 1002 can be used to execute any step in the processing method of the metamodel and model described in the above embodiment. The steps that the first processing module 1001 and the second processing module 1002 are responsible for implementing can be specified as needed, and the first processing module 1001 and the second processing module 1002 respectively implement different steps in the processing method of the metamodel and model described in the above embodiment to achieve Fig.10 The metamodel and model processing device 1000 have all the functions shown.

[0097] The present application also provides a computing device 1100. Fig.11 As shown, the computing device 1100 includes: a bus 1102, a processor 1104, a memory 1106, and a communication interface 1108. The processor 1104, the memory 1106, and the communication interface 1108 communicate through the bus 1102. The computing device 1100 can be a server or a terminal device. It should be understood that the present application does not limit the number of processors and memories in the computing device 1100.

[0098] The bus 1102 may be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus. The bus may be divided into an address bus, a data bus, a control bus, etc. For ease of representation, Fig.11 The bus 1104 may include a path for transmitting information between various components of the computing device 1100 (eg, the memory 1106, the processor 1104, and the communication interface 1108).

[0099] The processor 1104 may include any one or more of a central processing unit (CPU), a graphics processing unit (GPU), a microprocessor (MP), or a digital signal processor (DSP).

[0100] The memory 1106 may include a volatile memory, such as a random access memory (RAM). The processor 1104 may also include a non-volatile memory, such as a read-only memory (ROM), a flash memory, a hard disk drive (HDD), or a solid state drive (SSD).

[0101] The memory 1106 stores executable program codes, and the processor 1104 executes the executable program codes to respectively implement the aforementioned Fig.10 The functions of the first processing module 1001 and the first processing module 1002 shown in the above embodiment are implemented to realize the processing method of the metamodel and the model described in the above embodiment. That is, the memory 1106 stores instructions for executing the processing method of the metamodel and the model described in the above embodiment.

[0102] Alternatively, the memory 1106 stores executable codes, and the processor 1104 executes the executable codes to respectively implement the aforementioned Fig.10 The functions of the processing device 1000 for the metamodel and model shown in the embodiment are implemented to realize the processing method for the metamodel and model described in the above embodiment. That is, the memory 1106 stores instructions for executing the processing method for the metamodel and model described in the above embodiment.

[0103] The communication interface 1103 uses a transceiver module such as, but not limited to, a network interface card or a transceiver to implement communication between the computing device 1100 and other devices or a communication network.

[0104] The embodiment of the present application also provides a computing device cluster. The computing device cluster includes at least one computing device. The computing device can be a server, such as a central server, an edge server, or a local server in a local data center. In some embodiments, the computing device can also be a terminal device such as a desktop computer, a laptop computer, or a smart phone.

[0105] like Fig.12As shown, the computing device cluster includes at least one computing device 1100. The memory 1106 in one or more computing devices 1100 in the computing device cluster may store the same instructions for executing the metamodel and model processing method described in the above embodiments.

[0106] In some possible implementations, the memory 1106 of one or more computing devices 1100 in the computing device cluster may also store partial instructions for executing the metamodel and model processing methods described in the above embodiments. In other words, the combination of one or more computing devices 1100 may jointly execute instructions for executing the metamodel and model processing methods described in the above embodiments.

[0107] It should be noted that the memory 1106 in different computing devices 1100 in the computing device cluster may store different instructions, which are respectively used to execute the aforementioned Fig.10 The metamodel and model processing apparatus 1000 shown in FIG. 100B are partially functional. That is, the instructions stored in the memory 1106 in different computing devices 1100 can implement the functions of one or more modules in the first processing module 1001 and the second processing module 1002 .

[0108] In some possible implementations, one or more computing devices in the computing device cluster may be connected via a network, which may be a wide area network or a local area network. Fig.13 A possible implementation is shown. Fig.13 As shown, two computing devices 1100A and 1100B are connected via a network. Specifically, the network is connected via a communication interface in each computing device. In this type of possible implementation, the memory 1106 in the computing device 1100A stores instructions for executing the functions of the first processing module 1001. At the same time, the memory 1106 in the computing device 1100B stores instructions for executing the functions of the second processing module 1002.

[0109] It should be understood that Fig.13 The functions of the computing device 1100A shown in FIG. 1100A may also be completed by multiple computing devices 1100. Similarly, the functions of the computing device 1100B may also be completed by multiple computing devices 1100.

[0110] The present application embodiment also provides another computing device cluster. The connection relationship between the computing devices in the computing device cluster can be similar to that of Fig.12 and Fig.13 The connection mode of the computing device cluster is different in that the memory 1106 in one or more computing devices 1100 in the computing device cluster may store the same instructions for executing the method in the above embodiment.

[0111] In some possible implementations, the memory 1106 of one or more computing devices 1100 in the computing device cluster may also store partial instructions for executing the aforementioned data metamodel and model processing method. In other words, the combination of one or more computing devices 1100 may jointly execute instructions for executing the aforementioned data metamodel and model processing method.

[0112] Based on the method in the above embodiment, the embodiment of the present application provides a computer-readable storage medium, including computer program instructions. When the computer program instructions are executed by a computing device, the computing device executes the method in the above embodiment; or, when the computer program instructions are executed by a computing device cluster, the computing device cluster executes the method in the above embodiment. Exemplarily, the computer-readable storage medium can be any available medium that can be stored by a computing device or a data storage device such as a data center that includes one or more available media. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk), etc.

[0113] Based on the method in the above embodiment, an embodiment of the present application provides a computer program product containing instructions, which, when executed by a computing device, enables the computing device to execute the method in the above embodiment, or, when executed by a computing device cluster, enables the computing device cluster to execute the method in the above embodiment.

[0114] It is understood that the processor in the embodiments of the present application may be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application specific integrated circuits (ASIC), field programmable gate arrays (FPGA) or other programmable logic devices, transistor logic devices, hardware components or any combination thereof. The general-purpose processor may be a microprocessor or any conventional processor.

[0115] The method steps in the embodiments of the present application can be implemented by hardware or by a processor executing software instructions. The software instructions can be composed of corresponding software modules, and the software modules can be stored in random access memory (RAM), flash memory, read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), registers, hard disks, mobile hard disks, CD-ROMs, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an ASIC.

[0116] In the above embodiments, it can be implemented in whole or in part by software, hardware, firmware or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the process or function described in the embodiment of the present application is generated in whole or in part. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted through the computer-readable storage medium. The computer instructions may be transmitted from a website site, computer, server or data center to another website site, computer, server or data center by wired (e.g., coaxial cable, optical fiber, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrated. The available medium may be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid state disk (SSD)), etc.

[0117] It should be understood that the various numerical numbers involved in the embodiments of the present application are only used for the convenience of description and are not used to limit the scope of the embodiments of the present application.

[0118] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the protection scope of the technical solutions of the embodiments of the present application.

Claims

1. A meta-model and a model processing method, characterized in that: include: Using a first repository to carry content of a metamodel, and using a repository group including at least one repository to carry content of at least one model, wherein one repository in the repository group is used to carry content of one model, and the first repository and the repositories in the repository group are both code repositories that can be managed and / or tracked using a version control system; Using the association relationship between the first warehouse and warehouses in the warehouse group to represent the version matching relationship between the meta-model and the at least one model; The content of the meta-model is carried by the branch / Tag of the first warehouse; The at least one model includes a first model, the warehouse group includes a second warehouse, and the content of the first model is carried by a branch / Tag of the second warehouse; The version matching relationship between the meta-model and the first model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the second warehouse.

2. The method according to claim 1, characterized in that The at least one model further includes a second model, the warehouse group further includes a third warehouse, and the content of the second model is carried by a branch / Tag of the third warehouse; The version matching relationship between the meta-model and the second model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the third warehouse.

3. The method according to claim 1 or 2, characterized in that: Also includes: In case of planning a new version of the model, pulling a new first branch from the first warehouse, and pulling a new second branch from the warehouse hosting the model, and associating the first branch with the second branch; When a new version of the model is released, the first branch is converted into a first tag with the same name, and the first tag is used as the release item of the new version of the metamodel. In addition, a second tag of the repository carrying the model is typed out based on the second branch, and the second tag is used as the release item of the new version, and the first tag and the second tag are associated.

4. The method according to claim 1 or 2, characterized in that: Also includes: In case of planning a new version of the model, pulling a new first branch from the first warehouse, and pulling a new second branch from the warehouse hosting the model, and associating the first branch with the second branch; When a new version of the model is released, a first tag of the warehouse carrying the model is typed based on the second branch, and the first tag is used as the release document of the new version, and the first tag is associated with the first branch.

5. The method according to claim 1 or 2, characterized in that: Also includes: Acquire a modification command for a target object input by a user, wherein the target object is the model or the metamodel, and the modification command is related to the version control system; In response to the modification command, the target object is modified.

6. A device for processing metamodels and models, characterized in that include: A first processing module is configured to use a first repository to carry the content of a metamodel, and to use a repository group including at least one repository to carry the content of at least one model, wherein one repository in the repository group is used to carry the content of one model, and the first repository and the repositories in the repository group are both code repositories that can be managed and / or tracked using a version control system; A second processing module, configured to represent a version matching relationship between the meta-model and the at least one model by using an association relationship between the first warehouse and warehouses in the warehouse group; The content of the meta-model is carried by the branch / Tag of the first warehouse; The at least one model includes a first model, the warehouse group includes a second warehouse, and the content of the first model is carried by a branch / Tag of the second warehouse; The version matching relationship between the meta-model and the first model is represented by the association relationship between the branch / Tag of the first warehouse and the branch / Tag of the second warehouse.

7. A computing device cluster, characterized in that: comprising at least one computing device, each computing device comprising a processor and a memory; The processor of the at least one computing device is used to execute instructions stored in the memory of the at least one computing device, so that the computing device cluster executes the method according to any one of claims 1-5.

8. A computer-readable storage medium, characterized in that: The method comprises computer program instructions, and when the instructions are executed by a computing device cluster, the computing device cluster enables the computing device cluster to perform the method according to any one of claims 1 to 5, wherein the computing device cluster comprises at least one computing device.

9. A computer program product comprising instructions, characterized in that When the instructions are executed by a computing device cluster, the computing device cluster executes the method according to any one of claims 1 to 5, wherein the computing device cluster includes at least one computing device.

Images