07年3月对工作流的再学习

利用一个或多个建模技术与工具，完成实际的经营过程到计算机可处理的形式化定义的转化，所得到的定义就是过程模型，过程模板，过程元数据，过程定义。

过程建模方法学

值得思考的问题：
工作流系统运行的底层通信基础结构。Corbar，dcom，java都可选，但从分布式，安全，容错，可靠等方面考虑，没有好的方案。
标准化问题。不同厂商有不同的工作流模型，定义语言，api，不能互操作。虽然wfmc就此问题做了工作，但要实现像关系型数据库这样的标准（指关系数据库模型，sql语言）还很难。
现在的工作：api，为不同工作流系统以及工作流系统与应用程序间定义交换格式和协议。统一工作流模型，使不同系统的工作流定义可以相互使用。
现在的工作流模型的问题：缺乏能支持过程定义，过程演进，过程分析的形式化数学模型。模型的核心当然是对过程的定义，包括组成过程的基本活动，活动间的顺序关系。
现有的模型多是从直觉出发，以图形语言或文本语言定义过程。这种方式本质还在用户的角度。无法对工作流的本质进行描述，更无法进行分析和评价。Wf-net有形式化的数学描述，但是它对工作流模型描述的能力不够。
因为，模型的理论基础不够，所以造成工作流系统在关键特性上的问题。
工作流仿真问题：没有仿真的工作流系统是不完善的，但是现在没有相关的东东。

工作流的理论问题：
过程建模理论和建模方法，研究支持事务的工作流模型可解决一些本质问题。
模型验证：如何验证模型不会死锁（没法验证的话，可以直接限制模型的语法以避免死
锁）。
过程模型与其他模型的集成：
企业应用时，还存在功能模型，信息模型，资源模型，组织模型，甚至经济模型，
决策模型。这些模型描述了应用领域的不同侧面。如何集成还做的不好。

工作流模型应该包括：
过程的开始和结束条件，
构成过程的活动，及活动间的导航规则，
用户需要完成的任务，
可能被调用的应用，
工作流机的引用关系，
有关的数据。
组织结构，组织中的角色。
过程定义元模型：


1

转换条件：为过程实例的推进提供导航依据，对应于业务过程中的业务规则和操作顺序。参数包括：工作流过程条件flow condition（即前后条件），执行条件execution condition。
工作流相关数据：是工作流实例推进的另一个依据。举例，银行贷款时，大于10万的申请要交经理处理，小于的由业务员处理。

几个实例的研究：
1. Exotica使用的建模工具ibm的flowmark：
http://www.redbooks.ibm.com/abstracts/sg242184.html
flowmark以工作流管理联盟的元模型为基础：



活动（一个操作，功能）；
控制流；数据流（输入/输出数据箱间的映射关系）；输入/输出数据箱；
活动的开始/介绍条件；
开始/终止节点。

Flowmark里面有一个从事务模型到工作流模型的转换功能（为什么有这个功能？因为高级事务模型的目标与工作流类似）：
用户创建一个包括所要使用的事务模型以及要执行的事务项的规范，预处理器在确认符合事务模型之后，转化为flowmark definition language格式的flowmark过程模型，然后……




研究计划：flowmark的操作界面（利用其用户手册？），预处理器，FDL，
模型从事务模型到flowmark模型的转换中的预处理器的作用与用法，是否可以借鉴用来处理用户ipo输入到可视化模型的转换中的预处理。
因为flowmark使用的是wfmc的模型，所以比较一下fdl与xpdl，考虑如何从其流程图映射到fdl。


