应用 Rational 工具简化基于 J2EE 的项目第 6 部分 ：早期开发

本文是演示了在分布式的、基于 J2EE 的项目中使用 Rational 工具的系列文章（如下面所列）的第 6 部分。 第 1 部分: 项目介绍；高层次计划 第 2 部分: 风险管理；需求管理 第 3 部分: 模型创建和访问控制；需求分析 第 4 部分: 用例细化；产成报告；工具和技术选择 第 5 部分: 体系架构和设计 第 6 部分: 详细设计；早期开发；双向工程；早期单元测试 第 7 部分: 继续开发；早期的构建；演示 第 8 部分: 单元测试策略；功能测试；GUI 测试脚本 第 9 部分: 系统构建和测试；缺陷跟踪；产品交付 第 10 部分: 项目完成；结论；未来的工作 本文中所虚构我们是一家软件公司 Lookoff Technologies Incorporated，我们的客户 Audiophile Speaker Design, Inc. (ASDI)，它雇用我们实现他们最初的 IT 需求。对于更详细的信息，参见 第 1 部分。 本文讨论了团队的进展进入了实现阶段，并且因此进入了 RUP 的构建阶段。我们挑选了在 ASDI 项目的第一阶段被使用的大部分技术。设计的情况相当的好，虽然在本系列的第五部分中被讨论的包的结构和设计在未来的一到两周内还将继续的演进。例如，包结构的部分被重新定义来反映预期的 Java 包命名习惯。 第 6 部分快照 在第 6 部分演示的工具和技术： Rational Rose 企业版 — 支持双向工程 Rational Purify — 用于检查 Java 内存的使用情况 Rational Quantify — 用于了解性能瓶颈 J2SE （Java 2 平台标准版） 1.3 — Sun 的 Java 参考实现 Jikes — IBM 的高速编译器（Sun 的 Javac 的替代物） Castor — 来自于 ExoLab Group 的数据绑定框架，用于绑定 XML 到 Java ，反之亦然。 被创建或者更新的产物： 设计模型 （Rational Rose） — 随着代码的发展被更新 Java 代码 — 为 command gateway 和其他的子系统而创建 铺平道路 在能够进行开发之前，我们必须在管理和团队领导的层面上完成下面的事情： 建立指导方针和非正式的培训以便工程团队都能够遵守相同的编码和设计约定。 更新原有的团队结构（在本系列的第二部分被显示的）来反映与设计不同的实现需要。 建立开发策略和环境，以使我们的开发人员能够有效的协同工作，使开发人员可以在自己的系统部分工作而不会影响其他人，并且方便的测试他们的代码。 适当的紧密跟踪以确保任务能够按计划完成并满足他们的目标。 指导方针和标准 RUP 强调在一个产品被构建时同级评审的重要性；我们将在后面了解更多的细节。团队必须对同级评审的标准达成一致意见，以避免走向两个极端：松散的评审将带来非常微小的价值，或者过度严格的评审将产生大量的注释行，比如"这个被实现了，但这里我是如何实现的"的注释。 对于我们的 Java 代码，我们创建了一个基于AmbySoft Inc. Java 编码标准的编码标准文档。这些标准被证明在我们进行同级评审中是意义重大的。这些标准不仅可以帮助我们为客户产生更加一致的和高质量的交付系统，而且还允许我们的团队成员更加容易的在不同的子系统（和项目）之间进行调整。我们发现如果开发人员们对编码的形式和构建非常熟悉的话，他们将能够非常快的融入到统一的团队之中。通过避免使用模糊的命名习惯、不充分的注释和不好的编码风格，开发人员能够创建出使其他开发人员更加容易接手的代码。 培训 通常的情况下，工程师们都在尽力的学习被需要的技术以在业务上保持竞争力；然而，一些项目也会引入一些需要团队培训的新技术。我们在 ASDI 项目中并没有处于这种情况下，因为这个项目中使用的架构和技术都是我们所熟悉的。我们在这个项目中的培训是关于 Rational 工具的使用、UML 、Java 编码标准和 J2EE 设计模式的。虽然我们在这些领域有着非常好的知识背景，但是这些知识多数是在团队领导的头脑里。因此，培训由非正式的午餐时间和被团队领导发起的下午会议组成。我们发现这些维持在一个小时到半天的会议是非常成本高效的（但前提是，你必须要有具有充足知识和良好沟通能力的团队成员）。 因为我们的话题是与整个公司相关的，因此我们鼓励其他的技术人员参与到这些培训会议中。我们发现有更多的技术人员参与将会引发更加有价值的思想上的交换。最其码，我们计划能够让 ASDI 项目中所有的工程师都参加的会议（不论是参与分析、设计、实现或者测试的工程师）。 团队结构的演变</