业务驱动的开发

引言

在当今预算日渐紧张的经济环境中，越来越多的公司开始发现信息技术 (IT) 开销受到 IT 部门外的各种业务线的控制。为了让企业中的 IT 部门能够在这个受控制的财务环境中“幸免遇难”并适应这个环境，他们需要使自己与业务需求保持一致。此外，业务流程在不断地发生变化，而企业需要快速地调整其策略，以反映这些变化。企业软件开发流程固有的问题是其缺乏灵活性，无法跟上为了适应市场发展和竞争而发生的业务变更的速度。为了让企业 IT 部门度过困境并适应受控制的财务环境，还能对业务流程中的快速变化做出响应，IT 部门需要增强其功能和成熟度，以使自己与业务需求保持一致。IT 部门必须摒弃以前创建以 IT 为中心的解决方案的方式，转而创建实现一个或多个业务流程的解决方案。业务驱动的开发 (BDD) 是一种用于开发直接满足业务需求的 IT 解决方案的方法。

本文将努力让读者了解 BDD 的重要原则，并就其制度化给出了一个建议机制以实现可重复性的成功。

回页首

BDD 需求

当今的企业需要跟上竞争激烈的市场对新业务功能的需求的步伐。企业的 IT 预算中的约 80% 都花费在维护和增强现有应用程序上。创建这些现有的应用程序并没有充分考虑灵活性方面的问题，因此，虽然业务转而使用新的和增强的流程，IT 骨干却没有能力进行必须的更改。传统应用程序和体系结构无法跟上业务创新的步伐，而这主要是因为流程无法随需应变地适应业务需求。业务要求通常转换为孤立的 IT 项目，这些项目无法进行协作；为不同 IT 项目创建的构件之间的可重用性通常非常低。创建能够响应未知情况的足够灵活的应用程序则需要更为系统的应用程序开发方法。对于无法创建可对未知情况做出响应的 IT 功能的公司，通常非常难于确定创建灵活 IT 应用程序的更为深入的预算需求。由于传统应用程序体系结构的不灵活性，即使很小的改进也需要花费很大的成本，因而几乎不可能进行调整。

需要设计一种机制，利用该机制，可以通过已标准化的执行框架将 IT 工作与业务策略和要求彼此结合，同时这个执行框架已得到广泛的认可，能够重复而成功地加以执行。企业可以对业务流程（在其中全面地定义了业务执行方法）进行建模，从而实现业务灵活性。首先，需要通过主要流程步骤对业务流程进行建模。通过根据投资回报 (ROI)、主要性能指标 (KPI) 或其他度量标准来对业务流程或主要用例进行评估，企业可以将这些业务流程模型 (BPM) 作为与 IT 领域就业务需求进行沟通的主要机制使用。业务部门和 IT 部门通过使用良好连接的 BPM 来在业务需求和 IT 实现和提供的产品之间建立联系，从而可以极大地消除沟通鸿沟。

虽然 BDD 的第一步是创建 BPM，但 IT 解决方案结构也需要进行调整，以将 BPM 作为软件开发生命周期的设计和开发阶段的输入构件来使用。IT 体系结构需要能够将流程活动作为软件组件或服务进行设计和实现。

通过使用 BDD，企业可为 IT 部门建模和提供新业务流程（进行了概念化后）。对新流程的分析可能会发现可能已经存在满足该需求的软件服务，只需要将现有软件服务连接起来即可实现新业务流程，或者可能会发现企业需要实现新软件服务，并将其添加到 IT 服务组合中。类似地，如果需要对现有流程进行更改，将对 BPM 进行修改来反映此更改并提供给 IT 部门，以根据需要增强或修改的服务来进行后续技术修改。

BDD 方法可以帮助提高业务的灵活性，还可以帮助安排 IT 活动的优先顺序，并使之与业务需求保持一致。它还可以间接地帮助简化企业内 IT 预算的成本确定流程。

回页首

执行模型

