行至水窮處，坐看雲起時

您可以参阅本文在 developerWorks 全球站点上的英文原文。
您可以参阅 Rational Edge 电子月刊中文版的其他文章。

安装用于 USBD （基于统一场景的设计）的 UML 2.0 规范


		Philippe Dugerdil 是瑞士日内瓦应用科学大学 HEG（Haute école de gestion）的软件工程教授。在这之前，他在软件行业工作了十五年，主要致力于银行业软件部分。他拥有计算机科学的博士学位，以及工商管理硕士学位。您可以通过 philippe.dugerdil@hesge.ch 联系他。

基于统一场景的设计: 从概念到实践

2008-11-14T21:15:00.000-08:00

基于统一场景的设计（USBD）的 UML 扩展和工具

级别：中级

Alex Donatelli, 高级技术人员, IBM Tivoli Software
Rosario Gangemi, IBM Tivoli Configuration Manager Architect, IBM Tivoli Software
Claudio Marinelli, IBM Tivoli Configuration Manager Designer, IBM Tivoli Software
Roberto Longobardi, 交互解决方案设计人员, IBM Tivoli Software

2008 年 8 月 07 日

这篇文章是本系列文章的完结篇，它描述了用于方法学的 UML 扩展和支持工具。本文将关注点放在支持 USBD （基于统一场景的设计）的工具上面，也就是将用于 IBM® Rational® Software Architect 版本 7 以及后续版本的 IBM® WebSphere® Business Modeler 集成特性，以及一组 UML 2.0 的扩展放置到一组 UML 规范之中。这其中包括一个 UML 2.0 规范以及一个帮助创建 Business Model、Business Analysis Model、Use Case Model 和 User eXperience Model 的模型模板。

入门简介

在本系列前面的几篇文章中，我们已经描述了一个基于基于场景的设计（Scenario Based Design，SBD）和 Outside-In Design （OID）的一个有效的统一设计方法论。该方法论被称作 基于统一场景的设计 （USBD）。它的关注点在于产品所处的点对点的业务环境，而不是仅仅描述围绕在单一产品周围的业务场景。通过描述业务需要和软件执行之间的链接方式，这些文章大致描绘出了通过处理过程路线图、目标和类图表捕获业务处理过程的方式，以及如何根据实际执行来跟踪他们。本系列文章还描述了一种用户接口同系统分析相链接的正式的表示法。

本文将关注点放在支持 USBD （基于统一场景的设计）的工具上面，也就是：

用于 IBM® Rational® Software Architect 版本 7 及其后续版本的 IBM® WebSphere® Business Modeler 综合特性。
被捕获到一组 UML 规范中的一组 UML 2.0 扩展。

WebSphere Business Modeler 综合特性是同 Rational Software Architect 相伴而来的，并且被用作讲一个在 WebSphere Business Modeler 中被开发的的业务模型导入到 Rational Software Architect 之中。这一特性还包括一个被称作 IBM® WebSphere® Business Integration Modeler Nav Tree Profile 的 UML 规范，它提供了能够自动被应用于在导入期间被转换的 UML 类、接口和其他元素的 UML 模板。

Rational Software Architect 包括另一个被称作 Business Modeling Profile 的 UML 规范，它提供了进一步加强业务模型的其余一组 UML 模板。

为了通过特定于 USBD （基于统一场景的设计）方法论的概念来补足这两个规范，IBM 开发了另外一个规范，即用于 USBD 的 UML 2.0 规范。它定义了另外一组模板，当它们被应用到类时，接口以及其他的模型元素都根据 USBD 概念来表现它们。该规范将和 IBM® Rational® Software Delivery Platform （例如：IBM® Rational Software Modeler 或者 Rational Software Architect）一起被使用。

下一小节将讨论 USBD （基于统一场景的设计）的概念，在后面的小节中，我们将描述如何通过前面所提到的三种规范来刻画这些概念。

回页首

USBD （基于统一场景的设计）元模型

本小节将通过一个元模型帮助您更好地理解 USBD 方法论。这个模型描述了您使用 USBD 方法论在软件设计（包含业务、用户和系统）及其相互关系中将会捕获到的概念。该模型包括 USBD 的分类法和存在论。

用户、目标、处理过程、用户接口面板等概念都被放到一起，它们之间的关系通过一个模型来确定和描述。该元模型描述了实际的模型将如何使用 USBD 方法论。下一小节描述了被用来支持这些概念建模以及 USBD 模型结构的实际的 UML 扩展。

图 1 和图 2 分别显示了完整的元模型图表的左右两个部分。

图 1：对业务处理过程进行建模。

图 2: 根据业务上下文环境获得系统的需求和行为。

关于这些图表，正如在本系列的前几篇文章中我们所看到的：

一个 Business Process Map （业务处理过程路线图）包括一组 Business Processes （业务处理过程）。
Business Processes （业务处理过程）同 Business Actors （业务活动者）所开启的 Business Use Cases （业务用例）是一一对应的。
Business Event （业务事件）是一种特殊的 Business Actor （业务活动者），它也能够开启 Business Use Cases （业务用例）。
一个特定的 Business Process Realization （业务处理过程实现）就是 Business Roles （业务角色）执行一组 Business Process Activities （业务处理过程活动）。

在一个更低的层次上，重复着同样的逻辑结构（或者结构模式）：

业务处理过程活动同业务角色所开启的业务处理用例是一一对应的。
业务处理用例的存在支持业务目标。
业务目标是由您的客户来制定的，并且可以通过测量来被评价。
一个特定的业务处理活动实现就是业务工作者执行一组业务处理任务（生产、消费、交换业务实体等）。
业务实体同样在一个更高层次上作为实体在业务处理实现之间被交换。
由业务工作者所完成的任何一个这样的实现都是一种真实描述一个业务场景的交互作用。

在业务层和系统层之间，有两条链接。

业务工作者在一个场景中所执行的某些活动，甚至是所有的活动，都能够被自动地执行。USBD 最佳实践建议：每一项在业务处理过程活动实现中被自动执行的操作都确定了一个系统活动者（即调用该操作的一方）以及一个系统（即操作提供者），并且能够被映射到一个相应的用例实现上。
因此，每一个被选中为自动执行的业务工作者操作，都映射到系统层上面一个相应的用例实现。当然，这个用例实现链接到它所实现的用例上面。
与此同时，一个用户（一个特定类型的系统活动者）扮演一个业务角色（或者该场景中的业务工作者），并且使用一个系统来执行相应的操作。

您能够在图 1 和图 2 中看到业务工作者（及其操作）和业务角色，并且他们表现了业务层和系统层之间的链接。

但是当系统活动者是一个真实的用户的时候，还有系统设计的另一个方面开始活动。

进入用户经验的领域，您希望以有目标的角色的形式捕获到用户原型。
除此之外，您还需要设计用户接口，图 2 显示了如何做。
用例情节串联模板提供了另外一种描述用例实现的方式。情节串联模板描述了实现用例的用户接口元素的导航，从而支持相应的用户目标。

回页首

UML 2.0 扩展

表 1 描述了被引入到 UML 2.0 中的支持 USBD （基于统一场景的设计）概念建模的扩展。Business Modeling UML 2.0 规范是由 Rational Software Architect 的版本 7 引入的，与此同时，WebSphere Business Integration Modeler Nav Tree Profile 同 WebSphere Business Modeler 集成在了一起。

下面各小节将向您展示如何向模型中添加所有需要的规范。

表 1：UML 2.0 扩展以及它们到元模型中概念上的映射。

元模型类	UML 元类使用	UML 原型应用	UML 概要文件	用于协作的图
参与者	参与者	-
业务参与者	参与者		业务建模
业务实体	类		业务建模
业务事件	信号		业务建模
业务目标	类		业务建模
业务过程	协作	\| \| \|	WBI Modeler Nav Tree Profile \| USBD	活动图
业务过程活动	调用行为活动		USBD
业务过程活动实现	协作		USBD	时序图
业务过程路线图	协作		USBD	活动图
业务过程实现	协作		USBD	活动图
业务过程任务	消息, 操作	N.A. (针对消息), \| (针对操作)	USBD \| 业务建模
业务过程用例	用例		USBD
业务角色	类, 活动划分	(针对类), N.A. (针对活动划分, 使用 "Represents")	USBD
业务用例	用例		业务建模
业务执行者	接口		业务建模
客户涉众	参与者		USBD
度量	属性		USBD
操作	操作	-
人物	类型	\|	USBD
用例	用例	-
用例实现	协作		标准	活动图
用例情节板	协作		USBD	状态机图\|时序图
用户	参与者		USBD
用户目标	类		USBD
用户接口元素	类, 状态		USBD

回页首

用于基于统一场景设计的 UML 2.0 规范

图 3 显示了用于 USBD （基于统一场景的设计）的 UML 2.0 规范的新模板。表 1中并没有列出所有的模板。这些仅仅是当您将模型中的元素组织到不同包之中时除了由 WebSphere Business Integration Modeler Nav Tree Profile 所提供的模板之外的其他可选的模板。正如示例模型将要说明的那样，用更加具有描述性的包组织一个模型将大大增强它的可用性。

图 3：UML 规范。

为了能够在规范中使用模板，您需要将其安装到 Rational Software Architect 之中。

您应当首先在下载一节中下载档案文件，并且将其解压缩到本地。然后，您就能够使用通常的操作步骤来安装规范，从而将插件程序安装到 Eclipse 开发平台之上了。

具体的操作步骤如下所示：

打开 Help 菜单，并且选择 Software Updates > Find and Install。
下一步，选择 Search for New Features to Install，然后点击 New Local Site。
定位到档案文件被解压缩的目录（即 site.xml 文件所在的目录）。
在下一个对话框中，将其命名为 USBD Profile Site。
点击 Finish。
在下一个对话框中，展开 USBD Profile Site 节点，并且选择 Unified Scenario Based Design feature 1.2.0 特性。
继续完成向导所示的剩余步骤，安装 UML 规范。

在下一小节中，您将看到如何将一个业务处理过程（它在 WebSphere Business Modeler Advanced Edition 中被建模的）导入到 Rational Software Architect 之中，从而得到处理过程的自动部分的需求。

回页首

从“业务”到“代码”

基于统一场景的设计提供了一种从业务处理过程中得到软件需求的方法论，并且确保该软件同时满足业务和用户的目标。假设您的公司拥有一支业务分析和设计团队，他们负责建造通过 WebSphere Business Modeler 建模的业务处理过程的一个资产。

这些也许是您所在的公司所采用的的业务处理过程，或者是您的客户所采用的业务处理过程。在前一种情况中，您可能会希望自动完成处理过程的部分操作，从而提高公司的效率。在后一种情况中，您可能会成为一个面对这样一项业务的软件公司：提出一种自动完成客户的处理过程的部分操作的软件解决方案。

图 4 显示了 WebSphere Business Modeler 中的示例业务处理过程模型的内容。

图 4：WebSphere Business Modeler 中的业务处理过程模型的内容。

特别地，图 5 显示了一个示例 Batch 和 Schedule Development 的业务处理过程。为了更好的描述在 WebSphere Business Modeler 中建模的可能性，并且理解每一项是如何被转化到 UML 的，这个例子显示了如下内容：

用于收集 Scheduling 需求和收集 Batch 需求的简单任务。
一个用于 Batch Development 的目标任务。
用于 Schedule Developmen 和 Program Development 的全局处理过程。

我们还将描述全局知识库 Schedule Definitions、Batch Definitions 和 Program Library 将如何在转换中被处理。

图 5：WebSphere Business Modeler 中的 Batch 和 Schedule Development 业务处理过程。

图 6 展开了 Schedule Development 全局处理过程的细节，这些细节将在下一小节中被选为自动处理。处于简单性的考虑，其中只包括一个活动。

图 6：WebSphere Business Modeler 中的 Schedule Development 业务处理过程的细节。

您可以通过将 WebSphere Business Modeler 模型导入到 Rational Software Architect 之中，将知识传递到您的开发团队，从而提高业务处理过程资产的价值。在 Rational Software Architect 中，您能够通过 USBD 方法论的额外的语义学来补足知识。除此之外，在模型元素之间的路线关系将为您提供一幅关于问题的业务、系统和用户经验方面的全景图。

将一个 WebSphere Business Modeler 处理过程模型导入到 Rational Software Architect 之中

在开始之前，请确保您已将将 WebSphere Business Modeler 综合添加到您的 Rational Software Architect 安装之中。通常，您是在安装 Rational Software Architect 时指定这个选项的。如果您并没有这么做的话，那么您能够在稍后使用 IBM Installation Manager 从 Rational Software Architect 安装媒体中将其添加。

在本小节中，您将看到如何导入一个用于“富裕公司”的示例业务处理过程模型，接着前文中所给出的“工作量安排处理过程”的例子。我们在一个新的工作区中启动一个 Rational Software Architect，并且将其切换到建模视图。我们现在将 WebSphere Business Modeler 模型导入作为一个现已存在的项目：

从 File 菜单中选中 Import。弹出导入对话框，如图 7 中所示。

图 7：导入 WebSphere Business Modeler 项目。
在 General 文件夹中，选择 Existing Projects into Workspace，并且点击 Next。
接下来，指定业务处理过程项目所在的 WebSphere Business Modeler 工作区目录。
在图 8 中所示的对话框中，选择您希望导入的项目，以及其内容是应当被复制到 Rational Software Architect 工作区中，还是被引用到 WebSphere Business Modeler 中。

图 8：选择要导入的 WebSphere Business Modeler 项目。
点击 Finish。业务处理过程模型被转换到 UML，并且被导入到 Rational Software Architect 工作区中。图 9 显示了操作结果。

图 9：在 UML 中被转换的被导入的项目。

同步模型的版本

请注意，您当前所看到的是原始模型的一个不同的表示法。这个“UML 表示”实际上是只读的，也就是说您不能够改变 UML 模型，也不能够通过这些改变来影响原始的 WebSphere Business Modeler 业务模型。

在实践中，您实际操作的是一个内存中的 UML 模型，它在工作区中并没有一个副本文件。第一件要做的事情就是将模型保存到一个文件中，以便您能够将 UML 模型的任何改变保存下来。

当然，这就意味着如果您将 UML 模型保存到另一个文件中的话，您就需要负责使其同原始的 WebSphere Business Modeler 业务模型相一致。在您保存模型的同时，应当关闭原始的 WebSphere Business Modeler 模型（实际上就是 resource.xmi 文件），并且打开新的 .emx 文件继续进行操作。

请注意，在 WebSphere Business Modeler 中所定义的业务模型元素已经被转换到 UML 元素中，并且没有创建任何图表。为了创建图表，需要我们创建一组图表，并且将被转换的元素放至其中。首先，创建一个自由格式的图表，然后将 Business Items 和 Processes 包中的所有条目拖动到该图表之中。图 10 显示了布局改造后的结果。

图 10：由此得到的 UML 项目元素。

请注意，每一个处理过程都被转换为两个条目：一个和一个，第一个条目是一个 UML 用例，而第二个条目是一个 UML 协作。每一个业务条目都被转换为一个，而每一个角色都被转换为一个。

根据 USBD （基于统一场景的设计）概念补足业务知识

至此，您已经将相关的业务处理过程的知识导入到 Rational Software Architect 之中，并且您希望通过那些 WebSphere Business Modeler 不打算捕获的概念来增强这些知识。为了能够在我们的模型中使用 USBD （基于统一场景的设计）模板，您首先需要做的就是将用于 USBD 的 UML 2.0 规范添加到这个模型之中。

在左侧的资源树中，选择 UML 模型，然后在透视图中选择 Profiles 标签。
点击 Add Profile 按钮。弹出如图 11 中所示的对话框，从中您能够选择 USBD 规范。

图 11：将用于 USBD 的 UML 2.0 规范添加到模型之中。

您将首先对业务目标进行建模，尤其是那些对您已经描述过的业务处理过程产生影响的目标。

首先在您的 UML 模型的顶部创建一个包，并且将其命名为 Business Goals （业务目标）。
接下来，通过 USBD 规范中的模板对其进行刻画。
然后，在该包中打开图表，并且创建两个类以反映两个业务目标，并且将它们模板化为。
然后，您就能够为这些目标添加方法，作为相应的类属性，并且将它们模板化为。
至此，您需要对建立这些目标的人进行建模，这是因为这是这些人希望收到关于公司如何实现这些目标的报告。您可以通过向处理过程包中添加一个新的来完成这一操作。同时，也要将模板添加进去。

其结果如图 12 中所示。

图 12：业务目标。

您现在就可以在导入的业务处理过程上进行业务分析，进一步指定处理过程活动。这将允许您决定希望哪些活动被自动执行，从而得出用于相应的软件系统的需求。

您首先希望检查 Batch 和 Schedule 开发业务处理过程。因此，展开包，然后是 Batch 和 Schedule Development —— 即模板化的 UML 协作，然后是其中的 UML 活动。
您需要创建一个图表来查看该活动，右键双击活动结点，然后选择 Add Diagram > Activity Diagram。
这个新图表中自动加载了 UML 活动。打开该图表，如图 13 所示，您将注意到原始的业务处理过程已经被转换为如下内容：

在原始处理过程中被调用的每一个简单任务、全局任务和全局处理过程，都成为新的处理形式中的一个调用操作活动。
每一个这样的调用操作活动都被放置到一个泳道中，用来表现执行原始任务或者全局处理过程的原始活动者。每一个泳道都对应一个相应的业务活动者。
原始任务或者全局处理过程的输入和输出都被正确无误地转移到相应的调用操作活动中。

图 13：被转换的业务处理过程的摘录。

这个例子将关注 Schedule Development 全局处理过程，而图 14 显示了在您以同样的方法添加相应的活动图表之后的情况。出于简单性的考虑，这个子处理过程只包含一个任务，此处被转化到一个被称为“为 Batch 创建一个 Schedule 定义”的 Call Operation Action （调用操作活动）。

图 14：Schedule Development 业务处理过程。

您希望进一步分析这个活动及其子任务。您将通过开发一个（一个在表 1 中被显示的 UML 协作）来完成这一操作。

在进行这一操作之前，您需要分配一个适当的包来包含这些实现，所以我们创建另一个顶层包，并且通过模板来对其进行刻画。
此时，您将在一个 Sequence Diagram （序列图表）中描述“为 Batch 创建一个 Schedule 定义”活动所需要的任务流程，如图 15 中所示。

处理过程中一个活动的实现是由相应的业务活动者发起的，并且由一组业务工作者执行。将各种协作工作者从模型树中拖动到图表中，从而描述实现该处理过程活动的任务序列。

图 15：为 Batch 活动实现创建一个 Schedule Definition。

您将注意到一个被称为 Workload Scheduler 的新工作者的出现。您已经在包中显示的创建了这个工作者，这是由于您发现了一个参与到这个活动的实现中的新的活动者。正是在此处，您将业务的上下文环境传递到系统的上下文环境：假定您已经决定自动执行这个 Workload Scheduler 工作者。请您执行下列步骤：

首先，将模板添加到这个类中。
现在，您应当理解同这个工作者的每一次交互作用都定义了相应系统的一个用例，例如：一个交互作用成为了在序列图表中所描述的一个消息，而该序列图表对应于业务工作者类中的一个操作。随后，您还能够创建系统活动者来对应那些同新系统向连接的工作者（活动者），并且将或者模板添加到它们之中。
图 16 中显示的用例模型来自于 Workload Scheduler 工作者的引入消息，您可以在模型中所开发的所有活动实现中找到这些工作者。
您还能够看到一个系统活动者，它是一个符合 Schedule Developer Business Actor 的。您可以通过创建一个结点，将这个用例模型直接链接到序列图表上面，并且将该用例图表从模型树中拖动到这个结点之下。
除此之外，您能够将这些用例打包到一个顶层包中，并且使用模板对其进行刻画。

图 16：工作量 Scheduler 用例模型。

现在，我们希望这些用户对这个系统拥有一个成功和愉快的体验。USBD （基于统一场景的设计）方法论允许您设计这样一个系统，该系统将用户整合到业务处理过程之中，这应当肯定地说是一个成功的体验。然而，您可能还想将人为的因素考虑进来，从而提供一个有效的、简单的并且舒适的交互作用。

一种方法就是执行 Interaction Design （IaD），它最终定义了 Personas （角色）并且捕获了 User Goals （用户目标）。图 17 中显示了您如何描述模型中的用户目标，并且将系统的用例绑定到这些目标上。尽管这个例子并没有对其加以讨论，但是角色还可以通过使用 USBD 模板被描述和刻画，正如表 1 中所描述的那样。

图 17：用户目标。

最后，由于用户和系统之间的交互作用将会通过一个用户接口被建立，所以您能够为每一个相关的用例开发一个用例情节串联图板，根据参与的用户接口元素来描述这个交互作用将会如何发生，以及它们将如何被导航。

用例情节串联图板是用例的另一个，就像您在 Analysis 模型中所描述的通常实现一样。但是，它并没有定义用例如何通过系统被内在的实现，而是定义了用例如何通过其用户接口被外在的实现。图 18 中显示了您如何通过使用由一个状态机所描述的 UML 协作来建模一个用例情节串联图板。

您可以将协作和状态机都模板化为，状态集中的每一个状态都是一个。表现用户接口面板以及它们之间转换的各个状态，反映了和用户在面板上的活动相对应的定位路径。情节串联图板也被证明在设计用于用户接口的测试实例时是有效的。再一次说明，您能够将情节串联图板打包到一个顶层包之中，您可以使用模板来刻画它。

图 18：创建 Schedule 用例的情节串联图板。

图 19：业务处理过程路线图。

回页首

这篇文章是本系列的完结篇，它总结了在 IBM Rome 开发实验室中被成功实践的需求聚集和设计的方法论。

本文描述了关注于点对点的业务环境（即产品所存在的地方）的基于统一场景的设计（USBD）方法背后的原因，并且提供了将其链接到自动执行业务的系统的上下文环境中的强有力手段。通过解释如何将业务需要链接到软件执行，本文描述了通过处理过程路线图、目标和类图表来捕获业务处理过程的方式，以及如何通过系统执行来跟踪它们。本文还讨论了一种用户接口同系统分析相链接的正式的表示法。

本文所关注的重点在于帮助您将 USBD 方法论投入实践的那些工具。本文提供了一个新颖的规范，当您在 IBM Rational Software Architect 版本 7 及其后续版本中将它同 IBM WebSphere Business Modeler 综合特性一起使用时，这个规范允许您以一种正式的方式捕获和描述所有和业务、系统、用户经验层相关的概念。

回页首

下载

描述	名字	大小	下载方法
UML 2.0 Profile for USBD	usbdprofile_1.2.zip	101KB	HTTP


	关于下载方法的信息

学习

您可以参阅本文在 develperWorks 全球网站上的英文原文。
[1] Usability Engineering Scenario-based Development of Human Computer Interaction，作者：Mary Beth Rosson 和 John M. Carroll。
[2] An "outside in" approach to development，引自 CCR2，2005 年第 9 期。
[3] User-Centered Design: An Integrated Approach，作者：Karel Vredenburg、Scott Isensee 和 Carol Righi —— Prentice Hall 于 2001 年出版。
[4] 用户工程学，http://www.ibm.com/ibm/easy/eou_ext.nsf/publish/1996。
[5] 面向分析师的业务处理过程建模基础：“学习分析员的基本任务——业务流程建模”。
[6] 使用 UML 进行有效的业务建模：描述业务的用例和实现：http://www.ibm.com/developerworks/rational/library/content/03July/2000/2256/2256_PWN.pdf。
[7] 通过类推介绍 IBM Rational Unified Process 的本质：“通过类比介绍 IBM Rational Unified Process 的要点”。
[8] Unified Modeling Language 2.0：“统一建模语言(UML) 版本 2.0”。
[9] UML Distilled: A Brief Guide to the Standard Object Modeling Language, Third Edition，作者：M. Fowler —— Addison-Wesley 于 2004 年出版。
[10] UML 资源中心。。
[11] 关于 ITIL 请访问 http://www.ogc.gov.uk/index.asp?id=1000367。
请您浏览技术书店以获取相关技术主题的书籍。

获得产品和技术

请您点击这里下载 IBM Rational Software Architect 试用版，体验此软件的分析、设计和开发。
请您点击这里下载其他 IBM Rational 软件的试用版。
请您点击这里下载 IBM 产品的评测版本，体验 DB2®、Lotus®、Tivoli® 和 WebSphere® 的应用程序开发工具和中间件产品。

讨论

请您登录 developerWorks 博客并且参与到 developerWorks 社区之中。
请您点击这里访问 Rational Software Architect、Data Architect、Software Modeler、Application Developer 以及 Web Developer 论坛，提出关于 Rational Software Architect 和其他建模产品的问题。

作者简介


		Alex Donatelli 是 IBM 的一名高级技术人员。他是在意大利罗马的 Tivoli Laboratory 的主架构师，以及 Rome Central Architectural Team 的经理。他一直与罗马的 Tivoli 人员和整个技术社区一起，改进产品的质量。统一基于场景的设计工作是众多工作之一。


		Rosario 是意大利罗马的 Tivoli Laboratory 中的一名高级软件工程师。他是 IBM Tivoli Configuration Manager 的主架构师，在软件开发方面有十五年的经验，担任过软件工程师，市场经理和人员经理。在他之前的工作中，他一直从事于复杂企业级应用程序的架构，设计，发起人以及驱动实施。他经常与合作伙伴和客户工作在一起，有着大量的经验，将业务需要转化产品和解决方案需求。他获得过 Messina 大学物理学硕士。


		Claudio 目前是一名高级软件工程师，也是IBM Tivoli Configuration Manager 的主设计师，有14年多的经验在系统管理区域进行开发和理想状况。他是在 RUP 和基础上的。他被认为是在 RUP 和 UPS 方面的一个核心专家，他目前主要关注于软件工程最佳实践和模型驱动架构。


		Roberto Longobardi 是 IBM 的一名 Interaction Solution Designer。他从事过多个 Tivoli 开发项目，包括性能和可用性以及负荷管理方面。最近他正在尝试为 IBM Tivoli Workload Scheduler 界面提供一个重新设计基础，他寻求通过更接近其业务和运营环境来极大改善解决方案能力。统一的基于场景的设计是与罗马的 Central Architectural Team 的经验结合的结果。

通过用例实现需求管理

2008-11-14T21:14:00.000-08:00

级别：初级

Staff, IBM (dwinfo@us.ibm.com), Staff, IBM

2004 年 5 月 01 日

如果您对需求管理还不了解知或者只是有很少的了解，但你有希望改进需求过程，那么本文将为您提供一个框架，您可以利用它开发自己的方案。

过程时代的软件和系统开发

用例和软件需求说明 (SRS)

为了让读者更好地理解需求管理工作流程，作者从 IBM Rational Software 的统一过程（RUP）以及工业标准统一建模语言特地挑选了一些文档类型和需求管理工件予以说明。RUP 和统一建模语言都推荐使用一种用例驱动的软件工程流程。因此，本文描述了一种用于指定软件需求的用例驱动方案。这些工作流程还可代替用例模型和用例，或作为它们的补充，与更传统的软件需求规约（如 IEEE 标准）一起使用。

对大多数软件和系统开发团队来说，与过去自由的日子相比，20 世纪 90 年代是一个强调流程的时代。评测和验证有效的软件开发流程的标准得到推广和普及。许多论述软件开发流程的书籍和文献以及关于业务建模和重建的的相关材料纷纷出版。不断涌现出的软件工具已经帮助人们制定和应用有效的软件开发流程。在这十年内，全球经济对软件的依赖程度加深，它推动着开发流程的发展，提高了系统质量。

既然如此，那么今天频频发生的软件项目失败的事件又如何解释呢？即使不是大多数，但为什么仍有那么多的项目受到延期、预算超支和质量问题的困扰呢？随着我们的业务、国家经济和日常活动越来越依赖于系统，如何才能提高系统的质量？

像往常一样，答案就在于该行业的人员、工具和流程。需求管理通常在软件开发出现问题时作为解决方案提出来，但对于这门学科的改进则较少关注。

本文介绍有效需求管理流程的元素，特别强调成功实施需求管理所面临的障碍。

需求管理除了应用于纯软件项目以外，同样也应用于软件只占最终结果的一部分或根本不包括在内的项目。为方便起见，本文以后将使用“系统”这个词来指代任何或所有这些项目。然而，正是软件开发的抽象本质本身，或者和硬件一起，使需求管理复杂化了，因此本文的重点在于软件开发。

回页首

为什么要进行需求管理？

简单地说，系统开发团队之所以管理需求，是因为他们想让项目获得成功。满足项目需求即为成功打下了基础。若无法管理需求，达到目标的几率就会降低。

以下最近收集的证据很有说服力：

Standish Group 从 1994 年到 1997 年的 CHAOS Reports 证实，导致项目失败的最重要的原因与需求有关。[1]
1997 年 12 月，Computer Industry Daily 报导了 Sequent Computer Systems 公司的一项研究，该公司对美国和英国 500 名 IT 经理作调查后发现，百分之七十六的受访者在他们的事业中经历过完全的项目失败。其中提到最多的导致项目失败的原因就是“变更用户需求”。[2]

为什么要管理需求？避免失败就是一个很充分的理由。提高项目的成功率和需求管理所带来的其他好处同样也是理由。Standish Group 的 CHAOS 报告进一步证实了与成功项目关系最大的因素是良好的需求管理。

回页首

什么是需求？

理解需求管理的第一步就是对什么是需求管理达成共识。Rational 把需求定义为“（正在构建的）系统必须符合的条件或具备的功能”。电气和电子工程师学会 (IEEE) 使用的定义与此类似。

著名的需求工程设计师 Merlin Dorfman 和 Richard H. Thayer 提出了一个包容且更为精练的定义，它特指软件方面 - 但不仅仅限于软件。

“软件需求可以定义为：

用户解决某一问题或达到某一目标所需的软件功能。
系统或系统构件为了满足合同、规约、标准或其他正式实行的文档而必须满足或具备的软件功能。”[3]

回页首

什么是需求管理？

