CN114816389A - 一种基于元模型的管理***搭建方法、装置、设备及介质 - Google Patents

Abstract

本申请涉及一种基于元模型的管理***搭建方法、装置、设备及介质，涉及资产管理的领域，该方法包括获取用户输入的至少两个属性信息，属性信息表征企业的静态资产，从预设属性元模块中确定与各个属性信息各自对应的目标属性元模块，从预设服务元模型中确定每个目标属性元模块对应的目标服务元模型，服务元模型表征每个目标属性元模块对应的操作行为，建立每个目标服务元模型之间的关联关系，以得到至少两个属性信息对应的管理***。本申请具有提高管理***的开发效率的效果。

Description

一种基于元模型的管理***搭建方法、装置、设备及介质

技术领域

本申请涉及资产管理的领域，尤其是涉及一种基于元模型的管理***搭建方法、装置、设备及介质。

背景技术

在企业日常运营中，通常需要用到的管理***或控制***等，例如MES ***、APS***、质量管理***以及设备维护***等，以此对企业的运作、设备以及物料等静态资产进行管理。

由于企业的生产类型以及经营内容等方面的不同，针对不同企业管理***的开发，主要通过相关开发人员根据企业需求编写代码的方式实现，在出现新的企业需求时，需重新编写代码，从而导致管理***开发周期长，开发效率较低。

发明内容

为了提高管理***的开发效率，本申请提供一种基于元模型的管理***搭建方法、装置、设备及介质。

第一方面，本申请提供一种基于元模型的管理***搭建方法，采用如下的技术方案：

一种基于元模型的管理***搭建方法，包括：

获取用户输入的至少两个属性信息，所述属性信息表征企业的静态资产；

从预设属性元模块中确定与各个属性信息各自对应的目标属性元模块；

从预设服务元模型中确定每个目标属性元模块对应的目标服务元模型，所述服务元模型表征每个目标属性元模块对应的操作行为；

建立每个目标服务元模型之间的关联关系，以得到所述至少两个属性信息对应的管理***。

通过采用上述技术方案，获取用户输入的至少两个属性信息，并且从预设属性元模块中确定与属性信息对应的目标属性元模块。目标属性元模块为用户需要进行管理的静态资产的抽象，从预设服务元模型中确定与目标属性元模块对应的目标服务元模型，目标服务元模型为对应的目标属性元模块的相关操作，建立每个目标服务元模型之间的关联关系，从而得到目标属性元模块之间的关联逻辑，进而得到至少两个属性信息对应的管理***，根据开发需求从预设属性元模块中确定目标属性元模块、从预设服务元模型中确定目标服务元模型以及建立目标服务元模型之间的关系，从而搭建出所需的管理***，相较于编写代码效率更高。

在另一种可能实现的方式中，所述建立每个目标服务元模型之间的关联关系，包括：

从所述每个目标服务元模型中确定第一服务元模型以及第二服务元模型；

从预设事件元模型中确定目标事件元模型；

建立所述第一服务元模型、第二服务元模型以及目标事件元模型的对应关系，所述目标事件元模型用于所述第二服务元模型监听所述第一服务元模型是否触发，当所述第一服务元模型触发时，触发事件元模型以使得第二服务元模型监听到所述第一服务元模型已触发；

基于所述对应关系确定所述每个目标服务元模型之间的关联关系。

通过采用上述技术方案，第一服务元模型和第二服务元模型为需要产生对应关系的服务元模型。从预设事件元模型中确定所需的目标事件元模型，目标事件元模型连接第一服务元模型以及第二服务元模型，监听第一服务元模型是否触发，第一服务元模型触发后触发目标事件元模型，从而便于第二服务元模型得知第一服务元模型触发。

在另一种可能实现的方式中，所述基于所述对应关系确定所述每个目标服务元模型之间的关联关系，包括：

从预设订阅元模型中确定所述第二服务元模型对应的目标订阅元模型；

建立所述目标事件元模型、第二服务元模型以及目标订阅元模型的关联关系，所述订阅元模型表征当所述目标事件元模型触发时，触发所述第二服务元模型。

通过采用上述技术方案，从预设订阅元模型中确定第二服务元模型对应的目标订阅元模型，从而在目标事件元模型触发时，触发目标订阅元模型，进而控制第二服务元模型触发，从而达到自动控制第二服务元模型的效果。

在另一种可能实现的方式中，所述方法还包括：

建立每个属性信息对应的操作链接；

确定所述操作链接与对应的目标服务元模型的对应关系。

通过采用上述技术方案，操作链接用于控制属性信息对应的静态资产，设置操作链接并且将操作链接与对应的目标服务元模型进行对应，从而便于人员在初始触发静态资产时，与静态资产对应的目标服务元模型具有关联关系的服务元模型按照关联关系触发，更加方便。

在另一种可能实现的方式中，所述方法还包括：

若检测到确定目标属性元模块，则生成所述目标属性元模块对应的选择链接，所述选择链接包括所述目标属性元模块对应的至少一个预设服务元模型的选择链接；

控制显示所述选择链接；

若检测到针对任一预设服务元模型对应的选择链接的选中指令，则确定所述目标属性元模块与所述任一预设服务元模型的对应关系。

通过采用上述技术方案，检测到确定目标属性元模块，说明目标属性元模块已经建立，进而需要确定对应的目标服务元模型。因此检测到确定目标属性元模块后，生成该目标属性元模块对应的选择链接，并自动显示，从而便于工作人员选择所需的服务元模型，提高开发效率。检测到针对任一预设服务元模型的选中指令，则说明用户确定该目标属性元模块对应的服务元模型，进而完成确定目标属性元模块与该服务元模型的对应关系。

