【IT168技术文档】本文中所虚构我们是一家软件公司 Lookoff Technologies Incorporated，我们的客户 Audiophile Speaker Design, Inc. (ASDI)，它雇用我们实现他们最初的 IT 需求。

细化并文档化用例

    图 1 显示了在 ASDI 项目的第 1 阶段（RUP 的初始和细化阶段）中的用例的演化。我们在初始阶段创建了业务用例，然后在细化阶段的初期将业务用例转换成体现了“目前的”系统的用例。现在我们是在细化阶段的最激烈的时刻，我们正准备细化我们的用例，为系统完成向详细需求的转换。这个演进是自然形成的，因为直到断定了是否我们开始定义的用例是正确的，我们才可以为用例进行更为详细的信息添加。一旦详细的系统需求被完成，我们将它作为一个正式的交付物被 ASDI 审查通过。

图 1: 第 1 阶段用例的演进

标准化用例文档

在我们与 ASDI 对用例进行非正式的检查的会议中我们对用例进行了注释。用例图和包也被我们的高级团队成员定期的检查了，一个“健全的” 检查将带来以下的结果：

• 将不稳定的或者遗漏的方面反馈给组长
• 有用的分析建议、模式和功能分解方面的考虑
• 一致的系统视图
• 工程团队对详细需求的交流

我们现在的重点是记录我们已经了解到的东西。我们与 ASDI 在用例文档的形式上达成了一致，并且我们非常高兴他们愿意接受在 Rose 模型 中对每一个用例直接添加文档的方式。这对于我们来说，事情变得更加简单了，因为这意味着更低的对文档美观的期望。

在多个团队成员共同工作的情况下，我们发现我们需要标准化与每个用例相关联的文档。因此，我们起草一份用例的文档模板，并应用于 Rose 模型的每个用例中。在图 2 中显示的内容是被粘贴到每个用例作为模板的文档窗口。注意我们在这个模板中使用术语 “variation” 作为对 RUP 可选流概念的速记标记。

图 2: 用例文档模板

    在项目的后来，我们意识到在模型（ *.mdl和 *.cat）文件中有大量 ASCII 形式的文档，使模型的加载慢了下来。感谢我们的快速的电脑，这个副作用还可以被容忍，但是在后来的项目中我们使用了更加正式的方法来维护用例的内容，通过一个自定义接口的方式。（就像在文章 "Fine Tuning Rose to Complement Your Process" 所讨论的那样）另一个可选的方法是使用 Rose 附带单独的 Microsoft Word 文档到用例的特性（通过右键点击用例并从上下文菜单中选择 New > File ）。

用例的可跟踪性

    ASDI 原来的期望是 SOW 将最终成为一个大的文字形式的文档。我们通过与他们的不断的讨论，最终他们意识到这种方法的缺点，并作出了让步的姿态。他们现在明白了使用用例的好处并很快的掌握了相关的概念，并理解了使用用例将给他们一种不需要对模型进行预排的非常强大并适当的反馈的方式。无论如何，一个好的时间和精力的分配已经进入了 SOW ，可以理解 ASDI 希望我们能够确保不会遗漏任何在 SOW 中被捕获的东西。

    为了提供这个保证，我们使用了 Rational 的工具来建立在 SOW 需求和我们的相当稳定的用例之间的可跟踪性。首先我们通过 RequisitePro 将 Rose 模型与被管理的需求文档关联起来，通过选择 Tools > Rational RequisitePro > Associate Model to Project 并选择 SOW 。然后我们相应的映射每一个用例到主 SOW 需求，通过右键点击用例并在上下文菜单中选择 Requirement Properties > New 。如图 3 所示，我们展示了一个 SOW 需求列表，并从中选择适当的需求。

图 3: 关联需求与用例

    我们已经在模型中建立起了这些关联，我们可以跟踪需求到用例，相反也可以。双向的可跟踪性是十分重要的，因此我们既可以发现遗漏的需求也可以发现新添加的需求。遗漏某一需求是不可接受的，跟踪需求到用例可以使我们很容易的发现我们的任何遗漏。添加需求而没有清晰的调整将导致项目范围的蔓延并对项目的时间计划和预算有着负面的影响。为了防止这一切，我们应该跟踪所有的用例到每一个存在的 SOW 需求或者变更请求。

    不像跟踪需求到用例，反方向的跟踪经常被忽略，但是我们可以很容易的在 Rose 中完成这一点。为了浏览与一个用例相关联的 SOW 需求，我们简单的在 Rose 模型中右键点击用例，并选择从上下文菜单中选择 View RequisitePro Association 。这会弹出一个窗口指示哪一个 SOW 需求是被选择的用例跟踪的，如图 4 所示。如果用例没有被映射到一个 SOW 需求，底部的两个域将显示 “NONE” 。我们也可以通过 Rational SoDA 产生更加复杂的跟踪报告。