由于需求是正在构建的系统必须符合的事务，而且符合某些需求决定了项目的成功或失败，因此找出需求是什么，将它们记下来，进行组织，并在发生变化时对它们进行追踪，这些活动都是有意义的。

换句话说，需求管理就是：

一种获取、组织并记录系统需求的系统化方案。
以及一个使客户与项目团队对不断变更的系统需求达成并保持一致的过程。

这个定义与 Dorfman 与 Thayer 以及 IEEE 的“软件需求工程”的定义相似。需求工程包括获取、分析、规定、验证和管理软件需求，而“软件需求管理”则是对所有相关活动的规划和控制[4]。这里介绍的以及 Rational Software 提出的需求管理定义包括了所有这些活动。它们的区别主要在于这里选用了“管理”这个词，而不是“工程”。管理这个词更合适用来描述所有涉及到的活动，并且它准确地强调了追踪变更以保持涉众与项目团队之间共识的重要性。

对那些不熟悉“引出”这个词的人来说，它可定义为团队用来获取或发现涉众请求，确定请求后隐藏的真正需要，以及为满足这些需要对系统提出的一组适当需求。

回页首

需求管理问题

一个目的在于确保系统符合人们对其期望的流程面临着哪些困难呢？当它真正在实际项目实施时，困难就暴露出来了。图 1 显示了 1996 年对开发人员、经理和质量保证人员所做的一次调查结果。该图显示了经历过最常提到的需求相关难题的受访者比例。

图 1：常见的需求问题

下面列出了更多与需求有关的问题：

需求不总是显而易见的，而且它可来自各个方面。
需求并不总是容易用文字明白无误地表达。
存在不同种类的需求，其详细程度各不相同。
如果不加以控制，需求的数量将难以管理。
需求相互之间以及与流程的其他可交付工件之间以多种方式相关联。
需求有唯一的特征或特征值。例如，它们既非同等重要，处理的难度也不同。
需求涉及众多相关利益责任方，这意味着需求要由跨职能的各组人员来管理。
需求发生变更。
需求可能对时间敏感。

当这些问题与需求管理和处理技能不足以及缺乏易用工具等情况一同出现时，许多团队都对管理好需求不抱希望了。Rational Software 已经开发出指导团队提高需求管理技能和流程的专业技术。此外，Rational Requisite?Pro 是一个可获得的、有效进行自动化管理需求的工具。

回页首

需求管理技巧

为了解决上述问题，Rational 鼓励对关键技巧的开发。下面将要介绍的这些技巧是按顺序给出的，但在有效的需求管理流程中，它们以不同的顺序连续应用。在此，它们将以新项目在第一次迭代时可能使用的顺序出现。

图 2：问题分析步骤

关键技巧 1：分析问题

进行问题分析是为了理解业务问题，确定涉众的最初需要，并提出高层解决方案。这些推理和分析行为找出“隐藏在问题背后的问题”。

在问题分析过程中，将对实际问题的说明取得一致，并确定有关的涉众。初始解决方案的界限和约束从技术和业务两个方面来定义。在适当的时候，项目的商业理由还分析期望从系统获得的投资回报。

关键技巧 2：理解涉众需要

需求有许多来源。它们可能来自于对项目结果感兴趣的任何人。客户、合作伙伴、最终用户以及领域专家都是某些需求的来源。而管理人员、项目团队成员、业务策略和管理机构是另外一些需求源。

因此，掌握如何确定哪些人员应该是需求源、如何获得这些需求源以及如何从中获取信息是很重要的。作为提供这些信息主要来源的个人在本项目中称为“涉众”。

如果您正在开发一个在您公司内部使用的信息系统，那么在开发团队中应包括具有最终用户经验和业务领域专业知识的人员。讨论一般从业务模型一级开始，而不从系统一级开始。如果正在开发一个要在市场上出售的产品，那么您可以充分调动营销人员，以便更好地了解该市场中用户的需要。

获取需求的手段包括访谈、集体讨论、概念原型设计、问卷调查和竞争性分析等。需求获取的结果可能是一份图文并茂的请求或需要列表，并按相互之间的优先级列出。

关键技巧 3：定义系统

定义系统指的是解释涉众需求，并整理为对要构建系统的意义明确的说明。在系统定义初期，需要决定需求的构成、文档格式、语言规范、需求等级、请求优先级和预计工作量、技术和管理风险以及系统规模等。系统定义活动还可包括与最关键的涉众请求直接联系的初期原型和设计模型。

我们使用了“说明”这个词而没有用“文档”，是为了避免在后者常见的使用中发现的固有缺陷。说明可以是书面文档、电子文件、图像或用于表达除系统本身以外的系统需求的任何表示方式。

系统定义的结果是用自然语言和图解方式表达的系统说明。后面几节将介绍推荐使用的一些说明格式。

原则 55：在编写比较正式的模型前，先使用自然语言进行编写

在第一次编写正式模型时，往往要用自然语言描述模型，而不是直接得到解决方案系统。请考虑以下示例：

要打长途电话时，用户应该拿起电话。系统将回应拨号音。用户拨打号码“9”，系统回应一种特殊的拨号音...

系统有四种状态：空闲、拨号音、特殊拨号音和连接状态。要使系统从空闲状态转向拨号音状态，请拿起电话。要从拨号音状态转到特殊拨号音状态，请拨号码“9”。

-Alan M. Davis, 201 Principles of Software Development, 1995

关键技巧 4：管理系统规模

项目规模由分配给它的需求集定义。管理项目规模，使之适合可用资源（时间、人力和资金），是成功管理项目的关键。管理规模是一个持续不断的活动，需要迭代式和递增式开发，这就将项目细分为更易于管理的若干个小部分。

使用需求属性（如优先级、工作量和风险）作为协商应包含需求的基础，对管理规模而言是相当有用的技巧。侧重于属性，而不是需求自身，将减少通常对敏感问题的争论。

这也有助于培养小组负责人的谈判技巧，还有助于在项目中为组织培养推介人，对于客户而言也是如此。产品/项目推介人应能够代表组织拒绝那些超出可用资源的规模变更，也应有相应能力扩展资源以适应扩大的规模。

关键技巧 5：改进系统定义

对高层系统定义达成一致并充分理解了系统初始规模后，投入资源改进系统定义不仅有可能，而且也是经济的。改进系统定义包括两个重要的考虑事项：制定更详细的高层系统说明和验证系统是否符合涉众需要，是否按说明运行。

说明通常是项目团队的重要参考材料。在制定说明时一定要考虑受众。人们常会犯一个错误，那就是用复杂定义表示构建起来很复杂的东西，尤其是在受众无法或不愿意耗费精力去思考某些重要的需要取得一致认识时候。这就难以向项目团队内外的人员解释系统目的。相反，你可能会发现需要为不同的受众编制不同类型的说明。本文介绍了详细自然语言、正式文字和图解说明推荐使用的格式。确定说明格式后，改进将持续贯穿整个项目生命周期。

关键技巧 6：管理变更的需求

不管您多么认真地定义需求，需求终将改变。实际上，一些变更是非常值得的！这意味着您的团队需要与涉众保持密切联系。能否适应变更需求是评测团队的涉众敏感度和运作灵活性的一个尺度 - 敏感度和灵活性都是对项目成功有贡献的团队特征。变更不是敌人，而没有管理的变更才是真正的敌人。

图 3：变更管理流程

需求变更表明多少需要耗费一些时间来实施某个特定的功能，而且对一个需求的变更对其他需求可能有影响。管理需求变更包括这样一些活动：设立基线、追踪每个需求的历史、确定哪些依赖关系值得追踪、在相关项之间建立可追踪关系以及维护版本控制等。如图 3 所示，建立变更控制或批准流程也很重要，它要求由指定的团队成员来复审所有提议的变更。有时候这一单一的变更控制渠道称为变更控制委员会 (CCB)。

回页首

重要的需求概念

为了在项目中运用需求管理技巧，参与项目的每个人理解某些基本的需求管理概念是很有裨益的。这些功能包括：

需求类型
功能交叉的团队
可追踪性
多维属性
变更历史

需求类型

系统越大越复杂，出现的需求类型就越多。一个需求类型不过是指需求的一个类。通过确定需求类型，团队可以把大量需求组织成意义明确且更容易管理的组。在一个项目中建立不同类型的需求有助于团队成员对变更请求进行分类，并使相互之间的沟通更为清楚明确。

通常，一类需求可以细分即分解成其他类型的需求。业务规则和前景声明包括高层次的需求，团队可以从中导出用户需要、特性和产品需求类型。用例和其他建模形式驱动设计需求，该需求可分解为软件需求，并可以用分析设计模型来说明。测试需求源于软件需求，它被分解为具体的测试过程。如果既定项目中有成百上千个，甚至上万个需求实例时，对需求进行分类可以使项目更容易管理。

功能交叉的团队

与诸如测试或应用程序建模等流程不同（这些流程可在单个业务组中进行管理），需求管理涉及了每一个能够为开发流程提供专门技术的个人。其中应包括那些代表客户和业务预期的人。开发经理、产品经理、分析员、系统工程师甚至客户都应该参与进来。需求团队还应包括创建系统解决方案的人 - 工程师、构架设计师、设计员、程序员、技术文档编写员以及其他提供技术支持的个人。测试员和其他质量保证人员应当作重要的团队成员。

图 4: 功能交叉的需求团队

通常，创造和维护需求类型的职责可按照功能范围来分配，从而进一步优化大型项目的管理。需求管理的功能交叉性质是这门学科非常具有挑战性的一个方面。

可追踪性

如需求类型说明所述，没有一个需求表述是孤立存在的。涉众请求与提议用于满足这些请求的产品特性有关。产品特性与指定特性的功能性和非功能性行为的各个需求相关。测试案例与它们检验和验证的需求相关。有一些需求可能依赖于其他需求，也可能相互排斥。团队为了确定变更带来的影响，保证系统符合预期，就必须理解、记录并维护这些可追踪性关系。尽管可追踪性是需求管理中最难实施的概念之一，但它是适应变更所必不可少的。建立明确的需求类型，吸收功能交叉人员的参与，可使可追踪性更容易实施和维护。要了解需求可追踪性策略的更多信息，请参见白皮书“通过用例进行需求管理的可追踪性策略” [5]。

图 5：需求可追踪性

多维属性

每一个需求类型都有属性，每一个独立需求都有不同的属性值。例如，可为需求分配优先级，确定其来源和原理，委派给某个职能范围内的特定子团队进行管理，指定一定的难度，或者与系统的某个迭代关联关系起来。图 6 对此作了说明，该图显示了 Rational RequisitePro 需求管理工具中 Learning Project 的一个特性需求类型的属性。正如屏幕的标题所暗示，需求类型和每种类型的属性是为整个项目定义的，由此确保了团队上下使用的一致性。

图 6：定义特性的需求属性

图 7 显示了 RequisitePro 中某个项目的特性需求实例。注意，即使未完整地显示每个需求，但我们从属性值即可了解每个需求的很多内容。在这个例子中，需求的优先级和难度 - 毫无疑问是由团队的不同成员指定的 - 有助于团队兼顾考虑涉众优先级，以及对难度属性值所反映工作量的大致估计，把项目规模限制在可用资源和时间的合理范围内。在更详细的需求类型中，优先级工作量属性可能有更多的具体值（如预计时间、代码行等），从而进一步改进规模。需求的多维性以及不同类型的需求（每种类型都有自己的属性）对于组织大量需求和管理项目的整体规模来说是不可或缺的。

图 7：设置各个需求的属性值

变更历史

单个需求和需求集合都有历史记录，并且内容随着时间的推移而更具有含义。变更在所难免，而且变更有助于与环境变化和技术发展保持同步。记录项目需求版本有助于团队领导人找出变更项目的原因，如新的系统发布等。需求集合可能与某一个软件版本相关，理解这一点有助于人们扩大对变更的管理，降低风险，提高实现重大里程碑的几率。随着单个需求发展，理解它们的变更历史是很重要的：变更内容、起因、时间和谁授权变更等。

回页首

实施需求管理工作

需求管理采用上面介绍的关键技巧和概念成功地识别并解决问题。

为了建立一个真正满足客户需求的系统，项目团队首先必须确定系统要解决的问题。然后，团队必须确定涉众，从中获得业务和用户需要，对其进行描述，并区分它们的优先级。从这一组高层期望或需求出发，对产品或系统特性集达成一致意见。

详细的软件需求应该以客户和开发团队都能理解的形式写下来。我们发现，使用客户的语言来描述这些软件需求在取得理解和共识的过程中是最有效的。这些详细的软件需求随后用作系统设计规约的输入，或者作为实施和验证所需的测试计划及过程的输入。软件需求还应该促进初始用户文档规划及设计。

图 8：需求管理结构概述

为了推动需求管理，项目团队应该：

对项目的常用词汇表取得一致。
制定系统前景，描述系统将要解决的问题以及系统的主要特性。
至少获得五个重要领域的涉众需要：功能、可用性、可靠性、性能和可支持性。
决定使用哪些需求类型。
为每一个需求类型选择属性及属性值。
选择需求的说明格式。
确定创造一种或多种需求类型的团队成员，以及那些对此有贡献或仅仅进行查看的团队成员。
决定所需的可追踪性。
制定变更需求需遵守的提议、复审、决议程序。
开发一个追踪需求历史的机制。
为团队成员和管理人员创建进度和状态报告。

这些必要的需求管理活动与行业、开发方法和需求工具无关。它们同时也很灵活，能够在最严格、变化速度最快的应用软件开发环境下执行有效的需求管理。

文档简介

用文档来描述需求的决定值得认真考虑。一方面，书面记录是人们广泛接受的一种交流形式，对大部分人来说，这是自然不过的了。另一方面，项目的目标在于产生系统，而不是文档。

常识和经验告诉我们，问题不在于是不是要记录需求，而是怎么记录。文档模板为需求管理提供了一种统一的格式。Rational RequisitePro 不仅提供这些模板，还提供其他特性，将文档内的需求链接到一个包含所有项目需求的数据库。这种独一无二的特性不仅允许需求自然地记录下来，同时还能存放在关系型数据库里，便于访问和管理。

回页首

需求管理：工作流程明细

根据领域的不同，需求管理可遵循的方案有无限多种。下面的方案给出了六个详细的工作流程，它们适用于每一个关键的需求管理技巧，但也可以应用到任何领域。

下面的工作流程图摘自 Rational Unified Process [6]，需求工作流程明细。这些工作流程用角色、活动和工件（输入或输出）表示，图 9 的活动图对它们进行了概括。旁边的文字简单描述了每个工作流程，希望藉此增进读者对改进需求管理流程的理解和兴趣。关于 Rational Unified Process 的更多信息，可参考 http://www-900.ibm.com/cn/software/rational/products/unified_process/index.shtml.

图 9： Rational Unified Process 中的需求工作流程

工作流程明细：分析问题

在问题分析中，主要的活动是制定项目前景。此活动的结果是产生了一个前景文档，它确定了待建系统的高级用户或客户视图。前景文档将初始需求作为关键特性表述，这些特性是系统为了解决重大问题并满足关键涉众需要而必须具备的。系统分析员在此工作流程中扮演主要角色。系统分析员应该具有问题分析领域的专业知识，对问题有一定的理解，还应该能描述其认为可以解决问题的流程。此阶段要求各个项目涉众积极参与，还应该考虑所有相关的涉众请求。

要开始管理依赖关系活动，应该为职责分配属性，如基本原理、相对值或优先级以及请求的来源等。随着前景的发展，分析员确定可能用例的用户和系统（主角）。主角是用例模型的首要要素，它们将定义系统的功能性和非功能性技术需求。

图 10：分析问题

工作流程明细：分析问题

启动：一个或多个认识到问题存在的涉众启动工作流程。

开发团队中的系统分析员可以和这几个最初的涉众展开会话，帮助他们描述需要解决的问题。对所认识问题的简要说明达成一致意见是很重要的。下表列出了问题说明的关键元素：

问题	定义问题
对涉众影响	列出受问题影响的涉众
问题的影响	描述问题的影响
成功的解决方案	列出成功解决方案的一些主要优点

问题说明简明扼要解释了项目的目的。问题分析员深入调查所有涉众请求和初始商业理由，包括显著优点以及大致估计的成本等。在定义问题说明的同时，团队还应该编写词汇表，记录常用术语并统一其定义。

用例模型简介

用例模型包括主角、用例以及它们之间的关系。主角代表了必须与系统交换信息的所有事物，包括通常所谓的用户。当主角使用系统的时候，系统执行一个用例。好的用例是一个事务序列，该序列为主角提供一个可评测的价值结果。用例集合是系统的完整功能。

-Jacobson I., Christerson M., Jonsson P., Overgaard G., Object-Oriented Software Engineering - A UseCase Driven Approach, Addison Wesley - ACM Press, 1992

问题分析员还确定系统的主要主角。主角是系统的用户或者将与之交换信息的其他任何系统。在这一阶段，问题分析员应该简单确定主角与系统交互的一些显而易见的方式。说明应面向业务流程而非系统行为。例如，预算程序可能会允许一个类型的主角“制定部门预算”，而其他类型的主角可以“合并部门预算”。系统分析员以后可以将它们用到其他用例中，这些用例与特定系统行为结合起来更有意义。例如，“制定部门预算”可以产生像“导入电子表格信息”以及“创建预算视图”等系统用例。

上述问题分析会话通常进行不止一次，会话对象可能是不同的涉众，并且中间还夹带开发团队的内部会话。与涉众打交道的系统分析员将主持一次与开发团队成员的会话，展望问题的技术解决方案，从初始涉众输入中导出特性，并起草前景说明，即待建系统的第一个定义。为了方便初始涉众理解提议的解决方案，系统分析员可以利用建模工具或手工绘图技术来完善前景说明。

要从多方面向初始涉众咨询，以帮助改进问题说明，限制可能解决方案的个数和规模。涉众和系统分析员就关键特性的优先级进行谈判，对资源及开发资源所需的工作量取得一般性的理解，藉此来管理该工作流程中的依赖关系。尽管优先级和工作量/资源的估计不可避免会发生变化，但提早管理依赖关系可建立起一个在整个开发生命周期中一直延续使用的重要模式。这是规模管理的本质所在，是一个项目成功的早期预报器。

A在经过几次草案更新后，前景文档进入团队必须决定是否对额外需求获取进行投资的阶段。同时，商业理由的批准过程也分别开始启动了。本文不打算深入探讨商业理由，只对其进行简单说明。商业理由描述：

环境（产品领域、市场和规模）
技术方案
管理方案（时间安排、风险、对成功的客观评测方法）
以及财政预测

工作流程明细：理解涉众需要

如果初始问题分析证明增加投资是合理的，则郑重开始理解涉众需要工作流程。这一阶段的关键活动是获取涉众请求。主要结果是收集确定优先级的涉众需要和特性，利用此结果可改进前景文档，加深对需求属性的理解。另外，在这个工作流程中，您可以根据用例和主角对系统展开讨论。另一个重要输出结果是经过更新的词汇表，它使团队成员对常用词汇有一致的理解。

图 11：理解涉众需求

工作流程明细：理解涉众需要

系统分析员和关键涉众通过访谈、专题讨论会、示意板、业务流程用例和其他手段，确定更多的涉众，获取他们的请求，确定关键需要和特性。这些会话由一个或多个系统分析员主持进行。需求专题讨论会是最有用的需求获取手段。该流程包括用户、帮助台人员、企业主、测试员以及其他对提议项目的结果有利害关系的个人。涉众请求通常是不明确、重叠甚至是离谱的。除正式的获得结果外，涉众请求还可以用格式设计很好的文档、数据库的缺陷和扩展请求或者电子邮件和群件线程等形式表达。系统分析员记录已确定的关键涉众需要，对其进行分类和区分优先次序。

理解涉众需要：“取悦客户”从何处开始

涉众请求要尽可能在请求涉众使用的语言和格式中获取。与后继的需求类型（通常由具有丰富流程知识和技术的项目团队成员创造）不同，涉众请求通常很难表达清楚。涉众请求经常交叉或重复。而且涉众请求的表达形式多种多样，从纸条到扩展请求数据库等等都有。

分析员（或代表分析员角色的团队）必须复审所有需求，对其进行解释、分类，甚至还要重新录入（不重写），在前景文档中将其翻译成关键涉众需要及系统特性。根据开发的严格程度以及工具的可用性，可应用一部分或所有涉众请求、需要与特性之间的可追踪性，帮助涉众理解在决定系统需求时如何解释清楚他们的请求和需要。

通过应用理解涉众需要工作流程，说明获取请求和满足涉众需要的非常重要事项，对建立涉众对开发团队能力的信心而言具有重大意义。

对涉众需要有了更好的理解之后，开发团队里的系统分析员改进前景文档，将主要精力放在制定“产品定位说明”上。该说明用简洁的两三句话确立项目的显著价值。说明应包括预期用户、项目解决的问题、所带来的利益，以及它所取代的竞争者。所有的团队成员都应该理解该项目的主题。系统分析员还更新词汇表，促进团队对术语的共同理解。

从多方面向关键涉众咨询，以便对从理解涉众需要得到的新特性的优先级进行协商，获得对当前开发新特性所需资源和工作量的理解。利用问题分析，在该工作流程中管理依赖关系有助于管理项目的规模。它还建立起涉众请求、需要与系统特性之间的可追踪性，让涉众相信他们的建议确实得到考虑。

工作流程明细：定义系统

最初的两个需求工作流程明细（分析问题和理解涉众需要）创建了关键系统定义的早期迭代（包括前景文档指定的特性）、用例模型的第一个大纲，以及初始需求属性。下一个工作流程明细即定义系统，通过改进特性定义，添加新主角、用例和补充规约，完善了高级系统需求说明。

图 12：定义系统

工作流程明细：定义系统

更新词汇表是为了反映当前对术语的理解，这些术语用于描述在用例模型及补充规约中捕获的特性和需求。

系统分析员使用在改进的前景文档中定义的特性集来派生用例并以说明，这些用例详细阐述用户对系统预期行为的观点。用例模型作为客户、用户和系统开发人员之间的合同，规定了所选特性如何在系统中发挥作用。它有助于系统开发人员设置符合现实的期望和目标，帮助客户和用户验证系统是否达到了这些期望。

一些系统需求没有很好地符合用例。系统分析员就在补充规约里说明这些需求。许多非功能性需求，如可用性、可靠性、性能、可支持性等，都放在补充规约中。应该注意，这些类型的许多非功能性需求专门针对单个用例。用例阐释者最好将这些需求放在用例规约本身（请参见改进系统工作流程），在补充规约里描述系统范围的非功能性需求。

在该工作流程明细中，系统分析员创建和设置了补充需求的属性（如优先级和相关用例）。除此之外，系统分析员还为初始用例和新用例添加并更新属性值。

最后，系统分析员通过追踪重要用户需要和关键特性到相关用例以及补充规约说明的需求，以此来管理依赖关系。

工作流程明细：管理系统规模

在确定特性级别的需求，描述大多数主角、用例以及补充规约所指定的其他需求后，系统分析员应该收集需求属性（如优先级、工作量、成本和风险等），并尽可能精确地为其指定属性值。这使得人们对如何确定系统发布的初始规模有了更好的理解，也让构架设计师能够从结构上确定具有重要意义的用例。

由项目和开发管理人员一起制定的迭代计划，首次出现在该工作流程明细：管理系统规模中。迭代计划也是一个开发计划，它定义为发布版计划的迭代次数和频率。早期的迭代应计划规模内风险最高的元素。

管理规模工作流程的其他重要输出包括软件构架文档的初始迭代和一个修订过的前景文档，前景文档反映分析员和关键涉众对系统功能和项目资源的加深理解。

与前面提到的商业理由一样，迭代计划的第一个问题是，软件构架文档不是需求管理工作流程的一个工件，尽管它与该工作流程有关而且是 Rational Unified Process 的一部分。这部分内容不在本文的讨论范围内。

经验告诉我们，成功管理规模的关键在于，仔细考虑分配给涉众需要、特性、用例和补充规约所指定的其他需求的属性值，与代表性涉众定期进行开放而诚恳的交流。

图 13：管理系统规模

工作流程明细：管理系统规模

构架设计师为用例的风险范围、构架重要性和构架覆盖范围确定优先顺序。尽管定义系统时用到了许多用例和补充规约需求，但通常只有用例的一个子集才是好的系统构架的关键。确定用例的优先级后，构架设计师改进迭代或开发计划，利用 Rational Rose 这类工具建立系统构架的用例视图模型。

系统分析员通过改进前景中特性的需求属性来管理依赖关系。他们还对用例和补充规约里的需求进行改进。系统分析员确保涉众需要、特性、用例需求和补充规约需求存在适当的可追踪性。这里特意使用了“适当的可追踪性”。请参见本文中插入的关于可追踪性的说明文字。

在整个项目中，该步骤是最为重要的步骤之一。第一次，我们对所提议的系统了解如此之深，使得我们能对需求、项目资源和交付日期作出重大承诺。同时也必须理解，这些需求将会随着了解程度的加深而变更。如果在前三个工作流程对依赖关系进行管理，则执行这一步骤就会容易得多，将来进行变更也更容易。

贯穿项目的整个生命周期，随着形势和环境的变化，由于系统分析员必须就修改后的项目规模和前景与关键涉众进行协商，因此将会多次重新检查该工作流程明细。涉众和开发团队成员只有把该步骤看作一个自然前进过程 - 既不要让用户措手不及，也不要企图向组织索要更多时间和金钱 - 才能成功管理项目规模，使之与可用资源相符合。该工作流程在项目的主要里程碑处需重复多次，以便评估对系统及系统问题的新认识是否要求变更规模。尽管已承诺的需求、预算和期限很难更改，但随着对确定优先级的用例、补充规约和早期系统迭代的深入理解，不可避免会导致人们重新考虑系统规模。

需要重申，在到达改进阶段之前，以及在贯穿项目生命周期内发生变化前，项目团队应维持日常的规模管理，这一点很关键。涉众代表必须理解并相信，在难度不断增加的规模协商中，他们的优先考虑和利益始终得到认真的对待。在改进系统需求之前，只有重要的需求才有待于协商或修改。除非建立有效的规模管理制度，否则项目注定会变成一次“死亡之旅” - 规模过大的项目将残酷地走向延期和成本超支的绝路。

工作流程明细：改进系统定义

进入改进系统定义后，该工作流程明细假设已经概述了系统级别的用例并至少简要描述了主角。通过项目规模管理，前景中的特性再次确定了优先顺序，现在可以相信，这些特性在比较严格的预算和期限下是可以实现的。该工作流程的输出是对系统功能更深入的理解，这些系统功能在详细用例、已修订的补充规约以及系统本身的初期迭代中进行说明。

显然，不是所有的系统都有用户界面，不是所有的初期迭代都包括 GUI 元素。这里我们仅仅将它们作为初期迭代的示例。其他例子包括原型、模型和示意板。

图 14：改进系统定义

工作流程明细：改进系统定义

用例阐释者详述每个用例的事件流定义、前置和后置条件以及其他文本属性。为最大限度地减少工作量并提高可读性，建议使用标准文档格式或用例规约模板来记录每个用例的文字信息。创建考虑周全的用例规约对系统质量至关重要。制定规约要求对涉众需要以及与用例相关的特性有透彻的理解。让项目团队的若干成员（如软件工程师）参与用例创建是再好不过了。

同时，用例阐释者使用并非用例特有的附加需求对补充规约进行修订。

用户界面设计员模拟系统的用户界面并进行原型设计。这项工作与用例的演进密切相关。

对每个需求有更深入的理解后，用例阐释者和系统分析员对其工作量、成本、风险以及其他属性值进行修正。

系统定义改进流程的结果提交给另一轮管理规模工作流程明细。对系统有更多的了解后，可能需要改变优先级。毫无疑问，如果必要，系统发布的规模将需要复审和改进。

工作流程明细：管理需求变更

当变更发生时 -- 变更是不可避免会发生的 -- 管理需求变更工作流程明细需持续应用于项目生命的全过程，这与管理系统规模工作流程明细一样。该工作流程的输出可能导致对每个工件的修改，这又要求在所有的项目团队成员和涉众之间进行有效的交流。

在这个工作流程中，我们引入了受需求工作流程影响的其他工件。需求的变更必然影响在分析设计工作流程中表示的系统模型。需求变更还影响用于验证需求是否正确实施的测试。在前面的例子中，这些工件是 Rational Unified Process 的组成部分，但不是本文论述的主题。在管理依赖关系流程中确定的可追踪性关系是理解这些影响的关键。

可追踪性

在需求领域，与可追踪性有关的事务有很多。许多事务都具有追踪单个客户需求到每个相关规约、测试、模型元素以及最终源码文件的特点。的确，一些可追踪性是成功的需求变更管理的关键。

然而，这里事先警告，在项目的整个生命周期中，建立和维护各种形式的可追踪性都需要投资。像所有的投资一样，可追踪性的投资回报点逐渐减少，这取决于具体情况。本文强调在不同需求类型之间进行追踪的价值。这是一个很好的起点，而且可以用 Rational RequisitePro、Rose、SoDA 和 TeamTest 这样的工具使之自动化。我们相信，你终将发现某个级别的需求可追踪性是好的投资对象。

要了解需求可追踪性策略的更多信息，请参见白皮书“通过用例进行需求管理的可追踪性策略” [6]。

管理需求变更工作流程的另一个重要概念是需求历史追踪。通过把握需求变更的性质和基本原理，复审员（工作受变更影响的任何软件项目团队成员）将收到对变更作出正确响应所需的信息。

图 15：管理需求变更

工作流程明细：管理需求变更

出于各种原因，任何涉众或项目团队成员都有可能提出变更需求的请求。所有变更请求 (Cr)，包括对需求或扩展请求甚至缺陷的变更，都应该通过同一个变更请求管理 (CRM) 流程进行疏导。至少，这应包括在一个集中数据库系统中记录并追踪请求，并由中央复审委员会执行复审。CRM 流程的详情见 Rational Unified Process 的其他小节。

系统分析员应该协调最好由变更控制委员会 (CCB) 执行的复审活动，收集并检查所有的变更请求，并将它们分类为：

