轻量级工作流引擎的设计与实现

1、轻量级工作流引擎的设计与实现第一章引言1.1轻量级工作流引擎的概念轻量级的工作流引擎指的是从够用、灵活和低成木的设计原则出发，不追求工作 流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作 流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配 和控制等功能捉供支持，而不支持诸如提供内建(built-in)的应用开发工具、 对应用资料的定义和完整性维护、完善的异常处理以及长事务控制等功能。轻量 级工作流引擎的概念的提出，给开发工作流管理系统的开发人员开辟了一条新的 道路。工作流管理技术木身就是一项抽象复杂的技术，它致力追求从企事业各种 各样的业务屮抽取出一个

2、通用的模型，由这个模型去描述所有业务的一致性，以 达到“放之四海皆可用”的程度。不过，要把众多的而又错综复杂的业务都集中 在这个模型屮，这是一件非常困难的工作，要经过一段漫长的摸索历程。而轻量 级的概念让我们认识到可以从一般性的而又简单的业务入手，为企事业快速的开 发出一个适应他们本身业务需求的而又带有可扩展性可移植性的信息管理系统， 为他们提高工作效率，并保证在一段很长的时间内满足不断增加的业务需求。1.2工作流管理系统的分类及本文的侧重点根据工作流过程木身的特点、系统建模的方式、所使用的底层支撑技术、以 及工作流过程的执行方式等的不同而对工作流管理系统进行相应的分类。1.2.1面向文档的与

3、面向过程的前者的侧着点在于将电子形式的文件、图像等在有关的人员z间进行分发， 以便能够得到不同人的处理与审阅。现有的文件管理与映像管理系统均属此类。 在面向过程的wfms中，工作流被描述成一序列执行环节。与各环节相应都有待 处理的资料对象。各环节的资料对象可以按不同的方式分发到其它环节屮去，如 可以将资料对象的值作为控制条件、或者依此资料对象组装成其它的资料对象 等。高端的wfms般都属此类系统。1.2.2结构化的与即席的结构化工作流指的是在实际工作过程屮会反复重复、严格按照某个固定的步 骤进行的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过 程进行详细的分析而得到，从而得到完

4、整的过程定义并在以后的应用过程中反复 使用。大量的办公程序，如公文处理、审批等都属此类。即席工作流则是针对那 些重复性不是很强或没有重复性的工作流程的，关于这类流程执行所需的有关参 数（如参加者等）事先无法确定，而必须推迟到过程实例运行时才能确定，同时在 执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵 活性的同时，也为过程的建模与执行带来更多的复朵性。1. 2. 3基于邮件和基于数据库前者使用电子邮件來完成过程实例执行过程屮消息的传递、资料的分发与事 件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电子邮件系 统在广域环境下的资料分发功能，但整个系统将运行于

5、一种松散耦合的模式下。 在基于数据库的wfms中，所有的资料都保存在某种类型的dbms中，过程的执行 实际上就是对这些资料的杳询与处理。高端的大规模系统所使用的一 般都是此种 方法。1.2.4任务推动的与目标拉动的前者指的是从过程的开始逐步地一个环节一个环节的执行，当某个活动实例 被处理完之后，后续的有关活动将被创建并被激活，由此直至整个工作流程的完 成。这是目前人多数面向过程的wfms所使用的执行方式。而在目标拉动的wfms 中，一个业务流程被看成是一个冃标。过程实例执行时，该冃标将被分解得到多 个相互之间按一定约束条件的关联起來的可执行的多个环节，其中各环节还可以 当成是子h标而进一步进行

6、分解。在齐环节均执行完毕z后，整个过程也就完成 to日标拉动是一种全新的执行方式，下一代的wfms将具有此种特征。应该说 明的是：上述分类只是从不同的角度入手的。一般来说，后面那些特点将给wfms 带来更好的灵活性，同时也将成为那些能够支持跨机构的人规模复杂工作流管 理、面向关键任务的wfms不可缺少的特征。1. 2. 5本文的侧重点木文的侧重点不在于完全实现其中一种t作流管理系统的所有功能，更不在 于实现所有种类的工作流管理系统的全部功能，前文已经说过，这是一件非常困 难的事情。那么我们的侧垂点在哪里呢？就在丁综合以上四种工作流管理系统的 主要特点，是一个面向文件的，基于数据库的，曲冃标拉动

7、的结构化的工作流管 理系统，并見由此去设计和实现工作流管理系统的核心一一工作流引擎。从一般 性來说，冃前大多数的企事业的业务都是事务巾请，公文流转，各项通知等等，这些业务或者需要查看，或者需耍审批，而这些业务的资料基本上是以文件的形 式保存在计算机上，而其中一些格式化的资料是保存在数据库中，所以面向文件 和面向数据库是轻量级工作流引擎的一个重要特征。业务的发起和结束是一项过 程化的任务，任务乂可以分解成一个一个环节任务，而任务是带有日的性的，由 这个h的去拉动这个过程中的一个一个的环节任务，促使环节任务的推进，最终 达到任务完成的冃的。这些业务的过程化不是随机的，而是己经严格规定好的， 只有遵

