应用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 的当前业务流程的有用的背景信息。

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

业务用例模型， 建模“目前的”业务功能。
业务对象模型 (有时也称作 领域模型)， 对执行业务功能的对象和这些对象之间的关系进行建模。一个业务对象模型可能会显示一个发票是如何被生成并如何在系统中进行流转，或者显示了一个购买请求的开始到结束的过程。
注意在以前的一些项目中，我们跳过了业务建模的步骤，因为我们是建立一个全新的系统，或者是因为我们已经非常好的了解了已有的业务模型。但是因为我们对 ASDI 的业务是陌生的，因此我们觉得这一步是十分重要的。

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

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

创建模型
我们从一个开始点来创建我们的新模型文件（ASDI.mdl），我们使用符合 RUP 中定义的结构的 Rose 模板（见图 1）。因为我们在 RUP 中完成大量的工作，这将使我们工作的很好。RUP 的模型模板是可以在启动 Rose 时看到的，我们可以通过向导来访问的几个模板之一，或者你也可以在 Rose 应用程序的 Frameworks 目录中找到他们。


图 1: RUP 模型模板

我们对模板的结构做了一些改动以符合我们的需要和选择。例如，我们直接做了一下的修改：

代替跟踪被包括的与其他用例分离的用例，我们将这些用例组织到逻辑上包含他们的功能的包中。我们觉得可以将 <> 原型和 Rational SODA 的报告能力结合起来，这样当有必要时可以允许我们容易的识别被包含的用例。
我们删除了在逻辑视图（Logical View）下的分析模型。你可以阅读 Yves Holvoet 的演讲稿来了解分析框架重用和分析/设计用例的正反观点的讨论。我们决定一个分层的分析模型是没有必要的，因为我们并不期望 ADSI 系统中的多数业务模型可以在将来的项目中被重用。相反，我们允许用例在整个项目的过程中得到进化。
我们首先通过业务组件对设计模型进行了划分，然后再对他们进行层次的划分（这两个任务通常是不同的），而不是一开始就对模型进行层次划分。
接下来我们必须添加一个计划（schema）区域到模型中以使数据库架构师可以跟踪数据建模的工作。

管理模型
将 Rose 模型按照不同团队成员的责任分摊到包中通常是需要花费一定的功夫的。包的结构应该被创建的使在团队成员之间共享职责相对的简单一些，这可以通过划分系统成为不同的部分来实现：分析（比如，贯穿用例和业务对象），体系架构和设计。

我们的团队虽然不是很大，但我们还是要考虑到在模型之上的协作问题。我有几个 Rational Rose 的浮动的许可证，这足够我们所有的人同时访问模型，但是我们也需要使我们能够并发的访问模型的某一部分。因此我们使用 Rose 的 “单元控制” 的特性以对模型进行适当的分解。

在我们的团队的组织结构中的角色（如在第 2 部分被描述的）这些角色所拥有的对模型各部分的输入和更新的指责被显示在表 1 中。因此，团队中的其他成员，比如初级的开发人员和项目工程师将只拥有对模型进行访问的权限以完成他们的开发工作。

角色 输入/更新职责
组长/高级分析人员 打包管理
用例模型(业务和系统)
业务对象模型
体系架构
设计
高级开发人员 体系架构
设计
数据库架构师 体系架构
计划（Schema）设计
表 1: 模型输入/更新职责

我们对模型进行了分解，如图 2 中显示的 Rose 图。此时这个模型的结构服务于我们需要，因为我们有 3 个人直接的维护这个模型。将来，当团队和项目逐渐扩大时，这个模型结构可以被容易的分解为更多的 *.cat 文件。


图 2: 模型分解

关于分解 Rose 模型的额外信息可以在 Robert Bretall 的演讲稿中找到。这里只指出来自于它的模型结构讨论中的几个有价值的事情：