实施中不影响需求的缺陷
对现有的某类型需求的修改
扩展要求

分类后，按在其他需求工作流程中描述的方法为所提出的需求变更指定属性和值。

在复审变更请求的时候，系统分析员向一个由涉众代表和项目团队成员组成的 CCB 陈述确定优先顺序的需求变更。超过资源限制的规模修改请求被拒绝，或者将其上交给涉众代表，涉众代表有权批准对日期以及预算事项的必需变更。CCB 批准或拒绝需求变更。

系统分析员把需求变更传达给需求阐释者，或直接修改前景、用例、补充规约文档或其他需求工件中的需求。

需求复审员（开发人员、测试员、经理及其他团队成员）通过审查需求历史，对需求变更对他们的工作造成的影响进行评估。最后，他们实施变更，对他们有权修改的相关需求作适当改动。

回页首

管理需求的需要并不新鲜。那么，究竟是什么值得我们去思考呢？首先，如果项目常常不能满足客户、错过最后期限和预算超支，就有理由重新考虑开发方案了。在设计方案时，如果您确信与需求相关的问题正在消耗你的开发工作，就有理由考虑改进需求管理了。

其次，本文总结的需求管理方案体现了几千个案例的集体经验和智慧，而且代表了许多个人深思熟虑的观点，他们在需求管理领域与客户合作已有数年时间。我们认为，他们的贡献 - 以及 Rational Unified Process 对这些贡献所作的透彻陈述 - 总结起来代表了需求管理的“最佳方案”。你将发现这些需求建议是最可靠的。

作者向 Dr. Ivar Jacobson 对本文的直接和间接贡献，以及 Dean Leffingwell、Dr. Alan Davis、Ed Yourdon 和 Elemer Magaziner等人的帮助表示感谢。尤其，我们要感谢 Rational Software 的客户，他们在数以百计开发项目中应用和改进了这些方案。

最后，在过去的两年内，生产有效软件开发解决方案的领先公司 Rational Software 接受需求管理的挑战，生产了多种工具来使执行这一艰巨任务实现自动化。长期、普遍存在的需求管理问题得到了解决。也许这最终才是今天在需求管理领域开始追求卓越的最佳原因。

关于上述概念的完整论述，请参考 Dean Leffingwell 的关于软件需求管理的优秀著作[7]。

CHAOS, The Standish Group International, Inc., Dennis, MA, 1994, 1997.
Computer Industry Daily, December 12, 1997.
Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press,Los Alamitos, CA, 1997 pp. 79.
Dorfman, M. and R. Thayer, Software Engineering, IEEE Computer Society Press,Los Alamitos, CA, 1997 pp. 80.
Spence, Ian and Leslee Probasco, "Traceability Strategies for Managing Requirements with Use Cases",White Paper, Rational Software Corporation, 1998.
Rational Unified Process?, Rational Software Corporation, Cupertino, CA, 1999.
Leffingwell, Dean and Don Widrig, Managing Software Requirements - A Unified Approach, Addison-Wesley, 2000.


		This article is brought to you by IBM Staff.

一个项目经理对 RUP 的评论

2008-11-14T21:12:00.000-08:00

级别：初级

Vitalie Temnenco, 架构师, Sierra Systems

2008 年 5 月 15 日

阅读 IBM Rational 统一过程（Rational Unified Process, RUP）如何补充项目管理知识体系（Project Management Body of Knowledge，PMBOK），以及精通 PMBOK 的项目经理如何理解并使用 RUP 来支持其项目经理（Project Manager，PM）的角色。

来自 The Rational Edge.

为了寻找答案，项目经理（project managers，PMs）一般会从架构师找到开发人员，从开发人员找到测试人员等等。由于经常得到项目管理专业人员（Project Management Professional，PMP）认证的授权，PM 发现他们逐渐依赖于具体领域的专家经验了。他们经常发现 IBM® Rational® Unified Process®，或 RUP®，是实现团队所选择的框架，因此他们必须根据 RUP 规程调整并重新思考他们所了解的东西。

本文讨论了现代 IT 驱动的企业中的项目管理。本文探究了关于 RUP 作为项目管理工具的普遍误解，讨论项目管理知识体系（Project Management Body of Knowledge，PMBOK）标准如何与 RUP 交叉，并且阐述了减少或消除当把两个互补的过程框架联系起来时经常误以为存在的歧义的方式。最后，本文假定并探究企业 PM 角色的潜在价值。

根据我作为企业架构师的经验，本文还包含了一些项目管理的架构上的观点。IT 架构师为了了解项目经理的预期可以阅读本文，而 PM 可以阅读本文，从而了解更多关于 RUP 和 IT 架构的内容。

我们已经了解的关于项目管理的内容

按照流行的互联网百科全书上说的，项目是“创建带来有益的变化或增加的价值的独立产品或服务的临时且一次性的工作”。每个项目都需要资源 —— 包括人和资金 —— 并且项目管理（project management，PM）是试图用将产品或服务在分配给项目的范围、质量、时间，和成本界限内进行划分的方式组织和管理资源的规程。

虽然项目管理风格常常粗略地对应正在应用的软件开发生命周期（Software Development Life Cycle，SDLC）方法规格，例如瀑布、迭代、快速应用程序开发（Rapid Application Development，RAD），或敏捷开发，但是每个项目都涉及一组公共的活动，包括：

计划、分析和设计目标
评估和控制风险
估算和分配资源
获得人力和物力资源
通过分配任务和指导活动来组织工作
根据所获得的价值分析结果
预测项目
管理质量
问题预防和解决
项目结束
项目沟通
追踪和报告进展

PMI 是什么？

项目管理协会（Project Management Institute，PMI）建立于二十世纪六十年代末，并且是项目管理领域中的世界领导组织。它的成员总数超过 220,000，包括超过 170 个国家中的 160,000 认证的成员。PMI 开发了最全面的 PM 框架之一（PMP），并且提供了许多等级的项目管理认证。

PMP 是什么？

依据认证个人的数量来说，PMP 是世界最广泛认可的 PM 认证计划。它提供三个等级，包括 PM 助理、项目经理和规划 ¹ 管理中的认证。

PMBOK 是什么？

PMBOK 是被普遍接受为项目管理中最佳实践的标准的过程和知识资产的集合。它包含在大部分项目及在大多数商业领域（从建筑到软件工程）中复用的五个过程组（举例来说，初始和计划）和九个知识领域（举例来说，范围管理和时间管理）。在 PMBOK 中，过程是根据输入工件、工具和技术来描述的。技术消耗并且生产工件，同时也使用工具。

不同种类的管理者

在各种各样的管理角色中，只有一个拥有“项目” 修饰词。在当今的动态商业环境中，它已经远离了，因为它需要了解项目实体的独特性质，以及应用领域的管理规程的知识，这在软件开发的情况下是“迭代的”、“架构驱动的”和“减少风险的” 。

组织经理

与 “项目”作为临时且一次性的工作的定义相对比，许多组织任务是重复的，每次重复都有相同的基本范围（不要将其与迭代的实现相混淆，迭代实现的任务重复但生成不同的范围或细节）。一些实例是人力资源和库存管理功能，其中管理活动相当于确保充分地、每天地，及按部就班地执行任务。担任后一个角色的人可能担当各种管理职位，并且执行各种标准的管理活动。

项目经理

不像其他的组织管理角色那样，明确规定 PM 角色是治理独立的任务的。因此，为了准时且在其他确定出的约束条件内交付产品或服务，PM 必须能够了解任务的范围并选择及应用最佳的管理过程。与需求结合来开始并结束项目对 PM 的工作是非常必要的，并且还令其区别于其他的企业管理角色。

代理项目经理

项目常常是在根本没有专门的 PM 的情况下开始的。极其普遍的情况是经验丰富的团队成员承担所有或一部分 PM 的职责。一般来说，虽然有某个临时或兼职管理项目的人比没有项目管理要好，但是长时间采用代理项目经理是很糟的实践，因为这令决策制定的连续性和一致性处于危险中。此外，这个临时的 PM 角色常常是由缺乏重要的领域经验或者缺乏承担额外职责的动机的团队成员担当，这会导致未达到的预期，或令项目完全失败的最坏情况。

技术项目经理

PM 担当解决方案架构师或技术领导角色是很常见的。虽然这常常是糟糕的实践，但是对较小的项目团队（通常少于十个成员）有效。团队中拥有技术项目经理的好处之一是，在彻底了解了需求和/或设计的基础上，她可能能够生成可靠的项目计划。反过来，这可以帮助消除实现团队中的“沟通不畅”综合症。问题是她可能没有足够的时间致力于项目计划，更不用说提供有效的项目覆盖和控制。

规划经理

一些项目采取超出它们管理能力的方式。典型的情况是引入分层的项目管理结构，包含顶层的“规划”和下面的项目。计划管理是非常特殊类型的项目管理，它整体地处理项目，同时了解项目的个别表现。计划经理的主要职责包括将范围“分割为”可管理的块（项目），编制并管理它们的相关性，并且计划并进行扩大和委托。

企业项目经理

现代的组织是十分复杂的实体，其中在不设置为项目的情况下就可以常规地完成事情。一个实例是企业架构实现及其各种步骤，例如，远景开发、商业案例开发，和商业过程分析。这些功能可能十分复杂，因而，如果没有以及时的方式将它们包含于固定的边界内就很难管理。主题专家，例如 IT 架构师、过程工程师，和顾问很少拥有执行正式的企业 PM 活动所需的技能。所有这些都规定需要企业项目经理（Enterprise Project Manager）角色，我将在下面详细阐述。

PM 最大的担心

虽然一些 PM 好像比其他人更理性、见多识广、可信赖，或有经验，但是所有 PM 都对项目有相同的关注。最大的担心如下所介绍。

估算

当 PM 接到的估算允许 20%、50%，或甚至 100% 的错误差数时，他们会对架构师感到失望。的确，许多行业已经达到了一个状态，在这种状态中，可能只根据标准术语、高层范围，和行业生产力量化、估算，并计划项目 —— 而 PM 可能非常期望在软件开发中也一样。然而，这可能对 IT 期望太多了，从框架和平台到方法和工具中的每件事都是处于动态转变中，为了估算充分的准确性，需要彻底了解需求。

在今天的软件行业中，不能估计用适当的准确性进行大量工作，除非源于详细的、具体方法的结构化的需求 [4] 并且使用与前面成功地完成的项目相关的生产力比率，由差不多相同的团队（研究相同的技术）交付。架构师进行的估算常常与未结构化的需求（不足够好）相关，由实际的类似的过去的解决方案改编而来（坏的），或者根据从项目团队中获得的承诺（甚至更糟）。

预算和成本

作为组织和项目团队之间的代理，PM 经常陷入要求和现实的困境中。这种隔阂常常显露出的一个区域是专用的资源和估算的成本之间的差异。在大多数情况下，问题归结为组织远在解决方案需求收集之前就分配其预算了，更不用提很好地了解了。事实上，项目团队被任命了解在这些情况下可以合理地构建出什么。这令 PM 希望架构师在项目开始之前所进行的估算可以成为现实。

方法

项目的成功有赖于是否选择并遵照项目方法。与建筑或生产行业相对比，软件项目可以选择许多风格和味道的方法，从非常形式的，到非常敏捷的。PM 经常不开始选择项目的方法，但其适当的执行几乎总是 PM 的职责。因此，当决定要使用的项目方法时，PM 不得不注重实效且协作。

信任

由于工作的特性，大多数项目经理不能客观地判断架构和设计决策。他们必须依赖于团队中的某个人来进行这些关键的决策， —— 通常是架构师或领导的开发人员。不意外的是每个项目经理都希望它们的关系无暇地进行。用可交付件帮助项目经理的架构师应该了解 PM 的依赖关系的含义，并对此灵敏。

所有权和职责

在一些组织中，官僚主义和政治遮蔽了建设性的逻辑。如果项目团队和管理团队是有动机的，那就很好。在这种情况下，他们更可能选择“精益的”实现方法，将个人问题的职责实际地散布在团队中。然而，如果缺少职责的透明性，那么 PM 会拥有明显的所有权和职责，也许是基于 RACI（Responsible Accountable Consulted Informed）模型的。与架构师和项目发起人之间的可信赖关系是良好的开端，但不能取代明确划分的职责。清晰的职责结构是项目经理的安全网，这也向项目团队的其他成员提供了透明性。

对于 RUP 的普遍误解

在与 PM 的经常的对话中，我听到了关于在 RUP 项目上应用项目管理任务的不确定性和犹豫。令我惊讶的是大部分人缺乏对 RUP 概念和原则的了解。每个人通常会快速地说出 RUP 是迭代的过程，然而，大部分 PM 没有完全了解并理解应用 RUP 所带来的必要质量和实际的好处。下面讨论我遇到的最大的误解 —— 以及我对其的分解。

误解：RUP 是 PMBOK 标准的备选

令人悲伤的是，RUP 常常被认为与项目管理标准相竞争，比如 PMBOK。也许这种误解源于 RUP 的定义“在开发组织中提供分配任务和职责的规程化的方法” —— 看上去是项目管理任务。这个定义即没有代表性也非常令人误解。

尽管 RUP 将项目管理列为其九个核心规程之一（参见下面的图 2），但是使用 RUP 的组织仍旧得益于使用固定的项目管理框架。RUP 项目管理规程详细描述 PM 方面的选择，这些方面与活动的计划及任务的执行，特别涉及迭代计划，相关。不像 PMBOK 那样，RUP 不将项目管理作为端到端的过程。RUP 还完全地忽略了一些与项目管理相关的重要活动，包括人员管理、资源计划和估算、扩大，和联系管理。

误解：RUP 只关于用例

无疑的是用例分析技术对于 RUP 是必要的，因为它支持 RUP 的关键原则之一 —— 减少风险的，迭代的实现。然而，将用例建模和分析等同于 RUP 是错误的，因为 RUP 允许其他的标识和技术，只要它们符合迭代生命周期中 RUP 的基本原则。用例分析技术特别有助于描述交互密集的软件应用程序，但是可能在其他解决方案或应用环境中没那么有用，例如当系统用户和系统之间的通信最小时，或者当不需要重新获取流时，例如在 Commercial Off-the-Shelf（COTS）实现过程中。软件开发范围之外的用例的应用可能也是可行的，但是应用 RUP 作为最佳实践的过程框架和平台可能不错。

前面已经说过了，RUP 不仅是管理用例的容器，而且是可以用于迭代的及增量的项目交付的可定制的过程框架。在 IBM Rational Method Composer 支持的更广的企业组织方法环境中，RUP 引发的活动，以及来自其他方法和标准的活动可能用于装配适用于组织需求的自定义过程。

误解：RUP 令注意力从项目管理上移开了

由于既定的项目责任和理论的监督职责，项目经理的角色常被认为是强大的角色。虽然在十分专业的软件开发环境中，适当的管理授权对于任何项目的成功是至关重要的，但是比起运输或大量制造的项目来说，管理的成功更对多个个人的专业技能要求多，因此在软件项目中应该对 PM 角色区别对待。RUP 不是项目管理过程，并且软件开发不是“命令和控制”环境。在 RUP 中，规程扮演者平衡的角色。

项目管理在 RUP 中扮演着关键角色，RUP 从 PMBOK 中得到 PM 规程。在参考的 RUP 生命周期中，项目管理活动在来自任意其他规程的活动之前开始。事实上，如图 2 所示，这些活动甚至在正式的 RUP 项目开始之前就可能开始了（见下面）。考虑到一些警告和需求驱动的范围，PMBOK 可以用作设置 RUP 迭代的固定过程，如图 1 所示。

图 1：从 PMBOK 延伸来的 RUP PM 规程

重要的是，RUP 不涉及官僚主义和政治 [2]，因此当项目管理过程没有用作“cover up”，“must have”，或“go，go”命令序列，而是组织并指导专业团队时，RUP 明确地帮助将注意力锁定在最重要的事情上。

然而，RUP 是不是问题的最佳解决方案是不同的问题。一些组织如此远离它们对 PM 标准的理解和应用，以至于我会问它们是否应该立即着手 SDLC 方法，例如 RUP 来改善它们的业务。相反，要赶上行业，它们可能考虑利用结构化的企业架构框架（例如，Zachman Framework）屏蔽它们现有的过程、系统，和方法。这可能令它们更好地了解并编写 IT 架构的当前状态，并且可以之后遵照其进行通用标识的采用，例如 UML，和最终的 SDLC 过程，如 RUP [5]。

误解：RUP 比瀑布方法更复杂

如果可以在实际中像理论中那样有效，也许瀑布方法会比 RUP 表示更简单的管理过程，主要因为没有采用重复的迭代计划和管理。然而，这只是理论上的。

举例来说，一般在工程中，特别是在软件开发中，没有人能够确保原始的设计，以及实现进度将长期完好，共不用提直到项目结束。事实上，通过许多项目已经证明了反面。增量的细化是工程中固有的，不像建筑或制造业一样，原始的设计没机会长期存活，而行业动力增加了额外的易变性。

另一个错误的假设是用“大爆炸”方法可以有效地处理任何复杂性。通过实验（科学上的）已经证实，管理增加的复杂度需要指数上升的工作量，这反过来导致需要额外的时间和更高的技能。相反，RUP 已经形式化为，通过将活动分为可管理的但重要的块来减少复杂度，每一块对项目涉众有一个表面值，并且每一块都实现了对用户需求的增量变更。拥有多个“伪项目”，以及总体的迭代方法，被视为更加强的项目管理过程。虽然它更加强，但是还是更可靠的，并且因此是较便宜的实现方法。在实际中，迭代的方法通常增加工程团队的可信度，并且减少项目的成本。

迭代环境中的项目管理被广泛认为是专业技能，这依赖于对增量的设计原则，需求工程，和风险管理基础的很好的理解。像 PMBOK 的项目管理标准慢慢地围绕着软件工程的增加的特性，并且调整它们的活动和规则来考虑迭代管理的远景。而 RUP 试图帮助管理项目风险，提倡早期的干预和基于需求的项目计划，尽管似乎需要更多的项目管理工作，但这可以帮助交付具有较少风险的优秀的结果。

误解：RUP 没有提供明显的进入或退出标准

一些项目经理不清楚的是（以我的观察，其他经理也是）RUP 项目什么时候开始，以及较次要的，RUP 项目如何结束。PM 经常问到，在 RUP 生命周期中，PMBOK 初始活动，例如用战略目标连接范围的活动和保护项目基金的活动，是否发生。

值得注意的是（再次）RUP 是解决方案实现方法，它不涉及为具体的商业问题开发解决方案的清楚地表达的需求。它用于处理在所选的组织区域中工作的所选的用户组的需求，这些用户一般只利用整体商业过程的有限部分。因此，项目经理经常在 RUP 中寻找的活动存在于 RUP 之外，然而，组织通常在 RUP 项目的初始阶段中执行一些活动，通常作为商业分析规程的一部分。这种类型的架构计划可能被认为是企业架构“反模式”，并且还与 PMBOK 冲突，它期望接收这样的分析作为在初始过程中执行的决策制定过程的输入（参见图 2）。

图 2：RUP、PMBOK和企业规程（Enterprise disciplines）

如今，许多组织仍旧没有能够通过将项目实现为所实现的解决方案的特性和组件，准确地追踪战略决策的企业架构团队。由像 The Open Group Architecture Framework（TOGAF）和 Catalyst 这样的框架支持的企业架构（Enterprise Architecture，EA）领域只会慢慢地在软件行业中被采用。在某种程度上由于 EA 框架相对低的采用率，而且由于围绕它们的目的的行业争议，EA 框架不能充分地描述从企业架构到解决方案设计的转变。项目组合管理（Portfolio Management）和变更管理（Change Management）过程和工具（它们是对各种管理难题的管理响应）不完全支持基于架构考虑的决策制定。

Rational Method Composer，作为根据完全的企业范围的生命周期过程的指导扩展 RUP 的方法，试图处理一些局限性，提供丰富的程序上的和信息的指南，可以有选择地利用这些指南创建支持方法阶段转变的裁剪过的过程。在 Rational Method Composer 中，存在同化商业目标的指南和商业架构分析（TOGAF，企业统一过程（Enterprise Unified Process，EUP），及其它）的结果，以及项目涉众的请求和使用需求（RUP，特性推动的开发（feature-driven development，FDD），Scrum）、资源管理（PMBOK），和现有的系统架构（Zachman）。参考过程用于最流行的企业治理模型（举例来说，Department of Defense Architecture Framework（DoDAF）或 Capability Maturity Model Integration（CMMI®）），解决方案架构和实现模式（举例来说，面向服务的体系结构（service-oriented architecture，SOA），模型驱动的系统开发（Model-Driven Systems Development，MDSD）和 COTS），并且适用于任意规模的（使 RUP 分别适合于小/中/大型项目）。实现行业领先的过程的定制插件的数量在在增加（最近对于 TOGAF）。

误解：RUP 不能进行估算

许多项目经理抱怨 RUP 不生成估计值。这好像是正确的。RUP 是既不指导也不促进任何具体估算技术的过程框架，然而，他包含一些关于在哪如何估算的有用的指示。

早期的 RUP 版本及其缺少估算指南。这随着 Rational Method Composer 的兴起以及许多估算模型 [3] 的成熟而改变了。在 Rational Method Composer 中，估算用两个过程内容表示，它可以包含于随需的定制过程中，以及作为瞄准不同项目排列的参考过程的一部分（举例来说，用于维护的 RUP 和用于资产开发的 RUP）。可执行的引擎也以许多定制的 Rational Method Composer 插件的形式出现，例如 Quantitative Software Management（QSM） Measurement 和 Estimation 插件。后面的插件定为在过程中关键的里程碑处，以及随需调用，从而进行估算。该插件允许利用环境、过程，和项目量度的极度的参数化。

目前，核心的 RUP 包含一个库，该库含有对于功能点估算的指南，以及用例和宽范围的 DELPHI 技术。QSM 估算插件实现了精炼的 Putnam Lifecycle Model 并且接受功能计数（function count，FC）或软件代码行（software lines of code，SLOC）输入。不幸的是，Rational Method Composer 内容没有采用基于经验的且面向学习的方法，并且大规模地忽略了所有其他的技术，然而，这些技术可能仍旧在使用。

重点是 Rational Method Composer 对待估算与对待其他技术和最佳实践的方式相同，例如用力分析或单元测试。它迫使过程工程师和项目经理将估算认为是在最有意义的地方执行的可选的技术（然而重要），或者在特别的基础上，作为交付过程的预定义部分。

误解：RUP 没有审计追踪

类似于项目管理规程，受到其自己的标准和最佳实践治理，例如 PMBOK 和 Projects in Controlled Environments（PRINCE2），因此是审计实践。在核心的 RUP 中，这是配置和变更管理规程的一部分。像项目管理一样，变更管理活动在过程早期就开始了。它们包含配置管理、变更请求管理，和状态及度量，它们都可能直接引起审计活动。

对于此问题的部分理由是在项目有利于属于需求、分析和设计，及实现规程的活动的过程中经常忽视配置和变更管理任务，因为那些被认为对解决方案的交付更重要。对此，目光短浅的项目和组织最终要付出重大代价。因此，这取决于项目经理确保来自所有规程的活动都及时切有效的运行。RUP 不缺乏关于什么时候需要完成什么的指导。

误解：RUP 生命周期是基于阶段的

忘记迭代 —— 我见到的大部分项目将 RUP 用作胶棒，很少超出定义阶段并使用用例来描述前端和后端的交互。

要拥有多个项目迭代，每一个都要交付产品版本，这对于 PM 来说是很难做出的决策，并且计划它们是 PM 工作中最挑战的部分之一。促使适当的迭代要用灵活性和信赖，以及主题领域和方法经验。然而，阶段似乎更容易理解，因为它们提供清晰的桶，PM 可以将任务放进去。在 RUP 中，每个阶段都结束于定义良好的主要里程碑处 —— 参考架构的基石，并且不论项目大小、类型，或复杂度，对于所有 RUP 项目来说都是一样的。然而结束于次要里程碑的迭代可能在项目与项目之间都不同。

里程碑允许项目经理“同步注视”其技术团队，并且向上司交付重要的更新。重要的是，它们与最关键的工件的交付一致，因此可以并且必须用于构建项目计划并作出“去/不去”的项目决策。

大部分主要的 RUP 里程碑大部分时间都存在于单个的迭代中，它们是：

生命周期目标
生命周期架构
初始的操作功能
产品版本

次要（但不是极其次要）的里程碑与主要的产品版本的交付相一致。

迭代的概念无疑地对于作为过程框架的 RUP 来说比阶段的概念更重要。后者经常令人，包括 PM，想到精化阶段的需求获取、构建阶段的开发，和产品化阶段的部署，比起 RUP 这更令人想起瀑布方法。不幸的是 RUP 阶段感觉好像是从建筑行业的构建开发生命周期模型中推出来的。该行业的普遍过程模型本质上是顺序的，而主要的工程模型是循环的 [6]。

误解：RUP 一定被映射到 PMBOK 上

进行 RUP 和 PMBOK 之间的映射不是必须的，然而，如果在项目过程中联合使用一些标准的话，就需要某种形式的映射。在高层次上，这种映射十分直接，但在实际中，每个项目都采用稍微不同的模型。应该问的第一个问题是这两个标准中哪个应该用做基线。我强烈推荐 RUP，正如 PMBOK 通常作为固定的项目标准。理由是 RUP 代表更分立且更专业的软件工程领域，而 PMBOK 是基本上不分行业的项目管理方法。当创造并裁剪好定制的方法之后，基于 RUP 的且涉及 PMBOK 的交付过程可以作为内行的项目方法指南，这不太可能成为其他方面的东西。

如果要进行映射工作，那么只应该着手于满足 PM 愿望的细节的程度。一些项目经理倾向于只要映射个别的任务和工件。我建议有关生命周期元素的映射原则的协议就足够了。坚持做 RUP 的项目计划建议会是更好的时间投入。下表总结了来自 RUP 的生命周期元素和 PMBOK 标准之间的映射。

表 1：匹配 RUP 和 PMBOK 元素

RUP	PMBOK
阶段	阶段
*主要里程碑*	里程碑
迭代	项目
*次要里程碑*	里程碑
规程	知识域
活动	过程组
*工作产品（工件，可交付件）*	可交付件
任务	过程

当使用混合的方式时，工件冲突和添加的冗余正好是过程工程团队或项目团队将要面对的一些潜在挑战。一个很好的实例是 PMBOK Project Charter 可交付件，像一些 PM 所指出的，在 RUP 中被 Business Case and Vision 工件“替代”。虽然混合的方法可能提倡混合使用来自两个标准的工件，但是出于支持可溯性的原因我强烈建议维护所有的 RUP 工件，而可以在一个个案例的基础上添加并由 RUP 工件导出 PMBOK 工件。

还导致 PM 的痛苦的事情是 RUP 允许一些其自己的工件，例如 Software Architecture Document，在项目阶段和迭代中演进，并且比与 PMBOK 相一致的时间更长的时间内处于部分完成的状态。重要的是要强调，RUP 限制工件不确定地演进，并且使用严格的原则和标准让其工件通过里程碑。最近 PMBOK 规范也通过应用“发展的精化阶段”的原则，考虑了增量的方法。

误解：RUP 是“现成”过程

像许多其他的 IT 项目参与者一样，项目经理经常把 RUP 认为是单个现成的过程。也许这种感觉源于其发展的早期，就是 RUP 是单独的过程，涉及小范围项目（主要是“绿屏”软件开发项目）并且缺少关于项目规模的足够灵活性（倾向于将所有项目当作大型的来对待）的时候。在那个时候，RUP 还缺乏足够的叙述性的指导和定制能力。尽管在很久以前这些不足就被解决了，但是将 RUP 作为仪式的且呆板的过程的看法仍旧存在。

由于 Rational Method Composer 的引入，情况发生了重大的改变。后面的 RUP 版本包含许多根据规模的分类（并且根据所涉及的仪式的量），包括“小型项目的 RUP”，“中型项目的 RUP”，和“大型项目的 RUP”。可以结合基础 RUP 裁剪专门的“插件”，例如“RUP for COTS”和“RUP for Business Modeling”，为了创建专门的适当规模的交付过程。除了现成的规范，可以根据组织内部开发的指导，以及其他方法、框架，和最佳实践，例如 PMBOK 或 Information Technology Infrastructure Library（ITIL®），还通过 RMC 插件调整定制的过程。

误解：RUP 缺少“启动活动”

PM 经常期望 RUP 辅助他们的管理任务，例如获得资金批准或保护来自高级管理层的“补偿购入”。沿着这些思路，许多 PM 想要看到 RUP 初始阶段之间加上照顾这些问题的额外时期。然而，这种控制 RUP 生命周期的方法会违背其一些原则。

如果用来扩展 RUP 初始阶段，那么这些活动将约束项目资源，这违背了 RUP 的一致性和过程有效性规则。当不考虑基于需求的根据而做出重要的项目决策时，要么证明是完全肤浅的，要么交付有缺陷或不完全的解决方案。准确的项目计划只可能根据结构化的需求来执行，这一般通过精化阶段得出。

如果目标是保证更多的时间用于商业分析或政治控制，那么用 RUP 没什么用。也许，在 EA 领域中可以找到某种解决方法。EA 的要求比 RUP 的更广泛，并且 Rational Method Composer 中有它的指导，用于将企业愿景、商业案例和其它计划文档中包含的远景目标和商业方法转换为商业技术规范和解决方案提案。EA 方法包含对于企业过程和结构分析、目标和范围识别、资源估算、架构分析、解决方案确定及优先级化，和实现方法选择的指导。更多潜在的辅助存在于项目组合管理的领域中。在进行着连续的项目组合管理过程的情况下，很自然的是项目选择和一般的检查都会是循环的功能，因而去掉对解决方案实现方法的任何偏见。

这些方法可能需要对组织中的项目管理的新观点，也许是企业项目经理角色的形式。我接下来将讨论这种可能性。

企业 PM：酝酿中的故事？

