基于UML的工作流管理系统分析

0 引言

随着社会生产的流程化，工作流起着越来越重要的作用。根据 WFMC 的定义，工作流（Workflow）就是自动运作的业务过程部分或整体，表现为参与者对文件、信息或任务按照规程采取行动，并令其在参与者之间传递。简单地说，工作流就是一系列相互衔接、自动进行的业务活动或任务。本文将详细介绍基于UML的工作流管理系统分析与建模。

1 工作流概述

对工作流的研究起源于二十世纪七十年代，受网络的局限性，最初的工作流系统主要以企业内部的文档处理为主。到了二十世纪九十年代，随着Internet 技术的发展及应用，促进了电子商务应用的极大发展，使得公司与公司之间、公司内部部门之间以及子公司之间的业务相互处理成为可能，这为工作流的发展带来了很大的机遇和挑战。

根据国际有关组织的预测，随着电子商务的发展，以数据处理为中心的数据库产品已经进入稳定发展期，以业务过程处理为中心的工作流产品将进入高速发展期。在国内，随着企业管理的规范化和规模的不断扩大，企业的计算机管理将不仅仅停留在信息资源管理上，而将向更复杂的业务过程管理迈进。

为了实现组织目标，有关业务活动依时序或逻辑关系相互连接构成业务流程。在业务开展过程中，文档、信息或任务，依据组织规范在参与者之间传递、处理或执行。总体业务流程中，实现了基于计算机辅助处理而达到自动化的全部或部分称为工作流。也就是说，工作流是在计算机辅助下全部或部分自动执行的工作过程，该过程可运行于异质、分布的运行环境中，供多人协同工作。工作流服务器是供业务流程可视化设计、管理和控制业务流程的运行、并在实际执行过程中可动态修改业务流程的一种计算机软件平台。它使得快速开发、部署和运行企业业务管理系统、电子商务系统等成为可能。它也使得企业在复杂多变的市场环境中，为了快速适应市场的变化，在保存现有投资，现有系统不变的情况下，迅速调整业务或商务流程成为可能。如它可应用在：采购处理、各种申请、订单与报价处理、员工绩效考核、人事变动、贷款审批、索赔处理、B2B、电子商务等。

2 工作流管理系统概述

工作流管理系统是定义、创建和执行工作流的系统，它是一种特殊的计算机支持的协同处理（CSCW，Computer Supported CooperativeWork）软件系统。

工作流管理系统的产生

工作流管理系统（WfMS，WorkflowManagementSystem）是以计算机支持的分布式、协同工作业务流程的自动或半自动化为研究目标的软件系统。随着计算机网络，特别是Internet/Intranet 的迅猛发展和应用，计算机支持的分布式、协同工作的工作流系统在企、事业单位中的地位显得越来越重要，也有着广阔的前景。

工作流管理系统是定义、创建、执行工作流的系统。开发这类软件系统就是要协调分布式、协同处理的各个节点上的活动，按照预定义的控制流程进行执行，以达到对它们的自动执行和有效的管理。开发这类软件有很大的重复性，工作流管理系统就是将这类软件的公共的流程控制部分（工作流运行服务、引擎）、管理部分和其他公共部分抽象出来，形成一种软件开发平台，用户只需要将它们的控制流程描述出来，该平台软件就可对它们的控制流程进行自动执行和有效地管理，而不需要对每次不同的应用重复地开发。

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

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

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

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

由于信息技术的发展和日趋激烈的商业竞争，人们不再满足于独立、零散的办公自动化和计算机应用，而是需要综合的、集成化的解决方案。作为一种对常规性事务进行管理、集成的技术，WfMS 的出现是必然的。它可以改进和优化业务流程，提高业务工作效率；实现更好的业务过程控制，提高顾客服务质量；提高业务流程的柔性等。

3 工作流管理系统的组成

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

a.过程定义工具

过程定义工具被用来创建计算机可处理的业务过程描述。它可以是形式化的过程定义语言或对象关系模型，也可以是简单地规定用户间信息传输的一组路由命令。

b.过程定义

过程定义（数据）包含了所有使业务过程能被工作流执行子系统执行的必要信息。这些信息包括起始和终止条件、各个组成活动、活动调度规则、各业务的参与者需要做的工作、相关应用程序和数据的调用信息等。

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

工作流执行子系统也称为（业务）过程执行环境，包括一个或多个工作流引擎。工作流引擎是WfMS 的核心软件组元。它的功能包括：解释过程定义，创建过程实例并控制其执行，调度各项活动，为用户工作表添加工作项，通过应用程序接口（API，Application Program Interface）调用应用程序，提供监督和管理功能等。工作流执行子系统可以包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。

d.工作流控制数据

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

e.工作流相关数据

指与业务过程相关的数据。WfMS 使用这些数据确定工作流实例的状态转移，例如过程调度决策数据、活动间的传输数据等。工作流相关数据既可以被工作流引擎使用，也可以被应用程序调用。

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

工作表列出了与业务过程的参与者相关的一系列工作项，工作表处理程序则对用户和工作表之间的交互进行管理。工作表处理程序完成的功能有：支持用户在工作表中选取一个工作项，重新分配工作项，通报工作项的完成，在工作项被处理的过程中调用相应的应用程序等。

