CN117992035A - 业务模型建模方法、装置、设备以及存储介质 - Google Patents

Abstract

本申请公开了一种业务模型建模方法、装置、设备以及存储介质，属于低代码开发技术领域。该方法包括响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各预置模型视图具有模型配置信息以及应用程序接口信息；模型配置信息包括字段信息、字段状态信息以及显示顺序信息；响应于用户的第二操作，从多个页面预置组件中确定出目标页面预置组件；将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面；基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型。本申请可以提供一种可扩展性较强的业务模型建模方法。

Description

业务模型建模方法、装置、设备以及存储介质

技术领域

本申请涉及低代码开发领域，尤其涉及一种业务模型建模方法、装置、设备以及存储介质。

背景技术

在相关技术中，由于不同的低代码厂商的建模能力不同，建立在不同低代码产品中的相关模型在概念和能力方面也存在差异，目前的低代码模型的模型能力都是相对独立存在的，没有与低开平台其他自定义的模块结合起来，故存在着建模可扩展性较低的问题。

发明内容

本申请的主要目的在于提供一种业务模型建模方法、装置、设备以及存储介质，旨在提供一种可扩展性较强的业务模型建模方法。

为实现上述目的，本申请提供一种业务模型建模方法，所述业务模型建模方法包括以下步骤：

响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各预置模型视图具有模型配置信息以及应用程序接口信息；模型配置信息包括字段信息、字段状态信息以及显示顺序信息；

响应于用户的第二操作，从多个页面预置组件中确定出目标页面预置组件；

将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面；

基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型。

可选地，预置模型视图包括表格视图或者列表视图；

将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面，包括：

响应于用户的第三操作，对目标模型视图对应的字段信息进行更新，获得更新后的目标模型视图；

将更新后的目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面。

可选地，响应于用户的第三操作，对目标模型视图对应的字段信息进行更新，获得更新后的目标模型视图，包括：

响应于用户的选择操作，从目标模型视图对应的所有预置字段信息中确定出目标字段信息，获得更新后的目标模型视图；或者

响应于用户的输入操作，向目标模型视图添加新的字段信息，获得更新后的目标模型视图。

可选地，基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型，包括：

确定与业务模型关联的关联业务模型，以及所述业务模型与关联业务模型之间的模型关系；其中，所述模型关系包括主子关系或查找关系；

基于加载后的自定义页面、目标模型视图的应用程序接口信息以及模型关系，获得业务模型。

可选地，基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型，包括：

获取用户输入的自定义应用程序接口与绑定操作指令；其中，绑定操作指令具有待绑定的配置信息；

将自定义应用程序接口与待绑定的配置信息绑定；

基于加载后的自定义页面、目标模型视图的应用程序接口信息以及自定义应用程序接口，获得业务模型。

可选地，基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型之后，该方法还包括：

获取用户输入的操作信息；其中，操作信息的格式为对象查询语言；

解析对象查询语言，获得抽象语法树；其中，抽象语法树包括多个查询字段信息以及各查询字段信息之间的驱动关系；

基于多个查询字段信息以及各查询字段信息之间的驱动关系，生成至少一个结构化查询语言；

基于所有结构化查询语言，调用业务模型。

可选地，业务模型的字段信息类型以JSON数据格式描述。

此外，为实现上述目的，本申请还提出一种业务模型建模装置，该装置包括：

第一确定模块，用于响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各预置模型视图具有模型配置信息以及应用程序接口信息；模型配置信息包括字段信息、字段状态信息以及显示顺序信息；

第二确定模块，用于响应于用户的第二操作，从多个页面预置组件中确定出目标页面预置组件；

自定义模块，用于将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面；

模型生成模块，用于基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型。

此外，为实现上述目的，本申请还提出一种业务模型建模设备，该设备包括：处理器，存储器以及存储在所述存储器中的计算机程序，所述计算机程序被所述处理器运行时实现如上述业务模型建模方法的步骤。

此外，为实现上述目的，本申请还提出一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述的业务模型建模方法。

本申请提供的业务模型建模方法中可以响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各预置模型视图具有模型配置信息以及应用程序接口信息；模型配置信息包括字段信息、字段状态信息以及显示顺序信息；且还可以响应于用户的第二操作，可以从多个页面预置组件中确定出目标页面预置组件，从而本申请提供的业务模型建模方法可以根据用户自身的业务需求进行自定义建模，将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面，由此可以基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型，能够有效提升业务模型建模的可扩展性。

附图说明

图1为本申请实施例方案涉及的硬件运行环境的业务模型建模设备的结构示意图；

图2为本申请实施例提供的业务模型建模方法第一实施例的流程示意图；

图3为业务模型和业务数据以及业务字段类型与业务字段之间的关系示意图；

图4为一示例的模型关系示意图；

图5为预置模型的可视化建模原型图；

图6为表单视图的可视化配置原型图；

图7为列表视图的可视化配置原型图；

图8为前端模型视图与后端API关系图；

图9为融合模型页面示意图；

图10为图2中步骤S300的细化流程示意图；

