CN116881218A - 一种元模型和模型的处理方法、装置及计算设备集群 - Google Patents

Abstract

一种元模型和模型的处理方法，包括：利用第一仓库承载元模型的内容，以及，利用包含至少一个仓库的仓库组承载至少一个模型的内容，其中，仓库组中一个仓库用于承载一个模型的内容，第一仓库和仓库组中的仓库均为可使用版本控制系统进行管理和/或追踪的代码仓库；利用第一仓库和仓库组中仓库之间的关联关系表征元模型和至少一个模型的版本配套关系。通过该方法可以提升元模型和模型管理的灵活性，以及提升开发效率。

Description

一种元模型和模型的处理方法、装置及计算设备集群

技术领域

本申请涉及信息技术(information technology，IT)技术领域，尤其涉及一种元模型和模型的处理方法、装置及计算设备集群。

背景技术

在计算机领域中，模型和元模型技术被广泛应用于软件开发等领域。模型和元模型都是抽象概念，在软件工程中，它们被用来描述软件系统中的对象、关系、行为和规则等方面。其中，模型是对一个系统或者系统部分的描述，它可以是文字、图形或者代码等形式。而元模型则是对模型本身的描述，它定义了模型所包含的元素和它们之间的关系。

一般的，复杂软件系统的研发、交付和运维是一个长周期、多环节、跨领域的过程，在这个过程中如果没有一个模型服务来统一各个阶段、各个领域、各个场景的模型，那么每个点单独建模会导致整个系统的模型语言不统一，内部交互时需要不断的进行模型数据转换，甚至产生矛盾点，影响整个软件系统的研发、交付、运维的效率。例如，云厂商对外提供云解决方案的过程中，既要提供云平台底座也要提供众多的云服务，要提供版本配套软件同时也要提供这种软件的交付和运维能力。模型服务在这其中可充当重要作用，定义解决方案、云平台、云服务、微服务级的统一模型，把模型应用到开发、测试、发布、交付、运维等各个环节中，使得各个场景、各个环节都用统一套语言描述，大大提升整个云生命周期的效率。在模型服务的实施过程中，常需要用到元模型和模型。在使用模型和元模型的过程中，两者的统一管理十分重要。因为，在同一个模型服务中对模型和元模型进行管理时，可以在服务内根据元模型的规范对模型进行检查，及时发现语法上的问题并进行修正，而单独管理元模型，或单独管理模型的方式，无法做到版本的统一管理。

相关技术中，常使用关系型数据库对模型和元模型进行管理。但由于关系型数据库是基于表格来实现数据存储和管理的，所以表格之间的联系是固定的，而且每个表格只能存储特定类型的数据。这就导致了在数据存储和管理过程中，缺乏灵活性。当数据出现变化时，需要对数据库进行重新设计和重构，这样就会浪费大量时间和资源。另外，由于关系型数据库在管理模型时需要在多个表格之间建立联系，所以在查询和检索数据时需要进行多次连接操作，这就会导致数据库的查询和读写效率较低，尤其是在大数据场景下，效率更是低下。

发明内容

本申请提供了一种元模型和模型的处理方法、装置、计算设备集群、计算机存储介质及计算机产品，能够提升元模型和模型管理的灵活性，以及提升开发效率。

第一方面，本申请提供一种元模型和模型的处理方法，包括：利用第一仓库承载元模型的内容，以及，利用包含至少一个仓库的仓库组承载至少一个模型的内容，其中，仓库组中一个仓库用于承载一个模型的内容，第一仓库和仓库组中的仓库均为可使用版本控制系统进行管理和/或追踪的代码仓库；利用第一仓库和仓库组中仓库之间的关联关系表征元模型和至少一个模型的版本配套关系。

这样，通过可使用版本控制系统进行管理和/或追踪的代码仓库承载元模型和模型的内容，在规划模型的版本时，通过在相应的代码仓库中拉分支的方式，可以使得模型和元模型的新版本均可以从旧版本继承数据，而无需全量复制数据，提升了模型的开发效率。同时，通过承载元模型的仓库和承载模型的仓库之间的关联关系表征元模型和模型的版本配套关系，可以在元模型中的数据出现变化时，无需对整个元模型进行重新设计和重构，只需要修改元模型的分支，以及，将修改后的分支通过与模型分支的关联，并将元模型规范的变化传递到模型设计中即可，大幅提升了模型和元模型管理的灵活性。此外，由于本实施例中是通过文件的形式对模型和元模型进行存储，这使得在查询和检索数据时可以直接从文件系统中进行查询和检索，大幅提升了查询和检索效率。

在一种可能的实现方式中，元模型的内容通过第一仓库的分支/Tag承载。至少一个模型中包括第一模型，仓库组中包括第二仓库，第一模型的内容通过第二仓库的分支/Tag承载。元模型和第一模型的版本配套关系通过第一仓库的分支/Tag和第二仓库的分支/Tag之间的关联关系表征。

在一种可能的实现方式中，至少一个模型中还包括第二模型，仓库组中还包括第三仓库，第二模型的内容通过第三仓库的的分支/Tag承载。元模型和第二模型的版本配套关系通过第一仓库的分支/Tag和第三仓库的分支/Tag之间的关联关系表征。

在一种可能的实现方式中，该方法还包括：在规划模型的新版本的情况下，从第一仓库中拉取新的第一分支，以及，从承载模型的仓库中拉取新的第二分支，并将第一分支和第二分支进行关联；在模型的新版本发布的情况下，将第一分支转换为同名的第一Tag，并将第一Tag作为元模型的新版本的发布件，以及，基于第二分支打出承载模型的仓库的第二Tag，并将第二Tag作为新版本的发布件，且将第一Tag和第二Tag进行关联。示例性的，可以通过关系型数据库记录第一Tag和第二Tag之间的关联关系，也可以通过关系记录文件记录第一Tag和第二Tag之间的关联关系。由此以实现新版本的开发，且开发的元模型和模型的新版本均可以通过相应的仓库承载，以及，可以通过相应的仓库之间的关联关系表征元模型和模型之间的版本配套关系。

在一种可能的实现方式中，该方法还包括：在规划模型的新版本的情况下，从第一仓库中拉取新的第一分支，以及，从承载模型的仓库中拉取新的第二分支，并将第一分支和第二分支进行关联；在模型的新版本发布的情况下，基于第二分支打出承载模型的仓库的第一Tag，并将第一Tag作为新版本的发布件，且将第一Tag和第一分支进行关联。示例性的，可以通过关系型数据库记录第一Tag和第一分支之间的关联关系，也可以通过关系记录文件记录第一Tag和第一分支之间的关联关系。由此以实现新版本的开发，且开发的元模型和模型的新版本均可以通过相应的仓库承载，以及，可以通过相应的仓库之间的关联关系表征元模型和模型之间的版本配套关系。