正如前一部分中所提到的，企业 IT 部门应该努力缩小业务需求和 IT 解决方案之间的距离，而且在创建 IT 解决方案方面也应保持足够的灵活性和响应能力。正是由于这个需求，才开发了面向服务的体系结构 (SOA)，此体系结构提供了一个 IT 框架和一系列原则和指南，用于将 IT 解决方案作为一组可重用、可组合且可配置的服务 进行创建，而这些服务对应用程序和运行时平台没有依赖性。企业为了过渡到 SOA，需要采用 BDD 方法来使用业务目标和需求驱动下游的设计、开发和测试。这样就能通过重用现有的或新创建的服务来创建组合业务应用程序，从而可以帮助创建适应性强的灵活业务解决方案。它还给企业 IT 部门带来了很多急需的灵活性，并有助于使 IT 解决方案与业务需求保持一致。

这一部分提供了在采用 BDD 方法的典型项目中将涉及的各个步骤的粗略概述。下一部分将对这些步骤进行更为详细的讨论。图 1 显示了定义 BDD 的主要步骤的活动流。

图 1. 执行模型



建模业务流程的第一步需要 IT 支持。最好首先对关键业务流程进行建模，然后使用建模活动的输出来将业务需求告知 IT 部门。业务用户和参与者要负责将流程及其主要步骤与 ROI、KPI 和其他任何相关指标进行关联。在 IT 生命周期的后期，这将帮助验证 IT 是否提供了业务所要求的内容。

对流程进行了建模之后，可以将模型的输出作为活动的需求收集阶段的输入使用。组成给定业务流程模型的活动或流程步骤可以作为用例建模的基础进行分析。确定用例是项目的需求收集阶段的重要一步。将以用例为基础来设计应用程序体系结构，并且还将以用例为基础对企业服务进行标识、设计、开发，并最终将这些服务连接起来，形成实现业务流程的服务组合。开发完成之后，项目就进入部署阶段，在此期间会将已开发的组件作为可发布的、位置透明且可发现的服务进行公开。这些软件服务将被部署到执行运行时（如应用服务器）。

在部署完成后，项目就进入监视或管理阶段。业务流程启动并开始运行后，可以对其进行监视，以了解实时性能和进行数据捕获、报告及分析。为了进行此操作，需要给业务流程中的步骤（在第一个步骤中已建模）分配各种业务指标（如 ROI 和 KPI），可以根据这些指标对运行时性能、延迟和其他要素进行测定。测定结果非常重要，可用于验证 IT 解决方案是否满足了服务水平协议 (ervice level agreement , SLA) 定义的业务需求。

将以期望的 SLA 或其他基准性能指标和标准为基础对通过运行时监控获得的数据进行分析。捕获的信息将提供给架构师、设计人员及开发人员，以对数据进行分析，并找出通过对实现代码进行增强和性能调整来优化和提高流程的创新方式。有时候，业务用户可能会通过使用外部接口更改业务规则来实现更改，此时就不需要进行代码更改。如果分析结论建议在业务流程中进行更改，则可以修改对应的业务模型，并重复相同的步骤（即，开发-部署-监控）来对实现进行增强。这样就完成了将分析和流程调整技术反馈到建模步骤的执行循环。此机制可帮助业务部门和 IT 部门适应不断迅速变化的业务需求。它可直接将业务需求和给定 IT 活动的调整相关联，从而帮助确定对现有系统功能的成本的增加。

回页首

执行采用 BDD 的 IT 项目

到目前为止，您已经了解了组成 BDD 的各个主要步骤。如何将执行模型转换为可在典型的软件开发生命周期中重复执行的有组织有计划的工作活动呢？这一部分将尝试详细说明实际项目执行所需的各个步骤。重要说明：请记住，我在此处说明的是 BDD 的方法。该方法中的每个阶段的完整细节取决于具体的项目和技术，因此不在本文的讨论范围内。

回页首

业务需求分析

任何 IT 项目活动中的第一步（也是最重要的一步）都是了解业务需求。高级业务需求取决于主要业务参与者和现有遗留系统。除非将其形成文档，并最终签署确定，否则刚一开始项目本身就可能有很多未知的地方。占用业务高级管理人员的时间通常非常不容易，但有必要这样做，而且需要进行良好的计划和执行。（至少）需要记录下列需求：

业务远景

实现企业远景的业务目标（长期目标和短期目标）

帮助达成目标的高级业务需求

现有业务流程的问题（如客户难点、高成本、计划问题等等）

