应用Rational 工具简化基于J2EE的项目 （三）转换到系统模型

第 3 部分 ：转换到系统模型

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

本文将继续通过这个全面的应用 RUP 和 其他 Rational 工具的样例项目来介绍创建项目的 Rational Rose 模型，本文中我们将开始创建代表“目前”业务情况的系统模型，并将此业务模型转换成为“将来”的系统模型。

这个第 3 部分文章重点的介绍了在 Rational Rose 中完成的早期建模活动。首先我们来对 ASDI 现有的（“as is”）系统进行建模，通过业务用例和业务对象可以显示当前事情是如何工作的。我们将从这个反映现有系统的模型创建出符合 ASDI 新的需求的系统模型，并且将这个系统模型作为建立软件的基础。

伴随着这本文有 2 个演讲稿 (来自于 Rational 用户大会 2000) 这里讨论了以下主题： Yves Holvoet 的 “维护分析模型与多个设计模型的同步” 和 Robert Bretall 的 “结构化你的 Rational Rose 模型”。后一个演讲稿附带一个 Rose 模型。

第 3 部分所使用的工具和技术：

• Rational 统一过程 (RUP) — 指导软件开发过程，对项目的每个阶段提供建议的过程和工作产物
• Rational Rose 企业版 — 为了创建“目前的”业务模型（使用统一建模语言（UML））并在分析线索的基础上开始创建“将来的”系统模型

被创建的或者被更新的工作产物：

• 业务用例模型（Rational Rose） — 被创建用来代表系统“目前的”业务功能
• 业务对象模型 （Rational Rose） — 被创建用来捕捉系统“目前的”业务功能是如何被执行的：实体之间的协作、实体之间的交互和相关的过程和产物
• 用例模型（Rational Rose） — 不能完全的表示业务用例模型；被创建用来获取具体的系统“将来的”执行功能（它作为构建软件的基础）

捕捉“目前的”系统
有太多新的和被改进了的 IT 系统在已有系统被了解之前被启动。甚至是当已有系统还缺乏 IT 组件的时候，有必要在可选的和改进的方案被建议之前对当前的业务活动情况进行分析。然而人们总是跳过或者草草的完成这一步，但是这做会导致以下的问题：

• 对客户的需求的理解不够充分，减慢接下来的分析
• 对需求的不正确的解释
• 不能准确的估计新方案所带来的影响，导致当软件被交付给客户使用时对客户的工作产生巨大的震动和要求客户完全改变现有的工作流程
• 不一致的术语和概念，导致与客户之间产生交流上的误解和混乱

创建一个业务模型以捕捉“目前的”系统的情况可以是非常快速的任务并能够产生有用的分析线索，这些线索将简化对“将来的”系统的定义。在创建这个模型中能够对我们有帮助的一件事情是工作状态（SOW）。虽然 SOW 主要用来描述“将来的”系统的需求，但是它也提供了ASDI 的当前业务流程的有用的背景信息。

在 Rational 统一过程（RUP）初始阶段部分存在一系列的用于业务建模的方法（也是就在我们项目的第 1 阶段）。与 ASDI 一起创建一个 IT 系统，我们需要一个“目前的”模型以捕捉文件的流转和他们的当前系统的交互活动。我们在 Rational Rose 中创建了下列 RUP 工作产物作为业务建模工作的部分：

• 业务用例模型， 建模“目前的”业务功能。
• 业务对象模型 (有时也称作 领域模型)， 对执行业务功能的对象和这些对象之间的关系进行建模。一个业务对象模型可能会显示一个发票是如何被生成并如何在系统中进行流转，或者显示了一个购买请求的开始到结束的过程。

注重在以前的一些项目中，我们跳过了业务建模的步骤，因为我们是建立一个全新的系统，或者是因为我们已经非常好的了解了已有的业务模型。但是因为我们对 ASDI 的业务是生疏的，因此我们觉得这一步是十分重要的。

我们也考虑到开发一个业务术语表（使用 RUP 提供的工作产物模板），但是我们发现我们的术语中的大多数是相当标准和明确的，而且这些术语在我们的业务对象模型中被充分的捕捉了。更加复杂或者严格的项目将会从创建业务术语表中获益以确保在所有产物中的一致性。

当我们使用 Rational Rose 创建我们的模型时，我们感到仅仅简单的创建图是不够的。我们发现仅仅通过图的方式表达模型对图的创建者是轻易理解的，但对图的阅读者来说却是很难读懂的，因此我们为每一个图附加了文档（通过在图上点击并在文档窗口输入文本）。我们也为图中的每一项提供了文档 — 用例、业务对象、用户或者其他项 — 用一到两行的文字来描述每一项的目的。