内容


业务流程管理解决方案中的迭代开发

使用 WebSphere Business Modeler 和 WebSphere Integration Developer 的一个以模型为中心的方法

Comments

简介

WebSphere Business Modeler 和 WebSphere Integration Developer 中的迭代开发 (Marc Fasbinder,developerWorks 2008)描述如何随时间变迁保持 WebSphere Business Modeler(以下简称 Modeler)与 WebSphere Integration Developer (以下简称 Integration Developer)中的业务模型之间的一致性。基于对现实环境的观察,本文描述应用于业务流程的迭代方法以及 Modeler 和 Integration Developer 中可促进迭代的功能。描述可行的方法之后,我们推荐我们认为最好的方法,将工具的当前功能考虑在内。我们还会依次示范三个迭代开发场景,以探究两种产品的迭代开发功能并建议可能产生最佳效果的使用模式。

迭代开发

迭代开发是一种软件开发方法,能够通过需求和开发项目的连续改进让一个解决方案实现预期目标。迭代 这一术语常被错误地用作是增量 的同义词。尽管迭代方法可能会与增量交付方法一同使用,但两者并不相同。在本文中,我们将迭代作为优化循环(refinement cycles) 讨论,而非可交付增量。

因为将它作为一个优化循环,因此一个迭代不必包含开发流程的所有阶段。例如,可以有阶段特定迭代,比如分析迭代设计迭代。可以想象得到,这会使迭代开发方法具有相当大的复杂度和不稳定性。在复杂度谱的最顶端,您可以以优化循环内的优化循环结束,每个周期都使用不同的迭代频率。为此,确定最适合于特定软件解决方案的迭代开发方法很重要,要将用于开发它的当前工具的功能考虑在内。

BPM 和迭代开发

业务流程管理(BPM)解决方案是一种特别不稳定的业务软件类型。快速变化的业务环境以及持续的业务改进实践,意味着会有频繁的业务流程变化和较短的预期上市时间。由于一个 BPM 解决方案的最初观念不太可能比大多数软件解决方案更接近于预期的最终结果,这意味着在更多的时间内要充塞更多的迭代。而如果没有明确支持迭代开发的工具,这就不太可能。

Modeler 是 IBM 用于建模业务流程的工具,而 Integration Developer 是用于实现这些流程和支持它们的集成逻辑的工具。将这些工具结合起来就能够支持一个迭代开发流程,可创建和持续改进可部署的业务流程。Modeler 主要以分析为目标,且在一定程度上面向开发流程的设计组件,而 Integration Developer 主要负责实现方面。本文讨论在一个 BPM 上下文中使用这两种产品的迭代开发。我们将需要用到 Modeler 的活动指定为建模 活动(包括分析和设计),将那些用到 Integration Developer 的活动指定为实现 活动。因此,当我们谈到建模迭代 时,我们指的是 Modeler 中存在的优化循环,当我们谈到实现迭代 时,我们指的是 Integration Developer 中涉及到的同一概念。

迭代开发选项

在 BPM 解决方案开发中,使用支持迭代开发工具是取得成功的必要条件,而非充分条件。实际的迭代开发流程同样重要。迭代方法有多个变体。对这些变体的简单分类主要取决于大多数改进工作所在的开发流程阶段。通过使用这种分类,并基于涉及到 Modeler 和 Integration Developer 的开发流程经验,我们确定了 4 种主要迭代开发方法:

  1. 以实现为中心的方法
  2. 带定期模型更新的、以实现为中心的方法
  3. 对模型和实现的并行迭代方法
  4. 以模型为中心的方法

以实现为中心的方法

以实现为中心的方法包括对实现方法的重复增强,它基于技术需求,且在大部分情况下基于变化的业务需求。有一个初始建模阶段,且实现项目最初可能生成自模型。然而,在建模活动持续进行时,所有新的改进都在 Integration Developer 中完成,没有利用工具中的代码生成和同步功能,如图 1 所示。

图 1. 以实现为中心的方法:大多数迭代发生于实现端
以实现为中心的方法
以实现为中心的方法

论证

我们找到大量对该方法的论证,包括:

  • “我们的时间很紧,我们不能坐在那里等待模型完成。”
  • “同步和合并是很复杂的工作,我们害怕因犯错而导致作业损失。”
  • “所生成的代码不合我们的意,因此我们要进行大量实现更改,这使得我们很难保持模型与应用程序的同步性。”
  • “我们喜欢将业务模型保持在一个很高的 ‘业务’ 级别,并在 Integration Developer 中实现所有细节。”

