工作流管理系统.docx

工作流管理系统.docx

《工作流管理系统.docx》由会员分享，可在线阅读，更多相关《工作流管理系统.docx（16页珍藏版）》请在冰点文库上搜索。

工作流管理系统

工作流管理系统

2008年10月28日星期二11:

37

     工作流管理系统（WorkflowManagementSystem,WfMS）是一个软件系统，它完成工作量的定义和管理，并按照在系统中预先定义好的工作流逻辑进行工作流实例的执行。

工作流管理系统不是企业的业务系统，而是为企业的业务系统的运行提供了一个软件的支撑环境。

     工作流管理联盟（WfMC，WorkflowManagementCoalition）给出的关于工作流管理系统的定义是：

工作流管理系统是一个软件系统，它完成工作流的定义和管理，并按照在计算机中预先定义好的工作流逻辑推进工作流实例的执行。

     看起来工作流管理系统与BOS（BusinessOperationSystem，企业业务系统）或ERP（EnterpriseResourcePlan,企业资源规划）都很相似，但它们的实质是有很大区别的。

工作流管理系统为BOS提供一个软件平台，这就如运行在PC机上的操作系统，因此工作流管理系统比BOS的应用范围更广，环境更复杂。

工作流管理系统与ERP的区别在于，ERP侧重于满足企业内部业务操作功能，提高工作效率，而工作流管理系统侧重于企业管理，面向市场和客户，提高对外业务水平。

一、工作流管理系统的产生

     工作流管理系统（WfMS，WorkflowManagementSystem）是以计算机支持的分布式、协同工作业务流程的自动或半自动化为研究目标的软件系统。

随着计算机网络，特别是Internet/Intranet的迅猛发展和应用，计算机支持的分布式、协同工作的工作流系统在企、事业单位中的地位显得越来越重要，也有着广阔的前景。

     工作流管理系统是定义、创建、执行工作流的系统。

开发这类软件系统就是要协调分布式、协同处理的各个节点上的活动，按照预定义的控制流程进行执行，以达到对它们的自动执行和有效的管理。

开发这类软件有很大的重复性，工作流管理系统就是将这类软件的公共的流程控制部分（工作流运行服务、引擎）、管理部分和其他公共部分抽象出来，形成一种软件开发平台，用户只需要将它们的控制流程描述出来，该平台软件就可对它们的控制流程进行自动执行和有效地管理，而不需要对每次不同的应用重复地开发。

     不同工作流管理系统可以有不同的实现方法，不同的底层通讯机制，应用的范围也可能有很大的差距，但所有的工作流管理系统从用户的应用层上来看，通用工作流管理系统应该能够提供以下三个方面的功能支持：

     首先是建造功能，即对工作流的业务流程及组成这些业务流程的活动进行定义和建模。

     其次是运行控制功能，即在一定的运行环境下，负责创建、执行和控制工作流实例，激活相应的资源和应用，并完成过程中从一个活动到另一个活动的控制转移。

它是整个工作流管理系统的核心部分。

     最后是运行交互功能，即在工作流实例的运行中，工作流管理系统与工作流参与者（业务工作的参与者或控制者）及外部应用程序进行交互的功能。

     由于信息技术的发展和日趋激烈的商业竞争，人们不再满足于独立、零散的办公自动化和计算机应用，而是需要综合的、集成化的解决方案。

作为一种对常规性事务进行管理、集成的技术，WfMS的出现是必然的。

它可以改进和优化业务流程，提高业务工作效率；实现更好的业务过程控制，提高顾客服务质量；提高业务流程的柔性等。

二、工作流管理系统的组成

     一个完整的工作流管理系统中主要包括如下七个部分的部件和数据。

a.过程定义工具

     过程定义工具被用来创建计算机可处理的业务过程描述。

它可以是形式化的过程定义语言或对象关系模型，也可以是简单地规定用户间信息传输的一组路由命令。

b.过程定义

     过程定义（数据）包含了所有使业务过程能被工作流执行子系统执行的必要信息。

这些信息包括起始和终止条件、各个组成活动、活动调度规则、各业务的参与者需要做的工作、相关应用程序和数据的调用信息等。

c.工作流执行子系统和工作流引擎

     工作流执行子系统也称为（业务）过程执行环境，包括一个或多个工作流引擎。

工作流引擎是WfMS的核心软件组元。

它的功能包括：

解释过程定义，创建过程实例并控制其执行，调度各项活动，为用户工作表添加工作项，通过应用程序接口（API，ApplicationProgramInterface）调用应用程序，提供监督和管理功能等。