对于组织来说，设立企业 PM 角色值得吗？如果将企业的演进预想为单独长期的过程 —— TOGAF 和其它 EA 实现框架利用的东西，那么可能值得。

当然，将 EA 实现映射为一个或多个项目会要求包含已知项目中完整的 EA 生命周期，或者一部分生命周期。虽然前者的方法是吸引人的，但不好，因为这可能导致非常长的项目。尽管通过减少与项目初始和结束相关的工作可能减少实现活动的官僚主义负担，但是事实是可能花费数年来执行项目，这不实际（并且违背提倡有限项目的 RUP 的推荐）。

因此，更可取的是在 EA 实现路径旁设立许多项目，项目的生命更合理地分布。举例来说，这些项目可能交迭一个或一些 EA 实现阶段。它们既可以同时也可以交迭进行。举一个 TOGAF ADM 的实例，将三个不同的企业项目设置为联合的远景（阶段 A），开发架构（阶段 B 到 F），并且提供解决方的案实现治理和变更管理（阶段 G 到 H）。

现在由组织决定是否需要专门的企业 PM 来处理企业的事务，或者其成为企业架构师的附加职责 [1]。然后由企业 PM（或架构师）提出一个最佳的解决方案项目集合来实现 EA。这个决策必须考虑一些因素，例如组织的变更诱因，它的交付能力，在执行类似项目时组织原来的生产力，以及历史上的或预期的 EA 实现循环的持续时间。问题的历史暗示，企业架构师有其他要担心的事情（像架构问题），这可能形成了很难逾越的职责缝隙。

注释

计划是控制多个项目的项目。

回页首

注释和参考文献

作者想要感谢 Jas Madhur、Mark Arshawsky，和 Francis Pring-Mill 的颇有见解的批注。在此表达的看法是那些作者的，不一定符合 Sierra Systems Inc 的。

[1] 阅读关于 TOGAF 和 RUP 一起使用的我的 Rational Edge 文章，了解更多关于企业架构和解决方案实现之间的一致性的更多内容：TOGAF 或非 TOGAF：在 RUP 之上扩展企业架构

[2] 这篇 Philippe Kruchten 写的极好的论文谈论了对于 PM 来说，从瀑布过渡到迭代开发之间的挑战：From Waterfall to Iterative Development

[3] 可以在此了解到一些关于企业估算的有用模式：企业范围的软件评估，第 1 部分

[4] 来自 The Rational Edge 的我们的文章介绍了更多关于结构化的需求的内容：企业范围的软件评估，第 2 部分

[5] 要了解相关的信息，请参见我的关于一起使用 Zachman、RUP 和 UML 的 Rational Edge 文章：UML、RUP 和 Zachman 框架：完美结合

[6] 这里有另一个关于预测迭代项目的有趣内容。

[7] 在此可以找到在对 PMBOK 和 RUP 之间进行形式映射的过程中用到的模板：Software Project Management -- A Mapping between RUP and the PMBOK

[8] 要了解关于将 PMBOK 映射为 RUP 的思想和分析，请访问：Standards, compliance, and Rational Unified Process, Part I: Integrating RUP and the PMBOK

[9] 还要咨询 Rational Method Composer 内容数据库，以获得指导和有用的建议。

参与论坛讨论。
您可以参阅本文在 develperWorks 全球网站上的英文原文。
现在开办了一个特别为 Rational Edge 的文章创办的新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击这里开始。
全球 Rational 用户组社区


		Vitalie Temnenco 是 Sierra Systems Inc. 的软件架构师，他在那里向 Sierra 的客户提供技术和方法咨询。之前，他是 Ontario（加拿大政府的 Workplace Safety and Insurance Board）的架构师，他在那里提供关于实现项目的架构指导，并且帮助团队接受 RUP 和企业架构（Enterprise Architecture）概念。他的经历包括为各种商业领域，例如银行业、金融、保险、零售，和电信，中的客户架构并构建解决方案，并且他教授用于商业和系统分析的 UML 和 RUP，并结合到新系统中。您可以通过 vit@umlconsulting.com 联系他。

敏捷实践报告：用于系统测试的模型

2008-11-14T21:11:00.001-08:00

级别：初级

Mary Ellen Kerr, 系统测试, IBM
Curt J. Rousse, 系统测试, IBM
Donna P. Dynes, 开发经理, IBM
Dave Booz, 开发经理, IBM

2008 年 6 月 16 日

许多公司将敏捷的开发实践作为提高产品的质量和及时交付产品的方法。如何在敏捷的开发环境中最佳地执行系统测试策略，是每个公司和团队都希望能回答的问题。

来自 The Rational Edge.

如我在本文中提到的，系统测试是在将软件产品交付给客户使用之前完成的最终产品测试。此测试一般在完成开发和功能验证测试之后进行。某些入口标准用来确定对于系统测试的代码准备状态（举例来说， 回归状态，缺陷后备，等等）。必须达到这些标准，从而正式地开始系统测试并要求结果。

在一般的系统测试中，目标是用类似客户的配置在高压下对系统进行类似客户的工作量（举例来说，多平台、多软件版本，等等）。 正式的系统测试执行包含压力、寿命期运行、内存泄漏分析、多应用程序、复杂且各种各样的拓扑、高可用性及中断测试、混合的版本测试、全平台测试、产品集成测试，及文档测试。

本文介绍了团队所采用的将一组系统测试子集作为敏捷开发环境的一部分，并与代码开发活动并行的方法。我们将展示出我们的方法可以交付更好的系统测试应用程序，让实验方法将包含与代码开发并行的系统测试子集的价值和效率最大化，并提高团队的沟通和技能。这些成功导致 （led） 了在完整的系统测试开始时改进了的完整的 软件验证团队（ SVT ） 的加速的时间，以及改进了的产品质量的预期好处。

在六个迭代中，系统测试核心团队与开发团队并行工作。这能够让传统的系统测试应用程序的子集的开发和执行在每个迭代的过程中执行。该并行导致了此处描述的各个方面的成功。

敏捷的过程实现模型

在开发的一年之后，使用现有的瀑布实践并交付开放的 alpha 和 beta，我们的项目转换了工具，并实现敏捷的开发模型。整个团队需要将敏捷的开发原则作为“现场实验”，从而满足特定客户的需求。第一个迭代是过渡的，通常着重于交付在瀑布开发模型下开发了几个月的代码。当第一个迭代开始时，整个团队包括大约五十五个人，包括设计人员、开发人员、测试人员、信息开发人员和客户交付团队。

迭代 1 用作过渡的迭代，用于完成已经处于开发中的可交付件。敏捷开发过渡适当地启动，并且带有对前一或两个迭代的适度的开发承诺。主要的焦点在于在团队和集成的过程之间构建并交流新的项目和人与人之间的文化，例如，并行的早期系统测试，这将会用于在新的环境中令团队成功。

九个系统测试人员（整个系统测试团队的子集）在先前的瀑布开发周期中兼职参与。在开发代码的过程中，他们关注构建技术技能、计划、测试案例开发，和应用程序单元测试。这样做，他们练就了项目所用的技术中的技能，但没有获得内行的经验。

当转变为敏捷开发时，九个系统测试人员中的五个全职参与项目。因此，在第一个迭代之前，系统测试团队已经了解了新技术，创建了测试应用程序，并且像团队一样一起工作。这些早期的测试及开发活动令敏捷周期的开始有更高的生产率。

系统测试团队参与的目的

五个系统测试人员面临的挑战是确保代码质量足以达到在任一已知的迭代中开发的功能的 beta 级交付。为了迎接这个挑战，他们决定在每个迭代中运行传统的系统测试应用程序开发和执行的子集，预期最终的迭代进行一组更复杂的具体客户的，基于场景的测试。系统测试团队与项目的高级架构师会面，并一起为了增强和执行选择一个现有的系统测试应用程序。然后，该应用程序将用于在迭代过程中的压力和寿命期运行，并且在最终的迭代里大量地使用。目的是在项目最终在世界范围内交付时，系统测试人员有限且同时的参与会为最终的完全的系统测试迭代建立起坚固的基础。

项目和迭代的时间线

迭代有六个星期之久。表 1 显示了一般的迭代规划，以及为每个星期计划的具体的系统测试活动。在迭代的第 1 周中，高级架构师提出建议的候选功能列表。该列表主要基于具体客户的需求，并且通过用例进行描述。该列表可在线访问，以便在迭代进行中，所有的团队成员都可以改进用例。每个团队成员都会审查候选的列表，并与团队成员和高级架构师一起讨论设计及问题，并且在周末提交在迭代结束时（是否）要交付的功能。每天举行一个小会。高级架构师每天都出席大部分小会议，并且在所有迭代过程中都与全部团队成员在一起。

如前面所提到的，最后的迭代计划着重于在开发迭代中不能实现的最终的缺陷清理和复杂的测试。为了提高稳定性，最后的迭代没有新的功能。六个迭代完成了。同时，在最后的迭代中，大量的开发人员需要加入系统测试团队成员中，通过提供对测试执行和调试的辅助来完成最终的迭代。其余的开发人员会处理缺陷。这意味着在较早的迭代中的开发阶段里，一些开发人员需要为了最后的迭代而培训系统测试的知识。

表 1：每个迭代的活动：开发和系统测试

周	开发	系统测试活动
1	开始设计团队承诺	决定并提出迭代承诺，包括：根据在迭代中交付的新功能，定义压力测试的测试应用程序的提高及选择。
2	开发/测试	与高级架构师一起审查测试应用程序设计的增强。开始应用程序增强的开发和单元测试。利用可用的驱动程序开始回归测试。
3-4	开发/测试审查开发/测试结果	继续应用程序增强的开发和单元测试，及回归测试。创建测试场景并准备必要配置的机器。开发/提高自动化脚本。
5	高优先级的缺陷，没有新的功能	压力运行新的功能。在连续的迭代中增加压力/负载。对新的功能驱动程序进行回归。打开缺陷，带补丁执行，提供追踪，并检验缺陷。培训开发人员加入 SVT 的工作。用额外的细节改进测试场景，并追踪进展。
6	审查系统测试结果打包演示了解的经验交付	继续与第 5 周同样的活动。参与演示的计划、准备及执行。提出系统测试结果。为所了解的经验提供输入。
每天	功能测试的回归	对当前的驱动程序进行回归。

回页首

成功

在此我们将开始讨论一些实现了的重要成功、遇到的挑战，及与敏捷的系统测试活动相关的对比的好处。让我们从成功开始讨论。

更健壮且更实际的系统测试应用程序

敏捷的开发周期从客户开始。为了了解商业目标、IT 策略、应用方向，和优先级，架构师经常和客户会见。系统测试团队分析迭代的测试用例，并根据作为外部客户的关键的用例的子集设计测试应用程序的增强。如果测试应用程序增强是大规模的，那么就在先前的迭代中开发那些增强，从而给测试应用程序的开发留出时间。如果可以快速地完成应用程序的增强，那么就在当前的迭代中开发它们。

在第 2 周中，系统测试团队向架构师提出应用程序的设计增强。这会形成向系统测试团队提供机会来结合架构师的建议的对话。它还向架构师提供他们没考虑过的系统测试的观点，而有时，这会导致产品设计的变更。由于系统测试团队与架构师和开发团队有密切的合作关系，所以系统测试人员对客户的需求的了解深入得多。

将小型的系统测试团队与开发活动并行令系统测试团队能够以增量的方式开发更健壮“类似客户的”测试应用程序。这是比历史上在瀑布开发周期中进行的更实际的方法，因为它允许系统测试团队参与可交付件的创建，而不是在短暂的时间内，被迫消耗，并测试大量可交付件。敏捷的开发周期允许系统测试团队扮演实际的客户，从应用程序设计到系统测试应用程序的编码和单元测试。

开发和系统测试团队之间更密切的交流

由敏捷开发实践的采用及系统测试活动的加入所带来的重大好处是，开发和系统测试团队之间通过参与每日的会议而进行的更频繁且更深入的交流。因此，系统测试团队可以洞察会影响测试计划和/或测试应用程序的当前的构建问题、最近发现的缺陷、设计修改等等。当系统测试人员报告在并行的系统测试中发现的问题时，小会议也给开发团队带来好处。每日的会议交流允许系统测试向整个观众简要地描述可能需要多个开发人员协作或了解的问题。最终，会议允许开发指出什么时候系统测试方法与当前的代码基础功能不一致。

开发和系统测试之间的密切交流的另一个重要好处是，当新的功能首次出现在一个构建中时，系统测试团队可以立即注意到。对可用功能的交流是至关重要的，因为每个迭代中只有三个星期是执行系统测试应用程序的设计、编码，和单元测试的。这是重要的，因为系统测试有时为该迭代并行地开发测试应用程序及产品功能。记住，系统测试会令对测试应用程序及单元测试的增强的改进非常快速。因为系统测试及时地收到了构建中存在所需功能的通知，所以他们能够尽可能快地执行应用程序测试。

架构师、开发人员，和系统测试人员之间的密切交流令整个团队得益于许多观点和建议，提高代码质量和完整性。

较深入的系统测试技能

在敏捷的开发周期中加入系统测试子集的另一个优点是它促进较深入的系统测试应用程序开发和测试技能。在发布周期的较早期，将这一较小的“核心”系统测试团队指派到项目中。敏捷的开发周期的迭代特性令系统测试团队以较小的且更容易消费的规模在较长的时间内理解产品。

贯穿迭代的系统测试的连续子集

在所有的迭代过程中都执行系统测试的子集，即使每个迭代的系统测试时间都是有限的。在测试过程中，使用各种自动化的技术来启用压力/负载测试、内存泄漏分析、数据完整性测试，和回归测试。压力/负载工具允许系统测试在指定的持续时间内在模拟的客户量下运行测试应用程序。执行脚本获取浏览器动作（这些会被回放），允许执行自动的实施。这些脚本还允许生成随机的数据，这模拟了不同的客户交互。相关的配置脚本允许测试人员为每次执行指定所期望的持续时间和模拟客户的数量。他们通过定期查看产品日志，以及压力工具的日志来监控运行进展。压力工具还生成统计，这提供了潜在的问题及意外活动的指示。压力工具在第一个迭代之后的每个测试运行中都会用到。

伴随代码稳定性，及进行寿命期测试运行的能力的成功导致了以第三个迭代开始的迭代完成时，增加内存泄漏分析。在每个测试之前，系统测试人员配置许多产品参数来允许在测试过程中收集内存泄漏分析信息。在每次运行之后，他们会将运行的日志输入到内存泄漏分析工具中。工具会生成一组图，查看在运行过程中的内存使用，并检查内存泄漏的指示。如果发现了内存泄漏，那么会打开并追踪故障报告。一旦最终的执行在无问题的情况下完成，那么测试人员就会在测试追踪工具的完成记录中加入信息，指示最终的内存泄漏分析的结果。

数据完整性测试也在一些测试场景中进行，从而确保系统测试的子集的执行。测试应用程序严重依赖于 IBM® DB2® 来进行数据持久化。应用程序包含一组更新应用程序数据库中相同表的事务工作负载。这些事务工作负载是同时运行的，因此推动负载并有意地创建数据库争用。目的在于强迫事务回滚，这样系统测试人员可以确保成功地完成恢复。当试图对已上锁的记录进行更新时，事务回滚并在稍后重新执行。在执行完成时，所有的数据库活动都完成了，并且不得不使所有的事务都一致。测试应用程序中嵌入了数据库一致性检查。应用程序持久化了的数据在其使用的一组表中有相关的值。在执行的末尾，测试人员运行一组额外的测试来检验每个应用程序的表中的数据与彼此一致。

回归测试也用于以第二个迭代开始的迭代开发中。通过在当前的构建上为当前的迭代运行先前的系统测试应用程序的迭代版本，在每个迭代执行迭代的回归测试。随着我们进入后面的迭代，这些测试执行快速地成为早期的同时的测试执行的集合。这令在迭代过程中确定并处理回归缺陷，而不是像瀑布模型那样，在测试的结尾。

因此，即使敏捷的版本周期包含一系列相关的短迭代，仍旧能够执行系统测试的子集。由于团队利用大量的自动化功能，因此压力/负载测试、内存泄漏分析、数据完整性测试，和回归测试都将执行。这些类型的测试提供了模拟的客户环境中的产品代码稳定性置信度。

在产品周期早期除去的缺陷

因为在迭代过程中，系统测试执行回归、压力，和持续时间执行，所以在缺陷注入不久就被确定并除去了。由于产品代码在开发人员心里是新写的，所以系统测试可以收到来自开发的立即的修复。在敏捷的环境中，系统测试更容易检验修补，由于缺陷周转时间较快，并且由于准确的测试环境仍旧适当。因为工作在相同时间的相同用例上，开发人员和系统测试人员有相同的优先权，由此开发人员和系统测试人员之间的协作较好。这便于缺陷更快地确定、修复，及检验。

较早的迭代测试初始且较基本的产品功能。此次，系统测试应用程序还是基本且较简单的，然而，为了找到缺陷，能够在特定压力级别和持续时间内运行。后续的迭代引入了增加的产品功能和更复杂的产品配置。系统测试应用程序的功能和复杂度也增加了。在后继的迭代中，压力的等级和测试持续时间增加了。一般，在这些后继的迭代中可以找到更复杂的缺陷，但仍旧非常接近于注入产品的时间。

一般来说，在敏捷的开发周期中对系统测试缺陷的开发关注较多。这导致了较早地检测出缺陷，并且更快地缺陷修复周转时间。

过程演进

敏捷开发本身虑及了连续的增强。在迭代的末尾有一个“了解到的经验”的会话，让所有的参与者确定问题区域，并建议整体的改进和效率。

敏捷模型的一个关键特征是开发过程应该演进。这对所有与产品交付件相关的团队来说都是正确的，包括系统测试。在每个迭代中都实现了关于如何提高生产力的洞察。每个团队被要求提供他们关于了解到什么及可以提高什么的想法。整个团队开会并讨论每一个痛处或成功点。在该对话中，确定出额外的改进，从在线存储库中获得，并集成到下一个迭代中。

与系统测试相关的过程演进的一个具体实例发生在第一个迭代期间，在该迭代中，系统测试团队形式化一个用于测试追踪的过程。在过去，测试追踪工具用于定义系统测试场景及编档测试执行结果。在迭代 1 中，系统测试团队为那些测试场景定义模板，并且创建公共的配置文档。这些配置文档允许系统测试团队详述由一个公共的文档源安装并执行公告的系统测试规程所必要的步骤。这个独立的定义令个别的测试人员能够避免创建并维护重复的文档。所有相关的测试场景都指向公共的文档。

系统测试团队如何增量地改进他们的过程的另一个实例出现在内存泄漏分析被引入到迭代 3 中时，而不是等到最后的，只进行系统测试的迭代。如前面提到的，该变更是可能的，由于代码的稳定性。公共的配置文档中加入了必要的工具和安装说明，这是每个计划的测试场景所参考的。同样，测试完成的详情包括每次运行后的内存泄漏分析的结果。

系统测试团队定义约定及编写良好的过程，来帮助实现可重复的且一致的测试。在开始项目的测试工作之前，许多改进都还不为人知或未定义。一些想法基于“发现”，而其他的纯粹来源于对随后迭代的生产力提高的期望。“所了解的经验”的频率及对模型灵活性的关注令整个团队避免较早的痛处，提高效率，并试用解决方案。

停船识别

从迭代 3 开始，系统测试团队推动停船场景的识别。从迭代 4 开始，在迭代承诺会议过程中，系统测试团队的场景分类为停船货非停船。为了成功地完成迭代，所有的停船场景必须在没有缺陷或补丁的情况下成功运行。停船测试场景一般是那些在前面的迭代执行，并作为归回场景转到当前迭代的测试案例。这些测试场景还组合形成了一组同时执行的测试。比起较早的迭代，这些组合的测试一般在较高的负载下执行，并且还至少执行二十四小时。

非停船的测试场景一般基于需要在后来的迭代中交付的客户需求，但基于当前迭代中正在开发的功能。这允许在功能验证完成之后不久执行最初的系统测试和问题确定。敏捷环境中的这种附加的灵活性令复杂的问题得以确定、隔离、追踪、修补，并在跨多个迭代的时间段里在系统测试环境中执行。

系统测试团队在测试追踪工具中区别停船和非停船测试场景。在迭代的第 1 周中的承诺会议上，高级架构师指导将每个承诺划分为停船和非停船的。那些分类记录于在线承诺页上，并随后当为每个承诺创建测试执行记录时使用。对于停船场景，测试阶段有在迭代的系统测试周期末尾的完成日期，发生在第 5 和 6 周。非停船场景遍及多个迭代，但在最终迭代中，所有余下的非停船场景都成为停船场景。通过允许当未预期的问题出现时应用附加的资源，以较低优先级的测试场景为代价，测试场景之间的差别帮助管理风险。这令迭代交付按计划完成，但需要对非停船场景后备的小心管理。

回页首

挑战

以下是在敏捷系统测试活动中面临的一些最重要的挑战。

短迭代

系统测试场景的回归测试发生在第 2 到 6 的迭代周中。在第 2 到 4 周中，系统测试还需要提高并单元测试系统测试应用程序，以便它可以用于第 5 和 6 周中的新功能的测试。

对于新功能的系统测试场景的执行只发生在第 5 和 6 周。这种时间长度证明，当在后面的迭代中系统测试运行更加复杂时，在这种“现场试验”过程中，对场景的子集进行测试是种挑战。举例来说，在测试需要更复杂的拓扑，以及比三天更长的持续时间，和/或伴随中断和故障测试的复杂工作负载的情况下，在分配的时间内包含这些复杂的场景是困难的。这些较复杂的场景趋于暴露出较困难的故障，它们更难调试，并且有时是间歇的。用追踪重新创建这些类型的缺陷是耗费时间的，因为我们应用补丁并检验集成到驱动程序中的修复。在分配给少量测试人员的情况下，这是非常困难的。因此，一些较复杂的场景和缺陷需要跨迭代。

即使只有一个应用程序用于应用程序开发和场景执行，应用程序开发还是耗费迭代中的大量时间。通过为了对应用程序进行一些功能增强而扩展到两个迭代，在一个迭代进行应用程序开发而当需要时在以后的迭代中执行场景，来部分地减少浪费。

另一个挑战是迭代结果审查和演示的计时。在第 6 周，系统测试团队向整个团队提出他们的迭代结果。在一些迭代中，最后一周没有完成测试，从而提出结果，并且系统测试结果的提出需要移动到后继迭代的第 1 周。同样，有时系统测试团队负责一部分向产品管理层的演示，从而显示迭代的可交付件。这些演示需要大量的准备，而在后面的迭代中系统测试团队的参与更困难。

另一个使得第 5 和 6 周非常具有挑战的因素是系统测试需要培训开发人员进行系统测试的执行，以便那些开发人员在后面的迭代中可以辅助系统测试。然而，这需要有经验的系统测试人员来指导那些在特殊的迭代中分派到系统测试的开发人员，增加完成计划的系统测试承诺的难度。由于这涉及对于不熟悉系统测试的开发人员大约 1-2 周的学习曲线，所以如果将同样的开发人员分派到多个连续迭代的系统测试中才可以实现系统测试的好处，这不总是可能的。

第一个敏捷开发经验

对于大部分团队成员来说，该项目是敏捷开发中的首次经历，对于该项目，开发和系统测试活动的并行对团队的每个人都是陌生的。系统测试团队的五个人比预期超时工作。在项目过程中，每个人，包括系统测试团队成员，都了解如何估量每个迭代的设计、开发，和测试任务。过度承诺或错误的估计对系统测试团队，以及整个团队的其他成员产生了压力。

用例

在敏捷的周期早期需要定义并实现跨迭代的用例的标准化命名约定。为了确保系统测试团队不忘记任何用例，并且让所有团队都能够清楚地辨别每个用例，拥有一贯地使用的（从第一个迭代到最后的迭代）标准化的“用例标识符”是有帮助的。

模板用于一贯地编制跨整个团队的用例。虽然用例的概念对整个团队不是全新的，但是根据外部的客户价值陈述用例对大部分团队成员来说是陌生的。因此，由于迭代末尾的“所了解的经验的”反馈（其中包含来自整个团队的反馈，包括客户交付团队），用例描述的模板和用词不断地变化。

在项目过程中，客户文档是格式化的用例文档。由于系统测试不能得到标准的外部客户级文档，因此系统测试团队不能测试这类客户文档。如果该标准的产品文档在未来生成，那么它需要额外的测试工作。

回页首

好处

以下是与敏捷的系统测试工作相关的具体好处。

较好的系统测试应用程序

由于在许多迭代过程中一系列的连续增强，所开发的系统测试应用程序拥有较高的质量。当进行所有这些改进时，应用程序的许多其他方面也改进了，包括执行的验证、提供的日志，及异常处理。由于在许多月内进行开发，所以测试应用程序更加健壮，这与在传统的，集中的测试准备阶段中开发的相反。

提高了的全部系统测试的加速时间

在敏捷的环境中，与开发密切合作的核心系统测试团队向开发组织提供了重大的潜在好处。核心团队可以为在产品发布之前在最终系统测试时的使用而生成系统测试应用程序、场景，和自动脚本的子集。与开发并行地创建并执行这些资料将帮助让较广大的系统测试团队生产的更快。

出于技能转移的立场，系统测试核心团队在适当的时候可以向较广大的系统测试团队介绍新的技术和版本内容。核心团队可以提出类似客户的应用程序设计，并向广大的团队演示应用程序，同时提供所开发的文档、已建立的开发联系的指示，因而提高全部系统测试迭代的加速时间。

在全部系统测试开始时的提高了的产品质量

因为系统测试核心团队在产品开发周期的早期执行系统测试的子集，所以在正式进入完全的系统测试时应该提高代码质量，这必定影响较广的系统测试团队的生产力。此外，利用参与早期系统测试活动的系统测试核心团队的发布周期（在其后，产品发布之前，进行集中的完全的系统测试）可以提供与传统的开发/测试方法相比，提高了的质量。注意写到此时，最终的系统测试迭代还没有开始。在开发迭代中，由于系统测试核心团队早期的测试，与压力相关的及内存泄漏缺陷的子集在正式的系统测试开始之前就被除掉了。

回页首

结束语

本文所讨论的项目是小型的。它包含大约五十五个人，包括经理、架构师、开发人员，和测试人员。有大约十二个不同的组分团队，包括致力于开源技术的团队、它们是作为技术功能基础的团队。组分团队在不同的地理位置，然而，每个团队的小型规模使它在项目中相当容易地采用敏捷的开发原则。利用瀑布方法的项目的前期当作是项目中使用的技术的培训。这些先前的技术培训令到敏捷概念的过渡更容易。团队没有额外的技术学习曲线的困难。

迭代 1 用作过渡迭代，用于完成已经在开发中，并作为敏捷项目而开始运作的可交付件。敏捷开发过渡适当地启动，并且带有对前两个迭代的适度的开发承诺。主要的焦点在于在团队和建立的过程之间构建人与人之间的文化，例如，并行的早期系统测试应用程序开发和执行，这将会用于在新的环境中令团队成功。根据此项目的结果，鼓励花费在从瀑布开发到敏捷开发的过渡阶段上的时间。

在六个迭代中，系统测试核心团队与开发团队并行工作。这令传统的系统测试应用程序的开发和执行的子集在每个迭代中都能够运行。这种并行导致了以下方面的成功：

跨多个迭代增量地构建更健壮且实际的系统测试应用程序。
开发、功能验证测试，和系统测试之间较密切的沟通使得大家听到了许多观点，并形成系统测试的执行。
项目中使用的技术和环境中较深入的技能。
在产品周期较早期除去一些系统测试缺陷。
每个迭代都进行过程或测试的改进。

学习

您可以参阅本文在 develperWorks 全球网站上的英文原文。
您可以参阅 Rational Edge 电子月刊中文版的其他文章。

讨论

参与论坛讨论。
已经专门为 Rational Edge 文章创建了一个新论坛，因此你现在可以共享你对本文或其它在当前问题或我们存档上的文章的想法。阅读你遍及世界的同事所阐述的言论，阐述你自己的讨论，或者加入进行中的讨论。点击这里开始。
全球 Rational 用户组社区

作者简介


		Mary Ellen Kerr 是 IBM WebSphere Application Server 系统测试人员，在 IBM 工作了二十五年。


		Curt J. Rousse 是 WebSphere Application Server 系统测试人员，在 IBM 工作了十三年。


		Donna P. Dynes 是 WebSphere Application Server 的开发经理，在 IBM 工作了二十六年。


		David Booz 是 IBM 一名高级技术人员，在操作系统和中间件方面有十九年的经验。

软件开发项目取得成功的策略：一种个人的观点

2008-11-14T21:03:00.000-08:00

级别：初级

Goran Begic, Senior IT Specialist, IBM

2006 年 2 月 15 日

来自 Rational Edge：一位经验丰富的软件开发专业人员提出了一份他个人的建议，并且描绘了一幅通过改进和提高开发过程从而使项目获得成功的良好习惯，它涉及到交流沟通、用例、测试和市场营销等方面。

在过去两年中，无论是从事内部的还是外部的软件开发项目，我都会遇到这样或那样的挑战，同样也会发现一些在不同项目中都普遍适用的良好习惯。既然我懂得了如何利用这些习惯来克服困难，于是我决定将其作一些梳理并记录下来，作为本文的提要。

这些笔记可以归纳为如下四条策略：

弥补缺乏面对面交流所带来的不便
撰写更好的用例
确保有效的测试
支持市场工作

这项别具风格的建议决不是包罗万象。我的目的并不是教授您如何构造软件，而是和您探讨一些对于项目成功与否至关重要的技术或非技术性的问题。有时，一个好项目和一个堪称经典的项目之间的差异就是由一些看起来无关紧要的因素造成的。我的建议所着眼的就是那些相对较小却很关键的部分，它们可以作为整个工程的代表。

弥补缺乏面对面交流所带来的不便

人人都知道项目成功最关键的因素就是良好的交流与沟通。这是一个相当大的题目，在此我仅就其中一个确实能使项目之间产生出好与坏差别的方面加以论述。

面对面交流的好处