最好不要将内容放在模型的顶层。（在我们的案例中，所有的信息都被放到了被控制的 *.cat 文件中。）
如果你计划在将来的项目中重用你的系统模型的某些部分，考虑对分析模型进行分层。（你也可以在 Yves Holvoet 演讲稿中找到更多相关的信息。 ）
如果模型的结构是根据 RUP 的指导创建的，Rational 的工具（SoDA ，REI 脚本等）将更加有效的与模型进行交互。
使用 Rational Rose 分解模型成为分离的 *.cat 文件是很容易的。如图 3 所示，我们简单的右键点击我们想在单独的文件中控制的包；然后在上下文菜单中选择 Units > Control Use-Case Model ，这使我们可以控制这个包和这个包中的所有子子项。稍后在项目中，我们将重组一些 *.cat 文件成为几个更小的被控制的包以进一步的发布建模的工作产物。


图 3: 在 Rose 中创建分离的 *.cat 文件

建模用户和接口
一个角色（actor）是与系统交互的外界的人或者事物；这既可以是使用系统的人，也可以是其他的接口类型。建模系统的用户和接口以及他们之间的依赖是非常有用的；它不仅仅可以给你一个系统的完整实体，而且也可以提供给你对于将来的安全性和角色建模工作的良好信息。

图 4 显示了我们如何在 Rose 中将角色容入我们的业务模型当中 — 尤其是，在一个与客户服务相关的用例图中，这个用例图摘自我们的业务用例模型。两个特殊的原型类被使用：业务角色和业务用例。 Rose 可以基于原型分配自定义的图标，并且我们选择这个方法为用例和角色分配外表略有不同的图标 — 加了一条斜线 — 因为我们觉得区别用于构建软件的系统模型与业务模型是重要的。


图 4: 客户服务的用例模型摘录

当我们将业务用例模型充实起来时，对于业务对象模型来说将会出现一系列好的候选对象。虽然创建一个“目前的”系统的业务模型看起来要花费大量的工作（主要的工作量是生成图），但是我们觉得它是值得的。在我们过去的“目前的”模型中，已经包含了大量的在实验室工作簿中的注释和正式的技术注释。为了得到已有业务流程的更加清晰和完整的视图，应该在花费一些时间在 Rose 中捕获这个信息。

理解系统交互
有时人们会将重点都放到了系统的某个单独的部分上，但实际上系统各部分之间的交互也是非常重要的。充分的考虑整个系统部分的交互将使系统各部分之间集成的共性和可能性更加明显。这是为什么我们后来使用交互图的原因之一（显示系统各部分间的交互）以验证我们的设计；这对在分析和设计中识别流程和固有的缺口是非常关键的。

在项目的早期我们关注的交互：

业务用例对角色（什么样的个体和接口访问到我们识别出来的各种业务任务）
业务对象对业务对象（各个业务对象之间是如何彼此交互的，和他们共享信息的种类）
用例对用例（任务彼此之间的依赖，和被一定的过程共享的公用任务）
我们花费了一些时间在 Rose 中捕获我们对当前业务组织和过程的理解，结果是生成了对于我们理解现有系统非常有用的业务对象模型。在对象模型中的图（在图 5 中显示的是其中的一个）类似于标准的类图、除了他们使用了特殊的原型类：业务实体、业务控制和业务角色。业务实体表示被动的领域对象比如发票或者报告，而业务控制是执行功能的对象，可以表示报警或者机械的作用。（业务角色在之前已经被讨论了。）


图 5: 业务对象模型摘录

我们在业务用例建模之后很快开始业务对象建模。业务用例的说明文字确定了一系列合适的业务对象。如果是跨越多个用例的对象，比如“购买请求”和“产品”、“产品队列”和“运输队列”是被识别的业务领域的关键对象。有时如果我们意识到它是不合适的或者已经被其他对象覆盖到了，我们将删除这个业务对象。通过这种方法，可以快速的在任务（用例）和 事物（业务对象）中筛选与 ASDI 业务相关的业务对象。