了解业务环境和企业组织结构也非常重要。此外，还需要对业务域模型进行分析和充分了解。这种了解可以形成业务域矩阵。了解期望给定业务域提供的高级业务功能也非常重要。获得包含相关高级业务功能的业务域矩阵是结束业务分析活动的好方法。

回页首

业务处理建模

BPM 是一种通过一系列活动、用例和决策点对业务流程进行可视建模的技术。BPM 的目的是创建完全可执行的模型，工程组可以将这些模型作为技术服务加以实现。BPM 涉及到对原有 和将来 的业务流程进行建模以及分配资源实现每个流程的多个活动。流程优化是通过可以帮助获得理想 业务流程状态的模拟过程进行的。“将来”状态将作为达到理想流程状态的的第一个可行步骤（从预算和时间计划角度而言）被确定下来。

每个组织或业务域都具有希望支持或提供的业务功能。术语业务功能 和业务用例 的使用可以互换。BPM 技术用于对行为、组织结构和业务域对象等各个方面进行建模。将每项任务分配给一个角色。角色是一个实体（人、计算机或任何其他类型的参与者）或一组实体，其具有执行某项或某组任务的相同权利和义务。可以给角色分配任意数量的任务，而一个实体可以担当任意数量的角色。

进行分析时，每个业务流程都可以表示为活动或任务的一个序列。任务是对用户有意义的最小工作单位。有时候，流程的一部分已足够复杂，可以将其表示为一种用例。图 2 显示了 BPM 的一个示例。

图 2. 示例流程模型



流程的组成部分（活动或用例）可以在组织域中进行分配。有时候可以将功能域或业务域分配给流程活动。这样就可以了解哪个业务/功能域负责业务流程中的哪些步骤。这个视图可以帮助了解随后的体系体系结构和设计活动。

需要给活动步骤指定输入和输出。应该使用业务项（即业务域实体，如员工、客户等）对输入和输出进行标识。

需要根据性能标准对业务流程进行测定。可以为流程本身及组成流程的活动分配参数，这些参数可用于测定运行时性能。可以对这些参数进行添加，而且可以运行模拟来收集有关流程需要如何执行的数据。模拟的结果还可以帮助对流程模型进行调整，以使得模拟运行执行的结果与期望的性能测定结果更为接近。

企业从此工作中可得到什么好处？

当流程模型正式形成并经过了验证后，可以将其作为项目的下一阶段（如用例建模）的主要输入使用。数据体系结构团队可以通过合并而得到包含所有业务域实体的单一视图。在业务专家的帮助下标识了各个业务实体之间的关系后，可以迅速地将此业务域视图发展为概念数据模型，系统将以此模型为基础进行构建。

回页首

用例建模

用例模型是包含各个用例及其相互依赖关系的视图，其中还包含用例参与者列表。业务流程角色映射到用例参与者。用例可以指定一个完整的系统，也可以指定任何描述行为的模型元素，例如子系统。某些建模甚至会将用例作为业务流程进行映射。因此，当从流程模型标识用例时，无疑有很大的灵活性。

那么如何从业务流程标识用例呢？

没有用于从流程模型标识用例的硬性规则，因此这个步骤并没有正式的标准。我将尝试提供一个合理的机制来将 BPM 作为输入以定义用例。

如果将流程中的单个活动或任务映射为一个用例，则每个用例将仅对单个交互进行建模，因为任务被认为与单个交互等效。但是，用例的统一建模语言（Unified Modeling Language，UML）定义将其描述为一个完整的序列。这意味着用例指定了为将系统置于同一用例可以再次执行的状态而必须执行的所有交互。因此，将用例限制为单个交互将会显得约束过多。

当将整个流程映射到一个用例时，生成的用例可能会过于复杂。不仅其中会存在多个角色，而且可选路径的数量也会非常多。因此，此方法并不实用。

一种替代方法就是定义步骤 的概念。步骤是任务的序列，可以由同一角色不间断地执行。例如，保存预订 可以是一个用例，而保存预订并发送空房通知 则可能不是用例，因为在保存预订和空房通知创建、个性化并发送到客户之间有一定的时间间隔。因此，业务流程的不同视图就是步骤的序列，其中每个步骤都是具有希望的输出和行为的用例。