优点

  • 几乎没有模型/实现同步化工作。
  • 更易于采用偏向于某些非功能性方面(比如性能)的特定实现设计。

缺点

  • 业务模型应不断演化,以反映对实现的更改,但事实往往不是这样的,即使是这样,实现也不太可能准确反映模型。
  • 失去了将模型更改合并到实现中的能力,以及从代码生成中获得的益处。
  • 分析常被忽视,且实现更倾向于不满足业务目标(导致更多迭代)。

带定期模型更新的、以实现为中心的方法

该方法也侧重于实现,但与上一个方法的不同之处在于,开发流程明确需要每隔一定时间或在一定数量的实现改进之后将更改传回给模型。在工具的半自动化协助下,实现更改被传递给业务分析人员。这种方法在每一批中的更改量较少时效果最好。

图 2. 带定期模型更新的、以实现为中心的方法
带定期模型更新的、以实现为中心的方法
带定期模型更新的、以实现为中心的方法

论证

对该方法的论证类似于上一个方法,但更关注于保持实现与模型的同步。

优点

  • 与上一方法一样,该方法更易于采用特定实现设计。
  • 模型与实现之间有较高水平的同步。

缺点

  • 即使有工具的协助,向模型应用更改也是很耗时的,特别是在批次更改较大时。
  • 由实现更改产生的模型更改通常不易为业务分析人员所理解。
  • 与实现的随后同步可能会达到一定级别的复杂度,此时不再可能继续代码生成和所生成项目与实现的自动同步。
  • 与第一种方法一样,分析常被忽略。

对模型和实现的并行迭代方法

在这种情况下,优化循环同时发生在模型和实现中。这些周期在两种情况下都源于新需求、初始错误的纠正、各种结构化改进,等等。在某个时候,模型与实现是同步的。同样,在更改量较少时同步化效果最佳。

图 3. 模型和实现的并行迭代
模型和实现的并行迭代
模型和实现的并行迭代

论证

“往返” 拥护者通常偏向于使用这种方法,因为它更侧重于这样的情况,即需要快速更改实现来解决生产问题或在紧凑的工作期限内完成工作。在处理现有项目时,该方法也很有用。

优点

  • 该方法支持以不同的速率优化模型和实现,从而降低它们对彼此的依赖性。
  • 可将现有实现(起初未建模的实现)添加到模型中。
  • 与以实现为中心的方法相比,能够实现更高水平的实现/模型同步。

缺点

  • 模型与实现的同步会变得很复杂,特别是在有大量不一致的更改时。
  • 工作通常被复制。
  • 存在这样一种风险,即实现过程中引入的更改不会经过正式分析和管理流程。

以模型为中心的方法

在该方法中,源于新需求或设计更改的所有优化循环都在模型中执行。在经过少量更改(理论上)后,会生成相应的实现项目并将其并入现有实现中。请注意,以模型为中心的方法不需要所有实现项目都生成自模型,也不否定特定于实现域的项目或迭代的存在。反之,它要求所有项目都必须与业务相关,且只有 那些与业务相关的项目才能被建模,因此基本上没必要将实现传回给模型,如图 4 所示。

例如,在特定业务流程中,有必要指定该流程有一个 “通过电子邮件通知客户” 活动。使用支持 yyy 接口的 xxx 电子邮件适配器实现该活动,不会为理解或改进业务流程提供任何额外价值,因此该信息不应包含在业务流程模型中。另一方面,如果在业务流程模型中没有指定 “通过电子邮件通知客户” 活动,实现该流程的开发人员就无法获悉它,因而最后的实现就不会满足业务需求。从这个层面上来讲,“通过电子邮件通知客户” 是一个业务相关的概念,而实现中所用的特定电子邮件适配器类型不是。这通常意味着,大多数迭代,特别是最重要的那些都发生在建模域中。

图 4. 以模型为中心:迭代发生在模型中
以模型为中心:迭代发生在模型中
以模型为中心:迭代发生在模型中

论证

模型驱动开发的拥护者通常乐意使用该方法,因为它将更多的重点放在模型上,可以理解为比依赖于技术的实现更加持久且 “更接近于业务”。

优点

  • 对更改周期的更佳控制和管理。
  • 纠正错误的成本比在实现中要低。
  • 确保不忽略必要的分析工作。
  • 通常,最佳实践方法构建于代码生成器中。
  • 实现工作减少了,实现更一致且不易出错。