8、循这些过程化的规则和流程环节才能完成整个业务。轻量级的工作流引擎 就组合了以上这些，不追求工作流引擎的功能的完备和复朵，以满足一般性业务 为目的，为企事业快速开发出适合他们业务的工作流管理系统。第二章工作流管理系统参考模型简介在阐述工作流引擎之前，我们来了解一下工作流技术的基本知识。早在儿年 前，为了建立工作流管理系统的相关标准，国际上成立了一个称为“工作流管理 联盟”（简称wfmc）的国际纽织。她提出了有关工作流管理系统的一些规范， 定义了工作流管理系统的结构及其与应用、管理工具和其它工作流管理系统z间 的应用编程接口，也就是t作流系统参考模型。wfmc给! i【的工作流参考模型如下图：过程

9、定义工具工作流 管理工貝接口 i八八接口 3接口 5接口 4工作流机玄接调用的应用其它工作流执行服务工作流机接口 2工作流客户应用图2.1工作流参考模型从图屮可以看岀，参考模型包含了五类接口，分别是：（1）接口 1：过程定义输入输岀接口，这是t作流服务与t作流建模z间的接 口，该接口提供的功能包括通信建立，工作流模型操作和工作流模型对象操作。（2）接口 2：客户端函数接口，这是工作流服务与客户应用z间的接口，这是 最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方式。 包括通信建立，工作流定义操作（对过程模型定义操作），过程实例管理功能， 过程状态管理功能，任务项列表/任务项处

10、理功能，数据处理过程，过程监控功 能，其它的管理功能，应用程序激活。（3）接口 3：激活应用程序接口，这是工作流引擎和直接调用的应用程序之间 的接口，包括通信建立，活动管理功能，数据处理功能。（4）接口 4：工作流执行服务z间的互操作接口，这是工作流管理系统z间的 互操作接口，包括连接的建立，对工作流模型和其屮对象的操作，对过程实例的 控制和状态描述，对活动的管理，对资料进行处理。（5）接口 5：系统管理与监控接口，这是t作流服务和t作流管理工具z间的 接口，包括资源控制，角色管理，用户管理，过程实例的管理，状态管理，审核 管理。五个接口以及对应的apt函数囊括了工作流管理系统的全部功能。一个

11、完整 的工作流管理系统就是以工作流引擎为中心，向外部部件（应用程序或其它工作 流引擎）提供这五个接口，提供其实现的所有功能。第三章系统分析与设计在所有准备工作完成后，我们就开始进行系统设计和设计，构造一个轻量级 的工作流引擎。轻量级的工作流引擎并不完全实现wfmc所提出的工作流模型包 含的五个接口，特别是接口 4,在分布式工作流管理系统才具有该接口。既然我 们从轻量级的概念出发，我们就不再明显区分各个接口的界限以及其所具有的特 定的功能，以够用、灵活和低成本的设计原则去设计出我们所理解的工作流引擎。 我们运用了而向对彖的方法，首先从众多的业务需求屮抽取出工作流模型所包含 的对象，再分析各个对象

12、之间的逻辑关系，然后提出一个系统结构，再进行模块 划分，数据库设计，最终完成类的设计。我们当中所用到的建模工具就是rose umlo3. 1工作流模型的设计对t作流模型的设计是t作流引擎设计的垂要组成部分。3.1.1工作流模型的对象企事业经营过程就是一项项业务的实现过程，我们从一般业务入手，并对这 些业务进行详细的分析，研究，其结果就是得到一般性的业务对象，从而抽象成 工作流模型对象。3. 1. 1. 1从一个简单的业务实例看业务的需求fl前企事业的一项基本事务就是出差管理。它主要是对企事业的人员因为某 种工作上的原因需要到别的地方出差进行的管理。我们可以列出出差的相关步 骤：（1）中请人需要

13、出差，并但他（她）具有出差的权利；（2）申请人填写出差表格,说明因何事出差，出差何处,申请出差金额,何 时凹来等等和出差相关的情况；（3）巾请人需要其它说明的话，可以将更具体的说明以文档的形式保存下來;（4）申请人确认申请无误后提交申请，等待申请的结果；（5）根据规定，该中请必须先让中请人的上一级审批，那么该申请就会以一 项工作项的形式交给该级领导处理；（6）处理该中请的领导对该中请进行处理，他（她）会先查看该中请所有的 资料，包括出丼申请表和与之相关的其它文档，然后对其进行审批，审批的结果 是同意那么该次申请会交给再下一级领导处理；审批的结果不同意，该申请被打 冋，通知巾请人巾请不通过的结果

14、。等所有需要审批的领导都审批通过了，该巾 请就成功完成，通知申请人申请通过的结杲；（7）中请人得到中请的结果，如果审批通过则准备出差，如果审批不通过则 根据审批结果对该申请进行修改，重新提交申请；（8）申请事务结朿。这是一个简单的业务实例，对该实例进行分析我们可以得到该业务的-些对（1）巾请人：他（她）属于该企事业的某个部门的成员，并且具有启动该业 务的权利；（2）审批领导：他（她）也属于该企事业的某个部门的成员，并且具有对该 业务进行处理的权利；（3）出差表格：它是该业务规定的格式化资料，并月是必须的（4）出差具体说明：它是该业务附加的资料，可以不要的（5）申请人已经填写好的岀差表格：它是出

