CN115993966B - 应用开发系统及方法 - Google Patents

Abstract

本发明涉及计算机技术领域，提供一种应用开发系统和方法，系统包括：设计态模块，用于确定获取业务需求对应的元数据模型，并通过配置对所述元数据模型进行配置，得到所述业务需求对应的应用程序；还用于，将所述应用程序发布至运行时模块；所述运行时模块，用于运行所述应用程序。本发明能够通过配置元数据模型的方式快速生成应用程序，可以适应业务需求的变化及时对元数据模型进行相应配置，避免了通过代码调整应用的繁琐步骤，提高了技术标准化能力。

Description

应用开发系统及方法

技术领域

本发明涉及计算机技术领域，尤其涉及一种应用开发系统及方法。

背景技术

传统开发模式下，技术规范和标准需要投入很大管理成本才能做到统一。在没有统一规范和通用技术组件情况下，不同开发人员交付的业务功能从风格体验以及产品细节上会存在不一致。此外，传统软件产品的开发必须依赖于开发人员，真正理解业务的人员无法直接创造产品，往往导致无法获得真正需要的业务产品。当业务需求发生变化时，原有软件应用无法继续使用，需要开发人员调整当前版本的代码，代码的调整一方面会增加开发成本、延长交付时间，另一方面又会引入新的产品缺陷。

发明内容

本发明旨在至少解决相关技术中存在的技术问题之一。为此，本发明提出一种应用开发系统，在设计态模块通过配置元数据模型的方式快速生成的应用程序，可以适应业务需求的变化及时对元数据模型进行相应配置，避免了通过代码调整应用的繁琐步骤，提高了技术标准化能力。

本发明还提出一种应用开发方法。

本发明还提出一种电子设备。

本发明还提出一种非暂态计算机可读存储介质。

根据本发明第一方面实施例的一种应用开发系统，包括：

设计态模块，用于获取业务需求对应的元数据模型，并对所述元数据模型进行配置，得到所述业务需求对应的应用程序，将所述应用程序发布至运行时模块；

所述运行时模块，用于运行所述应用程序；

所述设计态模块包括属性配置单元和操作配置单元；

所述属性配置单元，用于确定所述业务需求对应的业务领域的初始元数据模型，并基于所述业务需求对应的业务属性，配置所述初始元数据模型的模型属性；

所述操作配置单元，用于将业务需求对应的业务操作与所述初始元数据模型的模型属性进行绑定，得到所述元数据模型。

根据本发明实施例的应用开发系统，设计了设计态和运行时两个模块，设计态过程无需编码或通过少量代码就可以实现，生成的应用程序为低代码应用。而运行时通过运行设计态发布的应用程序，实现了低代码方式运行，提升了运行效率。同时，由于应用程序统一基于元数据模型进行配置，因此生成的应用程序拥有统一产品设计规范和技术规范标准，提高了技术标准化。

根据本发明的一个实施例，所述设计态模块还包括：业务插件库和绑定单元；

所述业务插件库，用于提供业务规则和校验规则，所述业务规则用于判断是否执行所述业务操作，所述校验规则用于在确定执行所述业务操作的情况下验证所述业务操作的执行结果；

所述绑定单元，用于将所述业务规则和所述校验规则均与所述元数据模型中的业务操作进行绑定，得到所述应用程序。

根据本发明的一个实施例，所述设计态模块还包括：所述设计态模块还包括：表单设计器；

所述表单设计器，用于获取所述元数据模型对应的多个表单；

所述绑定单元，具体用于将所述业务规则和所述校验规则均与所述元数据模型中的业务操作进行绑定，并对所述多个表单进行配置，得到所述应用程序。

根据本发明的一个实施例，所述表单设计器包括表单结构设计单元，所述表单设计器包括表单结构设计单元和表单生成单元；

所述表单结构设计单元，用于基于所述元数据模型的实体结构，确定对应的表单结构；

所述表单生成单元，用于基于所述表单结构生成所述表单。

根据本发明的一个实施例，所述绑定单元包括：流程设计器；

所述流程设计器，用于基于所述业务需求，确定所述多个表单之间的业务流程，并基于所述业务流程对所述多个表单进行配置。

根据本发明的一个实施例，所述流程设计器，还用于针对所述多个表单中各表单，确定所述表单对应的多个执行方之间的审批流程。

根据本发明的一个实施例，所述元数据模型设置有扩展接口，所述扩展接口用于对所述元数据模型的模型属性、所述元数据模型的实体结构、所述元数据模型的业务规则和所述元数据模型的校验规则中至少一项进行扩展。

根据本发明的一个实施例，所述运行时模块包括执行引擎；

所述执行引擎，用于基于所述应用程序的业务规则执行所述业务操作，并基于所述校验规则验证所述业务操作的执行结果。