缺点

  • 实现开发人员必须等待每个建模迭代完成,不过这可以通过精心规划和调整建模器与实现器的比例改善。
  • 所生成的代码不会总是精确满足实现需求。
  • 需要对 Modeler 中特定于实现的设计功能有一个很好的理解。

尽管未考虑工具的功能和局限性,但基于上面概述的每种方法的优缺点,可以简单证明以模型为中心的方法的优越性。当然,当工具功能支持这种方法时,以模型为中心的迭代情况就变得更有力。像 Modeler 这样的 BPM 工具精通从业务流程模型生成实现项目。当您从实现项目中查看生成的建模元素时,情况就不一样了。有限的功能可以实现,但很难开发这样的功能,且通常不能完全自动化。为此,在实现所有更改之前对(需要建模的)所有更改建模时,保持模型与实现的同步更为简单。

因此,以模型为中心的迭代开发是我们开发 BPM 解决方案推荐使用的方法。该方法有诸多益处,包括:

  • 管理 —— 便于在实现之前对更改进行控制和授权。
  • 模型和实现的同步化 —— 单向同步只需较少的工作量,且确保将不一致减至最小。
  • 生产率 —— 高度的代码生成节省时间,并从头开始执行最佳实践。
  • 解决方案质量 —— 推广 “以分析为先” 的行为,更容易达到业务需求。
  • 更好的业务与 IT 的一致性 —— 通过这种方法更易实现业务流程模型与实现之间的结构均衡。

图 5 显示了使用 Modeler 和 Integration Developer 的以模型为中心的迭代流程的一个详细例子。

图 5. 迭代开发流程
迭代开发流程
迭代开发流程

(参见图 5 的放大图。)

该流程显示,模型因新需求和改进而得到优化。此外,有一个从实现到模型的反馈链接,它用于反映显示情况,其中:

  • 新需求或约束是在实现期间被发现的。
  • 所生成的实现被拒绝,因为模型不完整或不准确。
  • 某个模型设计受实现青睐。
  • 现有服务或数据定义被导入到 Modeler 中,以供重用。

使用 Modeler 和 Integration Developer 的迭代场景

在我们详细说明迭代场景之前,让我们快速看一下 Integration Developer 的同步向导的相关功能,它是使用 Modeler 和 Integration Developer 的迭代方法的一个关键推动者。同步向导具有以下功能:

  • 作为一个工作单元,添加或合并因业务模型更改而产生的实现项目。
  • 从 Integration Developer 开发人员的工作空间删除因业务模型更改而产生的实现项目。
  • 如模型与工作空间更改之间有冲突,两者择一。
  • 接受或拒绝 Integration Developer 工作空间更改。

这里是对向导工作方式的总结:

  1. 一个 Integration Developer 项目交换文件(PI)从 Modeler 中被导出。该文件包含产生自业务流程模型的 Integration Developer 项目。
  2. 当首次将该文件导入到 Integration Developer 时,所导入的 Integration Developer 模块的一幅映像被创建。该映像称为基准
  3. 每次(通过向导)将模型和实现同步化时,都有一个基准被创建。
  4. 当在 Modeler 中进行更改且导出一个新的 PI 文件时,向导比较该文件内容与上一个基准,以确定自上一个基准创建以来发生了哪些建模更改。
  5. 向导还比较工作空间相关内容与基准,以确定自上一个基准创建以来发生了哪些工作空间更改。
  6. 用户接受或拒绝这些更改,所接受的更改被应用到工作空间。
  7. 一个新基准被创建。

同步化范围是选定的 Integration Developer 模块及其依赖库。参与同步过程的 Modeler 更改的范围由导出的 PI 文件决定。该文件可能源自特定 Modeler 元素(比如一个流程)的导出,或源自整个 Modeler 项目及其依赖项的导出。如果使用后一种方法,向导的效能最好,即需要较少的人为干预。

同步向导还可用于通过 Rational Asset Manager 库中包含的资产同步化工作空间,从而实现对更改的管理。在这种情况下,向导的行为方式与在同步化 “直接” Modeler 导出文件时一样。

以下场景将帮助您深入了解同步特性如何运作,并阐述如何通过 Modeler 和 Integration Developer 使用建议的以模型为中心的方法。场景不会对同步功能提供全面描述。欲了解有关该主题的更多信息,请在 WebSphere Business Modeler V6.2 Information Center 查阅 Modeling iteratively with WebSphere Integration Developer