在一种可能的实现方式中，该方法还包括：获取用户输入的针对目标对象的修改命令，目标对象为模型或元模型，修改命令与版本控制系统相关；响应于修改命令，对目标对象进行修改。由此即可以通过与版本控制系统相关的修改命令(比如Git命令等)直接对目标对象修改，而无需再对与目标对象相关联的对象进行修改，大幅提升了开发效率。

第二方面，本申请提供一种处理元模型和模型的装置，包括：第一处理模块和第二处理模块。其中，第一处理模块，用于利用第一仓库承载元模型的内容，以及，利用包含至少一个仓库的仓库组承载至少一个模型的内容，其中，仓库组中一个仓库用于承载一个模型的内容，第一仓库和仓库组中的仓库均为可使用版本控制系统进行管理和/或追踪的代码仓库。第二处理模块，用于利用第一仓库和仓库组中仓库之间的关联关系表征元模型和至少一个模型的版本配套关系。

在一种可能的实现方式中，元模型的内容通过第一仓库的分支/Tag承载。至少一个模型中包括第一模型，仓库组中包括第二仓库，第一模型的内容通过第二仓库的分支/Tag承载。元模型和第一模型的版本配套关系通过第一仓库的分支/Tag和第二仓库的分支/Tag之间的关联关系表征。

在一种可能的实现方式中，至少一个模型中还包括第二模型，仓库组中还包括第三仓库，第二模型的内容通过第三仓库的的分支/Tag承载。元模型和第二模型的版本配套关系通过第一仓库的分支/Tag和第三仓库的分支/Tag之间的关联关系表征。

在一种可能的实现方式中，该装置还包括：第三处理模块，用于：在规划第一模型的新版本的情况下，从第一仓库中拉取新的第一分支，以及，从第二仓库中拉取新的第二分支，并将第一分支和第二分支进行关联；在新版本发布的情况下，基于第一分支打出的第一仓库的第一Tag，并将第一Tag作为新版本的发布件；将第二分支转换为同名的第二Tag，并将第二Tag作为元模型的新版本的发布件，以及，将第一Tag和第二Tag进行关联。

在一种可能的实现方式中，该装置还包括：第三处理模块，用于：在规划第一模型的新版本的情况下，从第一仓库中拉取新的第一分支，以及，从第二仓库中拉取新的第二分支，并将第一分支和第二分支进行关联；在新版本发布的情况下，基于第一分支打出的第一仓库的第一Tag，并将第一Tag作为新版本的发布件，以及，将第一Tag和第二分支进行关联。

在一种可能的实现方式中，该装置还包括：第四处理模块，用于：获取用户输入的针对目标对象的修改命令，目标对象为模型或元模型，修改命令与版本控制系统相关；响应于修改命令，对目标对象进行修改。

第三方面，本申请提供一种计算设备集群，包括至少一个计算设备，每个计算设备均包括处理器和存储器；至少一个计算设备的处理器用于执行至少一个计算设备的存储器中存储的指令，以使得计算设备集群执行第一方面或第一方面的任一种可能的实现方式所描述的方法。

第四方面，本申请提供一种计算机可读存储介质，包括计算机程序指令，当计算机程序指令由计算设备集群执行时，计算设备集群执行第一方面或第一方面的任一种可能的实现方式所描述的方法。示例性的，计算设备集群中可以包括一个或多个计算设备。

第五方面，本申请提供一种包含指令的计算机程序产品，当指令被计算设备集群运行时，使得计算设备集群执行第一方面或第一方面的任一种可能的实现方式所描述的方法。示例性的，计算设备集群中可以包括一个或多个计算设备。

可以理解的是，上述第二方面至第五方面的有益效果可以参见上述第一方面中的相关描述，在此不再赘述。

附图说明

图1是本申请实施例提供的一种模型和元模型的管理系统的架构示意图；

图2是本申请实施例提供的一种管理模型和元模型的模型服务的架构示意图；

图3是本申请实施例提供的一种元模型的仓库与多个模型的仓库之间关联关系的示意图；

图4是本申请实施例提供的一种在规划新版本时元模型和模型的管理过程示意图；

图5是本申请实施例提供的另一种在规划新版本时元模型和模型的管理过程示意图；

图6是本申请实施例提供的又一种在规划新版本时元模型和模型的管理过程示意图；

图7是本申请实施例提供的一种根据元模型的规范对模型进行检查的过程示意图；

图8是本申请实施例提供的另一种根据元模型的规范对模型进行检查的过程示意图；

图9是本申请实施例提供的一种元模型和模型的处理方法的流程示意图；

图10是本申请实施例提供的一种元模型和模型的处理装置的结构示意图；

图11是本申请实施例提供的一种计算设备的结构示意图；

图12是本申请实施例提供的一种计算设备集群的结构示意图；

图13是本申请实施例提供的另一种计算设备集群的结构示意图。

具体实施方式

本文中术语“和/或”，是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。本文中符号“/”表示关联对象是或者的关系，例如A/B表示A或者B。

本文中的说明书和权利要求书中的术语“第一”和“第二”等是用于区别不同的对象，而不是用于描述对象的特定顺序。例如，第一响应消息和第二响应消息等是用于区别不同的响应消息，而不是用于描述响应消息的特定顺序。

在本申请实施例中，“示例性的”或者“例如”等词用于表示作例子、例证或说明。本申请实施例中被描述为“示例性的”或者“例如”的任何实施例或设计方案不应被解释为比其它实施例或设计方案更优选或更具优势。确切而言，使用“示例性的”或者“例如”等词旨在以具体方式呈现相关概念。

在本申请实施例的描述中，除非另有说明，“多个”的含义是指两个或者两个以上，例如，多个处理单元是指两个或者两个以上的处理单元等；多个元件是指两个或者两个以上的元件等。

首先，对本申请实施例涉及的一些技术术语进行介绍。

(1)模型和元模型