15、差表格的实例化，代表一个具体 的应用审批同意和不同意：它们是对该业务的处理，遵循一定的业务规则（7）中请：这是一个过程，不是一个动作，需要时间和人的活动才能完成（8）审批：这是一个活动，是过程的一部分，并且可以向另外一个活动转化 其它应用程序：中请人要填写出差具体说明时要调用相应的外部应用程 序编辑该说明并以一定的格式保存下来，审批领导要查看出差具体说明时也要调 用相应的外部应用程序打开该说明并以一定的格式显示出来。从这些业务对象，再利用工作流技术，我们可以得到工作流模型的一些基本 对象:用户：正如申请人，审批领导，他们就是工作流管理系统的用户，由他 们去使用该系统的各种功能，并且直接参与业务

16、活动，促使业务的完成。（2）幷色：有些人可以中请出差，有些人对出差申请可以审批，这两种不同 的人可以作为两个不同的角色。角色是具有某种使用系统特定功能的权利的一个 人员或多个人员的组合。（3）工作流应用资料：出差申请表格，出差具体说明，这些就是对应某个具 体业务（这里是岀差管理）的相关资料，根据这些业务资料我们可以对该业务进 行处理。（4）需激活的应用程序：在需耍其它应用程序提供支持的时候，会去激活这 些应用程序。（5）流程：整个出茅申请的过程就是一个流程，它从整体去描述一个业务。（6）环节：乂称活动，它反映了业务流程的局部情况，通常业务流程是由一 个一个的环节组成。（7）流程实例：将该出差中

17、请这个业务流程实例化，就得到一个流程实例。 环节实例：将流程的其中一个环节实例化，就得到一个环节实例。业务规则：业务的开始和结束需要一定的条件，在处理业务的过程中必 须按照一定的规则，这些都是业务规则，只有严格遵循业务规则，业务才能完成。3. 1. 1. 2工作流对象的具体分析和说明通过一个具体的业务我们可以得到工作流模型的一些对象，那么我们再对其 他一般性业务进行分析，研究，我们就会找到它们的共同点，并归纳出基于这些 业务的公共的对象，这些公共的对象的组合，就是一个通用的模型，也就是工作 流模型，这个模型能去描述侮个业务，是我们追求轻量级工作流引擎的最终成杲。（1）用户：业务的执行者和参与者

18、，对应于企事业的每一个雇员，是一个独 立的、具有一定行为能力和一定技术能力的人的实体；（2）角色：以技能为前提，能够完成某项功能的人员的总称；（3）部门：对应于企事业的静态结构划分，由企事业的实际部门设置情况来 决定，可以是传统的面向职能的，也可以是现在流行的面向过程与客户的；（4）职位：以行政责任为前提，代表了管理上的等级关系；（5）工作纟fu以执行某一任务为日标而动态组建的、跨部门划分的一种组织 结构；（6）流程：对应于一个业务过程，表示一个业务由发起、处理、结朿的一个 过程；（7）流程实例：对应于一个业务流程具体应用，是业务流程实例化的表现形 式；（8）环节：对应于业务流程中一个单一的业

19、务操作，是流程按照业务耍求的 细化；（9）环节实例：对应于一个环节的具体应用，是环节实例化的表现形式；00）工作流定义主信息：描述一个工作流模型的主要信息，从整体来描述工 作流模型；（11）工作流附件信息：描述一个t作流模型所用到的附件信息，也就是工作 流应用资料，或者叫业务资料。按照wfmc提岀的工作流模型，这不是工作流模 型所包含的对彖，可是我们对其进行格式化，把它抽取成一个模型对象，用来规 定了工作流模型在具体应用时所需业务资料的格式，我们把它分为两类： 表格类型：这是以表格的形式保存附件信息，可以用关系结构來定义附 件信息，并保存在数据库屮，每一条记录就是一个该附件的实例； 文档类型：

20、只是以文件形式保存附件信息，可以是work文档，也可以是 文本文件，它的实例化是就是一个一个带有对应某个业务应用标志的文 件，保存在硬盘上（12）工作流实例信息：描述一个工作流模型实例化的信息，也作为启动一个 工作流的信息，它记录该业务流程随着时间和人员的参与处理的不断变化，直到 整个业务的结束；（13）工作项信息：描述参与某个业务应用时被分配到的一项任务，这就休现 了参与人员和系统交互的典型特征；（14）业务规则：描述业务在运行的过程屮必须要遵守的规定和原则，也是业 务活动得以向另一个活动推进的规则。我们把它分为四类规则，分别是： 自动型：它主要描述一些只给参与人员查看业务信息的业务规则，例

21、如 通知、公文流转等等业务。该类业务不需要参与人员去审批或其它人为 上的处理，只需要参与人员去查看其中的内容就足够，整个业务流程的 完成是全口动的。 与聚合：业务活动的完成是需要参与该活动的所有人员都进行人为处理, 其屮有一个人员没对其进行处理，整个活动只能停在原地，等待所有人 员的处理，当最后一个参与人员执行了处理工作，它才能完成。 或聚合：在参与某一业务活动的人员当中只要有一个对其进行处理，整 个活动就可以完成。 投票聚合：统计参与该活动的参与人员的处理结杲，当满足一定条件该 活动才能完成。（15）转换条件：描述流程、活动状态改变时需要的条件，用于业务运行过程 中的约束。例如流程的完成必须