根据本发明第二方面实施例的一种应用开发方法，所述方法应用于所述应用开发系统，所述方法包括：

设计态模块获取业务需求对应的元数据模型，并对所述元数据模型进行配置，得到所述业务需求对应的应用程序；

所述设计态模块将所述应用程序发布至运行时模块；

所述运行时模块运行所述应用程序。

根据本发明实施例的应用开发方法，设计态模块与运行时模块之间可以无需编码或通过少量代码就可以实现应用发布和应用的运行，因此生成的应用程序为低代码应用，提升了开发的效率还保证了业务需求的精准表达。同时，由于应用程序统一基于元数据模型进行配置，因此生成的应用程序拥有统一产品设计规范和技术规范标准，提高了技术标准化能力。

根据本发明第三方面实施例的一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，所述处理器执行所述程序时实现所述的应用开发方法。

根据本发明第四方面实施例的一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现所述的应用开发方法。

本发明实施例中的上述一个或多个技术方案，至少具有如下技术效果之一：由于可以通过属性配置单元配置模型属性，还可以通过操作配置单元配置业务操作。因此，针对不同领域不同的业务需求均采用可以统一的应用产品的设计规范和技术规范来创建应用，提高了技术标准化能力。同时，还减少了对于不同业务领域适配成本并提高了基础组件的复用能力。

进一步的，运行时模块可根据需要调用设计态模块的扩展接口，通过不同的需求配置不同的扩展功能，实现了交付产品的可配置功能还实现了目标业务领域内从标准产品到用户个性化产品的扩展，降低了平台的适配成本。

更进一步的，配置元数据模型的过程，利用了模型驱动设计技术，构建了低代码的可运行应用程序，由于元数据模型的模型属性可以配置，同时业务插件库的不同业务操作和业务规则也可以配置。因此，运行时模块可以对针对不同领域进行建模，得到不同领域的基础应用程序。

再进一步的，设计态模块的业务插件库可以提供海量的第三方模型配置工具，为开发者降低使用API获取数据的难度。

本发明的附加方面和优点将在下面的描述中部分给出，部分将从下面的描述中变得明显，或通过本发明的实践了解到。

附图说明

为了更清楚地说明本发明实施例或相关技术中的技术方案，下面将对实施例或相关技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本发明实施例提供的应用开发系统的结构示意图；

图2是本发明实施例提供的低代码应用开发系统的结构示意图；

图3是本发明实施例提供的业务插件库结构示意图；

图4是本发明实施例提供的应用扩展方式示意图；

图5是本发明实施例提供的应用开发方法的流程示意图；

图6是本发明实施例提供的电子设备示意图。

具体实施方式

下面结合附图和实施例对本发明的实施方式作进一步详细描述。以下实施例用于说明本发明，但不能用来限制本发明的范围。

在本发明实施例的描述中，需要说明的是，术语“第一”、“第二”、“第三”仅用于描述目的，而不能理解为指示或暗示相对重要性。参考术语“一个实施例”、“一些实施例”、“示例”、“具体示例”、或“一些示例”等的描述意指结合该实施例或示例描述的具体特征、结构、材料或者特点包含于本发明实施例的至少一个实施例或示例中。在本说明书中，对上述术语的示意性表述不必须针对的是相同的实施例或示例。而且，描述的具体特征、结构、材料或者特点可以在任一个或多个实施例或示例中以合适的方式结合。此外，在不相互矛盾的情况下，本领域的技术人员可以将本说明书中描述的不同实施例或示例以及不同实施例或示例的特征进行结合和组合。

传统产品研发模式下的工程架构下，开发人员依次编写核心代码和外围代码从而得到标准产品，在交付时会通过二次开发将标准产品进行扩展，推广至行业内部的行业产品再行交付。在产品交付过程中面临的二次开发需求相当繁杂，产品缺乏可配置能力，即便部分场景提供了可配置选项，也会由于技术栈与规范不统一，标准产品与扩展的业务领域差异大等问题，很难复用，如想实现个性化开发完全需要依赖于编码。

在这样的前提下，本发明实施例提出了一种应用开发系统，通过低代码方式提升产品力，如图1所示，本发明实施例的应用开发系统，包括：设计态模块110和运行时模块120；

设计态模块110，用于获取业务需求对应的元数据模型，并对元数据模型进行配置，得到业务需求对应的应用程序，将应用程序发布至运行时模块120；

运行时模块120，用于运行应用程序。

针对设计态模块110，需要说明的是，设计态模块通过元数据模型的固定形式实现了对产品设计规范和技术规范的统一，会在相应的业务需求下，构建目标业务领域内的应用程序，应用程序可以为任意领域内的标准应用，其应当包括领域内所有的常规功能。