图 4: 被 Rose 报告的对于一个用例的 SOW 需求

    注意在这个方法中使用一个捷径是重要的。通过我们使用的方法，我们可以仅仅可以每次关联一个用例到一个需求，反之亦然；然而，一个用例实际上是可以跟踪回到几个需求的，同样一个需求可能分布到多个用例中。我们不必苦恼映射多对多的关系。我们直接将用例关联到 SOW 中的需求，但是更好的方法是引入一个被 RequisitePro 管理的用例规格文档，它包含很多用例需求的文字描述并可以实现多对多的映射。（详细的描述可以在 Rational 白皮书 "Use Case Management with Rational Rose and Rational RequisitePro"中被找到。）我们现在觉得用例规格文档是我们不应该跳过的重要步骤。

用例文档的检查周期

    我们与 ASDI 都明白文档频繁的检查周期会导致无止境的循环下去。结束任何文档都是困难的，因为每一次阅读文档时检查人员经常会产生一些新的想法。在迭代的方法中，相同的 “何时结束的” 的挑战也会出现在软件的文档和其他任务中。为了满足 ASDI 对关于结束的关心，我们描述了我们对用例文档的检查周期将是什么样的，我们努力的借用了 RUP 中所描述的概念（见图 5）。

图 5: 文档检查周期图

    就像你所看到的，我们的每一个文档都经过了一系列的迭代。对于我们来说找到一个工具来支持它是重要的，我们在 Rational SoDA 中发现这样一个工具，它允许我们生成 Rose 模型以外的文档。虽然对文档直接做修改是诱人的，但是这将带来文档与模型不同步的风险。如果你将在一个或其他的文档中投入精力，更好的方法是在模型中投入精力。除了你开发的软件用户手册以外，模型几乎是可以在软件被交付后还可以继续被引用和维护的产物。

    通过使用 SoDA ，产生报告是简单的。为客户的检查生成用例文档，我们从 Rose 的 报告菜单中选择 SoDA Report ，这将出现一个报告模板的列表，如图 6 所示。从中我们选择 a RUP use-case model survey 模板。

图 6: SoDA 报告选择

    每一个模板提供了一个缺省的报告（作为 Microsoft Word 文档）伴随一个空的部分和相应的内容表格（TOC）。图 7 显示了我们选择报告的 TOC 。我们通过与 ASDI 检查 TOC 开始，并且我们查看了我们的用例以决定是否需要在报告中根据我们的需要进行合适的裁剪。

图 7: SoDA use-case survey 报告（TOC）

    你可能想知道在写任何实际的内容之前，为什么我们担心与 ASDI 一起检查 TOC 。我们发现这是一个重要的步骤。有时 ASDI 给我们一个 DID （数据项描述），它对正式的交付物提供一个 TOC ，但是我们发现在开始充实内容之前根据 TOC 从 ASDI （或者内部的团队检查人员）得到信息是有用的。有时我们在每一个部分填写显示我们将如何细化的标题，但是在首次的 TOC 检查时几乎没有任何的段落内容。

    后续的文章部分将讨论 Rational SoDA 和 模板定制的更加详细的信息。

细化：不只是用例

    为了使生活更加有难度， ASDI 期望我们在继续随后的任务之前创建用例文档。我们必须提醒他们用例文档直到软件被交付才会被 “完成” ，除非他们不想让我们在需求变化或者新需求出现时更新用例。我们说服了他们，他们不会对 完成的里程碑甚至是 自信的里程碑感兴趣。然而，他们希望放一个检查标记到下一个要做的 “详细的用例文档”项，因为它是十分成熟的，我们同意这个观点。

    真正的挑战是说服 ASDI 所有需要的活动应该是并行的发生，而不是所有的里程碑都是按照顺序被交付的。我们把它作为在项目早期的一个常规的关注点，它仍然没有被完全的解决。为了让他符合用例分析的一些活动，我们提出了这两个观点：

• 屏幕的模拟将简化需求的检查，并可以比用例讲述一个广泛的经过。
• 没有一些前瞻性的原型，工具获得、安装和培训不应该发生。

    我们非常高兴 ASDI 同意模拟和原型作为分析阶段的有用的部分。这使我们可以在用例分析被完成前进入到架构的和工具的选择问题中。