CN110648081A - 用于计算系统的业务建模方法、装置和计算机系统 - Google Patents

Abstract

本公开提供了一种用于计算系统的业务建模方法，包括：在元模型数据库中管理一个或多个模型类别的元模型；接收来自客户端的第一建模申请数据，所述第一建模申请数据包括第一模型类别；从所述元模型数据库获取针对所述第一模型类别的第一元模型，并将所述第一元模型发送至所述客户端；接收来自所述客户端关于所述第一元模型的业务配置信息，所述业务配置信息包括对象配置信息和关系配置信息；以及基于所述第一元模型和所述业务配置信息，在业务模型数据库中构建属于所述第一模型类别的业务模型。本公开还提供了一种用于计算系统的业务建模装置和计算机系统。

Description

用于计算系统的业务建模方法、装置和计算机系统

技术领域

本公开涉及计算机技术领域，更具体地，涉及一种用于计算系统的业务建模方法、装置和计算机系统。

背景技术

当前，国内外银行业在金融产品和技术创新的竞争日趋激烈，为加强客户服务、多元化业务经营、优化收入结构、持续创新、以及加强风险管理，对银行业务架构和IT架构构建提出更高的要求。由于银行系统复杂而庞大，为适应系统内外部运行环境的需要，现有传统的系统解决方案仅仅是依靠系统升级改造、增加系统资源，优化改进项目驱动模式等方法。传统业务建模方法先分析业务需求流程变化，再分析应用架构影响以及数据结构支持，最后评估对IT基础设施的变化，是一个迭代与渐进的过程。这种处理方式，由于缺乏完备的技术架构平台，导致无法有效继承原系统模型资产。

针对上述存在问题，迫切需要一种在现有模型资产的基础上进行业务建模的方法，来提高银行业务系统的继承性和稳定性。

发明内容

本公开的一个方面提供了一种用于计算系统的业务建模方法，包括：在元模型数据库中管理一个或多个模型类别的元模型。接收来自客户端的第一建模申请数据，第一建模申请数据包括第一模型类别；然后从元模型数据库获取针对第一模型类别的第一元模型，并将第一元模型发送至客户端。接着接收来自客户端关于第一元模型的业务配置信息，业务配置信息包括对象配置信息和关系配置信息。最后基于第一元模型和业务配置信息，在业务模型数据库中构建属于第一模型类别的业务模型。

可选地，上述一个或多个模型类别包括如下至少一项：业务流程模型类别、主辅应用模型类别、数据流模型类别、应用节点模型类别、逻辑数据模型类别、以及物理部署模型类别。

可选地，上述在元模型数据库中管理一个或多个模型类别的元模型包括：接收来自客户端的第二建模申请数据。其中，所述第二建模申请数据包括第一模型类别和元模型建模信息，元模型建模信息包括一个或多个元素信息以及元素之间的关系信息。然后，基于元模型建模信息构建针对第一模型类别的第一元模型。接着，将第一元模型存入元模型数据库。

可选地，上述方法还包括：接收来自客户端的模型查询请求，模型查询请求包括第二模型类别。然后，从业务模型数据库中获取针对第二模型类别的业务模型。接着，将针对第二模型类别的业务模型发送至客户端，以便客户端对针对第二模型类别的业务模型进行展示。

可选地，上述在元模型数据库中管理一个或多个模型类别的元模型包括：接收来自客户端的修改申请数据，修改申请数据包括针对第三模型类型的修改信息。然后，从所述元模型数据库中获取针对所述第三模型类型的第三元模型。接着，基于所述修改信息，对第三元模型进行修改，得到修改后的第三元模型。并且，基于修改后的第三元模型，对业务模型数据库中属于第三模型类型的一个或多个业务模型进行修改。

可选地，上述方法还包括：将属于第一模型类别的业务模型发送至客户端，以便客户端对属于第一模型类别的业务模型进行展示。

可选地，上述将属于第一模型类别的业务模型发送至客户端包括：将针对该业务模型的流程图发送至客户端。

可选地，上述将属于第一模型类别的业务模型发送至客户端还包括：接收来自客户端的输入参数。然后基于该输入参数运行上述业务模型，得到运行结果。接着，将运行结果发送至客户端。

本公开的另一方面提供了一种用于计算系统的业务建模装置，包括：管理模块、第一接收模块、元模型获取模块、第二接收模块和建模模块。管理模块用于在元模型数据库中管理一个或多个模型类别的元模型。第一接收模块用于接收来自客户端的第一建模申请数据，第一建模申请数据包括第一模型类别。元模型获取模块用于从元模型数据库获取针对第一模型类别的第一元模型，并将第一元模型发送至客户端。第二接收模块用于接收来自客户端关于第一元模型的业务配置信息，业务配置信息包括对象配置信息和关系配置信息。建模模块用于基于第一元模型和业务配置信息，在业务模型数据库中构建属于第一模型类别的业务模型。