图11为模型与表格的融合原型图；

图12为本申请实施例提供的业务模型建模方法第二实施例的流程示意图；

图13为目标模型视图、自定义页面与自定义API的结合示意图；

图14为本申请实施例提供的业务模型建模方法第三实施例的流程示意图；

图15为OQL转换为SQL的过程示意图；

图16为本申请业务模型建模装置的功能模块示意图。

本申请目的的实现、功能特点及优点将结合实施例，参照附图做进一步说明。

具体实施方式

应当理解，此处所描述的具体实施例仅仅用以解释本申请，并不用于限定本申请。

随着低代码相关技术的成熟，以及企业数字化转型的需要，市面上出现了越来越多的低代码平台，这些平台或多或少都有一些模型相关的能力。模型开发成为低代码应用开发中重要的一环。但是取决于不同的低代码厂商的建模能力，模型在概念、能力在不同的低代码产品中也是有着或多或少的差异。本申请发明人发现目前的低代码模型的模型能力都是相对独立存在的，没有与低开平台其他自定义的模块结合起来，故存在着建模可扩展性较低的问题。

为了解决这一问题，提出本申请的业务模型建模方法，本方法可以响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各预置模型视图具有模型配置信息以及应用程序接口信息；模型配置信息包括字段信息、字段状态信息以及显示顺序信息；且还可以响应于用户的第二操作，可以从多个页面预置组件中确定出目标页面预置组件，从而本申请提供的业务模型建模方法可以根据用户自身的业务需求进行自定义建模，将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面，由此可以基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型，能够有效提升业务模型建模的可扩展性。

以下将通过多个实施例进行展开说明和介绍。

参照图1，图1为本申请实施例方案涉及的硬件运行环境的业务模型建模设备的结构示意图。

如图1所示，该业务模型建模设备可以包括：处理器1001，例如CPU，用户接口1003，存储器1005，通信总线1002。其中，通信总线1002用于实现这些组件之间的连接通信。用户接口1003可以包括语音拾取模块，如麦克风阵列等，可选用户接口1003还可以是显示屏(Display)、输入单元比如键盘(Keyboard)等。存储器1005可以是高速RAM存储器，也可以是稳定的存储器(non-volatile memory)，例如磁盘存储器。存储器1005可选的还可以是独立于前述处理器1001的存储装置。

可以理解的是，所述业务模型建模设备还可以包括网络接口1004，网络接口1004可选的可以包括标准的有线接口、无线接口(如WI-FI接口)。可选地，终端还可以包括RF(Radio Frequency，射频)电路，传感器、音频电路、WiFi模块等等。

本领域技术人员可以理解，图1中示出的业务模型建模设备结构并不构成对业务模型建模设备的限定，可以包括比图示更多或更少的部件，或者组合某些部件，或者不同的部件布置。

如图1所示，作为一种存储介质的存储器1005中可以包括操作系统、数据存储模块、网络通信模块、用户接口模块以及业务模型建模程序。

在图1所示的业务模型建模设备中，网络接口1004主要用于与网络服务器进行数据通信；用户接口1003主要用于与用户进行数据交互；本申请业务模型建模设备中的处理器1001、存储器1005可以设置在业务模型建模设备中，业务模型建模设备通过处理器1001调用存储器1005中存储的业务模型建模程序，并执行本申请实施例提供的业务模型建模方法。

基于上述业务模型建模设备的硬件结构但不限于上述硬件结构，本申请提供一种业务模型建模方法的第一实施例。参照图2，图2示出了本申请业务模型建模方法的第一实施例的流程示意图。

需要说明的是，虽然在流程图中示出了逻辑顺序，但是在某些情况下，可以以不同于此处的顺序执行所示出或描述的步骤。

在本实施例中，实施业务模型建模方法包括以下步骤：

步骤S100，响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图。

其中，各预置模型视图具有模型配置信息以及应用程序接口信息；模型配置信息包括字段信息、字段状态信息以及显示顺序信息。

步骤S200，响应于用户的第二操作，从多个页面预置组件中确定出目标页面预置组件。

步骤S300，将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面。

步骤S400，基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型。

为便于本申请方案的理解，下文先从业务模型、业务字段以及业务字段类型的一些概念进行说明。

业务模型是在企业数字化信息建设过程中，可以识别的业务概念或业务对象，如员工、教育经历、工作经历、转正记录、出差申请、出差行程、请假申请等等。但其不同于数据库表，它不是员工表、出差申请表这些概念。虽然业务模型与存储它的表之间存在非常紧密的联系，但两者并不等价，根据业务模型创建的一条条数据可以被称为业务数据(也称为业务记录)，比如出差申请是一个业务模型，一条条出差申请记录就是出差申请模型的业务数据。