工作流执行子系统可以包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。

d.工作流控制数据

     指被工作流执行子系统和工作流引擎管理的系统数据，例如工作流实例的状态信息、每一活动的状态信息等。

e.工作流相关数据

    指与业务过程相关的数据。

WfMS使用这些数据确定工作流实例的状态转移，例如过程调度决策数据、活动间的传输数据等。

工作流相关数据既可以被工作流引擎使用，也可以被应用程序调用。

f.工作表和工作表处理程序

    工作表列出了与业务过程的参与者相关的一系列工作项，工作表处理程序则对用户和工作表之间的交互进行管理。

工作表处理程序完成的功能有：

支持用户在工作表中选取一个工作项，重新分配工作项，通报工作项的完成，在工作项被处理的过程中调用相应的应用程序等。

g.应用程序和应用数据

     应用程序可以直接被WfMS调用或通过应用程序代理被间接调用。

通过应用程序调用，WfMS部分或完全自动地完成一个活动，或者对业务参与者的工作提供支持。

与工作流控制数据和相关数据不同，应用数据对应用程序来讲是局部数据，对WfMS的其他部件来说是不可见的。

三、工作流管理系统的分类

     工作流管理系统是大型信息系统中驱动业务流程的必备基础软件。

当前市场上存在很多产品声称是工作流系统，或者带有工作流特性。

最终用户和开发商在接触各种产品时，往往会产生很多困惑。

     从技术角度来看，可分为四类：

     ·基于Domino的工作流管理系统

     由于Domino在群件市场上的普及率，加上莲花公司对工作流概念的大力宣传，人们很容易误认为Domino是一个工作流系统。

实际上这种观点是完全错误的。

Domino充其量是一个可以编写带有流程的应用的编程和运行环境，其本身并不具备一个工作流管理系统的特征，如图形化的工作流定义、独立的工作流引擎、清晰的工作流访问接口等。

应用程序所需要的每一个工作流特性，都需要自己手工编写。

为了弥补Domino的不足，国内一些OA厂商在Domino上添加了用其他语言编写的图形化工作流定义组件，但这仍然不能叫做一个工作流管理系统。

基于Domino的工作流管理系统的典型例子实际上还是莲花公司推出的DominoWorkflow?

。

它运行在Domino平台上，为开发工作流应用提供了很大的便利。

当然，人们只能在Domino平台上使用它。

在为其他平台开发应用时，人们必须求助于其它工作流管理系统。

     ·基于消息中间件的工作流管理系统

     这方面的典型代表是IBM公司的MQSeriesWorkflow。

它通过MQSeries将不同的应用集成在一起，并形成业务流程。

它没有一个集中的工作流引擎。

当进行分布式的应用系统的集成时，它是一个不错的选择。

但当你需要为运行在单一服务器上的应用提供工作流功能，而且不想因此而购买一大套消息中间件的时候，你必须考虑别的选择。

     ·基于微软平台的工作流管理系统

     这方面的典型代表是Ultimus和微软公司在BizTalk中提供的工作流组件，它们为基于微软平台的工作流应用提供支撑。

     ·基于J2EE的工作流管理系统

     这类系统是我们本文讨论的重点。

随着Java技术的日趋成熟和应用面的扩大，绝大多数企业级的应用系统开始基于J2EE技术来设计，对在J2EE平台上的工作流系统的需求也越来越大。

这种工作流系统应用能够充分发挥J2EE技术的优势，提供高度的可靠性、可扩展性和安全性。

E-wayworkflow?

正是这种类型的系统。

     从产品化程度和存在形态来说，可分为两类：

     ·嵌入在已有产品中的工作流组件

     国内从事OA产品研发的公司都能生成有工作流功能的产品。

但大多数OA产品中只是包含了一个图形化的流程定义工具，并不是一个真正的工作流系统，不具备完整的工作流引擎、工作流管理功能，也没有清晰定义的接口。

其提供的功能有限，与系统的其他部分紧密耦合，不可能作为统一的工作流平台来建立各种应用系统，如行政审批系统，也无法提供给其他开发商使用。

又如内容管理系统，也往往含有自己的工作流管理功能，其情形也差不多。

     ·产品化的工作流管理系统

     这种系统从一开始就作为单独的工作流管理系统来设计，考虑到了符合相关的国际标准，由专业产商以产品的形式推出，并提供给其他厂商在各个行业的应用系统中采用，或由用户在进行系统整体设计的时候统一采购。

E-wayworkflow?

