（计算机应用技术专业论文）模型驱动的业务流程设计工具的研究与实现.pdf

上海交通大学硕士学位论文 摘 要 模型驱动的业务流程设计工具的研究与实现 摘 模型驱动的业务流程设计工具的研究与实现 摘 要要 业务流程管理与面向服务架构为企业的高效整合提供了优秀的解 决方案。同时，模型驱动开发理论的日趋成熟以及元模型创建支撑工 具的不断完善均为上述方案的实现奠定了坚实的基础。本文针对目前 已有的各种主流业务流程元模型以及相关标准进行分析研究，通过对 它们各自的优缺点进行比较后发现，面对日渐显现的整合需求和日渐 复杂的业务流程，现有的元模型或者过于复杂，或者定义过于形式化 而难于被分析人员理解，无论使用哪个元模型均无法很好满足现在的 业务需求。此外，已有的流程建模工具在易用性方面支持尚不够完善， 代码与图形视图的同步性往往不够一致。 本文针对上述问题提出了一个精炼的业务流程元模型 cutemeta， 旨在以尽可能小的概念集合来提供丰富的语义支持，并且从元模型层 面提出了对服务架构的支持，同时，使用业务流程模式作为框架对所 提出的元模型进行了全面而详尽的评估。之后分析了异构模型转换时 会遇到的问题，并且给出了基于 cutemeta 元模型的解决方案，然后探 讨了模型在控制流和语义方面的校验问题。在此基础上，基于 eclipse 平台的模型驱动架构实现框架 gmf，本文使用 mda 方法设计并实现 了基于 cutemeta 元模型的业务流程建模工具 cuteflow。 该工具能可视 化地对业务流程进行建模， 使业务分析人员和 it 专业人员进行更有效 的沟通，并且显著地提高了开发和维护的效率。 目前，cuteflow 工具已和万达业务流程引擎集成，在万达信息研 上海交通大学硕士学位论文 摘 要 发中心进行了实际应用，并得到了良好的反馈结果。 关键词：关键词：业务流程建模，模型转换，模型驱动架构，工作流模式 上海交通大学硕士学位论文 abstract research and implementation of model-driven business process modeler abstract with the combination of both bpm (business process management) and soa (service oriented architecture), a promising solution to the highly efficient integration of enterprises is springing. in parallel, mda (modeling driven architecture) is proceeding rapidly on its way to a high maturity along with the perfection of supporting tools, which provides a solid foundation for the implementation. in this paper, we analize various mainstream business process meta-model and corresponding standards. by comparing both their merits and demerits, we find it much more difficult for them to meet the increasing requirements of integration and complex business processes. meta-model nowdays are too complicated or too formalized to be understood by analysts. none of them could meet current business requirements smoothly. moreover, not much support on usibility of modeling tools is available. synchronization between design and source code views is usually a problem. in this paper, we abstract a refined business process meta-model in coping with the above problems which is aimed at the support of profound semantics with as small as possible a set of concepts. besides, support of service architecture is proposed from within the metal-model level. meanwhile, we take workflow patterns as the framework for evaluating our meta-model thoroughly and deeply. after that, issues of transformation between heterogeneous models are discussed with cutemeta-based solutions proposed. also, model validation for the correctness of 上海交通大学硕士学位论文 abstract controlling flow structure and semantics is discussed. on this basis, we choose gmf, which is an mda implementation for eclipse platform, for both designing and implementing cuteflow a business process modeling tool based on cutemeta following the mda methodology, which visualizes business process modeling, makes the communication between business analysts and it specialists more smooth, and increases the efficiency of both the development and maintanence. currently, cuteflow has already been integrated with wonders business process engine which is in use at wonders research and development center with a good feedback also. key words: business process modeling, model transformation, modeling driven architecture, workflow pattern 上海交通大学上海交通大学 学位论文原创性声明学位论文原创性声明 本人郑重声明：所呈交的学位论文，是本人在导师的指导下，独立 进行研究工作所取得的成果。除文中已经注明引用的内容外，本论文不 包含任何其他个人或集体已经发表或撰写过的作品成果。对本文的研究 做出重要贡献的个人和集体，均已在文中以明确方式标明。本人完全意 识到本声明的法律结果由本人承担。 学位论文作者签名：唐文炜 日期：2009 年 2 月 2 日 上海交通大学硕士学位论文 摘 要 上海交通大学上海交通大学 学位论文版权使用授权书学位论文版权使用授权书 本学位论文作者完全了解学校有关保留、使用学位论文的规定， 同意学校保留并向国家有关部门或机构送交论文的复印件和电子版， 允许论文被查阅和借阅。本人授权上海交通大学可以将本学位论文的 全部或部分内容编入有关数据库进行检索，可以采用影印、缩印或扫 描等复制手段保存和汇编本学位论文。 保密保密，在 年解密后适用本授权书。 本学位论文属于 不保密 不保密。 （请在以上方框内打“” ） 学位论文作者签名：唐文炜 指导教师签名：沈备军 日期：2009 年 2 月 2 日 日期：2009 年 2 月 2 日 上海交通大学硕士学位论文 第一章 绪论 1 第一章 绪论第一章 绪论 1.1 研究背景 研究背景 现代企业面临业务拓展、重组以及重新定位的需求日益显现；各项标准的出 台日渐加快，执行流程的修改频率逐渐加大。业务流程管理(business process management，bpm)提供了一种全局性的框架，在组织机构内部，人员和系统作为 参与者共同协作完成定制好的流程。从而实现高效、敏捷的运作模式。另一方面， 组织机构内部各独立的应用之间的交互以及各组织机构之间应用的交互需求不断 增加，面向服务的体系架构(service oriented architecture, soa)应运而生。bpm 从 编制(orchestration)的角度对业务流程进行全局性控制管理;soa 从编排 (choreography)的角度为异构应用系统架起了互通的桥梁。随着相关技术的不断成 熟，将两者进行结合的策略逐渐成为主流34353637。osoa 组织提出的服务构件 架构 (service component architecture, sca32)提供了将业务流程包装成服务构件 的能力，业务流程的空间局限性立即被突破，从而获得更大程度的重用；此外， 在业务流程中提供服务构件的调用能力使组织机构获得更强的流程优化能力。 但是，集成所面临的一个重要问题就是如何兼顾到众多相互独立的遗留业务 流程管理系统，必须考虑使用什么样的机制来保证集成代价尽可能最小。2001 年 omg 组织提出了模型驱动架构（model driven architecture, mda） ，通过将软件 的业务逻辑和实现技术分离开来，可以较好地解决交互性、可移植性等问题，并 提高软件开发的效率。mda 核心在于以模型为整个软件系统的基础，将开发过程 的关注点更多的放到设计阶段。它提供的代码自动生成能力使模型的建立具有更 强的实际意义，即一旦完成模型的建立就等于具有了最终系统。这和业务流程设 计的理念极为相似。同样的，现代面向服务的趋势就是一切均为服务构件，广义 上来讲，也是一种模型的建立。可以看出，模型是驱动 bpm 结合 soa 进一步扩 展自身价值的关键所在40。 一般业务流程管理周期主要包括流程设计、部署、执行和监控四部分。在各 业务流程管理软件供应商给出的解决方案中，会提供可视化流程建模工具，通常 上海交通大学硕士学位论文 第一章 绪论 2 以各自独立的形式来存储，当流程被部署后则使用各自特定的方式来实现流程的 实际执行，流程元模型的定义互不兼容，导致了各个特定业务流程软件之间缺乏 互操作能力，最终使业务流程的重用遭到很大的限制。于是各组织从不同的关注 角度纷纷提出各自的业务流程建模规范。从建模角度来看，业务流程可以分为元 模型层、符号表示层、以及执行层。元模型是对现实世界中的业务流程核心概念 以及它们之间关系的一种抽象描述。在工业界和学术界内出现了各种元模型建立 的方法。uml 活动图除了用于软件系统模型的行为描述之外，还因为它和业务流 程在许多方面的共性而被选作其元模型。然而，经过实践后发现，uml 的符号不 易被业务人员所理解。 于是omg/bpmi在2004年提出业务流程模型标记(business process model notation, bpmn)作为符号表示层的标准,它从组织机构流程中提炼 出最佳实践方式，以此为业务流程图提供了可视化的图形标记以及具体语义。从 提出至今在业界已经得到广泛的使用，并被认为是到目前为止描述业务流程的最 佳图形符号标准1。对象管理组织(object management group, omg)在 2003 年提 出业务流程定义元模型(business process definition metamodel, bpdm)标准时，流 程图的表示部分也采用uml活动图， 但最终在2007年正式发布时仍然选择bpmn 作为其流程符号层标准。 1.2 研究意义 研究意义 作为业务流程管理系统的前端，流程设计工具提供了一种可视化的操作方式 便于 it 人员和业务分析人员进行协同开发定制。 工具的底层核心是通用的业务流 程元模型，现在多个组织分别从不同的关注点上提出了各自的建模标准。而现又 得建模工具则分别选择了不同标准所定义的元模型进行开发，使得他们在业务管 理解决方案的最前端就产生了根本性的异构，从而流程引擎无法辨识由其他建模 工具所创建的业务流程模型实例。从纵向来看，单个解决方案不是过于简单就是 过于复杂，往往无法较好的针对企业的实际情况进行实施；从横向来看，如果结 合不同的解决方案的若干个特性进行整合利用的确可以为具体案例提供可行实施 方案，但是，由于较差的互操作性导致二次开发整合的成本偏高，最终方案失败。 因此，以异构方案的整合为目标，对现有的主流业务流程元模型进行研究比较， 提出易于扩展而又精炼的元模型是从根本上架起了异构工具之间的互通桥梁。无 论是整合所需要的二次开发成本，还是对遗留系统的利用程度，本文的研究工作 都具有相当重要的现实意义。 上海交通大学硕士学位论文 第一章 绪论 3 另一方面，mda 和 soa 技术日渐成熟。从最初标准的提出、制定，到后来 不断的修改，以及参考实现的提供，这两者为企业应用的进一步发展明确了方向。 而 bpm 在这样的环境下， 应该充分利用这些优势。 传统的业务流程管理往往是以 单个企业为中心，所有的数据，资源都是自我定制的，十分缺少甚至是不必要和 外界进行交互。而在信息整合日益显现出其重要性的今日，则亟需引入以服务为 交互载体的开放式企业架构。业务流程中如何结合进服务的概念，如何从流程建 模阶段就引入对服务的关注，以及二次建模时如何对服务进行进一步扩展同时又 达到最小化的破坏。这些问题都将在对 mda 的研究下得到解决40。 综合来看，开发一个基于通用业务流程元模型的设计工具十分必要。该工具 能有效地解决已有流程的重用性问题，同时为新出现的服务构件架构提供了前端 互操作的直接支持。基于该工具，业务分析人员和 it 人员能够更好的共同协作完 成业务流程的制定，大大缩短了设计周期，并且大大降低由于理解角度不同所产 生的重复工作成本。 1.3 国内外研究现状 国内外研究现状 业务流程元模型是对业务流程概念的抽象表示，它描述了业务流程在功能、 行为、组织、数据四个方面内容。为了充分描述一个业务流程，每个流程模型都 需要将各种形式的信息整合到一起。各种不同的流程元模型的关注点本身不尽相 同，这使得他们各自的元模型元素有所不同。为了对现有流程元模型进行比较评 估，b list2定义了一个通用的元模型，他涵盖了很大一部分业务流程所涉及的概 念。在他的研究中一共选取了 7 种元模型，分别是 uml 活动图(ad)、业务流程 定义元模型(bpdm)、业务流程建模符号(bpmn)、事件驱动流程链(epc)、集成定 义方法 3(idef3)、petri 网，以及角色活动图(rad)。最终指出大部分元模型都具 有较强的功能、行为和数据描述能力，在组织结构的描述上，以软件系统描述为 目的的 idef3 和 petri-net 相对较弱， 相对其它元模型而言， 它们缺少角色的概念。 进一步的，只有 uml 活动图有明确的元素来表示一个角色属于组织机构内部还 是外部。而对于流程参与者的具体类型，大部分元模型均只用一个概念不加区分 的进行表示。 w.m.p. van der aalst 等人从控制流3、数据4、资源5，以及异常处理6这四 个方面对业务流程进行了详尽的阐述，总结了相应的业务流程模式，这些模式描 述了相应关注角度上经常遇到的结构特征，语义表达，概念属性等问题是应该采 上海交通大学硕士学位论文 第一章 绪论 4 用的通用指导性原则。 p wohed1和 nick russell7等人均以前三种流程模式为评估 标准分别从描述能力和流程建模适用性这个角度对 bpmn 和 uml 活动图进行了 较为系统的研究，为两者提出了改进建议。1分析了3中提到的 20 种流程建模 时会遇到的常见需求，指出 bpmn 对于 multiple instances 和 milestone 这两个模 式提供有条件的支持，对于 synchronising merge, discriminator 和 interleaved parallel 三种模式提供部分支持。造成这样的结果源于相同语义的流程模式具有多 种表示形式； 在数据方面， bpmn 不支持 workflow 和 environment 两种数据模式； 对于资源，bpmn 的支持最为缺乏，组织结构和资源的建模并不在其标准定义范 围之内，它通过甬道(lane)和池(pool)这两个概念的使用来表达特定资源与具体任 务之间的关联语义。在所有 43 个资源模式里，仅对其中的 8 个模型提供支持。另 外1还将 bpmn、 uml ad 和 ws-bpel 进行了横向比较： 在控制流方面， bpmn 和 uml ad 有着很多的重复，前者对 interleaved parallel routing 和 synchronising merge 这两个模式具有更强的描述能力，而后者则能更好的支持 discriminator 模 式。bpmn 与 ws-bpel 相比而言，各有一部分流程模式只被其中一者所支持。 从数据模式来看，uml ad 对 multiple instances data 和涉及多个相关任务的 data interaction 模式提供较好的支持，bpmn 则对于发生在任务和环境之间的 data interaction 模式支持更好。对 data transfer 和 data-based routing 这两类模式中三 者提供的支持项差别更大。 最后， 在资源模式方面 bpmn 和 uml ad 都提供了较 为有限的支持，ws-bpel 则没有考虑提供相应支持。为了解决这个问题，ibm 等 公司提出了 bpel4people8，作为 ws-bpel 的扩展，它引入了一系列元素用以描 述参与者交互行为。 ibm 的 bpws4j27提供了一种基于树型结构的流程模型编辑环境，从功能性 和易用性来看都比较欠缺。 oracle 同时提供了基于 jdeveloper 和 eclipse 平台两个 版本的 bpel designer，它提供了图形化界面和一些向导来完成业务流程建模工 作，但是可视化部分和代码之间不能保持较好的同步。activeendpoint 的 activevos designer28虽然较好的解决了同步问题， 但是它不允许 bpel 代码的编 辑功能。而 bpel 本身是一种开发者语言，图形可视化实现在一定程度上为建模 带来的方便， 但作为主要用户的开发者更习惯于直接编辑源代码， 因此 activevos designer 的只读约束较大的影响了工具的易用性。 soa 最初以一种架构方法学而出现，它提出将应用系统封装成服务的形式以 一致的方式开放给外界使用，在这些服务之上，传统的业务流程将以服务组合的 形式被重新定制。但是，对服务的开发、重用、部署、集成等相关实施细节并没 上海交通大学硕士学位论文 第一章 绪论 5 有具体的规定，这就给服务架构的实用性带来了巨大的挑战。此时，mda 技术已 渐趋成熟，它从方法论本身到实施细节都有比较好的规范和参考实现，这为前者 提供了良好的技术契合点，服务架构的应用整体上仍然缺乏有效的模型驱动方法 来使整个应用生命周期的各个阶段的自动化程度得到提高，不过已经有不少研究 从不同角度尝试着两者的结合。ateret anaby-tavor9等人针对服务架构系统的生 命周期提出了一个模型驱动的整合方法，其中涉及到用例模型、构件业务模型、 bpmn 模型、轻量级流程执行模型 splice 以及业务活动监控模型，遗憾的是它 对于流程执行模型的选取并不通用，大部分执行引擎并无法识别 splice，从而使 得这个方法在适用性方面减弱不少。philip mayer10等人认为 uml 在软件建模方 面较为成熟，其活动图所提供的语义元素对业务流程也能提供相当程度的支持， 更重要的是 mda 也是以 uml 为核心。 基于这些考量提出了一个 uml 旁集 （uml profile）uml4soa，它从元模型层扩展了面向服务的流程元素，同时该研究给 出了到 ws-bpel 的转换方法和参考实现。ws-bpel 是面向服务的业务流程的实 现标准，它的出现为 soa 从理论上升到实际应用提供了形式化基础，它定义了松 耦合服务之间的集成方式以及易于扩展的业务流程定制方式。 随着针对业务流程元模型的各种研究日渐深入， 工业界各种建模标准的出现， 必然导致的一个结果就是它们之间的兼容性问题。为了解决模型间的互相转换， 人们提出了各种模型转换语言和框架。 一部分研究尝试利用 uml profile 机制对活 动图进行扩展定制，然后转换成 bpel11, 14，但是都没有覆盖足够多的业务流程 相关内容。audris kalnins12等人解释了使用 uml 活动图和 bpmn 来设计业务流 程虽然十分相似，但是两者之间的转换还是存在不少问题，同时提出以 uml profile 机制提出了一套业务流程特定的uml 扩展子集， 并展示了如何使用mola 语言来进行转换。作为直接支持服务编制的元模型，绝大部分的流程引擎均以 ws-bpel 为标准，这就意味着它往往是转换过程中目标元模型的首选。他的持久 化表示是一种块结构的格式，而现有的主流元模型（如 bpmn）则属于图结构， 这一本质区别为后者到前者的转换带来了很大的困难15, 16。 多数转换方法都停留在较为通用层面上来提出解决方案，针对特定领域内的 支持尚不成熟，在业务流程元模型中亦是如此。模型转换的关键是要保留一个模 型的语义，但不幸的是往往不能达到语义的完全保留，因此经过转换后可能存在 信息丢失。通常的方法包括两种：如果目标模型支持注释(annotation)属性，那么 可以将转换源的特有语义记录到目标模型相关元素的注释属性中，不支持注释， 那么可以通过用户介入的方式。 marionmurzek 和 gerhardkramler 提出了一种分析 上海交通大学硕士学位论文 第一章 绪论 6 业务流程元模型比较框架13， 使用 atl 和 qvt 分别对四种业务流程元模型， (即 adonis,bpmn,epc 和 uml 活动图)进行转换，从基本控制流的角度分析得出 7 条特定于业务流程元模型的转换可能出现的问题。 1.4 论文的研究目标和内容 论文的研究目标和内容 本文拟分析各种现有的业务流程元模型及相关标准，通过对它们之间进行比 较得出其优缺点，并结合现有研究成果以及相关工业界的实践经验，抽取出业务 建模所共有的核心概念集合，基于此提出尽可能小规模的核心元模型，在此之上 再添加服务架构和资源扩展的元模型层直接支持。 基于所提出的元模型，采用模型驱动方法学，将其作为平台独立模型(pim)， 利用已有的框架支撑工具创建平台相关模型（psm） ，并根据 cutemeta 的元素进 行实现代码的定制开发，最终设计并实现一个包含丰富控制结构和语义表达的业 务流程建模工具 cuteflow。 在元模型的研究中，本文还要对三种不同类型的工作流模式共 100 个模式进 行分析，并将其作为评估框架来评价 cutemeta 对业务建模的有效性以及实用性。 同时，对于异构元模型的转换，还需要分别研究可能出现的各种问题，并结合现 有的解决方案提出自己的方案。另外，在模型的校验方面，需要根据 cutemeta 的 具体定义，以及后端流程引擎的运行时约束来进行校验规则的限定。 可视化建模工具方面， 本文拟基于 eclipse 平台进行开发， cuteflow 的主要框 架基于 gmf 来构建，同时还需辅以 gef、emf，分别从图形管理和领域模型管 理两方面进行支持。另外，作为一个完整的建模工具，本文还要研究 eclipse 插件 技术来实现图形向导、扩展工具栏按钮等具体组件的定制开发。 1.5 本文的组织结构 本文的组织结构 本文共五章，各章的内容概括如下： 第一章介绍了本文的背景知识，包括业务流程建模、模型驱动架构、面向服 务架构等领域，分析了本课题的研究意义，然后介绍了目前国内外关于该课题领 域的研究现状，最后提出了本课题所要做的主要工作和需要实现的成果。 第二章主要比较了各种业务流程元模型的异同，讨论了它们各自的优缺点， 在此基础上提出了精简的业务流程元模型 cutemeta。接着，分析了异构元模型之 上海交通大学硕士学位论文 第一章 绪论 7 间进行转换的主要问题，结合模型的比较来分析各种转换方法的优势与不足，然 后提出针对 cutemeta 的异构适配转换方法。然后，分析了基于 cutemeta 的校验 方法。 第三章使用3种不同类型的业务流程模式来对本文提出的业务流程元模型 cutemeta进行逐个地分析和讨论，并将结果与其他相关的流程元模型对模式的支 持情况进行比较，得出结论。 第四章描述了业务流程设计工具cuteflow的具体设计与实现，并分别针对其 中的各个模块进行详细分析。同时，设计了一组流程模型来对cuteflow进行应用 性验证。 第五章主要总结了现阶段的主要工作成果，并对其中的不足进行分析以及对 将来的工作进行展望。 上海交通大学硕士学位论文 第二章 业务流程元模型 cutemeta 8 第二章 业务流程元模型第二章 业务流程元模型 cutemeta 本章研究并提出了一个精简的业务流程元模型cutemeta。本章首先概要介 绍模型驱动架构（mda）的元模型描述体系。接着，对几个当前主流的业务流程 元模型（包括：bpmn、uml 活动图、xpdl 和 bpel）各自的优缺点进行分析 比较。然后，基于它们的核心元素提出了业务流程元模型cutemeta，并讨论了 基于 cutemeta 的模型与其它异构模型间进行转换的相关问题及解决方案。 最后阐 述了基于 cutemeta 的模型校验。 2.1 mda 及其元模型描述体系及其元模型描述体系 2.1.1 模型驱动架构模型驱动架构 对象管理组织（omg）于 2001 年提出一种新的软件开发方法学模型驱动 架构17（mda） ，它把模型作为软件开发的核心，贯穿了整个生命周期的各个阶 段。在 mda 理论中，软件系统的开发始于平台独立模型（platform independent model, pim） ，设计人员根据业务需求定义与具体实现技术为无关的 pim，它从业 务功能和业务行为上对整个系统进行描述，为了提供这种抽象描述能力，mda 中 的元对象设施18（meta object facility, mof）应运而生，所有的 pim 都必须遵循 mof 的定义规范。根据 mda 理论，模型与最后的可执行代码之间能够进行无损 的映射匹配， 一旦完成了 pim 的定义就意味着软件系统已经被平台无关的实现了。 下一步就是选择具体的技术平台，设计自定义转换规则将 pim 转换成平台相关模 型（platform specific model, psm） 。最终的可执行程序就将通过 psm 的转换来得 到。本质上，所有的过程都是对模型内容与结构的丰富和转换。因此，mda 规定 所有的模型都必须基于 mof，这样才能确保各种应用的模型表示在相互转换、存 储、解析等环节不失兼容性和一致性。 除了 mof 之外， omg 还定义了一系列的标准来对 mda 各个环节进行支持， 其中还包括：统一建模语言（uml） 、通用仓库元模型（cwm） 、xml 元数据交 换格式19（xmi）等。 上海交通大学硕士学位论文 第二章 业务流程元模型 cutemeta 9 2.1.2 元模型描述体系元模型描述体系 omg 基于 iso 等组织中使用的传统 4 层建模架构制定了 mof18规范用于描 述和定义元数据，它提供了一种可扩展的方法来对元数据进行管理，也就是说用 户可以实现任何类新的元数据，并且对已有类型进行修改。为了达到这个目的， mof 定义了一个元数据分层架构，它系统化地定义了元模型的描述方式。整个架 构分为 4 个层次18，如图 2-1所示： m3元-元模型层 m2元模型层 m0实例层 m1模型层 mof 模型 uml 元模型 uml 模型 对象实例 通用架构层次mof映射 实例化 图2-1 元建模架构及mof映射图 fig.2-1 metamodeling architecture with a mof mapping 1) m0 实例层：这层由我们希望描述的具体数据所组成。 2) m1 模型层（元数据层） ：这层的元素定义了 m0 实例层中数据的类型。 3) m2 元模型层：这层的元素定义并且描述了 m1 层元素的结构和语义。 4) m3 元元模型层：这层的元素定义并描述了 m2 层元素的结构和语义。 在这 4 层架构中，自顶向下每一层分别用于描述下一层的数据类型 m3 元-元 上海交通大学硕士学位论文 第二章 业务流程元模型 cutemeta 10 模型层的提出将下面的 3 层紧密地联系到了一起，它为不同应用模型之间的转换 提供了一个桥梁，换句话说，只要基于同一个元-元模型，不同模型体系之间也能 够互相转换。 mof 对其有做了进一步的扩展， mof 的元-级别并不是固定不变的， 它可以定义任意个元模型层， 而位于顶层的被称为 mof 模型， 而底层的则称为实 例层，相邻两层之间保持互为模型与实例的关系。 mof 本身是基于 uml 按照面向对象的方式来设计。以 4 层 mof 映射为例， 它的核心是顶层的 m3 元元模型层，其中许多概念和术语都引自 uml，例如它直 接使用了 uml 的 class 和 attribute 来描述 m2 层元模型的静态实体，使用 association 来描述这些实体之间的关联结构。但是，它们之间也并非完全一致， 例如在 m3 层，两者对于关联元素的约束定义就有所区别，uml 中允许存在多个 associationend，而在 mof 中则必须有且仅有 2 个存在。 2.2 主流业务流程元模型主流业务流程元模型 业务流程管理系统以企业的业务活动为核心，辅以组织机构不同角色的参与 共同协作完成企业的各项任务。开发这类系统的第一步就是流程建模，而流程模 型的创建依赖于具体的元模型集，从学术界到工程领域经过多年的探索和实践分 别从不同关注角度对业务流程建模可能需要的概念进行提炼总结，提出了各种不 同的业务流程元模型，下面我们将介绍 4 种目前主流的业务流程元模型。 2.2.1 bpmn bpmi 组织在 2004 年提出了 bpmn23，主要目的在于提供一个非技术人员易 于理解的图形化符号表示，使业务分析人员能够更好地与开发人员一起协作完成 流程管理系统生命周期的各个阶段。为了达到这个目的，bpmn 以业务分析人员 所熟悉的传统流程图表为基础，选取了核心元素作为其组成部分。首先，对每个 业务流程模型，bpmn 都用一个业务流程图（bpd）来表示，它是一个流程模型 的网状结构的图形表示。同时，bpmn 为各种流程相关的概念定义了图形符号， 一共有个类别，分别是流对象（flow object） 、连接对象（connecting object） 、 泳道（swimlane）和工件（artifact） 。 这样的设计除了使概念之间的关联更加明确清晰之外，更重要的是既满足了 核心概念的精简又提供对复杂结构的进一步支持。除了这些优点之外，bpmn 还 具有健壮的理论基础，它以 pi 算子这个进程代数分支作为其数学基础，从而具备 上海交通大学硕士学位论文 第二章 业务流程元模型 cutemeta 11 了与执行层语言 bpel 进行转换的强大能力。 bpmn 也存在缺点，比较突出的是 xor-join 网关的语义问题。在 bpmn 规 范中， xor-join 网关既被用来描述简单聚合(只要输入顺序流有 token 到来一次则 执行一次， 若有多个 token 到达则执行多次)， 同时又被用来描述鉴别器(第一条到 达的输入顺序流的 token 被允许通过，其后到达的 token 被禁止，也称作“多选 i)。因此，它没有明确执行次数到底是 1 次还是多次。另一方面，如果将这个网 关当作鉴别器来使用，bpmn 也没有说明到底禁止通行到什么时候为止，这将会 导致整个流程实例无法继续运行。 2.2.2 uml 活动图活动图 uml24已经成为软件建模与设计的事实标准，在最新的 2.1 版本中，uml 一 共定义了 13 个建模视图来从不同角度对软件系统进行描述。 其中 6 个视图用于描 述软件的静态结构；3 个视图用于描述软件的行为；另外 4 个视图则用于描述软 件交互的不同方面。 作为其中的一个重要组成部分， uml活动图 （activity diagram, ad）属于第二个分类，它描述了软件系统的动态行为。 ad 用于描述行为的基本单元被称为动作（action） ，每个动作能够接受一系 列的输入，然后将它们转换成一系列的输出，输入和输出均可以为空。每个动作 的执行均可能改变系统的状态。ad 对动作的类型进行了详细的定义，一共包含 40 多个不同类型的动作。为了从更高的层次来描述系统的整体行为，ad 定义了 活动（activity）这个概念。每个活动由一系列的动作组成，这些动作之间相互协 作关联共同组成一个可执行的活动。 可见，uml 活动徒的语义与业务流程建模所需要的语义有着原生的相似性。 此外，uml 活动还有图形化描述，支持信息流表示和表达能力较丰富等优点。 缺点方面，uml 的事件触发机制比较有限，不完全支持对业务流程的抽象和 细化，另外，ad 与外部环境进行交互的能力显得相对薄弱，而互操作性恰是面 向服务的架构中最为重要的一个特征。 2.2.3 xpdl 工作流管理联盟（wfmc）制定 xpdl25作为不同流程工具所创建的业务流 程之间进行互操作时的中间交换格式。 基于对 wfmc 早先制定的交换格式 wpdl 上海交通大学硕士学位论文 第二章 业务流程元模型 cutemeta 12 的使用以及 xml 不断的被广泛的用于文档描述格式，wfmc 于 2002 年发布了 xpdl1.0，它在继承 wpdl 的语义的同时使用 xml schema 定义了新的语法。 基于 xpdl 的交换可以发生在设计时的流程模型之间，除此以外，参与方也 可以是运行时模型、模拟时模型以及监控时模型中的任何一种，为了实现这个目 的，xpdl 抽取了流程建模中最小的概念集，同时，基于这个最小化元模型制定 了一个公共交换接口，外部程序可以通过这些接口对流程模型进行任意操作。 缺点方面，xpdl 没有提供流程概念的图形化符号标准，而它在元模型中又 定义了流程元素的图形化信息，于是，在生成持久化数据时会同时记录下流程模 型的逻辑信息和基本的可视化信息 （如流程活动的 x、 y 坐标位置， 节点的尺寸等） ， 但是，对于流程执行时真正有用的信息仅仅是实际的应用数据和逻辑结构，因此， 基于 xpdl 的流程模型持久化数据往往存在许多冗余信息。 2.2.4 bpel 2002 年 ibm 等公司将各自用于描述 web 服务交互方式的标准进行整合，制 定了一种基于 xml 的语言web 服务业务流程执行语言（ws-bpel） ，简称 bpel26。 一方面，bpel 可以对业务流程的行为结构进行概括性描述，另一方面，它 还包含了执行一个业务流程所需要的参数细节。将业务流程的行为与具体实现步 骤分离的方式既为业务分析人员在流程建模提供了更为清晰直观的视角，同时又 不失流程执行所必须的信息。通过扩展 web 服务交互模型，bpel 还增加了对业 务流程事务特性的支持。作为一个互操作的集成模型，bpel 使流程的自动化集 成能力从企业内部到企业与企业之间获得很大的提升。 不足的是，bpel 本身并没有提供业务流程元素的图形化符号，另外，它使 用的语法结构为块状结构，而对其可视化之后的形式往往难于被业务分析人员所 理解， 同时， 块状结构与 bpmn 等基于图结构的元模型之间又十分难于互相转换。 因此，注定 bpel 只能用作为执行层元模型。 2.3 cutemeta 设计设计 本节结合前面对各主流业务流程元模型的分析结果提出了精简的元模型 cutemeta，下面将从设计目标、架构以及具体要素几个方面来进行阐述。 上海交通大学硕士学位论文 第二章 业务流程元模型 cutemeta 13 2.3.1 设计目标设计目标 cutemeta 旨在结合现有各种主流业务流程元模型，提取出业务建模所共有的 最精简概念集合，以此来满足最基本的流程语义表达能力。在元模型层面能够直 接提供面向服务架构的语义扩展点支持。同时，在元模型层面还应能够增强外部 人力资源的参与度。 通过添加这两个方面的扩展支持来进一步提高 cutemeta 的实 用性。 基于该精简元模型最终实现的业务流程建模工具 cuteflow 应该能够创建具 有丰富控制结构和语义表达的业务流程模型。并且，cutemeta 应该便于和基于其 它业务流程元模型的异构模型进行互相转换。 2.3.2 核心概念与架构核心概念与架构 在 bpmn、uml、xpdl 和 bpel 四个主流业务流程元模型中，我们进行比 较后发现，虽然名称不完全相同，但是它们都直接或间接的提供了对活动和控制 关系以及路由这三种语义的定义。因此，我们直接选取这三者作为 cutemeta 的核 心元素。在 cutemeta 中，我们将表达业务流程的架构元素分为三种不同类型的概 念，分别是活动、变迁关系、以及路由节点，如图 2-2所示。其中虚线部分为架构 的可变点：应用（application）和资源（resource） ，目前 cutemeta 分别为两者提 供了一些子类以支持特定的实现方式。今后可以通过继承的方式来实现不同类型 的应用和资源。 activity autoactivity timeractivity manualactivity bindableactivity subporcess router andjoinandsplit orsplit xorsplit xorjoin orjoin conditionalrouter transition -fromactivity 1-toactivity 1 resourceapplication resourceassignment 1 * 1 * role webservicejspappjavaclassscript appbinding 1* 1 * 图2-2 cutemeta元模型架构元素 fig.2-2 architectural elements of cutemeta 整个业务流程构成的核心元素就是活动，它在较粗的粒度上定义了具体的业 上海交通大学硕士学位论文 第二章 业务流程元模型 cutemeta 14 务功能，元模型中所有类型的活动均继承自一个抽象根元素，称之为“活动” ，该 元素主要定义了名称、描述、以及扩展属性列表这 3 个域成员。业务流程的起始 和终止分别由开始活动和结束活动来标明。每个流程有且只能有一个开始活动， 该约束表达了入口单一性这个语义特征；而结束活动则只需满足至少存在一个的 约束，它表达了多出口这一语义特征。在实际执行业务功能的抽象级别上，按照 外部资源以及行为方式的不同，又抽象出人工活动、自动活动和定时活动以及子 流程。子流程概念的引入使得流程间的相互调用成为可能，为跨流程的集成提供 了元模型级别的基础语义支持。 变迁关系的引入将各个孤立的活动节点联系到一起组成一个有机的整体，它 从整个业务流程的组织角度来表达各个业务功能之间的依赖和转换关系。元模型 中定义了有条件变迁和无条件变迁两种变迁关系，从语义上表达了活动之间的转 换是否存在约束条件。 i1i2 im o1ono2 m - in guzelian, g. business process modeling: a service-oriented approach, in pr