整个团队能够在同处在一个地区是一件非常值得庆幸的事情。通常这种情况会发生在那些小规模的、刚刚起步的业务身上。几个理想坚定、雄心勃勃的人为共同的目标而奋斗，一同体验和经历着每一天中同样的细节。同样，一些更大规模的组织有效的使用灵活的方法在面对面交流的基础上建立它们的内部流程。当某一个团队同处在一座建筑物内时，其成员能够在午餐时、走廊内、下班后进行面对面的交流，这些非正式的会面通常比安排好日程的会议更具效率。我至今仍记得无数次这样的情形：当我在一个长时间的讨论之后从被写的满满当当的白板上面抄录下笔记之后，正是这些被大家分享观点和想法成为了新的方案的基础。

然而，业务的成功和事业的发展通常会使得将一个高水准的团队固定在同一个地点变得越来越不现实。由于并购、合作项目以及外包开发的出现，要求我们能够在不同时区、不同文化之间成功地进行交流和沟通。在这样一种情况下，什么才是我们最好的选择呢？

分布式环境下的交流的开展

第一个映入我们脑海的答案大概就是电子邮件了。我曾经觉得电子邮件确实是一种有效的沟通渠道，但它同时也是被滥用最甚的一种渠道。如果电子邮件的传送距离过长以至于人们没有时间去阅读它们，那还有什么用呢？根据我的经验，如果包含三条以上的信息，那么您就应当转而使用电话进行交流了。这个小小的规则帮助我节省了大量的时间，使得我不必去撰写那些关于Lotus Notes软件的无意义的文本。

此外，还有其他的一些沟通渠道，尽管它们并不能够取代面对面会议的亲密性，但它们确实能够提高一个团队的合作能力和理解能力：

项目主页。 在网络上建立一个主页，从而为项目领导者提供了一个极好的单向交流渠道（如果您使用wikis技术或者论坛/博客方式的话，也可以是双向的交流渠道）。主页上可以解释项目的具体内容是什么，确定所要达到的主要目标，以及介绍团队的成员。管理者同样可以应用这一页面来发布代码标准，“如何做”将帮助团队成员设置环境，凡此种种。
在线聊天。 这种交流形式在团队成员之间创建了一个虚拟的合作环境，营造了一种轻松的交流思想的气氛。显然的，通过即时消息系统随时向同事寻求帮助要比通过电话交流要有效率的多。例如，IBM的系统，Lotus Notes SameTime系统，与Lotus Notes地址录结合在一起，因此您可以轻易地在您的组织内部找到正确的连接，并且看到那个人是否已经登录到SameTime。如果您看到指示器显示“忙 ”，您就可以判断出此人同样也没有时间接听您的电话。SameTime同样允许您邀请多人一同聊天，因此说这是一种进行合作讨论并且立刻做出决定的非常好的方法，并且它省去了为进行一次正式会议而作的准备。

一些聊天程序还包括了其他一些有意思的功能，比如个性化可用性消息，为将来之用而保存副本的功能，等等。我之所以加亮了IBM SameTime是因为它提供了许多由于其与Lotus Notes电子邮件系统相结合而产生的附加功能。请记住，不同的聊天工具提供不同等级的安全性，并不是所有的聊天工具都能很好的适用于职业应用的。
缺陷跟踪系统。 这是另外一种有效的沟通渠道。每一个软件开发项目都必须能够处理功能增进的需求以及程序缺陷报告。一个有效的缺陷跟踪系统，例如IBM Rational ClearQuest，能够帮助开发团队规范化这些需求和报告。特别地，通过Rational ClearQuest和IBM Rational ClearCase结合而获得的统一变化管理（UCM）的能力，将允许您将缺陷记录和源代码联系起来，这将大大提高在日常事务上的交流质量。例如，如果对于一个不能正常工作的组件我需要得到帮助，我就可以找到该组件在缺陷跟踪数据库中的入口，并且查明该组件是否在执行进一步的工作，以及谁在执行那项工作。
“一杯咖啡。” 从另一个方面来说，每一种交流的工具都是人。当有人打电话给你仅仅是问候一下您最近在忙什么，特别是在您处在工作压力下的时候，难道这不是一件非常令人感到欣慰的事情么？尽管您的同事可能正处在地球的另一端，记得这些非正式的交谈对于巩固一个团队发挥着多么巨大的作用仍然是非常重要的。即使您使用的是最完善的管理和报告工具，有些时候与另一个人的交谈仍然是获得正确信息的唯一的方法。邀请您远方的同时共饮一杯咖啡如何？也许一个没有事先安排的电话会在一天工作结束之前的一小段时间内打来。请记住，如果您起初经常拨出这样的电话，那么您也将接到更多这样的电话。

回页首

撰写更好的用例

从某个角度来看，我们可以认为用例也是交流沟通的一种形式。但是，它却远远不仅仅如此，所以我在这里将其单独处理。

用例较之于其他系统设计技术有两个大的优点。首先，它们为每一个参与项目的人员提供了一个关于最终的用户需求的正确理解。其次，您可以在源代码的第一个原型出来的很长一段时间之前就对这些用例进行装配。弄清楚应用程序的关键原理以及用户的真正需求，一方面为今后同客户开展富有成效的合作开启了大门，另一方面也为在产品合成过程中不同角色和团队之间的合作奠定了基础。

简单的说，用例就是描述下列两件事情之一的一个简单的文档：

用户要求必须事先的关键功能（业务用例）.

或者

用户（活动者）与业务系统之间的交互（系统用例）。

也许您在想：“所以什么？那仅仅是另一个文档。”实际上，当我第一次面对要将需求和用户的期望写进文档之中，使之可以被不同的项目角色共享这一挑战之前，我也抱有同样的想法。在项目最初的阶段里，测试团队和文档团队就开始向我们询问一些关于我们将做什么以及各部分之间将如何协同工作等等细节。直到我发现用例之前，我的回答总是矛盾的、混乱的和非常耗费时间的。

当然，一旦我发现使用用例来计划和回答这些问题是多么的有效，我便面临着另外一项挑战：学习如何更加有效的撰写用例。

了解用户

在进入交互和特定情节之前，理解所有目标客户群并将其彼此区分开来，并且把他们的要求和需要列入清单是非常重要的。不同的用户群有着不同的业务用例。例如，一位负责确认遵循一套特定的全球性标准的测试人员的需求就在很多方面不同于一位拥有相似职责的开发者。开发者也许拥有知识、工具以及职权来修补那些错误的地方，但是测试者则是记录下这些缺陷然后等待开发者来作出改正。

在设计应用程序时，除非您弄清了这两类用户的特定需要，否则您就有可能设计出一个两方面需求都不能得到满足的系统。

业务用例与系统用例

取决于被讨论系统的不同，在业务用例和系统用例之间可能存在着巨大的差异。一个是描述用户的业务，而另一个描述的是用户同系统的交互活动。然而，这两种类型的用例之间的区别也可以变得模糊。例如，在一个软件开发项目中，系统就是业务。当您开发和测试一个特定的系统功能的时候，很容易就会忘记最终的用户很可能不会用您所采用的方法使用该系统，甚至都不会拥有同样的需要。

为了理解业务用例和系统用例之间的区别，想象一下软件开发团队已经承担了一项软件应用程序开发任务，并且要保证其在全球各种不同地区的环境下都可以同样出色的运作。为了确保该应用程序达到这些要求，该团队就必须遵循一套最小化的全球规则。¹ 这些规则在一套规范中被严格定义，不能随意被更改。开发团队需要针对这些规则来审核自己的代码，目前这些工作必须由手工来完成。一位程序师（审核员）必须打开源文件来查找同指定规则相矛盾的地方。

该组织收到一份执行决定，要建造一种能够使这些全球性规则（及其他规范）得到自动分析的工具，并且集合一支团队来开展这一项目。目标就是将业务用例中手工操作的那部分替换为软件应用程序（即系统）。这一手工过程非常耗费时间且容易出现错误。并不是所有的程序师都能够同样好的理解这一全球性的规则，许多人很可能没有注意到这之间存在的矛盾之处。另外，团队成员在持续的工作压力下变得越来越快的生产产品。一个可以核查全球化规则的自动化的系统将降低忽视某条规范的风险，并节省大量的时间。

在这个特定情节中，业务用例“在核查之前复审每一份源文件”可以被看作：

对于工作区内的每一份源文件：

打开源文件。
逐行阅读代码（注：需要深入的代码知识）。
如果您发现了一个可以的方法，就请参考包含这一规则的网页（注：非常耗费时间）。
如果可能的话，通过修改代码解决该问题（对于开发者的业务用例）。
1. 对于测试者来说可选的流程：如果您不能正确地解决这个问题，就请将发现的问题记录在Word文档中并提交给开发人员。
打开下一份源文件并重复上面的步骤。

正如您所看到的，这是一套冗长的流程，但却是实现自动控制的一个非常好的候选方案。

系统用例的价值

一旦您定义了用户的“就是这样”的流程和目标，您就能够指定那些用户活动的部分是一个自动控制的系统所能提供的。尽管它们仍然包含着用户的活动，系统用例却是以系统为中心的，来描述用户同系统交互的过程。然而，请注意系统用例应当在业务流程的背景下被定义。最终，我们的目标是帮助用户处理业务问题。

这里就是在我们虚构的项目中，团队是如何定义基础系统用例的，假设用户就是团队的一个成员：

前提：全球性的规则在IDE的复审特性的代码中被授权使用。

在IDE中打开代码复审工具。
1. （步骤之打开工具）。
运行一个代码复审。
1. 主流程——点击按钮“Run”。
2. （在新区域内列出可选流程的详细描述）。
复审自动化复审的结果（发现的问题）。
对于每一个发现的问题，解决之：
1. 主流程：提交缺陷。
2. （在新区域内列出可选流程的详细描述）。
如果您不能够修正这一代码，则提交缺陷。
1. （步骤之缺陷提交）。

一个包含以上这些步骤地简短的文档将提供充分的信息，使得读者了解到最终产品应该是什么样子，它将如何帮助客户处理他们的业务，等等。即使这一信息没有被明确的说清楚。

下面是拥有系统用例而带来的一些显而易见的好处：

即使没有一个代码被分类为“代码复审完毕，等待测试”，测试人员也能够针对上面描述的功能制定出一份测试方案。
另外，正是基于这一点，文档编写者可以针对代码复审创建并且（或者）添加文档中的结构。
开发管理者在此之后可以使开发进度更加优化，以便使得第一份开发构造将至少满足该用例的主要流程。

用例促进了项目的开发，并且使得全体团队成员在项目伊始就忙碌起来。如果您仍然没有将您的工作关注到用例上，那么请给它们一次机会。您所付出的努力将是值得的。

确定系统用例适当的详细程度

在每一个用例步骤中应该包含多少信息呢？

我更偏爱于取得系统用例并将其根据业务用例分类，并且同样通过一组步骤将大量的用户交互活动分类。该组步骤解释了该步骤的目的，并且可以在某些细节在实现过程中改变的情况下保持不变。这种方法使得文档更加易懂，它将系统用例和业务用例联系起来，并且如果产品执行变化时它允许用例可以被容易的修正。

例如，在上述系统用例中的简单的步骤“运行代码复审”中，向细心的读者传递了一个非常有价值的信息，包括：

代码复审被结合在IDE中。
代码复审必须在使用中，或者“运行”。
代码复审提供了一个关于违背某套有效性标准的问题清单。
某些问题可以被迅速的修正。
代码复审将获得迅速的修正。

回页首

确保有效的测试

一旦用例被适当的设置并且开发团队就他们所扮演的角色达成共识，这些用例就成为方案中其他部分的基础。实际上，这是最好的利用它们所提供功能的方法。

工程团队建造一个开发方案，其中至少要包括：一份将要被建造的组建的清单，以及每一个组建的时间期限。清楚的描绘主用例的特性需求和实际工作特性的组件必要性之间的关系是非常重要的。

识别这些核心组件并且定义它们的用例是非常关键的步骤，它使得应用程序功能性的早期测试变成可能。如果该核心组件能够在开发周期的初期被完成，那么测试人员就能够开始为基本的规则集合撰写测试脚本并且确认该工具功能的有效性。

在我们的例子中，系统用例“运行代码复审”使得测试人员能够为该核心功能制定能够测试计划，甚至可以在代码被编写出来之间就实现这一点。测试人员还可以为主流程和可选项目创建一套手工测试脚本。

测试类型

最简单的测试形式，同时也是非常有效的一种测试形式，就是聚集一大批受过良好训练的用户来针对该应用程序的各种不同特性来进行测试和演练，并且将测试结果（发现的问题和缺陷）报告给代码开发团队。这种确认形式很简单：拥有越多的用户，就会检查出更多的缺陷。不同的用户群将用不同的方式使用该工具并且进一步增加被检查出来的问题的数量。然而，有一些与此相关的问题。直到该软件为用户使用做好准备的那一刻之前，我们都有可能没有足够的时间来开展广泛的测试计划了。不同的用户可能使用不同的产品。更重要的是，完全依靠人工是非常昂贵而且非常不可靠的。

还有更多的事情需要考虑。如果没有一个清楚的测试计划，就不可能采取同样的测试方法来对不同版本的应用程序中的相同特性加以测试。如果没有测试工具的协助，对于每一次测试我们所采取的测试步骤将会大不相同。并且，我们将会疏漏一下很少用到的，但却是潜在的重要的情节。

手动测试和回归测试

手动测试 是指以确定一个特定的系统相应为目标的一套动作。手动测试的另外一种选择就是自动测试。两者都属于功能测试的类型.自动测试意味着您使用一个专门的工具或者一批脚本来对一套应用程序组件进行测试，记录应用程序的反应，将其与想定值进行比较，从而决定测试是否成功。所有这些工作都没有人工干涉。自动操作使得您可以一遍又一遍的重复同一项测试，具有人工永远无法达到的精确性。自动操作功能测试的例子包括IBM Rational Robot以及IBM Rational Functional Tester。

回归测试，用来衡量应用程序的质量，既可以手动处理也可以自动处理。您能够从自动功能性测试或者自动开发者测试（详见下文）中聚集一组回归测试组合工具。可靠的回归测试的关键因素就是景区的再现这些测试。因此，在被称作测试脚本的文档精确的定义测试步骤，并且在每一个回归测试中严格的按照这些步骤操作是非常必要的。在此之后，您就可以放心的使用这些测试结果，既不必担心有问题报告，也不必再去衡量其质量了。

测试的成功与否同您在制定测试计划、文档化手动测试和自动测试上所投入的时间长短是有着密切的联系的。下面是一些实现有效测试的具体的建议：

根据用例制定您的测试计划。首先开始测试主用例流程，然后扩展到可选流程。正如前面所描述的，关键是保持您的用例中的适当的粒度和模块性。
通过测试计划来组织您的手动测试，通过第一批测试就开始采用一种统一的方法记录和分析测试结果。重复的、统一的操作（即使是手动的）也将会提高您工作的质量。
自动测试首先具有相对简单可行的执行路径，但是每一次运行它都需要大量的入口数据。运用现成的数据池来完成测试脚本（例如，进行数据驱动测试）。

开发者测试

将用例转换为有效的测试通常会遇到一个大的障碍：代码底层中的一大块部分直到开发周期的后期才能够提供给功能测试。因此，如果一些组件在被组装进正在运行的应用程序之前就被测试将是一件好的事情。而这正是开发者测试所符合的。

开发者测试是一套关注于提高代码质量的活动，它经常被开发者使用。开发者测试包括两个主要方面：

自动化单元和组件测试。包括代码评审，单元或组件测试，以及代码覆盖分析。
手动测试和调试。包括运行跟踪，声明，内存泄漏检测和内存用法分析，性能评测，线程分析，等等。

自动批处理测试可以使用例如JUnit工具——一种集成在IBM Rational应用程序开发器里的代码复审工具，也可以使用IBM Rational PurifyPlus提供的附加的方法来确保高质量的软件。在开发环境下找到并且修改缺陷就意味着在后来会出现更少的功能性错误。并且可以节省出更多的时间来编写代码和引介更多的自动控制。另外，拥有可靠的可重复性的自动单元测试和代码复审，可以使您收集到关于代码质量的有价值的方案，获得前面所描述的一样的好处。

对于大多数组织，实现开发者测试的主要障碍就是对所需要工具的学习曲线。通常，个体的开发者测试工具注重于软件质量中某一个相对狭窄的方面。如果团队成员不具备自动开发者测试的经验，那么如何找到合适的工具和决定采用何种类型的测试就成为呈现在我们面前的巨大的挑战。因此，开发计划不应当仅仅将时间投入到开发和调试应用程序组件上，也应当将时间和资源投入到培训、设置、分析和报告有关执行自动开发测试方面。这一初期投资将会很快的带来回报，它将使得测试团队检测更少的功能性错误。它同样也会提高团队成员理解代码原理的水平。

下面是一些关于以开发者测试为开始的建议：

如果您即将进行单元测试，那么在运行单元测试的同时开始收集代码覆盖数据，从而对整套单元测试进行完全的评估。
如果您即将开发C++应用程序，那么请您运行关键用例，并且通过工具对动态内存分配进行分析。内存恶化的问题是本地C++应用程序的一个关键的方面，也是造成许多意想不到的和难于再现的缺陷的根源。
至少在每一个合成结构中的组件内收集执行的基线，并且随时监视执行的过程。
如果您即将开发一个Java/J2EE应用程序，那么请您在一组基本测试中监视内存使用情况和内存中的对象类型。
在开始时应用一把最重要的静态分析规则，将它们应用于每一个结构中，并且不断向您的代码底部添加更多的规则。这必将会减少运行结果中出现的错误。

开发者测试并不会取代功能回归测试，手动的或者自动的。它只是通过在开发环境中检测问题，从而在整体上提高了测试的效率，因为在这时修改起来相对更加容易。

积极测试和消极测试

积极的测试将关注点放在应用程序主流程的确认上，正如用例文档中所定义和区分出的优先次序那样。消极的测试则通常关注于那些应用程序性能极限的测试方面（例如，“破坏应用程序”）。

在我看来，一份好的测试计划应当明确的关注于确认用例路径，而不是包括极限测试。通常，您可以通过数据驱动测试来对极限进行评估，数据驱动测试应用不同的数据集来对某个单一的实例进行测试，这是为了确定应用程序对于特定问题和异常而不是标准的参数集的反应。

下面我来谈我的最后一项策略。

回页首

支持市场工作

在当今这个业务驱动的动态的环境中，充分理解软件市场的情况是项目成功的关键。实际上，一个组织对于市场的理解程度甚至比交流沟通、项目计划、质量以及测试更能影响它的成功。如果其产品未满足市场的需求或者定位于错误的消费群，那么即便是良好组织的、和谐的软件开发组织也会遭遇失败。

那么如何使得那些从事工程技术的人员同从事市场营销的人员来共同合作，从而提高产品取得成功的机会呢？下面就是一些建议。

驱动beta程序和消费者参考信息

对于软件团队来说，最有效的有助于营销一件新产品的方法就是从早期的客户那里获得积极的参考信息，并且通过他们这个组织的市场营销渠道来共享这些信息。不论您的营销人员具有多么熟练的技巧或者创造能力，他们都不可能在一夜之间收集到成功的经历。让消费者自己来熟悉新工具及其如何使用是需要一定的时间的。因此，为新项目制订计划应当将相当大量的时间和资源投入到早期的采用程序上。

在项目的开端阶段，应当安排由市场营销团队、一些有代表性的人员，以及一位来自于您的目标客户群的消费者共同参加的关于新产品特性及其他一些需求的讨论。同那些提出要在您的产品中增加需求的关键的消费者建立联系，拿出一份测试版本程序的计划和时限，并且确保该计划包括了用户提到的需求并将其作为目标。通过事先交流和沟通这些需求信息，有助于您为程序设定一个正确的期望值，并且提高产品同时厂合拍的机会。通常，消费者必须通过一系列合法性检查和许可之后才能提供出一些有助于您突出新的解决方案的优势的参考信息。

早期协作

还有一个好主意，那就是在项目中尽早开始同市场营销机构的合作，因为营销人员可以帮助您得到一些创建有效用例的必要信息。由于经常同那些对当前市场心中有数的分析师打交道，他们可以帮助您确定目标客户群和市场。同时，您为功能特性和产品发布确定目标所作的工作将产生出精心准备的文档，这些文档能够帮助营销机构较早的理解产品，并且使其能够描述和促进产品的正确性。关键词就是合作。

聚集一个合作的项目团队来帮助其中的每一位成员理解那些事情需要去完成是一项非常好的措施。除了上面所提到的收集市场信息之外，协同工作的团队还应当做下列事情：

认清关键的主办者并使他们在开发计划阶段能够聚在一起（复审目标，业务目标以及用例所描述的特定细节）。这些主办者可以是外部的投资者，潜在的消费者，或者甚至是您组织中的某一个团队。
获得那些关于客户支持的要求信息，包括他们的专业水平和进行培训的需要。
从销售团队那里获得渴望实现应用的日期，关键用户以及主要关注点等信息。
收集陈述和介绍的材料来介绍本组织的其他部分介绍给该项目，从而他们可以开始一同参加工作。协作的团队成员应当在整个项目周期中夜以继日的加速实现项目的目标、计划和活动，从而他们能够继续培养和教育感兴趣的参与者。

“谈论”市场营销

“谈论”市场营销就是指如何通过媒体传递技术性的功能。有时针对目标客户群的营销努力是非常技术性的，但是在更多的情况下，这样的努力由一些根本没有技术基础的业务决策者来执行。帮助您的营销机构将特性细节转换成有意思的信息以提供给一位非技术人员的顾客的最好的方法就是，充分理解该新产品所带来的好处和价值，并且准备好将其通俗的表达出来，例如以美元的数额。

准备好为下列问题提供清楚地答案：

“为什么这个新产品或者增强版本很重要？”
“它是如何在我们的业务策略中对关键的开端提供支持的？”
“谁将从这项新性能中获益？”
“该产品如何工作？”

根据我的经验，即使是最复杂的技水性解决方案都可以通过一种相对简单的方式来加以解释，这种方式概括了解决方案及其好处后面的动机。挑战在于如何找到一个使得您的用户中的大多数人都能够理解的模型。

回页首

面对全球化所带来的复杂的业务和技术要求，当今的组织不得不关注非技术性的和技术性的资源，才能够创造出成功的产品并且在激烈的市场竞争中占有一席之地。尽管没有所谓的“银弹”来保护您的软件开发组织在项目开发期间免受可能出现的挑战，但是认清楚您的组织内部不同开发部门和功能之间同步的重要性，将会为您在今后的发展中所遇到的每一次挑战做出更好的准备。

回页首

注释

¹ 代码编写标准可以是行业特定的，并且通常是强制性的需求。

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


		Goran Begic于1999年在荷兰加入Rational软件团队。从那时起，他曾先后从事IBM Rational PurifyPlus系列产品开发人员测试工具的技术支持、方法提供、产品管理以及销售工作。他同样拥有丰富的实现灵活开发的实践经验。1996年，他获得了萨格勒布大学的电机工程学学士学位。

从用例到代码，第二部分：用例设计

2008-11-14T20:56:00.000-08:00

级别：初级

Gary Evans, Independent Object Technology Evangelist, Evanetics

2005 年 4 月 01 日

来自 Rational Edge：这是“从用例到代码”系列文章中的第二部分，讨论如何把从用例中捕获的需求转换成可实现的表达形式与代码，本文介绍了在Rational Unified Process(RUP)中进行用例设计的几个步骤，其结论是与具体的实现技术相关的。

本文是系列文章的第二部分，讨论把从用例中捕获的需求转换成可实现的表达形式与代码。在第一部分“用例分析”中，我逐步介绍了在Rational Unified Process(RUP)中进行用例分析的几个主要步骤 ¹ 。我引入了一个简单的车辆租借系统的案例研究（以下称为车辆调度），这个系统为客户提供浏览访问服务，客户可以预约车辆、取消预约、查看租借记录等等。我还给了一个简单的用例预约车辆，首先是一个通用版本，然后是一个补充版本，引入了更多的外部交互，在这个用例里这种交互是一定会发生的。

之后我用了简单的语法分析技术来确定用例中的候选实体，并用四个问题来考察它们。这些问题从四十一个候选实体中筛选出八个，它们通过测试而成为分析类。然后我确定了每个分析类的职责，这样在我们对每个类的定义中就有了James Rumbaugh等人称之为“易碎边界”("crisp boundary")的东西。

确定了八个分析类之后，我引入了四个步骤用来构造初始分析类图，以捕获类间的关系和多样性。接着我又构造了预约车辆用例主场景的分析级别的序列图。它被严格约束于分析级别，只包含分析类，不包含设计类或实现类。为了使序列图更易理解，我引入了一般的用例控制器对象来为消费者参与者收到的信息提供中介。借助这些分析类及其已确定的关系，我又给每个分析类配上与其职责相一致的属性（数据成员）。最后，我为这个小的案例研究确定了分析机制。

在本系列的第二部分，我们要按步骤执行RUP中的用例设计活动。

RUP中用例设计的元素

图1选自RUP的《分析与设计概述》。它说明在其他分析与设计活动的上下文中，用例设计活动在哪里发生。

图1：RUP中的用例设计活动

在RUP中用例设计的目的是：

用交互改进用例实现
改进关于对设计类操作的需求。
改进关于对子系统及/或其界面操作的需求。

换个说法，用例设计的目标是把系统（也就是分析类）中每个业务抽象都转换成一个或多个作为可实现表示的设计类，并考虑到目标执行环境的属性。注意设计类是可实现的表示。设计类的实现（即编码）在设计稳定下来以后开始进行（虽然我们有时编写代码来研究可选的设计）。在设计时，我们要以合适的细节表达怎样着手于实现才能使编程实际上成为只跟语言和平台打交道的问题。图2说明了组成用例设计的步骤。

图2：用例设计步骤

设计活动包括同时保持关于你所建造的软件系统的多种视角。好的设计人员能成功地维系对目标系统的各种不同甚至对立的视图。正如一个长方体有六个面，彼此独立又都是同一个整体的部分，软件系统的设计也是多方面的，它包括：逻辑、流程、实现、配置、操作方面的视图；系统与软件架构；组件和类；模式与界面；静态结构与交互，等等。这篇文章里我不打算覆盖所有的软件设计实践，但我要给出一些具体的例子，解释我们在用例设计的主要步骤里究竟能做些什么，如图2。

类

面向对象和基于组件的设计策略的焦点在于类——将数据和对该数据操作的函数捆绑在一起的命名单元。在设计阶段，我们描述类以及类与其他类或子系统的关系，并且要把所有的技术关注点都考虑进来。

这些关注点有：

怎样表示两个类之间一对多或多对多的关系？
怎样表示对数据库的读写访问？
类里的哪些部分应该对其他类的对象可见？
哪些部分应该对其他类不可见？
怎样给多重对象提供一个简化界面？
怎样在业务类中把业务行为跟运行系统需要的技术行为合理地分开？

设计模型

用例设计活动的结果将产生RUP设计模型的内容，包括（当然不止于此）：

系统需要的设计类（也就是分析类加技术类）。
在设计类中软件架构文档(SAD)内容的实现。
每个设计类将拥有的操作和属性。
对实际数据类型、初值或者特殊子系统或卖方提供软件的界面做出规约。
按子系统或架构类型划分系统功能。
用交互图（即协作图与序列图）指出设计类如何协作，以完成用例中捕获的业务流程。

设计模型将成为原料，我们在实现阶段把它转化成可执行代码。我重申一下，这里讨论的焦点是使用C#，Java，C++语言纯粹以面向对象的方法开发一个新系统（常称为“绿地”开发）。

我们要讨论的步骤

我在做用例设计活动时遵循图2所示的步骤，不过我另外加了一步，见下面的修订列表：

创建用例实现
描述设计对象间的交互
用子系统简化序列图（可选）
描述持续相关行为
定义设计机制（RUP中正常情况下是一个软件架构活动）
改进事件流程描述
统一类与子系统
评估你的结果

这些步骤并非一成不变，记住这一点很重要。根据你对你所设计的领域的理解，你使用RUP的经验，你对所用模型的个人偏好，或者你在刻划设计类时遵循的隐喻（例如，应用设计模式，或遵循一些原则如关注点分离或界面隔离原则），你遵循的序列会有所不同。重要的是要对你最终实现的解决方案完成一个全面的表述。

在上述各步骤，我们只是来仔细推敲一下下面这五步：

创建用例实现
描述设计对象间的交互
用子系统简化序列图（可选）
描述持续相关行为
定义设计机制

架构准则

因为设计与架构关系紧密，并且被架构很强地约束，我们先来考虑一下软件架构(SA)，设想一下我们这个预约系统的全面架构，先约定SA已经作出了软件架构文档(SAD)，指出架构必须支持以下技术准则：

可扩缩性。车辆调度的预约系统和RDBMS（关系数据库管理系统）必须支持多重、并发的客户会话。各个会话之间没有依赖关系，系统必须能毫无困难地扩展到几千个并发客户。
可维护性。软件组件的更新必须易于集中完成，绝不向表示层分布业务逻辑。
技术简单性。我们这个租车公司不打算培训或者雇用熟练使用象J2EE或.NET这样庞大的组件平台的人员。这对我们项目的需要来说是杀鸡用牛刀。现有的雇员已经熟悉Java、Java ServerPages、servlets和JavaScript。
权衡技术。Internet必须成为浏览器和服务器之间的通信媒介，系统也必须把已有的编程界面用在遗留的平台上。

给定了这些准则，并且已知车辆调度项目在人员配备上是Java和servlet的开发人员，SA给SAD加上简单的UML架构模型，如图3。

图3：电子商务系统的初始配置图

图3解释了在独立客户浏览器与遗留预约数据库管理系统(DBMS)之间布局的最简单的视图，该DBMS包含了预约、客户和车辆的信息。图4给出了更多的内部细节，以及流程内部的一些通信。

图4：高级物理架构图

