利用一个或多个建模技术与工具，完毕实际的经营过程到计算机可处理的形式化定义的转化，所得到的定义就是过程模型，过程模板，过程元数据，过程定义。
过程建模方法学
值得思考的问题：
工作流系统执行的底层通信基础结构。Corbar，dcom，java都可选，但从分布式，安全，容错，可靠等方面考虑，没有好的方案。
标准化问题。不同厂商有不同的工作流模型，定义语言，api，不能互操作。尽管wfmc就此问题做了工作，但要实现像关系型数据库这种标准（指关系数据库模型，sql语言）还非常难。
如今的工作：api，为不同工作流系统以及工作流系统与应用程序间定义交换格式和协议。统一工作流模型，使不同系统的工作流定义能够相互使用。
如今的工作流模型的问题：缺乏能支持过程定义，过程演进，过程分析的形式化数学模型。模型的核心当然是对过程的定义，包含组成过程的基本活动，活动间的顺序关系。
现有的模型多是从直觉出发，以图形语言或文本语言定义过程。这样的方式本质还在用户的角度。无法对工作流的本质进行描写叙述，更无法进行分析和评价。Wf-net有形式化的数学描写叙述，可是它对工作流模型描写叙述的能力不够。
由于，模型的理论基础不够，所以造成工作流系统在关键特性上的问题。
工作流仿真问题：没有仿真的工作流系统是不完好的，可是如今没有相关的东东。
工作流的理论问题：
过程建模理论和建模方法，研究支持事务的工作流模型可解决一些本质问题。
模型验证：怎样验证模型不会死锁（没法验证的话，能够直接限制模型的语法以避免死
锁）。
过程模型与其它模型的集成：
企业应用时，还存在功能模型，信息模型，资源模型，组织模型，甚至经济模型，
决策模型。这些模型描写叙述了应用领域的不同側面。怎样集成还做的不好。
工作流模型应该包含：
过程的開始和结束条件，
构成过程的活动，及活动间的导航规则，
用户须要完毕的任务，
可能被调用的应用，
工作流机的引用关系，
有关的数据。
组织结构，组织中的角色。
过程定义元模型：
杩愯鏃堕敊璇?/i> 璇存槑: 鏈嶅姟鍣ㄤ笂鍑虹幇搴旂敤绋嬪簭閿欒銆傛搴旂敤绋嬪簭鐨勫綋鍓嶈嚜瀹氫箟閿欒璁剧疆绂佹杩滅▼鏌ョ湅搴旂敤绋嬪簭閿欒鐨勮缁嗕俊鎭?鍑轰簬瀹夊叏鍘熷洜)銆備絾鍙互閫氳繃鍦ㄦ湰鍦版湇鍔″櫒璁＄畻鏈轰笂杩愯鐨勬祻瑙堝櫒鏌ョ湅銆?
璇︾粏淇℃伅: 鑻ヨ浣夸粬浜鸿兘澶熷湪杩滅▼璁＄畻鏈轰笂鏌ョ湅姝ょ壒瀹氶敊璇俊鎭殑璇︾粏淇℃伅锛岃鍦ㄤ綅浜庡綋鍓?Web 搴旂敤绋嬪簭鏍圭洰褰曚笅鐨勨€渨eb.config鈥濋厤缃枃浠朵腑鍒涘缓涓€涓? 鏍囪銆傜劧鍚庡簲灏嗘 鏍囪鐨勨€渕ode鈥濆睘鎬ц缃负鈥淥ff鈥濄€?br>
娉ㄩ噴: 閫氳繃淇敼搴旂敤绋嬪簭鐨? 閰嶇疆鏍囪鐨勨€渄efaultRedirect鈥濆睘鎬э紝浣夸箣鎸囧悜鑷畾涔夐敊璇〉鐨?URL锛屽彲浠ョ敤鑷畾涔夐敊璇〉鏇挎崲鎵€鐪嬪埌鐨勫綋鍓嶉敊璇〉銆?br>
">1
转换条件：为过程实例的推进提供导航根据，相应于业务过程中的业务规则和操作顺序。參数包含：工作流过程条件flow condition（即前后条件），运行条件execution condition。
工作流相关数据：是工作流实例推进的还有一个根据。举例，银行贷款时，大于10万的申请要交经理处理，小于的由业务员处理。
几个实例的研究：
1. Exotica使用的建模工具ibm的flowmark：
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的
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，
强大的过程编辑器是其特定之中的一个：
图形化，
支持不可预知的过程定义，
具有工作流模板和协议向导，帮助高速生成过程模型。
杩愯鏃堕敊璇?/i> 璇存槑: 鏈嶅姟鍣ㄤ笂鍑虹幇搴旂敤绋嬪簭閿欒銆傛搴旂敤绋嬪簭鐨勫綋鍓嶈嚜瀹氫箟閿欒璁剧疆绂佹杩滅▼鏌ョ湅搴旂敤绋嬪簭閿欒鐨勮缁嗕俊鎭?鍑轰簬瀹夊叏鍘熷洜)銆備絾鍙互閫氳繃鍦ㄦ湰鍦版湇鍔″櫒璁＄畻鏈轰笂杩愯鐨勬祻瑙堝櫒鏌ョ湅銆?
璇︾粏淇℃伅: 鑻ヨ浣夸粬浜鸿兘澶熷湪杩滅▼璁＄畻鏈轰笂鏌ョ湅姝ょ壒瀹氶敊璇俊鎭殑璇︾粏淇℃伅锛岃鍦ㄤ綅浜庡綋鍓?Web 搴旂敤绋嬪簭鏍圭洰褰曚笅鐨勨€渨eb.config鈥濋厤缃枃浠朵腑鍒涘缓涓€涓? 鏍囪銆傜劧鍚庡簲灏嗘 鏍囪鐨勨€渕ode鈥濆睘鎬ц缃负鈥淥ff鈥濄€?br>
娉ㄩ噴: 閫氳繃淇敼搴旂敤绋嬪簭鐨? 閰嶇疆鏍囪鐨勨€渄efaultRedirect鈥濆睘鎬э紝浣夸箣鎸囧悜鑷畾涔夐敊璇〉鐨?URL锛屽彲浠ョ敤鑷畾涔夐敊璇〉鏇挎崲鎵€鐪嬪埌鐨勫綋鍓嶉敊璇〉銆?br>
">1
研究计划：Action Metro 4的工作流模板，web方式该怎样设计过程编辑器界面
7. JetForm的InTempo
具有组织定义工具，角色定义工具，过程定义工具等，
研究计划：InTempo怎样整合组织定义工具，角色定义工具，过程定义工具
8. Pavone的Espresso
基于IBM的Lotus Notes/Domino系统的，如图：
杩愯鏃堕敊璇?/i> 璇存槑: 鏈嶅姟鍣ㄤ笂鍑虹幇搴旂敤绋嬪簭閿欒銆傛搴旂敤绋嬪簭鐨勫綋鍓嶈嚜瀹氫箟閿欒璁剧疆绂佹杩滅▼鏌ョ湅搴旂敤绋嬪簭閿欒鐨勮缁嗕俊鎭?鍑轰簬瀹夊叏鍘熷洜)銆備絾鍙互閫氳繃鍦ㄦ湰鍦版湇鍔″櫒璁＄畻鏈轰笂杩愯鐨勬祻瑙堝櫒鏌ョ湅銆?
璇︾粏淇℃伅: 鑻ヨ浣夸粬浜鸿兘澶熷湪杩滅▼璁＄畻鏈轰笂鏌ョ湅姝ょ壒瀹氶敊璇俊鎭殑璇︾粏淇℃伅锛岃鍦ㄤ綅浜庡綋鍓?Web 搴旂敤绋嬪簭鏍圭洰褰曚笅鐨勨€渨eb.config鈥濋厤缃枃浠朵腑鍒涘缓涓€涓? 鏍囪銆傜劧鍚庡簲灏嗘 鏍囪鐨勨€渕ode鈥濆睘鎬ц缃负鈥淥ff鈥濄€?br>
娉ㄩ噴: 閫氳繃淇敼搴旂敤绋嬪簭鐨? 閰嶇疆鏍囪鐨勨€渄efaultRedirect鈥濆睘鎬э紝浣夸箣鎸囧悜鑷畾涔夐敊璇〉鐨?URL锛屽彲浠ョ敤鑷畾涔夐敊璇〉鏇挎崲鎵€鐪嬪埌鐨勫綋鍓嶉敊璇〉銆?br>
">1
有组织建模器和过程建模器，以及Notes数据库组成，其过程建模器例如以下，其工作流过程模型结构简单，活动节点和节点间的单向流线组成。
杩愯鏃堕敊璇?/i> 璇存槑: 鏈嶅姟鍣ㄤ笂鍑虹幇搴旂敤绋嬪簭閿欒銆傛搴旂敤绋嬪簭鐨勫綋鍓嶈嚜瀹氫箟閿欒璁剧疆绂佹杩滅▼鏌ョ湅搴旂敤绋嬪簭閿欒鐨勮缁嗕俊鎭?鍑轰簬瀹夊叏鍘熷洜)銆備絾鍙互閫氳繃鍦ㄦ湰鍦版湇鍔″櫒璁＄畻鏈轰笂杩愯鐨勬祻瑙堝櫒鏌ョ湅銆?
璇︾粏淇℃伅: 鑻ヨ浣夸粬浜鸿兘澶熷湪杩滅▼璁＄畻鏈轰笂鏌ョ湅姝ょ壒瀹氶敊璇俊鎭殑璇︾粏淇℃伅锛岃鍦ㄤ綅浜庡綋鍓?Web 搴旂敤绋嬪簭鏍圭洰褰曚笅鐨勨€渨eb.config鈥濋厤缃枃浠朵腑鍒涘缓涓€涓? 鏍囪銆傜劧鍚庡簲灏嗘 鏍囪鐨勨€渕ode鈥濆睘鎬ц缃负鈥淥ff鈥濄€?br>
娉ㄩ噴: 閫氳繃淇敼搴旂敤绋嬪簭鐨? 閰嶇疆鏍囪鐨勨€渄efaultRedirect鈥濆睘鎬э紝浣夸箣鎸囧悜鑷畾涔夐敊璇〉鐨?URL锛屽彲浠ョ敤鑷畾涔夐敊璇〉鏇挎崲鎵€鐪嬪埌鐨勫綋鍓嶉敊璇〉銆?br>
">1
其组织建模器例如以下，建立的组织模型：person，department，workgroup，role，material。角色带有一个參数以便在工作流运行时动态确定某个活动的具有參与者。
璇︾粏淇℃伅: 鑻ヨ浣夸粬浜鸿兘澶熷湪杩滅▼璁＄畻鏈轰笂鏌ョ湅姝ょ壒瀹氶敊璇俊鎭殑璇︾粏淇℃伅锛岃鍦ㄤ綅浜庡綋鍓?Web 搴旂敤绋嬪簭鏍圭洰褰曚笅鐨勨€渨eb.config鈥濋厤缃枃浠朵腑鍒涘缓涓€涓? 鏍囪銆傜劧鍚庡簲灏嗘 鏍囪鐨勨€渕ode鈥濆睘鎬ц缃负鈥淥ff鈥濄€?br>
娉ㄩ噴: 閫氳繃淇敼搴旂敤绋嬪簭鐨? 閰嶇疆鏍囪鐨勨€渄efaultRedirect鈥濆睘鎬э紝浣夸箣鎸囧悜鑷畾涔夐敊璇〉鐨?URL锛屽彲浠ョ敤鑷畾涔夐敊璇〉鏇挎崲鎵€鐪嬪埌鐨勫綋鍓嶉敊璇〉銆?br>
">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
工作流建模方法：
1. 基于活动网络：以活动间的关系为基础，大多数工作流系统的方式，能够转换为扩展petri网进行验证。
2. 基于形式化表示，petri，扩展的petri，工作流网，
3. 基于对话模型，
4. 基于状态和活动图，介于petri与图形化（活动网络？）之间的，比petrieasy理解，比图形化难理解，比图形化easy验证。比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。