22、等待所有活动的完成才能完成，活动的完成必须 按照业务规则去完成等等；（16）需激活的应用程序：工作流管理系统需要其它应用程序的支持，例如编 辑和查看文本文件信息等等；（17）口志信息：描述工作流中所有的状态改变、事件和控制流相关资料的变 化，工作流实例和环节实例的启动、结朿、挂起和激活等等信息都会记录下来, 以便对其进行管理。3.1.2对象之间的逻辑关系在找出t作流模型的对彖后，我们就开始分析它们z间的业务逻辑关系。3.1. 2. 1对对象进行分类以及各个分类中对象之间的关系到此为止，我们有必要对工作流模型对象进行一下分类，根据工作流对象对工作 流管理系统所起的作用我们可以分成以下儿类：（1）

23、组织模型组织模型描述了企事业的组织机构关系，包括的对彖有用户，部门，职位， 角色，工作组，它们的关系可以用下图表示：图3.1纽织模型结构从图屮可以看到它们之间的关系，用户是基本的单位，部门是由用户组成， 每个用户对应一个职位，负责该职位所要求的职能，用户凭着某种资格赋予一种 角色，工作组也由用户组成，也可以由角色组成。这儿个基本的对象以及其关系 所构成的组织模型，已经可以满足轻量级工作流引擎对组织模型的需要了。（2）工作流定义模型工作流定义模型描述了工作流模型的定义信息，包括工作流定义主信息，流 程定义信息，环节定义信息，工作流附件信息，业务规则。它们之间的关系如下 图：图3.2工作流定义模型

24、结构流程是包含若干环节的，而环节遵循一主的业务规则，再加上t作流主信息 和附件信息，共同构成工作流定义模型。（3）工作流实例模型工作流实例模型描述了工作流模型实例化时的信息，通过这些信息我们可以 知道实例过程中的齐种状态变化和最终的结果，因而得到一个业务具体应用的情 况。它包拾流程实例，环节实例，工作流实例信息，工作项信息和转换条件，它 们之间的关系如下图：图3.3工作流实例模型结构转换条件影响工作流实例，流程实例，环节实例和工作项的状态，并由转换 条件去决定它们的状态转变，工作流实例信息t流程实例信息t环节实例信 息t工作项信息，自上而下逐层细化，不但从全局了解业务运行情况，而且从 局部了解

25、业务运行的细节情况。而它们的状态改变都会记录在日志中，用以追踪 工作流实例的运行情况。（4）外部支持模型外部支持模型在本文只包括一个对象，就是需激活的外部应用程序，严格來 说这不是工作流模型的一部分，可是提供接口去激活所需的外部应用程序为工作 流管理系统提供支持是工作流模型的功能z-o有了这些外部应用程序的支持， 我们的t作流管理系统的功能才变得更完善。3. 1. 2. 2各个模型之间的逻辑关系不但模型中各个对象有一定的逻辑关系，而且各个模型之间也有一定的逻辑 关系，如下图所示：用户定义图3.4模型z间的关系组织模型的用户定义工作流定义模型；工作流定义模型使用组织模型的角色 和工作组，用來规定

26、工作流模型的启动条件和任务分配条件，因为工作流模型的 启动和任务的分配必须由一定的角色或工作纽完成；工作流实例模型依赖工作流 运义模型，同时使用组织模型的所有对象，并且调用外部支持模型为其提供支持。3.1.3工作流实例，流程实例，环节实例和工作项的状态转换工作流实例，流程实例，环节实例和工作项从不同的层次去描述业务运行过 程的具体情况，不同级别的用户可以看到业务运行的不同方面，创建工作流实例 的用户可以看到工作流实例信息以及其状态转换，参与该t作流实例的用户可以 看到工作项信息以及其状态的改变，系统管理员可以看到所有信息以及其状态的 转换。（1）工作流实例状态图图3.5工作流实例状态图流程实例

27、状态图环节实例状态图接受图3.5环节实例状态图工作项状态转换图图3.5工作项状态图3.1.4任务分派任务分派是工作流引擎的一个重要功能。当环节实例产生时，就会以一定的准则 把需要处理的工作当作一项任务项（工作项）分派给参与该环节实例的所有用户， 而这些用户是同属一个角色或者工作组的。我们乂把角色和工作组进行细化，可 以得到以下准则： 基于部门的：这就是说把任务分派到某个部门的所有人员，该部门的所有人 员都参与了该项任务，因而会为该部门的所有人员都产生一个工作项；基于职位的：这就是说把任务分派到某个职位的所有人员，同属该职位的所 有人员都被分配到一项工作项； 基于部门职位的：这就是说把任务分派到