图4反映了我们这个应用程序的高级结构是基于JavaServerPage (JSP) Model 2的架构。客户用客户计算机上的浏览器完成交互。浏览器通过HTTP（超文本传输协议）与Web服务器通信，调用Web服务器上的servlet。我只是特别地讲了一下预约车辆servlet。该servlet以控制器的角色出现，协调预约车辆用例工作中需要完成的各个步骤。该servlet创建业务对象并与之交互，这些业务对象有预约、客户、保护产品等等，都是JSP要用到的。业务对象（将作为 JavaBeans实现）通过一个Java数据库连接(JDBC)协议与接口，从遗留的关系数据库管理系统(DBMS)获得其内容。该servlet将服务请求转发给合适的JSP。

回页首

用例设计第1步：为每个用例创建用例实现

在本系列文章的第一部分，我指出用例实现实际上是一个收集若干UML图与其他文本工件的过程，这样的文本工件包括RUP的用例实现规约文档，它一并确认了我们已经拥有足以提供用例流程中的行为的类、责任和对象交互。

在分析阶段，我们的用例实现只包括分析类及分析对象，它们能组装成不同的UML图如类图和交互图。在设计时，我们的实现将包括设计级别的信息，以解释用例的各个步骤是如何用于设计对象的协作的。来自需求的类图、交互图与描述将组装成我们的设计级别的实现。如果你使用建模工具如Rational Rose或者Rational XDE产品，建立用例实现可能只需要简单地在工具里创建一个用例模型元素，然后在其之下创建UML协作与交互图就可以了。如果你不用建模工具，你的实现就得在桌子上画出图来，不管是纸面手工作图还是在白板上画好模型拍下来。确认并命名一个用例实现保证了交互图和文本注释回到用例的可追踪性。本文余下的内容主要是讨论设计级别用例实现的内容。

回页首

用例设计第2步：描述设计对象之间的交互

这是复杂的一步，所以要引用文中几张不同的图，还要观察运行时的迭代流程。首先，注意在本系列文章第一部分“用例分析活动”那一段，根据车辆租借系统的属性我们作出了分析类图，如图5：

图5：分析级别的类图

这对分析类以及不同类的关系是一个适当的初始描述，但并未变成可实现的形式。比如，我们怎样在设计时表达一个给定的预约必须能访问0或更多个ProtectionProduct对象？VehicleInventory和Vehicle的关系是聚合(aggregation)，而RentalLocation和VehicleInventory的关系是合成(composition)这又是什么意思？我们对Vehicle的status和specialEquipment属性，以及Reservation的dates、times和estimatedCost属性应该指定怎样的数据类型？在类里面应该添加怎样的操作？怎样表达Reservation(预约)RDBMS的接口，使我们能够对Reservation或Vehicle的状态发出请求或存储变更？

在解决这些问题之前，我们可以回顾一下第一部分中描述过的为登记顾客(Check in a Passenger)用例所作的分析级别的序列图(SQD)，如图6。

分析级别的序列图(SQD)
察看大图，点屏幕右下角的四箭头图标放到最大。

在用例分析阶段，我们的目标是证明可行性，也就是业务对象拥有正确的职责来执行预约车辆用例的步骤。我们假定所有对象都是静态的，忽略对象的创建和析构，以简化任务。但在设计阶段，我们必须显式地说明对象的创建（以及析构，这一点与所用的程序设计语言有关）。我们还要问“谁负责”访问和“钩住”服务一条客户请求所需要的对象。

下面我们来讨论如何把这一序列图转化成关于对象交互的设计视角。还是从预约车辆用例开始，尤其是"happy path"场景，那里一切正常。

这个预约车辆用例是怎么真的开始呢？图7的序列图片段捕捉了一个可能发生的对象间的交互。（简单起见，我在该序列图中省略了客户概况的处理，它放在了分析序列图当中。）

图7：第一部分中预约车辆的设计序列图
察看大图，点屏幕右下角的四箭头图标放到最大。

第1步，客户访问车辆调度网站，主页在客户的浏览器上可见，提供若干输入字段让客户填写，包括日期、地点、车辆类别。第2步，客户要求系统查询满足这些条件的可用车辆，JSP把表单数据发送给第3步中的预约(Reservation)servlet (RsvnServlet)。预约servlet必须校验所选的租车地点与客户指定的日期时间相符，这样servlet在第4步建立一个空的 RentalLocation对象，在第5步引导这个对象跟经确认的指派地点的数据组装在一起。RentalLocation必须从在线的预约RDBMS 获得这些已有信息，在第6步我加入一个新的设计类DataAccess，来实现Facade模式。将类或组件以一个简化界面替代，该模式可以使我们将复杂的界面隐藏起来。RentalLocation对象object调用DataAccess对象的retrieveLocation(locationID)操作，返回一个结构化的数据组。在第7步RentalLocation调用一个自身的私有操作fill(dbRecord)，解析数据组并为其适当的实例变量指派字段。在第7步结束时，RentalLocation的实例已经为一个特定的租车地点完全组装好了数据。在第8步servlet通过validate(dates)操作询问这个特定的租车地点：“在这几个日期时间中你是否可用？”在我们讨论过的"happy path"场景中，RentalLocation回答“是”(OK)。

该地点在指定日期时间可用，因此servlet得到一个符合客户请求的车辆列表，并显示给客户。在第9步，RsvnServlet创建一个空的实例 VehicleInventory来保留符合客户要求的可用车辆。在第10步，servlet调用VehicleInventory的populate( )操作传递所选条件。因为位置清单和可用车辆的信息位于在线数据库当中，在第11步VehicleInventory调用DataAccess对象的retrieveVehicles(collection)方法。这个方法知道去创建一个空的Vehicle对象（第12步），以从公司的RDBMS（未知）获得车辆信息，然后在第13步调用刚刚创建的Vehicle对象的fill(dbRecord)操作。在fill(dbRecord)中 Vehicle对象解析从dbRecord（一个数据组）获得的数据，填进自己的实例变量。第14步，DataAccess对象把Vehicle对象填好后加入VehicleInventory。重复第12－14步，直至结果集中所有匹配的车辆都排进对象里。最后，VehicleInventory和 servlet被告知其请求已经完成。

系统现在给客户显示所有可用的匹配车辆。在第15步和16步，预约servlet把VehicleInventory对象存进Session对象，使下一个JSP能把它取回，然后在第17步调用RequestDispatcher.forward( )操作显示ShowInventory JSP。

在这一个小片段的设计序列图上，我们就碰到了几乎跟整个分析序列图一样多的信息。但在我们演进设计序列图时，我们确已说明了分析对象和技术对象将怎样产生交互，以完成预约车辆用例的工作。我们已经决定VehicleInventory只是一个集合类，保留多重车辆对象，如果我们继续这个序列图，我们会加上另一个集合类，以保留所有能指派给一个Reservation的ProtectionProduct对象。

根据在开发预订车辆序列图的这一部分时发现的新的技术类与新的操作，我们现在可以重构类图（回顾图5），如图8 所示。

图8：由操作更新的第一个版本的类图
察看大图，点屏幕右下角的四箭头图标放到最大。

我们回来看一下开发中的大图。如图7所示，我们采纳了Java Server Page Model 2架构的方法。这种方法是分离关注点原则的一个变种，附在模型－视图－控制器架构中。在图7左边，有两个JSP，它们是介绍页面或视图，在浏览器中显示。在序列图的中间是预约servlet，作为控制器它掌握客户预约车辆时需要执行的所有步骤。右边是实体对象，称为模型对象，它们有我们需要的业务知识和业务关系。

在开发图7的序列图片段时，我们在三个模型类Vehicle、VehicleInventory和RentalLocation中发现新的操作。至此，它们还只是从在线数据库获得数据的操作。当我们进一步开发这个序列图的后续部分，或开发其他用例的序列图时，在所有的类中都将发现新的操作，包括存取和计算等等。

所以我们不要到此为止。我们只看到了从在线数据库获取已有数据放进对象的行为。当客户选定某一辆车并预约时，租车流程的下一部分就开始了。图9描述了这一部分流程的序列图。

图9：预约车辆第二部分的设计序列图
察看大图，点屏幕右下角的四箭头图标放到最大。

第 1步，客户指出他要预订某一辆车。该请求发送给servlet，servlet令VehicleInventory将这辆车（记为vehicleID）暂时标记为不可用的。这样标记可以防止其他租车客户预约同一辆车。VehicleInventory将该请求转发给对应客户选定车辆的Vehicle对象。 VehicleInventory通过mark(expiry)操作完成这一点，其中expiry参数为保留给客户的最长时间，以应付他未完成预约就离开页面的情形。

注意这里我加入了UML注记（“也更新数据库状态吗？”）作为敏捷开发的身体力行者，我强烈建议你只对有长期价值的模型使用建模工具。但如果你的长期模型仍然有很多待解决的问题，不要太担心把那些问题放进模型里。你不见得经常需要这样做，但重要的是让问题对所有人可见，并时刻记住它们。

标记车辆之后，servlet需要准备显示租车信息页面，客户在该页面检验系统给出的信息，以及他的客户概况的内容。前面我们在图7里省略了描述查找 CustomerProfile的序列图部分，但现在我们也需要这个概况以及Customer对象。在第5步servlet（从我们未提及的 HttpSession对象那里）获得了customerID，它可能已经放进了车辆调度的主页。在第6步，servlet用这个ID创建了一个Customer对象，将它送给populate( )，用客户ID组装它的实例变量。在第8步和第9步Customer对象按照一个现在已经熟悉的模式从DataAccess对象那里获得一个dbRecord型的内容。现在Customer对象已经为客户实例化和组装起来，第10步servlet告知Customer对象它对应的 CustomerProfile。第11步Customer告知profile它是profile的父对象。现在我们已经在这两个对象之间建立了双向联系。

完成了这个处理以后，servlet预备显示RenterInformation页面，这由 RequestDispatcher.forward( )操作完成。第13步，RenterInfo JSP页面进入活动状态。第14－16步，JSP从Customer和CustomerProfile对象获得一般信息，对应的数据将显示出来等待确认。第17步RenterInfo页面显示在客户的浏览器上等待确认完成。第18步客户指出他已经在RenterInfo页面确认、更改或键入数据，并准备继续预约。第19步我再次一般性地指出JSP将与Customer和CustomerProfile对象（记住它们是JavaBeans）交互，将其根据屏幕数据更新。第20步，RenterInfo 页面发送至servlet，指出租车信息已经完备。此后我们将建立模型，描述系统如何提供预订的总括信息，包括提供购买保护产品等等。

我们在这张序列图里已经画出了不少交互，也发现了类中更多的操作。将我们的序列图消息提升至接受类的操作，我们就得到类图的一个新的版本，如图10所示。

图10：由操作更新的第二个版本的类图
察看大图，点屏幕右下角的四箭头图标放到最大。

我们现在看到对Vehicle、Customer和CustomerProfile加入了新的操作。这就是迭代的用例驱动方法。从用例和类表出发，我们从类里选择需要交互的对象，然后构造一张序列图表示这种交互。分析阶段的消息现在分配给基于职责的类，这些职责是我们赋予给每个类的。之后，消息提升为接受消息对象的类上的操作。在理想情况下，这些操作被确认为必须的，因为生成它们是为了满足用例的需求，而用例是包含了许多系统的功能性需求的。回想一下这个用例设计步骤称作描述设计对象之间的交互。在我们的序列图里显然已经实现了这一点，并且捕捉到了使那些类图中的交互称为可能的静态结构。

回页首

用例设计第3步：用子系统简化序列图（可选）

用例设计的下一步骤是用子系统替换公共组以简化重复行为。在我们的例子里，已经确定了一个子系统，DataAccess对象。这个子系统暴露retrieve ...( ) 操作以从数据库获得对象数据。在DataAccess子系统内部实际上已经有了很多东西：SQL语句生成，错误处理，结果集管理，等等。但内部细节对查询数据获取（之后也有数据存储）的客户对象是隐藏的。

通常不太会意识到需要一个子系统（带有简化界面），直至被一大堆复杂的类和界面缠住的时候，我们才终于认识到它们彼此有一个自然的关系（比如打印子系统中的类：Spooler、QueueManager、PrinterDrivers等等）。把类组合成子系统有一条好的原则，Robert Martin的公共封闭原则：

包（或子系统）中的类应当按照同类的变更封闭在一起。对一个封闭包（或系统）的变更影响到包里所有的类，但不影响其他任何包。

换言之，我们要把具有公共目标的类组合在一个清晰的边界内，以使该包/子系统内部的变更隔离在其内部。当我们通过引入子系统来简化模型时，我们把序列图中大的段落替换成向该子系统发送一条简单的消息。这就把前者的复杂性隔离在子系统内部，我们就可以为子系统的内部交互开发独立的模型，而子系统也就成为整个系统中一个可重用的组件。

回页首

用例设计第4步：描述持续相关行为

然而，当我们把DBMS的某些细节正确地藏进DataAccess子系统时，我们实际上犯下了一个重大的错误：我们的分析对象（Vehicle、RentalLocation……）获得了DBMS的信息。分析对象应该只知道业务逻辑，而不该知道存储位置、dbRecord结构布局。这样做为什么是不好的？考虑一个作为对象变更主键的简单变更的影响，回顾我们目前的设计是让分析对象（如RentalLocation）把一个特殊的标识符（如locationID）传给DataAccess对象。如果该标识符用作主键，又有变更，我们只好在RentalLocation对象里改变逻辑。

有没有什么办法能限制或消除这种对分析对象的影响呢？

有。我们可以在软件架构文档中描述的显式物理隔离之外，还达到这种逻辑隔离，其方法是引入三个新的对象：

一个factory对象，为我们创建分析对象，完全从DBMS中组装
一个DB对象，它是DBMS能意识到的分析对象的孪生对象
一个persistence interface(持续界面)，这是一个子系统，用于对数据库读写信息。

在图11的序列图中，我们引入了这三个对象，在servlet需要Customer对象从在线存储中恢复时重新创建了交互。

图11：带有持续层的设计序列图
察看大图，点屏幕右下角的四箭头图标放到最大。

这是一个更具封装性，也更具重用性的设计。对每个必须从DBMS中存取的分析对象（如Customer），我们创建一个"DB-aware"（“数据库可意识的”）对象（如 DBCustomer），它能理解它“正常”的孪生的数据字段与格式。这些DB-aware对象会驻留在Web服务器上，由servlet之一创建和使用。DB-aware对象知道从哪里怎样连接，怎样建立一个SQL语句并使之执行，以及怎样获得结果数据并存储到该分析对象中。现在，DBMS的格式或结果集数据结构的变更被隔离在ObjectFactory层之下，分析对象决不会受到影响。

我们还得评估一下存储结构，确信我们可以存取对象需要的数据。表1－7是预约DBMS布局的一个逻辑模型的例子。注意各表中大部分字段匹配为类的属性。但有些表的字段（如表3：车辆：Date of Purchase(购买日期)）不在相应的类中，因为这类字段与预约车辆用例无关。

表1：租借地点(Rental location)

LocationID

Street
Address

State

Sales
Region

表2：预约(Reservation)

ReservationID

LocationID

VIN

CustomerID

StartDate
&Time

ReturnDate
&Time

Quoted
Cost

Payment
Method

表3：车辆(Vehicle)

VIN

Manufacturer

Make

Model

Assigned Location

Vehicle
Category

Date Of
Purchase

Current
Mileage

. . .

表4：保护产品(Protection product)

ProductType

Eligibility
Codes

Lower
Limit

Upper
Limit

Benefit
Increment

表5：客户(Customer)

CustomerID

Name

Street
Address

Email
Address

Business
Phone

Other
Phone

Drivers
License #

Issuing
State

License
Exp. Date

Date Of
Birth

表6：客户概况(Customer profile)

CustomerID

Default
Vehicle
Category

Smoking
Preference

Default Damage
Waiver

Default Personal
Accident Insur.

Default Supplemental
Liability

表7：奖励计划(Award program)

AwardID/CustID

Current
Balance

YTD Redemptions

此外，注意主键()和外来键()属性是怎样表达车辆调度类图的关系的。Reservation表从CustomerID字段知道相应的Customer。RentalLocation表可以通过Vehicle表中的Assigned Location主键字段获取所有它分配的车辆。DB-aware对象创建的SQL语句根据所访问数据库的物理数据模型而生成。SQL语句"SELECT * FROM VEHICLE WHERE ASSIGNEDLOCATION = 42355 ORDER BY VEHICLE.VEHICLECATEGORY"返回的结果集是所有分配给该租车位置的车辆，按车辆类别排序（廉价车、小型车等等）。

现在我们可以理解这条非常重要的表述了：你发现和使用的设计类依赖于你采用的设计方法。在我们解决持续性的第一个方法中，我们把DBMS的信息放在表示业务抽象（即分析类）的对象里。但在第二个方法中我们另外创建了一个DB-aware对象层，专门用来读写DBMS的数据。

回页首

用例设计第5步：描述设计机制

在分析车辆租借系统时，我们为以下分析机制确定了其需要：

持续性。在正常的预约会话或者预约变更会话中，Reservation和Vehicle对象会经历数据和/或状态的变更。所以我们需要一个持续机制来存储新的对象数据。在分析阶段我们只需要为持续存储指定一个有意义的名字，而如何实现这个持续性的细节将在后面的设计阶段解决。

安全性。不能把其他人的预约显示给当前的客户，所以必须指定一个机制来确保安全认证。

遗留界面。所有的车辆信息来自公司车辆系统(Corporate Vehicle System)，它为所有的租借地点提供集中的车辆信息维护。如何与公司车辆系统对话依赖于我们能选择的设计机制。

在设计阶段，我们重新评估这些东西，并把它们对应到设计机制中，这些设计机制是根据持续性（表8）、安全性（表9）和遗留界面（表10）所需的分析做出的特殊解决方案。对其中每一个我都加上了满足设计机制的实现机制，如表8所示。

表8：

机制	持续性
设计机制	RDBMS——分析确定要以一种持续的方式访问和存储对象信息。因为我们的公司有几个相关的数据库管理系统(RDMBS)，我们的设计机制也要指定RDBMS。我们拥有理解这一技术的职员，现有的数据基础设施包括以SQL为界面的工具（如报表生成器）。
实现机制	JDBC——我们在上一段特别提及了它，来完成Factory类、DB-aware类与Persistence Interface类。但Persistence Interface究竟如何访问目标RDBMS？在我们的场景里，假设Reservation RDBMS是运行于Unix服务器上的Oracle 9i系统，但有可能为Windows 2000上运行的SQLServer所取代。在此场景对RDBMS用一个JDBC界面会使我们获得需要的灵活性。

机制	安全性
设计机制	安全认证——分析确定需要确保客户只能看到他/她自己的预约。我们用客户的Awards ID号码（这是唯一确定的标识符）作为顾客数据库的索引。
实现机制	Unique Customer Number (Awards ID number)作为唯一标识符在Customer表上用作RDBMS索引。

机制

遗留界面

设计机制

这一机制在我们这个简单的车辆租借系统中并不必要。在用例分析中，我们规定车辆信息由公司车辆系统维护，它自己就是一个RDBMS。持续性机制提供的服务使我们能够在我们的RDBMS中插入或提取信息。

如果我们必须与IBM MVS大型机上的CICS应用程序通信，我们需要指定所用的通信协议（例如LU 6.2 APPC）。

实现机制

无。

回页首

结论

在这两篇系列文章中，我给了很多例子来说明在我们的生产环境的指定技术依赖下，怎样从包含许多系统需求的初始用例出发，达到问题域的分析和方案域的设计。在系统开发中还有更多的问题要考虑，但我相信这些例子已经给出了整个流程的一次实践性的漫游，达到了我的初衷。在我给出的设计级别的序列图和类图细节的基础上，读者应该发现把这些表达翻译成Java类定义或JSP已经是一个简单直接的事情了。通过我们的设计工件，可以直接进入为系统作概念证明编码，或者编写产品代码的阶段。每个用例将遵循文中的流程，直至所有的用例在这一迭代周期中完成，这样我们将会完成系统的大部分编码工作，完成对用例中捕获的所有重要业务功能的编码工作。

回页首

参考文献

Rumbaugh et al., Object-Oriented Modeling and Design. Prentice-Hall, 1991.

Robert C. Martin, Agile Software Development: Principles, Patterns, and Practices. Prentice-Hall, 2003. An award-winning book that covers a broad menu of essential design practices.

Eric Gamma, et al., Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. Required reading for any developer doing serious development today.

回页首

进一步的读物

Scott Ambler, Agile Modeling. Wiley, 2002. How to do more with less modeling and overhead.

Len Bass, et al., Software Architecture in Practice. Addison-Wesley, 1998. Excellent coverage of what software architecture really is.

回页首

注记

¹本系列文章所有对RUP的引用均来自RUP version 2003.06.00。文中所有UML模型均由IBM/Rational Extended Developer Environment (XDE) Developer Plus for Java version 2003.06生成。

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

图1：结构分析的工作流程(early Elaboration)


		Gary K. Evans是Evanetics公司 (www.evanetics.com)的创始人。Evanetics公司是一个致力于推广使用敏捷开发技术和过程，来降低软件项目风险的咨询公司。他发表了数十篇面向对象技术方面的论文，开发了很多工具软件，还经常在各大软件会议上发表演说。他很喜爱足球，但是他更喜欢与一个开发小组一起工作，帮助小组成员使用面向对象分析设计方法，和敏捷RUP方法进行软件开发，与他们一起更快更好的发布一个个软件。他的电子邮件地址是 gkevans@evanetics.com。

从用例到代码, 第一部分：用例分析

2008-11-14T20:51:00.000-08:00

级别：初级

Gary Evans, Independent Object Technology Evangelist, Evanetics

2005 年 4 月 01 日

来自 Rational Edge：这是 Rational Edge 上面的系列文章中的第一部分, 介绍了一个具体的案例，从用例中提取需求，并加以分析，进一步将其转化为可以直接进行编码的格式。

自从1992年 Ivar Jacobson 发表了关于如何使用用例，从系统用户的角度来提取软件需求的方法的论文之后，这种方法已经逐渐流行起来。但是有一个最常见的问题是：当我得到了用例之后，如何才能把他们用代码实现出来？本文由两部份组成，将会用一个实际的案例来说明这一点。如何从用例中提取需求，并加以分析，进一步将其转化为可以直接进行编码的格式。我希望能够把这一过程讲清楚，这样你在当前的，或是下一个软件项目中就可以使用它们了！

IBM Rational Unified Process(RUP) 提倡通过用例来提取系统中可操作的需求。 ¹ 软件需求说明书，即 Software Requirements Specification (SRS)，包括软件的所有需求，其中包括很多相关的文档。用例就是其中的一个重要部分。 SRS主要包括以下几部分：

用例模型，包括：
1. 用例图：可视化的描述系统用户，和系统为用户提供的服务。
2. 角色定义：用文字描述系统功能，和系统所需的服务。
3. 用例描述：用文字描述系统提供的主要功能。
软件补充规格文档：这个文档包括了整个系统相关的各种需求，和一些与对系统用户和用例都不直接相关的隐藏需求。

在 RUP方法中，这个需求文档是后续的分析和设计工作的起点。不同的开发方式，对项目的推动力是不同的，也就会产生不同的文档。如果软件发布之后，你还总是在不停的修补缺陷，你很可能根本没有需求文档。只能从Bug报告中看出，软件已经和最开始设计的样子不一样了。如果你在维护或者改进一个软件版本（比如增加一项新功能），你可能有一两个用例，他们描述了这些新功能和用户之间如何交互，但是你不会有软件补充规格文档，因为这些功能之外的部分并没有改变。

在这里，用一个虚构的软件项目"green-field" 作为例子。这是一个面向对象的软件项目，使用UML来描述系统中的各种概念与关系。读者需要具有对象和类的基础知识，熟悉UML 版本1.x 或者2.0中的类图、顺序图和协作图。

用例分析活动

下面我们讨论一下RUP中的用例分析。如图1所示，将RUP中结构分析的结果整合起来。

显而易见，严格来说的话，软件开发过程应该侧重于企业系统级的架构设计，以及软件重用。但是基于以下三点原因，在这里我不会长篇大论的讲述结构分析：

我的目标不是结构分析设计，而是面向开发人员的更底层的日常工作。
这不是一本专著，没有那么多篇幅来讲述结构分析。
根据我多年在软件架构和软件过程方面的咨询经验来看，只有很少的软件开发组织能够很规范的进行结构分析。如果你正在从事结构分析，你一定曾经经历过本文中的一些内容。对一个新的，或是一个大型的软件项目来说，采用结构分析是明智的选择。但是如果你不太熟悉结构分析，本文的内容将会对你有所裨益。

用例分析的目的：

找出用例中的执行流程、事件的各个类。
通过实现用例，把用例的行为指定到具体的类。
找出类的责任、属性和他们相互的关系。
规范地确定系统中各用例的职责。

我们也可以认为，用例分析的目标，就是把我们对用例的理解，转变为与业务一致的形式，实现需求的价值。在用例设计的时候，我们把业务概念抽象成类、对象、关系、组件、接口等等，这些都与目标系统直接对应。

图2引自RUP分析和设计概述部分，描述了需要使用用例分析的场景，和用例分析与其它步骤之间的关系。

图2：RUP中的用例分析

在RUP [RUP2003]中的用例分析由几部分组成：

每个用例包括：
1. 建立一个用例实现
2. 用例的补充描述（如果需要）
3. 从用例的行为中，找出分析类(Analysis Classe)
4. 把行为指定到具体的分析类
对每个分析结果的类：
1. 类的职责
2. 类的属性和关系
  - 定义类的属性
  - 分析类直接的关系
  - 分析类间事件与事件之间的相关性
整合所有的用例实现
建立跟踪机制
建立分析机制
对用例分析的结果进行评估

请注意这些步骤的次序不是一成不变的。你实际所采用的次序取决于你对于分析的领域的理解程度、你对RUP或UML的经验、你所采用的模型、或者是你自己的确定分析类的属性的一种习惯方式。(例如，以职责为中心，以行为为中心，或者以数据为中心) 关键只在于你是否能够对问题建立一个准确的描述，而不是对我们的用例设计的准确描述－－这将是本文的第二部分的内容)。我会遵循本文中的大多数（但不是全部）步骤，而且我会改变一些步骤的次序。在每个步骤的具体内容中，我会说明为什么这样做有助于RUP和OOAD的新手更好的学习OOAD。

如图3所示，一些步骤把编写用例和实现代码分隔开了。还列出了RUP中用例分析部分推荐使用的一些步骤。这张图将会指出在后面部分中，我们的前进方向。

图3：用例分析的步骤

回页首

用例的具体实例

例子可以更好的说明问题。这个虚构的简短例子是一个汽车租赁公司的网站系统。这种系统一般有几个用例描述了为客户提供的服务，如：

预约汽车
取消预约
查看租车历史信息
查看/编辑顾客档案
加入酬宾活动等

为了简化模型，假设我们的服务只针对个人用户，不针对企业用户。

为了让例子尽量简单、易于理解，我们只分析其中的一个用例。描述如下：预约汽车.

用例：预约汽车。

这个用例从顾客提出他想要预约一辆汽车开始。
系统提示顾客输入希望的租借和归还汽车的时间、地点，顾客输入以上信息。
系统提示顾客选择希望租用的车型，顾客进行选择。
系统列出在指定时间、地点可用的，所有符合条件的汽车。如果顾客需要某辆汽车的更详细的信息，系统也可以提供。
如果顾客选定了某辆汽车，系统提示顾客输入个人信息：姓名、电话、电子邮件等等，顾客输入以上信息。
系统提供各种保护产品的信息（如汽车损伤保险、乘客险等）并询问顾客是否购买，顾客做选择。
如果最后顾客表示接受这个预约，系统通知顾客预约已成功，给顾客一个确认。
当确认信息出现时，这个用例就结束了。

必须用通俗易懂的方式来描述用例，不仅仅对web程序是这样，即使是顾客走到营业点去当面预约也是一样。用例描述只需要指出结果，不需要详细说明具体系统将怎样操作、系统的客户将怎样操作。如果你用“营业员”代替上面的“系统”一词，上面的描述就变成了一段对顾客到营业员处预约汽车的准备描述。其中的第7步给出确认的手续，在这里就变成了书面格式的确认。

在设计web界面时，可以把多个步骤放在同一个页面中，例如上面描述中的步骤2和3。在web环境中，第7步的确认，将会在预约交易报告页面中呈现给顾客。

也请注意用例描述的文字风格。上面的描述是用正面的语气，用现在时态来描述的。正面的语气指的是描述清晰果断，相反的负面的语气指的是被动的语气，和比较含混的描述。例如，“John投球”是正面的语气，动作的执行者John放在动词前面。这句话的被动语气的描述是“球被John投出去”，或者更简单的“球被投”，连动作主体也省略了。动作的执行者John放在动作后面。在所有的负面语气的描述中，动作的执行者会出现在介词短语中。让你的用例描述清晰、一致。使用正面的语气，现在时态。不要使用太多的词汇，描述清晰就可以，不要使用太多无关的词语，保持前后一致。例如，不要使用“顾客”，而是使用“客户 ”，或者“商业伙伴”也不错。如果同时使用这三者，你的读者会认为你是在描述3种不同的用户，他们的信息和权限也不同。

我们准备好的用例描述，可以作为下一步的起点。下面让我们开始按照RUP中的用例分析过程来开始分析。

回页首

用例分析第一步：建立一个用例实现

RUP 中的用例分析过程的第一步是建立一个用例实现。在我们给出用例实现的定义之前，回过头来看一下，到底什么是用例？我们需要怎样来确认用例？我们写好的用例，是一个业务过程的描述，描述了顾客预约汽车的过程。它说明，我们会按照一些固定的步骤，按照固定的业务规则（例如在得到顾客的姓名之前不进行任何处理），也不为顾客提供那些无法按照指定的时间地点供客户租用的汽车的信息。

由于我们是在设计一个面向对象的软件系统，我们的用例行为需要由我们系统中的一些对象和类来执行。但是迄今为止，我们还没有任何对象和类，因此我们需要从用例中去发现这些对象和类。还需要指定每个类要执行用例图中的哪些行为。

