您的位置：软件研发->应用Rational 工具简化基于J2EE的项目（四）
应用Rational 工具简化基于J2EE的项目（四）2007-11-15 来自：conanpaul [收藏到我的网摘]
在这个展示了 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: 关联需求与用例
我们已经在模型中建立起了这些关联，我们可以跟踪需求到用例，相反也可以。双向的可跟踪性是十分重要的，因此我们既可以发现遗漏的需求也可以发现新添加的需求。遗漏某一需求是不可接受的，跟踪需求到用例可以使我们很容易的发现我们的任何遗漏。添加需求而没有清晰的调整将导致项目范围的蔓延并对项目的时间计划和预算有着负面的影响。为了防止这一切，我们应该跟踪所有的用例到每一个存在的 SOW 需求或者变更请求。
不像跟踪需求到用例，反方向的跟踪经常被忽略，但是我们可以很容易的在 Rose 中完成这一点。为了浏览与一个用例相关联的 SOW 需求，我们简单的在 Rose 模型中右键点击用例，并选择从上下文菜单中选择 View RequisitePro Association 。这会弹出一个窗口指示哪一个 SOW 需求是被选择的用例跟踪的，如图 4 所示。如果用例没有被映射到一个 SOW 需求，底部的两个域将显示 “NONE” 。我们也可以通过 Rational SoDA 产生更加复杂的跟踪报告。
图 4: 被 Rose 报告的对于一个用例的 SOW 需求
这个第 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: 关联需求与用例
我们已经在模型中建立起了这些关联，我们可以跟踪需求到用例，相反也可以。双向的可跟踪性是十分重要的，因此我们既可以发现遗漏的需求也可以发现新添加的需求。遗漏某一需求是不可接受的，跟踪需求到用例可以使我们很容易的发现我们的任何遗漏。添加需求而没有清晰的调整将导致项目范围的蔓延并对项目的时间计划和预算有着负面的影响。为了防止这一切，我们应该跟踪所有的用例到每一个存在的 SOW 需求或者变更请求。
不像跟踪需求到用例，反方向的跟踪经常被忽略，但是我们可以很容易的在 Rose 中完成这一点。为了浏览与一个用例相关联的 SOW 需求，我们简单的在 Rose 模型中右键点击用例，并选择从上下文菜单中选择 View RequisitePro Association 。这会弹出一个窗口指示哪一个 SOW 需求是被选择的用例跟踪的，如图 4 所示。如果用例没有被映射到一个 SOW 需求，底部的两个域将显示 “NONE” 。我们也可以通过 Rational SoDA 产生更加复杂的跟踪报告。
图 4: 被 Rose 报告的对于一个用例的 SOW 需求
推荐人评论
在这个展示了 RUP 和其他 Rational 工具使用的样例项目的接下来的阶段，用例通过添加文档和可跟踪性到需求被细化，并且使用的工具和技术被评估和选择。
用户评论
正在载入评论列表...
是谁推荐了此篇文章
MichaelCSDN测试频道编辑 联系email:mjj@csdn.net
- Michael推荐的其他文章