应用Rational工具简化基于J2EE 的项目

　　我们与 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 框架的文档。

　　在我们关心的剩余时间和工作量的问题上，当我们增加了对所需能够的理解和对技术熟悉后，我们觉得预算更加符合项目情况了。更进一步的技术探索勿庸置疑的将揭开新的挑战。

查看本文来源