为执行建模 & BPM

　　在 2008 年篇有关 IBM® WebSphere® 业务流程管理工具 文章 中曾讨论过为执行而建模思路方法在 2009 年篇 后续文章中 讨论了 IBM BPM 堆栈产品 V6.2 版本改进这些产品简化了为执行建模流程现在到了 2010 年由于我们已经在这个领域有了些实际实现体验另外业务流程管理方面也出现了些新工业标准因此现在是时候来再次讨论下这个主题了

　　什么是为执行建模？

　　为执行建模并不是个新概念这种方式已经在传统软件Software和系统开发中被用了有些时间了它总是开始于个用某种可视语言表达高级平台独立模型(PIM)这个模型然后会被以种针对特定平台特定编程语言翻译或转换为个特定于平台模型(PSM)然后才可被编译后执行实际上这个思路方法使用了 Object Management Group (OMG) Model Driven Architecture (MDA) 原理图 1 显示了这两个模型的间关系

　　图 1. 模型转换



　　这个受模型驱动架构开始于我们熟知并且是长期建立起来将系统运转和该系统如何使用其平台功能细节分离开来想法MDA 3个首要目标就是通过关注点架构分离可移植性、互操作性和可重用性

　　BPM 解决方案交付是种新受业务驱动和以流程为中心交付应用思路方法它能够也应该使用在过去十几年间软件Software开发和系统工程中所积累最佳实战MDA 原理当然也可以应用在这里但由于 MPM 解决方案交付比较独特它更强调可重复业务设计并需要业务使用者和分析人员更多参和因此在采用为执行而建模技术时需要加以特别考虑

　　用 WebSphere BPM 应用为执行建模

　　很多公司均已经为基于 WebSphere BPM 产品套件解决方案交付使用了为执行而建模思路方法和窍门技巧图 2 显示了从业务模型转换为技术业务模型再到实现模型典型转换

　　图 2. 从业务模型到实现模型



　　图 2 显示了这 3个阶段:

　　个业务分析员或业务流程架构师在 Basic 或 Advanced 模式下在 IBM WebSphere Business Modeler 中创建个业务模型这个业务模型图形化地显示了业务流程并使用了和业务分析员和主题专家相关语义这个业务模型也可被用于仿真

　　个技术业务分析员或技术流程架构师在 IBM WebSphere Process Server 模式下优化此模型生成个技术业务模型来图形化地给出业务流程并开始将业务语义翻译成技术语义技术业务分析师从 WebSphere Business Modeler 作为个项目交换文件导出技术业务模型这个文件格式为 .zip内含组成这个实现模型所有运行时工件

　　个流程架构师或集成开发人员将这个实现模型导入到 IBM WebSphere Integration Developer 这个实现模型图形化地给出要实现业务流程集成开发人员可进步完善这个模型并完成从业务语义到技术语义翻译

　　这里有点非常重要需要注意即虽然是工作在 WebSphere Business Modeler 内但底层那些模型还是表示为个特定于 Modeler BOM(业务对象模型)流程模型当作为个项目交换文件导出模型时这些 BOM 流程模型就会被转换为 BPEL 流程模型而这正是您在 WebSphere Integration Developer 内处理语义

　　改进这个开发流程

　　用户在使用为执行建模方式交付 WebSphere BPM 解决方案方面有了些成功经验尤其是在再面向对象和以集成为中心流程领域而它实现是通过使用 BPEL 作为转换自业务流程模型底层特定于平台模型(PSM)获得 BPEL 是种开放行业标准也是种经过验证流程编排语言并特别侧重于 Web 服务集成现在很多公司都具有基于 BPEL 关键流程应用在生产中运行提供了所需事务整体性、安全性和性能

　　虽然就运行时而言目前 WebSphere 为执行建模提供了强壮解决方案但是在开发流程方面仍有改进空间尤其是在迭代开发模型同步领域

　　图 3 给出了在目前工具条件下这个情况是如何处理

　　图 3. 用 WebSphere BPM 工具进行迭代开发流程



　　如您所见这个流程可能会相当复杂并且会涉及几个手动步骤而手动步骤很容易发生实际用户体验也表明这种方式对于经常需要进行更改情况将非常有挑战性这就是广为人知 “roundtriping” 问题当然这个问题并不是 WebSphere BPM 堆栈独有只要您在具有区别语义区别领域间进行模型转换模型同步都将是个挑战

　　于是出现了为执行建模些最佳实战种是在 WebSphere Integration Developer 内减少对代表着业务模型业务逻辑模块更改由于业务逻辑模块内元素直接和 WebSphere Business Modeler 内元素映射所以应该在 WebSphere Business Modeler 内做更改尤其应该减少对流程结构性更改

　　像这样建议对于减少模型同步需要可能会有所帮助但是它们并不能完全消除这种需求而这就为我们带来了另种方式

　　共享模型和 Lombardi 方式

　　Lombardi Software 是 BPM 软件Software和服务领先提供商该公司于今年年初被 IBM 收购它对为执行建模有着自己独特见解它会在流程整个生命周期都保持此模型具有相同格式图 4 给出了 Lombardi Teamworks BPM 套件架构

　　图 4. Lombardi Teamworks 为执行建模方式



　　查看原图(大图)

　　如上所示在 Teamworks 内定义所有流程元素均存储在个单 Shared Model 中用以表示流程内每个元素从流程图到业务数据、用户界面和系统集成借助 Shared Model 架构在个流程元素内所作更改会(根据访问权限)立即可见并可由其他流程元素访问这就使得流程元素的间依赖性目了然也就让流程设计者能够进行更好交流并有助于流程质量提高

　　那么为什么这点对于为执行建模如此重要呢？业务建模者和开发者(如图 4 所示)处理是相同共享底层流程模型 —— 只是从区别视图和透视图 ——- 此模型永远不会区别步并且 roundtripping 问题也没有了！这个范型会激励更为迭代和敏捷开发业务管理者和 IT 部门也会有更紧密协作

　　结束语

　　现在对于为执行建模我们有了两种策略:

　　转换模型以实现优化运行时行为



　　跨流程生命周期共享模型

　　哪个更好？答案仍要依赖于您实现是哪种业务流程以及哪些原因对您最为重要比如是对敏捷和迭代开发支持还是对 round-trip 支持又抑或是运行时健壮性、持续流程改善、鼓励业务/IT 协作简单易用性等等

　　希望这些信息能够帮助您在为您特定需求选择正确思路方法和工具时扩展您思维和决策过程