标识了用例后，用例中的活动集可以作为用例中的主要步骤进行记录。这样就允许将用例作为步骤序列进行记录。业务流程中的流程步骤之间的过渡被映射为用例之间的依赖关系。标识用例并将其记录到用例模型中（包含参与者关联情况）是这个总体活动的第一个迭代。

此时通过执行某种级别的分析，可以创建并记录正式的用例模型。

那么，使用此方法有什么优势呢？

由于用例可以作为业务流程中的步骤进行标识，因此每个用例都有其存在的意义。每个用例至少实现（部分或全部）一个业务流程。没有未标识的用例，而且在此工作结束时，业务流程组合中的每个步骤都有指定的用例名称和执行的主要步骤。另外，也没有孤立的用例，也就是说，每个用例都至少可以直接追溯到一个业务流程。

此工作成功完成后，IT 项目成功的几率通常会得到提高。

回页首

服务建模——SOA

向 SOA 过渡的企业需要仔细考虑如何创建企业服务组合。服务组合是企业提供的各种服务（供外部使用或内部使用）的列表。任何属于企业 SOA 范围内的 IT 活动都需要创建一个服务列表。就实现 SOA 的目标而言，各个企业处于各种成熟度级别。很多公司都在逐渐过渡到 Web 服务实现项目。为了成为真正的基于 SOA 的企业，需要达到更高的成熟度级别，而不仅仅是 Web 服务实现而已。企业的 SOA 成熟度级别的分析本身就可以算作正式的流程。

从上面不难看出，如果企业要发展成可公开业务服务的真正基于 SOA 的企业，需要了解、采用并遵循一个方法。尽管此主题不在本文的讨论范围内，但我仍然会努力将前面工作（即业务分析、BPM 和用例）的输出与 SOA 工作联系起来。我还将尝试演示为了完成一个 SOA 活动而需要进行的一系列活动（从相对较高级别进行说明）。

利用来自前面工作活动的输入

业务分析工作有助于清楚地了解公司的业务远景和目标。需要通过 IT 进行自动化的业务流程必须根据某个优先级标准进行分类。IT 部门可以和业务部门紧密合作来对业务面临的主要问题进行评估，例如以下问题：

主要流程缺陷和瓶颈

客户难点

需要随着事务量增加等因素进行扩展的流程

以此类评估为基础，可以制订一个计划来标识要首先实现的流程。流程归业务域所有。因此，一些初始业务域可能会被标识为需要 IT 部门重点考虑，以实现直接的短期优势。任何可能标识的服务都需要其试图解决（全部或部分）的业务目标给予足够的支持。这将有助于制订用于确定需要 IT 支持的业务域的优先级策略。在很多情况下，高优先级的域将是需要为其标识和定义业务服务的域。现有业务流程的问题也可以作为服务支持的主要目标。在任何情况下，IT 工作的优先情况都需要与业务需求（特别是上市时间考虑）相一致。

如前所述，BPM 将同时对“原有”和“将来”的业务流程进行建模。流程模型对实现端到端业务流程的任务序列（既包括本身就是原子任务的任务，又包括由用例表示的任务）进行标识。“将来”的流程模型构成了自顶向下的流程分解技术的基础。在此技术中，每个业务流程以及被标识的用例都是服务的候选对象。此外，每个通过用例建模工作标识的用例都可能被添加到候选服务列表中。（注意：务必了解，这些只是服务的“候选对象”，并不一定会成为最终的服务组合中的一员。）

SOA 的本质在于能提供一个服务组合，可以重用这些服务来实现多个较高级别的业务流程。服务的实现也需要仔细考虑，以便实现构件（如组件）也具有跨多个服务实现的重用性。

图 3. SOA 层



图 3 给出了 SOA 各 层的高级视图。该图演示了业务流程中的各个步骤可以如何通过单个服务或多个服务的组合进行实现。图中还演示了可以如何使用组件实现服务。这些组件可以是从现有资产（如遗留系统）中获得的资产、打包的应用程序或商品化的现成应用程序中的组件，以及完全自行开发的组件。