在另一种可能实现的方式中，当所述目标属性元模型对应至少两个预设服务元模型时，所述控制显示所述选择链接，包括：

获取每个预设服务元模型对应的使用次数；

基于所述使用次数对所述每个预设服务元模型进行由大到小排序；

基于所述排序结果控制显示所述选择链接。

通过采用上述技术方案，对每个预设服务元模型的使用次数进行排序，从而便于得知每个预设服务元模型的使用情况，按照由大到小的排序结果显示选择链接，将经常使用的服务元模型优先显示，进一步便于用户确定预设服务元模型。

在另一种可能实现的方式中，所述方法还包括：

若检测到针对目标服务元模型的选中指令，则获取所述目标服务元模型的历史关联信息，所述历史关联信息包括所述目标服务元模型在历史中具有关联关系的属性元模块以及对应的服务元模型；

基于所述历史关联信息判断当前已确定的目标服务元模型中是否存在待选目标服务元模型，所述待选目标服务元模型为满足历史关联信息的目标服务元模型；

若存在，则确定所述目标服务元模型与所述待选目标服务元模型的关联关系。

通过采用上述技术方案，检测到针对任一目标服务元模型的选中指令，说明需要对该目标服务元模型匹配其他服务元模型以及属性元模块等。从历史关联信息中判断当前已确定的目标服务元模型中是否存在待选目标服务元模型，若存在，则说明该目标服务元模型与待选目标服务元模型进行过关联，因此直接确定该目标服务元模型与待选服务目标服务元模型的关联关系，从而提高开发效率，缩短开发时间。

第二方面，本申请提供一种基于元模型的管理***搭建装置，采用如下的技术方案：

一种基于元模型的管理***搭建装置，包括：

第一获取模块，用于获取用户输入的至少两个属性信息，所述属性信息表征企业的静态资产；

第一确定模块，用于从预设属性元模块中确定与各个属性信息各自对应的目标属性元模块；

第二确定模块，用于从预设服务元模型中确定每个目标属性元模块对应的目标服务元模型，所述服务元模型表征每个目标属性元模块对应的操作行为；

建立模块，用于建立每个目标服务元模型之间的关联关系，以得到所述至少两个属性信息对应的管理***。

通过采用上述技术方案，第一获取模块用于获取用户输入的至少两个属性信息，并且第一确定模块从预设属性元模块中确定与属性信息对应的目标属性元模块。目标属性元模块为用户需要进行管理的静态资产的抽象，第二确定模块从预设服务元模型中确定与目标属性元模块对应的目标服务元模型，目标服务元模型为对应的目标属性元模块的相关操作，建立模块建立每个目标服务元模型之间的关联关系，从而得到目标属性元模块之间的关联逻辑，进而得到至少两个属性信息对应的管理***，根据开发需求从预设属性元模块中确定目标属性元模块、从预设服务元模型中确定目标服务元模型以及建立目标服务元模型之间的关系，从而搭建出所需的管理***，相较于编写代码效率更高。

在另一种可能的实现方式中，所述建立模块在建立每个目标服务元模型之间的关联关系时，具体用于：

从所述每个目标服务元模型中确定第一服务元模型以及第二服务元模型；

从预设事件元模型中确定目标事件元模型；

建立所述第一服务元模型、第二服务元模型以及目标事件元模型的对应关系，所述目标事件元模型用于所述第二服务元模型监听所述第一服务元模型是否触发，当所述第一服务元模型触发时，触发事件元模型以使得第二服务元模型监听到所述第一服务元模型已触发；

基于所述对应关系确定所述每个目标服务元模型之间的关联关系。

在另一种可能的实现方式中，所述建立模块在基于所述对应关系确定所述每个目标服务元模型之间的关联关系时，具体用于：

从预设订阅元模型中确定所述第二服务元模型对应的目标订阅元模型；

建立所述目标事件元模型、第二服务元模型以及目标订阅元模型的关联关系，所述订阅元模型表征当所述目标事件元模型触发时，触发所述第二服务元模型。

在另一种可能的实现方式中，所述装置还包括：

链接建立模块，用于建立每个属性信息对应的操作链接；

第三确定模块，用于确定所述操作链接与对应的目标服务元模型的对应关系。

在另一种可能的实现方式中，所述装置还包括：

生成模块，用于当检测到确定目标属性元模块时，生成所述目标属性元模块对应的选择链接，所述选择链接包括所述目标属性元模块对应的至少一个预设服务元模型的选择链接；

控制显示模块，用于控制显示所述选择链接；

第四确定模块，用于当检测到针对任一预设服务元模型对应的选择链接的选中指令时，确定所述目标属性元模块与所述任一预设服务元模型的对应关系。

在另一种可能的实现方式中，当所述目标属性元模型对应至少两个预设服务元模型时，所述控制显示模块在控制显示所述选择链接时，具体用于：

获取每个预设服务元模型对应的使用次数；

基于所述使用次数对所述每个预设服务元模型进行由大到小排序；

基于所述排序结果控制显示所述选择链接。

在另一种可能的实现方式中，所述装置还包括：

第二获取模块，用于当检测到针对目标服务元模型的选中指令时，获取所述目标服务元模型的历史关联信息，所述历史关联信息包括所述目标服务元模型在历史中具有关联关系的属性元模块以及对应的服务元模型；

