第 4 部分 ：分析和工具的进展
Steven Franklin
软件设计师和过程专家
2004 年 4 月
在这个展示了 RUP 和其他 Rational 工具使用的样例项目的接下来的阶段，用例通过添加文档和可跟踪性到需求被细化，并且使用的工具和技术被评估和选择。
这个第 4 部分文章的重点在于 ASDI 项目的细化阶段，尤其是在用例分析方面（细化我们的用例以对工作状态（SOW）添加可跟踪性，并且标准化和生成用例文档）并选择合适的工具和技术。
第 4 部分快照
在第 4 部分演示的工具和技术：
Rational Rose 企业版 — 用于用例细化
Rational SoDA — 为客户检查的低成本的产生用例文档的工具
Rational RequisitePro — 用于治理 SOW 需求和用例之间的可跟踪性
产生或者被更新的产物：
Rational Rose 模型 — 被修改并在用例的各个方面添加了更加具体的内容
用例报告 — 用 Rational SoDA 从 Rose 用例中生成
RequisitePro 数据库 — 被更新以包括SOW 需求和用例之间的可跟踪性
细化并文档化用例
图 1 显示了在 ASDI 项目的第 1 阶段（RUP 的初始和细化阶段）中的用例的演化。就像我们在第 3 部分讨论的，我们在初始阶段创建了业务用例，然后在细化阶段的初期将业务用例转换成体现了“目前的”系统的用例。现在我们是在细化阶段的最激烈的时刻，我们正预备细化我们的用例，为系统完成向具体需求的转换。这个演进是自然形成的，因为直到断定了是否我们开始定义的用例是正确的，我们才可以为用例进行更为具体的信息添加。一旦具体的系统需求被完成，我们将它作为一个正式的交付物被 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: 关联需求与用例