是产品化的工作流产品。

     从工作流产品和宿主系统之间的关系来说，可分为两类：

     ·封闭的开发环境

     这种产品强调在一个平台中提供完整的工作流引擎、表单工具和组织结构及权限管理工具，Ultimus和FormFlow就是典型的例子，这对于快速创建简单的基于流程的应用确实有帮助，但它们的问题在于，其系统结构一般是封闭的。

应用系统的开发者要么完全接受它所强制提供的结构，要么完全不采用它。

在开放性越来越成为趋势的情况下，这种产品难以适用于构建大型的复杂的系统。

     ·开放的可嵌入的工作流产品

     这类产品的设计思路与上面的一类不同，它们特别强调开放性和嵌入到宿主系统中的能力，采用组件化设计，并遵守业界的标准提供访问接口和扩展机制。

这类系统的典型代表是e-wayworkflow。

它能够迅速地嵌入到宿主系统中，并引用宿主系统的组织结构模型，而不会对宿主系统的结构产生负面的影响。

四、工作流管理系统带来的好处

     由于信息技术的发展和日趋激烈的商业竞争，人们不再满足于独立、零散的办公自动化和计算机应用，而是需要综合的、集成化的解决方案。

作为一种对常规性事务进行管理、集成的技术，WFMS的出现是必然的。

它可以带来以下收益：

     ·改进和优化业务流程，提高业务工作效率；

     ·实现更好的业务过程控制，提高顾客服务质量；

     ·提高业务流程的柔性等。

五、工作流管理系统的基本结构

     在这个一般结构模型中，有三种类型的部件：

     ·WFMS内提供各种功能支持的软件组元（用深色填充图形表示）；

     ·为一个或多个软件组元使用的各种系统定义和控制数据（未填充图形）；

     ·应用程序和数据库（浅色填充图形）。

六、工作流管理系统功能分析

     前面已经介绍过，一个完整的通用工作流管理系统应当包括七个部件，这里限于篇幅的原因，只对工作流管理系统的核心部分：

工作流执行子系统和工作流引擎进行分析。

     工作流管理系统核心功能

     工作流管理系统的核心组成部分称为工作流执行子系统，它为创建、初始化和执行过程实例提供了一个运行环境。

     在一个工作流执行子系统中可以包括一个或多个工作流引擎，前者是一种集中式的实现方式，而后者是一种分布式的实现方式。

分布式的实现方式又可以分为同构和异构两种不同的情况。

所谓同构是指在一个运行服务系统中包含了多个兼容的工作流引擎；所谓异构是指在工作流管理系统中包含了两个以上异构的工作流执行子系统。

     工作流引擎是工作流管理系统的核心软件部件。

它的主要功能有：

解释过程定义，控制过程实例（创建、激活、挂起、终止等），按照过程定义已确定的业务逻辑调用各项活动，为用户工作表添加工作项，维护工作流控制数据和工作流相关数据，调用应用程序，提供监督，管理和审计功能。

     工作流执行子系统涉及四种数据：

工作流控制数据、工作流相关数据、组织/角色模型数据和工作表。

     第一种，工作流控制数据。

指只由工作流执行子系统维护的内部控制数据，主要用于表示过程实例与活动实例的状态信息。

     第二种，工作流相关数据。

指与业务过程相关的数据，他们由应用程序或由用户通过工作项处理来产生和更新，工作流引擎根据相关数据来确定过程实例的状态转移，例如过程调度决策数据、活动间的传输数据等。

     第三种，组织/角色模型数据。

是描述组织结构的数据，主要用于确定工作项的执行者。

     第四种，工作表。

列出了与工作流参与者相关的一系列工作项。

七、工作流管理系统的标准和产品

     工业界的许多人将工作流管理奉为90年代的软件技术。

近年来，工作流技术得到长足的发展。

1993年成立了工作流管理联盟（WorkflowManagementCoalition,WFMC）。

此后，该组织颁布了一系列工作流产品标准，包括工作流参考模型、工作流术语表、工作流管理系统各部分间接口规格、工作流产品的互操作性标准等。

这些举措加速了工作流技术的商品化。

现在，许多公司都基于这些标准推出了自己的工作流产品，如ActionTechnologiesInc.的ActionWorkflow、IBM的FlowMark等。

LotusNotes等群件产品也具备较强的工作流支持功能。

这些产品为我们开发自己的工作流应用提供了条件。

     工作流管理系统的应用

     和其他的软件产品一样，用户可以引进成熟的工作流和群件产品，也可以自行开发适合自己业务的工作流系统，特别是基于Intranet的工作流应用。