28、某个部门的某个职位的所有人员， 同属该部门的该职位的人员都被分配到一项工作项； 基于所有人的：这就是说把任务分派到该企事业的所有人，该企事业的所有 人都被分配到一项t作项；基于工作组的：这就是说把任务分派到该企事业的某个特定的工作组上，同 属该组的所有人员都被分配到一项工作项。基于部门的，基于职位的，基于部门职位的和基于所有人的这四种类型，其 实是基于角色的细化，通过这些准则的分类，我们尽量做到系统与企事业有较强 的适应性，以及使系统在任务分派时有较大的灵活性。3. 1. 5转换条件的满足工作流实例，流程实例，环节实例和工作项的状态转换有各自特定的条件， 分别如下：（1）工作流实例的转换条件工

29、作流实例从整体看业务运行过程，工作流实例被用户创建后就进行初 始化并提交给工作流引擎，出工作流引擎去处理，此时实例处于运行状态；在运 行过程中，它会根据流程实例的状态而不断进行本身的状态改变；当管理员由于 某种原因要挂起它时，它就处于挂起状态，直到管理员重新激活它使它处于运行 状态或者终止它使它非正常结束；当它被正常处理完毕后，就止常结束。（2）流程实例的转换条件流程实例也从整体看业务的运行过程，流程实例在工作流实例初始化时 就开始它的工作。在运行过程中，它会根据各个环节的完成程度來改变自己的状 态，当所有环节实例都正常完成它就正常结束；管理员可能要挂起它使它处于挂 起状态，直到管理员重新激活

30、它使它处于运行状态或者终止它使它非正常结束。（3）环节实例的转换条件环节实例从某个方面看业务的运行过程，环节实例在流程实例运行时就开始 它的丁作处于处理屮状态。z后环节实例的状态由两方而决定，一是工作项的处 理结果，一是业务规则的规定。 如果业务规则是自动型的，不管工作项的处理结果怎样，当系统把 任务项分派（给特定用户）完毕后，该环节实例就正常完成处于正常 结束状态； 如果业务规则是与聚合的，系统分派完任务项后，当所有参与人员 都正常处理完该环节各自的工作项后，该环节才正常完成处于正常结 束状态；在处理过程中，只更有一个工作项是非正常处理的，该环节 就非正常完成处于非正常结束状态；在处理过程屮

31、，有工作项还未被 处理并且没有一个t作项被非正常处理，那么环节实例仍然处于处理 中状态； 如果业务规则是或聚合的，系统分派任务后，只要有一个工作项是 正常处理的，该环节实例就正常完成处于正常结束状态；如果所有同 属该环节实例的工作项都被非正常完成，那么该环节实例就处于非正 常结束状态； 如果业务规则是投票聚合的，系统分派任务后，统计工作项的完成 程度，当正常完成的工作项数量达到一定数量时，该环节实例就正常 完成处于正常结束状态；当正常完成的工作项数量不达到规定的数量 时，该环节就非正常完成处于非正常结束状态；当所有工作项还没处 理并且正常完成的工作项还没达到规定数量时，该环节实例仍然处丁 处理

32、中状态。工作项的转换条件工作项从更细节的方面看业务运行过程，工作项的状态转换要看参与人员对 各自的工作项的处理情况和业务规则的规定。我们把与聚合，或聚合和投票聚合 这些要人工干预的规则统称为人工型规则。 如果业务规则是口动型，同属该规则的工作项的状态就只有正常处 理后的正常结束状态，当然如果对该工作项还没被处理则处于处理屮 状态，可这不对环节实例等产生影响； 如果业务规则是人工型，就会有正常处理和非正常处理两种情况， 正常处理该工作项则使到该工作项处于正常结束状态，非正常处理该 工作项则使到该工作项处于非正常结束状态。3.2系统结构本着基于轻量级工作流引擎的原则，我们已经对工作流模型进行了详细

33、的分析和详细的设计,在这里我们就提出一个系统结构，如下图所示:组织定义接口工作流定义接口工作流实例接口2/纽织定义器工作流定义器实例调度屮心7工作流 定义数士数据组织泄 义任务分派器z组织i工作流 i管理器解析器工作流实例数据任务管理器启动控制器状态转换器_v图3.6工作流引擎系统结构图从图中可以知道，系统提供了三类接口：组织定义接口、工作流定义接口和 工作流实例接口。这三类接口实现了工作流模型的接口一，接口二，接口三和接 口五规定的主要功能；系统有一个实例调度中心，这是一个很重要的部件，它控 制工作流实例的运行，通过工作流解析器对该工作流模型进行解析其含义，通过 任务分派器按照一定的分派准则

34、把任务项分派给参与该工作流实例的用户，通过 任务管理器管理各个任务项的信息，通过启动控制器控制工作流的启动权利和启 动信息，通过状态转换器控制丁作流实例、流程实例、环节实例和工作项的状态 转换；组织定义器定义企事业的组织结构；工作流定义器定义工作流模型信息， 并通过组织管理器得到组织定义信息，为工作流模型提供组织支持。各个部件处 理的和关信息都保存在数据库中。3. 3系统模块的划分根据功能实现的不同我们进行模块的划分如下：（1）用户管理模块：对用户信息的管理，包括注册用户信息，注销用户信息, 查询用户信息等功能；（2）部门管理模块：对企事业部门结构信息的管理，包括增加部门信息，删 除部门信息，

