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

窗体顶端第一章 引 言1.1 轻量级工作流引擎的概念 轻量级的工作流引擎指的是从够用、灵活和低成本的设计原则出发，不追求工作流引擎的功能的完备和复杂，只是实现其中必不可少的功能和特征。在设计工作流引擎时主要考虑对其数据模型的定义和解释、活动之间的协调以及任务的分配和控制等功能提供支持，而不支持诸如提供内建（built-in）的应用开发工具、对应用资料的定义和完整性维护、完善的异常处理以及长事务控制等功能。轻量级工作流引擎的概念的提出，给开发工作流管理系统的开发人员开辟了一条新的道路。工作流管理技术本身就是一项抽象复杂的技术，它致力追求从企事业各种各样的业务中抽取出一个通用的模型，由这个模型去描述所有业务的一致性，以达到“放之四海皆可用”的程度。不过，要把众多的而又错综复杂的业务都集中在这个模型中，这是一件非常困难的工作，要经过一段漫长的摸索历程。而轻量级的概念让我们认识到可以从一般性的而又简单的业务入手，为企事业快速的开发出一个适应他们本身业务需求的而又带有可扩展性可移植性的信息管理系统，为他们提高工作效率，并保证在一段很长的时间内满足不断增加的业务需求。1.2 工作流管理系统的分类及本文的侧重点根据工作流过程本身的特点、系统建模的方式、所使用的底层支撑技术、以及工作流过程的执行方式等的不同而对工作流管理系统进行相应的分类。1.2.1 面向文档的与面向过程的前者的侧着点在于将电子形式的文件、图像等在有关的人员之间进行分发，以便能够得到不同人的处理与审阅。现有的文件管理与映像管理系统均属此类。在面向过程的WFMS中，工作流被描述成一序列执行环节。与各环节相应都有待处理的资料对象。各环节的资料对象可以按不同的方式分发到其它环节中去，如可以将资料对象的值作为控制条件、或者依此资料对象组装成其它的资料对象等。高端的WFMS一般都属此类系统。1.2.2 结构化的与即席的结构化工作流指的是在实际工作过程中会反复重复、严格按照某个固定的步骤进行的业务过程。定义此种工作流所需要的各种类型的信息可以通过对业务过程进行详细的分析而得到，从而得到完整的过程定义并在以后的应用过程中反复使用。大量的办公程序，如公文处理、审批等都属此类。即席工作流则是针对那些重复性不是很强或没有重复性的工作流程的，关于这类流程执行所需的有关参数(如参加者等)事先无法确定，而必须推迟到过程实例运行时才能确定，同时在执行过程中间还可能会发生一些意外的情况。这种动态多变的特点在提供更高灵活性的同时，也为过程的建模与执行带来更多的复杂性。1.2.3 基于邮件和基于数据库前者使用电子邮件来完成过程实例执行过程中消息的传递、资料的分发与事件的通知。低端的系统所使用的经常就是此种方法，它可以充分发挥电子邮件系统在广域环境下的资料分发功能，但整个系统将运行于一种松散耦合的模式下。在基于数据库的WFMS中，所有的资料都保存在某种类型的DBMS中，过程的执行实际上就是对这些资料的查询与处理。高端的大规模系统所使用的一般都是此种方法。1.2.4 任务推动的与目标拉动的前者指的是从过程的开始逐步地一个环节一个环节的执行，当某个活动实例被处理完之后，后续的有关活动将被创建并被激活，由此直至整个工作流程的完成。这是目前大多数面向过程的WFMS所使用的执行方式。而在目标拉动的WFMS中，一个业务流程被看成是一个目标。过程实例执行时，该目标将被分解得到多个相互之间按一定约束条件的关联起来的可执行的多个环节，其中各环节还可以当成是子目标而进一步进行分解。在各环节均执行完毕之后，整个过程也就完成了。目标拉动是一种全新的执行方式，下一代的WFMS将具有此种特征。应该说明的是：上述分类只是从不同的角度入手的。一般来说，后面那些特点将给WFMS带来更好的灵活性，同时也将成为那些能够支持跨机构的大规模复杂工作流管理、面向关键任务的WFMS不可缺少的特征。1.2.5 本文的侧重点本文的侧重点不在于完全实现其中一种工作流管理系统的所有功能，更不在于实现所有种类的工作流管理系统的全部功能，前文已经说过，这是一件非常困难的事情。那么我们的侧重点在哪里呢？就在于综合以上四种工作流管理系统的主要特点，是一个面向文件的，基于数据库的，由目标拉动的结构化的工作流管理系统，并且由此去设计和实现工作流管理系统的核心工作流引擎。从一般性来说，目前大多数的企事业的业务都是事务申请，公文流转，各项通知等等，这些业务或者需要查看，或者需要审批，而这些业务的资料基本上是以文件的形式保存在计算机上，而其中一些格式化的资料是保存在数据库中，所以面向文件和面向数据库是轻量级工作流引擎的一个重要特征。业务的发起和结束是一项过程化的任务，任务又可以分解成一个一个环节任务，而任务是带有目的性的，由这个目的去拉动这个过程中的一个一个的环节任务，促使环节任务的推进，最终达到任务完成的目的。这些业务的过程化不是随机的，而是已经严格规定好的，只有遵循这些过程化的规则和流程环节才能完成整个业务。轻量级的工作流引擎就组合了以上这些，不追求工作流引擎的功能的完备和复杂，以满足一般性业务为目的，为企事业快速开发出适合他们业务的工作流管理系统。第二章 工作流管理系统参考模型简介在阐述工作流引擎之前，我们来了解一下工作流技术的基本知识。早在几年前，为了建立工作流管理系统的相关标准，国际上成立了一个称为“工作流管理联盟”（简称WFMC）的国际组织。她提出了有关工作流管理系统的一些规范，定义了工作流管理系统的结构及其与应用、管理工具和其它工作流管理系统之间的应用编程接口，也就是工作流系统参考模型。WFMC给出的工作流参考模型如下图： 接口2接口3接口4接口1接口5过程定义工具工作流API与交换格式工作流执行服务工作流机（工作流引擎）工作流管理工具其它工作流执行服务工作流机工作流客户应用工作流机直接调用的应用图2.1 工作流参考模型从图中可以看出，参考模型包含了五类接口，分别是： 接口1：过程定义输入输出接口，这是工作流服务与工作流建模之间的接口，该接口提供的功能包括通信建立，工作流模型操作和工作流模型对象操作。 接口2：客户端函数接口，这是工作流服务与客户应用之间的接口，这是最主要的接口规范，它约定所有客户方应用与工作流服务之间的功能操作方式。包括通信建立，工作流定义操作（对过程模型定义操作），过程实例管理功能，过程状态管理功能，任务项列表/任务项处理功能，数据处理过程，过程监控功能，其它的管理功能，应用程序激活。 接口3：激活应用程序接口，这是工作流引擎和直接调用的应用程序之间的接口，包括通信建立，活动管理功能，数据处理功能。 接口4：工作流执行服务之间的互操作接口，这是工作流管理系统之间的互操作接口，包括连接的建立，对工作流模型和其中对象的操作，对过程实例的控制和状态描述，对活动的管理，对资料进行处理。 接口5：系统管理与监控接口，这是工作流服务和工作流管理工具之间的接口，包括资源控制，角色管理，用户管理，过程实例的管理，状态管理，审核管理。五个接口以及对应的API函数囊括了工作流管理系统的全部功能。一个完整的工作流管理系统就是以工作流引擎为中心，向外部部件（应用程序或其它工作流引擎）提供这五个接口，提供其实现的所有功能。第三章 系统分析与设计在所有准备工作完成后，我们就开始进行系统设计和设计，构造一个轻量级的工作流引擎。轻量级的工作流引擎并不完全实现WFMC所提出的工作流模型包含的五个接口，特别是接口4，在分布式工作流管理系统才具有该接口。既然我们从轻量级的概念出发，我们就不再明显区分各个接口的界限以及其所具有的特定的功能，以够用、灵活和低成本的设计原则去设计出我们所理解的工作流引擎。我们运用了面向对象的方法，首先从众多的业务需求中抽取出工作流模型所包含的对象，再分析各个对象之间的逻辑关系，然后提出一个系统结构，再进行模块划分，数据库设计，最终完成类的设计。我们当中所用到的建模工具就是ROSE UML。3.1 工作流模型的设计对工作流模型的设计是工作流引擎设计的重要组成部分。 3.1.1 工作流模型的对象企事业经营过程就是一项项业务的实现过程，我们从一般业务入手，并对这些业务进行详细的分析，研究，其结果就是得到一般性的业务对象，从而抽象成工作流模型对象。3.1.1.1 从一个简单的业务实例看业务的需求目前企事业的一项基本事务就是出差管理。它主要是对企事业的人员因为某种工作上的原因需要到别的地方出差进行的管理。我们可以列出出差的相关步骤： 申请人需要出差，并且他（她）具有出差的权利； 申请人填写出差表格，说明因何事出差，出差何处，申请出差金额，何时回来等等和出差相关的情况； 申请人需要其它说明的话，可以将更具体的说明以文档的形式保存下来； 申请人确认申请无误后提交申请，等待申请的结果； 根据规定，该申请必须先让申请人的上一级审批，那么该申请就会以一项工作项的形式交给该级领导处理； 处理该申请的领导对该申请进行处理，他（她）会先查看该申请所有的资料，包括出差申请表和与之相关的其它文档，然后对其进行审批，审批的结果是同意那么该次申请会交给再下一级领导处理；审批的结果不同意，该申请被打回，通知申请人申请不通过的结果。等所有需要审批的领导都审批通过了，该申请就成功完成，通知申请人申请通过的结果；申请人得到申请的结果，如果审批通过则准备出差，如果审批不通过则根据审批结果对该申请进行修改，重新提交申请； 申请事务结束。这是一个简单的业务实例，对该实例进行分析我们可以得到该业务的一些对象： 申请人：他（她）属于该企事业的某个部门的成员，并且具有启动该业务的权利； 审批领导：他（她）也属于该企事业的某个部门的成员，并且具有对该业务进行处理的权利； 出差表格：它是该业务规定的格式化资料，并且是必须的 出差具体说明：它是该业务附加的资料，可以不要的 申请人已经填写好的出差表格：它是出差表格的实例化，代表一个具体的应用 审批同意和不同意：它们是对该业务的处理，遵循一定的业务规则 申请：这是一个过程，不是一个动作，需要时间和人的活动才能完成 审批：这是一个活动，是过程的一部分，并且可以向另外一个活动转化 其它应用程序：申请人要填写出差具体说明时要调用相应的外部应用程序编辑该说明并以一定的格式保存下来，审批领导要查看出差具体说明时也要调用相应的外部应用程序打开该说明并以一定的格式显示出来。从这些业务对象，再利用工作流技术，我们可以得到工作流模型的一些基本对象： 用户：正如申请人，审批领导，他们就是工作流管理系统的用户，由他们去使用该系统的各种功能，并且直接参与业务活动，促使业务的完成。 角色：有些人可以申请出差，有些人对出差申请可以审批，这两种不同的人可以作为两个不同的角色。角色是具有某种使用系统特定功能的权利的一个人员或多个人员的组合。 工作流应用资料：出差申请表格，出差具体说明，这些就是对应某个具体业务（这里是出差管理）的相关资料，根据这些业务资料我们可以对该业务进行处理。 需激活的应用程序：在需要其它应用程序提供支持的时候，会去激活这些应用程序。 流程：整个出差申请的过程就是一个流程，它从整体去描述一个业务。 环节：又称活动，它反映了业务流程的局部情况，通常业务流程是由一个一个的环节组成。 流程实例：将该出差申请这个业务流程实例化，就得到一个流程实例。 环节实例：将流程的其中一个环节实例化，就得到一个环节实例。 业务规则：业务的开始和结束需要一定的条件，在处理业务的过程中必须按照一定的规则，这些都是业务规则，只有严格遵循业务规则，业务才能完成。3.1.1.2 工作流对象的具体分析和说明通过一个具体的业务我们可以得到工作流模型的一些对象，那么我们再对其他一般性业务进行分析，研究，我们就会找到它们的共同点，并归纳出基于这些业务的公共的对象，这些公共的对象的组合，就是一个通用的模型，也就是工作流模型，这个模型能去描述每个业务，是我们追求轻量级工作流引擎的最终成果。 用户：业务的执行者和参与者，对应于企事业的每一个雇员，是一个独立的、具有一定行为能力和一定技术能力的人的实体； 角色：以技能为前提，能够完成某项功能的人员的总称； 部门：对应于企事业的静态结构划分，由企事业的实际部门设置情况来决定，可以是传统的面向职能的，也可以是现在流行的面向过程与客户的； 职位：以行政责任为前提，代表了管理上的等级关系； 工作组：以执行某一任务为目标而动态组建的、跨部门划分的一种组织结构； 流程：对应于一个业务过程，表示一个业务由发起、处理、结束的一个过程； 流程实例：对应于一个业务流程具体应用，是业务流程实例化的表现形式； 环节：对应于业务流程中一个单一的业务操作，是流程按照业务要求的细化； 环节实例：对应于一个环节的具体应用，是环节实例化的表现形式； 工作流定义主信息：描述一个工作流模型的主要信息，从整体来描述工作流模型； 工作流附件信息：描述一个工作流模型所用到的附件信息，也就是工作流应用资料，或者叫业务资料。按照WFMC提出的工作流模型，这不是工作流模型所包含的对象，可是我们对其进行格式化，把它抽取成一个模型对象，用来规定了工作流模型在具体应用时所需业务资料的格式，我们把它分为两类： 表格类型：这是以表格的形式保存附件信息，可以用关系结构来定义附件信息，并保存在数据库中，每一条记录就是一个该附件的实例； 文档类型：只是以文件形式保存附件信息，可以是work文档，也可以是文本文件，它的实例化是就是一个一个带有对应某个业务应用标志的文件，保存在硬盘上 工作流实例信息：描述一个工作流模型实例化的信息，也作为启动一个工作流的信息，它记录该业务流程随着时间和人员的参与处理的不断变化，直到整个业务的结束； 工作项信息：描述参与某个业务应用时被分配到的一项任务，这就体现了参与人员和系统交互的典型特征； 业务规则：描述业务在运行的过程中必须要遵守的规定和原则，也是业务活动得以向另一个活动推进的规则。我们把它分为四类规则，分别是： 自动型：它主要描述一些只给参与人员查看业务信息的业务规则，例如通知、公文流转等等业务。该类业务不需要参与人员去审批或其它人为上的处理，只需要参与人员去查看其中的内容就足够，整个业务流程的完成是全自动的。 与聚合：业务活动的完成是需要参与该活动的所有人员都进行人为处理，其中有一个人员没对其进行处理，整个活动只能停在原地，等待所有人员的处理，当最后一个参与人员执行了处理工作，它才能完成。 或聚合：在参与某一业务活动的人员当中只要有一个对其进行处理，整个活动就可以完成。 投票聚合：统计参与该活动的参与人员的处理结果，当满足一定条件该活动才能完成。 转换条件：描述流程、活动状态改变时需要的条件，用于业务运行过程中的约束。例如流程的完成必须等待所有活动的完成才能完成，活动的完成必须按照业务规则去完成等等； 需激活的应用程序：工作流管理系统需要其它应用程序的支持，例如编辑和查看文本文件信息等等； 日志信息：描述工作流中所有的状态改变、事件和控制流相关资料的变化，工作流实例和环节实例的启动、结束、挂起和激活等等信息都会记录下来，以便对其进行管理。3.1.2 对象之间的逻辑关系在找出工作流模型的对象后，我们就开始分析它们之间的业务逻辑关系。3.1.2.1 对对象进行分类以及各个分类中对象之间的关系到此为止，我们有必要对工作流模型对象进行一下分类，根据工作流对象对工作流管理系统所起的作用我们可以分成以下几类： 组织模型组织模型描述了企事业的组织机构关系，包括的对象有用户，部门，职位，角色，工作组，它们的关系可以用下图表示： 设置负责组成组成资格组成部门职位用户工作组角色图3.1 组织模型结构 从图中可以看到它们之间的关系，用户是基本的单位，部门是由用户组成，每个用户对应一个职位，负责该职位所要求的职能，用户凭着某种资格赋予一种角色，工作组也由用户组成，也可以由角色组成。这几个基本的对象以及其关系所构成的组织模型，已经可以满足轻量级工作流引擎对组织模型的需要了。 工作流定义模型工作流定义模型描述了工作流模型的定义信息，包括工作流定义主信息，流程定义信息，环节定义信息，工作流附件信息，业务规则。它们之间的关系如下图：图3.2 工作流定义模型结构包含包含包含包含遵循包含工作流定义附件信息主信息业务规则环节流程包含 流程是包含若干环节的，而环节遵循一定的业务规则，再加上工作流主信息和附件信息，共同构成工作流定义模型。 工作流实例模型工作流实例模型描述了工作流模型实例化时的信息，通过这些信息我们可以知道实例过程中的各种状态变化和最终的结果，因而得到一个业务具体应用的情况。它包括流程实例，环节实例，工作流实例信息，工作项信息和转换条件，它们之间的关系如下图： 记录记录细化细化影响影响影响影响记录记录转换条件环节实例信息流程实例信息工作项信息工作流实例信息日志信息日志信息细化图3.3 工作流实例模型结构 转换条件影响工作流实例，流程实例，环节实例和工作项的状态，并由转换条件去决定它们的状态转变，工作流实例信息流程实例信息环节实例信息工作项信息，自上而下逐层细化，不但从全局了解业务运行情况，而且从局部了解业务运行的细节情况。而它们的状态改变都会记录在日志中，用以追踪工作流实例的运行情况。 外部支持模型外部支持模型在本文只包括一个对象，就是需激活的外部应用程序，严格来说这不是工作流模型的一部分，可是提供接口去激活所需的外部应用程序为工作流管理系统提供支持是工作流模型的功能之一。有了这些外部应用程序的支持，我们的工作流管理系统的功能才变得更完善。3.1.2.2 各个模型之间的逻辑关系不但模型中各个对象有一定的逻辑关系，而且各个模型之间也有一定的逻辑关系，如下图所示： 调用依赖使用使用角色和工作组用户定义工作流实例模型外部支持模型工作流定义模型组织模型图3.4 模型之间的关系 组织模型的用户定义工作流定义模型；工作流定义模型使用组织模型的角色和工作组，用来规定工作流模型的启动条件和任务分配条件，因为工作流模型的启动和任务的分配必须由一定的角色或工作组完成；工作流实例模型依赖工作流定义模型，同时使用组织模型的所有对象，并且调用外部支持模型为其提供支持。3.1.3 工作流实例，流程实例，环节实例和工作项的状态转换工作流实例，流程实例，环节实例和工作项从不同的层次去描述业务运行过程的具体情况，不同级别的用户可以看到业务运行的不同方面，创建工作流实例的用户可以看到工作流实例信息以及其状态转换，参与该工作流实例的用户可以看到工作项信息以及其状态的改变，系统管理员可以看到所有信息以及其状态的转换。 工作流实例状态图 创建管理员管理员管理员Running（运行）Completed（结束）正常情况Suspended(挂起)terminated(终止)Initial（初始化）图3.5 工作流实例状态图提交 流程实例状态图管理员管理员管理员Running（运行）Completed（结束）正常情况Suspended(挂起)terminated(终止)图3.6 流程实例状态图 环节实例状态图处理中接受完成正常处理没有完成异常处理回退处理提交给下一环节图3.5 环节实例状态图 工作项状态转换图等待操作完成通过没有完成不通过无操作，超时操作下一工作项回退处理已查看初始化未审批未查看图3.5 工作项状态图接受3.1.4 任务分派任务分派是工作流引擎的一个重要功能。当环节实例产生时，就会以一定的准则把需要处理的工作当作一项任务项（工作项）分派给参与该环节实例的所有用户，而这些用户是同属一个角色或者工作组的。我们又把角色和工作组进行细化，可以得到以下准则： 基于部门的：这就是说把任务分派到某个部门的所有人员，该部门的所有人员都参与了该项任务，因而会为该部门的所有人员都产生一个工作项； 基于职位的：这就是说把任务分派到某个职位的所有人员，同属该职位的所有人员都被分配到一项工作项； 基于部门职位的：这就是说把任务分派到某个部门的某个职位的所有人员，同属该部门的该职位的人员都被分配到一项工作项； 基于所有人的：这就是说把任务分派到该企事业的所有人，该企事业的所有人都被分配到一项工作项； 基于工作组的：这就是说把任务分派到该企事业的某个特定的工作组上，同属该组的所有人员都被分配到一项工作项。基于部门的，基于职位的，基于部门职位的和基于所有人的这四种类型，其实是基于角色的细化，通过这些准则的分类，我们尽量做到系统与企事业有较强的适应性，以及使系统在任务分派时有较大的灵活性。3.1.5 转换条件的满足工作流实例，流程实例，环节实例和工作项的状态转换有各自特定的条件，分别如下： 工作流实例的转换条件工作流实例从整体看业务运行过程，工作流实例被用户创建后就进行初始化并提交给工作流引擎，由工作流引擎去处理，此时实例处于运行状态；在运行过程中，它会根据流程实例的状态而不断进行本身的状态改变；当管理员由于某种原因要挂起它时，它就处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束；当它被正常处理完毕后，就正常结束。 流程实例的转换条件流程实例也从整体看业务的运行过程，流程实例在工作流实例初始化时就开始它的工作。在运行过程中，它会根据各个环节的完成程度来改变自己的状态，当所有环节实例都正常完成它就正常结束；管理员可能要挂起它使它处于挂起状态，直到管理员重新激活它使它处于运行状态或者终止它使它非正常结束。 环节实例的转换条件环节实例从某个方面看业务的运行过程，环节实例在流程实例运行时就开始它的工作处于处理中状态。之后环节实例的状态由两方面决定，一是工作项的处理结果，一是业务规则的规定。 如果业务规则是自动型的，不管工作项的处理结果怎样，当系统把任务项分派（给特定用户）完毕后，该环节实例就正常完成处于正常结束状态； 如果业务规则是与聚合的，系统分派完任务项后，当所有参与人员都正常处理完该环节各自的工作项后，该环节才正常完成处于正常结束状态；在处理过程中，只要有一个工作项是非正常处理的，该环节就非正常完成处于非正常结束状态；在处理过程中，有工作项还未被处理并且没有一个工作项被非正常处理，那么环节实例仍然处于处理中状态； 如果业务规则是或聚合的，系统分派任务后，只要有一个工作项是正常处理的，该环节实例就正常完成处于正常结束状态；如果所有同属该环节实例的工作项都被非正常完成，那么该环节实例就处于非正常结束状态； 如果业务规则是投票聚合的，系统分派任务后，统计工作项的完成程度，当正常完成的工作项数量达到一定数量时，该环节实例就正常完成处于正常结束状态；当正常完成的工作项数量不达到规定的数量时，该环节就非正常完成处于非正常结束状态；当所有工作项还没处理并且正常完成的工作项还没达到规定数量时，该环节实例仍然处于处理中状态。 工作项的转换条件工作项从更细节的方面看业务运行过程，工作项的状态转换要看参与人员对各自的工作项的处理情况和业务规则的规定。我们把与聚合，或聚合和投票聚合这些要人工干预的规则统称为人工型规则。 如果业务规则是自动型，同属该规则的工作项的状态就只有正常处理后的正常结束状态，当然如果对该工作项还没被处理则处于处理中状态，可这不对环节实例等产生影响； 如果业务规则是人工型，就会有正常处理和非正常处理两种情况，正常处理该工作项则使到该工作项处于正常结束状态，非正常处理该工作项则使到该工作项处于非正常结束状态。3.2 系统结构本着基于轻量级工作流引擎的原则，我们已经对工作流模型进行了详细的分析和详细的设计，在这里我们就提出一个系统结构，如下图所示：工作流定义器工作流解析器实例调度中心任务管理器任务分派器启动控制器工作流定义数据工作流实例数据日志数据工作流定义接口工作流实例接口组织定义数据组织定义接口组织定义器状态转换器组织管理器图3.6 工作流引擎系统结构图 从图中可以知道，系统提供了三类接口：组织定义接口、工作流定义接口和工作流实例接口。这三类接口实现了工作流模型的接口一，接口二，接口三和接口五规定的主要功能；系统有一个实例调度中心，这是一个很重要的部件，它控制工作流实例的运行，通过工作流解析器对该工作流模型进行解析其含义，通过任务分派器按照一定的分派准则把任务项分派给参与该工作流实例的用户，通过任务管理器管理各个任务项的信息，通过启动控制器控制工作流的启动权利和启动信息，通过状态转换器控制工作流实例、流程实例、环节实例和工作项的状态转换；组织定义器定义企事业的组织结构；工作流定义器定义工作流模型信息，并通过组织管理器得到组织定义信息，为工作流模型提供组织支持。各个部件处理的相关信息都保存在数据库中。3.3 系统模块的划分根据功能实现的不同我们进行模块的划分如下： 用户管理模块：对用户信息的管理，包括注册用户信息，注销用户信息，查询用户信息等功能； 部门管理模块：对企事业部门结构信息的管理，包括增加部门信息，删除部门信息，查询部门信息等等功能； 职位管理模块：对企事业职能信息的管理，包括增加职位信息，删除职位信息，查询职位信息等等功能； 角色管理模块：对企事业某种技能信息的管理，包括新增角色信息，删除角色信息，查询角色信息等等功能；- 工作流模型管理模块：对工作流定义模型信息的管理，包括定义新的工作流模型信息，删除旧的工作流模型信息，查询工作流模型信息； 工作流实例管理模块：对工作流实例信息的管理，包括启动一个新的工作流实例，查询工作流实例信息，按照一定的业务规则生成新的环节实例信息，为用户分派工作项，管理工作项信息，按照一定的转换条件为工作流实例、环节实例转换状态等等功能； 系统监控模块：为工作流实例，环节实例等的状态转换信息加入日志，挂起、激活工作流实例，强制结束工作流实例，为迟迟不对自己的工作项进行处理的用户发出提醒或警告信息，查看各个工作流实例的完成程度等等功能。功能模块的划分，为系统的实现做好充分的准备。3.4 数据库设计基于轻量级的工作流引擎的特点之一就是把系统相关的资料，如工作流模型定义信息，工作流实例信息，组织模型定义信息等等，都以特定的实体形式保存在关系型数据库中。 工作流定义主信息表（workflowTable）静态定义工作流主要信息，包括该工作流的标识ID（可以定义为以”WORKFLOW_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流名称，工作流描述，工作流类型（工作流的类型有自动型，人工型和混合型，自动型不需要人工参与，由工组流引擎自动执行，人工型需要人工参与，混合型包含了自动型和人工型），工作流创建日期，工作流创建者ID（即用户ID），工作流创建人名称（即用户名），工作流生命周期（每个工作流实例都有它的生命周期期限，在该期限内还没完成它的工作就直接死亡），目前该工作流实例数目（记录当前工作流实例数目），工作流启动者角色（指明该工作流可以由哪个角色发起，属于该角色的用户都可以启动该工作流模型对应的实例）。工作流重要信息还包括两方面，一是工作流附件，因为在工作流进行过程中，肯定会带有一些信息，这些信息对于出差申请来说就是出差申请表，对于公文流转来说就是以word文档形式的公文，对于通知来说可能就是以文本文档形式的通知书，等等；一是工作流流程描述，包括若干个环节（activity），这些环节有一定的顺序，表现工作流顺序执行的特征。把工作流附件和工作流流程描述从工作流定义分离出来，是基于工作流附件和工作流流程描述对于不同工作流有不同形式和数量的原因，有利于工作流附件和工作流流程描述的扩展。 工作流附件信息表（workflowAttachmentTable）静态定义工作流所需要的附件，包括附件ID（可以定义为以”Attachment_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），工作流ID（标识属于哪个工作流），附件类型（表或文件），附件名称（如果类型是表，则为该表的名称，如果是word文档，则为该文档名称，如果是文本文档，则为该文件名称），其它信息（如果类型为表格，该字段以一定的格式保存该附件表格的所有字段的各种信息，包括字段名称，字段数据类型，数据类型长度，字段描述）。 工作流流程描述表（workflowProcessTable）静态定义工作流的流程，由若干环节（activity）组成，一个环节为一条记录，包括工作流ID（环节所属工作流ID），环节ID（可以定义为以”ACTIVITY_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx”形式,x是自动生成的序号），环节名称（即该环节名称），环节描述（对该环节的具体描述），参与者角色ID（将相同权限的用户作为一个集合，在数据库以同一个角色操作数据库特定操作，该项标识角色ID），环节任务分派规则，上一个环节ID（保存上一个环节的ID，由这项可以判断该环节是否整个流程的开始环节，或者该环节的任务没有完成（审批不通过，或没在其生命周期期限内完成）时作回滚处理的重要数据项，根据这个数据项可以回滚到上一个环节），下一个环节ID（保存下一环节的ID，由这项可以判断该环节是否整个流程的结束环节，或者该环节的任务完成了，根据这个数据