UML软件工程组织

 

 

工作流管理与事务服务设计方案
 
2008-06-30 来源:网络
 

4.4.1 应用案例

城市政府宽带网络软件平台连接一个城市的市政府、党的机关、人大、政法四大类几十甚至上百个机关。政府部门中有大量的工作是需要部门内、部门之间的多部门、多工作岗位、多工作人员协同工作来完成的。而且其工作呈工作流状态和事务性状态(既工作流程的完整性)。

例一:公文的起草到完成、存档,构成了一个典型的工作流:

例二:跨部门的审批。市民、企业到政府机关办理证件、执照,往往要启动一个跨部门的协同工作流。一个大、中型城市的财政局的办事流程有100多个,而约有1/3的办事流程都是要经过物价局、公安局、主管厅等。而且办事流程会因各种原因作出三种选则:推回上一环节重新审批;通知流程启动者,该项事务作废;通知流程启动者,补办有关手续,待手续补办完毕,流程再往下进行。

例三:政府网上采购,由政府内部启动复杂工作流。政府网上采购有四个特点:公开性,为了杜绝腐败,流程全程公开;协同性,政府机关、企业、银行、有关专家多家联动;复杂性,流程会在多种类型的参加者之间反复互动,既有同步,也有异步;长时间,工作流会延迟至数周到一月以上。

一个完整的采购项目大至有如下的阶段:

阶段名称 分阶段名称 处理内容
计划 提出采购申请 填写采购清单
领导审批 多个领导签字
提交采购中心 统一的政府机构汇总
中心确认采购 中心负责人签字
资源确认 决定交易机制 竟标、询价或指定
招标竟标 委托招标公司
供应商信息管理 收集、查询相关档案
交易执行 要货订单发布 给供应商发订单
订单追踪 供应商查询未完订单
供货合同管理 签订合同、合同归档
库存查询 供应的商品库存
执行情况查询 到货、质量等情况
后续处理 收货管理
发票管理
付款管理
质量控制
供应商评估
供应商发布修改

根据上述三个案例的分析,有以下几点是带有共性的:

1) 业务模型:多节点、多路径信息传递与返回的同步/异步工作流模型

2) 工作流以单位为节点,而每一个节点中又可嵌套子工作流。

3) 工作流中的节点之间可以是并行、串行、选择三种工作顺序

4) 每一个节点中对信息加工处理的环境可能是异构的。

4.4.2 工作流结构的基本原理

4.4.2.1 工作流的模式分析

1、工作流的定义

工作流管理委员会把工作流定义为:工作流是一类能够完全或部分自动执行的业务过程。根据一系列规则,文档、信息、任务能够在不同的执行者之间传递、执行。完成正个过程所需要的参数有:

过程中每一单独步骤的定义,每一步骤由谁负责,每个活动需要的应用程序。定义一个工作流就是说明了处理过程是什么:由哪些活动、任务组成即流的结构。如何做:活动间的执行条件、规则,所交互的信息即控制流与信息流的定义,谁来做:人还是应用程序即角色定义,做得怎么样:对工作流的执行状态实施监控。

2、工作流的模式

工作流模型是办公事务中所包含的任务体及其执行规则的形式化。而在这众多的工作流模型中还存在着公共的部分,我们称这种公共的部分为"工作流模式"。工作流模式是流中公共的、抽象的、为大多数人所承认的、可以被重用的逻辑单元。在面向对象的程序设计中,模式由于能大大提高工作效率而被广泛使用。在工作流模型中也可可抽象出模式。

1) 顺序模式:只能一个一个按顺序执行的工作方式。

可用BPEL4WS描述如下:

  1. <sequence standard-attributes>
  2. activity F1
  3. activity F2
  4. activity F3
  5. </sequence>

也可用<links>描述。

2) 并行交叉模式:在过程的某一点,一个线程变成多个可并行执行的线程。而在这种模式中满足文件的会签等业务是一种同步控制方式。

在BPEL4WS中,并行和同步模式可用<flow>描述如下:

  1. <sequence>
  2. <flow>
  3. activityA
  4. activityB
  5. </flow>
  6. activityC
  7. </sequence>