业务字段是业务模型下的用户可以识别的各种要素，比如“员工”这一模型下有工号、姓名、性别、出生年月、家庭住址等要素。在此要特别强调的是，上述的“用户可以识别”是区别于用户不可感知的要素，比如在应用运行过程中为了一些非功能的需求，会记录一些审计信息、日志信息、处理的中间值等等。每一个业务字段都有它的类型，也即是业务字段类型。业务字段类型是对一类具有相同特征的业务字段的抽象，也是进行业务模型建模的核心支撑。比如，出差申请的开始日期与结束日期字段都是一种叫“日期”的业务字段类型，员工的家庭住址是一种叫“地址”的业务字段类型。在业务模型的建模过程中，可以通过业务字段类型来实例化业务模型下的一个个业务字段。

按业务字段是由用户配置的，还是由系统创建的来划分，可以将业务字段分为用户字段以及系统字段。系统字段主要有创建人、创建时间、更新人、更新时间、版本号(乐观锁版本控制)等。业务模型根据它的使用场景与相关特征，也可以具有一些附额的业务字段，比如：如果一个模型是具备流程能力的模型，那么它就有会内置一个“流程状态”的业务字段，在业务上通过流程状态字段也可以控制数据的增删改；如果一个模型具有层级结构，那么它就可以内置一个“父记录ID”的业务字段，方便在一些界面中将业务的数据展示成树形结构，这些额外的字段同时也是系统字段。为便于理解，如表1所示，表1展示了一个“员工(Staff)”的业务模型示例。

表1：

字段名称	字段标题	字段类型	字段分类
				staffId	员工编号	文本	用户
staffName	员工姓名	文本	用户
				birthday	出生年月	日期	用户
age	年龄	整数	用户
				address	家庭住址	地址	用户
mobile	联系电话	手机号	用户
				createdBy	创建人编号	文本	系统
createdAt	创建人姓名	文本	系统
				modifiedBy	更新人编号	文本	系统
modifiedAt	更新人姓名	文本	系统
				revision	版本号	整数	系统

从面向对象的角度来看，业务模型和业务数据之间的关系以及业务字段类型与业务字段之间的关系，就是类与实例的关系，如图3所示，图3示出了业务模型和业务数据以及业务字段类型与业务字段之间的关系示意图。

业务模型与业务模型之间的关系可以抽象为两类，一类为主子关系(也称Master-Detail关系)，一类为查找关系(也称Lookup关系)。其中，主子关系是一种附属关系，子模型的数据是不能独立存在的，必须依附于主模型存在。比如，“出差申请”是主模型，一个主出差申请模型下面可能有多条出差行程明细，那么这个“出差行程”就是子模型，“出差行程”不能脱离于“出行申请”主模型而独立存在。查找关系则是一种依赖关系，查找关系的两个模型都是可以独立存在的；比如，“出差报销申请”是一个业务模型，出差报销申请时必须关联一个出差申请，那么此时“出差报销申请”对于“出差申请”而言是查找关系。从数量上看，查找关系可以是一对一的，比如，每个出差报销申请只能关联一个出差申请；也可以是一对多的，比如，每个出差报销申请可以关联多个出差申请，模型之间具体的关联关系可以根据用户的需求(如企业制度等)来决定。如图4所示，图4示出了一示例的模型关系示意图。此外，两个模型之间的关系应该是明确的，不能既是主子关系又是查找关系；两个模型可以互为查找关系，但不能互为主子关系；一个主模型下可以有多个子模型，也可以有多个查找模型；一个子模型可以是多个主模型的子模型，在建模时可以在子模型中添加一个主模型的类型，完成模型的关联。

一般而言，一个业务模型下有很多个业务字段，既包括了用户字段，又包括了系统字段，关于业务字段的具体信息，可以内聚在一个字段的配置中。除去业务模型的基本信息(如名称、标题等)之外，一个业务模型整体的最核心内容还需要包括：模型字段之间的联动规则。在表单数据录入的时候，为了更好的用户体验，需要配置字段之间的联动关系，比如当某个字段变更时，触发另一个字段隐藏等，又比如在当用户选择了某一项时，按用户选定的值动态加载至另一个选项列表；模型的全局性校验。在表单数据提交时，或者后端调用应用程序接口作数据创建、更新时，对数据的合法性、完整性进行检查，比如，一笔订单的总金额不能超过订单的预算金额；模型之间的数据同步。模型字段之间的联动规则以及模型的全局性校验军事在同一个模型内部的规则，而模型之间的数据同步是两个模型或者多个模型之间的数据同步，比如在商品出库时需要扣减库存，“商品”和“库存”就是两个独立的模型。如下为一个“员工”模型的信息示例：

//模型的名称:STAFF

//模型的标题:员工

//模型记录校验函数

//数据联动(用于表单录入时的组件间联动)

//数据事件(用于后台数据监听)；

对于业务字段类型(即字段信息类型)，在企业数字化过程中，围绕着数据进行处理、流转的业务是非常多见的，在功能上具体就表现为通过表格、表单以及流程等功能来处理各类业务数据，同一条数据的同一个业务字段，在不同的场景下会表现出不同的行为、规则，主要有如下方面：

