UML很棒但是过于庞大了

早在1997年，统一建模语言UML就已经作为一个标准被采用了。这个语言的应用无所不在，适用于所有类型的软件。它帮助许多企业更好地开发软件。对于UML的采用目前仍然在不断增加，但是，没有5-10年前增长得那么快。其中一个原因就是，UML变得过于庞大了。无论如何，这个问题肯定是可以解决的。

最初的UML是由一个非常小的称为三剑客的团队： Grady Booch , Jim Rumbaugh和我所开发的。我们的昵称是三剑客——我没想到会用在自己身上的一个词。一旦确定了我们所希望达到的目标，于是，我们开始在全球范围内邀请其他的方法学家加入。毫无疑问，UML的核心部分是由我们三个来实现的，同时，其他的参与者也都做出了很重要的贡献。Grady, Jim和我经常通过远程通讯会议进行交流，也就是通过这种方式，我们做出了大量的决策。我们的工作效率非常高。该语言的第一个正式版本是UML1.1，它在1997年秋就被OMG组织（国际对象管理组织）所采用，这距我们真正开始开发UML仅仅不到一年的时间。这简直就是所有语言标准化尝试的纪录。

UML2.0是UML革命的下一步，它的开发过程虽然遵循标准的OMG步骤，但是与UML1很是不同。目前，一个由二十多人组成的委员会接手了UML2.0。当初，我们是以敏捷的方式开发UML1，而这个委员会采用另外一种非敏捷的方式来开发UML2了。2005年7月16号，UML世界大会在德克萨斯州，Austin市召开，其间，在关于UML的集体讨论中，Steve Cook发表的言论，给人以“UML1非常杰出，相反UML2却很糟糕”这样的印象。

UML2实在是太过于庞大了。仅仅规范就大概有1000页！虽然它包含着许多非常好的观点，但是，仍然有太多的工具提供商为自己进行宣传的篇幅。任何一个实际操作者都不会阅读这本说明书的。

关于UML语言从UML1到UML2的发展过程，有太多的工作要做。从UML1发展到UML2， UML1需要一个巩固时期，以积累更多的经验和进行细微的协调，但是，很不幸UML1从来没有经历过这样一个阶段。相反，UML2的开始却是从极为庞大的扩展，新组员希望改变任何他们不喜欢的部分。

Grady和我没有参加UML2的开发工作。在UML2的实现过程中，这个委员会做出了很多值得置疑的修改。举个例子，我发现该委员已经决定对用例进行修改，改变成和我最初介绍的且一直这样被大家理解的用例完全不同的内涵。他们声称说我实在不懂什么是用例，这个问题必须由他们来解决！没错，这确实是一件真实的事情。

当他们决定改变用例时，我立刻就知道了这件事情，于是我尽快给这个委员会写了封邮件，表达我非常严肃的态度。我告诉他们，如果他们改变用例的根本意义的话，我绝不会支持UML2。可想而知，这封邮件根本没有起任何作用，该委员会丝毫没有变化！因此，我必须向Rational公司的最高管理层表达我的担心。Rational公司向该委员会明确声明，如果用例这个本质改变的话，那么，用户团体将对此有消极反应，而且UML语言的声誉也会因此受到严重损害。Rational公司强调，改变用例本质这一点是不可接受的，并且或多或少威胁不再参加UML2.0的开发。我们参与UML2.0委员会的两个成员，被委派对修改要非常谨慎，在接受任何修改之前必须先咨询由Rational专家所组成的小组。

对于任何参与其中的人来说，这段发展史是非常具有戏剧性的。曾经有段时间，我坚信自己必须公开指责UML2。幸运的是，UML委员会回头是岸，我也就不再需要走这戏剧化的一步了。但是，UML在这个巨大委员会的影响下还是变得越来越庞大。现在，所有UML的爱好者都不得不承受着这个错误带来的痛苦。

不管怎么说，UML在根本上还是非常好的语言。基础的技术已经经过了数年的实践证明。举例说明，爱立信公司曾经表明，它在1969年就已经开始使用UML了，因为在那个时候，我们就开始使用组件图、时序图，协作图，状态图以及状态转换图（状态图和活动图的组合）。

因此，一方面，UML已经有了良好的基础，但是另一方面，它也在不断的增长，变得越来越笨重。我们知道，通过使用不到UML20%的内容，你就可以构建超过80%的软件系统。那么，我们需要做的就是，抽取出人们的确需要使用的那20%，进行精确的定义。实际上，我们已经开始做这件事情了，并一直坚持着。我们称这部分人们经常使用的20%的UML为20%EssUML。EssUML并不是一种新的语言。它甚至对UML没有进行一点修改。它仅仅是UML的一个适用子集。 

 

注：本文是Ivar Jacobson先生于2006年3月30号所著。