从候选服务组合开始是实现构件企业服务组合目标的重要一步。为了实现企业的服务模型，需要进行许多其他步骤的工作。在增强可重用性方面扮演着重要角色的一个分析就是对遗留和现有系统的分析，可以通过此分析找出可能进入候选服务列表的服务。需要在这里要指出的主要一点就是，服务建模活动可以将前面步骤的工作构件作为输入和出发点来使用。

为了在服务模型上进行概括和构建工作，可能需要执行的主要活动有：

自顶向下分析（通过流程建模）

遗留系统和应用程序分析

使用公开服务的标准从候选服务列表中创建初始服务模型

清楚地描述服务说明、功能和服务质量 (QoS)——选择并公开了服务后

将每个服务映射到业务目标，并确保每个服务至少参与一个业务流程

SOA 系统可以分解为多个层，然后在每个层对其工作活动进行标识、了解和执行，以帮助实现成为真正的面向服务的企业的优势。图 4 对各个 SOA 步骤进行了标识，并演示了每个步骤如何进行组合，以创建 SOA 的各个层的构件。

图 4. SOA 步骤



下表按照各个步骤在上图中的出现顺序提供了对每个步骤的简要说明：

业务组件化分析 (Business componentization analysis)。这是在项目执行的业务分析阶段主要完成的工作。将在此级别创建和分析业务域映射。

服务标识 (Service identification)。在此步骤执行自顶向下和自底向上（现有系统）分析和根据基于业务目标的标准矩阵对服务进行评估，从而对候选服务进行标识。

服务规范 (Service specification)。此工作定义依赖关系、组合、公开决策、消息、QoS 约束以及与服务内的状态管理相关的决策。它对模型中的服务之间的关系和协议依赖关系进行了描述。

组件标识 (Component identification)。此步骤中对将用于实现服务模型中的服务的企业组件进行标识。企业组件的例子有 EJB、组件外观等等。

组件规范 (Component specification)。此步骤描述组件的详细特性、内部流和结构。

要得到最终的服务模型和组合，还需要涉及许多其他步骤。这一部分仅演示了如何通过利用前面步骤的工作成果来初步完成此工作。

回页首

系统设计和开发

在开发阶段，团队将获得初始用例和服务模型并进行深入的工作：通过对组成用例的主要步骤进行细化来构建每个用例的功能规范。

系统设计

将功能规范作为输入，以创建系统的组件模型。组件模型通过说明组件提供的接口以及组件如何在整个系统解决方案中彼此依赖对组件进行描述。组件是支持公开的服务（在服务模型中）的实现机制。仍然有可能存在不直接实现服务的组件；相反，它们用于帮助实现一些公共实用服务（如，登录、事件提交和广播等等）。不公开直接由外部使用的接口的组件被用于帮助进行标准化的组件间通信。从体系结构设计方面而言，大量的用例经常用于通过组件接口创建序列关系图。这证明系统设计良好，可以通过由组件模型中各个组件公开的接口协同工作。

在此阶段的活动之一是标识和记录非功能系统需求。这些需求不仅用于为服务模型中的服务创建 SLA（前一步骤），也用于作为操作系统模型的输入。此外，操作模型描述各种基础设施组件（如中间件、消息传递、目录服务等等）。该模型还说明如何将组件在整个网络中进行分布以及如何将其部署到硬件基础设施设备上。

在对前面步骤中建模的流程进行实现之前，应用程序架构师和设计人员需要定义服务实现、服务描述和服务调用机制。并非所有的流程步骤都可以通过直接调用服务实现。这其中的一个原因可归结为步骤的严格性能要求（在 SLA 中定义）；服务调用的开销可能会太大。此种类型的步骤可以通过直接调用不具有服务 Facade 的组件来实现。其他一些因素可能会导致需要采用混合方法来实现单个流程步骤。需要对这些因素进行标识和捕获，以供后续开发参考。

本文并不会详细讨论系统设计，只会对步骤序列进行较为抽象的说明。

完成了宏观设计（组件和操作模型以及其他设计构件）后，项目执行的重点就转向微观设计。请记住，需要对项目活动进行迭代；传统的瀑布式系统开发方法的风险经常要高得多，特别对于大型的复杂项目更是如此。在微观设计中，将为组件模型中的每个组件设计和建模类关系图以及序列关系图。在此期间，通过恰当使用经过验证的设计模式可以帮助保证设计更可靠、更灵活且扩展性更好。

