按语：本文整理自2003年的一个阅读笔记。下面的引用文字，来源于《建模动力：UML2.0使模型驱动的开发更加容易，Louis Chua，computerworld，中文翻译：袁峰，UMLChina，2002-10

（以下缩进段落为引用文字，正常段落是笔记）

有人将UML描述为交流的符号集，这意味着可以直接写在纸上或者画在白板上。但大多数用户还是选择使用工具

“交流符号集”这种看法其实反应了UML的一种思路来源，它是隐隐地为“文档”记述的。认识到符号是次要的是一个飞越。

进行面向对象设计的时候，{dy}步就要对现实世界进行建模，UML正是为之定义的一套标准符号，它由三种面向对象的分析设计方法发展并整合而来：Grady Booch 描述对象及其相互关系的方法、James Rumbaugh的对象建模技术(OMT) 以及 Ivar Jacobson的方法，在Ivar Jacobson的方法中引入了use case方法的使用。

“对现实世界建模”，这是多么空泛的目标，却这样轻易抛出了。UML的设计目标到底是什么？软件建模与所谓现实世界建模的关系到底是什么？

尽管UML只是帮助参与开发的所有人员对模型进行交流的一套符号系统。但Martin Fowler在其著作《UML Distilled》中指出，UML是由描述开发过程和有关模型的使用的方法论发展而来的。尽管目前没有被广泛接受的统一过程，UML的使用者使用的方法实际上都非常相似。UML规约中有关建模的概念是对象、类、关联、职责、活动、接口、use case、包、顺序、协作和状态。

这句“尽管”后面隐藏了很多意味，人们（其实应当可能也包括了UML制订者自己）将它当作一套符号语言多过模型规范——它的名字就是如此。

既便我们接受UML作为{zd2}层的建模规范和工具，要建成复杂的世界，也还需要许多高层的规范。

在使用当前版本进行UML模型驱动的架构时，使用者发现还缺少一些支持，如bug修复等，UML2.0中将增加这部分内容，它将成为适用于企业建模和数据建模的庞大而灵活的符号语言。在UML2.0中，将对语意部分进行增强，这一点可以帮助UML模型更好地生成代码，以得到更加实用的模型。在即将推出的版本中，还将包括增强的组件处理、对商业过程模型的支持，并更好地支持元数据交换。这些努力都是为了使UML作为一种胜过大多数文本语言的高层次的语言，能够生成代码和进行反工程，甚至直接生成某些可执行的UML模型。

“它将成为适用于企业建模和数据建模的庞大而灵活的符号语言”——这个宣言恰恰对应着对UML的一些怀疑：无疑，UML（包括类似的面向对象建模）与数据模型例如E-R模型有某种深刻类似和关联，但毕竟不是为数据建模而设计的；当用于企业这样复杂的系统，它好像实在是太简单和吃力了。而所谓“可执行的模型”，一方面又提醒我们，UML的目标与用途，乃至设计者的领域，毕竟、终归是“软件建模”，一方面它又引发了软件（代码）与软件的模型之间的区别问题。从“对现实世界建模”，到“企业建模”，“数据建模”，又回到软件的“可执行模型”，中间有许多本质性的“跨越”。如果一个建模体系的用途、目标是如此随意，那么这个世界上就不会出现这么多的建模语言了。

来自Rational公司的Hermeling认为，工程师与开发人员将越来越多地看到对建模的需求。他认为，对于一个较大的开发团队来说，需要有一个可视化的模型以保证所有人员都能理解总体的设计思路，建模的需求是显而易见的。

接着上面的问题：这里说的才是实在的。更为中肯的说法也许是：前面所谓“现实世界模型”、“企业模型”，都是给软件设计者看的，是作为软件设计的一种“输入”或“环境”而做的。但这种合理的解释，仍然存在一些问题：如果一个现实世界模型，或企业模型，是现实世界或企业本身的专家“看不懂”的，怎样证明它真正反映了建模目标的真实情况？再进一步，所谓“现实世界”或“企业”模型，到底是应当由软件专家创建呢，还是由该领域的专家创建？如果换成领域专家，我们又有什么理由假设，领域专家所建立的模型（包括他们认为适合的表示法），是软件专家所喜欢或期望的？在这些背景问题含糊的基础上形成的“通用”建模语言，难免会四不像吧。