作为示例的，在资产管理领域，标准应用为资产管理产品，其业务需求要求产品具备的基本功能可以包括：出库、入库、领用、使用、盘点和借用等，此时生成的应用程序为标准应用。由于设计态模块的产出标准应用具有全方面的可配置性，因此，不同业务领域的标准应用均可复用同一批基础组件，以保证不同的开发人员可以从风格体验以及产品细节对发布的应用进行一致性把控，提高了技术的标准化。

同时，在业务需求更改，例如包含特定行业需求时，生成的应用程序也可以为行业应用，不仅包括常规功能还包括特定领域中的特定功能。业务需求也可以为特定用户需求，此时的应用程序也将适应用户需求满足用户需求的特定功能。

作为示例的，设计态模块还可以根据目标业务需要，通过更改相关组件直接产出目标业务领域的行业应用。行业应用可以是生猪养殖管理产品，其是在资产管理领域的垂直拓展领域下，对标准产品按照需求的功能的进行具体扩展后得到的。

另外，需要说明的是，由于元数据模型以实体模型方式存储，同时，实体模型是后续转换为表单模型、代码模型、报表模型的基础模型，因此，设计态模块配置元数据模型，即为配置实体模型的结构和属性。其中的配置，是指将实体模型的属性绑定不同的规则，配置后的元数据模型将具备各项操作的执行规则，本实施例通过配置方便运行时在运行应用程序时，无需额外编写的流程代码，达到低代码开发目的。

针对运行时模块120，需要说明的是，设计态模块向使用者提供的应用开发平台，在应用程序生成后，设计态模块会将应用程序打包发布至运行时模块。运行时模块往往运行有客户端app，直接面向用户。用户打开运行时模块在接收到应用程序后，解析应用程序并在运行环境中以低代码方式运行该应用程序。

此外需要说明的是，设计态模块和运行时模块的运行环境可以为个人计算机、服务器计算机、手持设备或便携式设备、平板型设备、多处理器装置、包括以上任何装置或设备的分布式计算环境。

本发明实施例的应用开发系统，设计了设计态和运行时两个模块，设计态过程无需编码或通过少量代码就可以实现，生成的应用程序为低代码应用。而运行时通过运行设计态发布的应用程序，实现了低代码方式运行，提升了运行效率。同时，由于应用程序统一基于元数据模型进行配置，因此生成的应用程序拥有统一产品设计规范和技术规范标准，提高了技术标准化。

可以理解的是，设计态模块包括属性配置单元和操作配置单元；

属性配置单元，用于确定业务需求对应的业务领域的初始元数据模型，并基于业务需求对应的业务属性，配置初始元数据模型的模型属性；

操作配置单元，用于将业务需求对应的业务操作与初始元数据模型的模型属性进行绑定，得到元数据模型。

需要说明的是，设计态模块在获取到业务需求后，首先需要解析出对应的目标业务领域。初始元数据模型实际上是通过元数据模型对某一目标业务领域进行建模后，以实体模型方式存储的数据表达形式。元数据模型提供实体元数据有效性校验能力，确保标准应用和扩展应用的数据按业务要求的规则存储。由于实体模型的结构一般包括：单实体、主子实体、关联实体、实体引用等类型，领域建模时通常是一个表对应一个实体，一个主表关联多个从表，然而，主子实体模型表示需要建模的领域内包含上下级的关系，如某一业务领域内需要以主表和子表来表示数据，则在领域建模时就可以采用主子模型。

业务需求对应一个目标业务领域，同时还包括多个业务属性，每条业务属性对应至少一个业务操作。领域建模实际上是根据业务领域的特点选择实体模型的结构，然后通过属性配置单元，进一步配置领域建模后得到的初始元数据模型的各项模型属性，初始元数据模型的模型属性为标准属性，例如：

标准属性1：String；

标准属性2：Object；

标准属性3：int。

基于业务需求对应的业务属性，可以增删标准属性的数量，还可以对标准属性进行业务属性的命名和描述字段的更改。例如，对于差旅费报销的初始元数据模型，属性单元配置后，模型属性可以包括：

姓名：String；

部门：引用；

授权人：String；

提交日期：Date；

每英里补贴：Money；

总报销费用：Money；

时长：String。

此外，需要说明的是，操作配置单元的主要功能是将初始元数据模型的模型属性与业务需求对应的业务操作进行绑定，业务操作中基础业务操作可以包括新增、修改、查询和删除操作，除此之外，还可以是特定行业的业务领域内的通用操作，例如费用管理领域的审批操作。对每个模型属性绑定业务操作后，每个业务属性都具备可配置可扩展的能力。