在数据录入(新增或修改)时，不同的业务字段会选择不同的输入型组件，比如日期字段会选择日期组件，单选字段会根据字段的属性“展示方式”选择下拉组件还是平铺组件，同时根据不同的设备(PC与移动)也可以选择不同的输入组件来录入；还有一些字段类型在数据录入时有一些特殊的规则，比如公式字段类型在表单数据新增和修改时均不可见，流水号字段类型在表单数据新增是不可见，且在表单数据修改时只读。

在数据查询时，不同的业务字段类型会选择不同的输入型组件，比如日期字段类型，可以根据日期是精确匹配还是区间匹配来选择是采用日期组件还是日期区间组件来输入。

在数据查看时，无论是在表格列中查看，还是在表单上查看(字段只读时)，以及数据导出EXCEL时，都需要对数据进行格式化，即将持久化的值转换为显示值，不同的字段类型可以有不同的格式化函数，比如，日期字段类型会根据字段的属性“日期格式”来将数据格式化成不同的展示形式。

在数据导入EXCEL时，要对数据进行反格式化，即将显示值转换为持久化的值。

在数据校验时，无论是前端录入数据时校验，还是后端保存数据时校验，每一种业务字段类型都有自己的数据校验方法，比如，对于数字类型的字段，会根据字段配置的最大值和最小值进行校验，如果前端校验失败，则会阻止表单提交，而如果后端校验失败，则会阻止数据持久化。

在数据持久化时，不同的字段类型需要将自己的类型映射成持久化层能支持的类型(如：文本、整数、小数、金额、布尔、JSON)，当数据保存缺少相应的数据时，不同的字段类型可以定制字段的默认值，比如出差类型的默认值可以是“因公出差”，流水号字段类型的默认值将通过一个函数生成一个流水号，公式字段类型的默认值将通过一个函数调用计算出一个值。如下为一个模型内的“日期”业务字段类型，其描述了上述提到的业务字段内容：

//字段类型的名称：date

//字段类型的标题：日期

//字段的属性，用于可视化配置时配置字段的信息

//默认值属性，支持表达式

//日期的存储数据格式，下拉选择

//字段类型持久化时采用的数据类型，可根据可视化配置的信息动态计算

//录入时的配置

//查询时的配置

//字段类型的数据默认值生成函数，在数据插入或更新时生成数据默认值

//字段类型数据校验函数，对数据进行校验

//字段类型数据格式化函数，对数据进行格式化

//字段类型数据反格式化函数，对数据进行反格式化；

需要说明的是，上述业务字段类型的高度抽象，可以以JSON的方式来描述字段类型的数据录入、数据编辑、数据查询、数据展示、数据存储等各方面的规范，从而使得低代码平台快速扩展得到一个业务字段类型，使得低代码平台在数据的CURD(即创建Create、更新Update、读取Read和删除Delete操作)等各种场景的代码中做到自适应。

基于这样的规范化的描述，本申请可以做到灵活地扩展一种新的业务字段类型，只需要修改业务字段类型而对程序实现没有任何影响，从而可以做到变与不变的分离，使得业务模型开发更为灵活。参照图5，图5示出了预置模型的可视化建模原型图，如图5所示，可以通过拖入左侧的字段类型组件，支持在界面上配置一个具体的字段。比如拖入一个日期字段类型，页面中间画布可以见到其在表单中的展现，通过页面右侧配置具体的属性，可以得某个具体日期字段(如出差的开始日期)，这也是一个字段类型实例化为一个字段的过程。

模型视图是一个模型以不同的形态来展示数据的一个视图。常见的模型视图有以列表形态展现的列表视图，以表单形式展现的表单视图，还有其它如图表视图等等。用户通过配置不同的表单视图和列表视图，可以满足不同的场景需求。如企业内部请假场景，普通员工在列表中只能查询自己的记录，后台也会对数据权限进行限制。当在表单有新增假期时，员工只能申请自己的假期。但企业HR则有专用的列表视图，可以查看全员的假期，当表单新增假期时，还可以代别人请假，表单中的字段数量和普通员工亦不相同。

其中，模型的表单视图以一个表单的形态展示一条业务数据，并通过表单操作此条业务数据操作，如单条数据的增删改以及打印操作等。不同的处理场景下对同一个业务字段的展示要求不同，比如某些场景下一个业务字段要能够输入，而有些场景要禁止输入，有些场景下是只读的，有些场景下需要隐藏起来。模型表单区别于普通的表单具有模态概念，即当前表单处于新增记录、编辑记录或者查看记录时，通过不同的模态可以控制不同字段的显示状态，字段的状态一般有4种，正常、不可编辑、只读、隐藏。图6示出了一个表单视图的可视化配置原型图，左侧配置模型用到的字段(也包括子模型的字段)、字段的状态、显示顺序等，右侧配置模型的初始化接口、操作等。在表单视图中可以配置表单中需要加载的字段(其它字段在渲染时不加载，就算通过浏览器F12工具也看不到)；表单提交操作，如前文所述的，可以对一条数据进行操作，调用模型开箱即用的模型API、自定义的API或者仅仅是一个前端的操作(如打印等)。如下为表单视图的配置示例：

//表单视图的名称:rHolidayForm

//表单视图的标题:HR请假表单