第五确定模块，用于基于所述历史关联信息判断当前已确定的目标服务元模型中是否存在待选目标服务元模型，所述待选目标服务元模型为满足历史关联信息的目标服务元模型；

第六确定模块，用于在存在时，确定所述目标服务元模型与所述待选目标服务元模型的关联关系。

第三方面，本申请提供一种电子设备，采用如下的技术方案：

一种电子设备，该电子设备包括：

一个或多个处理器；

存储器；

一个或多个应用程序，其中一个或多个应用程序被存储在存储器中并被配置为由一个或多个处理器执行，一个或多个应用程序配置用于：执行根据第一方面任一种可能的实现方式所示的一种基于元模型的管理***搭建方法。

第四方面，本申请提供一种计算机可读存储介质，采用如下的技术方案：

一种计算机可读存储介质，当所述计算机程序在计算机中执行时，令所述计算机执行第一方面任一项所述的一种基于元模型的管理***搭建方法。

综上所述，本申请包括以下至少一种有益技术效果：

1. 获取用户输入的至少两个属性信息，并且从预设属性元模块中确定与属性信息对应的目标属性元模块。目标属性元模块为用户需要进行管理的静态资产的抽象，从预设服务元模型中确定与目标属性元模块对应的目标服务元模型，目标服务元模型为对应的目标属性元模块的相关操作，建立每个目标服务元模型之间的关联关系，从而得到目标属性元模块之间的关联逻辑，进而得到至少两个属性信息对应的管理***，根据开发需求从预设属性元模块中确定目标属性元模块、从预设服务元模型中确定目标服务元模型以及建立目标服务元模型之间的关系，从而搭建出所需的管理***，相较于编写代码效率更高；

2. 检测到针对任一目标服务元模型的选中指令，说明需要对该目标服务元模型匹配其他服务元模型以及属性元模块等。从历史关联信息中判断当前已确定的目标服务元模型中是否存在待选目标服务元模型，若存在，则说明该目标服务元模型与待选目标服务元模型进行过关联，因此直接确定该目标服务元模型与待选目标服务元模型的关联关系，从而提高开发效率，缩短开发时间。

附图说明

图1是本申请实施例的一种基于元模型的管理***搭建方法的流程示意图。

图2是本申请实施例的一种基于元模型的管理***搭建装置的结构示意图。

图3是本申请实施例的一种电子设备的结构示意图。

具体实施方式

以下结合附图对本申请作进一步详细说明。

本领域技术人员在阅读完本说明书后可以根据需要对本实施例做出没有创造性贡献的修改，但只要在本申请的权利要求范围内都受到专利法的保护。

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有作出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

另外，本文中术语“和/或”，仅仅是一种描述关联对象的关联关系，表示可以存在三种关系，例如，A和/或B，可以表示：单独存在A，同时存在A和B，单独存在B这三种情况。另外，本文中字符“/”，如无特殊说明，一般表示前后关联对象是一种“或”的关系。

下面结合说明书附图对本申请实施例作进一步详细描述。

模型是对现实的实体特征的抽象，或者说是对抽象的描述。元模型属于模型的一种，用于描述“模型中的元素、元素间关系以及表示方法”。元模型是描述特定领域而定义的一种“抽象语言”，是对模型的进一步抽象。

以生产企业为例，元模型表征生产企业领域相关的模型，用于创建该生产企业领域中的模型的构建元素，例如生产企业中的设备、物料以及人员等静态资产的抽象模型。属性元模块是对企业静态资产的抽象，每个静态资产抽象为一个属性元模块，属性元模型包括全部属性元模块。

本申请实施例提供了一种基于元模型的管理***搭建方法，由电子设备执行，该电子设备可以为服务器也可以为终端设备，其中，该服务器可以是独立的物理服务器，也可以是多个物理服务器构成的服务器集群或者分布式***，还可以是提供云计算服务的云服务器。终端设备可以是智能手机、平板电脑、笔记本电脑、台式计算机等，但并不局限于此，该终端设备以及服务器可以通过有线或无线通信方式进行直接或间接地连接，本申请实施例在此不做限制，如图1所示，该方法包括步骤S101、步骤S102、步骤S103以及步骤S104，其中，

S101，获取用户输入的至少两个属性信息。

其中，属性信息表征企业的静态资产。

对于本申请实施例，企业静态资产包括设备、物料以及人员等，用户输入的属性信息表征静态资产。例如用户可通过键盘、鼠标以及触控板等输入设备输入属性信息，例如输入“某某设备”以及“某某员工”等。获取到用户输入的属性信息后，从而便于搭建属性信息对应的管理***。

S102，从预设属性元模块中确定与各个属性信息各自对应的目标属性元模块。

对于本申请实施例，预设属性元模块为每个属性信息对应的属性元模块，例如，“设备A”对应属性元模块1，“设备B”对应属性元模块2，“物料A”对应属性元模块3，“人员A”对应属性元模块4等。电子设备检测到用户输入属性信息后，根据属性信息从预设属性元模块中查找对应的属性元模块，即目标属性元模块。例如，用户输入“设备A”，电子设备确定属性元模块1为目标属性元模块。属性元模块属于每个静态资产的抽象。

S103，从预设服务元模型中确定每个目标属性元模块对应的目标服务元模型。

对于本申请实施例，服务元模型属于属性元模块处理逻辑的抽象，即静态资产对应的功能、动作以及状态等。例如，“设备A”对应有“启动”和“关闭”两种处理动作，“启动”对应服务元模型1，“关闭”对应服务元模型2，“物料A”对应有“进料”以及“出料”两种处理动作，“进料”对应服务元模型3，“出料”对应服务元模型4等。