2. Meteor
其建模工具中将模型分成了三个部分：
流程设计器:定义活动间的关系。
数据设计器：定义执行活动所需和传递的数据，以OO技术，通过数据类的方式来
实现。
任务设计器：有五类，非事务型，事务型，web型，人机交互型，两阶段提交型，
为此定义了五类任务设计器，分别描述如何激活不同类型的活动。
模型以WIL workflow intermediate language描述，类似wpdl。Wil能够记录活动间的前驱，后继关系，活动间所传递的数据对象，数据对象的定义，活动的详细描述，活动激活方法。
研究计划：wil，定义工具三个部分如何整合的，Meteor的WebWork是基于web的
wil类似wpdl，有何不同？
流程设计器，数据设计器，任务设计器如何整合的？流程设计与任务设计的关系？
其最新进展：Meteor-S的
http://lsdis.cs.uga.edu/projects/meteor-s/index.php
3. WIDE，
基于分布式主动数据库技术。
模型有三个：组织，信息，过程，是wfmc参考模型的扩展。不仅定义了工作流的基本要素（三个模型及相互关系），还支持丰富的组织模型，复杂的活动分配约束，动态控制流程，复杂过程结构，工作流事务管理。
组织模型与过程模型严格分离，通过授权机制连接，即用授权将过程模型中的角色映射到组织模型中的代理。

组织模型：组织结构，资源信息。
包括：单个职员，职位，出于临时目的的工作组，企业内的资源信息。为了表达前面几个元素的相互关系，定义了包含，分配，属于，替代关系。另外，职位的层次图，代理（作为活动的执行者）。

信息模型：两种数据，全局（对所有实例）、局部（一个具有的实例）。

过程模型中的活动：前后条件，活动中的操作，角色限制，异常情况处理。
支持层次化建模，即活动是分层的，最底层的叫基本活动。
基本活动描述对信息模型中的数据的操作，或用户要执行的外部操作。

WIDE有自己的描述语言。
研究计划：wide自己的描述语言与wpdl的比较
4. 基于状态和活动图的Mentor
采用状态和活动图为模型建立的规范，并用statemate为建模工具。用户可以用bpr工具，如Aris-Toolset建模，或其他工作流建模工具，如flowmark，Mentor可以自动转换为状态和活动图。

活动图中的活动与工作流模型中的活动类似，有向弧代表活动间的数据流动方向和内容，状态图反映了活动间的控制信息的流动。状态图中状态的转换是基于ECA规则的，并允许嵌套状态，允许同一层次的状态图独立地并行执行。

研究计划：Mentor中如何实现不同模型的转换的？活动图的语义？
Uml2活动图中的活动的语义是否还是工作流模型的活动的类似语义。

下面是比较具体的产品，上面的研究性质多点：
5. IBM MQSeries Workflow



其过程模型包括：程序活动，过程活动，活动块，控制流，数据流。
可以自定义图标的样式。
6. Action Technologies的Metro
基于web的Action Metro4.0，
强大的过程编辑器是其特定之一：
图形化，
支持不可预知的过程定义，
具有工作流模板和协议向导，帮助快速生成过程模型。


1
研究计划：Action Metro 4的工作流模板，web方式该如何设计过程编辑器界面
7. JetForm的InTempo
具有组织定义工具，角色定义工具，过程定义工具等，
研究计划：InTempo如何整合组织定义工具，角色定义工具，过程定义工具

8. Pavone的Espresso
基于IBM的Lotus Notes/Domino系统的，如图：


1
有组织建模器和过程建模器，以及Notes数据库组成，其过程建模器如下，其工作流过程模型结构简单，活动节点和节点间的单向流线组成。


1
其组织建模器如下，建立的组织模型：person，department，workgroup，role，material。角色带有一个参数以便在工作流执行时动态确定某个活动的具有参与者。


1

其中所谓的预定义工作流应该就是一个工作流过程模型，
提出一个路径选择的问题：必经always，多选择multiple choice，单选择exclusive choice，条件，备用else。
工作流版本管理的概念：每个预定义工作流可以有多个运行版本，运行版本的修改不影响预定义工作流。

9. CIMFlow
其模型有：过程模型，组织模型，资源模型，工作流相关数据。