系统开发

正是在项目的这个部分实际实现设计，在此过程中要选择编程模型（如服务组件体系结构——Service Component Architecture (SCA) 或 Java™ 2 Platform Enterprise Edition (J2EE)）、兼容编程语言（如 Java）和帮助进行复杂开发的集成开发环境 (IDE)。将流程模型构件导出为业务流程执行语言（Business Process Execution Language，BPEL），然后在开发 IDE 中将作为起点，用所选择的编程语言来实现流程活动。还要使用所选择的技术来实现服务定义。已开发的服务将通过流程编排引擎连接到一起，该引擎可以帮助提供通过服务接口连接业务流程的机制。

应该了解单个服务可以在实现多个业务流程的过程中进行重用，这一点非常重要。每个服务都可能用于实现多个流程，具体取决于它与其他服务软件建立的联系。事实上，BDD 带来的业务效益是直接通过多个业务流程之间的服务可重用性实现的。因此，业务部门和 IT 部门都将通过服务组合、重新组合和重用技术来利用 IT 服务，从而以灵活的方式适应不断变化的业务需求，最终获得适应新的和不断变化的需求的灵活性。

基础设施设置需要和开发活动同时进行。基础设施团队将利用操作建模工作的输出来设置网络节点、硬件、软件（经过授权）和其他必要的步骤，从而为部署做好准备。

回页首

部署

开发活动处于稳定状态后（构建-测试连续体中的每个迭代均已完成），就要对实现进行部署了。对项目时间计划进行同步，以便让基础设施能够准备好，从而能在生产环境（即其最终用户看到的环境）中部署应用程序。另外，请确保仔细对软件构件的分布式部署进行计划。例如，体系结构层中将大量使用的部分必须包含容错功能，能够承担高负荷工作，且具有较大的容量，所有这些对于在集群环境中进行部署都是必要的。

回页首

运行时监控和分析

业务流程的运行时引擎可以用于分析正在运行的流程。除非在运行时对业务流程进行监控，否则就没有科学的方法对是否通过 IT 解决方案实现了业务 ROI 进行验证。此监视可提供实时数据和分析。可以收集运行时数据，因为建模操作可以将业务及性能指标与业务流程、用例或流程内的活动关联起来。

回页首

对监控得到的数据进行分析并据此进行调整

在 BPM 期间，请使用模拟技术来确定业务流程可以如何满足所需的 SLA。通过监控活动收集到的运行时数据需要根据模拟结果进行测定。如果结果非常相近，且具有合理水平的容错性，则实现和整个项目就可能成功。不过，如果模拟结果与运行时性能不匹配，则需要进行一些相关工作。需要对运行时数据进行分析，以确定哪些特定流程步骤对满足 SLA 方面造成的影响最大。

第一步要对实现代码进行仔细的分析，并确定可以对哪些方面进行调整以实现更佳的性能。如果完成了此工作，而更改后仍然无法达到要求的 SLA，则需要对业务流程进行仔细检查并进行一定更改。需要对更改的业务影响进行分析，如果更改被认为对业务非常重要，则需要对流程步骤进行更改，以缩小存在的差距。可能也需要对基础设施体系结构进行分析，以确保该级别的更改是否能满足 SLA 要求。有可能通过添加冗余基础设施组件来弥补性能缺陷，但这就有可能存在预算超支的风险，应该作为最不得已的方法考虑。

务必注意，BDD 提供了一个用于调整和改进业务流程的机制。因此，如果流程得到了恰当的遵循，实现业务流程的相应 IT 解决方案将会无缝地进行更改。

回页首

执行所需的角色

正如我在前面简单提到的，BDD 项目需要各种人员的支持，这些人员各自具有其唯一的一套技能。这一部分将对成功执行由业务目标、远景和需求驱动的 IT 项目所必需的各个角色进行介绍。图 5 显示了执行业务驱动的 IT 活动的各个阶段所必需的一些重要角色。

图 5. 各个项目阶段所必需的角色



以下是对每个主要角色的说明：

业务分析人员 (Business analyst)。负责业务分析和 BPM 工作活动的高级角色。业务分析人员进行用例标识，并为每个用例创建功能规范。此高级角色意味着在项目进行期间，该分析人员还可能承担更多的专门任务。