其中<flow>标签中的内容可按任意顺序执行。若要表示同步执行,则要用控制链定义:

  1. <flow name="F">
  2. <links>
  3. <link name="L1"/>
  4. <link name="L2"/>
  5. </links>
  6. activityA
  7. <source linkName="L1"/>
  8. activityB
  9. <source LinkName="L2"/>
  10. activityC
  11. joinCondition="L1 AND L2"
  12. <target LinkName="L1"/>
  13. <targetLinkName="L2"/>
  14. </flow>

3) 排它选择模式:在流程中的某一点,根据结果或流程控制数据,从多个分枝中选定一个路径。

在BPEL3WS中可利用<switch>来描述这一模式:

  1. <switch>
  2. <case condition="C1">
  3. activityB
  4. </case>
  5. <case condition="C2>
  6. activityC
  7. <case/>
  8. <switch>

4) 简单合并模式:在流程中某一点,将多个可选分枝聚合而不同步

用BPEL4WS描述如下:

  1. <flow name="F">
  2. <Links>
  3. <Link name="L1">
  4. <Link name="L2"/>
  5. </links>
  6. activityA
  7. <source linkName="L1/">
  8. activityB
  9. <source linkName="L2/">
  10. activityC
  11. joinCondition="L1 XOR L2"
  12. <target linkName="L1"/>
  13. <target linkName="L2"/>
  14. </flow>

5) 多重选择模式:在工作流的某一点,根据判定或工作流控制,选择一个或多个分枝:

读者可用BPEL4WS中的<flow>,<links>自已写出它的程序表示。

6) 非同步的多实例模式:在某一时刻,流程中的某个活动可能会创建多个独立的、可并发执行的实例。,可有BPEL4WS中的<while>和<invoke>描述如下:

  1. <processA>
  2. <while cond="C1">
  3. <invoke processB…>
  4. </invoke>
  5. </while>
  6. </process>
    …….
  7. <processB>
  8. <receive processA …
  9. createInstance="yes">
  10. </receive>
  11. </process>

这种模式指定的活动可会创建多个实例,而且这些实例在继续下面的流程之前会进行同步。但建立的实例的数目有以下几种情况:

  1. 在设计阶段已知要建立的数目
  2. 设计时不能确定,而在运行的某一时刻可以确定要建实例的数目
  3. 不能确定,根据请求创建实例,直到没有请求为止

第一种情况,用循环和<flow>来实现个数控制和同步。第二、三种情况,用嵌套了<pick>操作的<while>循环,且设置三个消息来控制循环操作:

表示要创建一个新的实例

实例创建结束

没有新的实例创建请求

  1. moreInstances:=True
  2. I:=1
  3. <while moreInstances OR I>0>
  4. <pick>
  5. <onMessage StartNewActivityA>
  6. invoke activityA
  7. I=I+1
  8. </onMessage>
  9. <onMessage NOMoreInstances>
  10. I:=I-1
  11. </onMessage >
  12. <onMessage NoMoreInstances>
  13. moreInstances:=False
  14. </onMessage>
  15. </pick>
  16. </while>

除此之外之外,还有如下的一些模式:

7)、推迟选择模式:在某一刻,几个分枝中的一个被选中,但选择不是显现的。

8)、交叉并行路由模式:在流程中,一组任务可以任意顺序执行,且组中的每一任务仅被执行一次。活动顺序在运行时决定,在一个活动完成之后才能决定下一活动,且没有两个任务在同一时刻执行。

9)、里程碑式模式:任务的节点的可用性取决于特定的状态条件,即任务只有在某一里程碑已经到达且还没有过期的时候才可被激活。

10)、取消活动模式:取消一个案例,即取消流程实例。它用与禁止另一任务的执行。

4、 利用UML建模

UML由于它的可视性、领域无关性,已被广泛用于建模。在UML的多个视图中,活动图可用与描述工作流。在上述的工作流模式中,顺序模式、并行交叉模式、同步模式、排它选择模式、简单合并模式是最基本的模式。可用UML的活动图描述如下;

1)、顺序模式

2)并行交叉模式

3)同步模式

4)P排它选择模式

5)简单合并模式

4.4.2.2 流的质量保证分析

1、流的结构分析

城市电子政务的开发,实际上是一个大型的集成活动。它是通过把COTS软组件、遗留系统、可行的技术,在政务领域的体系结构的框架之内集成而成。其中大量的工作呈工作流状态。工作流中的关键点就是对这些复杂的结构和它门产生的异步行为进行智能控制。并且,在这种系统中,异步的网络系统常常有动态的、不确定的因素发生。所以在设计电子政务系统的平台时要考虑三个重大的工程问题:

