BPMN 建模见习手册


BPMN 建模见习手册 TT SOA 技术专题之“BPMN 建模见习手册” Page 2 of 17 BPMN 建模见习手册 BPMN(业务流程建模标注)是 BPM 以及 workflow 的建模语言标准之一,有必要学习。 BPMN 的主要目标就是要提供被所有业务用户理解的一套标记语言,包括业务分析者、软件 开发者以及业务管理者与监察者。BPMN 还将支持生成可执行的 BPEL4WS 语言。所以,BPMN 在业务流程设计与流程实现之间搭建了一条标准化的桥梁。在这本见习手册中,我们将介 绍一些相关知识,希望对您有所帮助。 业务流程建模标注 BPMN 业务流程图由一系列的图形化元素组成。这些元素简化了模型的开发,且业务分析者 看上去非常熟悉。这些元素每个都有各自的特性,且与大多数的建模器类似。跟任何标记 或方法一样,有关各方总会存在着意见分歧,下面我们就来介绍其元素注解和 BPMN2.0。  BPMN2.0 用注释法解决 BPM 编制  BPMN 元素的注解 BPMN 和 BPEL 当许多开发人员在辩论对于业务流程建模那种工具是最佳的的时候,Bruce Silver 已 经就为什么业务流程执行语言(BPEL)不能使得业务流程建模标注(BPMN)简化给出了强 有力的观点。下面我们来介绍一下 BPMN 和 BPEL 之间各种争论。  EDA 中事件的界定和社交媒体 Twitter 关于 BPMN 和 BPEL 的争论  BPMN 和 BPEL 可以实现往返工程吗? TT SOA 技术专题之“BPMN 建模见习手册” Page 3 of 17  BPMN 和 BPEL 如何产生的? 架构师 企业架构师在很多开发者的眼中一直是一个令人神往的职位。那么企业架构师在进行 业务流程建模的时候更倾向哪一种建模语言呢?  BPMN 为企业架构师流程建模通用语言 TT SOA 技术专题之“BPMN 建模见习手册” Page 4 of 17 BPMN2.0 用注释法解决 BPM 编制 BPMN 自 21 世纪初以来已经存在了,但似乎已达到一个新的高度,一:商业用户要求 它创造更多的面向业务流程的应用;二:最重要的 BPMN 2.0 版开始在工具产品中出现。 编制模式是一个重要补充。 许多组织和更多的个体在尝试任何事物之前等待 2.0 版本。因而 BPMN 2.0 将特别注 意许多方面。更重要的,或许,BPMN 2.0 添加了 XML 模式来支持使 BPMN 2.0 能够输出供 使用的被 BPEL 授权规则引擎转换的 BPM。BPMN 2.0 的正式标准认可仍在进程之中,但是 已经到达一个点,即厂商自定义一些 BMPN 2.0 性能。 这对于开发人员特别重要,因为它应能协助转换一种业务分析员的流程模型成为可执 行的软件的进程流线化。如何的进程的流线化目前很难讲得清楚。有很多的 BPMN 学习如 何做对企业的业务和 IT 双方的缺口。 注释的想法和用户熟悉的 UML 很相似,尽管这个建模语言随着时间的推移是除了注释 的已经被用于多种用途。 BPMN 的新版本包括加强了一些原有 BPM 注释,包含 Activities, Events, Gateways, Connections, Artifacts 以及 wimlanes。新版本包含扩展机制。 有效的 BPM 有一点跳跃,原因起源于需要确认进程的执行。因此,BPMN 2.0 新的编制 模型间发现利益并使用。 OMG 关键标准文档描述: 编制是进程的一类,但不同于标准的 BPMN Process 的目的和行为,一个标准的进 程,或者编制进程更像大多数进程模型和定义具体的 PartnerEntity 或者组织的活动流。 TT SOA 技术专题之“BPMN 建模见习手册” Page 5 of 17 相反,编制使业务参与者协调他们的相互影响更正规化。重点不是对在这些参与者所 做的工作编制,而是这些参与者(消息)之间的信息交流,。 Pools 和相关 Swimlanes,已成为 BPMN 必要的符号。这些概念指南对齐进程执行不同 的子进程的路径。在 BPMN2.0 中,编制存在 Pools 之外或 Pools 之间。 OMG 写到: Pools 是与会者的图形表示。一种编制,另一方面是一个不同类型的进程。编制定义 了参与者之间的相互作用序列。因此,不在单独的 Pool 中不存在编制——它不是一个单 一的参与者范围。 (作者:Jack Vaughan 译者:张培颖 来源:TechTarget 中国) 原文链接:http://www.searchsoa.com.cn/showcontent_28119.htm TT SOA 技术专题之“BPMN 建模见习手册” Page 6 of 17 BPMN 元素的注解 经过若干年的发展,BPMN 已经成为描述业务流程的一种标记方法。跟任何标记或方法 一样,有关各方总会存在着意见分歧:诸如哪些东西应该或不应该被放进这样的标记?什 么才是最有用或最相关的部分,使用标记时,组织中的哪些个体最有可能取得成功等等。 有时候这种意见分歧会导致争议,正如随之而来的最近一篇 Gartner 分析师的博客, 感叹成熟的 BPMN 需要高水平的技术技能一样。有没有这样的一个 BPMN 沙盒,其中的元素 可以让非技术员工也可以安全地“把玩”?这很难说,但我们的讨论会从检视一下现在所 理解的 BPMN 元素开始。 尽管不同的人对于他们认为是最重要的 BPMN 元素的关注点各有不同,对于 BPMN 标 注,有一些大家一致公认的基本要素。其核心集包括含事件、活动和网关在内的流对象 (flow objects),含顺序流、消息流以及关联在内的连接对象(connecting objects);以及含数据对象、文字注释和组在内的人工产物(artifacts)。 BPMN 的一个突出部分是强调被称为泳道类型的元素。该元素由泳池和泳道组成。 据 OMG 的说法,泳道图就是一个图形化的容器,该容器将一组活动与其他泳池的活动 进行分隔。活动因此成为整个业务流程的自动单元。泳道则用于对活动进行组织和分类, 是泳池内的子分区。 还是按照 OMG 的说法,泳道通常被用于分隔与特定公司职能或角色有关的活动。顺序 流可以跨越泳池内泳道的边界,但是消息流不能运用到同一泳池的泳道上不同的流对象之 间。 TT SOA 技术专题之“BPMN 建模见习手册” Page 7 of 17 如果你忽略一些特定的领域部分,看起来这一切似乎都跟流程图很类似。实际上, BPMN 就是以流程图为基础的、特别针对业务流程的标记,有关各方均同意坚持由对象管理 组织监管的 BPMN 标准。 BPMN 2.0 可能主要被描述为给以 Web 服务为基础的 BEPL 和 BPMN 提供更好的联系的一 次尝试。尽管提供的好处十分明显,BPMN2.0 在新元素方面还是激起了涟漪 – 在这一点 上,BPMN 纳入的元素超过了 100 种。不少的子类现在都具备 BPMN 的特征。如上所述,博 客圈已经被最近的争议搞得沸沸扬扬,不少人都在大声质疑,这样的东西作为 BPMN 元素 的核心是否真的适用于不那么懂技术的员工中间。 (作者:Jack Vaughan 译者:杨华军 来源:TechTarget 中国) 原文链接:http://www.searchsoa.com.cn/showcontent_42130.htm TT SOA 技术专题之“BPMN 建模见习手册” Page 8 of 17 关于 BPMN 和 BPEL 的争论 当许多开发人员在辩论对于业务流程建模那种工具是最佳的的时候,Bruce Silver 已 经就为什么业务流程执行语言(BPEL)不能使得业务流程建模标注(BPMN)简化给出了强 有力的观点。他最近看到 Active Endpoints 的 CTO Michael Rowley 在其博客中主张使用 BPEL 的 BPMN2.0 比新的 BPMN 执行语言更简化的观点,Bruce Silver 想做出正确的陈述。 首先,BPMN 和 BPEL 的目标有些轻微的不同。 当 BPMN 是面向图形的时候,如流程图,Silver 认为 BPEL 更多的是面向组件,像计算 机程序。开发人员使用 BPMN2.0 来创建 BPEL 单独使用 BPMN 的一套子集,根据说明书,该 子集支持“基础映射”。另一方面,“扩展映射”部分不符合 BPEL 的面向组件的架构。 例如:为了在图表中支持形式自由的环路,单一 BPMN 进程不得不分成多个通过消息 传输的 BPEL 进程。Silver 认为,建模标注和执行之间是如此复杂,就要避免来自 BPM 运 行期标准的 BPEL。 这不是最好的,Rowley 发表了第二遍博客回击,他表示在使用 BPEL 的 BPMN2.0 上的 辩论才刚刚开始。这仅仅是今年八月 BPMN2.0 进入测试版的事情,还没有厂商正式的使用 它。他认为 Silver 对于他所主张的使用 BPEL 的 BPMN 比使用 BPMN 执行语言容易的观点的 异议,Active Endpoints 已经创建了执行引擎,并且实施重叠语言结构的选取不是那么的 困难。 Rowley 写到“这次关于简单性的辩论不是关于厂商是否创建了的辩论,这是关于引擎 技术对在引擎上设计和部署流程的用户的根本影响。” 为了回应 Silver 主张的 BPEL 过多的面向组件而不能使用面向图形的 BPMN 高效的工 作的观点,Rowley 表示 BPMN 对于两者的样式都支持,但使用了一些警告。问题是 BPEL 的 TT SOA 技术专题之“BPMN 建模见习手册” Page 9 of 17 工作更像是一个流程图,是必须嵌套循环的。这导致了两个主要问题达成一致意见:BPMN 不是一个独立的执行语言。也许这是最应该得到注意的。 (作者:Rob Barry 译者:张培颖 来源:TechTarget 中国) 原文链接:http://www.searchsoa.com.cn/showcontent_29441.htm TT SOA 技术专题之“BPMN 建模见习手册” Page 10 of 17 BPMN 和 BPEL 可以实现往返工程吗? BPMN 和 BPEL 有可能实现往返工程吗? BPMN 只是为标注设定了标准。它和语义学有点关系,但还不足以生成可运行的东西。 Rowley 提到,对于如何将 BPMN 转化为可执行的东西,厂商有几种不同的选择方法。一种 方法是用厂商各自的专利技术来创建 BPMN 示意图,但 Rowley 表示,这样会令开发人员局 限于该技术中。 Rowley 解释道:“如何创建基本控制流,并具有可执行性,是需要投入大量的精力。 当你投入这么大的精力时,是不希望被束缚于某一种厂商的技术之中。主要的问题存在于 数据。数据操作完全不是在 BPMN 标准的范畴之内。但如果希望工作流能顺利执行的话, 这又是一个不得不考虑的问题” 同样,把完成的 BPEL 代码转化为业务人员能理解的图标也很重要。工程师擅于发现 异常事件,通常能够考虑到业务人员可能忽视的工作流事件。Rowley 说:“工程师可能考 虑到一些执行案例,例如,万一服务宕机,或做这个工作的人被炒了。工程师们可能设计 另一种工作流,不同于图标中,然后给业务人员看。这样可以促进开发者和业务分析师之 间的协作。” Tartu 大学计算机科学研究所的软件工程教授 Marlon Dumas 说:“BPMN 和 BPEL 之间 的转化是需要资金推动的。其中包括授权成本、安装成本、培训成本等。此外,还要付出 额外的开发努力,让研究同步进行。所以必须有实实在在的投资回报。比如,如果 BPMN 到 BPEL 的转化可以让公司不被某特定厂商绑定,就算是一种回报。不过,我还没有看到 厂商热衷于 BPMN 和 BPEL 之间互操作性的推动。甚至不同的 BPMN 工具之间或者不同的 BPEL 工具之间都存在互操作性问题。” TT SOA 技术专题之“BPMN 建模见习手册” Page 11 of 17 BPEL 和 BPMN 将何去何从? 业内人士对 BPEL 和 BPMN 的共同发展有着不同的看法。Dumas 认为,BPMN 仍然将继续 存在,但 BPEL 的前景尚不明朗。 他说:“BPMN 存在已有一段时日。至少在业务分析社区中,BPMN 将持续使用。在很 多进行流程再改造的大型机构中,BPMN 已经取代了流程图、IDEF 和 EPC(事件驱动流程 链)。” 如果厂商采用 BPEL,是否将引领用户更广泛地采用 BPEL?对此,Dumas 持怀疑态度。 Weerawarana 则看好 BPEL 的前景,业内多数厂商目前都支持 BPEL。同时,他表示, BPMN 将在业务分析领域继续成长。他认为这两种标准都将持续发展下去,因为它们都是自 动业务执行中很有价值的组成部分。 “这不是两种竞争的标准谁获得控制权的问题,”Gartner 的 Sholler 说,“而是这 两种优秀的标准都只能够解决一个问题的某些部分,两者都不够简洁,不够统一。” (作者:George Lawton 译者:杨晓明、Shirley 来源:TechTarget 中国) 原文链接:http://www.searchsoa.com.cn/showcontent_22202.htm TT SOA 技术专题之“BPMN 建模见习手册” Page 12 of 17 BPMN 和 BPEL 如何产生的? 业务流程执行语言(BPEL)在开发者社区获得了广泛关注,业务流程建模标注 (BPMN)在业务社区的重要性也越显突出。建立在这两个标准上的技术旨在简化分析师和 开发者之间的交流以及 SOA 应用的开发。但是,要把用 BPMN 创建的业务模型转换为用 BPEL 写的应用,却仍然存在很大的挑战。 BPMN 标注是一组标准,描述一个应用中组成元素看上去是什么样子。随着公司渐渐学 习如何使用 BPMN,让业务分析师能够创建应用,BPMN 已经越来越受欢迎。Gartner 的研究 总监 Dan Sholler 说:“如果漂亮的图片不但能有助于理解,还能帮助创建业务,那么对 它的兴趣就会如雨后春笋般涌现。但是不管它有多好用,我认为人们可能会误以为将进入 这样一个时代:画一幅图片,就能够把图片上的流程运行到大型的、跨厂商和跨技术的实 例中。事实上,其中的依赖性会带来很多困难。” BPEL 的诞生之初只是 Web 服务标准的衍生语言,更多对 BPEL 的关注来自开发者。有 的概念在 BPMN 中有,在 BPEL 中却没有。BPEL 之所以没有包括这些概念是为了让实施变得 更容易些。最简单的是 loop(循环)。你可以用 BPMN 画一个自循环的流程。在 BPEL 中则 是不允许的。 Gartner 的 Sholler 指出:“BPMN 这种标注语言让我们了解如何去用图标画一幅图, BPEL 语言则让我们了解如何去调用流程中的步骤。而我们所亟需的是一种能将前者转化为 后者的方法。” “从 BPMN 转化到 BPEL,已经存在普遍认可的方法。真正的困难存在于往返工程 (roundtrip engineering)。我希望 BPMN 示意图能直接、精确地表现我的流程。BPMN 示 意图中的每个变化都能反应在流程的执行中;执行中的每一个变化都可以反映到 BPMN 示 意图上。这对于许多技术来说都是个难题。” TT SOA 技术专题之“BPMN 建模见习手册” Page 13 of 17 BPMN 和 BPEL 如何产生的? 根据 Active Endpoits 公司的技术战略总监 MichaelRowley 所说,BPMN 源自一种可替 代 BPEL 的 BPML。BPML 中的标注部分就是最终流行起来的 BPMN。 WSO2 公司的 CEO 兼主席 Sanjiva Weerawarana 曾经参与了这两个方案的起草。他说: “工作流的愿景之一就是作为一个来弥补业务和 IT 之间鸿沟的桥梁。业务人员希望完成 某个任务的话,可能要花两年的时间来表述和实施。工作流要解决的正是这个问题。” Weerawarana 还说:“BPEL 原本不是旨在成为这个桥梁。” “BPEL 原先是很明确地当作可执行语言来设计的。我们从来没有想过让非技术人员写 BPEL。如果我们当初设计 BPEL 时就意识到这种重要性,就会创建一种可视化的标注语 言。” Weerawarana 说,“我们没有那样做,这是一个很大的缺憾。我们低估了工作流中 可视化标注的重要性。” BPMN 就是在流程建模的需求中应运而生的。它本质上是可视化标注的一个标准。BPMN 是一种更高层次的抽象,为业务人员提供所需的工具;而 BPEL 是一种更低层次的抽象, 即如何执行计划。 (作者:George Lawton 译者:杨晓明、Shirley 来源:TechTarget 中国) 原文链接:http://www.searchsoa.com.cn/showcontent_22201.htm TT SOA 技术专题之“BPMN 建模见习手册” Page 14 of 17 BPMN 为企业架构师流程建模通用语言 过度依赖 IT 基础设施来提供一个解决方案可能会引起新的问题。但这不意味着应该把 IT 的超常能力搁置起来。 BPM 独立分析师,Sandy Kemsley 说:“很多时候我都看到组织采取的手工流程和 BPM 中的流程完全一样。这是 IT 的能力推动了 BPM。业务会考虑用手工方法来改进流程,但它 可能不会明白 IT 的功能。” Kemsley 相信这就是企业架构师能够胜任的角色。一个企业架构师应该有用技术驱动 流程改进的工具和知识,因为他/她应该能驾驭业务目标和 IT 功能。更重要的是,他/她 应该有来协调这两者的工具和专业技术。 Kemsley 表示:“很可能企业架构师会对更高层次的业务流程管理亲自做一些工作, 在企业架构建模套件中,其中有一个工具会处理建模。它不会一直向下到细节的层面或连 接到可执行的 BPM 系统,但它会涉及到。” 设计可执行的业务流程通常不是企业架构师的角色。但高层次的建模让架构师创建了 可以被理解的业务和 IT。Kesmsley 说,BPMN 正成为许多企业建模方法的选择之一。 Kemsley 说:“BPMN 这个想法是用来为描绘流程模型而提供标准化的可视语法,由于 我们处理了标准化的流程建模标记,我们不会遇到某些人在模型前后转化方面所遇到的问 题。” Kemsley 认为 BPMN 的新版本将使它为企业架构师创建高层次的模型,这些模型更加类 似可执行的流程。“在 BPMN2.0 中,有更多的执行语义,更容易地把这些流程模型转化可 执行的格式。” TT SOA 技术专题之“BPMN 建模见习手册” Page 15 of 17 用 BPMN 建模是企业架构师将 IT 和业务结合起来的唯一方法。Kemsley 认为企业架构 师应该在其他方面寻找运用技术的方法。Kemsley 表示对整个 IT 投资来说,企业架构师不 得不有点传教士的味道。 (作者:Mike Pontacoloni 译者:杨晓明 来源:TechTarget 中国) 原文链接:http://www.searchsoa.com.cn/showcontent_32425.htm?lg=t TT SOA 技术专题之“BPMN 建模见习手册” Page 16 of 17 如何使用“正好”的复杂事件进行 CEP? 机遇和威胁都是有形的,但是威胁更多一些。企业全力以赴地去开拓机会,但是,威 胁需要最先关注。这个方案在采用复杂事件处理软件的早期就发生了——早期,欺诈行为 已经成为一种应用类型,排队得到 CEP 的处理。 当然,欺诈检测代表 CEP 的最主要的金融服务的外部入侵。为什么 CEP 在华尔街取得 的成功是显而易见的呢:世界金融市场主要都是计算机化,存有大量的信息,可以合并为 事件、分析并遵照程序获得利润。 即使面对 2008——2009 年的毁灭性的信贷危机,CEP 系统也能在华尔而街给予方法, 找到机会并赚钱。华尔街的机会比其他地方多,但是机会和欺诈是相辅相成的。它仍然是 宇宙中最主要的地方,并且有大量的复杂的事件。 华尔街是一个特殊的情况,CEP 正慢慢向高级地区扩张。尽管如此,在主街的企业都 想用现代化系统技术,开拓自己的机会。CEP 似乎是实现这一目标的手段。 华尔街之外 华尔街和缅因街的不同是显而易见的。在金融市场,向华尔街提供的大部分数据都是 恰当地,如果你需要加上一个特殊的转变,它也许会找微调基金。 需要特殊的算法来分析事件数据吗?能够做到!一些成功的交易可以为火箭科学家支 付运费,并创建分析过滤器。 但是,当你离开华尔街,事情就变得不同了。CEP 的实施能够威胁自身。这些是有危 险的项目,难以量化的经济利益。在开发团队中,本想做复杂事件的人们可能会认为这是 一个时机,建立他们自己的程序。 TT SOA 技术专题之“BPMN 建模见习手册” Page 17 of 17 课程导航 CEP 应用程序包含大量高级技术,值得应用开发团队去思考。就数据点而言,你所拥 有的关系数据、消息、HTTP Web 监听等聚集到“事件”。事件可以用软件对象、规则和 SQL-like 和 not-SQL-like 的程序语言进行处理。显然,“技术蠕变”是一个不断迫近的 威胁,等待伏击项目。 最好的办法是基于应用常识——对不起,这里没有惊喜。当开始 CEP 一段时间的时 候,围绕着“多少个 CEP 正好”的问题出现了。 CEP 架构师需要衡量多少个复杂的事件正好,什么样的更新速度正好,包含多少种新 技术正好。在一天结束的时候,你用“正好的复杂事件”会做的更好。 (作者:Jack Vaughan 译者:刘志超 来源:TechTarget 中国) 原文链接:http://www.searchsoa.com.cn/showcontent_43121.htm
还剩16页未读

继续阅读

下载pdf到电脑,查找使用更方便

pdf的实际排版效果,会与网站的显示效果略有不同!!

需要 6 金币 [ 分享pdf获得金币 ] 0 人已下载

下载pdf

pdf贡献者

ka520

贡献于2015-11-19

下载需要 6 金币 [金币充值 ]
亲,您也可以通过 分享原创pdf 来获得金币奖励!
下载pdf