利用业务过程建模，应用UML可以得到业务的可视化模型，其作用类似于建筑工程中的结构图。这个可视化模型可以使你在构造整个软件系统之前，就可以理解并预知设计的一些关键特性，判断设计是否可行。事实上，除了软件工程，在众多工程领域中，建模都是非常关键的规避风险的技术。

在传统、成熟的工程领域，例如机械、建筑、电子，其专门的建模技术都是用来xx表达其制造物本身，而不是制造物存在或工作的环境；在这些工程领域，将建模理解为“规避风险的技术”，即使算不上不恰当，至少也是非常“弱”的理解。

但是，在Fowler眼里，软件工程和其它工程是不同的。

首先，对建筑工程来说，工程师一般都有多年的经验并且对所用的各种工程符号了如指掌，而UML的设计可能在纸上画出来看着很好，真正编程时却会发现很多问题。

这句话可以称之为“露出了马脚”，神乎其神的UML原来是这样吗？

另外，在建筑工程上，关键设计都是可以经过数学分析进行验证的；而在UML设计中，类似的手段只有同行评审，虽然有一定作用，却并不能避免错误的发生。

这个基本的分析显示了UML的不足。机械图纸要经过加工这样一个容易走样的过程来达成最终的结果，而软件的模型如果达到了自动编程，则它应当直接自动产生最终预期的结果；另一方面，如果模型的描述是用户可以理解的（至少用户所将接触或面对的部分），那么用户对这样的模型进行审核的效率不会比对机械图纸审核的效率相差更多。

不应当认为软件模型不可以达到机械模型的严谨水平，而由于软件模型可以借助软件本身来表达，所以在与最终结果的符合性方面，是可以达到机械模型所无法达到的境界（例如所谓自动编码，或更进一步的，“模型驱动系统”MDS）。

公众对UML的接受刺激了以模型为中心的开发，OMG提供了支持这种开发的一系列标准的框架MDA（Model-Driven Architecture）。MDA的关键特点就是软件开发的重点和输出不再是程序，而是各种模型，开发人员的工作是不断拓展模型，只有到了{zh1}阶段才会考虑将其实现。

这的确是观念上的进步。但是回顾一下前面的问题：其实在提到“现实世界”或“企业”模型时，最不能忘记的是“软件模型”（即对所要开发的软件建立的模型）——这才是UML本来的、xx和基本的功能吧。许多时候可以发现，人们往往忘记了它所讨论的模型，到底是软件模型，还是软件工作环境——现实世界中的事物的模型。

OMG认为，利用MDA可以得到更好的“高层抽象”设计框架，更好地得到针对今天各种语言的“通用化”代码。和正在酝酿之中的基于XMI的数据交换一样，基于MDA的数据交换方法将给开发商和用户双方带来好处。

MDA的输出是“通用化代码”，这就将模型驱动降格为编程了（MDA本来立意就不高）——接着这里的话题说，混淆“执行代码”和“系统模型”，这恐怕是认识上的一个陷阱。

有人提倡，UML的发展应该是向下兼容的，要保证过去基于UML1.x的用户和工具开发商所做的努力不会全部作废。UML2.0中应该提高xx度，可以选择加入少量的一些新特性，要避免导致“语言膨胀”的困境。而现在有一个不妙的苗头： UML将变得越来越大，而在最初，OMG声称的目标本来是简单化的。

在声称“现实世界建模”的那一刻，所有复杂性的种子就已经埋下了。另一方面，试图在单一层次中建立（模拟）最复杂的对象（现实世界？），可能又是一个陷阱。

Gartner公司的Duggan认为，“新的规约正在变得越来越复杂，变得非常大，难以管理、理解和实施。标准委员会曾经说过将要把物理模型和逻辑模型分开。但是，一旦规约复杂化了，要做到这一点就不大可能，而且规约本身也开始失去作用。”

为什么会觉得不大可能？也许这里缺乏实质性的层级划分，或者某种可扩展的框架。