用户建立目标属性元模块后，可调取预设服务元模型对应的集合，从预设服务元模型对应的集合中选择所需的服务元模型，即目标服务元模型。选择目标服务元模型，以使得目标属性元模块与目标服务元模型产生对应关系。例如，目标属性元模块为属性元模块1，目标服务元模型为服务元模型2，即，属性元模块1对应服务元模型2。

S104，建立每个目标服务元模型之间的关联关系，以得到至少两个属性信息对应的管理***。

对于本申请实施例，确定出每个目标属性元模块对应的目标服务元模型后，电子设备建立具有关联逻辑的目标服务元模型之间的关联关系，即其中一个服务元模型是否触发取决具有关联关系的服务元模型，确定出所有的服务元模型之间的关联关系后，从而得到属性信息对应的管理***。相较于根据需要编写代码搭建管理***，本申请根据开发需求从预设属性元模块选择对应的属性元模块，以及从预设服务元模型中选择对应的服务元模型，并且配置服务元模型之间的关联关系搭建管理***即可，相较于编写代码搭建管理***更加高效，开发周期更短。

本申请实施例的一种可能的实现方式，步骤S104中建立每个目标服务元模型之间的关联关系，具体包括步骤S1041（图中未示出）、步骤S1042（图中未示出）、步骤S1043（图中未示出）以及步骤S1044（图中未示出），其中，

S1041，从每个目标服务元模型中确定第一服务元模型以及第二服务元模型。

对于本申请实施例，确定出全部的目标服务元模型后，从全部的目标服务元模型中确定第一服务元模型以及第二服务元模型。第一服务元模型和第二服务元模型为需要建立对应关系的服务元模型，进而达到对属性元模块进行关联的效果。第一服务元模型和第二服务元模型为用户根据开发需要选择的服务元模型，例如，需要对“设备A”以及“设备B”进行关联，用户可以通过鼠标、键盘以及触控板等输入设备选定“设备A”对应的第一服务元模型以及“设备B”对应的第二服务元模型，电子设备检测到输入设备发送的选定信号，从而使得电子设备确定出第一服务元模型以及第二服务元模型。

S1042，从预设事件元模型中确定目标事件元模型。

对于本申请实施例，事件元模型用于监听服务元模型是否触发。例如，服务元模型1触发后，会将“服务元模型1已触发”的消息广播至整个管理***。事件元模型用于监听“服务元模型1已触发”的事件。电子设备确定出第一服务元模型以及第二服务元模型后，用户可通过预设事件元模型对应的集合中选择开发所需的事件元模型，即目标事件元模型。

S1043，建立第一服务元模型、第二服务元模型以及目标事件元模型的对应关系。

其中，目标事件元模型用于第二服务元模型监听第一服务元模型是否触发，当第一服务元模型触发时，触发事件元模型以使得第二服务元模型监听到第一服务元模型已触发。

对于本申请实施例，电子设备建立第一服务元模型、第二服务元模型以及目标事件元模型之间的对应关系。例如。第一服务元模型为目标属性信息1对应的服务元模型1，即“设备A”对应“启动”；第二服务元模型为目标属性元模块2对应的服务元模型2，即“设备B”对应“启动”。目标事件元模型监听服务元模型1是否触发，即“设备A已启动”，并告知服务元模型2，即“设备B”。服务元模型1触发后，“设备A已启动”的事件广播至整个管理***，目标事件元模型监听到服务元模型1已触发，从而通知服务元模型2，以使得“设备B”对应的服务元模型得知“设备A已启动”。

用户可通过鼠标、键盘以及触控板等输入设备进行建立第一服务元模型、第二服务元模型以及目标事件元模型对应关系的相关操作，电子设备检测到输入设备产生的操作指令后，从而确定第一服务元模型、第二服务元模型以及目标事件元模型的对应关系。

S1044，基于对应关系确定每个目标服务元模型之间的关联关系。

对于本申请实施例，电子设备确定出第一服务元模型、第二服务元模型以及目标事件元模型的对应关系后，对建立对应关系后的第一服务元模型和第二服务元模型进行配置，从而得到第一服务元模型以及第二服务元模型之间的关联关系，进而形成管理***。

本申请实施例的一种可能的实现方式，步骤S1044中基于对应关系确定每个目标服务元模型之间的关联关系，具体包括步骤S10441（图中未示出）以及步骤S10442（图中未示出），其中，

S10441，从预设订阅元模型中确定第二服务元模型对应的目标订阅元模型。

对于本申请实施例，电子设备确定出第一服务元模型、第二服务元模型以及目标事件元模型的对应关系后，需要确定第一服务元模型以及第二服务元模型之间影响触发的逻辑，订阅元模型是对触发条件的抽象，例如第一服务元模型触发时，第二服务元模型触发。

用户可通过调取预设订阅元模型对应的集合，从预设订阅元模型的集合中选择开发所需的订阅元模型，即目标订阅元模型。例如，订阅元模型1表征“当服务元模型1触发时，服务元模型2触发”，订阅元模型2表征“当服务元模型2触发时，将服务元模型3的状态由‘进料’改为‘出料’”。即，服务元模型的触发不需要人为控制，通过订阅元模型的关联条件进行自动控制。

S10442，建立目标事件元模型、第二服务元模型以及目标订阅元模型的关联关系。

其中，订阅元模型表征当目标事件元模型触发时，触发第二服务元模型。