架构师 (Architect)。负责创建体系结构和系统设计的总体工作的高级角色。更专业的角色，如企业架构师、应用程序架构师、SOA 架构师、首席设计师（针对微观设计级别的任务，如类建模、序列关系图等等）和基础设施架构师等，实际上负责项目设计阶段包含的各项体系结构工作。

开发人员 (Developer)。负责实现解决方案的高级角色。同样，可能由此角色中更专业的参与者来完成实际工作，这些参与者包括数据库编程人员、Java 开发人员、Web 开发人员和业务流程编排人员等等。

测试人员 (Tester)。负责在将应用程序部署到生产环境中之前执行测试应用程序所需活动的角色。测试人员直接根据说明用例的功能需求创建测试脚本。随后将使用各种输入条件来执行这些测试脚本，以验证获得了希望的输出结果。测试用例及其执行越全面，应用程序就越可靠，从而可以尽可能地减小运行时出现意外的情况。

部署管理人员 (Deployment manager)。负责在各种环境（例如、测试环境、临时环境和生产环境）中的基础设施上部署应用程序代码，以及完成适用于所有环境的无缝部署所需的全部工作（如开发部署安装脚本、配置管理等等）。

IT 操作管理人员 (IT operations manager)。负责支持应用程序启动和运行时（特别是在生产环境中）的现场支持的主要活动。此角色还可能负责从应用程序收集运行时数据，并根据 SLA 要求对结果进行分析。

这并不是暗示此处提到的角色是项目中所需的全部角色。可能存在任何典型的项目中将涉及的主要角色，但请根据客户端的组织结构和项目的要求和复杂性来对列表进行自定义。

回页首

工具支持

技术、IT 方法和流程的成熟度取决于支持它们的工具。一个重要的例子就是 J2EE 技术和相关的编程模型。正是通过成熟工具的发展（其中很多工具都是 IBM 和其他重要的平台与工具供应商提供的），J2EE 设计与开发流程才得到了极大的简化。如果在给定的项目生命周期中缺乏各项工作的工具支持，流程和方法就更多只是停留在纸上谈兵的阶段。

IBM 提供了全面的工具支持，用于实现其提供支持 BDD 的所有方面的端到端工具的远景。以下就对其中的很多工具以及其如何使用 BDD 各个阶段进行了说明：

Rational® Software Modeler 和 WebSphere® Business Integration Modeler and Monitor。这些工具可用于帮助进行 BPM 开发。它们使用称为 Business Process Modeling Notation (BPMN) 的概念进行流程建模。业务分析人员使用这些工具来将业务流程形式化为可重用的构件。分析人员将解决方案标识为最优的“将来”BPM 后，他/她需要定义业务需求，并将其细化为软件需求（用例）。IBM Rational RequisitePro 可以作为正式记录和维护这些用例的工具。编写良好的用例可为体系结构、分析和设计活动提供坚实的基础。IBM Rational RequisitePro 中的需求可以与其他工具中的流程模型建立关系，从而提供全面的可跟踪性，并确保下游体系结构、设计及开发活动均是通过业务需求驱动的（以流程模型的形式）。

Rational Software Architect。系统架构师可以使用此工具来确定系统体系结构和进行设计。Rational Software Architect 和 WebSphere Business Integration Modeler and Monitor 的输出可作为 UML 模型导入 Rational Software Architect，从而形成系统体系结构和设计的基础。从分析人员在 Business Process Modeler Notation 或 BPEL 的工作转换到架构师在 UML 的输入的过程是无缝的，这些工具可以协同工作，从而节省时间和减少麻烦。

Rational Application Developer 和 Rational Web Developer。J2EE 和 Java 开发人员使用这些工具将 Rational Software Architect 设计模型转换为实现代码。此开发环境可以实现很多在 Web 服务构造和使用过程中执行的任务的自动化，从而帮助进行面向服务的构件的开发。此开发环境可为开发人员提供帮助，可为各种技术组件提供拖放 Widget，如 Java Server Pages (JSPs)、Servlet、Enterprise JavaBean (EJB) 等等，从而可帮助减少开发时间。打包编程模型是现在大部分供应商工具的标准功能。