注意:我们在这些场景中使用了 Modeler 和 Integration Developer V6.2.0.2。不过,这些内容也适用于产品的 V7 版本。V7 中引入的最重要的增强就是通过图形可视化更改影响的功能。

场景 1:仅在 Modeler 中的更改

业务分析员 Luke 创建了一个 Search Customer 流程模型,如图 6 所示,它位于 Modeler 的 Customer Validation 项目中。该模型在 Integration Developer 的 Customer Validation 实现模块中仅包含为实现预定的流程。两个项目的名称相同且包含相同的流程,这有助于 Luke 与 Integration Developer 开发人员 Lucy 通信。它还促进两个项目的自动同步。如果 Luke 对这个 Search Customer 很满意,他就会将模型导出到 Integration Developer。因为他希望简化迭代开发流程,因而导出整个 Customer Validation 项目。他使用所推荐的导出选项,该选项能明确分离规范和实现。

图 6. Search Customer 流程
Search Customer 流程
Search Customer 流程

(参见图 6 的放大图。)

Lucy 将项目导入到 Integration Developer 中,意识到她希望做一些更改。Lucy 可以在 Integration Developer 中进行更改,但她知道这些是与业务相关的更改,必须在 Moderler 中指定,因此她遵循公司的开发流程,告知 Luke 她的更改:“我认为,在我们未找到匹配搜索标准的任何客户时,我们需要创建一条新客户记录。这是旧有系统中的一项功能。这也是未来的一项需求吗?”

Luke 认为 Lucy 的需求有重大关系,于是进行了更改。他还添加了自己的更改。他将映射元素的名称 “Map” 改为更有意义的 “Copy address status”。更改后的流程模型如图 7 所示。Luke 导出模型并将 PI 传给 Lucy,然后 Lucy 使用 Modeler 导出同步了她的 Integration Developer 工作空间。

图 7. 修改的 Search Customer 模型
修改的 Search Customer 模型
修改的 Search Customer 模型

(参见图 7 的放大图。)

Lucy 分析了同步向导中的新更改,如图 8 所示。

图 8. 同步向导中的建模和实现更改
同步向导中的建模和实现更改
同步向导中的建模和实现更改

(参见图 8 的放大图。)

在左窗格中,Lucy 看到了受更改影响的项目。由于选中了 Modeling Artifacts 选项卡,她看到了 Modeler 更改(以及熟悉的 Modeler 图标)。在右窗格中,Lucy 查看了左窗格中选定的项目对应的建模更改。之所以称之为建模更改,是因为它们源于业务流程模型的更改,但实际上它们是要从 Integration Developer 工作空间添加(左上端的加法修饰器)、更改(δ 修饰器)或删除(红色 X 修饰器)的 Integration Developer 项目的描述。(欲了解同步向导中使用的图标和修饰器的更多内容,请查阅 WebSphere Business Modeler V6.2 Information Center。)

Luke 所做的所有更改都被默认接受,这可以从每个更改图标右下角的绿色 “记号” 修饰器看出来。Lucy 没有更改她的工作空间,因此无工作空间更改,当然也没有不一致的更改。

在提交新更改之前,Lucy 最后看了一下将受到更改影响的高级工作空间项目,查看方法是选择左窗格中的 Workspace Artifacts,如图 9 所示。

图 9. 显示受更改影响的项目的工作空间项目窗格
显示受更改影响的项目的工作空间项目窗格
显示受更改影响的项目的工作空间项目窗格

(参见图 9 的放大图。)

Lucy 看到了所有受影响的模块,逐一选择它们之后,她能够看到对每个模块应用的更改。Lucy 了解工作空间项目如何会受更改影响,因此她提交了这些更改。这些更改被成功纳入其工作空间中。

该场景展示一个简单的 “在 Modeler 中创建一个流程模型,生成模型,更改模型,再次生成” 实例。这类同步通常相当简单明了,且仅需要接受更改(Lucy 所需做的仅是单击 Commit)。由于 Lucy 未在 Integration Developer 中进行任何更改,她可以删除原来的 Integration Developer 项目并导入更改的模型来获得同样的结果。但如果这样做,我们就没有一个简单场景来向您展示同步向导的基本运作方式。

该场景更现实的一种情形就是实现已更改;例如,一名开发人员已经编码实现了生成的 Java™ 组件(存根)。在这种情况下,删除工作空间并不是一种好的选择。