本发明实施例的应用开发系统，通过在元数据模型中设计了属性配置单元和操作配置单元，可以将不同业务领域的业务需求拆分为业务领域、业务属性和业务操作，并基于两个配置单元分别配置模型属性并绑定模型属性的不同操作。通过这种方式建立得到的元数据模型从模型结构、模型属性以及业务操作三个层面上均满足业务需求，实现了针对变化的业务需求的精准建模。同时，基于元数据模型的结构，配置出的元数据模型了具备统一的设计规范和技术规范，提升应用的标准化。

可以理解的是，业务插件库和绑定单元；

业务插件库，用于提供业务规则和校验规则，业务规则用于判断是否执行业务操作，校验规则用于在确定执行业务操作的情况下验证业务操作的执行结果；

绑定单元，用于将业务规则和校验规则均与元数据模型中的业务操作进行绑定，得到应用程序。

需要说明的是，业务插件库存储了多种业务插件和业务组件，业务插件或业务组件的组合对应了不同业务需求的业务规则和校验规则。插件库中包含通用插件、行业插件和客户定制插件。如图3所示，业务规则由插件i和插件i+1组成，校验规则由插件j和插件j+1组成，组成的插件数量和种类不限。通过丰富的业务插件可以组合出各种形式的业务规则和校验规则，从而保证了业务规则和业务校验的个性化。例如费用管理领域的行业插件就包括预算余额校验规则和余额占用校验规则，用于计算余额后与设定标准进行比较。同时，业务插件库可以支持外部调用，丰富了访问来源。

业务规则是每个业务操作的触发的前置条件，每条业务规则同时规定了业务操作执行后的产生的结果，其可以定义为如何执行一个业务操作。而校验规则用于验证每个业务操作执行后产生的执行结果，其可以定义为如何验证一个业务操作的正确性。校验规则通常采用加减乘除和函数等方式来验证，因此，设计态模块还需要集成公式编辑器支持校验规则的定义。

绑定单元在绑定时不会绑定业务插件库中的所有插件，其会对业务需求进行分析后，解析得到业务需求的各项业务功能，这些业务功能往往由不同业务属性和业务属性对应的业务操作组成。把所需规则与解析出的所需业务操作进行绑定，例如，将审批操作和预算余额校验规则和余额占用校验规则进行绑定，丰富了审批操作的功能。

本发明实施例的应用开发系统，开发人员可以在设计态对元数据模型进行规则方面的全面配置，业务规则和校验规则的存在保证了每项业务操作执行的准确性和安全性。业务插件库的存在也减轻了开发人员在同一标准下的应用开发的额外配置规则的工作。

可以理解的是，设计态模块还包括：表单设计器；

表单设计器，用于获取元数据模型对应的多个表单；

绑定单元，具体用于将业务规则和校验规则均与元数据模型中的业务操作进行绑定，并对多个表单进行配置，得到应用程序。

需要说明的是，在进行产品设计之前，需要由开发人员根据目标业务领域的行业规则或特定行业或用户的交付需求，这些交付需求往往是通过表单数据的形式展现的，其中包括所有想要后期产品实现的功能。鉴于表单是应用程序的常用展现形式的特点，本发明实施例将会通过表单设计器，将元数据模型转化为表单的形式，并通过配置表单实现应用程序的生成。

在进行元数据模型到表单的转化时，需要根据元数据模型拆分出的实体和属性与表单进行一一对应，使得表单中的包含的业务属性和元数据模型的模型属性形成对应关系，表单的结构与实体结构形成对应关系。此外，虽然转化为表单，但是在设计态中应用程序的底层逻辑仍以元数据模型的结构进行存储，因此对于表单的配置与元数据模型的配置方法相同。业务规则、校验规则和业务操作也都可以绑定至表单的业务属性中。

可以理解的是，表单设计器包括表单结构设计单元和表单生成单元；

表单结构设计单元，用于基于元数据模型的实体结构，确定对应的表单结构；

表单生成单元，用于基于表单结构生成表单。

需要说明的是，表单结构设计单元能结合元数据模型的实体结构来确定表单结构，并通过模型属性确定表单的描述项。作为示例的，元数据模型为主子实体结构时，转化后的表单为主子表结构。在人资管理领域，需要构建人员信息表作为主表，在人员信息表下还可以构建人员履历表和薪酬明细表作为子表。该三张表单即可构成人资管理应用。进而，通过表单生成单元，实现转化后的表单的输出。

此外，需要说明的是，表单设计器还可以包括可视化设计器、表单渲染引擎和模型树，可视化设计器可以通过拖动方式调用业务插件库进行业务规则和校验规则的绑定，表单渲染引擎用于对表单进行排版，模型树用于将表单与元数据模型进行绑定。可视化设计器是一种可视化表单设计工具，可以拖动模型组件展现在表单上，并通过版式和UI组件规范化界面交互和展示。模型树中存储有不同行业不同业务领域内的标准产品和行业产品等对应的元数据模型。

