CN103455324A - 一种用于业务开发流程的模型 - Google Patents

Abstract

本申请提供一种基于业务流程开发的模型，包括：业务逻辑模块，用于存储业务逻辑的定义；业务流程模块，用于存储业务流程的定义。

Description

一种用于业务开发流程的模型

技术领域

本发明涉及计算机业务平台开发技术，更具体地，涉及一种用于业务开发流程的模型。

背景技术

现在的管理软件是将管理软件运行程序与所处理的业务逻辑一起编写，然后编译成为一种可执行的方式固定下来。从形态构成上来说，无论是早期面向过程的开发和面向对象开发，还是目前面向组件或构件化的开发方法，都是直接基于某种技术平台，通过对代码的层层提炼和封装，来描述企业业务，并被打包成为一个应用软件产品，形成一个“黑盒”。一旦企业业务发生变化需要调整，就会遇到重重困难。即使拥有应用的源代码，也难以实现灵活调整和扩展。

在现有管理软件的“黑盒”模式下，业务调整导致必须从底层对现有代码或者组件化的代码段进行调整。无论是使用何种先进的程序设计方法、还是使用各种流程建模、UML建模和数据建模工具，或者通过软件能力成熟度测试，都无法回避这一问题。不同方法的差别仅仅在于，通过付出更高昂的成本和代价，换取在效率方面的有限提升，最终构建出来的***仍然是刚性的***，无法从根本上解决业务***灵活调整的难题。无论是专业的软件厂商还是最终用户，都很容易陷入软件开发维护的泥潭。

现有管理软件，一部分虽然提供了部分二次开发支持，但都局限在某些资源和参数的简单修改，或者只是局部的一些定制能力，如报表定义工具、权限分配等，但这些部分相互割裂，不成体系，仍然无法有效解决信息***灵活调整的问题。导致经常需要打破、甚至抛弃原有的信息***，完全重新构建才能满足实际应用需要。

发明内容

为克服现有的缺陷，本发明提出一种用于业务开发流程的模型。

根据本发明的一个方面，提出了一种基于业务开发的的应用模型，包括：业务逻辑模块，用于存储业务逻辑的定义；业务流程模块，用于存储业务流程的定义。

其中，业务逻辑模块用于编写业务逻辑，包括：

动作子模块，用于定义动作和程序；代码子模块，用于业务逻辑的实现；函数子模块，用于函数定义。

其中，业务流程模块包括业务流程定义、业务流程运行和业务流程实例；其中，业务流程定义用于描述业务流程的整个过程和各种规则；业务流程运行的核心是业务流程引擎，用于解析业务流程定义，推进业务流程的运行；业务流程实例，是业务流程运行的结果；其中，一个业务流程定义被运行一次就产生一个业务流程实例。

其中，业务流程定义用于描述企业实现一个业务目标需要包含的环节步骤，各环节步骤间前后顺序和同步关系，各步骤由谁来处理的信息；其中，步骤对应业务环节，顺序关系由连接弧定义，处理人对应执行者，处理要求对应到处理规则。

其中，业务环节用于描述业务流程中需要人为参与的处理、自动的处理和业务流程中路径的选择、分支和合并。

其中，业务流程运行用于实现各种业务流程的业务动作，是基于PetriNet原理的业务流程引擎；其中，从体系结构上来说业务流程引擎和业务动作是没有关联。

其中，业务流程引擎用于实现解析和计算业务流程定义，生成过程控制ProcessControl；还用于根据过程控制实现实际的业务流程操作，并生成业务流程实例数据且存入数据库。

其中，业务流程实例包括流程实例和每个活动环节的任务两部分的数据；其中，流程实例是每次启动流程生成一个，而活动环节的任务则是每次流转、回退和转发时都会为流向活动环节生成的。

本发明通过将业务模型资源与***实现技术分离，从根本上提升管理***的技术无关性。业务资源是随用户需求而变动的最频繁的部分，通过分离业务与实现部分，可以做到业务资源变动时，不影响底层的实现技术，无需重新配置或升级运行环境。而运行环境的独立，则可以保证应用能够跨实现技术，运行在不同的***之上，可以随时零成本迁移到新的实现技术上。

附图说明

图1所示为对应的业务流程模块的运行图。

具体实施方式

下面结合附图和具体实施例对本发明提供的一种用于业务开发的模型进行详细描述。

在以下的描述中，将描述本发明的多个不同的方面，然而，对于本领域内的普通技术人员而言，可以仅仅利用本发明的一些或者全部结构或者流程来实施本发明。为了解释的明确性而言，阐述了特定的数目、配置和顺序，但是很明显，在没有这些特定细节的情况下也可以实施本发明。在其他情况下，为了不混淆本发明，对于一些众所周知的特征将不再进行详细阐述。