注意:要特别注意含有 Java 实现的模型任务的重命名。在这种情况下会生成一个新的空 Java 组件。不过,旧的组件还未从工作空间中删除,因而允许您引用上一实现。

场景 2:仅在 Integration Developer 中的更改

该场景将同步看作仅对 Integration Developer 做更改,即更改与业务无关。

Lucy 意识到在需要通过电子邮件通知的流程中漏了一步。她知道该活动是与业务相关的,且她打算将这个需求告诉 Luke。同时,她决定使用 Integration Developer 电子邮件适配器来实现该服务。她创建了一个 Notification Services 项目并在该项目中创建了一个电子邮件适配器。

她还对映射地址状态的方式进行了更改。通常她会要求 Luke 在 Modeler 中做更改,但是有些 Integration Developer 映射功能在当前版本的 Modeler 中不受支持。Lucy 通过最近的 Modeler 导出执行了一个同步化流程。由于未对模型做更改,因此没有建模更改,只有工作空间更改,如图 10 所示。Lucy 意识到她为电子邮件适配器创建的模块在同步向导中未显示。这是因为同步机制仅考虑为同步化选定的模块(本例中为 CustomerValidation)及其依赖库所包含的更改。

图 10. 仅显示选定模块的工作空间更改
仅显示选定模块的工作空间更改
仅显示选定模块的工作空间更改

(参见图 10 的放大图。)

Lucy 看到了她对映射(Assign 活动)所做的更改,该更改默认情况下是被接受的。她小心翼翼地确保不拒绝该更改(通过按下带蓝色 x 修饰器的图标),因为这样做会导致工作空间更改被删除。她认为,“这是恢复到前一同步状态的一种方式”,但是这并非她这次想要的。她提交了更改,并决定使用相同的 Modeler 导出执行另一个同步化流程。图 11 显示了她看到的内容。

图 11. 被接受的工作空间更改作为被拒绝的建模更改重新显示
被接受的工作空间更改作为被拒绝的建模更改重新显示
被接受的工作空间更改作为被拒绝的建模更改重新显示

(参见图 11 的放大图。)

Lucy 看到同一更改,但此次它是作为一个建模更改显示。另外,更改现在是工作空间上的一个 “删除项”(x),而它前面是一个 “加号”(+)。Lucy 觉得很困惑。这是什么意思?当她执行上一个同步时,包含新工作空间元素的一个新基准被创建。Modeler 导出(PI 文件)不包含这些元素,因此为实现一个同步化状态,向导将其作为一个建模更改,表明这些元素已从工作空间删除。在 V7 中,这类更改被划分为未并入模型中的实现更改

Lucy 注意到该更改被默认拒绝。这表示,如果她提交该更改,这不会影响其工作空间。换言之,她对映射所做的更改不会被删除,这与她接受更改时的情况一样。因为该更改永远不会在 Modeler 中实现,在随后的同步中它将继续以被拒绝建模更改的形式显示。

Lucy 现在将注意力转向她为电子邮件适配器创建的那些新模块。她使用 Modeler 导出同步该适配器。Lucy 现在能够看到其余的工作空间更改,如图 12 所示。与上一种情况不同,这里没有 Integration Developer 基准可供比较,因此这些更改作为默认接受的 “删除” 建模更改显示。她小心翼翼地确保不提交这些更改,因为这样做会导致她的电子邮件适配器更改从工作空间上被删除。因而她取消了向导。

图 12. 同步化一个最初并非从 Modeler 生成的模块
同步化一个最初并非从 Modeler 生成的模块
同步化一个最初并非从 Modeler 生成的模块

场景 3. Modeler 和 Integration Developer 中的更改

所选方法的其中一个基本规则是与业务相关的更改必须在 Modeler 中完成。然而在实践中,源自这种更改的实现项目与特定于实现的更改并非总是界限分明,因而导致同步冲突。接下来的场景更接近于现实情况,它深入探析如何在既有模型更改又有实现更改时实现同步,有些更改可能会有不一致。

Lucy 将电子邮件通知更改告知 Luke。Lucy 还要求 Luke 更改 Telecom Operations Content Pack (TOCP) findCustomer 业务服务对应的 FindCustomer Modeler 任务,该服务是她所在公司的一个标准。这表示,她不需要在每次迭代后更新引用(或拒绝更改)。

Luke 更改了模型,如图 13 所示,并将其作为一个 Integration Developer PI 文件导出。