本公开的另一方面提供了一种计算机系统，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机可读存储介质，存储有计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

本公开的另一方面提供了一种计算机程序，所述计算机程序包括计算机可执行指令，所述指令在被执行时用于实现如上所述的方法。

根据本公开的实施例，在元模型数据库中集中统一管理一个或多个模型类别的元模型，并在业务模型数据库中集中统一管理一个或多个模型类别的业务模型，实现了模型资产的统一结构化管理。在业务建模时以相应模型类别的元模型作为建模基础进行配置和构建，避免用户从零开始建模。并且上述过程可以不断增加模型资产的数量和种类，使得用户基于这些模型资产获知计算系统的技术架构、数据架构、应用架构、业务架构等的相关动态。

附图说明

为了更完整地理解本公开及其优势，现在将参考结合附图的以下描述，其中：

图1示意性示出了根据本公开实施例的应用业务建模方法和装置的示例性系统架构；

图2示意性示出了根据本公开实施例的用于计算系统的业务建模方法的流程图；

图3示意性示出了根据本公开实施例的计算系统的示例结构图；

图4示意性示出了根据本公开实施例的图3所示的模型数据存储模块310的示例结构图；

图5示意性示出了根据本公开实施例的构建各种模型类别的元模型的示例示意图；

图6示意性示出了根据本公开实施例的图3所示的模型数据处理模块320的示例结构图；

图7示意性示出了根据本公开实施例的用于计算系统的业务建模装置的框图；以及

图8示意性示出了根据本公开实施例的计算机系统的框图。

具体实施方式

以下，将参照附图来描述本公开的实施例。但是应该理解，这些描述只是示例性的，而并非要限制本公开的范围。在下面的详细描述中，为便于解释，阐述了许多具体的细节以提供对本公开实施例的全面理解。然而，明显地，一个或多个实施例在没有这些具体细节的情况下也可以被实施。此外，在以下说明中，省略了对公知结构和技术的描述，以避免不必要地混淆本公开的概念。

在此使用的术语仅仅是为了描述具体实施例，而并非意在限制本公开。在此使用的术语“包括”、“包含”等表明了所述特征、步骤、操作和/或部件的存在，但是并不排除存在或添加一个或多个其他特征、步骤、操作或部件。

在此使用的所有术语(包括技术和科学术语)具有本领域技术人员通常所理解的含义，除非另外定义。应注意，这里使用的术语应解释为具有与本说明书的上下文相一致的含义，而不应以理想化或过于刻板的方式来解释。

在使用类似于“A、B和C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B和C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。在使用类似于“A、B或C等中至少一个”这样的表述的情况下，一般来说应该按照本领域技术人员通常理解该表述的含义来予以解释(例如，“具有A、B或C中至少一个的系统”应包括但不限于单独具有A、单独具有B、单独具有C、具有A和B、具有A和C、具有B和C、和/或具有A、B、C的系统等)。

本公开的实施例提供了一种用于计算系统的业务建模方法、装置以及计算机系统。该方法可以包括管理过程、第一接收过程、元模型获取过程、第二接收过程以及建模过程。在管理过程，在元模型数据库中管理一个或多个模型类别的元模型以支持后续元模型获取过程。在第一接收过程，接收来自客户端的第一建模申请数据，第一建模申请数据包括第一模型类别。然后进行元模型获取过程，从元模型数据库获取针对第一模型类别的第一元模型，并将第一元模型发送至客户端。响应于客户端针对该第一元模型的操作，进行第二接收过程。接收来自客户端关于第一元模型的业务配置信息，业务配置信息包括对象配置信息和关系配置信息。最后进行建模过程，基于第一元模型和业务配置信息，在业务模型数据库中构建属于第一模型类别的业务模型。

图1示意性示出了根据本公开实施例的可以应用业务建模方法和装置的示例性系统架构100。需要注意的是，图1所示仅为可以应用本公开实施例的系统架构的示例，以帮助本领域技术人员理解本公开的技术内容，但并不意味着本公开实施例不可以用于其他设备、系统、环境或场景。

如图1所示，根据该实施例的系统架构100可以包括终端设备101、102、103，网络104和服务器/服务器集群105。网络104用以在终端设备101、102、103和服务器/服务器集群105之间提供通信链路的介质。网络104可以包括各种连接类型，例如有线、无线通信链路或者光纤电缆等等。

终端设备101、102、103上可以安装有各种客户端应用，例如业务建模工具(仅为示例)。终端设备101、102、103可以通过各种客户端应用与服务器/服务器集群105进行交互，以向服务器/服务器集群105发送各种请求或接收服务器/服务器集群105返回的结果。