g.应用程序和应用数据

应用程序可以直接被WfMS 调用或通过应用程序代理被间接调用。通过应用程序调用，WfMS 部分或完全自动地完成一个活动，或者对业务参与者的工作提供支持。与工作流控制数据和相关数据不同，应用数据对应用程序来讲是局部数据，对WfMS 的其他部件来说是不可见的。

 

术语解释

表1 工作流管理系统术语解释

术语／缩写	解   释
过程定义	由过程定义工具所定义的一个工作流过程
过程实例	过程定义运行之后转化为过程实例，一个过程定义可以产生多个过程实例
活动	一个相对独立的工作的描述，它是过程定义的一个重要组成部分
活动实例	活动运行之后的一个实例
工作项	在一个活动实例中，工作流参与者所需执行的工作
工作项列表	一个参与者所负责的所有工作项的详细描述
信牌箱	活动之间传递信息的驿站
转移	从活动到信牌箱或从信牌箱到活动，描述信牌箱与活动之间关系的连接
工作流控制数据	表示过程实例、活动实例的状态信息
工作流相关数据	与业务过程相关的数据，工作流引擎根据它们来确定过程实例的状态转移
日志数据	系统中所有发生的事件及相应数据的记录
运行服务器	负责整个过程的运行、调度、查询及日志的记录等
过程定义状态	表示过程定义目前所处的状态，如：是否已发布等
过程实例状态	表示过程实例目前所处的状态，如：运行、挂起等
活动实例状态	表示活动实例目前所处的状态，如：运行、挂起等
工作项状态	表示工作项目前所处的状态，如：运行、挂起等
引擎	运行服务器的核心，负责过程实例的执行、调度
引擎容器	包含了多个引擎，并提供多引擎管理功能

 

4 工作流管理系统功能分析

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

 工作流管理系统核心功能

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

在一个工作流执行子系统中可以包括一个或多个工作流引擎，前者是一种集中式的实现方式，而后者是一种分布式的实现方式。分布式的实现方式又可以分为同构和异构两种不同的情况。所谓同构是指在一个运行服务系统中包含了多个兼容的工作流引擎；所谓异构是指在工作流管理系统中包含了两个以上异构的工作流执行子系统。

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

工作流执行子系统涉及四种数据：工作流控制数据、工作流相关数据、组织/角色模型数据和工作表。

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

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

第三种，组织/角色模型数据。是描述组织结构的数据，主要用于确定工作项的执行者。

第四种，工作表。列出了与工作流参与者相关的一系列工作项。

5 建模实例

5.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 是对系统中的过程实例进行查询，主要包含如下内容：取得过程实例列表：得到系统中的所有过程实例的一个列表；从过程实例列表中取得一个过程实例的信息；根据给定的过程实例编号得到该过程实例的详细信息；关闭已经打开的过程实例列表；取得系统中过程实例的各种状态的一个列表；根据给定的过程实例编号查询其状态；关闭打开的过程实例列表；取得系统中过程实例的各种属性信息的列表。

5.2 创建交互视图

交互视图描述了实现系统行为角色之间的消息交换序列。分类角色是对交互中充当特殊角色的对象的描述。交互视图提供了系统中行为在全局的描述，显示了多个角色间的控制流程。交互视图用侧重点不同的两种图来显示：顺序图和协作图。

消息指角色间的单向通信，从发送者到接收者的携带信息的控制流。消息可能带有角色间传递值的参数。

顺序图和协作图均显示了交互，但它们强调了不同的方面。顺序图显示了时间顺序，但角色间的关系是隐式的。协作图表现了角色之间的关系，并将消息关联至关系，但时间顺序由于用顺序号表达，并不十分明显。每一种图应根据主要的关注焦点而使用。

a.顺序图

顺序图表示了随时间安排的一系列消息。每个分类角色显示为一条生命线，代表整个交互期间上的角色。消息则显示为生命线之间的箭头。顺序图可以表达场景，即一项事务的特定历史。

顺序图以二维图表来显示交互。纵向是时间轴，时间自上而下。横向显示了代表协作中单个对象的分类角色。每个对象用方框表示，对象的名字在方框内部，并在名字的下方加下划线。每个分类角色表现为垂直列－生命线。在角色存在的时间内，生命线显示为虚线；在角色的过程激活时间内，生命线显示为双线。

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

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

 

图4 表示处理请求用例的顺序图。图中五个方框分别表示五个对象：ProcessMonitor、EngineManager、Engine、EntactmentDB、Logfiles。这个用例是由ProcessMonitor 接收用户操作，再将这些操作转换成固定的请求，发送给引擎执行而产生的。

当ProcessMonitor 接收到用户在界面上所作的操作后，将这些操作转换为固定的命令请求，发送给EngineManager。EngineManager 再根据接收到命令的类别，将命令分发给不同的Engine。Engine 则具体执行相应的命令。Engine 执行完命令后，通知EntactmentDB 修改相应的数据。接下来，Engine 再通知Logfiles 将所作的操作记录下来，以供以后查询。最后，Engine 直接将结果返回给ProcessMonitor，由ProcessMonitor将结果包装，显示给用户。