本发明实施例的应用开发系统，通过将元数据模型转化为表单后再进行应用发布，可以适用于更广泛的应用领域以及业务环境中。通过表单，可以很直观的看到各项业务属性。因此，通过表单进行的应用发布有利于后续用户对应用程序的使用，甚至有利于用户对应用程序进行下一步的扩展。

可以理解的是，绑定单元包括：流程设计器；

流程设计器，用于基于业务需求，确定多个表单之间的业务流程，并基于业务流程对多个表单进行配置。

需要说明的是，流程设计器可以通过调用业务插件库的丰富业务插件，按照一定的顺序对不同的业务插件进行组合，形成不同的流程。不同的业务需求对应的业务流程可能有一个或多个插件实现。业务流程是基于企业真实要求确定的工作流程，需要结合执行不同业务功能时业务操作的先后执行流程进行业务编排，表单根据具体的业务需求数量可能为一张，也可能为多张。而业务流程的每一个步骤将会至少对应一张表单。业务流程是指对于对业务功能对应的不同表单的调用流程。

作为示例的，在资产管理领域构建的应用程序中，业务流程可至少包括如下流程：购买、入库、资产申请、抵押、捐赠和应收应付。其中，购买这一业务功能可能会对应一张采购单，入库这一业务功能可能对应一张入库单，通过定义业务流程，可以将每个业务功能对应的表单之间按照次序进行连接，使得生成的应用程序会更加贴近企业的生产实践活动。

此外，可以理解的是，流程设计器，还用于针对多个表单中各表单，确定表单对应的多个执行方之间的审批流程。

需要说明的是，表单在使用时，对其进行操作的业务人员即为执行方，通过定义审批流程，可以确定每张表单在执行需要哪些人员进行审批，该审批的先后可以按照跨岗位、跨职级或其他的审批顺序定义。审批结果可能会影响校验规则或者业务规则的执行。

作为示例的，在人力资源管理领域构建的应用程序中，对于人员招聘表单，审批流程可能会包括以下岗位之间的审批流程，如助理、专员、主管、经理和总监。审批流程的每一步对应一个执行方，审批后会得到当前执行方的审批状态。表单上可以显示整个审批流程，以及当前的审批状态。

可以理解的是，元数据模型设置有扩展接口，扩展接口用于对元数据模型的模型属性、元数据模型的实体结构、元数据模型的业务规则和元数据模型的校验规则中至少一项进行扩展。

需要说明的是，对于某一标准应用或行业应用，在用户对交付产品有不同的需求时，为了摆脱现有升级方法必须依赖于源代码的二次开发，本发明实施例对用户的业务需求进行分析后，可以将需求转化为对应用程序的不同组件的扩展更新。该过程是可以是对标准应用进行的扩展，也可以是对行业应用的扩展。为了保证每个业务领域的标准应用不受扩展的影响，只有从扩展应用进入元数据模型页即调用扩展接口，才能对元数据模型进行扩展。

如图4所示，扩展前应用为一个标准模型，其中包含一个主表和一个子表，主表为人员表，其中包含标准属性1：String；标准属性2：引用；标准属性3：int。子表为人员履历表，其中包含标准属性1：String；标准属性2：引用；标准属性3：int。经过扩展接口进行扩展后，扩展模型包含一个主表两个子表，主表为人员表，其中包含标准属性1：String；标准属性4：String；标准属性2：int。子表1为人员履历表，其中包含标准属性1：String；标准属性2：Object；标准属性3：int；标准属性4：String。子表2为薪酬明细表，其中包含属性1：String；属性2：int；标准属性3：int。

从扩展前应用到扩展后应用的过程，包括三个方面的扩展，第一是在人员履历表子表下增加了扩展属性4，第二是在扩展应用中增加了薪酬明细表，第三是在人员表中对其中包含的模型属性进行了增删和修改。其中，扩展属性4的扩展、模型属性的增删和修改都属于模型属性的扩展，而薪酬明细表的扩展属于模型实体结构的扩展，即从主子形式扩展为主子子形式。通过扩展接口对元数据模型的模型属性进行扩展时，可以通过扩展子实体或扩展描述字段的方式，需要将所有扩展后的修改差量化单独存储。

此外，还需要说明的是业务插件库中的插件也可以支持扩展，插件扩展可直接调用外部数据库，还可以通过在运行时自建实现插件扩展。运行时模块配置有插件开发基础jar包，用户可以基于该jar扩展开发满足业务需求的插件。自建的插件扩展包括以下阶段：1）开发阶段，包括：创建一个插件开发的java工程，引入插件开发基础jar包，新增插件类和继承插件接口，调用基础插件方法编写插件逻辑。2）打包阶段，打包项目jar包。3）上传阶段，上传jar包到业务插件库中指定的类加载目录。4）注册阶段：在业务插件库注册插件类路径。5）使用阶段：用户在运行时模块重启插件微服务，用户触发业务操作后，遵循双亲委派机制，通过自定义类加载器加载注册在该业务操作上的插件。插件加载时，优先加载行业应用插件；行业应用插件未加载到指定类时，再加载标准应用插件。

