应用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 部分快照
第 3 部分所使用的工具和技术：
Rational 统一过程 (RUP) ― 指导软件开发过程，对项目的每个阶段提供建议的过程和工作产物
Rational Rose 企业版 ― 为了创建“目前的”业务模型（使用统一建模语言（UML））并在分析线索的基础上开始创建“将来的”系统模型
被创建的或者被更新的工作产物：
业务用例模型（Rational Rose） ― 被创建用来代表系统“目前的”业务功能
业务对象模型 （Rational Rose） ― 被创建用来捕获系统“目前的”业务功能是如何被执行的：实体之间的协作、实体之间的交互和相关的过程和产物
用例模型（Rational Rose） ― 不能完全的表示业务用例模型；被创建用来获取详细的系统“将来的”执行功能（它作为构建软件的基础）
捕获“目前的”系统
有太多新的和被改进了的 IT 系统在已有系统被了解之前被启动。甚至是当已有系统还缺乏 IT 组件的时候，有必要在可选的和改进的方案被建议之前对当前的业务活动情况进行分析。然而人们总是跳过或者草草的完成这一步，但是这做会导致以下的问题：
对客户的需求的理解不够充分，减慢接下来的分析
对需求的不正确的解释
不能准确的估计新方案所带来的影响，导致当软件被交付给客户使用时对客户的工作产生巨大的震动和要求客户完全改变现有的工作流程
不一致的术语和概念，导致与客户之间产生交流上的误解和混乱
创建一个业务模型以捕获“目前的”系统的情况可以是非常快速的任务并能够产生有用的分析线索，这些线索将简化对“将来的”系统的定义。在创建这个模型中能够对我们有帮助的一件事情是工作状态（SOW）。虽然 SOW 主要用来描述“将来的”系统的需求，但是它也提供了ASDI 的当前业务流程的有用的背景信息。