35、查询部门信息等等功能；（3）职位管理模块：对企事业职能信息的管理，包括增加职位信息，删除职 位信息，查询职位信息等等功能；（4）角色管理模块：对企事业某种技能信息的管理，包括新增角色信息，删 除角色信息，查询角色信息等等功能；-（5）工作流模型管理模块：对工作流定义模型信息的管理，包括定义新的工 作流模型信息，删除旧的工作流模型信息，查询工作流模型信息；（6）工作流实例管理模块：对工作流实例信息的管理，包括启动一个新的工 作流实例，查询工作流实例信息，按照一定的业务规则生成新的环节实例信息， 为用户分派工作项，管理工作项信息，按照一定的转换条件为工作流实例、环节 实例转换状态等等功能；（7）系

36、统监控模块：为t作流实例，环节实例等的状态转换信息加入h志， 挂起、激活工作流实例，强制结束工作流实例，为迟迟不对自己的工作项进行处 理的用户发出提醒或警告信息，查看齐个工作流实例的完成程度等等功能。功能模块的划分，为系统的实现做好充分的准备。3. 4数据库设计基于轻量级的工作流引擎的特点之一就是把系统相关的资料，如工作流模型 定义信息，工作流实例信息，组织模型定义信息等等，都以特定的实体形式保存 在关系型数据库中。 工作流定义主信息表（workflowtablc）静态定义工作流主要信息，包括该工作流的标识id （可以定义为以” workflow xxxxxxxxxxxxxxxxxxxxxxx

37、xxxxxxxx” 形式，x 是口动生成的序号）, 工作流名称，工作流描述，工作流类型（工作流的类型有口动型，人工型和混合 型，自动型不需要人工参与，由工组流引擎自动执行，人工型需要人工参与，混 合型包含了自动型和人工型），工作流创建h期，工作流创建者id （即用户id）, 工作流创建人名称（即用户名），工作流生命周期（每个工作流实例都有它的生 命周期期限，在该期限内还没完成它的t作就直接死亡），冃前该t作流实例数 目（记录当前工作流实例数目），工作流启动者角色（指明该工作流可以曲哪个 角色发起，属于该角色的用户都可以启动该工作流模型对应的实例）。工作流重 要信息还包括两方而，一是t作流附件，

38、因为在t作流进行过程中，肯定会带有 一些信息，这些信息对于出差申请来说就是出差申请表，对于公文流转来说就是 以word文档形式的公文，对于通知来说可能就是以文本文档形式的通知书，等 等；一是工作流流程描述，包括若干个环节（activity）,这些环节有定的顺 序，表现工作流顺序执行的特征。把工作流附件和工作流流程描述从工作流定义 分离出來，是基于工作流附件和工作流流程描述对于不同工作流有不同形式和数 量的原因，有利于工作流附件和工作流流程描述的扩展。 工作流附件信息表（workflowattachmenttable）静态定义工作流所需要的附件，包括附件id （可以定义为以” attachmen

39、t_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 形式，x 是 自动生成的序号）， 工作流td （标识属于哪个工作流），附件类型（表或文件），附件名称（如果 类型是表，则为该表的名称，如果是word文档，则为该文档名称，如果是文本 文档，则为该文件名称），具它信息（如果类型为表格，该字段以一定的格式保 存该附件表格的所有字段的各种信息，包括字段名称，字段数据类型，数据类型 长度，字段描述）。 工作流流程描述表（workf 1 owprocesstable）静态定义工作流的流程，出若干环节（activity）组成，一个环节为一条记 录，包括工作流id （环节所属工作

40、流td）,环节td （可以定义为以” activlty_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"形式，x 是自动生成的序号）, 环节名称（即该环节名称），环节描述（对该环节的具体描述），参与者角色 ii）（将相同权限的用户作为一个集合，在数据库以同一个角色操作数据库特定操 作，该项标识角色id）,环节任务分派规则，上一个环节id （保存上一个环节 的id,由这项可以判断该环节是否整个流程的开始环节，或者该环节的任务没 有完成（审批不通过，或没在其牛命周期期限内完成）时作冋滚处理的重要数据 项，根据这个数据项可以冋滚到上一个环节），下一个环节ii）（保存下一环节

41、 的id,由这项可以判断该环节是否整个流程的结束环节，或者该环节的任务完 成了，根据这个数据项可以启动下一环节，继续向前推进）。 t作流实例启动描述（workflowlnstancestartuptable）动态定义工作流实例启动信息（其实这也是工作流实例信息表）启动者在产 生一个工作流实例z前必须根据工作流的定义做好准备工作，这些准备工作的信 息就填入该表中，然后交付给工作流引擎。该描述包括工作流id （所属工作流 id）,工组流实例id （标识该工作流实例，可以定义为以” workflow instance xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx v 形式，x 是自