终端设备101、102、103可以是各种电子设备，包括但不限于智能手机、平板电脑、膝上型便携计算机和台式计算机等等。

服务器服务器/服务器集群105是可以提供各种服务支持的后台管理服务器或服务器集群(仅为示例)。后台管理服务器可以对接收到的用户请求等数据进行分析等处理，并将处理结果(例如根据用户请求获取或生成的网页、信息、或数据等)反馈给终端设备。

需要说明的是，本公开实施例所提供的业务建模方法一般可以由服务器/服务器集群105执行。相应地，本公开实施例所提供的业务建模装置一般可以设置于服务器/服务器集群105中。本公开实施例所提供的业务建模方法也可以由不同于服务器/服务器集群105且能够与终端设备101、102、103和/或服务器/服务器集群105通信的服务器或服务器集群执行。相应地，本公开实施例所提供的业务建模装置也可以设置于不同于服务器/服务器集群105且能够与终端设备101、102、103和/或服务器/服务器集群105通信的服务器或服务器集群中。

应该理解，图1中的终端设备、网络和服务器/服务器集群的数目仅仅是示意性的。根据实际需要，可以具有任意数目的终端设备、网络和服务器/服务器集群。

本公开实施例提供了一种用于计算系统的业务建模方法，通过对各种模型类别的元模型以及业务模型的管理实现了计算系统对于业务模型资源的统一结构化管理。下面对该方法的实施过程进行说明，应注意，以下方法中各个操作的序号仅作为该操作的表示以便描述，而不应被看作表示该各个操作的执行顺序。除非明确指出，否则该方法不需要完全按照所示顺序来执行。

图2示意性示出了根据本公开实施例的用于计算系统的业务建模方法的流程图，该方法可以应用于计算系统的服务器或服务器集群。

如图2所示，该方法可以包括以下操作S201～S205。

在操作S201，在元模型数据库中管理一个或多个模型类别的元模型。

其中，属于不同模型类别的模型(model)用于描述计算系统的不同方面的特征，展现针对计算系统的不同关注点。模型类别可以根据计算系统实际情况进行划分。例如，针对计算系统的软件领域，可以划分出如下至少一个模型类别：类模型、功能模型、通信模型、部署模型、对象模型等等。对象模型关注计算系统内部对象之间的关系，通信模型关注计算系统分布组件之间的通信关系，功能模型关注计算系统功能模块之间的关系等。每个模型类别对应于一个元模型(MetaModel)。针对一个模型类别的元模型定义了该模型类别的规范，例如定义了组成模型的元素和元素之间的关系。本操作S201在元模型数据库中集中统一管理一个或多个模型类别的元模型，以支持后续模型创建过程。

然后，在操作S202，接收来自客户端的第一建模申请数据。

其中，在用户希望构建一个业务模型时，可以通过客户端向服务器发送第一建模申请数据。该第一建模申请数据可以包含用户所希望构建的业务模型所属的模型类别，如第一模型类别，以便后续基于相应模型类别的元模型进行建模。其中，本文中的“用户”可以是计算系统的运维人员。

接着，在操作S203，从元模型数据库获取针对第一模型类别的第一元模型，并将第一元模型发送至客户端。

上文已经说明，针对第一模型类别的第一元模型定义了该第一模型类别的规范，包含最基本的元素信息和元素之间的关系信息。将该第一元模型发送至客户端，由客户端向用户进行展示，即向用户展示该第一模型类别的基础模型结构。在此基础上，用户可以在该基础模型结构上根据其所希望构建的业务模型的业务需求进行配置，例如可以通过填写配置信息、拖拽等方式进行元素的定义、对象的定义、应用的定义、关系的定义等等，上述配置过程对应生成业务配置信息。

接着，在操作S204，接收来自客户端关于第一元模型的业务配置信息。

其中，业务配置信息可以包括对象配置信息和关系配置信息。

最后，在操作S205，基于第一元模型和业务配置信息，在业务模型数据库中构建属于第一模型类别的业务模型。

其中，每个模型类别可对应一个或多个业务模型。每次建模得到的业务模型均存入业务模型数据库中。在业务模型数据库中，可以按照模型类别分类对业务模型进行存储。

本领域技术人员可以理解，图2所示的方法在元模型数据库中集中统一管理一个或多个模型类别的元模型，并在业务模型数据库中集中统一管理一个或多个模型类别的业务模型，实现了模型资产的统一结构化管理。在业务建模时以相应模型类别的元模型作为建模基础进行配置和构建，避免用户从零开始建模。并且上述过程可以不断增加模型资产的数量和种类，使得用户基于这些模型资产获知计算系统的技术架构、数据架构、应用架构、业务架构等的相关动态。