基于业务插件库的插件扩展，由于业务规则和校验规则是调用业务插件库中插件或组件确立的，因此，在新的业务需求下，如有新的业务操作产生，也可通过扩展接口调用业务插件库组成新的业务规则和校验规则，实现二者的扩展。

具体的，元数据模型进行字段扩展时，扩展字段和标准字段都记录在t_model表中。t_model表增加一个字段project_version用于记录该字段属于哪级扩展应用。扩展元数据模型时，需绑定扩展表。实现元数据生成表前，需在界面上选择业务数据库的表进行绑定。实现元数据生成表后，可以自动生成扩展表。扩展表名为：“标准表名”+“_ext”。在t_model表增加一个字段ext_table_name记录该扩展表名。从不同扩展级别的应用进入同一元数据模型，看到的字段数会不同。如果当前应用扩展级别为A，则加载字段会加载project_version<=A的所有字段。元数据模型的标准字段在运行时的数据，用标准表存储。元数据模型的扩展字段在运行时的数据，用扩展表进行存储。标准表的每一行数据都和扩展表的数据一一对应，且对应行的主键ID相等。假设当前应用扩展级别为A，运行时可操作的字段为project_version<=A的所有字段。

本发明实施例的应用开发系统，运行时模块可根据需要调用设计态模块的扩展接口，通过不同的需求配置不同的扩展功能，使得业务人员或用户自行配置产品，无需开发人员介入即可实现产品多维可配置，进而实现了对于多渠道的推广交付。实现了交付产品的可配置功能还实现了目标业务领域内从标准产品到用户个性化产品的扩展，降低了平台的适配成本。

可以理解的是，运行时模块包括执行引擎；

执行引擎，用于基于应用程序的业务规则执行业务操作，并基于校验规则验证业务操作的执行结果。

需要说明的是，应用发布后会将设计态配置的最新版本的应用程序发布到运行时环境，此时需要在运行时模块配置运行时环境，以及运行时环境设置的发布主数据源链接地址、发布备份数据源的链接地址、缓存清除外链地址。上述配置完成后，再调用执行引擎，运行应用程序。由于应用程序封装了业务规则和校验，因此，在运行时，执行引擎会根据编排，逐步执行校验规则和业务规则，以保证执行应用的完整性和安全性。

运行时模块还包括，元数据访问接口和业务操作访问接口，这两个接口属于L查询接口，开发人员可以通过该接口设定过滤条件来查询指定应用程序对应元数据模型的不同模型编码数据表的业务数据。

可以理解的是，设计态模块包括设计态数据库，运行时模块包括设计态数据库。

需要说明的是，在配置应用程序的同时，可以将配置应用程序过程中的配置数据存储至设计态数据库，然后根据应用程序的运行需求，将设计态数据库中的部分配置数据发布至运行时数据库。通过这种方式，设计态实现了和运行时的解耦。相比传统方式中运行时会直接访问设计态的配置数据，本发明中运行时访问自身的运行时数据库，实现了设计态和运行时的解绑，支持设计态和运行时工作在不同的目标环境中。同时，由于运行时数据库中存储的是设计态数据库发送的基于配置完成标识的配置数据，因此运行时不会受到未配置完成的数据的影响，提高了运行应用的可靠性。

具体的，在数据库中，数据均以应用信息表形式存储，扩展后在应用信息表中增加一个字段project_version，用于表示应用不同的扩展版本。标准应用该字段值为0。每扩展一次该字段值增加一。每扩展一次应用就会在应用信息表中增加一条记录。主键id由系统生成一个新的id，而标准应用和扩展应用的project_code值相等。project_name是由用户在界面输入，各扩展应用该值是不相同的。对于标准应用和扩展应用，其他字段的值是相等的。

如图2所示，本发明实施例公开了一种低代码应用开发系统，包括设计态模块110和运行时模块120，该系统可以通过元数据模型驱动实现动态建模和分层扩展，具有高可用和弹性扩展的能力。具体的，设计态模块通过元数据模型配置元数据模型，并再次基础上通过业务插件库绑定对应的业务插件后送入表单设计器，将元数据模型转化为表单后，通过流程设计器增添业务流程和审批流程最终得到应用程序。设计态模块通过应用发布将构建好的应用程序发送给运行时。运行时模块通过执行引擎，依据应用程序执行业务逻辑下的业务操作。