模型是对现实世界的抽象，是对某种事物、过程、系统或现象的简化描述。它可以是数学模型、计算机模型、概念模型等，用来表示某个领域的特定问题或现象的结构、行为和属性。模型可以通过符号、图形、图表、方程式等形式进行表示，帮助理解和分析问题，并提供预测、决策和设计的依据。在计算机科学中，模型可以是软件系统的抽象表示，如数据模型、软件架构模型、流程模型等。模型能够描述系统的组成部分、它们之间的关系、行为和特性。

元模型是一个用于描述其他模型的模型。它是对模型的元素和关系进行抽象和概括的一种方式。元模型描述了模型中的类、属性、关系等元素，以及它们之间的约束和规则。元模型定义了一个特定的模型语言，规定了该语言中的语法和语义。元模型用于形式化和标准化建模语言，例如统一建模语言(unified modeling language,UML)和业务流程建模符号(business process model and notation,BPMN)。通过元模型可以对模型进行分析、验证和转换，从而更好地理解和管理复杂的模型，促进模型的重用和标准化。

总结来说，模型是对现实世界的抽象描述，而元模型是对模型本身进行抽象和概括的描述。模型是特定问题领域的表达形式，而元模型是对模型的元素、关系和规则的抽象描述，用于形式化和标准化建模语言。

(2)版本控制系统

版本控制系统(version control system,VCS)是一种用于管理文件和代码版本的软件工具。它可以追踪文件的修改历史、记录变更、协调多人协作开发，以及恢复、比较和合并不同版本的文件。常见的版本控制系统包括：Git、Mercurial、Bazaar、Subversion(SVN)等。为叙述方便，下文将以版本控制系统为Git为例对本申请实施例提供的技术方案进行介绍。应理解的是，将版本控制系统替换为Git之外的系统时的技术方案，仍在本申请的保护范围之内。

(3)具备使用版本控制管理软件特征的仓库

具备使用版本控制管理软件特征的仓库是指可以使用版本控制系统进行管理和追踪的代码仓库。它提供了版本控制、分支管理、冲突解决、远程协作、Tag和历史记录等功能，帮助开发者更好地管理和协作开发代码。示例性的，当版本控制系统为Git时，具备使用版本控制管理软件特征的仓库可以为Git仓库。

接下来，对本申请实施例提供的技术方案进行介绍。

示例性的，图1示出了本申请实施例提供的一种模型和元模型的管理系统的架构示意图。如图1所示，该模型和元模型的管理系统主要包括基于Git的模型服务100。该模型服务100对架构师提供元模型管理能力，并对开发者提供模型管理能力。架构师通过维护元模型实现对模型的规范化和标准化，确保模型的一致性和合理性。例如：架构师可以定义一个元模型来描述模型中的元素、关系和约束，和/或，设计一个模型语言，用于描述特定领域的模型，等等。在该系统架构下，模型和元模型的管理均依赖于模型服务内部的版本控制系统。本实施例中，模型和元模型均通过Git仓库进行管理，而模型和元模型间的版本配套关系通过模型的Git仓库和元模型的Git仓库之间的关联关系进行管理。也即是说，通过Git仓库的分支/Tag分别承载模型和元模型的内容，通过模型Git仓库的分支/Tag和元模型Git仓库的分支/Tag之间的关联关系承载模型和元模型间的版本配套关系。示例性的，通过Git仓库的分支/Tag承载，也可以理解为是通过Git仓库承载。在图1所示的系统架构下，当周边系统需要获取元模型和模型时，周边系统可以通过应用编程接口(application programminginterface,API)或者模型包/元模型包的形式获取。在一些实施例中，Git仓库承载模型的内容，可以理解为：模型的内容在物理上存储在Git仓库中，或者，模型的内容在逻辑上归属于Git仓库，比如：模型的内容实际上存储在一个文件系统中等。同理，Git仓库承载元模型的内容，可以理解为：元模型的内容在物理上存储在Git仓库中，或者，元模型的内容在逻辑上归属于Git仓库，比如：元模型的内容实际上存储在一个文件系统中等。而通过模型Git仓库的分支/Tag和元模型Git仓库的分支/Tag之间的关联关系承载模型和元模型间的版本配套关系，可以理解为：通过模型Git仓库的分支/Tag和元模型Git仓库的分支/Tag之间的关联关系来表征/描述模型和元模型间的版本配套关系。

下面对图1所示的模型服务100进行详细描述。

示例性的，图2示出了本申请实施例提供的一种管理模型和元模型的模型服务的架构示意图。如图2所示，该模型服务100可以包括Console微服务110、管理微服务120、Git微服务130、关系型数据库140和文件存储数据库150。其中，Console微服务110主要是用于对外提供页面访问能力。管理微服务120主要是用于负责模型和元模型的管理。Git微服务130主要是承载Git系统，以提供模型仓库和元模型仓库，以及仓库的分支/Tag的管理能力。管理微服务120可以配套使用关系型数据库140，以存储描述与模型和元模型管理相关的信息，例如元模型和模型的名称、简介，以及创建人、创建时间等信息。Git微服务130配套使用文件存储数据库150，以实现Git仓库中文件的分布式存储，满足高可用需求。

管理微服务120中的元模型管理模块底层可以对接Git微服务130提供的具体的元模型仓库，模型管理模块底层可以对接Git微服务130提供的具体的模型仓库。另外，管理微服务120中的元模型管理模块可以通过元模型仓库的分支或Tag管理具体的元模型版本，模型管理模块可以通过模型仓库的分支或Tag管理具体的模型版本。

Git微服务130提供的元模型仓库中的分支/Tag可以承载元模型的内容，模型仓库中的分支/Tag可以承载模型的内容。而元模型仓库中的分支/Tag和模型仓库中的分支/Tag之间的关联关系承载模型和元模型间的版本配套关系。另外，一个元模型仓库中的分支/Tag可以与至少一个模型仓库中的分支/Tag之间具有关联关系，以实现元模型和模型的版本映射。举例来说，如图3所示，开发者开发了三个模型，分别为模型A、模型B和模型C，不同的模型通过不同的Git仓库承载，各个模型的版本均通过承载模型的仓库的分支/Tag进行管理；架构师设计了一个元模型，该元模型通过一个Git仓库承载，元模型的版本通过承载元模型的仓库的分支/Tag进行管理。在图3中，模型A、B和C的Git仓库的分支/Tag2均与元模型的Git仓库的分支/Tag1具有关联关系，这样就实现了元模型和模型的版本映射。

为便于理解，下面分场景介绍通过Git系统管理元模型和模型的过程。

(1)场景一