模型是人们了为方便研究、理解和解决客观事件中存在的种种问题而对客观现实经过反复思维抽象后的文字、图标、符号、关系式以及实体模样描述的集合，以描述所认识到的客观事物的一种直观表现形式。

业务模型是从企业信息化的需要出发，针对企业的业务和管理所做的一种体系性抽象和描述，业务模型体系为信息***的设计和开发提供科学、合理的导向和依据。

业务建模就是基于企业工程理论和业务模型体系，来分析、设计、开发和维护信息***。业务建模的过程，是从业务和管理的现实和知识出发，依据和参照业务模型体系，采用业务建模工具，设计并构建出相关的业务模型资源，业务模型资源是业务建模的主要产品。

本申请的业务应用模型包括：业务逻辑模块，用于存储业务逻辑的定义；业务流程模块，用于存储业务流程的定义。

其中，业务逻辑模块用于编写业务逻辑，一般包含三个子模块：action（定义action和procedure）、code（业务逻辑的实现，一般使用java实现，有src，dsrc，lib）和fn（函数定义）。

本申请的业务流程是基于PetriNet原理的业务流程定义和运行体系，PetriNet是当今被广泛应用于业务流程描述和运行算法的理论体系。在PetriNet中只有三个基本元素，它们分别是Place（容器），Activity（处理）和Token（令牌），PetriNet的基础原则都是围绕这三个元素定义的，它们分别是：Place是用来存放Token的；Activity用来消耗其输入Place中的Token，并且给它的输出的Place产生新Token；Activity和Activity不能直接互连接的，只能通过Place互连。Activity激活的条件是其输入的所有Place中都有Token。一个Token被一个Activity消耗以后就没了，不能再被消耗。

虽然本申请的的业务流程体系是基于PetriNet原理的，但由于业务模型层封装的原因，在实际的业务流程建模过程中并不会太多接触到底层PetriNet的东西。所以在这里就不再对PetriNet做详细描述了，具体PetriNet的详细信息请参阅与PetriNet相关的专业文档。

图1所示为对应的业务流程模块的运行图。业务流程本质上就是把业务表单在人之间传来传去，负责传送业务表单并且通知对方进行处理的媒介途径是待办任务。所以业务流程体系中待办任务是核心基础，无论是业务流程还是协同只要牵扯到业务表单在人之间的传递都要依赖待办任务。基于以上的理解和考虑，业务流程体系是以待办任务为核心，结合业务流程与协同于一身的业务流程体系。

其中，业务流程模块分为三部分，它们分别是业务流程定义，业务流程运行和业务流程实例（业务流程控制数据）。业务流程定义描述业务流程的整个过程和各种规则，从使用上说画的流程图和设置的流程规则就是业务流程定义。业务流程运行的核心是业务流程引擎，它解析业务流程定义，推进业务流程的运行，运行的结果就是业务流程实例。一个业务流程定义被运行一次就产生一个业务流程实例，在业务流程实例中包含若干待办任务。

其中，业务流程定义描述的是企业实现一个业务目标（业务审批）需要包含多少个环节步骤，各环节步骤间前后顺序和同步关系，各步骤由谁来处理等信息。抽象到业务模型上，步骤对应业务环节，顺序关系由连接弧定义，处理人对应执行者，处理要求对应到处理规则，所以业务流程定义是由环节，处理规则和连接弧组成。

业务过程中画在流程图上的业务环节，将以业务流程的方式使用待办任务作为入口来运行。此类业务环节需要在执行者收到待办任务以后，通过打开处理待办任务才可以运行业务环节。业务流程定义特指此类业务环节的定义，在业务过程中包含的没被画在流程图上的业务环节都是静态的业务环节，它们不包含在业务流程定义的范畴内。

其中，业务流程环节是业务流程里最基本最重要的组成元素，它描述业务流程中需要人为参与的处理，自动的处理和业务流程中路径的选择，分支和合并等。需要注意的是，所有业务流程环节定义的各种规则和条件都只有在业务流程执行讯问动作的时候起作用。

其中，业务流程规则定义业务流程的执行者，各种操作的处理选项和通知等信息。为了支持复杂业务流程，所有业务流程规则都是可以设置多条的，在业务流程运行的时候根据设置的生效条件和规则的排列顺序计算出唯一的一条生效的规则。也就是说相同类型的业务流程规则在同一时刻只有唯一的一条可以生效。

业务流程规则的计算一般都在调用讯问相关的业务动作时计算，计算时根据业务流程规则定义的顺序一条一条的计算，当找到一条可以生效就不再往下计算了。业务流程规则包括如下的多个示例规则。

启动规则

