j2ee|项目
第 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: 关联需求与用例
我们已经在模型中建立起了这些关联，我们可以跟踪需求到用例，相反也可以。双向的可跟踪性是十分重要的，因此我们既可以发现遗漏的需求也可以发现新添加的需求。遗漏某一需求是不可接受的，跟踪需求到用例可以使我们很容易的发现我们的任何遗漏。添加需求而没有清晰的调整将导致项目范围的蔓延并对项目的时间计划和预算有着负面的影响。为了防止这一切，我们应该跟踪所有的用例到每一个存在的 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 同意模拟和原型作为分析阶段的有用的部分。这使我们可以在用例分析被完成前进入到架构的和工具的选择问题中。
选择工具和技术
工具和技术选择从来就不是微不足道的任务，虽然它常常被忽略。团队经常根据启动成本、“小工具因素”、好奇心或者对工具和技术的忠心来作出选择，相反，他们应该考虑生产成本、可靠性、可得到的培训、团队技能和特性标准。在评估过程中添加一些正式手续可以确保工具的选择使基于项目需要的而不是个人主观的意见。
正式的工具评估
一个在 RUP 中很少关注的地方是团队挑选现货（off-the-shelf）— 也称作商业现货供应 (COTS) — 工具的过程。可以了解这个过程领域知识的一个地方是卡内基－梅隆软件工程学院（SEI），那里有 COTS-Based Systems Initiative 关注于 COTS 产品的选择和采纳的策略。特别有趣的是 SEI 的 product feature checklist ；虽然它更关注于选择软件系统的组件和框架，但是其中的很多策略也可以被用于选择软件开发工具、Web 服务、数据库等等。
工具选择标准
ASDI 向我们展示了这些他们觉得将影响我们的工具选择的标准：
他们最终承担系统的核心开发和维护团队包含 3 到 5 个人。
系统能够被 4 到 7 个内部用户和 1 到 5 个来自于 20 到 30 个公司的外部用户访问（虽然系统的将来版本将支持数千人在线用户）。
跨平台技术是重要的， 因为 ASDI 期望在数年中这个系统仍然是可用的。
对所有技术的培训必须是容易得到的。
他们强烈首选基于 Java 的解决方案。
他们首选 OODB （面向对象的数据库）作为数据的存储。
系统的早期版本将运行在 Linux 系统上，虽然之后将运行在 Solaris 系统之上。
开发人员需要能够在 Windows 2000 的机器上有效的使用软件。
性能不会是重要的挑战，因为在同一时刻仅有少数的用户与系统进行交互。
应用服务器的选择
我们拥有 J2EE 应用服务器的经验，因此我们非常幸运 ASDI 选择基于 Java 方案。不过在我们还是快速的评估了象 Perl/CGI 和 PHP 这样的入门级的 Web 方案之后的计算技术（主要是 Microsoft .NET/DNA）。
我们一致发现 Orion Application Server 是友好的并是最成本有效的开发环境。在那里 Orion 唯一评分低的方面是 供应商的稳定性和支持。提供 Orion 产品的公司是非常小的并且不具备象 BEA 的 WebLogic 或者 IBM 的 WebSphere 的能力和信誉。然而在与 ASDI 的检查人员讨论后，我们互相同意 Orion 的 J2EE 标准遵从的好处足以抵消这些风险。如果第二阶段开发需要，仔细的开发将可以确保我们拥有轻便的可以移植到其他应用服务器方案的代码。因此我们选择了 Orion — 这意味这启动成本为零，因为 Orion 是免费的。
Web 服务器选择
Orion 带有高速的内建的 Web 服务器，因此当 Orion 被选定后 Web 服务器的选择过程也就有了结论。它主要的竞争对手是 Apache 。然而，在 Orion 网站上显示 Orion 已经在某些测试方面达到并超过了 Apache 。
数据库选择
使用哪一个数据库的选择不是显而易见的。数据库通常不会执行高负载，但是它需要有丰富的特性支持。比如，复杂的数据关系要求有完全的引用完整性限制。同时，系统必须可以 24 小时不间断运行，因此我们希望它具有热备功能、复制、其他的可用性和容错特性。我们是否会用到所有的特性将在以后被决定。
我们觉得 PostgreSQL 仅仅是一个有资格的开放源码的候选者。它有很好的 ANSI SQL 支持和引用完整性，并且只要并发用户的增长不太大它可以保持良好的性能。然而，数据存储需要更多的来自于一个供应商的 committed 支持。此外，我们觉得 PostgreSQL 在线支持（比如用户社区讨论）对我们来说是不够的。MySQL 实际上是更加流行的开放源码的数据库，但是它缺少太多的特性（比如，外键支持）。
然后我们转到主流的数据库：DB2， Oracle， and Microsoft SQL。我们在 Oracle 上有着丰富的经验，但是新的处理器单元价格模式对于我们的这个应用来说是过于昂贵了。Oracle 的每 MHz 每 CPU 的基本负荷，意味着 ASDI 将为系统忍受高的生产环境成本，除非他们愿意将 Oracle 安装在一台 P-133 的机器上。Microsoft SQL 被淘汰了，因为它是基于私有平台的。如果创建一个基于 DNA 的方案，Microsoft SQL 自然是首选的，但是对于 J2EE 来说很少被选择的。
最后，我们选择了 DB2 ，我们的调查表明 DB2 对 SQL 有着非常优秀的支持、强大的容错特性、公道的价格模式和正在增长的和被培训的在线用户集合。 IBM 的 JDBC 驱动是高性能的，而且他们的个人版可以被免费的用于开发团队中。不幸的是，我们缺乏 DB2 的技能，这就意味着一些培训在原型活动期间被需要。
你也许正想知道对于 ASDI 首选的 OODB 的选择发生了什么。在通过原型和探索产品后，我们很快个到了结论，使用 OODB 得到的好处不足以抵消它带来的风险。关于这个的更多思想，看下面的文章 引用和其他资源 。
集成开发环境（IDE）选择
在这一点上，我们不想使用任何高端的 IDE 产品，有几个原因：
我们并不明确第 1 阶段概念的证明需要使用 Enterprise JavaBeans 。
IDE 的投入是昂贵的。
团队的成员已经有了他们自己的选择。
因为第 1 阶段的时间是很紧的，使用如 IBM 的 VisualAge 所带来的学习曲线是我们无法承受的。
相反，我们混合使用了以下工具：
JCreator — 免费的基于 Java 的 IDE
CodeGuide — 低成本的 IDE
log4j — 简化服务器端 调试的日志工具
Jikes — 快速严格的 Java 编译器
很自然，这些工具可通过使用 Rational 工具来弥补在测试、调优和代码覆盖上的缺乏。
总结
在这个阶段我们看到了用例的演进（通过可跟踪性和文档化）并且通过 ASDI 参与的用例的检查，我们快速的发现我们是自由主题方式的专家。这通常是软件开发项目中的最大挑战之一，因此早期的并有效地建立这种关系才是真正的胜利。我们与 ASDI 的关心通常是很好的。他们很快的理解并同意了基于 RUP 的开发过程而没有花费我们太多的精力。这是令人惊讶的，被他们给的首选的瀑布型的开发最终取得了这个和约。很多被 RUP 鼓励的迭代和增量开发的方法被良好的进行了调整，并且 ASDI 也看到可好处。
我们幸运的是工具的选择相当的简单，并在项目的早期被完成。Rational 的一些工具被用来节省我们的时间。在之前的项目中我们使用 Excel 来管理需求，但是我们发现 Rational RequisitePro 是一流的并是完整的方案。此外， Rational SoDA 报告可以大大的降低我们的文档生成的成本。因为这个项目是我们第一次使用 SoDA，我们非常高兴 ASDI 对标准的 SoDA 模板表示满意。
计划未来
到现在为止，我们把焦点放到了需求相关的产物上，并且花费了相对来说不多的时间来评估技术并创建原型以支持工具的选择。现在对我们来说重要的是通过创建更有挑战的原型来揭示系统更加复杂的领域，并开始在实际的开发中使用工具。我们是否会用到 XML ？如果会用到，我们应该使用什么样的解释器？我们需要什么样的安全机制？我们应该使用 Enterprise JavaBeans 吗？象这些问题我们将很快有答案。
换句话说，是时候从分析转移到架构和设计了 — 尽可能快而不是晚，因为大多数的技术风险将在接下来的几周显现出来。我们有一个很好的功能基线包含一系列定义良好的用例。对于我们来说避免分析麻痹大意和维护前进的动力是重要的。
主要风险
没有新的风险被识别出来；实际上我们的风险列表比以前更短了。因为 ASDI 同意对于这个项目 OODB 是不合适的，我们因此不再有技术上的风险要管理。他们也放松了对我们的交付产物的正规形式和他们预想的结构，并且他们毫无保留的批准了我们的基于 RUP 框架的文档。
在我们关心的剩余时间和工作量的问题上，当我们增加了对所需能够的理解和对技术熟悉后，我们觉得预算更加符合项目情况了。更进一步的技术探索勿庸置疑的将揭开新的挑战。