如图4所示，在该场景下，模型在一个版本开发阶段存在多个迭代版本，这多个迭代版本对应一个模型的Git仓库的分支，比如，在开发版本A时，这个过程中的迭代版本均对应模型的Git仓库的分支1。在模型开发过程中，当某个迭代版本被发布时，可以从该版本对应的模型所在的Git仓库的分支打出模型的Git仓库的Tag，并对外发布；而对于基于其他的迭代版本打出模型的Git仓库的Tag则可以不发布。以及，将模型的发布版本时打出的Git仓库的Tag作为模型发布版本的最终发布件。并且，将模型的Git仓库的分支和Tag均关联至一个元模型的Git仓库的分支，以便与元模型对应的发布版本配套。当某个迭代版本发布时，该迭代版本对应的Git仓库的分支所关联的元模型同样也可以发布版本，以及，将元模型的Git仓库的分支转为同名Tag，并作为元模型发布版本的最终发布件。另外，由于模型的Git仓库的分支后续可能会继续出补丁版本，因此可以在模型发布版本的生命周期结束，且不在出补丁版本后删除该Git仓库的分支。在该场景下，模型和元模型的管理均较为严格，且使用Git仓库的Tag来承载模型和元模型的内容，以及，使用模型的Git仓库的Tag和元模型的Git仓库的Tag之间的关联关系承载模型和元模型间的版本配套关系。另外，在图4中，在规划下一个版本(即版本B)时，可以可以从版本A对应的Git仓库的Tag处拉取新的分支2，并通过分支2开发版本B，由此通过版本数据继承的方式开发版本B，而无需全量复制数据，大幅提升了开发效率。同时，在规划下一个版本时，可以从元模型的版本A对应的Git仓库的Tag处拉取新的分支2。

在图4中，当模型的版本A发布时，可以通过模型的Git仓库的Tag1承载模型的内容，并通过元模型的Git仓库的Tag1承载元模型的内容，以及，通过模型的Git仓库的Tag1和元模型的Git仓库的Tag1之间的关联关系承载模型和元模型间的版本配套关系。当模型的版本B发布时，可以通过模型的Git仓库的Tag2承载模型的内容，并通过元模型的Git仓库的Tag2承载元模型的内容，以及，通过模型的Git仓库的Tag2和元模型的Git仓库的Tag2之间的关联关系承载模型和元模型间的版本配套关系。

(2)场景二

如图5所示，模型在一个版本开发阶段存在多个迭代版本，这多个迭代版本对应一个模型的Git仓库的分支，比如，在开发版本A时，这个过程中的迭代版本均对应模型的Git仓库的分支1。在模型开发过程中，当某个迭代版本被发布时，可以从该版本对应的模型所在的Git仓库的分支打出模型的Git仓库的Tag，并对外发布；；而对于基于其他的迭代版本打出模型的Git仓库的Tag则可以不发布。以及，将模型的发布版本时打出的Git仓库的Tag作为模型发布版本的最终发布件。并且，将模型的Git仓库的分支和Tag均关联至一个元模型的Git仓库的分支，以便与元模型对应的发布版本配套。当某个迭代版本发布时，该迭代版本对应的Git仓库的分支所关联的元模型同样也可以发布版本，但元模型的版本发布后并不会将元模型的Git仓库的分支转为同名Tag，而是通过人工管理手段限制修改。元模型的Git仓库的分支在元模型的版本发布后，仅能做字段描述修改等不影响逻辑的修改。该场景可以适用于元模型的版本数据不会被客户现场使用的场景，即元模型的版本数据仅保持在研发组织内，客户现场仅会用到模型的版本数据。另外，在图5中，在规划下一个版本(即版本B)时，可以从版本A对应的Git仓库的Tag处拉取新的分支2，并通过分支2开发版本B，由此通过版本数据继承的方式开发版本B，而无需全量复制数据，大幅提升了开发效率。同时，在规划下一个版本时，可以从元模型的版本A对应的Git仓库的分支处拉取新的分支2。

在图5中，当模型的版本A发布时，可以通过模型的Git仓库的Tag1承载模型的内容，并通过元模型的Git仓库的分支1承载元模型的内容，以及，通过模型的Git仓库的Tag1和元模型的Git仓库的分支1之间的关联关系承载模型和元模型间的版本配套关系。当模型的版本B发布时，可以通过模型的Git仓库的Tag2承载模型的内容，并通过元模型的Git仓库的分支2承载元模型的内容，以及，通过模型的Git仓库的Tag2和元模型的Git仓库的分支2之间的关联关系承载模型和元模型间的版本配套关系。

(3)场景三

如图6所示，在该场景下，模型在一个版本开发阶段存在多个迭代版本，这多个迭代版本对应一个模型的Git仓库中一个主分支上不同的子分支，比如，在开发版本A时，这个过程中的迭代版本1对应模型的Git仓库的主分支1中的子分支11，迭代版本2对应模型的Git仓库的主分支1中的子分支12。在该场景下，在开发每个迭代版本时，均需要从Git仓库的主分支上拉取一个子分支，且该子分支需要从前一个拉取的子分支中同步内容，此时，前一个拉取的子分支中承载有模型的内容。例如，在开发模型的版本A时，当开发迭代版本2时，需要新拉取子分支12，同时从子分支11中同步迭代版本1的内容，此时，子分支11承载迭代版本1的内容。当某个迭代版本被发布时，可以从该版本对应的模型所在的Git仓库的分支打出模型的Git仓库的Tag，并对外发布；而对于未被发布的迭代版本则不强制打出模型的Git仓库的分支的Tag。以及，将模型的Git仓库的最后一个迭代版本对应的Git仓库的Tag作为模型发布版本的最终发布件。并且，将模型的Git仓库的分支和Tag均关联至一个元模型的Git仓库的分支，以便与元模型对应的发布版本配套。当某个迭代版本发布时，该迭代版本对应的Git仓库的分支所关联的元模型同样也可以发布版本，但元模型的版本发布后并不会将元模型的Git仓库的分支转为同名Tag，而是通过人工管理手段限制修改。另外，在图6中，在规划下一个版本(即版本B)时，可以可以从版本A对应的Git仓库的分支处拉取新的分支2，并通过分支2开发版本B，由此通过版本数据继承的方式开发版本B，而无需全量复制数据，大幅提升了开发效率。同时，在规划下一个版本时，可以从元模型的版本A对应的Git仓库的主分支1处拉取新的主分支2。