启动规则是定义在业务流程上的当调用startProcessQueryAction动作启动业务流程时，为业务流程实例数据做初始化的规则定义。在启动规则里一般做一些流程实例的标题，限制时间的初始化，但是其实启动规则可以对业务流程实例所属的概念SA_Task的所有关系赋值。启动规则只有在调用startProcessQueryAction时生效，而以后流程运行中就不再起作用了。所以当业务流程运行中业务数据值发生改变时这里是不会自动跟着变的，而只能写代码主动去刷新。

通知规则

通知规则用于当业务流程在运行的过程中做了某个操作而需要通知有关人时。通知规则里定义通知接收人，接收人的处理方式等信息。当通知规则定义于业务流程自身上时是根据一些业务流程级别的操作生效，而当通知规则定义于活动环节上是就根据活动环节级别的一些操作来生效。

执行规则

执行规则用于定义活动环节的执行者，执行者可选范围，待办任务属性和处理方式等信息。执行规则是在其他环节做流转动作（且只有在做流转动作）流入当前活动环节时起作用的，在给当前活动环节计算执行者且生成了待办任务以后执行规则就不再起作用了。

流转规则

业务流程运行中当某个活动环节处理完毕以后要流到下一步去，即为流转。顾名思义流转规则就是在当前活动环节做流转操作时生效的规则，这来的流转操作指的是advanceProcessQueryAction动作。它定义的是当前活动环节调用advanceProcessQueryAction动作时的一些选项，例如是否需要弹出流转对话框等。需要注意的是，流转到下一步是哪些环节和是哪些执行者则由环节间的关系和下一步活动环节的执行规则来定的。

回退规则

业务流程运行中在某个活动环节由于某种原因不能继续发流到下一步，而需要发回给上一步重新处理既为回退。顾名思义流转规则就是在当前活动环节做回退操作时生效的规则，这里的回退操作指的是backProcessQueryAction动作。它定义的是当前活动环节调用backProcessQueryAction动作时的一些选项，例如是否需要弹出流转对话框等。需要注意的是，回退操作是把待办任务再发给曾经经过的活动环节，所以给曾经经过的活动环节生成新的待办任务的依据不再是这些活动环节上定义的执行规则，而是这些活动环节当初用来流转的待办任务。曾经的待办任务由谁处理就把新待办任务发给谁，并且执行模式，抢占模式等一些属性都从旧待办任务上直接拷贝到新待办任务里的。

转发规则

业务流程运行中某个活动环节的执行者无法决定要怎么处理，或者需要先把待办任务发给其他人看看然后再做处理即为转发。转发规则就是在当前活动环节做转发操作时生效的规则，这里的转发操作指的是transferTaskQueryAction动作。它定义的是当前活动环节调用transferTaskQueryAction动作时的一些选项，例如是否需要弹出流转对话框等。转发和流转区别在于，流转是把待办任务发给了下一步活动环节的执行者，业务流程的当前活动环节和执行者都变了。而转发虽然也把待办任务流给了其他执行者，但是业务流程的当前活动环节没有发生改变。转发规则的属性配置和执行规则一摸一样，所以转发规则的详细信息请参考执行规则的详细信息。详见。

合并规则

合并规则是定义在AND合并上用来描述AND合并的多个输入之间的关系的。合并规则是在所有直接输入到AND合并的活动环节中，只要任意活动环节做流转操作时它都会起作用。

分支规则

合并规则是定义在AND分支上用来定义AND分支的多个输出之间的关系的。分支规则是在AND分支前的活动环节做流转操作时起作用的。例如某个活动环节后的AND分支后有3个活动环节，在此活动环节流转时想要做到其中2个活动环节是必须选择的，剩下1个活动环节是否选择由用户自己定。在分支规则中描述，用户自己决定的活动环节为可选输出，剩下就是必选输出了。

其中，对于业务流程执行者，业务流程从本质上说其实就是待办任务在不同人之间按照既定的顺序和规则间传来传去，所以业务流程是否能和组织机构紧密结合是衡量业务流程是否可用的一大标准。

业务流程通过组织机构函数的方式实现在业务流程和组织机构的紧密整合，使用组织机构函数组成组织机构表达式，用来选择任意复杂的组织范围作为业务流程执行者。同时一般的表达式函数也可以穿插用于组织机构表达式中，实现了业务流程可以从任意地方获取执行者。业务流程执行者定义目前用在执行规则，通知规则和转发规则中，执行规则用来定义活动环节的执行者，通知规则用来定义通知接收者，转发规则用来定义转发时的接收者。

执行者函数和其他一般函数最大的区别在于返回值的格式，执行者函数的返回值类型必须是指定类型（OrgUnit）的组织单元的列表。组织单元是用FID和FName两个标识一起来描述。