如图4所示，用例实现实际上是一组UML图，说明了我们都需要哪些类、它们的职责和它们的实例对象之间如何进行交互，来完成用例中的行为。

图4：机票预订系统中的一个RUP用例实现

通常一个用例实现会由下面这些组成：

包括我们所关注的用例中出现的所有类的一个UML类图(有时也叫做合作类视图）, 和
描述交互的对象，以及它们之间的调用关系的一个或多个UML交互图。UML定义了两种类型的交互图：顺序图 (如图4)，和协作图。都很有效。

看起来我们有很多事情需要处理，是这样吗？是的，而且当你使用诸如Rational Rose或Rational XDE这样的开发工具的时候，这项工作看起来更像一项家务管理工作，你只需要建立很多结构，存放你的用例实现。后面我们会完成实际的类和交互图。但是现在我们先来明确一下我们的目标：一个类图，一个或多个交互图。

回页首

用例分析第二步：补充用例描述

当你在进行分析的时候，你的用例描述只记录了从系统外面的用户角度来看，系统的行为是什么样子的。在概要的描述系统内部的一些不可见的操作的时候，这足够了，但是按照这样的描述，并不能完成具体的实现。

举一个例子，看看上面描述的第四步：系统列出在指定时间、地点和可用的所有符合条件的汽车。如果顾客需要某辆汽车的更详细的信息，系统也可以提供。在这里，我们有可供搜索汽车信息的数据库了吗？我们也许知道，汽车信息由CICS（客户信息控制系统）管理，存放在MVS主机上，通过LU6.2 APPC可以访问，但是我们不能确定这一点。让我们来把这些我们要做的事情，特别是在我们系统之外事情的细节，来清楚的确定下来，而不是只知道我们希望怎样做。下面是补充了这些信息的第四步，补充一个汽车数据库：系统通过访问这个汽车数据库来查找汽车的位置信息，并列出在指定时间地点和可用的所有汽车。

这里我们给出了一个汽车数据库的信息，并且比较抽象的描述了如何用网页来访问它。这是一个很简单的例子，但是读者可以从中了解一些内容。

在RUP这样的迭代开发流程中，从分析阶段转移到设计阶段只用了很少的时间。对一个中等规模的，四周左右的项目来说，你可能第一周用来获取需求，做你的分析和设计，然后后面3周都用来写代码和进行测试。你用于分析的用例会侧重于系统对外可见的行为，不过你可能需要细化这些用例的描述，增加更多的系统内部如何交互的描述。这样你的顾客和分析人员才能确认你没有遗漏一些重要的业务。请注意，只需要把用例描述细化到你可以很好的找出系统中的分析类的程度就可以了。对于设计级别的类（诸如树、堆栈、队列、集合等等）可以在后面的阶段完成（如设计阶段）。

例子：补充“预约汽车”用例

假设我们的系统是一个网站程序。当客户需要的时候，我们会为他们提供私人在线预约汽车服务。我们要为这个实现的具体情况来细化我们的用例，不过不要过多的涉及到设计阶段的工作。

这是预约汽车用例的更详细的描述，还是侧重于做什么，而不是侧重于怎么做：

用例：预约汽车（补充）

这个用例从顾客进入我们的预约汽车网站开始。
系统提示顾客输入希望的租借和归还汽车的时间、地点，顾客输入以上信息。系统还提供给顾客一个选项，来选择汽车的种类，如微型汽车、SUV、标准汽车，等等。顾客可以限定在一个或多个种类中搜索汽车。默认值是搜索所有种类的汽车。如果顾客参加了我们的有奖租赁汽车活动，他可以在网页上一个单独的地方输入他的有奖活动的编号。如果他填写了这个编号，系统会访问顾客的档案，来预先获取相关的信息。
如果顾客要继续进行预约，系统在下一个网页上，列出从数据库中找到的所有符合条件（时间地点）的汽车，提供每辆汽车的基本费率，根据顾客的租用历史情况还可以打一点折扣。如果顾客需要汽车的更详细的信息，系统从数据库中查找该信息，并将其显示给顾客。
如果顾客选定了一辆要预约的汽车，系统在一个新的网页中让顾客填写个人信息（姓名、电话、用于确认的电子邮件、信用卡发行商，等等）。如果系统中已经有该顾客的档案，则调出系统中的相应信息显示在页面上。有些信息是必填项，另外一些则是选填项（如电子邮件）。用户需要填写所有的必填项。系统还提供各种保护产品的信息（如汽车损伤保险、乘客险等）和单日的价格，并询问顾客是否购买，顾客做选择。
如果顾客表示“接受这个预约”，系统在网页上显示这次预约的概要信息（汽车型号、日期、时间、选用的保护产品及其费用、费用总额等等），让顾客确认。如果顾客填写了电子邮件，系统会发送一封确认信到顾客的电子邮件地址。
当确认信息出现在顾客面前时，这个用例就结束了。

在这个经过补充的用例描述中，我们清晰的描述了一个基于浏览器的程序的行为，描述了很多对顾客来说不可见的行为。但是并没有提供设计级别的信息。

我们需要为每个用例提供类似的详细信息吗？

不需要。但是请记住，补充细节，并不是指实现的具体细节。我们的目标是为了能够有足够的信息来理解系统中的分析类，并与你的顾客或分析人员就所有用例的业务流程达成一致。如果你觉得补充一些细节对于找出系统中的分析类有所帮助，那么就加上它。

注意：把握这个细节的尺度会比较困难。需要时间和一些练习。多上手练习，向别人多询问，还要记住当你无法决定的时候，应该稍微偏向抽象一点的描述。增加一些没有写上去的内容比较容易做到，但是要从很多杂乱的描述中找到有用的信息可就难的多了。

为什么还要先写出比较抽象的用例呢？为什么不直接把用例补充的比较详细？

这是因为抽象的用例是系统行为的最通用的描述（不过多的描述系统内部行为）。如果你还要开发一套客户端/服务器版本的预约汽车的用例会怎么样呢？如果你从详细的用例（基于浏览器的系统用例），每次改变你的实现平台的时候，你都得重写整个用例。这个通用的描述与技术无关，特别是当你还没有、或是无法确定系统的具体环境的时候，它的价值就得到了体现。另外，通用描述用例能够让你的业务分析人员能够只看到系统如何工作的内容，而不是看到包含很多他们难以理解的技术细节的内容。

回页首

用例分析第三步：为用例行为找出分析类

根据RUP过程，这一步的目的是找出分析类的候选范围，这些类合作起来，可以完成用例的所有行为。因为我们还没有任何类，所以我们的主要目标就是找出在汽车租借系统中的所有分析类。

这就引出了一个有趣而又重要的问题：什么是分析类？有两种答案。首先，一个业务级别的分析类是业务领域中的一个要素，与实现技术无关。例如，银行系统中的银行顾客、帐户、帐号交易等等。而且它与系统的实现无关，不管是一个新的电子商务系统，或是一个从19世纪80年代就开始使用的借贷系统。

其次，RUP过程把这个定义扩展出三种不同的分析类：实体类、控制类和边界类。RUP过程中的实体类大致上相当于前面提到的，业务级别的分析类。控制类与业务过程相关，它们控制整个业务的流程和执行次序。它通常控制一个用例中业务过程的执行。边界类在系统与外界之间，为它们交换各种信息与事件。边界类处理软件系统的输入与输出。

根据我在面向对象技术和面向对象建模方面的教学经验，我发现开发人员总是很快的从RUP过程中的实体类、控制类和边界类这个环节，进入下一个设计环节, 没有对问题进行足够的分析。实际上，显然控制类和边界类都是面向技术实现的类，而不是面向业务的类。它们都是在设计阶段所定义的系统设计模型中的一部分，而不是分析模型。因此，在这一步，我将会侧重于业务方面的，与技术无关的分析类。在讨论设计的时候再讨论涉及技术的部分。请一直记住，搜索与业务相关的类，是在RUP过程中的结构分析部分进行的,如果你的项目采用了RUP过程的话。

让我们回顾一下，用例描述的是行为，也就是系统为用户提供了什么样的服务。在用例描述中，没有涉及面向对象的内容，但是这些描述是用来找出系统中的对象和类的。可以在很多地方，用各种各样的方法来寻找类：

领域的常识只是
前一个类似的系统
企业模型或供参照的体系结构
CRC (类/职责/合作关系)方法
词汇表
数据挖掘

寻找类的一个简单的方法就是语法分析，下面我将加以说明。我们只要找出我们的需求中的名词，这些名词（有些是形容词＋名词）：

一些是类。
一些会成为类的属性。
一些对我们的系统无关紧要。

找出预约汽车的用例描述中的这些名词（跳过代名词，如“他”），如下：

用例：为顾客预约汽车（补充）

这个用例从顾客进入我们的网页开始。
这个系统显示输入框，来提示顾客输入借出和归还时的预约的地点，和借出和归还时的日期和时间。顾客输入地点和日期。系统还提供选择框，让顾客来限定汽车的型号分类 ，例如，如微型汽车、SUV、标准汽车，等等。顾客可以指定一个汽车分类进行搜索，也可以指定多个分类。默认的设置是在所有的汽车分类中搜索。如果顾客参加了我们的租赁有奖活动，他需要把他的有奖活动中的编号输入到网页上的一个独立的输入框中。如果这个输入框 填写了内容，系统会访问顾客的个人档案，系统会提前查找所需的信息。
如果顾客表示希望继续进行预约过程，系统访问汽车数据库，来 查找位置信息然后在一个新的网页中显示所有的汽车信息。这些汽车都是在指定的汽车分类 中的，并且在指定的地点、日期和时间中是空闲的。对每辆汽车，系统都会显示一个基础费率，如果顾客租用汽车的历史比较长，还可以打一些折扣。如果顾客想要看到某辆汽车的更详细的信息，系统从汽车数据库中读取这些信息，并把他们显示给顾客。
如果顾客选定了汽车来预约，系统显示一个新的网页，提示顾客输入用于确认顾客身份的个人信息，（姓名, 电话, 用来确认的电子邮件, 信用卡发行商 ）。如果顾客档案已经存在了，系统从中读取所有已经填写过的信息。一部分输入信息是必填项，其它（如电子邮件）是选填项。顾客填写所有必填的信息。系统还要显示保护产品相关的信息（如汽车损伤保险、乘客险等）和单日的价格，并询问顾客是否购买这些保护产品。顾客给出决定。
如果顾客表示接受这个预约，系统给出一个网页，来显示 预约的摘要信息，（汽车的类型、日期和时间、所有选购了的保护产品及其费用、租用总额），还为顾客显示预约的确认页面。如果系统有用户的电子邮件 ，系统会发一封预约确认信到这个地址。
这个用例当预约确认信息出现在顾客面前的时候，就结束了。

注意每个名词，或者形容词＋名词的组合，都被标出来了。有很多重复的，因此把每个词单独列入词汇表1，按字母顺序排序：

表1：候选的名字/实体类

我们如何分辨出哪些候选的名词才是真正的问题领域中的类呢？一个常用的方法就是，用一些简单的问题来测试每个词，如图5：

这个候选是在系统的边界之内吗？
如果不是，它可能是系统的用户。
这个候选词有某些明显的与业务主题有关的行为吗？
（也就是说，这个候选词可以拥有或者提供某些系统的服务或功能吗？）
这个候选词拥有明显的数据结构吗？
（也就是说，这个候选词拥有或者管理某些数据吗？）
这个候选词和其它候选词之间有什么关系吗？

图5：用来寻找分析类的问题

如果某一个答案是“不是”，那么这个候选词很可能不是一个类。再继续检查下一个词。如果答案是“是的”，那么继续检查下一个问题，如果所有的问题的答案都是肯定的，这个候选词就是一个类。再继续检查下一个词。

我们对每个候选词做检查，就会得到类似于表2的结果：

表2：名词检查结果

请注意租借地点已经被加进去了，虽然它不是用例的一部分。在与我们的业务专家（Subject Matter Experts，SMEs）们谈话时我们发现，业务中会使用地点来指代一个地址，或者一个租借部门。为了不致于混淆，我们一致统一使用单词租借地点来表示业务地点，也就是发生租借和归还的地方。

从这个列表中，我们列出了通过了问题检查的词，也就是下面列出的分析类：

啊哈！在总共得30多个候选中，现在我们只需要面对选出的8个分析类。前面的四个问题帮助我们缩小了搜索范围，是个很有效的工具。

但是我们有没有犯错呢？有没有漏过某个真正的类，或者把一个不该作为类的词加进来了？这并不重要。RUP的迭代特性，会逐渐暴露出我们犯过的错误，并允许我们用尽量小的代价来修正它们。分析和设计的目标不是先把一切事情设计的很完美，而是当你需要确认这些事情的时候，才去确认这些。开始阶段往往是最困难的，我们现在实现了对象（或者说类）从无到有的突破！重要的是我们已经起步了，而且我们能够按照面向对象的方法一步一步的取得进展。

我们现在完成了RUP的用例分析活动中的前三步：

对每个用例
1. 建立一个用例实现
2. 补充用例描述（如果需要的话）
3. 从用例行为中，找出分析类

如果我们严格按照RUP过程进行，下一步应该是：

把行为分配给分析类

基于以下理由，这一次，我又会对RUP过程做一点小的改动：回顾一下我们的进展。我们刚刚找到了8个实体类，我们认为这些都是我们系统中的类。在我们做下一步之前，我们需要给这8个实体类增加一些内容，来确认他们是类。

有三种基本的方法来充实我们的分析类：

数据驱动的方法
行为驱动的方法，和
职责驱动的方法。

数据驱动的方法对于从事数据库工作，或者从事过程语言编程的人员来说很常见。他们就是用数据和数据之间的关系来认识、描述世界的，因此会首先去寻找类中的数据－一般没有什么标准的方法去寻找类的函数或功能。这看起来不错，但是数据只是工作的一半。实际上，类的准确定义，包括了数据和对数据进行的操作。

行为驱动的方法有着双重的成立理由。首先找出类执行的操作，从中决定这些操作涉及的数据中，哪些应该被这个类所拥有。这很棒，但是我们如何确认我们为类找出的操作之间能够保持一致呢？如何区分操作和类，以明确这个操作是属于这个类，但是其它的操作要属于同一个类，还是其它的类？我们需要某种方法来区分各个操作。这就是职责驱动的方法带给我们的。

职责驱动的方法是自上而下的，从总体的类及其职责的视图开始。首先定义一个类在业务中的“使命”，这个“使命”描述了这个类对外提供的服务。从军事术语上来说，就是责任和策略。操作和数据是战术层面上的（为战略服务的，服从于某些目标、策略的）。 ²

一旦我们确定了我们的类的职责，我们就可以设计一个分析类图，来描述类间关系的整体结构。这个结构一般都是由业务领域决定的。一个UML分析类图可以帮助我们可视化的把这个关系的结构表示出来。

因此，我建议对标准的RUP过程做如下修改（次序的改变）：粗体）：

对每个分析类
1. 描述类的职责
2. 在分析类图上，建立分析类间的联系
3. 把行为指定给分析类（找出操作）
4. 描述每个类的属性和关系
  - 定义类的属性
  - 描述分析类间事件的相关性

回页首

用例分析第四步：描述类的职责

在这里，我们要对每个分析类进行处理。类的职责描述了这个类在系统中所提供的服务，而且其它类不会重复提供这些服务。各个类的职责不能重叠。

根据我们对汽车租借领域的理解，和对汽车租借专家、业务分析专家一起工作，我们在表3中，写出了我们对每个分析类的职责的理解。

表3：每个分析类的职责

James Rumbaugh与其它人 ³ 定义一个对象，或者说类，作为“一个概念，抽象，或者一个对业务来说有意义的，具有清晰定义的东西【我的重点】”。在类的职责定义中，首先要注意“清晰定义”，就是指明确指定了可以做什么，不可以做什么。

如果我们定义的职责出现错误怎么办？我们再重复一次，这无关紧要。我们已经开始，并且在不断取得进展。当我们对系统了解的更多之后，我们对类的职责作出些调整是很正常的。这样才能帮助我们把建模工作和软件做的更好的。

回页首

用例分析第五步：建立分析类之间的关系

我们已经确定了类的职责，下面将会设计一张UML类图作为起点，来找出分析类之间的关系。建立类图有四个简单的步骤：

确定要进行建模的类（我们已经完成了）。
确定哪些分析类具有与其它类之间的关系。
对于任意两个之间具有关系的类，确定关系的语义：是关联、聚合、合成还是继承？
对于非继承关系，确认关系的多样性（指另一个类的多少个对象可以被关联到这个类的一个对象上面，类似于数据建模中的概念。）

通过以上步骤，加上我们前面确定的类的职责，我们得到了UML类图，如图6：

图6：汽车租借系统的类图

这个类图上有三种UML关系，用不同的线区分出来。简单的实线表明是关联关系。用来表明两个类之间的点对点的关系，每个类都会调用另一个类提供的操作。

在线上用实心菱形表示，在预约和保护产品之间的是合成关系（或者说不可共享的聚合关系）。这是个整体/部分的关系，或者说是一种拥有的关系。在这张类图上，合成关系表示预约拥有管理0个或者多个保护产品，这些保护产品被预约所拥有。更进一步来说，合成关系表明如果预约这个对象被销毁了，他所拥有的保护产品也必须被销毁，因为当保护产品不再是预约的一部分之后，就失去了存在的意义。

在线上用空心菱形表示的，在汽车租用和汽车之间的是聚合关系（或者说，可共享的合成关系）。这也是个整体/部分的关系，或者说是一种拥有的关系，但是当我们销毁汽车租用的时候，我们并不销毁汽车。这符合常理：因为汽车不出租时，汽车对象会暂时成为“孤儿”，但是并不被销毁，只是把它提供给另一个汽车租用。

在关系两头的数字和* 符号叫做多样性描述。这些符号表明有多少个实例可以被连接到一个实例上。例如可以和一个顾客有关联关系的汽车的数量。或者，反过来，可以和一辆汽车有关联关系的顾客的数量。在这个类图里面，我们的多样性表明“对每位顾客，可以没有汽车预定，也可以有多项汽车预定”。反过来，就是“对每辆汽车，可以没有顾客预定，也可以有多个顾客预定”。

在分析中，我们试图确认，我们能够正确的表述和理解问题。对业务专家和分析专家来说，分析类图是一个有用的工具，帮助他们和技术人员一起审查设计，并且将设计进一步推进。

现在我们有了类，职责和一张显示类间关系的结构的类图。但是迄今为止，我们还没有涉及类的内部－没有操作和属性。而且类图是静态的。我们如何确认这些类能够完成我们在用例中描述的业务过程？这就是下一步的目的，这是一个非常重要的步骤，因为它将会把用例描述映射到分析类的潜在的操作上面。

回页首

用例分析第六步：确认分析类的行为

这些类如何协作完成预定一辆汽车这个用例？我们用UML交互图来找出分析类之间的这些交互动作。回忆一下前面提到的顺序图和协作图，就是两种交互图，它们是我们的用例实现的一部分，如图7所示，这是一张分析级别的顺序图，描述了预定一辆汽车这个用例。

图7：预定一辆汽车的分析阶段的顺序图

点击放大

你会看到，在这个图中我已经引入了一个非业务类－UCController。这个用例控制类表示的是一个尚未进一步定义的类，它的职责是从用户那里接收事件和消息。我发现大多数读者都会感到困惑：一个业务类（例如出租地点或者预约）来接收用户的消息？因此我通常会给我的分析交互图增加一个通用的用例控制类，来表示这个逻辑，而且方便了读者的理解。在设计阶段，我们会把这个类改名为ReserveAVehicleController，但是现在我用这个通用的名字UCController 来表示。

顺序图和交互图包括几乎相同的内容，它们只是表示方式不同而已。选用哪一种图主要取决于是否方便和个人偏好。在顺序图中，对象按竖列对齐，按照从上到下的时间线来顺序排列。标了数字和文字的水平线叫做消息。在一个顺序图中，消息的顺序用它们的位置来表示：按照时间顺序从上到下排列，因此排在下面的消息就在排在上面的消息之后发生。消息从一个对象的时间线上开始，在一条时间线上终止（一般都是另一个对象的时间线），但是有时也会终止在同一个对象的时间线上，如图7中的消息21。

顺序图与协作图相比，有一个非常明显的优点，就是在图左边的脚本。这些文字是从用例，或者场景中摘取的，对顺序图的描述。这些描述就是对预约汽车这个用例的一个简短的描述。通过把这些脚本放在图边，使得消息的含义变得非常清晰。而且把消息、对象和原先的用例相结合起来。用例中的每条语句都会对应图中的一个或多个消息，在顺序图上，这表示的非常清楚。

我想强调一下，在分析阶段的交互图中很重要的一点就是：消息表明了意图，而不是实现，也不是接口在预约汽车顺序图上，消息只是简单的表明了，我希望接收消息的对象做什么事情，消息并不代表一次函数调用。函数调用这些更具体的信息，会在设计阶段确定。但是现在，我们只需要在这个用例中，类的职责。

我们如何找出这些消息呢？只要看看我们的职责的定义就可以了。例如，在第八步中，租借地点要决定在这个地点，哪些汽车是可用的。在第九步中，汽车租借要提供在这个地点，能够满足用户要求的日期和时间的所有汽车。在第十步，租借中的每个汽车都需要回答它本身是否满足某些租借条件。请注意所有这些知识都不在租借地点这个对象中。我们把这些知识分布到了我们的所有分析类当中，因此每个类都可以按照定义来完成一部分工作。

UML说明：对象－是否需要命名？

在顺序图中，对象框没有名字“：”，这些对象叫做匿名对象。但是也可以为对象起一个名字。如果我们有一个类叫做Account，我们可以这样命名：

Account

如果我们建立两个Account类的实例对象，FredsStash和EthelsMadMoney，它们将是这样：

FredsStash ： Account

EthelsMadMoney ： Account

以左边的一个为例，表明“FredsStash是Account类型的一个对象”。如何决定是否给一个对象命名呢？如果系统中的一个实体类，有一个很清楚的名字，你可能想为它的对象起一个名字。如果你的图中有一个示范的对象（类似于数据模型中的数据表例子），你也可以用一个有名字的对象。但是对大多数情况来说，匿名对象就足够了。我们只关系类和对象提供了什么服务，致于对象的名字并不会影响到对象的行为。

回页首

用例分析第七步：描述属性和关系

在分析中，我们会发现，类为了完成自己的职责，会需要一些属性（也就是类的属性变量）。从类的职责列表中，我们可以确定分析类的一些属性。另外一些属性要从常识中得出（例如，每个汽车对象应该有一个独一无二的标识属性，与实际的汽车上的汽车联盟的标准汽车编号相对应）。

UML 说明：UML中的类在图上分为三段，以Account类为例，如下图所示：

图8中的类图上展示了汽车租借的分析类、它们之间的关系以及每个类所拥有的一些基本的属性。这些属性是由类的职责推理得到的一些很明显的属性。请注意这些属性都没有表明数据类型，因为数据类型是设计阶段的问题。

图8：类属性的起点

在当前这一步中，我们只需要表明顾客类具有一个叫做地址的属性就足够了。至于地址这个属性是什么样的，甚至需要不需要成为一个独立的地址类，会在后面的阶段中决定。你会发现汽车租借类还没有属性，它会变成系统的一个对外的接口。而汽车数据库需要哪些属性，则还根本没有决定。今后的阶段会解决这些问题。

回页首

用例分析第八步：验证分析机制

分析机制指的是高级的系统构建组件，它可以提供解决特定领域问题所需要的一些服务，而不是技术方面。例如，在保险领域，保单中的信息、声明和其它内容，在整个保险管理期间都是需要的。这个需求用分析机制来说，就叫做：持久化：无论程序是否运行，都一直维护数据的信息和状态。请注意我们并没有指定使用Oracle SQL，或是SQL Server这些特定的实现环境，我们只是列出了持久性，和我们后面会谈到的设计机制和实现机制。实现机制将会是与特定平台或者软件供应商相关的。

我们在表4中试着举例说明，分析、设计和实现机制之间的关系：

表4：说明，分析、设计和实现机制之间的关系

一些通用的分析机制是：

持久性
通讯（进程之间，或是应用程序之间）
意外处理
事件通知机制
消息
安全
发布（也就是说，被发布的对象）
遗留的系统接口

在汽车租借系统中，我们需要为这些指定分析机制：

回页首

结论

在“从用例到代码”的第一部分中，我们从一个用例开始，迄今为止已经找出了用来实现用例的类，它们之间的关系，和它们需要的属性。我们还找出了一些分析机制，在今后的设计和实现中会用到它。

如果我们对另一个用例再一次重复这整个过程，我们会发现另一些分析类，定义它们的职责，它们之间的关系。也许还会发现一些新的分析机制，画出新的协作图或是顺序图，来说明这些类如何交互。这演示了RUP过程的递增的特点：每个任务，每次迭代，都是在前面工作的基础之上进行的。

我们已经完成了很多工作，但是我们还无法开始写代码。下面我们的重点将会放到用例设计上面来，这就是本文第二部分的主题。

回页首

鸣谢

感谢IBM Rational的Peter Eeles和Zoe Eason，他们对本文的早期版本提出了深刻的见解和建议。

回页首

参考文献

Wirfs-Brock, Rebecca. Designing Object-Oriented Software. Prentice-Hall, 1990. A classic in object thinking and modeling. Introduces the significance of the responsibility-driven approach to software modeling和design.

Rumbaugh, Jim, et al. Object-Oriented Modeling and Design. Prentice-Hall, 1991, pg. 21. The defining book on the Object Modeling Technique, a major influence on the Unified Modeling Language.

The Rational Unified Process, version 2003.06.00.65. Rational Software Corporation.

回页首

进一步的读物

Ambler, Scott. The Object Primer, 2nd ed. SIGS, 2001. Covers end-to-end object-oriented development with a single case study.

Fowler, Martin. UML Distilled, 3rd ed. Addison-Wesley, 2004. Best introduction to UML (version 2.0) for those learning UML for the first time.

Taylor, David. Object Technology： A Manager's Guide. Addison-Wesley, 1998. One of the best introductions to object-thinking ever written.

Bell, Donald. "UML basics -- An introduction to the Unified Modeling Language," in The Rational Edge, June 2003： http://www.ibm.com/developerworks/rational/library/769.html

Bell, Donald. "UML basics： The activity diagram," in The Rational Edge, September 2003： http://www.ibm.com/developerworks/rational/librarycontent/RationalEdge/sep03/f_umlbasics_db.pdf

Bell, Donald. "UML basics： The class diagram," in The Rational Edge, November 2003： http://www.ibm.com/developerworks/rational/librarycontent/RationalEdge/nov03/t_modelinguml_db.pdf

Bell, Donald. "UML's sequence diagram," in The Rational Edge, January 2004: http://www.ibm.com/developerworks/rational/library/3101.html

回页首

注记

¹本系列文章所有对RUP的引用均来自RUP version 2003.06.00。文中所有UML模型均由IBM/Rational Extended Developer Environment (XDE) Developer Plus for Java version 2003.06生成。

²想了解更多有关职责驱动的信息，请参考Rebecca Wirfs-Brock的相关图书Designing Object-Oriented Software， Prentice-Hall， 1990。

³ Rumbaugh, Jim与其它人合著的Object-Oriented Modeling and Design， Prentice-Hall，1991， pg. 21。

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


		Gary K. Evans是Evanetics公司 (www.evanetics.com)的创始人。Evanetics公司是一个致力于推广使用敏捷开发技术和过程，来降低软件项目风险的咨询公司。他发表了数十篇面向对象技术方面的论文，开发了很多工具软件，还经常在各大软件会议上发表演说。他很喜爱足球，但是他更喜欢与一个开发小组一起工作，帮助小组成员使用面向对象分析设计方法，和敏捷RUP方法进行软件开发，与他们一起更快更好的发布一个个软件。他的电子邮件地址是 gkevans@evanetics.com 。

Rational Edge: 从业务用例和 Rational 统一过程中验证需求

2008-11-14T20:48:00.000-08:00

级别：初级

Adam Frankl, 市场营销副总裁, Ravenflow

2007 年 10 月 15 日

解读企业如何在软件开发过程中应用用例来作为验证需求的基础。

来自 The Rational Edge。

在应用程序开发项目的各个涉众之间进行有效的沟通往往非常具有挑战性，特别是当开发团队受到时间和空间上的种种限制的时候更是如此。IBM® Rational® 软件帮助开发组织通过 IBM Rational 软件交付平台对软件核系统核心业务流程进行自动的、集成的、可掌控的操作。平台的核心就是 IBM Rational 统一过程® (RUP®) 一种为软件和系统交付建立的迭代业务流程的灵活的框架结构。在超过二十年的成功实践的基础上，RUP 有助于开发组织减少项目失败的风险，提升一致性、可预测性、生产力和效率。

该 RUP 业务模型为业务用例提供了工具和符号，这些用例可以有效的促进涉众同领域专家之间的交流和验证。它允许业务分析师使用同样的符号和工具来记录业务流程，软件架构师和设计者也使用同样的符号来记录软件的解决方案。从而两组人可以更好的进行沟通，确保软件系统真正满足业务的需要。

什么是业务用例？

一个业务用例描述了一个业务流程，记录了一系列动作的顺序，这些动作为业务操作者提供了显而易见的价值。业务操作者可以使任何人、系统、或者同该业务或组织发生交互操作的事物。所以，业务用例应该描述业务做了什么（也就是同其外部环境进行了那些互操作），从而将价值传送给其涉众。要想全面的理解业务及其流程的目的，就必须知道是谁提出了要求，是谁输出的结果感兴趣。

另一种思考业务用例的方式是，它记录了特定的业务流程。事件流、或者工作流程流，是业务用例的一个关键要素。它描述了业务“做什么”才能将价值传送给业务操作者。任何参与该业务的人员都应当理解这种描述。（重要的是，这不同于那种对“如何”解决业务问题的描述）

无论开发项目所关注的是一个新的业务领域还是提供新的功能，验证业务用例都是 RUP 的一项至关重要的组成部分。Rational 统一过程业务建模原则通过提供工具和符号，提高了沟通和项目需求验证的效率。

业务用例模型

从业务参与者的角度来看，业务用例模型提供了蓝图。它以一种所有项目团队成员都能理解的方式描述了业务流程。但是，还有其他一些原因使得软件团队需要业务模型。软件在商业价值而非技术需要的驱动下，必须被快速的交付。一个好的业务模型能够为进程的自动化提供一个软件独立的描述，从而在技术选择之前提升对优先级和风险的包容能力。

IT 团队必须对业务加以描述，从而使团队成员做出正确的决定，包括涉及相关价值和开销因素的业务流程的明确的规格。业务用例通过包含文本描述和一至多个 UML 活动图被记录下来。图1为我们提供了一个业务用例规格的例子。请注意，左侧的图为右侧的业务用例文本中描述的工作流程结构提供了一个图形化的展示。

图1：一个业务用例规格的例子

图1的相应的工作流程描述。

“Customer Sales Interface”完成初始化操作。
如果“Customer Sales Interface”确定初始化机会工作已经完成，那么“Customer Sales Interface”发送一个请求到“Proposal Owner”。
否则，“Customer Sales Interface”寻找替代方案。
如果“Customer Sales Interface”找到了替代方案，那么就启动它。
“Proposal Owner”创建一个提议项目方案。
“Proposal Owner”发送一个提议项目计划到“Quote Owner”。
“Quote Owner”准备一个报价。
“Quote Owner”发送一个报价到“Proposal Owner”。
“Proposal Owner”分析这个提议并且确定这个提议。
“Proposal Owner”生成一个项目方案。
“Proposal Owner”完成附加的信息。
“Proposal Owner”发送提议到“Customer Sales Interface”
“Customer Sales Interface”呈现这个提议。
“Customer Sales Interface”获得客户的决定。

图1中组件的清单如下。

“泳道”或者列，显示哪一个业务人员在执行活动。业务人员将不会显示在一个为了业务用例本身所绘制的活动图里，但是他会作为业务用例实现的一部分被显示出来。
活动状态表现了工作流程中的活动或者步骤的执行情况。
跃迁表明了活动状态之间的顺序关系。这种类型的跃迁被称作完成跃迁。这种跃迁类型是在某一活动状态时完成某一活动所触发的。
每一个决定都已一套明确定义的守卫条件。守卫条件控制着在某项活动完成后触发一套备选方案中的哪一个跃迁。决定和守卫条件允许业务分析师在业务用例流程中展示不同的路径。

业务用例和仿真原型

用户接口原型能够大大促进验证用户用例的过程。通过接口验证所获得的反馈信息应当被整合进业务用例规格中，但是在原型建立之前生成用户用例规格十分重要。过早的在用户面前展示仿真效果会带来错失完整的问题定义的风险。在开始设计页面流程之前，业务分析师必须开启业务用例才能理解问题，理解进程流程。换句话说，业务分析师需要在设计特定页的仿真之前理解业务流程。

业务分析模型

业务用例模型描述了在业务操作者和业务之间发生了什么——不对业务的结构及其如何达到目标做任何假设——业务分析模型的目的就是描述业务用例是如何工作的。业务分析模型正确的定义了由业务提供的服务，定义了内部业务工作者及其使用的信息，将他们的结构组织描述为独立的单元，并且定义了它们如何互操作从而实现业务用例中所描述的行为。

业务分析模型通过提供一种业务系统、工作人员以及其他实体如何协作以执行业务用例的抽象，从而描述了业务用例的实现。它还定义了那些在业务用例执行过程中由业务操作者所调用的额外的业务服务。

涉众和业务流程分析师通过业务分析模型来理解业务的当前工作（采用如-是形式），并且分析变化对业务的影响（采用将要形式）。系统分析师通过该模型获取自动系统所需的要求，这种自动系统将作为业务流程的一部分被使用。软件架构师通过该模型定义无缝连接的软件架构，同时在软件分析和设计模型中定义类。由于业务方和 IT 团队方都采用同样的模型，所以这两部分人员拥有“共同的语言”，因此他们能够更好的沟通业务的真正需要是什么。

业务用例和软件开发周期

业务建模既可以是独立的也可以作为业务流程再工程的一部分，两种情况下它都向软件开发流程中添加了价值。具体来说，业务建模有助于定义系统需求。对于开发团队来说，需求处理部分就是分析待解决的问题。在更大的背景下从事这种分析有助于确保系统建成后达到业务的目标。

实际上，基于 UML 的业务模型可以直接输入到需求模型中。RUP 定义了两者之间的直接映射关系。如果要将一个业务模型映射到一个分析模型上：

要被自动处理的业务流程将呈现为一个用例。
业务用例将变成一个子系统。
每一个业务实体都将变成一个实体类。

这种映射为敲定需求和分析、设计工作流程提供了一个开头。当一个复杂的开发组织试图自动处理重要的功能时，业务用例模型是非常宝贵的。请确保企业解决的这个问题对于其业务的成败来讲至关重要。使用 UML 为业务和需求建模，是一种最好的重视沟通和良好项目成果的办法。

对业务用例的工具支持

无论是对于正确获得需求，还是对于同所有项目团队成员进行良好的沟通，工具都是非常重要的。它能够自动将文本用例转换成可视化的模型，从而大大节省了时间。

常见的错误往往在图中更加容易被发现，因此，快速生成可视化用例的能力就会加速迭代需求的验证过程。项目陷入困境往往是因为业务人员用语言思考，而架构师和设计师用模型回应。克服这种沟通障碍的最佳方式就是文本和图一同工作。在开发周期的早期阶段获得完整的需求和精确的可视化模型，是项目取得成功的关键。

图2指出了对于应用程序开发来说，适合 Rational 统一过程的需求定义、管理和建模工具流行于哪些地方。

图2：对于应用程序开发来说，适合 Rational 统一过程的需求定义、管理和建模工具是多么的流行

IBM Rational RequisitePro® 是一个需求管理工具，它可以让团队通过使用相似的、基于文档的方法来共享需求，同时使用激活的数据库功能（诸如需求追溯和效果分析）。结果中包括更加有效的对需求的沟通和管理，以及更大的按时完成项目的可能性，同时满足预算和以上所述的各种期望。

IBM Rational 软件建模器是一个功能强大的、基于 UML 2.0 的可视化建模和设计工具。它使得架构师、系统分析师、设计师以及其他人员能够从若干个角度同不同的涉众说明和沟通开发信息，同时，它还为 UML 2.1 建模提供了丰富的支持。

来自 Ravenflow 的 RAVEN 是一款经过验证的“为 IBM Rational 量身定做”的配套产品，它帮助设计团队开发和验证业务用例。“为 IBM Rational 量身定做”的称号表明了 RAVEN 达到了 Rational 的综合指导方针；它可以同 Rational 产品安全的完成互操作，并且提供了一致的用户体验。RAVEN 允许分析师同所有的项目涉众和用户一起通过从业务用例文本中自动生成图视图快速地指定和验证业务用例。它通过同 Rational RequisitePro 的互操作将业务视图保存在 RequisitePro 的数据库中。

原则 5: 用例描述：陈述“是什么”，而非“如何做”

学习

您可以参阅本文在 developerWorks 全球网站上的英文原文。
您可以参阅 Rational Edge 电子月刊中文版的其他文章。
注册今天的 Webinar

撰写，确认和管理业务需求的自动化解决方案：Ravenflow 和 IBM Rational RequisitePro

2007 年 9 月 5 日 - 12pm EDT - Ravenflow 赞助

准确地将业务目标和 IT 交付结合起来对于交付创新的业务应用程序是非常重要的。不幸的是，说远比做容易。复杂需求的沟通不足常常会导致项目交付延期，超过预算，或者缺失业务所需要的特性。参加 webinar 来学习 Ravenflow 和 IBM Rational 的 RequisitePro 如何形成一个完整的解决方案，获得正确的需求，并成功地在整个业务应用程序项目的开发和交付过程中管理它们，以及观看此集成的演示。

使用用例捕获业务需求

2008-11-14T20:46:00.000-08:00

导致区别的七个原则

级别：高级

Thomas Behrens, 首席技术官, Alpheus解决方案

2005 年 2 月 15 日

来自Rational Edge：这篇文章基于Simpay，一个通过移动电话操作的支付系统，的业务需求工程项目的经验，大致描绘了关于捕获业务需求的七个实用原则。

假定你已经有需求工程规范的一些经验，而且你突然面对一个包括多个公司，并跨越不同商业领域的重大业务需求方案。开始在你的心里出现问题：用例是否会在这个项目中使用？我应如何决定用例粒度的正确层次？我应如何构建用例模型？我必须裁剪标准的 IBM® Rational Unified Process 或 RUP以达到交付标准吗？这篇文章提供Alpheus，一位国际性的IT顾问，如何在Simpay（一个可共同操作的手持电话支付系统）组织需求工程项目 ¹ 中应对这些问题。它提取我们在项目中所学到的，成为七个实用的原则，它将举例说明你怎样在你自己的业务需求计划中取得成功。

该论述假定读者对需求工程，使用用例及对RUP的基本协议，有很好的理解。

Simpay 是关于开发联合现在分段的手持电话支付市场的、能共同操作支付的全新架构的第一步 ² 。图 1 显示业务上下文的概观。Simpay 占领这上下文的中心位置，使用开放的接口，来整合手持电话商业要求者（代表多个零售商及[或] 内容供应者）和手持电话操作者（代表并认证最终客户），成为在线金融交易。Simpay 为支付认证，结算并解决手持电话操作者与手持电话商业要求者之间的资金流，提供服务。 ³

图 1: Simpay 商业上下文概观

业务需求过程被嵌入到一个把支付解决方案（如Simpay 产品）转变进入市场的大型过程中。产品展现了一个使用手动或自动过程的、从头建造的、新业务。由于预算必须控制得恰到好处，因此决定延期实现确切的自动化过程，直到业务已经被建模。

整体项目及商业特性可以摘要为：

多公司（Orange，Telef a M es，T-Mobile和Vodafone）
重视规模方面（支持约二亿八千万客户）
拥有虚拟团队的多国公司
持有名誉方面的潜在影响
覆盖多重专家领域（举例来说，无线通通讯，财政服务）
规则加强器，拥有多种不同的法律约束

这些特性表达了许多关于建立所有企业涉众、共同的、一致的业务需求集合的重要性和可见性。

我们介绍一个与RUP ⁴ 结合的过程，跨越Simpay从商业想法到产品部署的项目生命周期。我们把活动和交付产物映射到 RUP的四个阶段（初始，精化，构建和产品化）及它们各自的里程碑。RUP 活动和交付产物最初剪裁为软件开发过程，然而项目已经有一个非常宽泛的范围（举例来说，一个交付产物是新公司的建立，如Simpay Ltd.）。然而，活动和交付产物有时大幅度地偏离 RUP 。而且，这个与 RUP最佳实践相反的进程，并不是可重复的。 ⁵ 然而，许多个别交付产物在重复的/增量的基础上产生，提供早期的评审，验证和质量保证，以及偶尔依靠早期的活动启动。

当我们想要在业务层次上捕获需求，而不指定特定交付产物是手动的或自动的，我们使用 RUP 业务建模规范作为我们的参考规范，并用需求工程的一些元素进行强化。对于我们定制的交付产物结构，参见文章的补充内容。

实践原则

下面，我们将讨论由我们的经验总结的实践原则。他们将会帮助你：

为你的业务需求寻找正确的边界（原则 1：得到正确范围）
适当结构化你的用例模型（原则 2：向你的用例目标和原则挑战；原则3：使用需求属性决定最好的用例模型）
进一步详细说明你的业务需求（原则 4：分而治之：通过业务参与者分解）
适当描述你的业务用例（原则 5：用例描述：阐明“ 是什么”，而不是“如何做”）
连接你的业务用例,避免冗余，并确认你的需求（原则 6：提出域模型和原则7：使用实体的生命周期）

原则 1：确定正确范围

需求管理的目的是为了确定正确范围。边界在哪里呢？谁在里面而谁在外面呢？这是更高层次的抽象，更为重要的。在范围方面很小的变化，就可能会带来与企业所有者相关，将要开展的工作，及项目运行的最后期限的重大影响。

让我们回顾图 1，这次把它当作一个市场视图。 ⁶ 这个视图显示购买（购物相互作用）和付款相互作用；它也显示Simpay作为支付中介。现在，比较图1与图2。除了使用不同的记号（UML）之外，图 2 显示两个不同的语境。上面一个是具有销售功能的商人的语境，它在购买商品用例中表现。下面的一个是 Simpay 拥有的支付功能，用请求支付用例表现。 ⁷

如果你认真地看，你将会看到这个特征把Simpay从市场视图分为两个部分：Simpay 产品和和 Simpay 有限公司。当我们发现 Simpay 产品不仅仅Simpay有限公司（也就是，中心实体）需要，也被移动操作者、及移动商家要求者实体需要时，这种区别是必要的。同时，这些实体识别到产品的功能；因此，所有的三方都在项目范围内。

这是在斤斤计较吗？不！它帮助我们清晰地建立项目边界。这意谓着我们可以从早期开始，就能避免不必要的讨论。在事后，这些区别可以看得很清楚，除了新的业务活动，为涉及到需求活动的当事者确定边界。然而，这是值得研究的工作。

图 2: 商业语境和 Simpay 语境

原则 2: 挑战你的用例目标

一旦你确定了你的范围，你可以开始确定用例和参与者。一个通常的问题是用例模型爆炸式快速增长，特别当你正在业务需求的抽象层工作的时候。很快的，你将会发现你需要表达很多内容。从字面上，停留在你的用例模型的顶层以避免“700 用例并发症”。如果你的用例模型正在爆炸式增长，你应该挑战你的用例粒度。对于 Simpay来说，在最高抽象层，我们以大约二十种主要用例作为结束。记住，一个用例传递值的一些东西给参与者；它为参与者实现一个目标。确保所有用例目标都在相同的层次上，并且对于业务建模来说所有目标都在抽象层上。

有一个来自 Simpay 语境的具体实例。支付可以立刻实现——支付授权 ⁸ 和支付捕获 ⁹ 同时发生，或延期实现——授权在捕获之前发生。图 3 显示了一个可能的用例图。然而，请注意用例所表现的目标并不在同一层次。商家的目标是接受支付。他必须服从管理规则，并把支付事务，分离为捕获之后的独立授权，这可能不是他乐意的。同时，你被迫表达在请求支付授权和请求支付捕获之间的一些关系。一个简单的解决方案是把这两个用例，结合为一个称为 Request Deferred Payment的用例。 ¹⁰ 你以更少的用例完成，并进一步得到易于理解的用例建模。

如果在授权和捕获之间有一个长的时间间隙，那是什么呢？这你无须关心！时间间隙并不是你分隔用例的指示器；尤其是业务用例可以是长期运转的。决定是否分隔用例的本质标准是他们的目标是否不同。

导致用例膨胀的另外一个危险是我称之为“睡莲并发症状”。当你为一个用例找到一种变化的时候，它就开始了；在 Simpay 例子中，它可能是支付发生的通道（例如，SMS，WAP）。你可能马上被我们例子中的多用途用例所诱惑（要求使用WAP，SMS等方式立即支付）。也可能存在更多的维数。很快地，你就可以像睡莲覆盖池塘一样，覆盖你的用例图。相反地，向目标挑战。如果你做些分析，你将会发现目标对于所有这些用例都是相同的。把焦点集中在本质的用例上，稍后你会知道表现这些变更的更好的方法（举例来说，在用例描述的特别需求部分）

同时, 当你确定支持目标，如维护重要的业务实体，把它们排除在外，使之独立并使用自己的图支持用例包。

图 3：不同的目标层次

原则 3：使用需求属性决定最好的用例模型

需求属性包含需求信息。优先级：显示一个需求对于商业用户有多重要。迭代：表明需求分配到哪个迭代。稳定度：指出哪些需求可能遭受变更。还有更多的属性，但是，让我们把目光集中到上述三个属性上。请确定你在坚持不懈地为你的用例捕获这些属性。为什么呢？因为他们可以使你的过程变成更轻松。特别地，你将时常会有关于如何构建用例模型 ¹¹ 的多种选择；当你这样做时，用上述的属性定位你的用例模型。这将产生最少的重构工作，并聚焦于你的工作。

实际上，考虑下列的指导方针以决定你的选择：

如果任何的这些指导方针违背原则2，并导致用例增加，不要应用指导方针！
如果两个用例有不同的优先级，避免合并它们。
如果两个用例被分配到不同的迭代中，避免合并它们。
如果两个用例具有不同的稳定性等级，避免合并它们。
不要为取得不稳定用例的模型花太多时间；这个功能可能根本上不需要改变。现在，把焦点集中在稳定用例上，以得到正确的模型。

记住：你如何重构用例模型将会影响其它的工作。业务用户将不得不找到适合新模型的方法，对于不同的可交付变量的追踪也将需要被更新。从一开始就正确地构建模型，也将节省其他人的时间。

在上面的例子中，我们坚决反对把延期和即付功能，归并到一个单一用例中（如，请求支付），因为“初始Simpay开发，可以而且也会包括延迟的或直接的支付 ”可能很快会被产生；无论选择哪种支付机制，其它的将是以后版本的范围。这种用例反复属性的变化，导致分裂为即付请求和迟延支付请求。

原则 4：分解和规则 – 通过业务参与者分解

现在你有一个结构良好并可以理解的业务用例模型。接下来你要往哪里去呢？一件重要的事情是不要把功能分解到你的用例模型中；即，不要把你的用例打破成较小的部分。这样的部分将会变成孤立的，违反用例步骤的最重要的优点之一：在参与者的目标语境中呈现需求。相反地，答案是递归地在当前语境中，基于用例步骤重新应用。

让我们回过头看看图 3。底部的 Simpay 产品语境显示由Simpay 有限公司，移动操作者和移动商业要求者实现的Simpay 产品。这些实体的 RUP 术语是 业务参与者 。这些业务参与者合作完成 Simpay 产品功能。一个，二个，或所有的业务参与者都参与每个 Simpay 产品用例。通过这一信息，你可以为每个业务参与者（由Simpay产品语境分配的）产生一个语境。每个语境由下面二者建立：(1)通过业务参与者划分用例，和(2)从现有的业务参与者派生出新的参与者。这个过程在图 4 中举例说明，它为移动操作者显示了一个实例结果。带有两段用例和一个新参与者（Simpay 有限公司）的新的移动操作者语境已经由更高抽象层派生出来。现在你能分开控制（相互调用）新的语境。 ¹²

这与功能分解有什么不同吗？是的！取替在Simpay 产品语境（不是由参与者目标激发的）创建孤立的部分的是，你已经用新参与者表现的精确目标，创建了更小的域。看看移动操作者语境的结果。明显地，Simpay 有限公司代表移动业务需求方（依次代表贸易商）做这些事情。然而，移动操作者的领域是自我包含的；它不需要了解Simpay 有限公司参与者做什么。相反地，功能分解方式将把用例分解成许多部分：获得商业细节；进行外汇交易；授权支付；捕获支付。哪种方式更适合管理方案范围呢？

图 4: 业务参与者划分。 点击这里放大。

很幸运；我们拥有感兴趣的业务代表，他们很快地就适应了用例方式，和有能力的技术队伍，他们的目标是把需求自动翻译成科技规范。然而，如同它被生成一样，业务代表尽可能地由状态激发，而且科技队伍对于强加于他们之上的不必要的限制因素感到不安。用例通过描述产品做什么来展现需求，以达到参与者的目标。“ 做什么 ”和“ 如何做 ”间的产品活动是人们特别是全球性的分布化团队不太清楚的一些事情，误解是正常的。这里有四种类型的指导方针可以帮助我们避免这些错误：

业务需求交付产物的结构

Simpay 产品（如这里所示）业务需求的可交付文档，采用了UML类图结构。过程框架和功能架构是高层次的业务需求文档，相当于针对 Simpay 产品的RUP业务视图和业务用例模型。在产品定义中捕获详细说明的业务需求，产品定义是接近于三个业务参与者（在Simpay中作为实体引用）：Simpay有限公司，移动操作者和移动业务需求方）的业务用例模型的文档集。对于 Simpay 有限公司，产品定义捕获了在RUP中引用、作为业务分析模型的东西。标准的 RUP 交付产物内容已经被修改，因为：

业务需求存在于两个抽象层面上（例如，Simpay 产品和移动电话操作者或Simpay 有限公司或移动业务需求方）
在第二个抽象层上要求两个不同层的细节：
a）一个层次是为 Simpay 有限公司确切描述，如何建立业务需求，或者通过技术解决方案自动实现，或者由操作者手动编写。
b）另一个层次主要是为移动操作者和移动业务需求方，描述设计准则（不包括个别实体）。

特定的自然语言表达有技术内涵。（举例来说，回路）。如果你使用这些表达，确定他们在作为技术设计建议时不会被误解。
业务用例描述商业流；它们决定谁是信息的来源，以及谁是目标。它们没有暗示流的技术实现。没有明确定义信息是否要推或拉，信息交换是批量的或在线的，是否要使用缓存。这样的技术性的决断主要关联到非功能需求。确定人们理解业务用例中的词，例如联系、请求，不要为基本的技术交流基础设施暗示技术约束。
争取涉及参与者及产品间的简单交流模式。尝试遵照同步请求/响应 ¹³ 沟通模型。这暗示一个请求的响应在用例描述持续情况下，或者被接收，或者不被接收（举例来说，在超时的情况下）。当用例已经在它的描述中继续前进时，它不可能接受响应。请求的表达是充分的，并且它简化了描述。应强调的是，它并不暗示同一模型的技术性实现。
当你为用例步骤编号时，人们通常认为你正在下令应该如何完成功能。 ¹⁴ 然而，用例步骤的顺序通常仅仅关系到参与者的下一个交互。当在这样一组步骤的特定顺序被托管时，请习惯于跟随明确的状态。

交流这些指导方针是重要的。对于 Simpay 来说，我们在产品概述文档（见页面边栏）捕获它们。在RUP中最适合做这件事的地方是用例模型，指导方针文档。更为重要的是，如果你正工作于定制的过程之中，要有一个试验。选取一个用例，并努力与整个队伍前进一致，这样每个人都会对你将如何生成事务及管理期望，感到满意。

原则 6：提出域模型

在 RUP 中一个域模型（见图 5）被定义为：在域的语境中捕获最重要类型的对象。域模型是业务分析模型的一个子集，业务分析模型包含描述业务参与者（见原则4）和业务实体如何获得用例功能的业务用例实现。域模型很有用，即使你不提出业务用例实现。它通过为你的用例描述提供具有精确含义的通用词汇术语，来连接你的各个用例。域模型确保相同的术语指向相同的业务实体。正好也捕获如下类型的需求：

业务实体和它们的多样性之间的联系（举例来说，一个移动用户使用一个或多个移动电话）
限制因素（举例来说，一个支付不能够超过一个特定的数值）和推导规则（举例来说，利息计算），尤其当这些不仅仅与一个用例相关时

结构化你的域模型文档，为这一信息（见到图 5）加入占位符。在我的经验中，业务用户对这些细微改进的形式感到相当满意，而且它为你提高稳定性和完全性检验：

所有的业务实体及它们的属性是否都已经定义？
你是否已经捕获了所有的联系？
所有涉及的业务实体是否至少在一个用例中？
所有涉及的业务实体是否都存在于域模型的用例中？

当创造域模型的时候，除了根据常识和你的读者偏好之外，你能使用下列的指导方针：

使用图帮助描述，尤其是显示业务实体间的彼此联系。
宁愿冗余的泛化；否则，你可以从你的业务用户那里要求。
对于简单的关系类型使用属性；否则，你将会使你的图混乱。
当属性的类型会明显避免制造困惑时，忽略它们。
如果识别符（比如用户ID）与商业无关，忽略它们。
只有当参与者名字有助于澄清语境的时候，才使用它们。否则，意味着把业务实体作为参与者命名，以避免弄乱你的图。
产生相关条目的简单导航技巧。域模型将会时常被用于查找信息。对于 Simpay来说，我们使用IBM Rational Rose为域模型捕获信息，使用IBM Rational SoDa来产生简单的导航文档。

一个域模型如何与一个术语表相关联？一个术语表定义了项目中使用的重要术语。以这个定义为基础，一个域模型是术语表中术语的一个子集。但要避免冗余：在术语表或域模型中定义一个条目，但是不要在两者里面都下定义。通常，当你知道更多关于你的商业域时，术语从术语表转移到域模型。然而，你的术语表对于那些不存在于业务实体中的术语，仍然是有用的交付产物内容。

图 5：域模型图和相关文本。 点击这里放大。

原则 7: 使用实体生命周期

实体生命周期在商业规范中未得到充分利用，但是，一个好的解决方案是可用的：UML状态图。你为什么要使用这些，以及它们如何关联到用例？业务实体（举例来说，一个移动使用者）通常有跨用例的生命周期。一个在状态之间的用例过渡（通常是不同的，状态图给一个统一视图，它关于你的重要业务实体在哪里，如何被操纵。图 6 显示一个关于移动使用者业务实体的例子。转变表现了维护移动用户的用例 ¹⁵ ，并在不同状态间转化它。

作为一个分析师，你也可以使用状态图保持你的需求集的一致性和完整性。我的业务实体是如何成为实物的呢？我是否已经错过了一个重要的状态？我是否已经描述我的用例中支持的所有转变的所有状态？我是否错过了影响转变的特别条件？

限定最重要的业务对象的生命周期，而在你的文档中描写所有状态。你的用例将以正确定义的域模型术语，描述涉及的这些状态，在保持可读性的情况下，把歧义从你的规范中排除。一个用例描述（涉及到图 6 所示的实例）会如下被看到：

4. 移动操作者确认移动用户并未被禁止。

这种禁止状态 指明了移动用户所处的状态，并为状态展现了一个非常精确的定义。依赖参数选择，你可以使用格式来强调文本中的状态。

生命周期最好作为由业务实体定义（如图5所示）耦合的附录，置于域模型中。你能够使用IBM Rational Rose来维护状态图并文档化状态，而且你也可以使用IBM Rational SoDa 产生易于操纵的文档。

采用这种方式，当你把实体生命周期置于业务用户之前时，你可以就像技师 ¹⁶ 一样，在没有做出需求时，平衡使用它们的好处。

一个对于未来的调查：通过模型驱动架构， ¹⁷ 你将会独立于一个特定的平台，受益于预先指定的精确性态。除此之外，可运行的 UML 将会使你可以在你开始着手不惜代价的细分你的需求之前，确认你前面的模型。

图 6：状态图：手机用户 -- 生命周期

回页首

用例是捕获业务需求的一个优秀的方法。只要你定义适当的抽象层，以支持可理解及可追踪的全部细节，他们就可以通过大的项目很好地伸缩。仅仅增加用例的数目并不起作用。确认你的需求的业务用户，会对基于用例的方法感到非常舒服。关于这种方法，精心描述你的自动化业务用例，让技术需求的技术团队通常更容易被接受。

因此，如果你被分配了一个复杂的业务需求项目，不要绝望。通过应用用例方法于需求工程，一个由可靠的开发过程及本文中呈现的原则，细化支持的方法，你就能克服许多挑战，并使方案成功。正如我所做的，你甚至可能已经发现，它是一个令人满意的实践。

回页首

感谢

我很感谢在 Simpay 中的人们，因为他们在本文中描述的方法中所承担的工作。特别是Tim Jones，Simon Richards，Martin Rugfelt 和 Jim Wadsworth。特别感谢我的同事Martin Elliffe提供了有帮助的说明及建议。

回页首

脚注

¹在这该文章中，我使用需求工程，作为业务需求工程一个简称。

²本文所用的例子来源于宽泛的Simpay语境。一些已经被简化了，仅仅用来论证要点和要求的观察保密性。因此，请读者不要把这些例子，理解为真实的Simpay活动。

³更多关于 Simpay 商业模型的细节，见 www.simpay.com。

⁴更多关于 RUP 的细节，见 Philippe Kruchten的《The Rational Unified Process. 》，Addison-Wesley，2000及 http://www-306.ibm.com/software/awdtools/rup/index.html。

⁵非迭代交付的主要障碍是，IT解决方案和它的操作者是由第三方转包，并通过一组法律合同集成到整个过程的事实。一个迭代过程会在这些法律合同中增加重要的复杂性。

⁶尽管不是与RUP关联的标准4+1 视图的一部分，但这一视图是基本的。在最后，你不得不出售你的产品。

⁷两个语境有很明显的关系。作为在商业语境中购买产品用例的一部分，商业触发器支付请求使用 Simpay 语境中的例子。

⁸商人确定手机使用者能支付和为他储备的货币。

⁹商人请求应支付给他的金额。

¹⁰实际上，你甚至可以更进一步考虑，并有一个独立的支付请求用例：我们的确决定反对它。理由是范围管理, 但是继续向下看。

¹¹我不在这里讨论扩大并包括联系。以我的经验，最好在你的业务用例模型中避免这些联系。

¹²在《 The Object Advantage》（Addison-Wesley，1995，第173页），E.A. Jacobsen 介绍了一个算法，用于映射一个业务用例模型到一个系统用例模型。这里使用一个类似的算法，把一个业务用例模型映射到不同语境中的另一个业务用例模型。

¹³在确定的环境中，你可能有一个不存在响应的请求。如果响应没有业务含义，这与被提议及将被使用的模型完全一致。

¹⁴相反地，我强烈建议你使用一个有细密纹理的编号样式，作为用例描述。它允许你改良一致性、完整性检查及参照。

¹⁵如果一个用例在多种状态间转换为业务实体。你可以转换为备选流或一组步骤（举例来说，使用标签或你用例描述的数字记号）。

¹⁶让我强调一下，它们可能看起来象技师，但是它们不是技师，因为它们仅仅书写商业决策的文档。

¹⁷更多关于模式驱动架构的细节，参见 http://www.omg.org/mda 和 Behrens，Richards的《 StateLator in Advanced Information Systems Engineering》，Springer，2000。

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