根据本公开的实施例，元模型数据库中的元模型可以是从其他设备获取的，也可以是创建生成的。在用户希望构建一个针对新的模型类别的元模型时，可以通过客户端向服务器发送第二建模申请数据。示例性地，以构建针对第一模型类别的元模型为例，上述在元模型数据库中管理一个或多个模型类别的元模型可以包括：接收来自客户端的第二建模申请数据。其中，第二建模申请数据可以包括第一模型类别和元模型建模信息，元模型建模信息包括一个或多个元素信息以及元素之间的关系信息。然后，基于元模型建模信息构建针对第一模型类别的第一元模型。接着，将第一元模型存入元模型数据库。元模型数据库中针对其他模型类别的元模型的构建过程与上述构建第一元模型的过程原理相同，在此不再赘述。可以理解，随着元模型构建过程的进行，元模型数据库中的元模型的数量及其所针对的模型类别不断增加，能够促进业务模型构建过程的优化。

由于在业务模型数据库中对业务模型进行统一管理，根据本公开实施例的业务建模方法也可以支持针对业务模型的查询。示例性地，在用户希望查询一个业务模型时，可以通过客户端向服务器发送模型查询请求。服务器接收来自客户端的模型查询请求，模型查询请求包括用户所希望查询的业务模型所述的模型类别，如第二模型类别。服务器从业务模型数据库中获取属于第二模型类别的业务模型，并将获取到的业务模型发送至客户端，以便客户端对该业务模型进行展示。

进一步地，由于在元模型数据库中对元模型进行统一管理，根据本公开实施例的业务建模方法也可以支持针对元模型的修改，并依据元模型与业务模型之间的继承关系，实现通过对一个元模型的修改即可完成对同一模型类别下的多个业务模型的统一修改。示例性地，在用户希望对计算系统中已有的一个模型类别的所有业务模型进行修改时，可以通过客户端向服务器发送修改申请数据。上述在元模型数据库中管理一个或多个模型类别的元模型还可以包括：接收来自客户端的修改申请数据，该修改申请数据可以包括针对第三模型类型的修改信息。然后，从元模型数据库中获取针对第三模型类型的第三元模型。接着，基于所述修改信息，对所述第三元模型进行修改，得到修改后的第三元模型。并且，基于修改后的第三元模型，对业务模型数据库中属于第三模型类型的一个或多个业务模型进行修改。

进一步地，根据本公开实施例的业务建模方法还可以包括：将所述属于第一模型类别的业务模型发送至客户端，以便客户端对属于第一模型类别的业务模型进行展示。示例性地，可以生成针对该业务模型的流程图，在客户端展示该流程图，以使用户直观地获知该业务模型的逻辑。在此基础上，在向用户展示该业务模型后，还可以接收用户通过客户端填写的输入参数。基于所述输入参数运行业务模型，得到运行结果并将该运行结果发送至客户端。

下面参考图3～图6，对根据本公开实施例的用于计算系统的业务建模方法进行示例性说明。

图3示意性示出了根据本公开实施例的计算系统的示例结构图。

如图3所示，例如计算系统可以为银行系统架构的计算系统，上述用于计算系统的业务建模方法可以为针对银行业务的业务建模方法。计算系统300可以包括：模型数据存储模块310、模型数据处理模块320、金融传输网络330、系统构建终端340。其中，模型数据存储模块310和模型数据处理模块320部署于上文所述的服务器或服务器集群，系统构建终端340可作为上文所述的客户端。

模型数据处理模块320用于针对模型建模申请做出响应，进行建模数据加工与处理，完成模型建模申请、基础模型数据调阅、建模后数据的组装与处理过程等。金融传输网络330是银行内部网络，系统构建终端340通过金融传输网络330连接模型数据处理模块320。系统构建终端340是支持各类模型展现的C/S类型终端。

模型数据存储模块310用于存储基础架构模型数据以及各类系统架构模型数据，可以是一个数据库管理系统，也可以是一个文件系统。例如模型数据存储模块310可以包括上文所述的元模型数据库和业务模型数据库。模型数据存储模块310以元模型为核心，可以按照模型类别划分存储单元。例如，模型类别可以包括如下至少一项：业务流程模型、主辅应用模型、数据流模型、应用节点模型、逻辑数据模型、以及物理部署模型。模型数据存储模块310的存储单元划分如图4所示。

图4示意性示出了根据本公开实施例的图3所示的模型数据存储模块310的示例结构图。

如图4所示，模型数据存储模块310可以包括业务流程模型存储单元311、主辅应用模型存储单元312、数据流模型存储单元313、应用节点模型存储单元314、逻辑数据模型存储单元315、物理部署模型存储单元316、以及元数据存储单元317。