其实执行者函数本质就是选择出各种条件的组织单元。执行者函数本身也不仅仅可以在业务流程中使用，在***其他有根据条件选择组织单元的地方可以通过直接调用函数或者调用表达式的方式使用。其他一般函数的返回值只要和执行者函数的输入参数匹配，就可以直接当作执行者函数的传入参数使用。

其中，在实际业务需求中往往需要写一些代码用来控制业务流程运行，或根据业务流程的运行结果同步业务数据，更有甚者通过代码是实现一些业务流程原本不支持的特性。而写这些代码的切入点就是事件。

业务流程事件其实就是业务流程默认提供的业务动作的事件。它不只包含下面列的这些事件，还可以给任意动作扩展事件。

业务流程事件可以在业务过程上定义，也可以在业务环节上定义。它们的触发顺序是先触发业务过程上级的事件，后触发业务环节上的事件。

其中，业务流程运行的本质其实就是实现各种业务流程的业务动作，其最核心部分是基于PetriNet原理的业务流程引擎。从体系结构上来说业务流程引擎和业务动作是没有任何关系的，业务动作只是外界用来控制业务流程引擎的一种途径，抛开业务动作，外界同样还可以像使用一般Java接口和类一样使用业务流程引擎提供的各种接口和类。

业务流程引擎实现两大特性，第一是解析和计算业务流程定义，然后生成ProcessControl。第二是根据ProcessControl实现实际的业务流程操作，并生成业务流程实例数据且存入数据库。所以业务流程引擎的本质就是解析业务流程定义然后生成和维护业务流程实例数据，这也是业务流程运行的本质。

其中，业务流程实例中，业务流程运行框架中的业务流程引擎（ProcessEngine）解析业务流程定义，其运行的结果就是生成业务流程实例。业务流程实例是个泛指，其实它真正包含了流程实例（ProcessInstance）和每个活动环节的任务（Task）两部分的数据。其中流程实例（ProcessInstance）是每次启动流程生成一个，而活动环节的任务（Task）则是每次流转，回退和转发时都会为流向活动环节生成的。所以它们是一个流程实例（ProcessInstance）包含多个任务（Task）的关系。

由于流程实例（ProcessInstance）和任务（Task）的绝大多数属性是都一样的，所以在数据库中，它们都是存入到任务表（SA_Task）。两种数据使用SCATALOGID和SKINID字段组合来区分。所以流程实例（ProcessInstance）本质上也是任务（Task），一种特殊类型的任务（Task）。

最后应说明的是，以上实施例仅用以描述本发明的技术方案而不是对本技术方法进行限制，本发明在应用上可以延伸为其他的修改、变化、应用和实施例，并且因此认为所有这样的修改、变化、应用、实施例都在本发明的精神和教导范围内。

Claims (9)

1.一种基于业务开发流程的模型，包括：

业务逻辑模块，用于存储业务逻辑的定义；

业务流程模块，用于存储业务流程的定义。

2.根据权利要求1所述的模型，其中，业务逻辑模块用于编写业务逻辑，包括：

动作子模块，用于存储业务动作的定义；

代码子模块，用于业务逻辑的实现；和

函数子模块，用于定义函数。

3.根据权利要求1所述的模型，其中，业务流程模块包括业务流程定义、业务流程运行和业务流程实例。

4.根据权利要求3所述的模型，其中，业务流程定义用于描述业务流程的整个过程和各种规则；业务流程运行的核心是业务流程引擎，用于解析业务流程定义，推进业务流程的运行；业务流程实例，是业务流程运行的结果；其中，一个业务流程定义被运行一次就产生一个业务流程实例。

5.根据权利要求4所述的模型，其中，业务流程定义用于描述企业实现一个业务目标需要包含的环节步骤，各环节步骤间前后顺序和同步关系，各步骤由谁来处理的信息；其中，步骤对应业务环节，顺序关系由连接弧定义，处理人对应执行者，处理要求对应到处理规则。

6.根据权利要求5所述的模型，其中，业务环节用于描述业务流程中需要人为参与的处理、自动的处理和业务流程中路径的选择、分支和合并。

7.根据权利要求4所述的模型，其中，业务流程运行用于实现各种业务流程的业务动作，是基于PetriNet原理的业务流程引擎；其中，从体系结构上来说业务流程引擎和业务动作是没有关联。

8.根据权利要求4所述的模型，其中，业务流程引擎用于实现解析和计算业务流程定义，生成过程控制ProcessControl；还用于根据过程控制实现实际的业务流程操作，并生成业务流程实例数据且存入数据库。

9.根据权利要求8所述的模型，其中，业务流程实例包括流程实例和每个活动环节的任务两部分的数据；其中，流程实例是每次启动流程生成一个，而活动环节的任务则是每次流转、回退和转发时都会为流向活动环节生成的。

Images