对于本申请实施例，以步骤S1043为例，用户通过鼠标、键盘以及触控板等输入设备进行关联操作，电子设备检测到输入设备的操作指令后，确定目标事件元模型、第二服务元模型以及目标订阅元模型的关联关系。

例如，用户选择订阅元模型1，电子设备建立订阅元模型1、服务元模型2以及目标事件元模型之间的关联关系。即，目标事件元模型监听到“服务元模型1已触发”，目标事件元模型生成“服务元模型1已触发”的时间，并将该时间告知服务元模型2，服务元模型2收到该事件后，触发订阅元模型1，服务元模型2按照订阅元模型1触发，从而达到“当服务元模型1触发时，服务元模型2触发”的效果。对每个目标服务元模型进行关联关系的搭建，进而得到属性信息，即静态资产对应的管理***。

本申请实施例的一种可能的实现方式，方法还包括步骤S105（图中未示出）以及步骤S106（图中未示出），步骤S105可在步骤S103之后执行，其中，

S105，建立每个属性信息对应的操作链接。

对于本申请实施例，例如，工作人员可通过电子设备控制“设备A”的启动或关闭，电子设备根据用户输入的操作指令生成操作链接，电子设备与“设备A”通信连接，操作链接用于控制“设备A”的启动，操作链接可以是虚拟图形链接，也可以是文字链接，还可以是其他形式的连接。当触发操作链接时，电子设备控制“设备A”启动。

S106，确定操作链接与对应的目标服务元模型的对应关系。

对于本申请实施例，电子设备建立操作链接与“设备A”的服务元模型1的对应关系，即建立操作链接与服务元模型2的对应关系，从而便于在启动“设备A”时即可同时启动管理***，即，在初始启动“设备A”时与服务元模型1具有关联关系的服务元模型按照关联关系触发，更加方便。

在本申请实施例中，电子设备向员工派发任务，可通过触发用于表征上传任务工单的虚拟链接，然后将任务工单上传至电子设备中，说明任务工单已上传，将该虚拟链接关联表征传输任务工单的服务元模型，并且传输任务工单的服务元模型关联员工的属性元模块，从而将任务工单直接分发至员工处。

本申请实施例的一种可能的实现方式，方法还包括步骤S107（图中未示出）、步骤S108（图中未示出）以及步骤S109（图中未示出），步骤S107可在步骤S102之后执行，其中，

S107，若检测到确定目标属性元模块，则生成目标属性元模块对应的选择链接。

其中，选择链接包括目标属性元模块对应的至少一个预设服务元模型的选择链接。

对于本申请实施例，电子设备检测到用户确定目标属性元模块后，说明需要对该目标属性元模块配置服务元模型。用户可预先设置每个属性元模块对应的服务元模型的对应关系，因此在检测到用户确定目标属性元模块后生成该目标属性元模块对应的选择链接。假设该目标属性元模块为“设备A”，“设备A”对应三个服务元模型，分别为服务元模型1“启动”、服务元模型2“关闭”以及服务元模型3“自检”，电子设备生成每个服务元模型对应的选择链接，例如，“启动链接1”、“关闭链接2”以及“自检链接3”，以便于用户选择所需的服务元模型。

S108，控制显示选择链接。

对于本申请实施例，以步骤S107为例，电子设备检测到用户确定目标属性元模块后，在显示屏等显示装置上控制显示三个服务元模型对应的选择链接，从而便于用户选择所需的服务元模型。

S109，若检测到针对任一预设服务元模型对应的选择链接的选中指令，则确定目标属性元模块与任一预设服务元模型的对应关系。

对于本申请实施例，用户可通过鼠标、键盘以及触控板等输入设备选择所需的选择链接，电子设备根据输入设备发出的选中指令确定用户选定的选择链接，电子设备检测到选中指令后，从而确定目标属性元模块对应的服务元模型，以步骤S107为例，电子设备检测到用户选定服务元模型1“启动”，电子设备确定“设备A”与“启动”的对应关系。相较于从预设服务元模型中查找所需的服务元模型更方便快捷。

本申请实施例的一种可能的实现方式，当目标属性元模型对应至少两个预设服务元模型时，步骤S108中控制显示选择链接，具体包括步骤S1081、步骤S1082以及步骤S1083，其中，

S1081，获取每个预设服务元模型对应的使用次数。

对于本申请实施例，电子设备检测到用户选择服务元模型时，对该服务元模型对应的使用次数加一，服务元模型的使用次数可存储在电子设备本地的存储介质中，也可存储在云服务器中。以步骤S107为例，假设“设备A”对应的服务元模型1“启动”的使用次数为10次，服务元模型2“关闭”的使用次数为7次，服务元模型3“自检”的使用次数为3次。电子设备从本地存储介质或云服务器中获取上述三个服务元模型分别对应的使用次数。

S1082，基于使用次数对每个预设服务元模型进行由大到小排序。

对于本申请实施例，以步骤S1081为例，电子设备将获取到的三个服务元模型分别对应的使用次数由大到小进行排序。排序结果为服务元模型1＞服务元模型2＞服务元模型3。

S1083，基于排序结果控制显示选择链接。

对于本申请实施例，以步骤S1082为例，使用次数越多，说明“设备A”经常配置服务元模型1，在当前配置“设备A”对应的服务元模型时，仍配置服务元模型1的可能性较大，因此，电子设备根据使用次数优先显示使用次数多的服务元模型。例如在显示屏上由上到下依次显示服务元模型1、服务元模型2以及服务元模型3，从而便于用户更直观快捷的配置“设备A”。电子设备还可将服务元模型1与其它服务元模型区别开，例如对使用次数最多的服务元模型1对应的图标进行加粗或放大处理，从而使得用户选择服务元模型1更加方便。

