工作分析基于的工作流管理系统分析.docx
《工作分析基于的工作流管理系统分析.docx》由会员分享，可在线阅读，更多相关《工作分析基于的工作流管理系统分析.docx（12页珍藏版）》请在冰点文库上搜索。
工作分析基于的工作流管理系统分析
（工作分析）基于的工作流管理系统分析
基于UML的工作流管理系统分析
0引言
随着社会生产的流程化，工作流起着越来越重要的作用。
根据WFMC的定义，工作流（Workflow）就是自动运作的业务过程部分或整体，表现为参和者对文件、信息或任务按照规程采取行动，且令其于参和者之间传递。
简单地说，工作流就是壹系列相互衔接、自动进行的业务活动或任务。
本文将详细介绍基于UML的工作流管理系统分析和建模。
1工作流概述
对工作流的研究起源于二十世纪七十年代，受网络的局限性，最初的工作流系统主要以企业内部的文档处理为主。
到了二十世纪九十年代，随着Internet技术的发展及应用，促进了电子商务应用的极大发展，使得公司和公司之间、公司内部部门之间以及子公司之间的业务相互处理成为可能，这为工作流的发展带来了很大的机遇和挑战。
根据国际有关组织的预测，随着电子商务的发展，以数据处理为中心的数据库产品已经进入稳定发展期，以业务过程处理为中心的工作流产品将进入高速发展期。
于国内，随着企业管理的规范化和规模的不断扩大，企业的计算机管理将不仅仅停留于信息资源管理上，而将向更复杂的业务过程管理迈进。
为了实现组织目标，有关业务活动依时序或逻辑关系相互连接构成业务流程。
于业务开展过程中，文档、信息或任务，依据组织规范于参和者之间传递、处理或执行。
总体业务流程中，实现了基于计算机辅助处理而达到自动化的全部或部分称为工作流。
也就是说，工作流是于计算机辅助下全部或部分自动执行的工作过程，该过程可运行于异质、分布的运行环境中，供多人协同工作。
工作流服务器是供业务流程可视化设计、管理和控制业务流程的运行、且于实际执行过程中可动态修改业务流程的壹种计算机软件平台。
它使得快速开发、部署和运行企业业务管理系统、电子商务系统等成为可能。
它也使得企业于复杂多变的市场环境中，为了快速适应市场的变化，于保存现有投资，现有系统不变的情况下，迅速调整业务或商务流程成为可能。
如它可应用于：
采购处理、各种申请、订单和报价处理、员工绩效考核、人事变动、贷款审批、索赔处理、B2B、电子商务等。
2工作流管理系统概述
工作流管理系统是定义、创建和执行工作流的系统，它是壹种特殊的计算机支持的协同处理（CSCW，ComputerSupportedCooperativeWork）软件系统。
工作流管理系统的产生
工作流管理系统（WfMS，WorkflowManagementSystem）是以计算机支持的分布式、协同工作业务流程的自动或半自动化为研究目标的软件系统。
随着计算机网络，特别是Internet/Intranet的迅猛发展和应用，计算机支持的分布式、协同工作的工作流系统于企、事业单位中的地位显得越来越重要，也有着广阔的前景。
工作流管理系统是定义、创建、执行工作流的系统。
开发这类软件系统就是要协调分布式、协同处理的各个节点上的活动，按照预定义的控制流程进行执行，以达到对它们的自动执行和有效的管理。
开发这类软件有很大的重复性，工作流管理系统就是将这类软件的公共的流程控制部分（工作流运行服务、引擎）、管理部分和其他公共部分抽象出来，形成壹种软件开发平台，用户只需要将它们的控制流程描述出来，该平台软件就可对它们的控制流程进行自动执行和有效地管理，而不需要对每次不同的应用重复地开发。
不同工作流管理系统能够有不同的实现方法，不同的底层通讯机制，应用的范围也可能有很大的差距，但所有的工作流管理系统从用户的应用层上来见，通用工作流管理系统应该能够提供以下三个方面的功能支持：
首先是建造功能，即对工作流的业务流程及组成这些业务流程的活动进行定义和建模。
其次是运行控制功能，即于壹定的运行环境下，负责创建、执行和控制工作流实例，激活相应的资源和应用，且完成过程中从壹个活动到另壹个活动的控制转移。
它是整个工作流管理系统的核心部分。
最后是运行交互功能，即于工作流实例的运行中，工作流管理系统和工作流参和者（业务工作的参和者或控制者）及外部应用程序进行交互的功能。
由于信息技术的发展和日趋激烈的商业竞争，人们不再满足于独立、零散的办公自动化和计算机应用，而是需要综合的、集成化的解决方案。
作为壹种对常规性事务进行管理、集成的技术，WfMS的出现是必然的。
它能够改进和优化业务流程，提高业务工作效率；实现更好的业务过程控制，提高顾客服务质量；提高业务流程的柔性等。
3工作流管理系统的组成
壹个完整的工作流管理系统中主要包括如下七个部分的部件和数据。
a.过程定义工具
过程定义工具被用来创建计算机可处理的业务过程描述。
它能够是形式化的过程定义语言或对象关系模型，也能够是简单地规定用户间信息传输的壹组路由命令。
b.过程定义
过程定义（数据）包含了所有使业务过程能被工作流执行子系统执行的必要信息。
这些信息包括起始和终止条件、各个组成活动、活动调度规则、各业务的参和者需要做的工作、关联应用程序和数据的调用信息等。
c.工作流执行子系统和工作流引擎
工作流执行子系统也称为（业务）过程执行环境，包括壹个或多个工作流引擎。
工作流引擎是WfMS的核心软件组元。
它的功能包括：
解释过程定义，创建过程实例且控制其执行，调度各项活动，为用户工作表添加工作项，通过应用程序接口（API，ApplicationProgramInterface）调用应用程序，提供监督和管理功能等。
工作流执行子系统能够包括多个工作流引擎，不同工作流引擎通过协作共同执行工作流。
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表示过程实例的状态机视图。
从图中能够见出，壹个工作流定义的过程实例，于运行时可能有五种不同的过程，分别为初始状态、就绪状态、运行状态、挂起状态和结束状态。
壹个过程实例于初始时，均为初始状态（initialstate）。
根据需要，某个过程实例被创建（create），成为就绪状态（Ready）。
随后，用户能够根据需要，选择就绪状态的过程实例进行启动（start），被启动的过程实例的状态就变为运行状态（Running）。
处于就绪状态和运行状态的过程实例均能够通过取消操作（abort）转变为结束状态（endstate）。
处于运行状态的过程实例，通过挂起操作（hold），能够转变为暂时停止的挂起状态（Holded），同时处于挂起状态的过程实例也能够通过运行操作（run）转变为运行状态。
挂起状态和结束状态的区别于于挂起状态且不释放所占用的资源，因而是能够恢复的。
最后，壹个处于运行状态的过程实例如果运行完毕，通过完成操作（finish）转变为结束状态。
状态机能够用于描述用户界面、设备控制和其它交互式子系统。
它们仍可用于于生命期中经历了若干特定阶段，每个阶段拥有特殊的行为的对象。
5.4创建活动视图
活动视图是用于显示执行某个计算过程中的运算活动的状态机的壹种特殊形式。
活动状态代表了运算执行的状态：
流程的步骤或操作的执行。
活动图描述了顺序和且发活动分组。
活动视图表达为活动图。
活动图包含活动状态。
活动状态表现了过程中语句的执行或工作流中活动的运行。
和壹般等待状态等待事件不同，活动状态等待的是运算的结束。
当活动结束时，执行处理到图中的下壹个活动。
前壹个活动结束时，活动图中的结束迁移被激发。
活动状态通常没有外部事件的迁移，但它们能够由外围状态的事件而被取消。
于活动图中，用左右俩段是圆弧的长方形表示活动，用较粗的横线表示活动的分发，用带有箭头的线表示活动处理的先后顺序。
图7表示用户的操作活动图。
用户于使用系统所提供的功能之前，首先应当登录系统，也就是说，操作的第壹步是登录（login）。
登录之后，用户能够于三种操作中任选壹个执行：
选择过程定义（chooseprocessdefine）、选择过程实例（chooseprocessinstance）以及选择工作项（chooseworkitem）。
这三个活动的执行，没有先后顺序，完全由用户进行选择。
当用户选择了过程定义后，能够创建壹个所选的过程定义的实例，也就是执行创建过程定义活动（createprocessdefine）；当用户选择了壹个过程实例后，根据这个过程实例状态的不同，能够对这个过程实例进行终止（abort）、启动（start）、挂起（hold）和运行（run）等操作，这些操作的执行是没有先后顺序的；当用户选择了壹个工作项后，能够执行这个工作项，也就是做这个工作项的内容（doworkitem）。
根据之上使用用例视图、交互视图、状态机视图以及活动视图对工作流管理系统所应具有的功能层次进行的分析，对通用工作流管理系统要达到的目标，应当有了壹个较为清晰的认识。
而这些认识和理解，将为进壹步的设计，奠定良好的基础。
升级会员 