本发明实施例的低代码应用开发系统，由于表单形式展现的应用程序实际为元数据模型，因此可通过模型属性扩展，支持业务属性可扩展；还可通过扩展业务插件库支持业务规则和校验规则可扩展；通过在元数据模型扩展新的业务操作，并绑定满足业务需求的业务服务API，来支持业务操作可扩展。因此，本实施例基于元数据模型进行配置，因此生成的应用程序拥有全方面的可配置能力，有效提高不同业务需求的落地率，也减少了开发系统的适配成本。

如图3所示，为本发明实施例提供的一种应用扩展方式，对新增扩展的基础应用，需要在扩展后的模型进行模型扩展中，本发明实施例的扩展方式会将所有修改差量化单独存储，扩展不影响基础应用的标准模型。例如扩展实体存储在新表中，扩展字段可以存储在扩展前同表或单独存储在扩展表中。

如图5所示，本发明实施例还公开了一种应用开发方法，该方法应用于应用开发系统，至少包括如下步骤：

步骤201、设计态模块获取业务需求对应的元数据模型，并对元数据模型进行配置，得到业务需求对应的应用程序；

步骤202、设计态模块将应用程序发布至运行时模块；

步骤203、运行时模块运行应用程序。

本发明实施例的应用开发方法，设计态模块与运行时模块之间可以无需编码或通过少量代码就可以实现应用发布和应用的运行，因此生成的应用程序为低代码应用，提升了开发的效率还保证了业务需求的精准表达。同时，由于应用程序统一基于元数据模型进行配置，因此生成的应用程序拥有统一产品设计规范和技术规范标准，提高了技术标准化能力。

图6示例了一种电子设备的实体结构示意图，如图6所示，该电子设备可以包括：处理器(processor)610、通信接口(Communications Interface)620、存储器(memory)630和通信总线640，其中，处理器610，通信接口620，存储器630通过通信总线640完成相互间的通信。处理器610可以调用存储器630中的逻辑指令，以执行如下方法：

设计态模块获取业务需求对应的元数据模型，并对元数据模型进行配置，得到业务需求对应的应用程序；

设计态模块将应用程序发布至运行时模块；

运行时模块运行应用程序。

此外，上述的存储器630中的逻辑指令可以通过软件功能单元的形式实现并作为独立的产品销售或使用时，可以存储在一个计算机可读取存储介质中。基于这样的理解，本发明的技术方案本质上或者说对相关技术做出贡献的部分或者该技术方案的部分可以以软件产品的形式体现出来，该计算机软件产品存储在一个存储介质中，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行本发明各个实施例方法的全部或部分步骤。而前述的存储介质包括：U盘、移动硬盘、只读存储器（ROM，Read-Only Memory）、随机存取存储器（RAM，Random Access Memory）、磁碟或者光盘等各种可以存储程序代码的介质。

另一方面，本发明实施例公开一种计算机程序产品，计算机程序产品包括存储在非暂态计算机可读存储介质上的计算机程序，计算机程序包括程序指令，当程序指令被计算机执行时，计算机能够执行上述各方法实施例所提供的方法，例如包括：

设计态模块获取业务需求对应的元数据模型，并对元数据模型进行配置，得到业务需求对应的应用程序；

设计态模块将应用程序发布至运行时模块；

运行时模块运行应用程序。

又一方面，本发明实施例还提供一种非暂态计算机可读存储介质，其上存储有计算机程序，该计算机程序被处理器执行时实现以执行上述各实施例提供的传输方法，例如包括：

设计态模块获取业务需求对应的元数据模型，并对元数据模型进行配置，得到业务需求对应的应用程序；

设计态模块将应用程序发布至运行时模块；

运行时模块运行应用程序。

以上所描述的装置实施例仅仅是示意性的，其中作为分离部件说明的单元可以是或者也可以不是物理上分开的，作为单元显示的部件可以是或者也可以不是物理单元，即可以位于一个地方，或者也可以分布到多个网络单元上。可以根据实际的需要选择其中的部分或者全部模块来实现本实施例方案的目的。本领域普通技术人员在不付出创造性的劳动的情况下，即可以理解并实施。

通过以上的实施方式的描述，本领域的技术人员可以清楚地了解到各实施方式可借助软件加必需的通用硬件平台的方式来实现，当然也可以通过硬件。基于这样的理解，上述技术方案本质上或者说对相关技术做出贡献的部分可以以软件产品的形式体现出来，该计算机软件产品可以存储在计算机可读存储介质中，如ROM/RAM、磁碟、光盘等，包括若干指令用以使得一台计算机设备（可以是个人计算机，服务器，或者网络设备等）执行各个实施例或者实施例的某些部分的方法。

