标准程度如何 标准 UML？

(摘自 Martin Fowler 的专栏，最初发表于 1999 年春季的《分布式计算》杂志)

几年前，我咨询生涯中最令人厌烦的事情之一就是方法论之争：关于使用哪种符号的激烈争论。这些争论总是引起很多热议，而且几乎总是毫无意义——我们选择哪种符号并不重要。由于 UML 的出现，大多数争论都烟消云散了。我们现在有了标准符号。但正如人们所发现的，标准并不能解决所有问题。

现在出现的问题往往是更详细的问题：如何在 UML 模型中表示某个特定事物，或者某个特定 UML 结构对我们的实现环境意味着什么。令许多人惊讶的是，对于许多这些问题，并没有现成的答案。

为什么会出现这种情况？一个主要原因是传统。建模方法，无论是面向对象还是其他，从来都不是非常正式的事情。定义留给直觉，而且存在许多空白。具有形式化方法背景的人批评这些方法的这种做法。他们认为，缺乏严谨性意味着模型中存在太多歧义。但现实情况是，许多人发现，尽管缺乏形式化，但非正式方法通常比正式方法更有用。在实践中，非正式性似乎是一种优势。

UML 中存在正式元素。这些元素的核心是元模型：一个描述 UML 结构的 UML 模型。但即使是元模型也留下了许多空白。它可能将属性定义为一种结构特征，其类型是分类器，但当我编程时，这到底意味着什么？在 Java 中，它意味着一个字段、一对 get 和 set 操作，还是一个操作的参数？如果你问十位 UML 专家这个问题的答案，你可能得到的唯一共识是答案包含“视情况而定”这几个词。元模型的主要目的是定义一个格式良好的模型，以便 CASE 工具将来可以进行通信。它距离真正严谨的方法还有很长的路要走。
 

处理多种解释

那么，这对您意味着什么呢？首先，这意味着您将看到许多对 UML 的解释。这些解释将出现在书籍、培训课程和项目文档中。您需要意识到这一点。与过去方法之间的差异相比，差异要小得多，但差异仍然存在。在团队内部，您需要针对这些问题达成更标准的共识解释。在这样做时，要警惕任何以极大确定性断言一种解释正确或错误的人。有些事情是相当明确的，但许多事情并非如此。

如何选择解释？首要原则是了解您使用 UML 的目的。如果您使用 CASE 工具生成代码，那么使用的解释必然是 CASE 工具代码生成器的解释。如果不是，那么首要目的是通信。因此，您需要选择一种最能与其他人进行沟通的解释。这是关于标准的一个重要观点，它鼓励我们对图表进行共同解释。

我认为，解释问题将类似于自然语言（如英语）而不是定义语言（如 ANSI C）。不会有一个单一的机构来对 UML 解释进行裁决。如果这样的机构存在，那就是 OMG：通过其分析和设计工作组。它掌握着 UML 标准的关键。但他们永远不会对所有问题进行裁决。即使他们确实做出了裁决，常见做法也可能与官方路线有所不同。这类似于法语学院的作用，它禁止使用诸如“faire du shopping”之类的短语，但无法阻止它们进入日常用语。

因此，就像英语一样，引导共同使用的一个重要部分将来自 UML 大师，那些自命不凡地对正确和优雅的 UML 进行评论的人。在这幅图中，三位好友将是特别重要的大师。他们的著作将具有很大的分量，但并不一定具有绝对权威。

除了解释的差异之外，我们还会发现完全不同的符号。许多人会认为 UML 中存在一个重要的差距，并提出一些新的扩展来解决这个问题。其中一些将通过 UML 扩展功能（如原型和类似功能）顺利地融入其中，而另一些将完全偏离 OMG 文档。同样，这些扩展的兴衰取决于其他人是否采用它们。

选择解释

这种将 UML 视为自然语言的观点也暗示了它如何发展。自然语言通过人们将语言推向不同的方向而发展。那些有用的语言会进入通用用法，然后逐渐变得更加标准，那些没有用的语言会逐渐消失。我认为，在未来几年，我们将看到对 UML 边缘的相当多的推动。这是一件好事，因为它将使 UML 保持活力，并允许它发展。这种边缘推动发生在 UML 之前的方法中，许多想法都找到了进入 UML 的途径。差异具有共同基础这一事实将使这个过程更容易，甚至可能加速 UML。因此，不要指望它保持静止，并期望官方标准落后于最佳用法几步。
对 CASE 工具的影响

CASE 工具在这个标准世界中扮演着特殊的角色，它们的决定将影响您使用 UML 的方式。本质上，CASE 工具必须选择如何玩 UML 游戏。UML 对 CASE 行业的最大优势在于它使他们摆脱了支持多种方法的必要性。他们现在可以集中精力在 UML 上做一些有用的事情。

为了支持 UML，他们必须支持 UML 元模型，但所有解释问题仍然适用。例如，我们将看到代码生成器做出的不同决定。它们不仅会生成不同的代码，而且还会对它们生成的代码的意图做出不同的决定。因此，您会发现，在一个 CASE 工具中的 UML 与另一个 CASE 工具中的 UML 并不相同。

CASE 工具谈论它们检查您的图表的能力，以防止您犯错误。他们认为这是一个功能，但我并不确定。我知道我想做什么，当我发现一个 CASE 工具不允许我做我需要做的事情时，我感到非常恼火。人们认为这对经验不足的开发人员来说是一个福音，但我认为，一个好的审查过程比机械检查更有价值。工具忽略了沟通的微妙之处。因此，不要让 CASE 工具成为您绘制内容的仲裁者。您的大脑随时可以战胜 CASE 工具。