在图6中，当模型的版本A发布时，可以通过模型的Git仓库的分支1n的Tag1承载模型的内容，并通过元模型的Git仓库的分支1承载元模型的内容，以及，通过模型的Git仓库的分支1n的Tag1和元模型的Git仓库的分支1之间的关联关系承载模型和元模型间的版本配套关系。当模型的版本B发布时，可以通过模型的Git仓库的分支2n的Tag2承载模型的内容，并通过元模型的Git仓库的分支2承载元模型的内容，以及，通过模型的Git仓库的分支2n的Tag2和元模型的Git仓库的分支2之间的关联关系承载模型和元模型间的版本配套关系。

由上述三个场景可以看出，通过Git仓库的分支/Tag承载模型和元模型的内容，在规划模型的版本时，通过在Git仓库中拉分支的方式，可以使得模型的新版本从旧版本继承数据，而无需全量复制数据，提升了模型的开发效率。

另外，通过元模型的Git仓库的分支/Tag与模型的Git仓库的分支/Tag的关联关系承载元模型和模型的版本配套关系，可以在元模型中的数据出现变化时，无需对整个元模型进行重新设计和重构，只需要修改元模型的分支，以及，将修改后的分支通过与模型分支的关联，并将元模型规范的变化传递到模型设计中即可，大幅提升了模型和元模型管理的灵活性。此外，由于本实施例中是通过文件的形式对模型和元模型进行存储，这使得在查询和检索数据时可以直接从文件系统中进行查询和检索，大幅提升了查询和检索效率。

以上即是对通过Git系统管理元模型和模型的介绍。接下来，基于上述内容，基于模型的仓库的分支/Tag和元模型的仓库分支/Tag之间的关联关系的存放形式，对根据元模型的规范对模型进行检查进行介绍。

(1)通过关系型数据库关联模型的仓库的分支/Tag和元模型的仓库的分支/Tag之间的关联关系。

如图7所示，模型的内容和元模型的内容均通过文件的形式在Git仓库中承载，模型的仓库的分支/Tag和元模型的仓库的分支/Tag之间的关联关系通过关系型数据库关联。例如，可以通过关系型数据库记录模型的仓库的分支/Tag和元模型的仓库的分支/Tag之间的关联关系。管理微服务120中的管理模块可以从Git仓库中分别读取元模型文件和模型文件，以及，在模型被修改时或者周期性(比如每隔1分钟、10分钟等)通过元模型文件检查模型文件的规范性，并将产生的模型规范性检查结果放入到关系型数据库140中。

(2)通过关系记录文件的形式关联模型的仓库的分支/Tag和元模型的仓库的分支/Tag之间的关联关系，并通过模型的仓库承载。

如图8所示，模型的内容和元模型的内容均通过文件的形式在Git仓库中承载，模型的仓库的分支/Tag和元模型的仓库的分支/Tag之间的关联关系是以一个关系记录文件的形式承载在模型的Git仓库中。该关系记录文件无需在Console服务110提供的模型管理页面中直接呈现，仅作为后台存储的隐藏文件即可。此外，该关系记录文件依赖元模型的仓库。管理微服务120中的管理模块可以从Git仓库中分别读取元模型文件和模型文件，以及，在模型被修改时或者周期性(比如每隔1分钟、10分钟等)通过元模型文件检查模型文件的规范性，并将产生的模型规范性检查结果放入到关系型数据库140中。

以上即是对通过Git系统管理元模型和模型，以及，对根据元模型的规范对模型进行检查的相关介绍。接下来，基于上述内容，对本申请实施例提供的一种元模型和模型的处理方法进行介绍。可以理解的是，该方法是基于上文所描述的内容提出，该方法中的部分或全部内容可以参见上文中的相关描述。

示例性的，图9示出了本申请实施例提供的一种元模型和模型的处理方法的流程示意图。可以理解，该方法可以通过任何具有计算、处理能力的装置、设备、平台、设备集群来执行。

如图9所示，该元模型和模型的处理方法可以包括以下步骤：

S901、利用第一仓库承载元模型的内容，以及，利用包含至少一个仓库的仓库组承载至少一个模型的内容，其中，仓库组中一个仓库用于承载一个模型的内容，第一仓库和仓库组中的仓库均为可使用版本控制系统进行管理和/或追踪的代码仓库。

S902、利用第一仓库和仓库组中仓库之间的关联关系表征元模型和至少一个模型的版本配套关系。

这样，通过可使用版本控制系统进行管理和/或追踪的代码仓库承载元模型和模型的内容，在规划模型的版本时，通过在相应的代码仓库中拉分支的方式，可以使得模型和元模型的新版本均可以从旧版本继承数据，而无需全量复制数据，提升了模型的开发效率。同时，通过承载元模型的仓库和承载模型的仓库之间的关联关系表征元模型和模型的版本配套关系，可以在元模型中的数据出现变化时，无需对整个元模型进行重新设计和重构，只需要修改元模型的分支，以及，将修改后的分支通过与模型分支的关联，并将元模型规范的变化传递到模型设计中即可，大幅提升了模型和元模型管理的灵活性。此外，由于本实施例中是通过文件的形式对模型和元模型进行存储，这使得在查询和检索数据时可以直接从文件系统中进行查询和检索，大幅提升了查询和检索效率。

在一些实施例中，元模型的内容可以通过第一仓库的分支/Tag承载。前述的至少一个模型中包括第一模型，仓库组中包括第二仓库，该第一模型的内容可以通过第二仓库的分支/Tag承载。元模型和第一模型的版本配套关系可以通过第一仓库的分支/Tag和第二仓库的分支/Tag之间的关联关系表征。

另外，前述的至少一个模型中还包括第二模型，仓库组中还包括第三仓库。此时，第二模型的内容通过第三仓库的的分支/Tag承载。元模型和第二模型的版本配套关系通过第一仓库的分支/Tag和第三仓库的分支/Tag之间的关联关系表征。

在一些实施例中，在规划模型的新版本的情况下，可以从承载元模型的第一仓库中拉取新的第一分支，以及，从承载模型的仓库中拉取新的第二分支，并将第一分支和第二分支进行关联。在模型的新版本发布的情况下，可以将第一分支转换为同名的第一Tag，并将第一Tag作为元模型的新版本的发布件，以及，基于第二分支打出承载模型的仓库的第二Tag，并将第二Tag作为新版本的发布件。并且，可以将第一Tag和第二Tag进行关联。示例性的，可以通过关系型数据库记录第一Tag和第二Tag之间的关联关系，也可以通过关系记录文件记录第一Tag和第二Tag之间的关联关系。由此以实现新版本的开发，且开发的元模型和模型的新版本均可以通过相应的仓库承载，以及，可以通过相应的仓库之间的关联关系表征元模型和模型之间的版本配套关系。

