UML2.5 值得期待吗

UML2.5 的 Beta 版自 2012 年底发布以来在开发社区中引起了不少争议，其正式版本预计会在最近发布。Scott W. Ambler认为，UML 虽然已经成为业界的通用标准，但是其实际的存在价值和意义并不是很高。

Scott 是一位有着三十多年开发经验的开发者和布道师，他编写了不少 UML 的著作，包括《UML 2.0 Style》（2005）、《The Object Primer》（2004）、以及荣获 Jolt 奖的“生产力奖”的《Building Object Applications that Work》（1997）。他认为尽管 OMG 已经在营销 UML 上取得了成功，但它在生产一些人们觉得有用的产品上变得不尽如人意了。

从 1996 年开始，对象管理组织（OMG）的统一建模语言（UML）标准已经成为 IT 界内的普遍标准。UML 对我们行业的影响令人印象深刻——有数十种 UML 的书籍被出版、数以千计的博客和文章被发表、还有成千上万的的培训课程因此开展——其中有些是我开办的。而现在 UML v2.5 版本即将发布，但我甚至不确定我是否关心（它的发布）。

对于 UML 的发展历史，Scott 做了简要总结：

UML 最初由 Rational Software 公司所开发，现在则是 IBM 公司（我的前任雇主）的一个部门分支。1996 年时，UML 处于“The Three Amigos”（三个朋友）的领导之下，即 Jim Rumbaugh、Grady Booch、和 Ivar Jacobson。UML 版本 1.0 在 1997 年的一月被提出，并在那年的晚些时候被 OMG 正式通过。此后，UML 已经经历了多次版本修改，如 2005 年发布的 UML 2.0 版以及最近于 2001 年 8 月发布的 UML 2.4.1 版本。一个“处理中版本”的 UML 2.5 已经在 2012 年的十月被发布了，并且预计不久将会正式发布。我猜测正式版本将在下次 OML 技术会议中被发布，此次会议将在十二月于 Santa Clara（圣克拉拉）举行。

虽然 Scott 丝毫不怀疑每个参与发布 UML 2.5 版本的人都做了大量的工作，但他仍需要努力寻找一个理由来对这个版本产生兴趣。首先就是 UML 的简化，Scott 指出，UML 2.5 的目标是简化并阐明一个规范文档来减少实施中的问题并且促进工具间的互用性。由于曾经因为 UML 2.0 版本的复杂性而产生过显著的反对，因此简化规范是朝着正确方向迈出的一步。

UML 中的复杂性之一的表现是增加了图表，似乎这对于大多数使用者来说几乎没有任何价值。举个例子，你有没有见过，更别说用过组合结构图（composite structure）、交互概览图（interaction overview）或者通信图（communication ）？你是不是甚至不知道我在说的是什么？好消息是在 UML 2.5 版中，语言本身基本保持不变。然而新的图表已经被增加到总共 19 个了（由 UML 2.0 中的 16 个图）。

新增的图分别是：

• 模型图（Model）。这是包图中的一个特例（类似于自由形式的架构图）。
• 表现形式图（Manifestation）。是部署图或者组件图的一个特例，展示了组件在物理解决方案中是如何体现的。
• 网络架构图（Network Architecture）。这实际上是一个高层次的部署图。

但是，令 Scott 失望的是，依然没有特定用于用户界面或者数据库开发的图。

UML 2.5 的第二个复杂之处，至少对于工具厂商来说，是规范本身在语义方面的不一致。UML 2.5 版本发布的主要重点将是清理规范，也就是理论上说，应该使工具的互通性变得更好。

由于 SysML 空间中的一些意外，自从计算机辅助软件工程（CASE）工具在 80 年代末期问世后，工具的互通性一直维持在“构架（marchitecture-- marketing 和 architecture 的复合词）”水平上。我会让基于 UML 模型驱动架构（MDA）工具的市场份额为自己说话。对于我来说，工具互通性的底线意味着我可以在工具 A 中编辑一个模型，将其导出到工具 B 中，并在那里更新，然后再将其导入回工具 A 中，并且这过程中不会有任何信息的损失。此外，工具 B 并不一定得是一个建模工具。我真正需要的是在我的整个工具包中都能达到这种级别的互通性，而且无论我是用于捕捉高层次的需求还是一路下降到底层运行代码中都应该可以满足。不过更好的是工具能够真正做到无缝的即插即用并且提供一个功能齐全的传递解决方案的堆栈。

Scott 指出，除了在那种定义非常良好的，如在典型要用到 SysML 的地方之外，他怀疑到底能不能理解有意义建模工具的互通性。互通性的主要挑战并不是技术性质的，而是政治上的挑战。

建模工具的厂商，无论他们的营销主张是什么，都不愿去生产与其它工具兼容的很好的工具，因为这对他们来说也是失去顾客群的方式之一。更糟糕的是，甚至有一些厂商提供了很多甚至不与自身兼容互通的工具，更别说与其它厂商的产品互通了。因此建模工具的互通性已经“指日可待”了十多年，并且我怀疑它很长一段时间都可能会停在那了。

为了支持自己的观点，Scott 之前针对 UML 的实际意义做了调查：

我并不是唯一一个对 UML 感到厌倦不堪的人。在 2013 年 10 月的最后一周里，我进行了一个小型的调查来探索出人们是如何进行建模的，包括同时使用 UML 和业务流程建模与标注（BPMN）的人。此次调查总共有 162 个回应，并且调查的详情可以免费下载。每位受访者都听说过 UML（如同我之前说的，UML 确实是无处不在的），但是有 26% 的人从来没听说过 BPMN。只有 13% 的人认为 UML 是非常有用的，并且 45% 的人表示 UML 是有用的，不过他们如果没有 UML 也可以完成自己的任务。另外 20% 的人表示 UML 带来的麻烦比它的价值还要多，并且 22% 的人表示他们根本不用 UML（尽管这些人里 10% 的人表示他们曾在过去的一个月中看过一个 UML 图）。总之，OMG 已经非常成功的推广了 UML，但并没有成功的生产出人们觉得有用的东西。

Scott 认为，也许有一天，基于 UML 的工具将真正提供长期有保证的更高水平的抽象层，从而使软件开发的生产力产生飞跃。但在这个阶段，他怀疑任何这种类型的生产力的提高都将来自于一个完全不同的方向。