本申请实施例的一种可能的实现方式，方法还包括步骤S110（图中未示出）、步骤S111（图中未示出）以及步骤S112（图中未示出），步骤S110可在步骤S103之后执行，其中，

S110，若检测到针对任一目标服务元模型的选中指令，则获取任一目标服务元模型的历史关联信息。

其中，历史关联信息包括任一目标服务元模型在历史中具有关联关系的属性元模块以及对应的服务元模型。

对于本申请实施例，以设备A的“启动”服务元模型为例，电子设备检测到针对该服务元模型的选中指令，说明用户选中该服务元模型，进而对该服务元模型进行关联事件元模型等操作。电子设备获取该“启动”服务元模型的历史关联信息，从而便于得知“启动”服务元模型曾经建立过的对应关系的服务元模型以及服务元模型对应的属性元模块。

S111，基于历史关联信息判断当前已确定的目标服务元模型中是否存在待选目标服务元模型。

其中，待选目标服务元模型为满足历史关联信息的目标服务元模型。

对于本申请实施例，假设此时已建立“设备A”的属性元模块以及“设备A”的“启动”服务元模型，并且已建立“设备B”的属性元模块以及“设备B”的“启动”服务元模型、“设备C”的属性元模块以及“设备C”的“启动”服务元模型、“设备D”的属性元模块以及“设备D”的“启动”服务元模型。电子设备从历史关联信息中查找设备A“启动”服务元模型建立过对应关系的目标属性元模块以及对应的服务元模型。

S112，若存在，则确定目标服务元模型与待选目标服务元模型的关联关系。

对于本申请实施例，以步骤S111为例，假设历史关联信息中存在设备A“启动”的服务元模型对应“设备C”的属性元模块以及“设备C”的“启动”的服务元模型，即待选目标服务元模型，则说明“设备A”与“设备C”存在过关联。而此时搭建管理***，同样可能需要建立“设备A”与“设备C”的关联关系。因此在确定出存在待选目标服务元模型后，直接确定设备A“启动”服务元模型与设备C“启动”服务元模型的关联关系。而“设备B”的属性元模块对应的“启动”服务元模型以及“设备D”的属性元模型对应的“启动”服务元模型，均未在“设备A”的历史关联信息中出现，即“设备B”和“设备D”的服务元模型都为“启动”，但不满足历史关联信息，因此无法确定“设备A”的“启动”服务元模型与“设备B”的“启动”服务元模型的对应关系，也无法确定“设备A”的“启动”服务元模型与“设备D”的“启动”服务元模型的对应关系。

在本申请实施例中，若存在待选目标服务元模型，还可输出提示信息，其中，提示信息可以是电子设备控制显示屏装置显示的“发现待选目标服务元模型，是否建立关联”的文字信息，从而提示用户目标服务元模型可与待选目标服务元模型关联，用户可根据提示信息选择是否将目标服务元模型与待选目标服务元模型进行关联。

上述实施例从方法流程的角度介绍一种基于元模型的管理***搭建方法，下述实施例从虚拟模块或者虚拟单元的角度介绍了一种基于元模型的管理***搭建装置，具体详见下述实施例。

本申请实施例提供一种基于元模型的管理***搭建装置20，如图2所示，该基于元模型的管理***搭建装置20具体可以包括：

第一获取模块201，用于获取用户输入的至少两个属性信息，属性信息表征企业的静态资产；

第一确定模块202，用于从预设属性元模块中确定与各个属性信息各自对应的目标属性元模块；

第二确定模块203，用于从预设服务元模型中确定每个目标属性元模块对应的目标服务元模型，服务元模型表征每个目标属性元模块对应的操作行为；

建立模块204，用于建立每个目标服务元模型之间的关联关系，以得到至少两个属性信息对应的管理***。

本申请实施例提供的一种基于元模型的管理***搭建装置20，其中，第一获取模块201用于获取用户输入的至少两个属性信息，并且第一确定模块202从预设属性元模块中确定与属性信息对应的目标属性元模块。目标属性元模块为用户需要进行管理的静态资产的抽象，第二确定模块203从预设服务元模型中确定与目标属性元模块对应的目标服务元模型，目标服务元模型为对应的目标属性元模块的相关操作，建立模块204建立每个目标服务元模型之间的关联关系，从而得到目标属性元模块之间的关联逻辑，进而得到至少两个属性信息对应的管理***，根据开发需求从预设属性元模块中确定目标属性元模块、从预设服务元模型中确定目标服务元模型以及建立目标服务元模型之间的关系，从而搭建出所需的管理***，相较于编写代码效率更高。

本申请实施例的一种可能的实现方式，建立模块204在建立每个目标服务元模型之间的关联关系时，具体用于：

从每个目标服务元模型中确定第一服务元模型以及第二服务元模型；

从预设事件元模型中确定目标事件元模型；

建立第一服务元模型、第二服务元模型以及目标事件元模型的对应关系，目标事件元模型用于第二服务元模型监听第一服务元模型是否触发，当第一服务元模型触发时，触发事件元模型以使得第二服务元模型监听到第一服务元模型已触发；

基于对应关系确定每个目标服务元模型之间的关联关系。

本申请实施例的一种可能的实现方式，建立模块204在基于对应关系确定每个目标服务元模型之间的关联关系时，具体用于：