示例性地，本公开在Eclipse开源项目的模型框架EMF(Eclipse ModelingFramework)的基础上，新增了XCore元模型，可以将该XCore元模型存入元数据存储单元317。该元模型实现各模型类别的基础模型的存储定义，主要可分成两个部分：(1)模型结构(数据结构)，又称为抽象语法；(2)展现样式和行为定义的描述，称为具象语法。

例如抽象语法主要有以下几个元素组成：

1、XPackage：包的概念，主要用于控制管理一组模型的结构，以及模型结构的实例化，实例化的结果就是XObject。本身具有一些包名称的定义，以及一些描述信息的定义。

2、XClass：一个模型结构的定义，主要包含属性信息(XAttribute)和引用信息(XReference)，以及继承的父级XClass。本身具有结构名称定义，以及一些描述信息的定义。

3、XAttribute：属性信息定义，定于属性的名称，属性的类型，以及一些相关描述信息。

4、XReference：引用信息的定义，定义模型之间的引用关系。定义引用的XClass，定义单引用还是多引用，以及一些相关描述信息。

5、XObject：通过XPackage去实例化模型结构(XClass)的结果就是XObject。提供对于这种模型结构的数据存储。

例如具象语法对应模型的样式、行为的定义可以包括：边框样式定义、线条图案、线条粗细、线条颜色、文本样式定义等等，在此不再赘述。

在XCore元模型的基础上，元数据存储单元317还可以包括元模型设计器3171、模型编辑器3172和资源管理器3173，用来完成各种模型类别的基础模型的定制、编辑和解析。其连接关系如图5所示。

图5示意性示出了根据本公开实施例的构建各种模型类别的元模型的示例示意图。

如图5所示，示例性地，元模型设计器3171用于实现业务流程模型、主辅应用模型、数据流模型、应用节点模型、逻辑数据模型、物理部署模型等各种不同的基础模型的定制，这些基础模型可以看作是各种模型类别的元模型。模型编辑器3172通过从元模型设计器3171下载各种模型类别的元模型，在元模型的指导和约束下实现各架构领域相关业务模型的建模设计，将模型文件中每个对象、关系、字段的坐标位置、颜色、线条粗细等信息保存为XML文本文件。资源管理器3173负责资源和版本管理，为元模型设计器3171和模型编辑器3172提供支撑，解析XML文本文件，分析并提取出其中每个对象、关系、字段的坐标位置、颜色、线条粗细等展现相关的信息，再将这些信息转换成资产网页，从而为银行提供了完整的、可视化的全景呈现。

继续回到图4，示例性地，业务流程模型存储单元311可以用于存储具体业务处理过程，支持银行核心业务流程和辅助业务流程的应用，可根据业务战略和业务流程的改变而进行改变。该储存单元至少包括：事件、活动、条件、顺序流、消息流。其中，事件指一个业务流程期间发生的东西。事件影响流程的流动，一般有一个原因(触发器)或一个影响(结果)。基于它们对流程的影响，有三种事件：开始，中间以及终止事件。活动指要处理工作的一个具体环节，条件用于控制序列流的分支与合并，顺序流用于指定活动执行的顺序，消息流用于描述两个独立的业务参与者(业务实体或业务角色)之间发送和接收的消息流动。

主辅应用模型存储单元312可以用于存储主应用和相关辅应用之间的关联关系，至少包括：主应用、辅应用、关联关系。其中主应用是实现业务核心功能的应用，辅应用是所有配合主应用完成本业务系统功能的应用。数据流模型存储单元313可以用于存储系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，至少包括：应用、联机关系、批量关系、联机与批量关系等。其中联机关系用于表示两个应用之间是通过联机接口访问的关系，批量关系用于表示两个应用之间是通过批量文件接口访问的关系，批量与联机关系用于表示两个应用之间既有联机接口访问，又有通过批量文件接口访问的关系。

应用节点模型存储单元314可以用于存储应用内部的应用节点划分，是连接应用架构和技术架构的桥梁，至少包括：主机服务节点、WEB服务节点、标准应用服务节点、非标准应用服务节点、数据服务节点、客户端节点等。其中主机服务节点指需要部署在主机系统运行环境的应用程序资源，WEB服务节点指遵循B/S结构技术要求，应用部署在WEB服务器上的应用资源，标准应用服务节点指遵循B/S结构技术要求，应用部署在应用服务器上的应用资源，非标准应用服务节点指采用C/S结构实现的功能，部署在服务器上的程序资源，数据服务节点指需要部署在数据库服务器上的应用资源，客户端节点指需要在客户端环境部署的应用资源。