1) 虽然是分布、异构的环节,但要建立系统分析、规约、设计和验证的统一的工程基础;

2) 分布、异构环境中,如何保证电子政务系统中服务的存活性、可靠性和各项性能指标;

3) 什么样的政务软件平台才能简化分布、异构环境中应用系统的开发和运行;

要很好地解决这三个问题,就要建立电子政务平台设计的统一基本概念:

流结构:业务工作流的结构以及实现流的各个节点的功能所调用的服务的质量是进行功能属性、质量属性的工程化的基础。

计算的质量属性:系统的质量属性与两者有关:流和流调用的服务。即要考虑实现它们的计算的动态特性,要对它们的不确定因素按优先顺序有一个估计。

流的管理体系结构:能把服务组合起来实现流结构的政务服务,能对它们调用的多个服务的运行状态进行监控;能保证流在运行过程中的必要环节进行人/机会话。

2、流的工程化原理

要实现流的各项业务功能,必须在流的层次上考虑它的工程化实现问题。为此,我们必须能用形式化的(或算法化)描述流的结构,以支持不确定环境中流的开发和验证。为了允许有不可预见的服务的行为,只考虑流本身执行的行为,而不考虑服务调用的服务的处理。流服务F调用服务A的语义描述如下:

业务流可以用一个图来描述,而形成了所谓"流服务结构",由此而形成的FSQ(Flow-Service-Quality)理论如下:

1) 流结构理论:任一用图表示的工作流,都只要用"组合"、"选择"、"循环"三种结构就可实现。根据这一理论,流服务的开发者只要用这三种结构就可实现任何复杂的工作流,而没有必要去考虑其它的结构。

2) 抽象/求精理论:两个流等价,当且仅当两个流有相同的流说明。这一理论能够用来简化流的设计。例如下:

由上图可看出:A1 = A + B; C = C1 F = A1 + C

3、流的验证理论:组成流设计的一组单入口、单出口的控制结构能用等价的功能计算来加以验证。

流可能包含着不确定数目的可能的执行路径,它是不可能根据各种特定的情况用穷举法来加以验证的。但流是由有限数目的控制结构组成的,而每一个控制结构是可用有限步骤加以验证的。其原理可用图说明如下:

这个流是要实现的功能 流验证理论所表示的如何测试

4、流的转换性分析

流调用的服务,它本身就是由流组成的,即一个基本流的实现依赖于很多其它流的完成,而且,这些流可能是在一个大的政务系统之中,并且是跨很多部门。如一个完整的政府采购系统就是属这种情况。

首先要找到满足基本流所直接调用的服务和实现这种服务的流。要明确调用这个服务所产生的结果:希望的结果,不希望的结果。

5、巨型系统中流集的设计

若一个巨型系统涉及若干系统,而每一个系统内又有跨部门的、十分复杂的流的定义和管理。这种情况就要把服务、支持特定的功能组件进行分组,这种组就叫流集。

6、流的安全性和可服务性分析

流代表的是端-端的处理,即是从流的用户开始,通过网络最后又回到该用户。在这种遍历各个部门时,要访问很多系统和领域,因此,每一个都有自已的安全和可服务性策略和能力,而整个流的质量(可服务性、安全性)只取决于最差的哪一个组件。

4.4.3 工作流中的事务服务原理

l 1应用需求

城市政务宽带网络平台连接市政府、工商、保险、统计、医药、税务。。。等各个国家机关部门。从逻辑上是属分布式应用系统。在分布式应用系统的设计中常常面临诸多带有共性的问题,比如:应用系统的平台多样性,数据操作的一致性、可靠性、可用性得不到保障,异构平台间难以互操作、数据共享度低、应用维护、开发困难、系统管理不便和信息安全难以保证。而且政府的很多手续、证件、文件的办理过程需要引进"原子事务"的管理等等。

为解决上述问题,我们提出了"多节点多路径信息传递及返回同步/异步工作模型",并给出设计实现该模型的系统平台的要求,用流程化方法解决电子政务中的分布式事务处理。什么是电子政务中的事务呢?

在数据库管理系统中最早引进|"事务"的概念,即两个或多个不可分割的计算操作的完整完成构成事务。也称"原子事务"。 原子事务具有四个重要属性,ACID。原子性(atomic),一致性(consistent):隔离性(isolated),持久性(durable):