在一些实施例中，在规划第一模型的新版本的情况下，在规划模型的新版本的情况下，从第一仓库中拉取新的第一分支，以及，从承载模型的仓库中拉取新的第二分支，并将第一分支和第二分支进行关联；在模型的新版本发布的情况下，基于第二分支打出承载模型的仓库的第一Tag，并将第一Tag作为新版本的发布件，且将第一Tag和第一分支进行关联。示例性的，可以通过关系型数据库记录第一Tag和第一分支之间的关联关系，也可以通过关系记录文件记录第一Tag和第一分支之间的关联关系。由此以实现新版本的开发，且开发的元模型和模型的新版本均可以通过相应的仓库承载，以及，可以通过相应的仓库之间的关联关系表征元模型和模型之间的版本配套关系。

在一些实施例中，用户可以对目标对象(比如：元模型或模型等)进行修改，此时在用户下发的与版本控制系统相关的修改命令后，可以获取用户输入的针对目标对象的修改命令。之后，可以响应于该修改命令，对目标对象进行修改。由此即可以通过与版本控制系统相关的修改命令直接对目标对象修改，而无需再对与目标对象相关联的对象进行修改，大幅提升了开发效率。

可以理解的是，上述实施例中各步骤的序号的大小并不意味着执行顺序的先后，各过程的执行顺序应以其功能和内在逻辑确定，而不应对本申请实施例的实施过程构成任何限定。此外，在一些可能的实现方式中，上述实施例中的各步骤可以根据实际情况选择性执行，可以部分执行，也可以全部执行，此处不做限定。

以上即是对本申请实施例提供的元模型和模型的处理方法的介绍。接下来，基于上述实施例中的方法，对本申请实施例提供的一种元模型和模型的处理装置进行介绍。

示例性的，图10示出了本申请实施例提供的一种元模型和模型的处理装置的结构示意图。如图10所示，该元模型和模型的处理装置1000可以包括：第一处理模块1001和第二处理模块1002。其中，第一处理模块1001，用于利用第一仓库承载元模型的内容，以及，利用包含至少一个仓库的仓库组承载至少一个模型的内容，其中，仓库组中一个仓库用于承载一个模型的内容，第一仓库和仓库组中的仓库均为可使用版本控制系统进行管理和/或追踪的代码仓库。第二处理模块1002，用于利用第一仓库和仓库组中仓库之间的关联关系表征元模型和至少一个模型的版本配套关系。

在一些实施例中，元模型的内容通过第一仓库的分支/Tag承载。至少一个模型中包括第一模型，仓库组中包括第二仓库，第一模型的内容通过第二仓库的分支/Tag承载。元模型和第一模型的版本配套关系通过第一仓库的分支/Tag和第二仓库的分支/Tag之间的关联关系表征。

在一些实施例中，至少一个模型中还包括第二模型，仓库组中还包括第三仓库，第二模型的内容通过第三仓库的的分支/Tag承载。元模型和第二模型的版本配套关系通过第一仓库的分支/Tag和第三仓库的分支/Tag之间的关联关系表征。

在一些实施例中，该装置还包括：第三处理模块(图中未示出)，用于：在规划第一模型的新版本的情况下，从第一仓库中拉取新的第一分支，以及，从第二仓库中拉取新的第二分支，并将第一分支和第二分支进行关联；在新版本发布的情况下，基于第一分支打出的第一仓库的第一Tag，并将第一Tag作为新版本的发布件；将第二分支转换为同名的第二Tag，并将第二Tag作为元模型的新版本的发布件，以及，将第一Tag和第二Tag进行关联。

在一些实施例中，该装置还包括：第三处理模块(图中未示出)，用于：在规划第一模型的新版本的情况下，从第一仓库中拉取新的第一分支，以及，从第二仓库中拉取新的第二分支，并将第一分支和第二分支进行关联；在新版本发布的情况下，基于第一分支打出的第一仓库的第一Tag，并将第一Tag作为新版本的发布件，以及，将第一Tag和第二分支进行关联。

在一些实施例中，该装置还包括：第四处理模块(图中未示出)，用于：获取用户输入的针对目标对象的修改命令，目标对象为模型或元模型，修改命令与版本控制系统相关；响应于修改命令，对目标对象进行修改。

在一些实施例中，图10中所示的第一处理模块1001和第二处理模块1002均可以通过软件实现，或者可以通过硬件实现。示例性的，接下来以第一处理模块1001为例，介绍第一处理模块1001的实现方式。类似的，第二处理模块1002的实现方式可以参考第一处理模块1001的实现方式。

模块作为软件功能单元的一种举例，第一处理模块1001可以包括运行在计算实例上的代码。其中，计算实例可以包括物理主机(计算设备)、虚拟机、容器中的至少一种。进一步地，上述计算实例可以是一台或者多台。例如，第一处理模块1001可以包括运行在多个主机/虚拟机/容器上的代码。需要说明的是，用于运行该代码的多个主机/虚拟机/容器可以分布在相同的区域(region)中，也可以分布在不同的region中。进一步地，用于运行该代码的多个主机/虚拟机/容器可以分布在相同的可用区(availability zone，AZ)中，也可以分布在不同的AZ中，每个AZ包括一个数据中心或多个地理位置相近的数据中心。其中，通常一个region可以包括多个AZ。

同样，用于运行该代码的多个主机/虚拟机/容器可以分布在同一个虚拟私有云(virtual private cloud，VPC)中，也可以分布在多个VPC中。其中，通常一个VPC设置在一个region内，同一region内两个VPC之间，以及不同region的VPC之间跨区通信需在每个VPC内设置通信网关，经通信网关实现VPC之间的互连。

模块作为硬件功能单元的一种举例，第一处理模块1001可以包括至少一个计算设备，如服务器等。或者，第一处理模块1001也可以是利用专用集成电路(application-specific integrated circuit，ASIC)实现、或可编程逻辑器件(programmable logicdevice，PLD)实现的设备等。其中，上述PLD可以是复杂程序逻辑器件(complexprogrammable logical device，CPLD)、现场可编程门阵列(field-programmable gatearray，FPGA)、通用阵列逻辑(generic array logic，GAL)或其任意组合实现。

