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

核心提示：应用Rational 工具简化基于J2EE的项目 第 5 部分 ：架构与设计Steven Franklin软件设计师和过程专家2004 年 4 月当这个正在进行的应用 RUP 和其他的 Rational 工具的 J2EE 样例项目从用例转换成架构和设计时（包括数据建模和构建测试设计假想的原型），这个项目已经进入了更加

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

第 5 部分 ：架构与设计

Steven Franklin
软件设计师和过程专家
2004 年 4 月

当这个正在进行的应用 RUP 和其他的 Rational 工具的 J2EE 样例项目从用例转换成架构和设计时（包括数据建模和构建测试设计假想的原型），这个项目已经进入了更加技术的阶段了。
这个系列的第 5 部分首先检查了一下项目的时间进度，然后当我们进入了架构、设计、数据建模和创建原型时，我们已经在下一个阶段进行细化阶段中了。

第 5 部分快照

在第 5 部分演示的工具和技术：

• Rational Rose 企业版 用于创建设计模型（包括使用 Rose 的 data modeler 进行数据建模）
• Rational RequisitePRo — 用于添加或者细化需求

产生或者被更新的产物：

• 设计模型 （Rational Rose） — 被创建来添加架构和设计信息（包括数据库计划（schema））
• RequisitePro database — 被更新以添加或者细化基于架构和设计探索的需求

项目的时间进度

在开始进行具体的架构和设计工作之前，让我们来检查一下 ASDI 项目的整体进度。就像你可以第 1 部分回想起来的，这个由多个部分组成的系列文章覆盖了项目的第 1 个阶段：以一系列需求、一个参考架构和代码（理想的可重用的）为结果的概念的验证。到目前为止，我们大概使用了整个第 1 阶段预算的三分之一，但我们已经接近了项目时间进度的一半了。这是在我们的预料之中的，因为我们有意的让进度稍微慢一点。分析和计划活动总是以较慢的步伐移动，团队应该在项目开始时逐步的将他们建立起来。

因为第 1 阶段要求一个相关的结构化的和正式的概念的证据，我们将它作为一个小的项目处理，通过在演进的产品上进行测试和 QA（同级审查）来完成它。RUP 有一些用于开发概念证据的机制，基本在分析和设计工作流的执行架构的合成的活动中。我们正在进一步的将概念的证据转化成可用的 beta 版产品。我们能够将更多的功能、风险的降低和产品的成熟放到这个阶段中，我们越多的将技能和知识用到系统的产品版本中，我们的客户就越兴奋。

这个接下来的一系列的任务将比之前的活动更加具有技术性。我们正很好的向架构。设计、数据建模和原型前进。在第 4 部分中我们讨论了一些原型和评估如何进行我们的工具选择；现在我们的原型的关注点在测试我们设想的需求、系统说明和设计上。

过渡到架构和设计

架构和设计活动是在 ASDI 项目中最令人愉快和具有创造力的任务。我们为我们将系统计划的高效、安全和简单优雅而自豪。技术方案的远景在多次令人兴奋的会面、自由讨论和技术探索中最终形产生了。

简单的讲，架构意在捕捉技术上灵活的方案，这个方案可以覆盖上个月我们定义出来的系统需求。不论是向前看（对于设计）还是向后看（对于需求），架构团队都将承受巨大的压力。 Rational Rose 的集成开发环境通过让我们能够做以下的事情简化了这个挑战：

• 使用 SoDA 产生文档以答应架构和设计元素的分发，简化了检查并保持每个人都有一致的当前远景。
• 从场景直接更新类的签名（方法和属性），以使我们不必回到类的说明中添加缺少的方法。
• 为自动化的任务比如产生类的骨架、检查模型的命名习惯和测试模型的完整性和有效性生成 RoseScripts （可以通过访问 Tools 菜单得到）。
• 使用 Rose 的 RUP 模板，提供一个附带 RUP 指南的模型框架。
• 在 Rose 中从提供的 J2EE 类框架中拖出类。
• 用 Rose 的”单元控制“特性将模型分解成为能够被团队进行版本控制和并行工作的片断。

注重，因为我们在过去的项目中创建的系统与目前这个系统类似，因此假如我们引用一些参考架构，我们的架构将会从中受益。然而，我们不能在已存在的包或者设计模式中找到任何可重用的机会，因此我们只是引用了已存在系统中可能会在将来用到的思想和类。

从用例到设计类的转化
从用例到设计类的转化过程是缓慢的，需要进行多次的迭代。这牵扯到分析人员和设计人员，因为我们有很少的既可以舒适的与客户讨论业务领域又可以使用特定的工具进行分析、细化设计产物的人员。

这个活动的目标

有时将需求直接的转换成代码是诱人的。实际上，我们在以前的项目中就是这样做的（因为我们有非常具体的需求说明），我们在我们对项目的理解上非常自信。这样就产生了一个错误。需求被遗漏，范围很难被跟踪，并且大量的工作和返工是无用的。使用设计模型来连接在需求和代码之间的鸿沟是重要的；设计模型可以在开发和测试之前很久捕捉错误和有问题的假设。

在从用例向设计类转化的过程中，我们希望能够实现：

• 将分析小组的知识传授给工程团队。
• 识别能够满足所有需求的技术方案 — 或者，什么地方不是可能的，识别与技术方案冲突的需求，并确定是否他们是重要的或者被改变或者被删除。
• 识别能够帮助确定团队结构、架构层次和对于购买软件的候选的接口。
• 指定技术方案的细节并开始计划如何在团队之中分配工作。
• 基于设计模型的细化时间进行计划和预算的预估。
• 分配类到平台、产品和私有代码。
• 为了反馈和同步的目的，生成软件架构文档，软件架构文档能够被分发到内部和外部的团队成员。

实现稳定的设计

从用例和分析类到设计和设计类的转化是不可避免的模糊的。在我们能够拥有我们感到满足的设计之前，我们需要做大量的工作。图 1 显示了我们以我们的方法定义一个稳定的设计的主要活动。

图 1: 从用例模型到设计模型的转化

前面的文章部分讨论了多数的在图 1 中作为”架构“预备的活动和产物（非凡是 SOW 需求、用例、业务对象模型和分析类）。此外，这些其他的活动对设计工作也是重要的：

• 确定包的结构
• 建模数据（创建数据库计划）
• 创建原型和屏幕模拟

这些将在接下来的部分连同如何处理新的和改变的需求一起被讨论。

打包和子系统结构

在开始考虑设计类之前，整个团队要对一个良好的包结构达成一致同意。不管我们最后的决定是什么，它都应该成为设计过程中的指导方针，所有团队成员都要遵守这个指导方针。

包结构的选择