在某些情况下，业务对象模型将演化成系统类。这对于实体对象来说基本上是正确的，实体对象通常被映射为容器类或者是数据库表。在其他一些情况下，业务对象模型简单的作为一个为理解客户领域的引用的结合点来使用。我们确认客户已经完全理解了图形化的符号和每个图的内容，因为他们的检查和批准是关键的。

总而言之，我们花费了大量的时间在业务建模的工作上。这并不一定是一流的或者是完全的，但是对于我们来说应该是能够对当前的业务流程有一个足够的认识。在项目的第一个或者两个月后，我们将很少的提及业务模型，但是我们觉得它是值得花费时间的，因为它是形成“未来的”系统的系统模型的一个必要的步骤。当一个新成员加入到我们的团队时，我们可以通过浏览业务模型来帮助他们来理解新的领域；然而，一旦对它熟悉了，业务模型将很少再被查看，除非是阐明术语。

将 SOW 转换成用例
计划“将来的”系统，我们需要将已经用文字形式表示的 SOW 需求(在 第 2 部分中被讨论的)转换成为经过深思熟虑的用例。换句话说，通过对“目前的”系统的业务用例的创建（就像早些时候所讨论的），我们准备为“将来的”系统细化这些用例。这将不是一个快速的步骤，但是它经历超过两周的时间。（在 RUP 的术语中，这个转换反映了一个从初始阶段到细化阶段的逐步转化过程。）我们在业务建模上所作的工作，获得了当前系统的经验并将它的功能划分进了业务用例，这对我非常有帮助。（ RUP 的文档显示了从业务用例模型到业务对象模型和系统用例模型的演进；我们发现这是非常正确和有帮助的。）

我们并不担心映射 SOW 需求到“目前的”系统业务用例的原因是 SOW 需求中的许多在当前的系统中是不存在的。我们早期所创建的业务模型只不过是一个临时的产物，它用于我们确保我们的团队理解 ASDI 的当前系统。

用例对文字说明
一系列的工作簿和工作产物（包括那些后面被列的“引用和其他资源”）解释了用例建模和理解需求的好处。我们发现许多被提及的好处是真实的，虽然定义用例的内容不是琐碎的任务。与良好的文字说明相比，如果用例没有被良好的设计，对于你来说他们当然没有用的。

这里是一些开始创建用例时的误解：

用例被创建的太大或者太小
用例在跨越团队的情况下不一致
没有对用例分组的包进行良好的计划
不合理的对模型的访问进行控制，导致在团队分析协作的过程中发生冲突
过于细致的定义用例，在用例进入原型、设计和开发任务之前就定义每一件事情
定义用例时过于简单，使需求被工程团队可以有众多的解释
结果，我们决定用例建模标准和指南需要被组长定义。这些包括下面的指南：

用例典型的获取 10 到 20 天的开发和单元测试。这不是 RUP 的规则，但是对于我们来说这是一个好的规则。如果我们发现用例比这个标准过大或者过小，我们将花费额外的时间检查他们以保证他们有合适的范围。
工程团队必须在早期对包的结构达成一致。这个结构可能会变化，但是变化应该首先与团队进行讨论。
当决定什么应该包括在我们的用例中时，我们应该遵从在文章中指出的指南Fine Tuning Rose to Complement Your Process:

标识 — 名称、唯一的 ID、 原型、可跟踪需求和简介
描述 — 开始状态、结束状态主流程描述和变更
注释 — 临时的“便签簿”注释
从“目前的”到“将来的”演进
当我们从“目前的”转移到“将来的”时，我们的许多业务角色被演化成了系统中真实的用户和接口，虽然有意义的重构是必要的。这是自然的，因为当重新定义其他角色时新的 IT 方案统一了原有的一些角色。一些业务实体作为抽象的概念消失了，而其他的一些通过计划（schema）或者详细的设计被映射成了类。

在图 6 到 图 9 中显示了我们早期工作产生的对于“将来的”系统的用例模型的一部分。通过图形、协作图和时序图以及进一步的详细分析的帮助，它将随着时间推移而成熟。