最后应说明的是，以上实施方式仅用于说明本发明，而非对本发明的限制。尽管参照实施例对本发明进行了详细说明，本领域的普通技术人员应当理解，对本发明的技术方案进行各种组合、修改或者等同替换，都不脱离本发明技术方案的精神和范围，均应涵盖在本发明的范围中。

Claims (5)

1.一种应用开发系统，其特征在于，包括：

设计态模块，用于获取业务需求对应的元数据模型，并对所述元数据模型进行配置，得到所述业务需求对应的应用程序，将所述应用程序发布至运行时模块；

所述运行时模块，用于运行所述应用程序；

所述设计态模块包括属性配置单元、操作配置单元、业务插件库、绑定单元和表单设计器；

所述属性配置单元，用于确定所述业务需求对应的业务领域的初始元数据模型，并基于所述业务需求对应的业务属性，配置所述初始元数据模型的模型属性；其中，所述初始元数据模型是对目标业务领域进行建模后，以实体模型方式存储的数据表达形式；

所述操作配置单元，用于将业务需求对应的业务操作与所述初始元数据模型的模型属性进行绑定，得到所述元数据模型；

所述业务插件库，用于提供业务规则和校验规则，所述业务规则用于判断是否执行所述业务操作，所述校验规则用于在确定执行所述业务操作的情况下采用加减乘除和函数的方式验证所述业务操作的执行结果；

所述表单设计器，用于获取所述元数据模型对应的多个表单；

所述绑定单元，具体用于将所述业务规则和所述校验规则均与所述元数据模型中的业务操作进行绑定，并对所述多个表单进行配置，得到所述应用程序；

所述绑定单元包括：流程设计器；

所述流程设计器，用于基于所述业务需求，确定所述多个表单之间的业务流程，并基于所述业务流程对所述多个表单进行配置；

所述流程设计器，还用于针对所述多个表单中各表单，确定所述表单对应的多个执行方之间的审批流程；

所述元数据模型设置有扩展接口，所述扩展接口用于对所述元数据模型的模型属性、所述元数据模型的实体结构、所述元数据模型的业务规则和所述元数据模型的校验规则中至少一项进行扩展；

所述运行时模块包括执行引擎；

所述执行引擎，用于基于所述应用程序的业务规则执行所述业务操作，并基于所述校验规则验证所述业务操作的执行结果。

2.根据权利要求1所述的应用开发系统，其特征在于，所述表单设计器包括表单结构设计单元和表单生成单元；

所述表单结构设计单元，用于基于所述元数据模型的实体结构，确定对应的表单结构；

所述表单生成单元，用于基于所述表单结构生成所述表单。

3.一种应用开发方法，其特征在于，所述方法应用于如权利要求1或2所述应用开发系统，所述方法包括：

设计态模块获取业务需求对应的元数据模型，并对所述元数据模型进行配置，得到所述业务需求对应的应用程序；

所述设计态模块将所述应用程序发布至运行时模块；

所述运行时模块运行所述应用程序；

所述获取业务需求对应的元数据模型，包括：

确定所述业务需求对应的业务领域的初始元数据模型，并基于所述业务需求对应的业务属性，配置所述初始元数据模型的模型属性；其中，所述初始元数据模型是对目标业务领域进行建模后，以实体模型方式存储的数据表达形式；

将业务需求对应的业务操作与所述初始元数据模型的模型属性进行绑定，得到所述元数据模型；其中，所述元数据模型设置有扩展接口，所述扩展接口用于对所述元数据模型的模型属性、所述元数据模型的实体结构、所述元数据模型的业务规则和所述元数据模型的校验规则中至少一项进行扩展；

获取所述元数据模型对应的多个表单；

将业务规则和校验规则均与所述元数据模型中的业务操作进行绑定，并对所述多个表单进行配置，得到所述应用程序；其中，所述业务规则用于判断是否执行所述业务操作，所述校验规则用于在确定执行所述业务操作的情况下采用加减乘除和函数的方式验证所述业务操作的执行结果；所述对所述多个表单进行配置，包括：基于所述业务需求，确定所述多个表单之间的业务流程，并基于所述业务流程对所述多个表单进行配置；以及针对所述多个表单中各表单，确定所述表单对应的多个执行方之间的审批流程；

所述运行时模块运行所述应用程序，包括：

基于所述应用程序的业务规则执行所述业务操作，并基于所述校验规则验证所述业务操作的执行结果。

4.一种电子设备，包括存储器、处理器及存储在存储器上并可在处理器上运行的计算机程序，其特征在于，所述处理器执行所述程序时实现如权利要求3所述的应用开发方法。

5.一种非暂态计算机可读存储介质，其上存储有计算机程序，其特征在于，该计算机程序被处理器执行时实现如权利要求3所述的应用开发方法。

Images