定义UML核心 面对UML不断增长的系统复杂性和更短的时间限制，新一代的建模者正在致力于消除，而不是增加这个已经很庞大的软件设计标准的复杂性。这是在2000年6月15日第二次国际年会上，《SOFTWARE DEVELOPMENT》技术编辑Roger Smith在主持完由工业界杰出人物组成的专门小组的圆桌讨论之后得到的结论，并于会后将讨论会的内容组织成本文，发表在《SOFTWARE DEVELOPMENT》上。
在第二次UML国际年会上，《SOFTWARE DEVELOPMENT》技术编辑Roger Smith主持了在下列人士之间展开的圆桌讨论，他们是:Cris Kobryn，OMG UML修订任务组和OMG分析设计平台任务组联合主席；Martin Fowler，Melrose和Mass.-based ThouhgtWorks的首席科学家;Scott Ambler，Ronin国际软件服务咨询公司总裁；Peter Coad，Togethersoft公司的CEO。讨论的焦点是UML的变革途径，即UML的核心是什么，或者说应该是什么，以及如何来扩展它。
SD(software development):Kobryn，什么是UML核心？我们可以怎样扩展它？
Cris Kobryn：你可以将UML的核心看做实质的UML，它可以用来对89%的普通问题建模。该核心可以在元模型层次上用元类或其他具有丰富语义的元实体（相对于具有贫乏语义的元实体而言）来定义。
任何优秀的设计者的设想都是：下一代语言应该从这种语言中精简出来，而不是向其中添加。就是说，当没有东西可添加或者可删除的时候，设计就做完了。
我们对2.0发布版承诺的关键部分是:一个精简的核心，加强可定制性，以及改善对基于构件的开发（比如EJB、CORBA和COM+）的支持。特别是2.0发布版将从体系结构上精简核心，并使之与其他关于元数据集成和储存的OMG规范（例如元对象设施MOF）更加一致。
此外，对模型管理的支持将有所改进，包括辅助分层、多视点和构件框架。目前的共识是，模型版本管理不属于新版UML的范围。版本和图的交换应该由OMG的另一个结构规范来处理，叫做XMI（即XML Metadata Interchange 格式规范，是一个通过Internet进行对象数据交换的标准协议）。XMI不但可以用来交换模型语义，还可以用来交换模型图。
开发商们对修订会支持到什么程度？很显然建模者希望UML易学易用，UML的复杂性使他们晕头转向，他们指出了很多UML的错误和使用中出现的问题，其中许多都超出了微小修订的范围。用户因为缺少工具支持而经常混淆工具带来的局限和UML规范本身的局限，这使得他们很难明智地、准确地批评UML。UML开发应该是市场驱动的，如果用户要求支持UML 1.3、1.4或2.0，开发商就应该提供。
Scott Ambler:两天前，我和这里的Norm Kerth和Neil Pitman在"UML世界"的一个为期一天的实习班上一起工作，这是我和Norm第三次在这种实习班上工作，有件事引起了我的注意。今年参与的每个人几乎都做了同一件事：他们用了Use Case、顺序图和类图。此后另一个组做了活动图，但那是仅有的不同。而在1999年UML国际会议上，我和Norm教了同样的实习班，使用同样的笔记、同样的讲演，但是那些小组所用的方法要多得多，有些甚至超出了UML的界限。有人使用数据建模，还有人使用屏幕模仿。但是今年没有人做屏幕模仿。这些人都是职业的软件开发者，很有经验，也知道自己在做什么，但他们没有想要超出UML的范围。
Kobryn：Ambler，他们做了一些元模型吗？
Ambler：没有，那正是问题所在。哪怕他们只做了元模型建模，事情也就好办了。学生们也反映到，他们需要一些方法、步骤或是一些关于如何使用UML的指导。客观地说，UML并不是一种方法论或一种过程，但他们的意见恰恰显示了他们赞成所有能真正符合现实世界发展的软件过程。注意我没有提到Rational统一过程（RUP）。
所以我打算持相反的观点，并且要争辩说UML还不够复杂。根据我作为现实世界开发者的经验来看，UML并不充分。我经常问：为了实际交付应用软件，我需要做什么？当我问自己这个问题时，我很快发现UML遗漏了一些可以提供的东西，例如数据模型或用户界面模型，为了交付软件，我几乎每天都要做这些东西。我需要理解用户界面，而且要知道如何存储数据。在UML中我没有看到这些东西。或许Kobryn可以帮助在UML 2.0中注意这一点。
我们也学着对适当的工作采用适当的工具，这些工具可以是白板或纸。而有的时候，我喜欢选用丰满的CASE工具，好的CASE工具可以简化对UML的应用，如果你精通它的使用方式的话。
SD：UML是否应该考虑界面的设计或人类工程学因素？
Peter Coad：在我的印象中，Ambler在很多文献和演讲中提倡这样的观点:UML是一种建模语言，人们可能还要做其他一些事来勾勒出它的结构，例如描绘用户界面设计等。Jared Spool的《网站可用性：设计者指南》就是这方面的一部经典著作，它将用户界面设计和诸如类图、交互图、特征表之类的东西结合起来。但最终将在UML模型中放进这些商业的东西和用户界面吗？这必须是UML的一部分吗？我看不太合适，虽然这是好的工程实践的一部分。
Ambler：我认为UML应该能够描述窗口导航图或用户界面流图。不管怎样，我们在一些Web扩展中看到了这些。如果能将它提取为用户界面元素而不是Web用户界面元素，那就更好了。说实在地，我很怀疑Web外围的必要性。
Martin Fowler：我不同意这样的观点。如果不同的人用不相容的方法做相同的事，那应该在把它放到UML之前去统一它。我并没有看到在用户界面设计方面已经有这方面的尝试。许多有趣的用户界面设计思想正在浮现，但我不认为已经达到可以将其拉到标准中的程度。有些东西虽然重要，但并不意味着它必须进入UML核心。
SD：Fowler，我确信你对此有独到的观点，因为你曾说过你全然没有高估UML工具。你说过你可以用黑板和粉笔做正规的建模。但是否UML正变得太复杂而不适合那样做呢？
Fowler：UML肯定需要简化。不过因为各种技术和人为的因素，简化工作并不是很容易。现在UML之所以会庞大到这种地步，正是因为一帮方法学家都将他们喜欢的技术加进来。
而当UML日渐成熟，并不是所有好的技术都要成为其中的一部分，UML的威力在于它允许人们做类似的事情并用通用的表示方法来表达。如果人们想做一些不同的东西，例如做Doug Rosenberg的健壮图，我认为不应该把它们并入UML。
即使这样UML还是有些庞大，Kobryn有一项困难的工作摆在面前，那就是要想方设法将核心缩减到最小。因此，我尝试着提出一个核心。我在实践中发现，有三种技术应该包含在UML内：Use Case、类图和交互图，剩下的可以进入某种扩展机制。这样我将其中很多东西都去掉了，不过还有更多需要去除的东西，在Use Case中真正有用的部分是它的文本描述，而Use Case图虽然使用起来很方便，但不是必需的，去掉Use Case图的Use Case严谨而简洁。
有很多符号是为特殊功用而设的，但哪些表示法能满足大多数的需求？我想它们应该是类、属性、操作、关联和泛化。我认为不大应该将交互图去掉，顺序图也用得比较广泛，或许可以去掉协作图，因为目前对它的使用并不多，虽然我也觉得这样有点激进。最后就剩下Use Case的标题、类图和顺序图，足够小了吧？
SD：但是Use Case图很流行，有些人觉得Use Case图是沟通管理者和最终用户的最好方式,对他们来说该怎么办呢？
Fowler：我不是说你只使用我提出的核心，你可以使用任何对你有帮助的技术。实际上，我甚至没有说你应该只用UML。但当我考虑UML核心的时候，我得问，"什么是我能让人轻松接受建模思想的最小数量？"在进行实际建模时并不会只使用核心，我自己也不会。但那是我提议的最低限度。
SD：工具开发商们不应该支持比最低限度更多的内容吗？
Fowler：每一个开发商都应该支持核心和不同的UML扩展片段。而购买者应该能将它们分出层次，并且知道自己需要什么。
Kobryn：将核心与其扩展部分分开并不像人们所想像的那么困难。UML元模型的结构良好，虽然其中有缺陷，但要看怎么说。比如开发商完全或部分地遵守基础语义、行为语义和状态机了吗？他们将语义和表示法分开了吗？有很多这一类的问题，但开发商并不认为自己应该这么做，而用户也没有要求他们这么做。
Coad：为争取更多的人使用UML，OMG可以提供预定义外围的方式。而UML的用户也应该学会选择自己想要的东西，即有较强的能力来定制他们的工具。
SD：我们为什么需要一个UML核心？为什么不把实践这个最重要的东西摆在首位，或者让市场决定呢？
Kobryn:自然选择是可以决定哪些在核心里面，哪些不在，但是我们必须首先处理那些语义贫乏的东西，我的意思是先清理语言本身然后再进行自然选择。此外，因为我们被卷到这个浑身长毛的东西的肠子里，所以一些清理工作必须从体系结构上进行，也要从用户层次上来做。办法就是通过围绕一个核心的若干外围来做这件事，就像Unix的内核思想一样。
SD：如果状态图、活动图等元素不是核心的一部分，工具开发商们会不会找到一种方式，使用他们自己的外围来代替这些元素？
Fowler：我想状态图等工具上的分歧不是问题，状态图作为核心的扩展，是标准的一部分，如果你想支持状态图，你可以将它作为UML标准的一部分来开发。再强调一遍，核心不是整个的UML，重要的是选出一小部分。让开发商来做互不兼容的东西，而当不兼容成为问题时，UML的人就会站出来说："好，让我们统一吧。"事实上，UML的崛起就是由于许多人做了一些相互矛盾的事情，而我们统一了它们。
Kobryn：我同意。UML中某些最丰富的语义与状态图和活动图有关，我们当然不会把孩子和洗澡水一起泼出去。状态图和活动图可以放到外围中，或者通过某种规则将其放到定义良好的元模型扩展中。因此，让我们明确一点:如果你想遵循Fowler和Coad建议的原则做一些简单的事情，你可以把这些原则作为依据。但它的定义必须清晰，这样当用户买一个工具的时候可以知道他得到了什么。
SD:各位愿意看到UML 2.0发布中有些什么呢？
Ambler:我对OMG加入更多的软件工程方法提出异议。我们为什么不首先对我们谈论的这些新的外围设立需求呢？这是我对OMG的异议：首先是需求，然后才是设计。
Fowler:我不觉得UML目前需要很多修改。除了它以外还有很多更重要的东西：好的软件设计原则、理解模式、对软件过程的关注等。最主要的是UML能在一定程度上解决无聊的争论，那时我们就可以转移到更有趣的东西上。
Coad:我发现以小组的方式进行工作能够导致复杂性的瓦解。在17世纪，Blaise Pascal这样写道："我应该写更短的信，但我没时间。"或许现在就是考虑更短书信格式的时候了，这对我们的工作会有所帮助。
Kobryn:如果有团体的支持，核心的实现不是目前需要解决的主要问题。现在应该注意需求，要在几个月内将需求文档定稿，时间已经相当紧迫。它不是指令性的，也不能由任何一个开发商支配，我鼓励每个人都去评论它。我希望已经唤起了这样的公众意识：UML并不一定是你在自己喜欢的建模工具中所实践的那样，问一问你的开发商，至少搞清楚它们的产品是否遵守UML 1.1、1.3或其他版本。最后，我想鼓励你直接参与，把你在RTF划定的范围内不能建模的特殊问题发送给我，我会关注它们。