从预设订阅元模型中确定第二服务元模型对应的目标订阅元模型；

建立目标事件元模型、第二服务元模型以及目标订阅元模型的关联关系，订阅元模型表征当目标事件元模型触发时，触发第二服务元模型。

本申请实施例的一种可能的实现方式，装置20还包括：

链接建立模块，用于建立每个属性信息对应的操作链接；

第三确定模块，用于确定操作链接与对应的目标服务元模型的对应关系。

本申请实施例的一种可能的实现方式，装置20还包括：

生成模块，用于当检测到确定目标属性元模块时，生成目标属性元模块对应的选择链接，选择链接包括目标属性元模块对应的至少一个预设服务元模型的选择链接；

控制显示模块，用于控制显示选择链接；

第四确定模块，用于当检测到针对任一预设服务元模型对应的选择链接的选中指令时，确定目标属性元模块与任一预设服务元模型的对应关系。

本申请实施例的一种可能的实现方式，当目标属性元模型对应至少两个预设服务元模型时，控制显示模块在控制显示选择链接时，具体用于：

获取每个预设服务元模型对应的使用次数；

基于使用次数对每个预设服务元模型进行由大到小排序；

基于排序结果控制显示选择链接。

本申请实施例的一种可能的实现方式，装置20还包括：

第二获取模块，用于当检测到针对目标服务元模型的选中指令时，获取目标服务元模型的历史关联信息，历史关联信息包括目标服务元模型在历史中具有关联关系的属性元模块以及对应的服务元模型；

第五确定模块，用于基于历史关联信息判断当前已确定的目标服务元模型中是否存在待选目标服务元模型，待选目标服务元模型为满足历史关联信息的目标服务元模型；

第六确定模块，用于在存在时，确定目标服务元模型与待选目标服务元模型的关联关系。

在本申请实施例中，第一获取模块201以及第二获取模块可以是相同的获取模块，也可以是不同的获取模块。第一确定模块201、第二确定模块202、第三确定模块、第四确定模块、第五确定模块以及第六确定模块可以是相同的确定模块，也可以是不同的确定模块，还可以是部分相同的确定模块。

所属领域的技术人员可以清楚地了解到，为描述的方便和简洁，上述描述的一种基于元模型的管理***搭建装置20的具体工作过程，可以参考前述方法实施例中的对应过程，在此不再赘述。

本申请实施例中提供了一种电子设备，如图3所示，图3所示的电子设备30包括：处理器301和存储器303。其中，处理器301和存储器303相连，如通过总线302相连。可选地，电子设备30还可以包括收发器304。需要说明的是，实际应用中收发器304不限于一个，该电子设备30的结构并不构成对本申请实施例的限定。

处理器301可以是CPU（Central Processing Unit，中央处理器），通用处理器，DSP（Digital Signal Processor，数据信号处理器），ASIC（Application SpecificIntegrated Circuit，专用集成电路），FPGA（Field Programmable Gate Array，现场可编程门阵列）或者其他可编程逻辑器件、晶体管逻辑器件、硬件部件或者其任意组合。其可以实现或执行结合本申请公开内容所描述的各种示例性的逻辑方框，模块和电路。处理器301也可以是实现计算功能的组合，例如包含一个或多个微处理器组合，DSP和微处理器的组合等。

总线302可包括一通路，在上述组件之间传送信息。总线302可以是PCI（Peripheral Component Interconnect，外设部件互连标准）总线或EISA（ExtendedIndustry Standard Architecture，扩展工业标准结构）总线等。总线302可以分为地址总线、数据总线、控制总线等。为便于表示，图3中仅用一条粗线表示，但并不表示仅有一根总线或一型的总线。

存储器303可以是ROM（Read Only Memory，只读存储器）或可存储静态信息和指令的其他类型的静态存储设备，RAM（Random Access Memory，随机存取存储器）或者可存储信息和指令的其他类型的动态存储设备，也可以是EEPROM（Electrically ErasableProgrammable Read Only Memory，电可擦可编程只读存储器）、CD-ROM（Compact DiscRead Only Memory，只读光盘）或其他光盘存储、光碟存储（包括压缩光碟、激光碟、光碟、数字通用光碟、蓝光光碟等）、磁盘存储介质或者其他磁存储设备、或者能够用于携带或存储具有指令或数据结构形式的期望的程序代码并能够由计算机存取的任何其他介质，但不限于此。

存储器303用于存储执行本申请方案的应用程序代码，并由处理器301来控制执行。处理器301用于执行存储器303中存储的应用程序代码，以实现前述方法实施例所示的内容。

其中，电子设备包括但不限于：移动电话、笔记本电脑、数字广播接收器、PDA（个人数字助理）、PAD（平板电脑）、PMP（便携式多媒体播放器）、车载终端（例如车载导航终端）等等的移动终端以及诸如数字TV、台式计算机等等的固定终端。还可以为服务器等。图3示出的电子设备仅仅是一个示例，不应对本申请实施例的功能和使用范围带来任何限制。

本申请实施例提供了一种计算机可读存储介质，该计算机可读存储介质上存储有计算机程序，当其在计算机上运行时，使得计算机可以执行前述方法实施例中相应内容。与相关技术相比，本申请实施例中获取用户输入的至少两个属性信息，并且从预设属性元模块中确定与属性信息对应的目标属性元模块。目标属性元模块为用户需要进行管理的静态资产的抽象，从预设服务元模型中确定与目标属性元模块对应的目标服务元模型，目标服务元模型为对应的目标属性元模块的相关操作，建立每个目标服务元模型之间的关联关系，从而得到目标属性元模块之间的关联逻辑，进而得到至少两个属性信息对应的管理***，根据开发需求从预设属性元模块中确定目标属性元模块、从预设服务元模型中确定目标服务元模型以及建立目标服务元模型之间的关系，从而搭建出所需的管理***，相较于编写代码效率更高。

