级别： 初级 James Densmore, 顾问解决方案架构师, IBM
2008 年 2 月 15 日 
了解软件分析和设计过程中所使用的模型和 UML 图的差别。本文带着您一步步地使用 IBM Rational 建模工具执行许多操作，从而说明了各种查看和改变模型的方法。
来自 The Rational Edge.
英语中一件有趣的事是一个词会有多个含义。在技术领域似乎也有这样的事，当然在 Rational Edge 中经常涉及的软件和系统开发中也是。
早期的“面向对象的”思想有一部分是处理 C++ 中“虚拟”的许多不同的用法，更不用说语言的复杂性：“如果您认为 C++ 不是太复杂，就是一个保护的抽象的虚拟的底层的私有的析构函数，那么最近一次您需要它是什么时候？”
1
“Model”是另外一个这样的单词，它有多重复杂性的含义。本文着重于那些经常干扰 IBM® Rational® Software Modeler 系列中的建模工具的新用户的 UML 建模的一些基本方面。了解了这些概念之后，当您在开发方法中使用建模工具时，将更好地利用它们。
基本语义
单词“model”的多重含义的问题是最近在用 SysML，
2
用于系统建模的统一建模语言（Unified Modeling Language
3
，UML）的派生物，对系统建模的过程中提出来的。当然，我们使用 Rational Systems Developer
4
（RSD）。首先，我们注意到，文件 RSD 产生（?.emx）称为 model file（模型文件）。那么，RSD 工具本身形成的该文件的内容一定是模型，对吗？不。实际上，我们正在观察在开发的系统 CheeseGrater
5
的子系统的模型，协作实现其他系统以及 CheeseGrater 中的功能的子系统（参见图 1）。我们的系统模型涉及许多模型文件，每个都是 .emx 文件。在此我要做一个应该宣布的隐含的假设：我们应该称为模型的唯一的模型是与正在开发、增强，或正在研究的整个系统相关的那个。因此，模型这种东西是随所研究的系统而变化的，不是随着其他的而变化。当建模（至少用 UML）时，我与其他分析人员进行讨论时，我们发现阐明是哪个系统是很重要的。另一方面，我们可以有任意东西的模型，并且我们可以有许多模型文件。
图 1： Cheese grater 系统
那么我们系统的模型在哪里？它一定在 CheeseGrater.emx 中，对吗？不完全：有一些是，但不是全部，因为 CheeseGrater.emx 的内容涉及关于其他 .emx 文件中的子系统的信息。CheeseGrater 的模型一定是存在于所有那些文件中。形式上，系统的整体模型是描述系统任意部分的模型文件闭包的信息量。
让我们来考虑单词 model（模型） 的定义。Dictionary.com
6
提供了这样的定义：科学或经济学中，系统或现象的简化的表示，包含描述系统或解释现象所需的任意假设，经常是数学上的。这与我们的“模型不是系统，只是系统的表示”的直觉相结合。模型是真实系统的简化，用于示范或说明系统的各种重要的方面，从而令系统的涉众感兴趣。那么当使用 UML 或 SysML 描述模型时，要如何进行示范呢？我认为您知道答案 —— 建模工具用图的形式表示信息。图是决定性的，因为没有它们，理解模型是很困难的，因此理解模型代表的系统也是很困难的。图是模型的视图，但它不是整个模型的视图。在数学体系中，图是模型的投影。
将图作为模型的窗口
许多人可能知道，IBM Rational 建模工具允许在图上显示模型中的大部分内容。相反，如果不在模型中，那么（除了只是图的一部分的注释和其它可视化的糖以外）就不可能是模型的一部分。因此，如果您看到图中描述了一些东西，那么您就知道它是在模型中。然而，如果您期望看到的东西不在图上怎么办？这不意味着它不在模型中。图的作者可能选择了从图中去掉该元素。作者随意去做，并且可能已经这样做了，以减少混乱，或者满足与作者上心的某个项目涉众沟通的需求。
如果 Rational Software Modeler（RSM）的 project explorer 视图中没有找到该元素怎么办？这意味着它不在模型中吗？通常是，但不是必然的。大多数建模工具的 project explorer 都试图提供系统的模型的几乎完全的视图，但也可能丢掉东西。举例来说，RSA 有 project explorer 的过滤器的概念
7
。任意类型的元素都可以被滤掉，以便它不出现在浏览器窗口中，如图 2 所示。
图 2：Rational Software Architect 的 Preferences 窗口中的 Project Explorer Filter
UML 图的能力
让我们开始建模。图 3 显示了 CheeseGrater 的小模型，从类图开始。
图 3：模型“CheeseGrater”的类图
让我们来回顾一下图 3 中的简单类图传达了什么。注意到它传达了令人印象深刻的精确定义的信息。老话é 是真理：一图胜千言。好的，这种情况下是 200 个词。
- 任一 Kitchen 有零个或多个 CheeseGrater 对象。所有的 CheeseGrater 对象与一个 Kitchen 对象有关联。如果 Kitchen 销毁了，那么也销毁它包含的 CheeseGrater。
- 一个 CheeseGrater 有可选的 Cover。每个 Cover 与一个 CheeseGrater 相关联。CheeseGrater 的销毁不一定意味着其 Cover 的销毁。
- 每个 CheeseGrater 有一个 Handle。每个 Handle 与一个 CheeseGrater 相关联。如果销毁 CheeseGrater，那么其 Handle 就销毁了。
- 每个 CheeseGrater 有一个 CuttingSurface。每个 CuttingSurface 与一个 CheeseGrater 相关联。如果销毁了 CheeseGrater，那么其 CuttingSurface 就销毁了。
- 每个 CuttingSurface 有一个或多个 Edge。每个 Edge 与一个 CuttingSurface 相关联。如果销毁 CuttingSurface，那么也销毁其 Edge。
- 每个 CheeseGrater 有一个制造者。每个 Handle 由某种具体的材料组成。每个 CuttingSurface 属于一个具体的类型和材料。每个 Edge 是一个特殊的类型。（模型，至少如其显示的一样，不确定出这些类型的值，以及可能具有的相关对象。尽管如此，让我们来看看一个实例：Edge 的类型可能是锯齿的或平滑的。）
现在，让我们来看看来自同一个模型的另一个类图（图 4）。
图 4：CheeseGrater 模型的另一个类图
这个包含了一个类的简单类图没能告诉我们关于 Kitchen 或 Edge 的信息。也许该图的作者是在满足只对 CheeseGrater 本身，而不对其组成部分感兴趣的项目涉众的需求。
让我们对该模型进行简单的变更。假设我们对 Cover 的类命名错误，我们应该将其命名为“GraterCover”。变更该名称的一种方式是到 project explorer 中变更类的拼写，如图 5 所示。
图 5：重命名类
现在，前面的图如图所示（图 6）：
图 6：现在 cover 元素重命名为“GraterCover”。
第一个类图长什么样呢？上面应该也有变更了，对吗？让我们来确保了解了这个简单却强大的概念：每个图中原来称为 Cover 的模型元素，现在用新的名称 GraterCover。Cover 在第一个图中表示出来，因此我们应该发现它已经变更了，如图 7 所示：
图 7：CheeseGrater 模型的完全的类图，显示出 cover 元素的新名称
它确实改变了，在类名出现的所有图中的拼写都改变了。再说一次，图是模型的视图，或投影。在从 Cover 到 GraterCover 的名字变更过程中，我们不只是变更图，我们在变更模型，因此，所有的图都投影该变更。这包括 project explorer 。虽然它不是图，但是 project explorer 的确是模型的投影，因此类 Cover 的名也变更为 GraterCover，如图 8 所示。
图 8：甚至 project explorer 也映射对 cover 元素名所做的变更。
我们都知道模型随着时间变得更大。为了确保我们理解的全面，假设模型中另一个包中包含了某个也名为“Cover”的元素。该元素的名称也变更了吗？不。它仍旧是 Cover。名字中的相似是一致的。Cover 与 GraterCover 无关，因为它是模型中的不同元素，如图 9 所示。
图 9：有名为“Cover”的元素的同一个模型中的另一个包没有改变。
模型的能力
希望我们已经清楚地展示出这些图背后存在一个语义模型。该事实可以通过其他有用的方式来利用。举例来说，假设我们在处理一个复杂的模型，也许比我们在此使用的更复杂，很难记住与 CheeseGrater 相关的所有元素。让我们来示范如何可以发现模型所包含的关联。我们创建新的类图（在 For Edge 模型包上单击右键，并选择 Add Diagram，和 Class Diagram）。由于是新的，所以图最初是空的。在 project explorer 中，我们用鼠标抓取 CheeseGrater 类，并拖到该空图中（图 10）：
图 10：空图中现在填充了从 project explorer 中拖拽过来的 CheeseGrater 类
接下来，我们在图中该类上单击右键，并选择环境菜单 Filter，然后选择 Show Related Elements，如图 11 所示。
图 11：选择“Show related elements”功能
结果的对话框如图 12 所示：
图 12：“show related elements”功能
在此，我们选择“Show All Relationships [Default]”，然后单击 Details> > 获取 Relationship Types、Expansion Direction、Stopping List，和 Levels。如果 Levels 没设置为 1，我们将其设置为 1，如果必要，我们设置 Expansion Direction 单选按钮，然后单击 OK。
图 13 显示出该图形查询的结果。
图 13：结果的类图，基于对“Show related elements”功能的选择
我们获得了完整的模型了吗？仔细看：我们没有。特别是，Edge 类没有出现。如果我们将 Level 设置为 2，或者选择了 Expand Indefinitely（小心，这可能是资源密集的，并且/或者形成非常忙的图），那么 Edge 类就能出现。Level 仅仅决定查询算法应用于多少层。此外，不存在我们可以运行的，生成其他包中名为 Cover 的元素的 Show Related Elements 查询，因为不存在于该元素的直接或间接的关系。
为什么该图与第一个图看起来不一样？因为我们开始了一个新的图，两个图中没有任何类型的表示关系。二者都是同一模型的投影，但类和关联的位置是彼此不同的。位置是由试图用看上去吸引人的方式安排元素的 RSA 中的位置算法所选择的。我们可以用喜欢的方式重排该图。
一旦清楚了底层模型的概念，建模工具使用起来就容易得多了。也许您已经犯了传统的错误，即从模型而不只是当前图中删除元素。曾经，我们都犯过这样的错误，然而一旦您清楚了模型的概念，您就不太可能犯这种错误了。
让我们来进一步讨论此概念。在下图中，我们打算从模型中彻底删除一个元素（我们右键单击的元素），不只是在描述该元素的图中。如果我们完成了该操作，将把它从模型，以及它出现的所有图和视图中删除，包括 project explorer。如果它是个包，那么其内容也将被删除。它所拥有的所有关系也将被删除。因而，图 14 中显示的“Delete from Model”选项是非常强大的操作，因此应该小心使用。我们的实践是为了避免草率地从模型中删除元素。取而代之，我们通常创建一个包来保存我们认为不再需要的元素，名为“Obsolete”。将您认为不再需要的元素移动到该包中。当然，您也将无疑地把它从它出现的图中删除。这将花费更长的时间，但如果您后来发现不是真的想要删除该元素的话，其关系是保留下来的。
图 14：“Delete from Model”选项是应该小心使用的非常强大的操作。
结束语
模型提供关于系统的一站式信息选定。它是强调了对于您的担负开发实际系统的开发人员中的项目涉众很重要的东西的系统的表示。在本文中，UML 模型是由例如 RSM 或 RSA 这样的建模工具操纵的。UML 模型包含语义元素和图，而图是 UML 模型中语义元素的视图或投影。
出于许多原因，这是强大的概念。首先，很少存在二义性。在纯绘图工具中，例如 Microsoft PowerPoint，的两个分离的图会失去彼此的同步。对于描述同一模型中的元素的两个图来说，这是不可能的，因为对一个图中的元素所进行的变更会自动地映射到它出现的其他图中。其次，更细微的原因是模型，不是图，成为系统的结构、语义和行为的记录的表示。
除了为新的项目涉众生成更多映射系统的 UML 图以外，我们还可以用其他方式利用该事实。举例来说，我们可能也由系统模型生成报告。最新版的 RSM 拥有基于 Eclipse Business Intelligence and Reporting Tools（BIRT）的新报告生成工具，这是最近 Steve Hovater
8
所写的论证该技术的有效性的 IBM Rational developerWorks 文章的主题。有了该工具，分析人员不再以同样的方式从图中了解信息。取而代之，他们转向模型。模型中已经包含的图可能描述充足的信息，但如果没有的话，分析人员可以使用模型的能力来创建给予他们所需的信息的新的图或者报告。
注释
1 Tom Cargill，C++ 期刊（C/C++ Users Journal）
2
OMG Systems Modeling Language，OMG SysML 官方网站。
3
统一建模语言（Unified Modeling Language, UML），UML 官方网站。
4
Rational Systems Developer 产品页面
5不，当然，它不称为 CheeseGrater，但我需要系统名。您希望我向其他人那样使用 Foo 或者 Bar 或者 Baz？顺便说一下，那不是我的注意 —— 感谢 Bob Wise 的最初想法，使用 Cheese 代替 Foo。
6
reference.com 上关于 model 的词条。
7通过 Windows > Preferences > Modeling > Views > Project Explorer 访问
8
Using IBM Rational Systems Developer V7.0.5, UPDM, and BIRT to produce DoD Architectural Framework views（英文）。
参考资料 学习
讨论
- 参与论坛讨论。
- 现在开办了一个特别为 Rational Edge 的文章创办的 新论坛，现在您就可以分享您对本文或本期杂志或以前杂志中的其他文章的想法。阅读世界各地您的同行们所说的内容，生成您自己的讨论，或者加入正在进行的讨论。单击 这里 开始。
-
全球 Rational 用户组社区
关于作者  | 
| | Jim Densmore 是 IBM Rational 的解决方案架构的区域实践领导。他的职责包括让客户进行组织的转型，以及负责系统的工程。在 2000 年他作为销售团队的技术代表加入 Rational 之前，Jim 花费二十多年的时间致力于高保真、实时战斗仿真和实时通信软件的架构、设计和开发。他从洛杉矶加利福尼亚大学获得学士学位，并且从马里兰大学获得计算机科学硕士学位。 |
对本文的评价
| 