图 13. 使用 findCustomer 业务服务的修正模型
 使用 findCustomer 业务服务的修正模型
使用 findCustomer 业务服务的修正模型

Lucy 使用同步向导合并 Luke 的建模更改与她的工作空间更改。向导首先提醒她处理 TOCP 模块,她选择将这些模块导入到工作空间中,如图 14 所示。

图 14. 将新模块导入工作空间
将新模块导入工作空间
将新模块导入工作空间

接下来,Lucy 查看向导的同步页面,如图 15 所示,且发现有不一致的更改。她忘记了她已对 FindCustomer 接口的 preferred interaction style 属性进行了修改。现在这个更改与因替换模型中的 FindCustomer 接口而被删除的接口不一致。

图 15. 工作空间更改窗格中显示的不一致更改
工作空间更改窗格中显示的不一致更改
工作空间更改窗格中显示的不一致更改

默认情况下,不一致的建模更改是受拒绝的,而这并非 Lucy 希望看到的。她接受更改,不一致的工作空间更改被自动拒绝。Lucy 还能够在建模更改和工作空间更改窗格中看到不一致的更改(按相反的次序)。她提交了更改,更改被成功纳入工作空间,如图 16 所示。

图 16. 接受更改后的组装图
接受更改后的组装图
接受更改后的组装图

Lucy 仍然需要将 Notify customer by e-mail 连接到电子邮件适配器,且每次同步都有一组相关更改作为被拒绝的建模更改显示。

优化迭代流程

如果您仔细研究上面场景的同步截图,就会发现,Modeler 中即使较小的更改都会导致许多 Integration Developer 工作空间更改。鉴于模型比实现的抽象级别更高,这在一定程度上是不可避免的。在有大量更改被报告的情况下,同步向导试图制定正确的决策,如您所见,只有上一个场景(其中有一个冲突)要求用户明确接受或拒绝一个更改。

上述场景阐明了同步向导的基本行为。表 1 概括了该行为。

表 1. 同步向导的行为
接受拒绝
建模更改更改被应用于工作空间。更改未被应用于工作空间,但是将继续在每次迭代后作为被拒绝的建模更改显示。
工作空间更改更改被应用于工作空间,且将在随后的迭代中作为被拒绝的建模更改显示。除非将模型更新为与基准同步。在这些更改中,动作被倒转。例如,向工作空间添加一个项目会产生这样一种建模更改:如更改被接受,将导致同一项目从工作空间被删除。对工作空间所做的更改被删除。

通过该表,我们可以得出一些重要结论:

  • 在拒绝工作空间更改时一定要谨慎,因为这可能导致作业损失。
  • 在随后的同步中接受建模更改也会导致工作空间更改的损失。
  • 被拒绝的建模更改集会变得很大,因为它们会随每次迭代累积。为使该集合尽量小,对于实现更改伴有模型更改的所有情况,更改模型也很重要。对模型进行更改首先会减少同步工作量。
  • 能够减少工作量并使迭代更流畅的场景是:当所有建模更改被接受且工作空间更改的数量较小时。
  • 如果每个迭代中正在处理的更改量很小时也会有所帮助。

根据这些结论以及我们从许多实践场景的实现中所得的观察结果,我们提出以下准则来进一步增强建议的迭代流程:

  • 业务分析人员和 Integration Developer 开发人员将从合作中获益,他们的合作可以确保业务流程模型是实现就绪的,且与实现模式(例如 WebSphere Process Server)相关的所有属性都得到正确设置。因此,Integration Developer 开发人员精通 Modeler 工具集的相关特性是很重要的。这也会增加建模更改被接受的可能性。
  • 正在进行同步的 Modeler 项目不应该包含不完整的或不是为实现预定的元素。这意味着,在同步化过程中不必拒绝这些元素。
  • 生成的项目不引用的 Integration Developer 项目应尽量在独立的实现模块中实现。这可以减小同步向导中显示的工作空间更改量。

结束语

在本文中,我们为迭代开发推荐了一种以模型为中心的方法,如得到正确运用,该方法将产生较大效益。我们还展示了如何通过 WebSphere Business Modeler 和 WebSphere Integration Developer 使用这样一种方法,并鉴于工具的功能和局限提供了附加准则来确保迭代流程的高效性。


相关主题


评论

添加或订阅评论,请先登录注册

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=502241
ArticleTitle=业务流程管理解决方案中的迭代开发
publish-date=07262010