逻辑数据模型存储单元315可以用于存储实体和它们之间的关系，至少包括：实体、关系等。其中实体是现实世界中可区别于其他对象的“事件”或“物体”，关系是多个实体之间的相互关联，例如一对一、一对多、多对多关系等。物理部署模型存储单元316可以用于存储应用在生产环境的物理部署情况，至少包括：区域、网络安全区域、应用节点、关联关系等。其中区域根据不同物理部署地进行划分，网络安全区域是一个具有相同安全风险、相同安全防护等级、相同用户访问群的服务器集合，由同一网络安全层次内的一个或几个VLAN(Virtual Local Area Network，虚拟局域网)组成，关联关系描述应用节点之间的关联关系。元数据存储单元317还可以用于存储各种模型之间的关联关系，为上述各种模型存储单元提供支撑服务，至少包括：组织、角色、区域、安全区域等。其中组织和角色在业务流程模型存储单元中使用，描述业务流程的参与者，区域和安全区域在物理部署模型存储单元中使用，描述应用节点的部署区域。

图6示意性示出了根据本公开实施例的图3所示的模型数据处理模块320的示例结构图。

如图6所示，模型数据处理模块320可以包括：主处理单元321、接口数据处理装置322、模型控制装置323、模型引擎装置324、模型数据装备装置325、模型数据处理装置326、以及模型结果数据储存装置327。

主处理单元321是模型数据处理模块320中负责响应建模申请数据、基础模型数据调阅、建模后数据的组装与处理等的主控单元。系统构建终端340发起的处理请求(例如建模申请数据)，经过金融传输网络传输，发送至模型数据处理模块320中的主处理单元321。主处理单元321通过接口数据处理装置322将处理请求传给模型控制装置323。模型控制装置323获取建模申请数据中的模型类别后，调用模型引擎装置324，从基础架构资产库(如模型数据存储模块310)中调出现有的属于该模型类别的模型(可以包括基础模型和非基础模型)并返回至客户端向用户进行展示。用户根据实际业务中新产品属性对现有的模型进行配置。在接收到来自客户端的配置数据后，主处理单元321调用模型数据装备装置325按照模型结构要求进行组装，通过模型数据处理装置326进行模型数据的处理，最后调用模型结果数据储存装置327对建模数据进行入库处理。

接口数据处理装置322用于系统内部各模块之间数据信息交互，以及作为本系统与外部用户之间进行请求和结果交互的入口。模型控制装置323负责处理请求解析，在接收到接口数据处理装置322传输过来的处理请求后，从所述处理请求中解析得到处理请求涉及的模型类别。模型控制装置323在获取到模型类别信息后，模型引擎装置324负责解析模型数据存储模块310中的各类模型储存单元，并将现有的属于该模型类别的模型资产通过接口数据处理装置322反馈给客户端。然后用户基于业务需求通过客户端针对所反馈的模型资产进行配置操作(如输入操作、拖拽操作等)，配置信息通过接口数据处理装置322返传给主处理单元321。模型数据装备装置325负责将配置信息，按照模型类别要求，装配成可执行的模型数据处理指令，通过接口数据处理装置322传输给模型数据处理装置326。模型数据处理装置326接收到模型数据装备装置325传输过来的可执行的模型数据处理指令，进行运行处理，通过接口数据处理装置322将运行结果信息传递给模型结果数据储存装置327。模型结果数据储存装置327通过接口数据处理装置322接收运行结果信息，并将运行结果信息保存至模型数据存储模块310中的相应模型储存单元中，并通过接口数据处理装置322将所述处理请求的运行状态(正常/失败)反馈给主处理单元321。如果运行状态正常，将模型结果数据储存装置327中的运行结果信息通过接口数据处理装置322反馈给系统构建终端340，由系统构建终端340以流程图、数据流图等可读性强的方式将运行结果信息展示给用户。

图7示意性示出了根据本公开实施例的用于计算系统的业务建模装置的框图。

如图7所示，该用于计算系统的业务建模装置700可以包括：管理模块710、第一接收模块720、元模型获取模块730、第二接收模块740和建模模块750。

管理模块710用于在元模型数据库中管理一个或多个模型类别的元模型。

第一接收模块720用于接收来自客户端的第一建模申请数据，第一建模申请数据包括第一模型类别。

元模型获取模块730用于从元模型数据库获取针对第一模型类别的第一元模型，并将第一元模型发送至客户端。

第二接收模块740用于接收来自客户端关于第一元模型的业务配置信息，业务配置信息包括对象配置信息和关系配置信息。

建模模块750用于基于第一元模型和业务配置信息，在业务模型数据库中构建属于第一模型类别的业务模型。