42、动生成的 序号），工作流实例描述，工作流实例创建时间，工作流实例创建者td （启动 者id） , t作流实例创建者名称，当前t作流状态（标识当前工作流实例的状 态，启动者在创建后却没提交给工作流引擎前的状态为“initialized”初始化 状态，z后的状态要视工作流类型而定），当前状态具体描述，当前操作者1d（当前工作流要被谁操作），当前操作者名称。工作流实例完成标志（标识该工 作流实例的完成），工作流实例完成时间，当前工作流状态和当前操作者id和 当前工作流状态具体描述三项在工作流实例的运行过程中，可以动态追踪该工作 流实例的运行，而这三项再加上工作流完成标志和丄作流完成时间，可以知道该

43、工作流实例的完成情况。 工作流实例过程描述（workflowtnstanceprocessingtable）以环节为单位动态描述工作流实例的处理过程，启动者创建工作流实例后, 提交给工作流引擎后，工作流实例就根据工作流定义的流程进行运转了。包括工 作流实例id,工作流实例所对应环节（工作流流程就是由一系列的环节组成， 按照预定义的流程一个环节过渡到另一个环节），当前该环节所处状态（这标识 着该环节在处理过程中的状态，最终状态表示该环节的完成状态），当前操作者 （对应的是角色），当前状态具体描述。（6）工作项描述（workltemtable）动态描述已经参与该工作流实例处理的参与者（对应已处理环

44、节的角色的每 个用户）的工作情况。包括工作项td （可以定义为以”work it cm-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx" 形式，x 是自动生成的序号）, 工作项名字，工作项描述，工作流实例id （该工作项所属的工作流实例），该 环节任务分派规则（继承环节的任务分派规则，用于判断该环节任务完成方式）， 当前该工作项所处状态（根据不同的工作流类型有不同的状态，根据这些状态可 以在参与者接口上显示不同的工作项列表），执行动作（记录执行者会对该工作 项执行怎么样的动作，如果是申请事务则是审批通过或审批不通过），执行时间 （记录该执行动作的时间），用户ii）（

45、标志该工作项是属于谁的。（7）用户描述（usertable）该表描述所有用户的资料，包括用户id （可以定义为以”user： xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” 形式，x 是自动生成的序号）, 用户 名称，用户密码，用户所属部门，职位等等信息，级别是该用户的系统权限，包 括普通职员，高级职员和系统管理员。 日志信息描述（logtable）描述用户的工作口志，便于对各种操作进行追踪。包括口志ii）（可以定义为 以"log-_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx "形式，x 是自动牛成的序号）等 等，其屮有一项是相关工作项

46、td,这是当参与者对原始工作项进行执行操作动 作时的t作项。(9) 角色信息(roletable)描述角色的信息，包括角色id (可以定义为以”rolexxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxv 形式，x 是自动牛成的序号), 角色 名称，部门名称，职位名称，角色描述。角色出部门和职位组成。(10) 部门信息(departmenttable)描述部门的信息，包括部门td (可以定义为以”depatment xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxn 形式，x 是口动牛成的序号), 部门名称，部门其它信息。(11) 职位信息(positiontable

47、)描述职位的信息，包括职位td (可以定义为以”position_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx” 形式，x 是自动生成的序号), 职位名称，职位其它信息。除了以上这些主耍表以外，述有一些我们是在定义工作流模型的时候才加入 数据库的，如对应工作流附件类型为表的表格。为了减少网络流量和提高系统的 运行速度，我们把一些有关联的数据库操作写成存储过程：(1) 删除工作流模型存储过程：删除一个工作流模型，必须删除它的工作流 定义主信息，同时删除对应的附件信息，附件为表的表格，环节信息；(2) 创建附件类型为表的表格：定义附件信息时已经把该表格的字段信息保 存在该附件信息

48、的其它信息字段中，并且有一定的格式，那么我们从该字段中按 照一定的格式还原表格的字段信息，并根据这些信息在数据库中创建该表格。3. 5类的设计用而向对彖的方法和uml建模丁具，再根据系统结构图，模块的划分和数据 库的设计，我们把对象转化成类，进行类的设计。我们把整个系统的类分成三部 分，一是实体类，二是业务类，三是接口类。3. 5.1实体类的设计工作流模型的对象就是一个一个的实体，实体类乂分为数据库访问类和值对 象类。数据库访问类是对存储在数据库的实体信息进行访问(插入，删除，更新, 查询)的类，值对彖类是在客户端和服务器端z间交换资料的实体信息类。3.5. l1数据库访问类(1) 数据库连接

49、类：该类是其它数据怩访问类的父类，管理数据丿车的连接， 负责从数据库连接池找可用的数据库连接给其它数据库访问类使用，使用完毕后 负责放回连接池，类图如下图：说明：属性只有一个connection,它代表数据库的一条连接，类型为 connection,方法有一个构造函数workf lowda0()和一个关闭连接的函数 closeconnection () o workf lowdao()实现从数据库连接池找一个可用连接并赋值 给属性connection, closeconnection ()负责把连接放回数据库连接池。(2)工作流定义主信息访问类：对应数据库的工作流定义主信息表，该类封 装了对该