随着分布式计算技术的进一步发展,又产生了分布式事务这个概念产生,分布式事务是指事务中多个操作的程序、数据分别位于分布式系统的不同计算机之上。

X/OPEN组织定义了事务处理和分布式事务处理的XA规范,目前几乎所有主流的数据库产品和应用服务器产品(无论是DNA还是J2EE)都支持这一规范。

无论对于事务和分布式事务,所指的一系列操作都是在瞬间完成的,TPS(每秒种处理多少事务)就是一个常用的衡量系统性能的指标。

2、 长事务处理

上述的事务是由计算机自动完成的。而在电子政务的应用中,很多工作是需要多人按既定顺序干预或操作才能完成的。 这就是工作流概念,它对事务处理又提出了新的要求。

工作流是一系列不同的人和计算机程序共同参与的活动的一种计算机化的表示模型,定义了完成整个过程所需用的各种参数以及参加完成各项功能所需的各个服务。这些参数包括对过程中每一个步骤的定义、步骤间的执行顺序条件以及数据流的建立、每一步骤由谁负责以及每个活动所需要的应用程序。

由于工作流是一个在至少两个环节上需要人工交互过程模型,这也是工作流区别于一般的业务流程管理(Business Process Management)的关键所在。因此会进一步将分布式事务从一个几秒钟延长到数个工作日甚至数月。由此产生了长事务的需求。长事务是事务和分布式事务的进一步扩充。

因此,一个长事务可能包含任意多个事务或分布式事务。在长事务处理中,需要有效地管理和标记一些工作流过程的中间数据,以使得整个审批过程的数据保持一致性和整个长事务的隔离性(isolated)。

长事务的处理模型可用图描述如下:

  • 应用程序:根据某一业务应用逻辑定义、编制的应用框架
  • 资源管理器:事务全过程中共享的各种资源
  • 事务管理器:对事务的启动、提交、执行、并发、回推、结束进行全程管理
  • 通信管理器:对事务中定义的各个服务的信息交换的通信实施全程管理

4.4.4 工作流管理平台的设计模型

从电子政务的工作流技术所要解决的问题来看,它必然是分布式的。因为无论是从企业或政府各部门的信息环境、组织环境,还是与外界的协作环境来看,都具有明显的分布式特点:网络的延伸、系统的异构、信息的储存、人员的地理分布等等。在这样的环境下要完成不同应用系统的集成、不同组织人员的协作,并最终实现业务过程规范化、自动化与高效率,所采用的工作流管理系统必然要具有分布式的特点。

"分布式工作流"的概念是相对于早期的集中式工作流管理系统而言的。随着计算机与网络技术的迅速发展,特别是在Internet应用日益普及的情况下,现代信息系统的分布性、异构性和自治性的特征越来越显著,相应的组织信息资源也分布在异构的计算机环境中,信息源之间的连接表现出松散耦合的特点,这样的信息系统环境简称HAD环境(异构、自治、分布),这也是电子政务系统的显著特点,即不同部门使用各自的系统处理各自的业务,同时各个部门之间还有能够有效地共享或传递一些信息。典型的应用例子就是工商税务并联审批。

分布式工作流反映了"多节点、多路径返回、同步/异步工作模型"的需求。

从技术复杂性与实现的先后顺序上,分布式工作流管理可以分为三个层次:

  • 工作流体系结构的分布
    这是一个最基本的层次,工作流定义的步骤中所定义的不同环节上的应用程序是分布式的,但是工作流定义仍然是在同一个组织的。
  • 工作流引擎的分布式执行
    这一层次主要解决工作流管理系统的可缩放问题。是多个工作流引擎能够集群化工作,且可灵活调整工作流系统的处理能力。
  • 作流模型的分布式定义与柔性执行
    这一层次主要解决跨越不同组织的工作流定义,例如:工商并联审批。柔性执行则是指正在运行的流可以修改,且保证修改后的流可保持数据一致性。

4.4.4.1城市电子政务系统的工作流平台应具备的特征:

① 具备普通事务处理的能力,保证数据的一致性。
② 具备长事务处理能力,保证业务数据的一致性。
③ 具备长事务回退机制,保证业务数据的完整性。
④ 具备完整的工作流设计和引擎,实现业务流转。
⑤ 工作流服务须支持任意流转情况下数据的一致性。
⑥ 工作流服务须支持与异构业务组件的耦合,并保证在回退时的一致性。
⑦ 工作流平台必须跨体系结构,能在不同的平台和体系构架上运行。
⑧ 工作流平台须支持分布式工作流,各分布工作流服务器有逻辑上的对等结构,工作流引擎的分布式执行。
⑨ 工作流平台须支持工作流模型的分布式定义与柔性执行。

4.4.4.2 工作流平台功能模型设计

工作流平台是用于定义、实现和管理工作流运行的软件系统。一个成熟的工作流系统通常由工作流设计工具、工作流引擎、Repository等几个部分组成。如图:

(1) 工作流引擎

由信息路由、状态控制、用户接口组成

工作流引擎是工作流平台的核心,它是业务流程的任务调度器。工作流引擎的具体功能如下:

  • 对过程定义进行解释
  • 控制过程实例的创建、激活、挂起、终止等
  • 控制活动实例间的转换,包括串行或并行的操作、工作流相关数据的解释等
  • 支持分布式工作流的协同
  • 管理流程的柔性执行
  • 提供支持用户操作的接口
  • 维护工作流控制数据和工作流相关数据
  • 提供用于激活外部应用程序和访问工作流相关数据的接口
  • 提供控制、管理和监督工作流实例执行情况的功能。

(2)流程定义与设计

表单设计

用户可以使用图形化设计方法,开发出动态页面应用,其结果可保存为XML并具有数据库访问能力。

表单开发工具的主要功能有:

  • 所见即所得的文档和表格设计
  • 多文档复合信息支持
  • 多种业务文档类型
  • 文档与XML数据的连接与输入自动感知
  • 复杂文档窗体的设计
  • 文档视图动态测试
  • 业务文档事件

流程建模

使用图形化的方法,让开发者用最少的时间设计或修改业务工作流程,建模工具提供了相当丰富的流程逻辑表达方式,可以表示非常复杂的流程,和表单设计工具相结合可以轻易的设定每个流程步骤要执行的功能,和组织机构建模工具相结合,可方便准确地选择每个活动执行的参与者。

流程建模工具的主要功能有:

  • 支持专业的流程建模
  • 流程协作定义
  • 任务协作定义
  • 事件驱动和流转条件控制
  • 时间控制
  • 分布式流程设计
  • 决策型流程支持

角色建模

使用角色建模工具建立参与业务流程的人员角色,使得流程的管理与具体的人员分离,可以通过管理工具灵活的变化流程角色,使岗位职能转变等变化很容易被适应。

角色建模工具的主要功能有:

  • 定义角色权限
  • 定义角色范围
  • 分派角色任务

组织机构建模

利用图形化的形式定义组织机构图,让用户以图形化的方式为政府几个、部门及单位建立组织机构图,组织机构图能显示使用者的职责、职称及从属关系等。管理者可以根据工作流使用者在不同工作流程中需要完成的任务,为其赋予角色。角色建模工具与统一用户管理平台相连接,能够读取或更新统一用户数据库中的数据,保证用户信息的集中管理。

组织建模工具的主要功能有:

  • 实体定义(包括人员、角色、职务、部门、工作组)
  • 业务分工
  • 权限管理

(3)工作流客户方参加的处理应用

给用户参加工作流的协同工作提供的一个手段,使用户能通过它完成应由人工完成的任务,如审查、签字等

(4)被调用的各项服务

工作流引擎在流程实例的运行过程中要调用各种应用程序实现业务处理,这些应用程序可能是:WEB服务、中间件服务器上的各种软组件等。在流程定义中已规定了被调用的应用程序的各类信息:类型、访问方式、组件形为等

(5)管理和监控工具

对流程引擎中的状态进行监控,监控的内容有:流程实例的启动者、当前状态、工作吞吐量等。有一些供用户查询的信息还要交给工作流客户方工具进行处理,以便用户查看。

3、分布式工作流

分布式工作流是将可协同工作的工作流引擎分布于网络的各个服务器上,实现流程的同步/异步交互, 达到协同工作的目标。其逻辑结构如图4-29。

 

组织简介 | 联系我们 |   Copyright 2002 ®  UML软件工程组织 京ICP备10020922号

京公海网安备110108001071号