需要说明的是，装置部分实施例中各模块/单元/子单元等的实施方式、解决的技术问题、实现的功能、以及达到的技术效果分别与方法部分实施例中各对应的步骤的实施方式、解决的技术问题、实现的功能、以及达到的技术效果相同或类似，在此不再赘述。

根据本公开的实施例的模块、子模块、单元、子单元中的任意多个、或其中任意多个的至少部分功能可以在一个模块中实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以被拆分成多个模块来实现。根据本公开实施例的模块、子模块、单元、子单元中的任意一个或多个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式的硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，根据本公开实施例的模块、子模块、单元、子单元中的一个或多个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

例如，管理模块710、第一接收模块720、元模型获取模块730、第二接收模块740和建模模块750中的任意多个可以合并在一个模块中实现，或者其中的任意一个模块可以被拆分成多个模块。或者，这些模块中的一个或多个模块的至少部分功能可以与其他模块的至少部分功能相结合，并在一个模块中实现。根据本公开的实施例，管理模块710、第一接收模块720、元模型获取模块730、第二接收模块740和建模模块750中的至少一个可以至少被部分地实现为硬件电路，例如现场可编程门阵列(FPGA)、可编程逻辑阵列(PLA)、片上系统、基板上的系统、封装上的系统、专用集成电路(ASIC)，或可以通过对电路进行集成或封装的任何其他的合理方式等硬件或固件来实现，或以软件、硬件以及固件三种实现方式中任意一种或以其中任意几种的适当组合来实现。或者，管理模块710、第一接收模块720、元模型获取模块730、第二接收模块740和建模模块750中的至少一个可以至少被部分地实现为计算机程序模块，当该计算机程序模块被运行时，可以执行相应的功能。

图8示意性示出了根据本公开实施例的适于实现上文描述的方法的计算机系统的框图。图8示出的计算机系统仅仅是一个示例，不应对本公开实施例的功能和使用范围带来任何限制。

如图8所示，根据本公开实施例的计算机系统800包括处理器801，其可以根据存储在只读存储器(ROM)802中的程序或者从存储部分808加载到随机访问存储器(RAM)803中的程序而执行各种适当的动作和处理。处理器801例如可以包括通用微处理器(例如CPU)、指令集处理器和/或相关芯片组和/或专用微处理器(例如，专用集成电路(ASIC))，等等。处理器801还可以包括用于缓存用途的板载存储器。处理器801可以包括用于执行根据本公开实施例的方法流程的不同动作的单一处理单元或者是多个处理单元。

在RAM 803中，存储有系统800操作所需的各种程序和数据。处理器801、ROM 802以及RAM 803通过总线804彼此相连。处理器801通过执行ROM 802和/或RAM 803中的程序来执行根据本公开实施例的方法流程的各种操作。需要注意，所述程序也可以存储在除ROM 802和RAM 803以外的一个或多个存储器中。处理器801也可以通过执行存储在所述一个或多个存储器中的程序来执行根据本公开实施例的方法流程的各种操作。

根据本公开的实施例，系统800还可以包括输入/输出(I/O)接口805，输入/输出(I/O)接口805也连接至总线804。系统800还可以包括连接至I/O接口805的以下部件中的一项或多项：包括键盘、鼠标等的输入部分806；包括诸如阴极射线管(CRT)、液晶显示器(LCD)等以及扬声器等的输出部分807；包括硬盘等的存储部分808；以及包括诸如LAN卡、调制解调器等的网络接口卡的通信部分809。通信部分809经由诸如因特网的网络执行通信处理。驱动器810也根据需要连接至I/O接口805。可拆卸介质811，诸如磁盘、光盘、磁光盘、半导体存储器等等，根据需要安装在驱动器810上，以便于从其上读出的计算机程序根据需要被安装入存储部分808。

根据本公开的实施例，根据本公开实施例的方法流程可以被实现为计算机软件程序。例如，本公开的实施例包括一种计算机程序产品，其包括承载在计算机可读存储介质上的计算机程序，该计算机程序包含用于执行流程图所示的方法的程序代码。在这样的实施例中，该计算机程序可以通过通信部分809从网络上被下载和安装，和/或从可拆卸介质811被安装。在该计算机程序被处理器801执行时，执行本公开实施例的系统中限定的上述功能。根据本公开的实施例，上文描述的系统、设备、装置、模块、单元等可以通过计算机程序模块来实现。

本公开还提供了一种计算机可读存储介质，该计算机可读存储介质可以是上述实施例中描述的设备/装置/系统中所包含的；也可以是单独存在，而未装配入该设备/装置/系统中。上述计算机可读存储介质承载有一个或者多个程序，当上述一个或者多个程序被执行时，实现根据本公开实施例的方法。