b.协作图

协作图对交互中存在意义的对象和链建模。对象和链仅在提供的上下文中存在意义。分类角色描述了对象，关联角色描述了协作中的链。协作图通过图形的几何排布显示交互中的角色。消息显示为附属在连接分类角色的关系直线上的箭头。消息的顺序由消息描述前的顺序号来表示。

协作图的一个用途是表现操作的实现。协作显示了操作的参数和局部变量，以及更永久性的关联。当行为被实现时，消息的顺序与程序的嵌套调用结构和信号传递一致。

 

图5表示对应于处理请求用例的协作图。这个用例是由ProcessMonitor 接收用户操作，再将这些操作转换成固定的请求，发送给引擎执行而产生的。这个协作图表现了处理请求用例所涉及的五个相关对象之间相互协作的关系。

5.3 创建状态机视图

状态机视图通过对一种对象的可能生命历史进行建模，描述了对象在时间序列上的动态行为。每个对象被认为是通过检测事件并对之响应来与外界进行通讯的孤立实体。事件表达了对象可以检测的变动－对象间的调用或显示信号、某个值的改变或时间的推移。任何影响对象的事物可以被描述成事件。真实世界发生的事情被建模成外部世界至系统的信号。

状态指就某个特定类而言，对于发生的事件具有相同性质响应的一系列对象值。换言之，同一状态的所有对象以相同的方式响应某个事件，即对于给定的所有对象在接收到同一事件时执行相同的动作。而不同状态的对象可能对相同事件具有不同的响应，执行不同的动作。

状态机包含由事件连接的状态。每个状态对对象生命期中的一段时间建模，该时间内对象满足一定的条件。当事件发生时，它可能导致迁移的激发，使对象改变至新状态。当迁移激发时，附属于迁移的动作可    能被执行。状态机在UML 中显示为状态图。

在状态机视图中，状态用带圆角的长方形表示，初始状态用实心填充的圆表示，结束状态用实心填充的圆外套一个圆圈表示。

 

图6 表示过程实例的状态机视图。从图中可以看出，一个工作流定义的过程实例，在运行时可能有五种不同的过程，分别为初始状态、就绪状态、运行状态、挂起状态与结束状态。

一个过程实例在初始时，均为初始状态（initial state）。根据需要，某个过程实例被创建（create），成为就绪状态（Ready）。随后，用户可以根据需要，选择就绪状态的过程实例进行启动（start），被启动的过程实例的状态就变为运行状态（Running）。处于就绪状态和运行状态的过程实例都可以通过取消操作（abort）转变为结束状态（end state）。处于运行状态的过程实例，通过挂起操作（hold），可以转变为暂时停止的挂起状态（Holded），同时处于挂起状态的过程实例也可以通过运行操作（run）转变为运行状态。挂起状态与结束状态的区别在于挂起状态并不释放所占用的资源，因而是可以恢复的。最后，一个处于运行状态的过程实例如果运行完毕，通过完成操作（finish）转变为结束状态。

状态机可以用于描述用户界面、设备控制和其它交互式子系统。它们还可用于在生命期中经历了若干特定阶段，每个阶段拥有特殊的行为的对象。

5.4 创建活动视图

活动视图是用于显示执行某个计算过程中的运算活动的状态机的一种特殊形式。活动状态代表了运算执行的状态：流程的步骤或操作的执行。活动图描述了顺序和并发活动分组。活动视图表达为活动图。

活动图包含活动状态。活动状态表现了过程中语句的执行或工作流中活动的运行。与一般等待状态等待事件不同，活动状态等待的是运算的结束。当活动结束时，执行处理到图中的下一个活动。前一个活动结束时，活动图中的结束迁移被激发。活动状态通常没有外部事件的迁移，但它们可以由外围状态的事件而被取消。

在活动图中，用左右两段是圆弧的长方形表示活动，用较粗的横线表示活动的分发，用带有箭头的线表示活动处理的先后顺序。

 

图7 表示用户的操作活动图。用户在使用系统所提供的功能之前，首先应当登录系统，也就是说，操作的第一步是登录（login）。登录之后，用户可以在三种操作中任选一个执行：选择过程定义（choose process define）、选择过程实例（choose process instance）以及选择工作项（choose workitem）。这三个活动的执行，没有先后顺序，完全由用户进行选择。

当用户选择了过程定义后，可以创建一个所选的过程定义的实例，也就是执行创建过程定义活动（create process define）；当用户选择了一个过程实例后，根据这个过程实例状态的不同，可以对这个过程实例进行终止（abort）、启动（start）、挂起（hold）与运行（run）等操作，这些操作的执行是没有先后顺序的；当用户选择了一个工作项后，可以执行这个工作项，也就是做这个工作项的内容（do workitem）。

根据以上使用用例视图、交互视图、状态机视图以及活动视图对工作流管理系统所应具有的功能层次进行的分析，对通用工作流管理系统要达到的目标，应当有了一个较为清晰的认识。而这些认识与理解，将为进一步的设计，奠定良好的基础。