与Intranet技术相结合，工作流系统更具开放性，有更多的工具可供选用，且Browser/Server风格的界面简单易用，这也是当前工作流产品的发展方向。

     另外值得注意的是，WFMS的引入是与管理思想和管理业务的转变密切相关的。

一般来说，我们应把WFMS的引进视为改进或重组业务流程的机遇。

WFMS可以和企业再造或规范化管理相结合。

企业再造追求的是对企业的经营管理模式和生产作业程序进行彻底的革命性变革。

规范化管理则是在管理经验的基础上对业务过程进行科学化、规范化研究，以建立一套完整的管理工作规范体系为目标。

这种规范化一般会促进系统组织结构和运行的改善。

     目前在国外，企业再造和工作流系统的关系较为人们所关注，如WorkflowAndReengineeringInternationalAssociation（WARIA）就是致力于此的国际组织。

然而，由于国情不同，我国多数企事业单位面临的主要管理问题是随意性大、运行不规范。

除了少数企业外，大部分单位不需要、也不可能进行革命性的重组。

因此，相对于企业再造理论，规范化管理在我国更现实、更可行，更适于和WFMS的引进相结合。

八、建模实例

     1创建用例视图

     用例视图从外部用户的角度捕获系统的行为。

它将系统功能划分为对活动者（系统的理想用户）具有意义的事务。

这些功能片被称为用例。

用例通过系统与一个或多个活动者之间的一系列消息描述了与活动者的交互。

其活动者包括人员、其它的计算机系统和进程。

活动者用一个小人表示，活动者的名字标在这个小人的下方。

用例用一个椭圆表示，用例的名字标在椭圆中或下方，用实线与同自身通信的活动者相连接。

用例视图对活动者，所感知的系统功能进行建模，目的是列举活动者和用例，显示活动者在每个用例中的参与情况。

     a.工作流执行子系统

     图1表示工作流执行子系统的用例图。

活动者包括WfClient（工作流客户端）、Monitor（工作流监控端）、DefinitionDB（工作流定义数据库）、EnactmentDB（工作流运行数据库）、OrganizationDB（组织机构数据库）、ApplicationDB（应用程序数据库）、WorkItemDB（工作项数据库）、ConfigFile（工作流系统配置文件）。

这里，WfClient作为接收用户交互的界面部分，将用户所作的行为，依照固定的规则，将请求送给工作流执行子系统进行处理。

Monitor作为接收系统管理员交互的界面部分，将系统管理员对系统作出的调整，发送给工作流执行子系统进行处理。

其余的DefinitionDB等活动者，负责将工作流执行子系统每一步的操作与状态记录到数据库中，以永久保存。

用例包括ResourceLocate（资源定位）、EngineContainer（引擎容器）、ProcessDefLoad（定义装载）、ProcessMonitor（过程监控）、Util（公用程序）。

其中，EngineContainer通过ResourceLocate定位所有系统所用到的资源，表EngineContainer用例使用ResourceLocate用例，用带有箭头的实线表示。

EngineContainer不直接与用户交互，活动者对工作流的参与都是通过ProcessMonitor这个工作流执行子系统的入口来进行的。

EngineContainer通过ProcessDefLoad将现有的工作流定义装入，这样才能运行该工作流，EngineContainer用例与ResourceLocate用例之间是使用关系。

     这里仅给出用例ProcessMonitor的具体功能分析。

这些功能分析作为对ProcessMonitor用例的注释，不在用例图上标识，只作为系统详细设计时的要点。

对其余用例的分析方法与之类似。

     过程监督服务器作为引擎容器的一部分，主要提供外部对引擎容器的运行状况的监督，即对引擎当前运行状况的查询。

     譬如，当客户端或管理端需要了解引擎的运行状况时，首先发出一个消息请求，消息服务器接受到该消息后对消息进行解释，如果属于查询引擎的运行状况，则调用监督服务部分提供的API（应用程序接口）对引擎进行查询，然后将结果返回至请求者。

     监督服务器处理的查询请求根据请求对象的不同主要有如下内容：

     引擎容器运行状况的查询；各引擎运行状况的查询；过程定义信息的查询；过程实例信息的查询；活动实例信息的查询；工作项信息的查询；同步命令请求的响应。

     b.工作流引擎　

     图2表示工作流引擎的用例图。

其中的活动者包括EngineManager（引擎管理器）与LogFiles（日志文件）。

EngineManager负责控制工作流中所有元素的状态，是工作流调度的核心。