图 6: 早期的角色模型



图 7: 核心的客户服务用例



图 8: 客户定单用例



图 9: 系统管理用例

就像 RUP 的描述，“用例建模的最重要的目的是与客户或者最终用户沟通系统的行为。”然而，增加复杂性可以导致我们的客户也许感觉不舒服的风险，我们发现当我们充实用例时，在用例中引入更高级的包含和扩展关系是很有价值的。在详细的检查我们的用例模型时，被包含和扩展的用例频繁的出现。我们发现甚至在我们理解了系统的（包括用户）外界接口视图，通过包含和扩展用例来分组功能产生在重要的计划、架构和测试中的好处。然而，在我们看到客户对检查这些高级的关系没有信心时，我们有时会将被包括和扩展的用例从检查的包中拿掉。

总结
我们现在已经有了一个描述了 ASDI 业务中已有过程和实体的画面，并且在对将被构建系统的任务和角色的系统建模上有一个良好的开始。虽然还有一些在团队内的关于跳过业务建模工作的讨论，但是我们觉得我们的工作将收到回报。其他的好处是，它使客户容易的以一种舒服的和相对非技术的级别进入用例。

不同项目之间的用例建模有着显著的不同；用例的定义、用例的关系、详细的程度等等都是经常被争论的。最后我们发现当我们向客户展示我们的用例模型时，一致的并频繁的检查是成功的关键。

计划未来
我们需要得到技术上的强劲进展。客户正向我们索取比我们现在可以提供的更多的有关用户界面、代码原型和工具选择的信息。我们必须开始提供屏幕的模拟并开始考虑适当技术的选择；现在重要的是开始使用更加实际的、技术的产物和购买工具（尤其是如果我们需要更多的培训）。

虽然我们还没有开始进入体系架构阶段，但是我们知道系统必须是基于 Web 的并且是跨平台的，同时从原型到企业级方案都要是可扩展的。我们已经学习了 J2EE ，并且 ASDI 雇用的 IT 经理也首选这个技术平台。因此，我们觉得开始探索 J2EE 的成本和能力是明智的。我们的团队在这个领域不需要太多的培训，这是另外一个因素。数据的存储应该被更多的考虑，然而，因为 IT 经理极力的推崇面向对象的数据库(OODB)方案。因为我们对关系型数据库更加在行，这对我们来说是一个艰难的路程，但是我们还是同意了考察 OODB 的方案。

我们非正式的与我们的客户审查了我们的所有工作产物，但是是时候进行正式的检查了。在接下来的几周中，我们将建立我们的 Rational SoDA 模板以便我们提供我们的第一个正式的交付：详细的软件需求。我们同意这个文档应该包括用例和非功能需求（可靠性、可用性等等）。

我们的用例开始稳定了，开始指明在对 SOW 合适的可跟踪的地点。我们需要用 Rational RequisitePro 来确保维护 SOW 与我们的用例之间的映射。

我们接下来的方向，应该是：

技术上的进展，尤其是工具和技术的选择
建立必要的 Rational SoDA 模板以生成我们的第一个正式的文档
精练我们的用例以添加可跟踪性到 SOW
主要风险
我们仍然觉得时间是非常紧的，并且存在着时间进度或者预算的一些出入 — 并且我们的风险列表还在增长，甚至我们还没有开始任何的认真的技术探索。其中有以下新的风险：

过多的涉众竞争，有时在系统的功能上会有矛度的意见。我们需要与客户澄清觉得的过程。
假如我们选择 OODB 方案，我们必须扩展我们的深度，因此这会产生强迫的培训和对工程团队的时间进度产生不确定性。
客户心急的要求第一阶段的重要的正式的和详细的工作产物，而我们设想的是这只是个概念性的证实。我们仍然与客户针对 RUP 进行沟通，并尽力在 RUP 中的工作产物和符号中增加他们舒服感受。

原文转自：http://www.ltesting.net