//表单视图的字段配置:开始日期、结束日期、员工编号、请假类型、请假原因

//表单视图的操作配置：录入、编辑、删除、查看详情、启禁用；

基于上述配置可以进行界面渲染，界面渲染和相关操作逻辑如下：初始化时，根据配置的字段清单初始化表单，同时如果存在初始化接口的话，则调用初始化接口初始化表单；当用户的输入表单数据的时候，模型上配置的联动关系就会生效；当用户提交表单的时候，模型上配置的校验逻辑就会生效，如果校验通过，则继续执行配置的操作。

而列表视图是以列表的形式来展示模型的数据，通过列表的表头操作以及表行操作可以对数据进行数据的增删改查处理，同时还可以输入查询条件来查询特定范围的数据。不同的场景下对同一个业务字段的展示要求也是不同，如前所述，员工列表中不能显示代请假人，且仅能看见自己的数据，HR则可以显示代请假人，且全部数据可见。图7示出了一个列表视图的可视化配置原型图，左侧配置模型的字段(也包括子模型的字段)、显示顺序等，右侧配置模型的初始化接口、操作等。在列表视图中可以配置列表中需要加载的字段以及字段的格式化函数；后台数据的过滤条件，如普通员工视图和HR视图的后台过滤条件不同；表头操作，表头操作一般用于打开新增的弹窗，或者对当前列表选中行的数据进行操作，当前列表全部选中行存于一个局部变量selectedRecords中。表头操作的函数签名如下：(selectedRecords)＝>{//在这里实现处理逻辑}。通过这个操作来处理如下动作：1、没有选中行时阻止后续动作；2、将选中行的某一列的数据提交到后台API处理(如批量更新、批量导出等)；表行操作，表行操作一般用于当前行的详情查看、修改、删除、打印、审批等操作，当前行的记录存在于局部变量record中，当前行的行号存在于局部变量index中。表行操作的函数签名如下：(record,index)＝>{//在这里实现处理逻辑}。利用上述操作可处理如下动作：1、以选中行的某些列的数据提交到后台API处理(如更新记录)；2、弹出一个窗口，将选中行的数据直接赋值给弹出的窗口。如下为列表视图的配置示例：

//列表视图的名称：hrHolidayList

//列表视图的标题：HR请假管理

//列表视图的字段配置:开始日期、结束日期、员工编号、请假类型(带格式化函数)、请假原因

//列表视图的表头操作配置：批量发送(调用API)

//列表视图的表行操作配置：删除(调用API)；

基于上述配置可以进行列表视图界面渲染，界面渲染和操作逻辑如下：初始化时，根据配置的字段清单与操作初始化表格，同时调用初始化接口加载数据，在渲染数据的时候，每一行的渲染都会调用列的渲染函数，将当前列的值、当前行的值、当前行号传递给渲染函数；当点击查询时，收集查询表单的数据后调用后台的API，并将返回结果刷新表格；当点击表头操作时，收集当前选中行数据，初始化selectedRecords局部变量，然后调后表头操作；当点击表行操作时，收集当前行数据，初始化record、index等局部变量，然后调用表行操作。

具体而言，用户根据实际业务需求在前端输入待开发模型的如上文所述的相关配置信息(字段信息、字段状态信息以及显示顺序信息等)，基于配置信息进行渲染可以在前端页面得到多个预置模型视图，各预置模型视图对应有后端开箱即用的模型应用程序接口(如增删改查API、导入导出API等)，如图8所示，图8示出了前端模型视图与后端API关系图。比如，当前有一个预置员工模型，员工有流水号用于生成员工编号、通过出生日期计算年龄，同时员工下面又有教育经历、工作经历等子模型，当提交一条带有教育经历、工作经历的员工数据时，后台对应的API会执行如下处理：1、生成主表(员工)的流水号(员工号)、公式(年龄)以及其它字段的默认值(依赖字段类型中定义的默认值生成函数)；2、对主表(员工)的每个字段的数据进行校验(依赖字段类型中定义的校验函数)，如有不符合业务规则的，则报错，否则继续；3、对主表(员工)数据的整体完整性进行校验(依赖模型中定义的校验函数)；4、插入主表(由持久层的驱动实现)，并返回主表的自增主键；5、循环对子表的数据进行处理：5.1将主表的ID填入子表的数据中，插入子表数据(同主表的处理逻辑)；5.2生成子表的流水号、公式、默认值(同主表的处理逻辑)；5.3对子表的每个字段的数据进行校验，如有错误则报错(同主表的处理逻辑)；5.4对子表的数据的整体完整性进行校验，如有错误则报错(同主表的处理逻辑)。

用户可以在前端操作页面根据模型的设计需求从预置模型视图中选择目标模型视图，如上文所述，预置模型视图的可以是表单视图也可以是列表视图。接收到用户的操作信息后，设备可以响应于用户操作，在自定义页面中引入用户选择的目标模型视图。此外，当前的页面内还包含多个预置组件，用户可以根据建模需求从当前页面中的多个预置组件中确定出所需的目标页面预置组件，设备可以将确定出的目标模型视图以及目标页面预置组件在当前的自定义页面直接进行融合加载，以获得前端的融合模型页面，如图9所示，图9示出了融合模型页面示意图。这种可视化的建模方式可以降低业务模型建模的难度，使得一些非专业人员也可以快速进行业务模型的建模开发。或者作为一种实施方式，参照图10，图10示出了步骤S300的细化流程示意图。

在此实施方式下，步骤S300具体包括：

步骤S310，响应于用户的第三操作，对目标模型视图对应的字段信息进行更新，获得更新后的目标模型视图。

步骤S320，将更新后的目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面。

具体而言，可以响应于用户的选择操作，从目标模型视图对应的所有预置字段信息中确定出目标字段信息，获得更新后的目标模型视图。如可以通过自定义页面上的表格组件或者表单组件等绑定目标模型，用户可以从目标模型视图对应的预置字段信息中选择出所需的目标字段信息，设备响应于用户的选择操作，可以基于该目标字段信息获得绑定后的新的目标模型视图。

或者可以响应于用户的输入操作，向目标模型视图添加新的字段信息，获得更新后的目标模型视图。如，可以向目标模型视图中添加当前模型不具备的一些字段信息，以弥补目标模型视图上字段信息较为固定的不足。比如。一个目标模型有10个业务要素，但是在实际业务流转过程中，需要用到一些无需持久化到模型中的中间要素。如员工转正的表单上需要展示员工近两年的绩效，但绩效信息并不需要持久化到转正的模型上。此外，还可以依赖于模型的相关配置，快速生成自定义页面上表格与表单的配置，并且模型的配置调整后，自定义页面上的表格与表单相关的配置也会进行同步调整，由此可以在模型调整时做到表格或表单的及时更新。如图11所示，图11示出了模型与表格的融合原型图。完成目标字段信息的选择和添加后，可以将新获得的目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面，由此可以基于加载后的自定义页面以及目标模型视图对应的后台API，构建得到所需的业务模型。

不难理解的，本实施例提供的业务模型建模方法可以响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各预置模型视图具有模型配置信息以及应用程序接口信息；模型配置信息包括字段信息、字段状态信息以及显示顺序信息；且可以响应于用户的第二操作，可以从多个页面预置组件中确定出目标页面预置组件，从而可以根据用户自身的业务需求进行自定义建模，将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面，由此可以基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得所需的业务模型，有效提升了业务模型建模的可扩展性。

此外，基于加载后的自定义页面与所述目标模型视图的应用程序接口信息，获得所述业务模型，还可以包括：确定与业务模型关联的关联业务模型，以及业务模型与关联业务模型之间的模型关系；其中，模型关系包括主子关系或查找关系；基于加载后的自定义页面、目标模型视图的应用程序接口信息以及模型关系，获得业务模型。

上述业务模型之间的模型关系在前文已详细说明，此处不再赘述。根据具体业务模型的设计需求可以确定出与业务模型相关联的关联业务模型，并确定出模型之间的具体模型关系，由此可以根据模型关系、渲染得到的自定义页面以及自定义页面中模型对应的API信息，来搭建一个完整的可满足应用需求的业务模型。

需要说明的是，有时通过目标模型自动生成的界面可以完全满足业务需求，但目标模型对应的开箱即用的内置API可能无法满足应用需求。比如，业务数据在入库前需要做一个数据处理再入库，而直接调用目标模型开箱即用的API无法满足这一需求。故需要在目标模型的配置上绑定自定义的API来满足这一需求。进一步的，基于上述实施例，提出本申请业务模型建模方法的第二实施例。本实施例中，步骤S400还包括步骤S410、步骤S420和步骤S430，用于绑定自定义API。参照图12，图12示出了业务模型建模方法第二实施例的流程示意图。

在本实施例中，步骤S400具体包括以下步骤：

步骤S410，获取用户输入的自定义应用程序接口与绑定操作指令。

其中，绑定操作指令具有待绑定的配置信息。

步骤S420，将自定义应用程序接口与待绑定的配置信息绑定。

步骤S430，基于加载后的自定义页面、目标模型视图的应用程序接口信息以及自定义应用程序接口，获得业务模型。

具体而言，自定义应用程序接口是根据具体业务需求和功能要求，有开发者或者系统管理员定义的接口，可以进行特定操作。通过绑定操作指令可以将自定义API与目标模型视图进行绑定关联，以便后续生成的业务模型可以正确执行相应的操作。其中，绑定操作指令的格式可以为"api://apikeyxx"。通过加载了目标模型视图和相应预置组件的自定义页面、目标模型视图对应的后端API以及绑定的自定义API，可以构建得到所需业务模型，参照图13，图13示出了目标模型视图、自定义页面与自定义API的结合示意图。

不难理解的，绑定自定义API可以在一定程度上弥补模型原有的开箱即用API在灵活性上的不足，使得业务模型的开发更加灵活且可定制，且目标模型与自定义页面和自定义API的融合使得其可发挥各自优势，让模型功能更加完备。

进一步的，基于上述实施例，提出本申请业务模型建模方法的第三实施例。本实施例中，在步骤S400之后还包括步骤A100至步骤A400，用于使用OQL语言调用业务模型。参照图14，图14示出了业务模型建模方法第三实施例的流程示意图。

在本实施例中，业务模型建模方法包括以下步骤：

步骤A100，获取用户输入的操作信息。

其中，操作信息的格式为对象查询语言。

步骤A200，解析对象查询语言，获得抽象语法树。

其中，抽象语法树包括多个查询字段信息以及各查询字段信息之间的驱动关系。

步骤A300，基于多个查询字段信息以及各查询字段信息之间的驱动关系，生成至少一个结构化查询语言。

步骤A400，基于所有结构化查询语言，调用业务模型。

具体而言，应用开发者可以输入OQL(Object Query Language，对象查询语言)格式的操作信息。OQL是一种用于描述数据查询和操作的语言，通过指定查询条件和操作方式可以实现对数据的获取和处理，OQL区别于一般的SQL(Structured Query Language，结构化查询语言)，其不是直接操作数据库表的，而是直接操作业务模型的。由于OQL已经封装了与底层数据库的交互细节，故应用开发者无需知道底层数据库是关系型数据库还是非关系型数据库，能够提升模型开发效率。而AST(Abstract Syntax Tree，抽象语法树)则包括多个查询字段信息以及各查询字段信息之间的驱动关系，也即是这些查询字段之间的逻辑关系和依赖关系。通过解析开发者输入的OQL字符串，可以得到一个AST，解析提取AST上的查询字段信息，通过查询字段信息对数据进行加工处理，如计算默认值、公式以及流水号等。经过后台处理后可以基于各查询字段信息之间的驱动关系可以生成不同的SQL语句，利用生成的SQL语句可以调用业务模型，业务模型根据接收到的SQL执行相应的数据查询等操作。参照图15，图15示出了OQL转换为SQL的过程示意图。此外，用户可以在可视化的API编排界面中以OQL语句的形式来调用业务模型的数据操作能力，可以让用户直接输入和编辑OQL语句，从而实现对数据的查询和操作；或者可以通过可视化的CURD(即创建Create、更新Update、读取Read和删除Delete操作)节点配置OQL语句，来调用业务模型的数据操作能力，这种方法可以通过可视化的方式展示OQL语句的结构和参数，便于用户理解和管理。或者是可以通过直接写JS代码的方式来调用，用户可以通过编写JavaScript代码，如$oql.execute(”select...“,params)传入OQL语句和参数来调用模型的数据操作能力。这种灵活的数据操作方式可以满足不同用户的需求，提高了数据操作的便捷性和灵活性。

不难理解的，通过获取用户输入的对象查询语言，并将其解析成抽象语法树，可以更加准确地捕捉用户的查询意图。基于多个查询字段信息以及各查询字段信息之间的驱动关系，生成结构化查询语言，可以更加高效地访问数据库，从而提高业务模型的查询效率。

对应于业务模型建模方法，本申请提出了一种业务模型建模装置，如图16所示，包括：

第一确定模块，用于响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各预置模型视图具有模型配置信息以及应用程序接口信息；模型配置信息包括字段信息、字段状态信息以及显示顺序信息；

第二确定模块，用于响应于用户的第二操作，从多个页面预置组件中确定出目标页面预置组件；

自定义模块，用于将目标模型视图与目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面；

模型生成模块，用于基于加载后的自定义页面与目标模型视图的应用程序接口信息，获得业务模型。

需要说明的是，本实施例中的关于业务模型建模装置的各实施方式以及其达到的技术效果可参照前述实施例中业务模型建模方法的各种实施方式，这里不再赘述。

此外，本申请实施例还提出一种计算机存储介质，存储介质上存储有业务模型建模程序，业务模型建模程序被处理器执行时实现如上文的业务模型建模方法的步骤。因此，这里将不再进行赘述。另外，对采用相同方法的有益效果描述，也不再进行赘述。对于本申请所涉及的计算机可读存储介质实施例中未披露的技术细节，请参照本申请方法实施例的描述。确定为示例，程序指令可被部署为在一个计算设备上执行，或者在位于一个地点的多个计算设备上执行，又或者，在分布在多个地点且通过通信网络互连的多个计算设备上执行。

本领域普通技术人员可以理解实现上述实施例方法中的全部或部分流程，是可以通过计算机程序来指令相关的硬件来完成，上述的程序可存储于一计算机可读取存储介质中，该程序在执行时，可包括如上述各方法的实施例的流程。其中，上述的存储介质可为磁碟、光盘、只读存储记忆体(Read-Only Memory，ROM)或随机存储记忆体(RandomAccessMemory，RAM)等。

另外需说明的是，以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。另外，本申请提供的装置实施例附图中，模块之间的连接关系表示它们之间具有通信连接，具体可以实现为一条或多条通信总线或信号线。本领域普通技术人员在不付出创造性劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，所属领域的技术人员可以清楚地了解到本申请可借助软件加必需的通用硬件的方式来实现，当然也可以通过专用硬件包括专用集成电路、专用CPU、专用存储器、专用元器件等来实现。一般情况下，凡由计算机程序完成的功能都可以很容易地用相应的硬件来实现，而且，用来实现同一功能的具体硬件结构也可以是多种多样的，例如模拟电路、数字电路或专用电路等。但是，对本申请而言更多情况下软件程序实现是更佳的实施方式。基于这样的理解，本申请的技术方案本质上或者说对现有技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品存储在可读取的存储介质中，如计算机的软盘、U盘、移动硬盘、只读存储器(ROM，Read-OnlyMemory)、随机存取存储器(RAM，RandomAccessMemory)、磁碟或者光盘等，包括若干指令用以使得一台计算机设备(可以是个人计算机，服务器，或者网络设备等)执行本申请各个实施例的方法。

以上仅为本申请的优选实施例，并非因此限制本申请的专利范围，凡是利用本申请说明书及附图内容所作的等效结构或等效流程变换，或直接或间接运用在其他相关的技术领域，均同理包括在本申请的专利保护范围内。

Claims (10)

1.一种业务模型建模方法，其特征在于，所述方法包括：

响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各所述预置模型视图具有模型配置信息以及应用程序接口信息；所述模型配置信息包括字段信息、字段状态信息以及显示顺序信息；

响应于用户的第二操作，从多个页面预置组件中确定出目标页面预置组件；

将所述目标模型视图与所述目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面；

基于加载后的自定义页面与所述目标模型视图的应用程序接口信息，获得所述业务模型。

2.根据权利要求1所述的业务模型建模方法，其特征在于，所述预置模型视图包括表格视图或者列表视图；

所述将所述目标模型视图与所述目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面，包括：

响应于用户的第三操作，对所述目标模型视图对应的字段信息进行更新，获得更新后的目标模型视图；

将所述更新后的目标模型视图与所述目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面。

3.根据权利要求2所述的业务模型建模方法，其特征在于，所述响应于用户的第三操作，对所述目标模型视图对应的字段信息进行更新，获得更新后的目标模型视图，包括：

响应于用户的选择操作，从所述目标模型视图对应的所有预置字段信息中确定出目标字段信息，获得更新后的目标模型视图；或者

响应于用户的输入操作，向所述目标模型视图添加新的字段信息，获得更新后的目标模型视图。

4.根据权利要求1所述的业务模型建模方法，其特征在于，所述基于加载后的自定义页面与所述目标模型视图的应用程序接口信息，获得所述业务模型，包括：

确定与所述业务模型关联的关联业务模型，以及所述业务模型与所述关联业务模型之间的模型关系；其中，所述模型关系包括主子关系或查找关系；

基于加载后的自定义页面、所述目标模型视图的应用程序接口信息以及所述模型关系，获得所述业务模型。

5.根据权利要求1所述的业务模型建模方法，其特征在于，所述基于加载后的自定义页面与所述目标模型视图的应用程序接口信息，获得所述业务模型，包括：

获取用户输入的自定义应用程序接口与绑定操作指令；其中，所述绑定操作指令具有待绑定的配置信息；

将所述自定义应用程序接口与待绑定的配置信息绑定；

基于加载后的自定义页面、所述目标模型视图的应用程序接口信息以及所述自定义应用程序接口，获得所述业务模型。

6.根据权利要求5所述的业务模型建模方法，其特征在于，所述基于加载后的自定义页面与所述目标模型视图的应用程序接口信息，获得所述业务模型之后，所述方法还包括：

获取用户输入的操作信息；其中，所述操作信息的格式为对象查询语言；

解析所述对象查询语言，获得抽象语法树；其中，所述抽象语法树包括多个查询字段信息以及各查询字段信息之间的驱动关系；

基于所述多个查询字段信息以及各查询字段信息之间的驱动关系，生成至少一个结构化查询语言；

基于所有结构化查询语言，调用所述业务模型。

7.根据权利要求1至6任一项所述的业务模型建模方法，其特征在于，所述业务模型的字段信息类型以JSON数据格式描述。

8.一种业务模型建模装置，其特征在于，所述装置包括：

第一确定模块，用于响应于用户的第一操作，从多个预置模型视图中确定出目标模型视图；其中，各所述预置模型视图具有模型配置信息以及应用程序接口信息；所述模型配置信息包括字段信息、字段状态信息以及显示顺序信息；

第二确定模块，用于响应于用户的第二操作，从多个页面预置组件中确定出目标页面预置组件；

自定义模块，用于将所述目标模型视图与所述目标页面预置组件加载至自定义页面进行渲染，获得加载后的自定义页面；

模型生成模块，用于基于加载后的自定义页面与所述目标模型视图的应用程序接口信息，获得所述业务模型。

9.一种业务模型建模设备，其特征在于，包括：处理器，存储器以及存储在所述存储器中的计算机程序，所述计算机程序被所述处理器运行时实现如权利要求1至7中任一项所述业务模型建模方法的步骤。

10.一种计算机可读存储介质，其特征在于，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如权利要求1至7任一项所述的业务模型建模方法。