过程模型：节点，连接狐，状态，条件。节点和连接狐是以图标的形式表现的，状态和条件是以属性的形式表示的。

过程模型有三种活动节点：任务（人工型，自动应用，可分解的过程），逻辑，标志。
可分解的过程：如果过程比较复杂，那么可以将一些关系紧密的节点集合在一起。

任务节点的重用：
任务节点是过程模型的核心，如果能统一任务节点的内部结构、建立输出à输入的映射机制，可以提高建模速度和规范化建模。因此，任务节点有重用的必要性。重用的概念：一个活动或过程可以用在多个不同的工作流中；而用户只要引用已有的活动或过程即可；活动可以出现在不同的工作流中，与其相关的前驱和后继无关，这就是重用。
引用外部活动或过程的用户对外部活动或过程没有修改权限。系统提供搜索功能，即对每一个活动自动搜索可能的后继节点。
什么样的节点可以重用。从编程来看，具有统一接口的组件和对象是可以重用的，并且严格区分内部属性和接口属性。所以，认为节点的内部结构被定义为IPO结构的。这样节点间的关联是通过输出与输入关联的，内部细节被封装。因此，每个可重用的工作流都是IPO的，并且其内部的结构也是IPO的。

逻辑节点：
按wfmc的规定，有六种逻辑结构。串行，与分支，与连接，或分支，或连接，循环。
另外，CIMFlow特别定义了空节点。

标志节点：
因为采用的是活动网络图，从理论上可以选择任一节点做为入口。所以定义了开始节点。
另外，由于实际的业务过程执行路径的不同，也会有多出口的问题。为了显示表达过程
的结束，使用了结束节点。


过程模型中的连接弧：
控制连接狐（有条件，无条件），
数据连接狐：引入数据连接狐的原因是，一个活动执行完之后，不仅要向其控制连接狐指向的节点提供数据，还可能向其他节点提供数据。因此，用数据连接狐来表示。



状态：这是过程模型执行过程中的问题，但是为了解决活动网络图中的对状态的表达的欠缺，将它明确地提出来。活动可能具有的状态以及在状态间的转换，如下：




组织模型：



角色：以技能为继承，能够完成某项功能的人员的总称。
资源模型：
2000年前的工作流产品中的资源模型很少，这跟工作流起源于办公自动化系统，而不是企业有关。引入“资源类型”和“资源个体”来表示资源模型。



研究计划：我们的系统中有没有资源模型？

工作流相关数据：
一个工作流系统必须给用户提供定义工作流相关数据的能力。相关数据其实是信息模型的简化，即只有实体类型，没有实体间关系。
CIMFlow中的工作流相关数据：简单变量和对象。
对象的属性和其中的方法的返回值作为工作流相关数据。
工作流相关数据是有作用域的。

CIMFlow的建模过程：
1. 建立过程模型，
2. 建立资源和组织模型，
3. 活动的执行角色定义，人工活动：将相应用户界面模板绑定；自动活动，建立数据对象域命令行参数的映射，还要考虑如何从应用程序得到其执行的返回结果。
4. 保存工作流模型，
5. 分配工作流模型，分配到工作流机。



研究计划：从CIMFlow的建模界面考虑我们的系统的建模界面。
CIMFlow中的实现：
1. 四个模型间的关系：process model“使用”其他三个模型



2. 过程模型中的类图：




WMProcess由WMNodeList和WMLinkList组成。
3. 组织模型的类图：




4. 资源模型的类图：



5. 相关数据的类图：




研究计划：关于CIMFlow的论文，以及CIMFlow的实现方法里有否可借鉴的地方。

研究计划：一些可能基于web的workflow
http://www.open-open.com/open9608.htm
http://www.open-open.com/open9908.htm
http://www.open-open.com/open10508.htm
http://www.open-open.com/open11308.htm
http://www.open-open.com/open87208.htm