IBM WebSphere Integration Developer。集成开发人员使用此工具来装配组合应用程序，此类组合应用程序部署在 IBM WebSphere Process Server 之类的运行时服务器环境中。WebSphere Integration Developer 可将服务连接成组合应用程序，以供进行测试并随后部署到运行时环境中，从而帮助进行服务编排。

Rational Functional and Manual Tester 和 Rational Performance Tester。应用程序和系统测试人员将使用这些产品。将这些工具与 Rational RequisitePro 集成，可以直接从用例和功能规范创建自动测试脚本。这样就可以实现测试用例和用例之间的可跟踪性，并帮助确保在整个项目生命周期实现更高层次的成功。该工具还支持测试运行的数据收集，并根据此数据创建报告——此数据向开发团队提供反馈。

IBM Tivoli® Monitoring。从工具对系统的执行运行时进行监视。它收集运行时数据和分析数据，可以随后将这些数据用于分析和调整已建模的“将来”业务流程，从而满足 SLA 要求。IBM Tivoli Configuration Manager 对软件应用程序和部署环境进行配置。

IBM Rational Portfolio Manager。高层管理人员和项目管理人员主要使用此工具来了解与 SOA 服务组合相关的业务优势、成本和风险。他们还可以使用此工具来确定所建议的服务的创建优先级，跟踪服务开发的状态，预测将来服务的需求，并帮助管理 SOA 项目团队依赖关系。该工具还提供了供 SOA 开发生命周期使用的成熟功能，如服务的创建、操作、维护、增强和撤消。

结束语

BDD 的相关概念已经出现很久了。但直到最近，该方法才开始引起重视，并得到了广泛的认可。此方法得以实现的主要原因在于，构成此方法的所有活动都有了相关标准。BPEL 中有各个企业都可以用来定义业务需求的共同语言。UML 提供了通用 IT 语言来描述体系结构和设计构件，许多开发工具集都是以标准框架为基础构建的。（对于 IBM 和许多其他供应商，此框架是 Eclipse。）

通过严格按照此方法进行操作，可以帮助实现 BDD 在以下方面的价值主张：降低开发成本、缩短上市时间，以及提高质量和客户满意度。为了处理成本削减问题，不仅要通过服务的可重用性和可组合性来实现多个业务流程，而且也涉及到通过遗留现代化技术进行相关处理。它通过重用来解决缩短上市时间的问题，同时也通过清楚记录的业务需求和 BPM 来改进业务部门和 IT 之间的沟通机制。通过处理现有业务流程中的客户难点，可以大幅度提高客户满意度。各个企业可以通过了解创建业务驱动的解决方案的策略影响 为基础来创建 IT 解决方案，从而实现此目标，这正是 BDD 的基本原则。

本文帮助您从实践的角度了解 BDD 的主要原则，并说明了如何通过使最终 IT 解决方案与业务需求保持一致的各种工作活动来执行 IT 项目。文中还说明了在各个项目阶段中主要项目参与者的高级角色。此外，还列出了 IBM 为了支持 BDD 而提供的端到端工具集，从而进一步证明了 BDD 在行业中的应用。

各个企业可以通过本文了解可帮助他们实现基于资产且以业务为中心的 IT 解决方案的方法所固有的优势。BDD 正在迅速地获得各方面的重视，我们希望通过本文能够让您对 BDD 有足够的了解。

参考资料

学习

您可以参阅本文在 developerWorks 全球站点上的 英文原文。

这个经过整合的站点可以为您提供有关 Rational Application Developer 的大量文章、参考资料和案例研究。

有关 IBM Rational RequisitePro 的使用的一篇不错的入门文章。

了解有关以下方面的更多内容：

Rational Software Architect

WebSphere Process Server：IBM 为 SOA 提供的新基础

IBM Rational Portfolio Manager

使用服务组件体系结构构建 SOA 解决方案——第 1 部分: SCA 编程模型

请访问 SOA and Web services 专区，以获得数百篇关于如何开发 Web 服务应用程序的文章以及入门级、中级和高级教程，您将大开眼界。

Architecture: Build for the future——访问 developerWorks 的体系结构专区，以获取提高您的体系结构方面的技能的各种资源。