应该理解的是，虽然附图的流程图中的各个步骤按照箭头的指示依次显示，但是这些步骤并不是必然按照箭头指示的顺序依次执行。除非本文中有明确的说明，这些步骤的执行并没有严格的顺序限制，其可以以其他的顺序执行。而且，附图的流程图中的至少一部分步骤可以包括多个子步骤或者多个阶段，这些子步骤或者阶段并不必然是在同一时刻执行完成，而是可以在不同的时刻执行，其执行顺序也不必然是依次进行，而是可以与其他步骤或者其他步骤的子步骤或者阶段的至少一部分轮流或者交替地执行。

以上所述仅是本申请的部分实施方式，应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以做出若干改进和润饰，这些改进和润饰也应视为本申请的保护范围。

Claims (10)

1.一种基于元模型的管理***搭建方法，其特征在于，包括：

获取用户输入的至少两个属性信息，所述属性信息表征企业的静态资产；

从预设属性元模块中确定与各个属性信息各自对应的目标属性元模块；

从预设服务元模型中确定每个目标属性元模块对应的目标服务元模型，所述服务元模型表征每个目标属性元模块对应的操作行为；

建立每个目标服务元模型之间的关联关系，以得到所述至少两个属性信息对应的管理***。

2.根据权利要求1所述的一种基于元模型的管理***搭建方法，其特征在于，所述建立每个目标服务元模型之间的关联关系，包括：

从所述每个目标服务元模型中确定第一服务元模型以及第二服务元模型；

从预设事件元模型中确定目标事件元模型；

建立所述第一服务元模型、第二服务元模型以及目标事件元模型的对应关系，所述目标事件元模型用于所述第二服务元模型监听所述第一服务元模型是否触发，当所述第一服务元模型触发时，触发事件元模型以使得第二服务元模型监听到所述第一服务元模型已触发；

基于所述对应关系确定所述每个目标服务元模型之间的关联关系。

3.根据权利要求2所述的一种基于元模型的管理***搭建方法，其特征在于，所述基于所述对应关系确定所述每个目标服务元模型之间的关联关系，包括：

从预设订阅元模型中确定所述第二服务元模型对应的目标订阅元模型；

建立所述目标事件元模型、第二服务元模型以及目标订阅元模型的关联关系，所述订阅元模型表征当所述目标事件元模型触发时，触发所述第二服务元模型。

4.根据权利要求1所述的一种基于元模型的管理***搭建方法，其特征在于，所述方法还包括：

建立每个属性信息对应的操作链接；

确定所述操作链接与对应的目标服务元模型的对应关系。

5.根据权利要求1所述的一种基于元模型的管理***搭建方法，其特征在于，所述方法还包括：

若检测到确定目标属性元模块，则生成所述目标属性元模块对应的选择链接，所述选择链接包括所述目标属性元模块对应的至少一个预设服务元模型的选择链接；

控制显示所述选择链接；

若检测到针对任一预设服务元模型对应的选择链接的选中指令，则确定所述目标属性元模块与所述任一预设服务元模型的对应关系。

6.根据权利要求5所述的一种基于元模型的管理***搭建方法，其特征在于，当所述目标属性元模型对应至少两个预设服务元模型时，所述控制显示所述选择链接，包括：

获取每个预设服务元模型对应的使用次数；

基于所述使用次数对所述每个预设服务元模型进行由大到小排序；

基于所述排序结果控制显示所述选择链接。

7.根据权利要求1所述的一种基于元模型的管理***搭建方法，其特征在于，所述方法还包括：

若检测到针对目标服务元模型的选中指令，则获取所述目标服务元模型的历史关联信息，所述历史关联信息包括所述目标服务元模型在历史中具有关联关系的属性元模块以及对应的服务元模型；

基于所述历史关联信息判断当前已确定的目标服务元模型中是否存在待选目标服务元模型，所述待选目标服务元模型为满足历史关联信息的目标服务元模型；

若存在，则确定所述目标服务元模型与所述待选目标服务元模型的关联关系。

8.一种基于元模型的管理***搭建装置，其特征在于，包括：

第一获取模块，用于获取用户输入的至少两个属性信息，所述属性信息表征企业的静态资产；

第一确定模块，用于从预设属性元模块中确定与各个属性信息各自对应的目标属性元模块；

第二确定模块，用于从预设服务元模型中确定每个目标属性元模块对应的目标服务元模型，所述服务元模型表征每个目标属性元模块对应的操作行为；

建立模块，用于建立每个目标服务元模型之间的关联关系，以得到所述至少两个属性信息对应的管理***。

9.一种电子设备，其特征在于，其包括：

一个或者多个处理器；

存储器；

一个或多个应用程序，其中所述一个或多个应用程序被存储在所述存储器中并被配置为由所述一个或多个处理器执行，所述一个或多个应用程序配置用于：执行根据权利要求1～7任一项所述一种基于元模型的管理***搭建方法。

10.一种计算机可读存储介质，其上存储有计算机程序，其特征在于，当所述计算机程序在计算机中执行时，令所述计算机执行权利要求1～7任一项所述的一种基于元模型的管理***搭建方法。

Images