工作流建模方法：
1. 基于活动网络：以活动间的关系为基础，大多数工作流系统的方式，可以转换为扩展petri网进行验证。
2. 基于形式化表示，petri，扩展的petri，工作流网，
3. 基于对话模型，
4. 基于状态和活动图，介于petri与图形化（活动网络？）之间的，比petri容易理解，比图形化难理解，比图形化容易验证。比petri难验证。
5. 基于事务。

工作流描述语言：
wpdl，
pslßNIST
WFDLßWIDE
WFSL工作流定义语言,TSL任务定义语言ßMeteor
C&CoßC

工作流模型研究
工作流首先要描述的是业务过程，所以很多工作流模型都是从过程的描述开始，并且采用比较直观的有向图，或基于有向图的模型。缺点是不能处理复杂的过程逻辑。

1. IDEF系列方法广泛用于企业建模，过程建模。
包括：
功能建模IDEF0，系统的功能结构：功能的输入输出，执行控制，功能的递规分解，
并没有功能执行顺序的定义。
信息建模IDEF1/1X，系统中的信息实体及它们间的关系，
动态行为建模，IDEF2，
过程建模，IDEF3：用场景描述（过程流网）或对象（对象状态转移图）来获取对过程的描述。
面向对象建模IDEF4
可以用IDEF0,1X,3来建立过程模。

2. STEP Part 49用中性语言EXPRESS定义的。
研究计划：EXPRESS中性语言到其他语言的转换？
3. 基于对话的工作流模型。Winograd和Flores
4. 基于Petri网的ICN模型。
5. 基于Petri网的WF-Net，即工作流网。
6. 基于活动树结构的模型。
7. Broker/Services代理/服务模型，Andreas Geppert。


业务过程中除了活动及活动间关系外，还有：
活动间传递的信息，活动的执行实体，活动需要的资源。
Wfmc为此定义了工作流相关时间、工作流控制数据、工作流参与者、角色等。
有的将上面三个部分从过程模型中分离了出来，（wfmc没有，而是直接加入到过程模型中
了）。WIDE提出了组织模型，信息模型，过程模型的概念。

为了在不同的模型间实现转换，需要“规范的描述语言”：
wfmc：wpdl；
ibm:fdl;
Meteor2:wil。
研究计划：这些规范的描述语言打算如何转换不同的模型？是否参见MDA下面一个类似计划？


关于flowmark的工作流模型：
其模型的组成元素：
过程：为了实现一个目标而定义的。（目标驱动？）
活动：程序活动，过程活动。



1

模块：类似过程，区别是过程可以多次在不同的工作流过程中使用，模块不行，只属于一个
过程。模块与过程的区别是：begin与end间的代码，和外部链接库的区别。
控制连接弧，
数据连接弧：前一活动的输出数据箱指向后一活动的输入数据箱。
条件：存在于活动间的转移条件（在控制连接狐上），活动的开始条件，活动的结束条件（因此，活动有使能状
态和执行状态的区别）。



Flowmark是典型的基于活动的IPO模型，以活动为基本单元，连接狐是过程逻辑，输入输出数据箱是活动输入输出的接口，加上条件的设置，从而实现建模。下面是一个实例。



检查一个订单，然后并发执行计算价格，查找库存，验证技术可行性，之后到决策，如果没有问题就“准备确认文件”等，如果有问题，就“建议更改订单”等。但是上图没有体现出一个活动具有多个后继时如何判断是并行还是选择逻辑。
研究计划：研究一下flowmark的ipo特性，比较一下基于uml活动图建模与flowmark。
Flowmark将控制流与数据流分离了，uml？
Flowmark的活动有状态，uml？
Uml中时序能力是否比较强，或者说flowmark如何表达不同的时序。
研究计划：深入研究wpdl，xpdl的定义。


研究计划：工作流相关数据，工作流控制数据的区别，具有表现。