Alistair Cockburn，Humans and Technology的顾问，在他的论文中表达了同样的意思。“在软件开发中把人也当成了非线性的、{dy}位的组件”，Cockburn认为那些重量级的开发方法中试图为一切建模，这是导致成功率不高的重要原因。他认为在软件开发中人是最重要的，在设计符号中把人当成一个组件，就是{zd0}的失败之源。

把人纳入等于纳入了不确定的因素，模糊了系统的边界，但这不应当是UML应用失败的{zd0}原因吧？看来许多时候，人们不单把UML建模的目标从软件本身扩大到了软件的应用环境，还扩大到了软件开发系统（环境）。

其它公司，如Telelogic也在致力于利用UML2.0从图形化的用户模型中自动生成代码。Telelogic在新加坡和亚洲其它地区创建了开发中心，力图提供帮助从概念模型转化到组件的软件。Scott Raskin（如图），Telelogic公司亚太地区总裁，认为亚洲是这方面增长最快的地区。“UML允许组织从计划到嵌入式系统实现的全部生命周期实现自动化”但是，对于有些程序员而言，并不需要UML，他们完成的代码中通常都很难找到相似的地方，对他们来说，模型是多余的。

看来，大家顺利成章的想法就是自动生成代码。软件系统模型和软件系统执行代码的实质性区别是什么，这无疑是一个陷阱。

Gartner公司的Dugguan警告说，“要记住，UML只是一种符号，并不是什么方法论”。但事实上，几乎所有的面向对象分析与设计（OOAD）工具和业务模型都是使用的UML。Dugguan指出，根据Gartner公司的估计，在所有项目中，使用OO A&D方法论的大概有10%到12%，和过去使用CASE工具的峰值数值几乎相同。Dugguan认为这个数字还会继续增加到15%到20%。在数据建模领域，IDEF符号还在广泛使用，但UML也开始进入。

这个警告如果成立的话，等于宣告了UML的宿命。取代IDEF1X，也许是可能的。建模语言本身虽然不是方法论，但似乎不可能也不应该独立于方法论。较弱的理解，至少有匹配性、适合性的问题。

Dugguan认为，设计工具的总体使用率还是很低，在项目中使用设计驱动开发方式的大概有10%，通常是那些对质量和持久性要求很高的项目。而数据建模工具在项目中使用的比率大概是35%，大多数情况下都是由DBA使用。

这是奇怪的：数据建模不是由应用开发的主要设计者，而是由所谓的数据库管理员做。

尽管UML可以和白板一起使用，但它还是复杂了些。Gartner公司认为有以下原因导致了UML的低使用率。首先，在小的短期项目和开发周期中根本不用设计，都是采取的快速开发和演进。Dugguan说，“根本不需要{zj0}实践，能用的实践就够了。”第二个原因是大多数遗留的程序都是面向过程的，不需要UML或者什么工具。但他又加了一句：“新的事件驱动和对象驱动的程序开发技术可以从UML工具中受益，新的开发人员很多都学过这些符号，而且会用相关工具”。

面向过程的程序开发就不需要UML？稍微跳跃一点思考，这是否在暗示面向对象的程序开发就会产生所谓“现实世界建模”的需求，以及“软件模型”和“软件代码”的区别呢？这是值得深入思考的话题。

小结

能够对目标达成某种描述是一回事，能否在特定的应用环境中成为有效的建模手段，达成特定的建模目的又是一回事。UML无论从设计还是应用现实看，无疑还是一种“软件系统建模工具”，而软件模型、软件代码、现实世界（领域或企业）模型，它们之间存在本质区别。忘记了这一点，难免会带来许多困惑。

UML作为一种通用的建模语言，在软件开发领域看来颇为成功，“统一”的目标似乎也达成得不错。与程序设计语言目前的多样性、企业建模领域的状况相比，似乎也能说明这一点。

然而，对UML的用途不应过于夸大，乃至忘记了它的“本分”是什么，陶醉于“{wn}建模语言”的幻想。正如对软件的一种常识性的经验：许多软件产品，都是在其最初的目标达成并成熟时是{zh0}的。随后往往自我膨胀，趋向于保罗万象，无所不能，这通常就意味着开始走向生命周期的衰亡进程了。只有坚守本分，才会更长久和不可替代。