LogFiles阶段性将固定格式的文字记录为日志，用以保存。

这里的用例有ProcessControl（控制过程实例）、TransitionControl（控制转移）、ActivityControl（控制活动）、WorkItemControl（控制工作项）、DanamaticModify（动态修改流程）、CreateLogfile（创建日志文件）。

EngineManager根据一定的条件，通过ProcessControl、TransitionControl、ActivityControl、WorkItemControl与DanamaticModify，控制工作流各个组成元素的状态，以达到控制工作流的目的。

     c.过程监督

     图3表示过程监督用例图。

其中的活动者包括EnactmentDB（工作流运行数据库）与engineContainer（引擎容器）。

用例有EngineQuery（对引擎的查询）、ProcessDefQuery（对过程定义信息的查询）、EngineContainerQuery（引擎容器运行状况的查询）、ProcessInstanceQuery（对过程实例进行查询）、ActivityInstanceQuery（对活动实例进行查询）、WorkItemQuery（对工作项进行查询）、TransitionQuery（对转移信息查询）。

     这里仅对用例ProcessInstanceQuery进行详细功能分析，对其余用例的分析方法与之类似。

ProcessInstanceQuery是对系统中的过程实例进行查询，主要包含如下内容：

取得过程实例列表：

得到系统中的所有过程实例的一个列表；从过程实例列表中取得一个过程实例的信息；根据给定的过程实例编号得到该过程实例的详细信息；关闭已经打开的过程实例列表；取得系统中过程实例的各种状态的一个列表；根据给定的过程实例编号查询其状态；关闭打开的过程实例列表；取得系统中过程实例的各种属性信息的列表。

     2创建交互视图

     交互视图描述了实现系统行为角色之间的消息交换序列。

分类角色是对交互中充当特殊角色的对象的描述。

交互视图提供了系统中行为在全局的描述，显示了多个角色间的控制流程。

交互视图用侧重点不同的两种图来显示：

顺序图和协作图。

消息指角色间的单向通信，从发送者到接收者的携带信息的控制流。

消息可能带有角色间传递值的参数。

     顺序图和协作图均显示了交互，但它们强调了不同的方面。

顺序图显示了时间顺序，但角色间的关系是隐式的。

协作图表现了角色之间的关系，并将消息关联至关系，但时间顺序由于用顺序号表达，并不十分明显。

每一种图应根据主要的关注焦点而使用。

     a.顺序图

     顺序图表示了随时间安排的一系列消息。

每个分类角色显示为一条生命线，代表整个交互期间上的角色。

消息则显示为生命线之间的箭头。

顺序图可以表达场景，即一项事务的特定历史。

     顺序图以二维图表来显示交互。

纵向是时间轴，时间自上而下。

横向显示了代表协作中单个对象的分类角色。

每个对象用方框表示，对象的名字在方框内部，并在名字的下方加下划线。

每个分类角色表现为垂直列－生命线。

在角色存在的时间内，生命线显示为虚线；在角色的过程激活时间内，生命线显示为双线。

     消息显示为从一个角色生命线出发至另一个角色生命线的箭头，箭头用从上而下来的时间顺序来安排。

     顺序图的一个用途是显示用例的行为序列。

当行为被实现时，每个顺序图中的消息同对象的操作或状态机中迁移上的事件触发相一致。

     图4表示处理请求用例的顺序图。

图中五个方框分别表示五个对象：

ProcessMonitor、EngineManager、Engine、EntactmentDB、Logfiles。

这个用例是由ProcessMonitor接收用户操作，再将这些操作转换成固定的请求，发送给引擎执行而产生的。

     当ProcessMonitor接收到用户在界面上所作的操作后，将这些操作转换为固定的命令请求，发送给EngineManager。

EngineManager再根据接收到命令的类别，将命令分发给不同的Engine。

Engine则具体执行相应的命令。

Engine执行完命令后，通知EntactmentDB修改相应的数据。

接下来，Engine再通知Logfiles将所作的操作记录下来，以供以后查询。

最后，Engine直接将结果返回给ProcessMonitor，由ProcessMonitor将结果包装，显示给用户。

     b.协作图

     协作图对交互中存在意义的对象和链建模。

对象和链仅在提供的上下文中存在意义。

分类角色描述了对象，关联角色描述了协作中的链。

协作图通过图形的几何排布显示交互中的角色。

消息显示为附属在连接分类角色的关系直线上的箭头。

消息的顺序由消息描述前的顺序号来表示。

     协作图的一个用途是表现操作的实现。

协作显示了操作的参数和局部变量