第一处理模块1001包括的多个计算设备可以分布在相同的region中，也可以分布在不同的region中。第一处理模块1001包括的多个计算设备可以分布在相同的AZ中，也可以分布在不同的AZ中。同样，第一处理模块1001包括的多个计算设备可以分布在同一个VPC中，也可以分布在多个VPC中。其中，所述多个计算设备可以是服务器、ASIC、PLD、CPLD、FPGA和GAL等计算设备的任意组合。

需要说明的是，在其他实施例中，第一处理模块1001可以用于执行上述实施例描述的元模型和模型的处理方法中的任意步骤，第二处理模块1002可以用于执行上述实施例描述的元模型和模型的处理方法中的任意步骤,第一处理模块1001和第二处理模块1002负责实现的步骤可根据需要指定，通过第一处理模块1001和第二处理模块1002分别实现上述实施例描述的元模型和模型的处理方法中不同的步骤来实现图10所示的元模型和模型的处理装置1000的全部功能。

本申请还提供一种计算设备1100。如图11所示，计算设备1100包括：总线1102、处理器1104、存储器1106和通信接口1108。处理器1104、存储器1106和通信接口1108之间通过总线1102通信。计算设备1100可以是服务器或终端设备。应理解，本申请不限定计算设备1100中的处理器、存储器的个数。

总线1102可以是外设部件互连标准(peripheral component interconnect，PCI)总线或扩展工业标准结构(extended industry standard architecture，EISA)总线等。总线可以分为地址总线、数据总线、控制总线等。为便于表示，图11中仅用一条线表示，但并不表示仅有一根总线或一种类型的总线。总线1104可包括在计算设备1100各个部件(例如，存储器1106、处理器1104、通信接口1108)之间传送信息的通路。

处理器1104可以包括中央处理器(central processing unit，CPU)、图形处理器(graphics processing unit，GPU)、微处理器(micro processor，MP)或者数字信号处理器(digital signal processor，DSP)等处理器中的任意一种或多种。

存储器1106可以包括易失性存储器(volatile memory)，例如随机存取存储器(random access memory，RAM)。处理器1104还可以包括非易失性存储器(non-volatilememory)，例如只读存储器(read-only memory，ROM)，快闪存储器，机械硬盘(hard diskdrive，HDD)或固态硬盘(solid state drive，SSD)。

存储器1106中存储有可执行的程序代码，处理器1104执行该可执行的程序代码以分别实现前述图10中所示的第一处理模块1001和第一处理模块1002的功能，从而实现上述实施例描述的元模型和模型的处理方法。也即，存储器1106上存有用于执行上述实施例描述的元模型和模型的处理方法的指令。

或者，存储器1106中存储有可执行的代码，处理器1104执行该可执行的代码以分别实现前述图10中所示的元模型和模型的处理装置1000的功能，从而实现上述实施例描述的元模型和模型的处理方法。也即，存储器1106上存有用于执行上述实施例描述的元模型和模型的处理方法的指令。

通信接口1103使用例如但不限于网络接口卡、收发器一类的收发模块，来实现计算设备1100与其他设备或通信网络之间的通信。

本申请实施例还提供了一种计算设备集群。该计算设备集群包括至少一台计算设备。该计算设备可以是服务器，例如是中心服务器、边缘服务器，或者是本地数据中心中的本地服务器。在一些实施例中，计算设备也可以是台式机、笔记本电脑或者智能手机等终端设备。

如图12所示，所述计算设备集群包括至少一个计算设备1100。计算设备集群中的一个或多个计算设备1100中的存储器1106中可以存有相同的用于执行上述实施例描述的元模型和模型的处理方法的指令。

在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备1100的存储器1106中也可以分别存有用于执行上述实施例描述的元模型和模型的处理方法的部分指令。换言之，一个或多个计算设备1100的组合可以共同执行用于执行上述实施例描述的元模型和模型的处理方法的指令。

需要说明的是，计算设备集群中的不同的计算设备1100中的存储器1106可以存储不同的指令，分别用于执行前述图10所示的元模型和模型的处理装置1000的部分功能。也即，不同的计算设备1100中的存储器1106存储的指令可以实现第一处理模块1001和第二处理模块1002中的一个或多个模块的功能。

在一些可能的实现方式中，计算设备集群中的一个或多个计算设备可以通过网络连接。其中，所述网络可以是广域网或局域网等等。图13示出了一种可能的实现方式。如图13所示，两个计算设备1100A和1100B之间通过网络进行连接。具体地，通过各个计算设备中的通信接口与所述网络进行连接。在这一类可能的实现方式中，计算设备1100A中的存储器1106中存有执行第一处理模块1001的功能的指令。同时，计算设备1100B中的存储器1106中存有执行第二处理模块1002的功能的指令。

应理解，图13中示出的计算设备1100A的功能也可以由多个计算设备1100完成。同样，计算设备1100B的功能也可以由多个计算设备1100完成。

本申请实施例还提供了另一种计算设备集群。该计算设备集群中各计算设备之间的连接关系可以类似的参考图12和图13所述计算设备集群的连接方式。不同的是，该计算设备集群中的一个或多个计算设备1100中的存储器1106中可以存有相同的用于执行上述实施例中方法的指令。

在一些可能的实现方式中，该计算设备集群中的一个或多个计算设备1100的存储器1106中也可以分别存有用于执行前述数据元模型和模型的处理方法的部分指令。换言之，一个或多个计算设备1100的组合可以共同执行用于执行前述数据元模型和模型的处理方法的指令。

基于上述实施例中的方法，本申请实施例提供了一种计算机可读存储介质，包括计算机程序指令，当计算机程序指令由计算设备执行时，计算设备执行上述实施例中的方法；或者，当计算机程序指令由计算设备集群执行时，计算设备集群执行上述实施例中的方法。示例性的，该计算机可读存储介质可以是计算设备能够存储的任何可用介质或者是包含一个或多个可用介质的数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘)等。

基于上述实施例中的方法，本申请实施例提供了一种包含指令的计算机程序产品，当指令被计算设备运行时，使得计算设备执行上述实施例中的方法，或者，当指令被计算设备集群运行时，使得计算设备集群执行上述实施例中的方法。

可以理解的是，本申请的实施例中的处理器可以是中央处理单元(centralprocessing unit，CPU)，还可以是其他通用处理器、数字信号处理器(digital signalprocessor，DSP)、专用集成电路(application specific integrated circuit，ASIC)、现场可编程门阵列(field programmable gate array，FPGA)或者其他可编程逻辑器件、晶体管逻辑器件，硬件部件或者其任意组合。通用处理器可以是微处理器，也可以是任何常规的处理器。