50、表格记录的各种操作，就是插入或删除一条丁作流定义主信息，查询特 定工作流定义信息或者所有工作流定义信息，类图如下图：说明：构造函数wfdefinemaintnfodaoo调用父类构造函数，从数据库连接 池中找一个可用的数据库连接(其它数据库访问类也一样)。(3) 工作流流程信息访问类：对应工作流流程描述表，该类封装了对该表格 记录的各种操作，流程是曲若干环节组成，就是插入或删除一条环节信息，查询 同属于一个流程的环节信息等等，类图如下图：说明：findworkflowfir 1 stactivitytnfo()函数负责找该工作流模型的第一 个环节的信息，f indworkflownextact

51、ivitdd()负责根据当前环节1d找下一环 节的信息。(4) 工作流附件信息访问类：对应工作流附件信息表，该类封装了对该表格 记录的各种操作，就是插入或删除一条工作流附件信息，杳询同属于一个工作流 模型的附件信息。类图如下：(5) 工作流附件类型为表的信息访问类：对应工作流附件类型为表格的信息 表，该类封装了该表记录的各种操作，就是插入或查询一条工作流附件类型为表 格的具体信息，类图如下：(6) 工作流实例启动信息访问类：对应t作流实例启动信息表，该类封装了 该表记录的各种操作，就是插入或查询一条工作流启动信息，查询同属于一个用 户的工作流实例启动信息，更新部分字段信息，类图如下：说明：se

52、 1 ectfi ni shedworkf 1 owtnstancestartuptnfovo()负责查询特定用 户启动的并且己经完成的工作流信息，sei ectnotfi nishedworkfl owtnstancestartuptnfovoo 负责查询特定用户启动 的并且还没有完成的t作流信息，updatewflnstfinishedfields ()负责在t作流 实例结束时更新特定的字段信息，updatewfinstprocessingfields ()负责在t作 流实例运行工程中更新特定的字段信息。(7) 工作流实例过程信息访问类：对应工作流实例过程信息表，该类封装了 该表格记录的各

53、种操作，每一条记录实际上是一个环节实例，就是插入、删除或 查询一条环节实例信息，查询指定工作流实例的所有环节信息，更新部分信息字 段，类图如下：说明：setwftnstprocessi ngcurrentperformernumfiel d()负责更新2经处 理该环节实例对应的工作项的参与该环节实例的用户数日， updatewinstprocessi ngfi el ds ()负责在环节实例处理过程屮更新特定的字段 信息。(8) 工作项信息访问表：对应工作项表，该类封装了该表格记录的各种操作, 就是插入或删除一条工作项信息，查询工作项信息，更新工作项信息，类图如下:说明：selectfinis

54、hedworkltemvo()负责查询特定用户己经处理完毕的t作 项信息，selectnotyetfinishedworkltemvoo负责查询还没有处理的工作项信 息，updateworkttenifields （）负责更新工作项在处理过程屮的特定字段信息， isperformedinwork 1 tembyuser （）负责判断该t作项是否己经处理完毕。0）用户信息访问表：对应用户信息表，该类封装了该表格记录的各种操作, 就是插入、删除或查询一条用户信息，查询特定角色对应的用户信息，类图如下:说明：selectcountrso负责统计同属于一个角色的用户数冃。（10）角色信息访问类：对应角

55、色信息表，该类封装了该表记录的各种操作,就是插入、删除或查询一条角色信息，查询所有角色信息，类图如下：（11）部门信息访问类：对应部门信息表，该类封装了该表记录的各种操作, 就是插入、删除或查询一条部门信息，查询所有部门信息，类图如下：02）职位信息访问类：对应职位信息表，该类封装了该表记录的各种操作, 就是插入、删除或查询一条职位信息，查询所有职位信息，类图如下：（13）日志信息访问类：对应日志信息表，该类封装了该表记录的各种操作, 就是插入、删除一条h志信息，查询特定的日志信息，类图如下：3. 5. 1. 2值对象类值对彖类其实是一种数据结构，用于客户机和服务器z间的数据交换，也用 于对象

56、实例的数据传递，它有若干属性，可是很少方法，实例化后就对应数据库 表的一条记录。（1）工作流定义主信息值对象类：可以保存工作流主信息表的一条记录信息, 类图如下：（2）工作流流程信息值对象类：可以保存工作流流程信息表的一条记录信息, 类图如下：（3）工作流附件信息值对象类：可以保存工作流附件信息表的一条记录信息, 类图如下：说明：setothertnfoo负责以一定格式把工作流附件类型为表的表格字段信 息保存在otherlnfo中,getotherlnfoo负责从otherlnfo中以一定的榕式还原 工作流附件为表的表格字段信息。（4）工作流附件类型为表的信息值对象类：可以保存工作流附件类型为表的 信息表的一条记录信息，类图如下：说明：tablenmne就是工作流附件类型为表的表格名称，fieldvalue就是对 应该表的一条记录的各个字段值，用可变长数组vector保存下来。（5）工作流实例启动信息值对象类：可以保存工作流实例启动信息表的一条 记录信息，类图如下：（6）工作流实例过程信息值对象类：可以保存工作流实例过程信息表的一条 记录信息，类图如下：工作项信息值对象类：可以保存工作项信息表的一条记录信息，类图如 下：用户信息值对象类：可以保存用户信息表的一条记录信息，类图如下:角色信息值对象类：