附图中的流程图和框图，图示了按照本公开各种实施例的系统、方法和计算机程序产品的可能实现的体系架构、功能和操作。在这点上，流程图或框图中的每个方框可以代表一个模块、程序段、或代码的一部分，上述模块、程序段、或代码的一部分包含一个或多个用于实现规定的逻辑功能的可执行指令。也应当注意，在有些作为替换的实现中，方框中所标注的功能也可以以不同于附图中所标注的顺序发生。例如，两个接连地表示的方框实际上可以基本并行地执行，它们有时也可以按相反的顺序执行，这依所涉及的功能而定。也要注意的是，框图或流程图中的每个方框、以及框图或流程图中的方框的组合，可以用执行规定的功能或操作的专用的基于硬件的系统来实现，或者可以用专用硬件与计算机指令的组合来实现。

本领域技术人员可以理解，尽管已经参照本公开的特定示例性实施例示出并描述了本公开，但是本领域技术人员应该理解，在不背离所附权利要求及其等同物限定的本公开的精神和范围的情况下，可以对本公开进行形式和细节上的多种改变。因此，本公开的范围不应该限于上述实施例，而是应该不仅由所附权利要求来进行确定，还由所附权利要求的等同物来进行限定。

Claims (10)

1.一种用于计算系统的业务建模方法，包括：

在元模型数据库中管理一个或多个模型类别的元模型；

接收来自客户端的第一建模申请数据，所述第一建模申请数据包括第一模型类别；

从所述元模型数据库获取针对所述第一模型类别的第一元模型，并将所述第一元模型发送至所述客户端；

接收来自所述客户端关于所述第一元模型的业务配置信息，所述业务配置信息包括对象配置信息和关系配置信息；以及

基于所述第一元模型和所述业务配置信息，在业务模型数据库中构建属于所述第一模型类别的业务模型。

2.根据权利要求1所述的方法，其中，所述一个或多个模型类别包括如下至少一项：

业务流程模型类别、主辅应用模型类别、数据流模型类别、应用节点模型类别、逻辑数据模型类别、以及物理部署模型类别。

3.根据权利要求1所述的方法，其中，所述在元模型数据库中管理一个或多个模型类别的元模型包括：

接收来自客户端的第二建模申请数据，其中，所述第二建模申请数据包括第一模型类别和元模型建模信息，所述元模型建模信息包括一个或多个元素信息以及元素之间的关系信息；

基于所述元模型建模信息构建针对所述第一模型类别的第一元模型；以及

将所述第一元模型存入所述元模型数据库。

4.根据权利要求1所述的方法，还包括：

接收来自客户端的模型查询请求，所述模型查询请求包括第二模型类别；

从所述业务模型数据库中获取属于所述第二模型类别的业务模型；以及

将所述属于所述第二模型类别的业务模型发送至客户端，以便所述客户端对属于所述第二模型类别的业务模型进行展示。

5.根据权利要求4所述的方法，其中，所述在元模型数据库中管理一个或多个模型类别的元模型包括：

接收来自客户端的修改申请数据，所述修改申请数据包括针对第三模型类型的修改信息；

从所述元模型数据库中获取针对所述第三模型类型的第三元模型；

基于所述修改信息，对所述第三元模型进行修改，得到修改后的第三元模型；以及

基于所述修改后的第三元模型，对所述业务模型数据库中属于所述第三模型类型的一个或多个业务模型进行修改。

6.根据权利要求1所述的方法，还包括：

将所述属于所述第一模型类别的业务模型发送至所述客户端，以便所述客户端对所述属于所述第一模型类别的业务模型进行展示。

7.根据权利要求6所述的方法，其中，所述将所述属于所述第一模型类别的业务模型发送至所述客户端包括：

将针对所述业务模型的流程图发送至所述客户端。

8.根据权利要求7所述的方法，其中，所述将所述属于所述第一模型类别的业务模型发送至所述客户端还包括：

接收来自客户端的输入参数；

基于所述输入参数运行所述业务模型，得到运行结果；以及

将所述运行结果发送至客户端。

9.一种用于计算系统的业务建模装置，包括：

管理模块，用于在元模型数据库中管理一个或多个模型类别的元模型；

第一接收模块，用于接收来自客户端的第一建模申请数据，所述第一建模申请数据包括第一模型类别；

元模型获取模块，用于从所述元模型数据库获取针对所述第一模型类别的第一元模型，并将所述第一元模型发送至所述客户端；

第二接收模块，用于接收来自所述客户端关于所述第一元模型的业务配置信息，所述业务配置信息包括对象配置信息和关系配置信息；以及

建模模块，用于基于所述第一元模型和所述业务配置信息，在业务模型数据库中构建属于所述第一模型类别的业务模型。

10.一种计算机系统，包括：存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述计算机程序时用于实现如权利要求1～8任一项所述的方法。

Images