本申请的实施例中的方法步骤可以通过硬件的方式来实现，也可以由处理器执行软件指令的方式来实现。软件指令可以由相应的软件模块组成，软件模块可以被存放于随机存取存储器(random access memory，RAM)、闪存、只读存储器(read-only memory，ROM)、可编程只读存储器(programmable rom，PROM)、可擦除可编程只读存储器(erasable PROM，EPROM)、电可擦除可编程只读存储器(electrically EPROM，EEPROM)、寄存器、硬盘、移动硬盘、CD-ROM或者本领域熟知的任何其它形式的存储介质中。一种示例性的存储介质耦合至处理器，从而使处理器能够从该存储介质读取信息，且可向该存储介质写入信息。当然，存储介质也可以是处理器的组成部分。处理器和存储介质可以位于ASIC中。

在上述实施例中，可以全部或部分地通过软件、硬件、固件或者其任意组合来实现。当使用软件实现时，可以全部或部分地以计算机程序产品的形式实现。所述计算机程序产品包括一个或多个计算机指令。在计算机上加载和执行所述计算机程序指令时，全部或部分地产生按照本申请实施例所述的流程或功能。所述计算机可以是通用计算机、专用计算机、计算机网络、或者其他可编程装置。所述计算机指令可以存储在计算机可读存储介质中，或者通过所述计算机可读存储介质进行传输。所述计算机指令可以从一个网站站点、计算机、服务器或数据中心通过有线(例如同轴电缆、光纤、数字用户线(DSL))或无线(例如红外、无线、微波等)方式向另一个网站站点、计算机、服务器或数据中心进行传输。所述计算机可读存储介质可以是计算机能够存取的任何可用介质或者是包含一个或多个可用介质集成的服务器、数据中心等数据存储设备。所述可用介质可以是磁性介质，(例如，软盘、硬盘、磁带)、光介质(例如，DVD)、或者半导体介质(例如固态硬盘(solid state disk，SSD))等。

可以理解的是，在本申请的实施例中涉及的各种数字编号仅为描述方便进行的区分，并不用来限制本申请的实施例的范围。

最后应说明的是：以上实施例仅用以说明本申请的技术方案，而非对其限制；尽管参照前述实施例对本申请进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换；而这些修改或者替换，并不使相应技术方案的本质脱离本申请各实施例技术方案的保护范围。

Claims (10)

1.一种元模型和模型的处理方法，其特征在于，包括：

利用第一仓库承载元模型的内容，以及，利用包含至少一个仓库的仓库组承载至少一个模型的内容，其中，所述仓库组中一个仓库用于承载一个模型的内容，所述第一仓库和所述仓库组中的仓库均为可使用版本控制系统进行管理和/或追踪的代码仓库；

利用所述第一仓库和所述仓库组中仓库之间的关联关系表征所述元模型和所述至少一个模型的版本配套关系。

2.根据权利要求1所述的方法，其特征在于，所述元模型的内容通过所述第一仓库的分支/Tag承载；

所述至少一个模型中包括第一模型，所述仓库组中包括第二仓库，所述第一模型的内容通过所述第二仓库的分支/Tag承载；

所述元模型和所述第一模型的版本配套关系通过所述第一仓库的分支/Tag和所述第二仓库的分支/Tag之间的关联关系表征。

3.根据权利要求2所述的方法，其特征在于，所述至少一个模型中还包括第二模型，所述仓库组中还包括第三仓库，所述第二模型的内容通过所述第三仓库的的分支/Tag承载；

所述元模型和所述第二模型的版本配套关系通过所述第一仓库的分支/Tag和所述第三仓库的分支/Tag之间的关联关系表征。

4.根据权利要求1-3任一所述的方法，其特征在于，还包括：

在规划所述模型的新版本的情况下，从所述第一仓库中拉取新的第一分支，以及，从承载所述模型的仓库中拉取新的第二分支，并将所述第一分支和所述第二分支进行关联；

在所述模型的新版本发布的情况下，将所述第一分支转换为同名的第一Tag，并将所述第一Tag作为所述元模型的新版本的发布件，以及，基于所述第二分支打出承载所述模型的仓库的第二Tag，并将所述第二Tag作为所述新版本的发布件，且将所述第一Tag和所述第二Tag进行关联。

5.根据权利要求1-3任一所述的方法，其特征在于，还包括：

在规划所述模型的新版本的情况下，从所述第一仓库中拉取新的第一分支，以及，从承载所述模型的仓库中拉取新的第二分支，并将所述第一分支和所述第二分支进行关联；

在所述模型的新版本发布的情况下，基于所述第二分支打出承载所述模型的仓库的第一Tag，并将所述第一Tag作为所述新版本的发布件，且将所述第一Tag和所述第一分支进行关联。

6.根据权利要求1-5任一所述的方法，其特征在于，还包括：

获取用户输入的针对目标对象的修改命令，所述目标对象为所述模型或所述元模型，所述修改命令与所述版本控制系统相关；

响应于所述修改命令，对所述目标对象进行修改。

7.一种处理元模型和模型的装置，其特征在于，包括：

第一处理模块，用于利用第一仓库承载元模型的内容，以及，利用包含至少一个仓库的仓库组承载至少一个模型的内容，其中，所述仓库组中一个仓库用于承载一个模型的内容，所述第一仓库和所述仓库组中的仓库均为可使用版本控制系统进行管理和/或追踪的代码仓库；

第二处理模块，用于利用所述第一仓库和所述仓库组中仓库之间的关联关系表征所述元模型和所述至少一个模型的版本配套关系。

8.一种计算设备集群，其特征在于，包括至少一个计算设备，每个计算设备均包括处理器和存储器；

所述至少一个计算设备的处理器用于执行所述至少一个计算设备的存储器中存储的指令，以使得所述计算设备集群执行如权利要求1-6任一所述的方法。

9.一种计算机可读存储介质，其特征在于，包括计算机程序指令，当所述指令被计算设备集群运行时，使得所述计算设备集群执行如权利要求1-6任一所述的方法，其中，所述计算设备集群包括至少一个计算设备。

10.一种包含指令的计算机程序产品，其特征在于，当所述指令被计算设备集群运行时，使得所述计算设备集群执行如权利要求1-6任一所述的方法，其中，所述计算设备集群包括至少一个计算设备。