建模动力：UML2.0使模型驱动的开发更加容易

Rational公司新加坡分部的高级软件工程专家，Mark Hermeling认为：UML2.0根据工业界使用UML1.x的经验作了相应改进，目的就是为了帮助简化模型驱动的开发。

UML的目前版本是1.4,它提供了方便开发团队在分析设计、需求管理等活动中进行交流的整套工具，以及一个软件开发生命周期模型。

有人将UML描述为交流的符号集，这意味着可以直接写在纸上或者画在白板上。但大多数用户还是选择使用工具，目前业界的领导是Rational，它和其它的工具提供商一起提供各种UML产品。

1996年，UML刚诞生的时候，广受欢迎。在UML之前，建模方法非常多，这大大阻碍了基于模型的设计，而UML实现了建模语言一定程度上的统一。

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

经过多年的发展，在Rational 公司的Booch、Rumbaugh、Jacobson 三友以及其它专家的努力下，UML中还融入了很多其它的思想，现在，UML已经成为OMG认可的标准。

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

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

目前，在各种工具之间进行模型交换时，只能保存非图形化的信息，而象绘制的各种图、尺寸、坐标这样的内容都会丢失。在UML2.0中，将提供保留图形信息的能力。

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

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

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

首先，对建筑工程来说，工程师一般都有多年的经验并且对所用的各种工程符号了如指掌，而UML的设计可能在纸上画出来看着很好，真正编程时却会发现很多问题。另外，在建筑工程上，关键设计都是可以经过数学分析进行验证的；而在UML设计中，类似的手段只有同行评审，虽然有一定作用，却并不能避免错误的发生。

另外，在成本比例方面，软件设计和其它领域的工程也是截然不同的。举修桥的例子来说吧，设计成本可能也就占全部成本的 10％,而在软件设计中，这个比率是50％。

UML最早是由Rational公司提出的，但已经被很多公司使用，这里面最重要的就是OMG。公众对UML的接受刺激了以模型为中心的开发，OMG提供了支持这种开发的一系列标准的框架MDA（Model-Driven Architecture）。MDA的关键特点就是软件开发的重点和输出不再是程序，而是各种模型，开发人员的工作是不断拓展模型，只有到了最后阶段才会考虑将其实现。

OMG认为，利用MDA可以得到更好的“高层抽象”设计框架，更好地得到针对今天各种语言的“通用化”代码。和正在酝酿之中的基于XMI的数据交换一样，基于MDA的数据交换方法将给开发商和用户双方带来好处。
XMI（XML Metadata Interchange）试图通过XML语言为程序员和其它用户提供一种交换元数据信息的标准途径。XMI希望能够帮助使用各种语言和开发工具的UML开发人员自由地交换数据模型，另外，XML也可以用于数据仓库信息的交互；最重要的是，XMI制定了描述各种元数据定义的统一标准，并要求跨行业和跨操作环境的用户使用一致的方法读取数据。

今年6月，包含OMG MDA标准，促进模型交互的UML基础库修改版已经正式提交讨论。参与讨论的包括用户熟悉的很多开发商，包括I-Logix, Oracle, Rational, Telelogic and Computer Associates等等。
UML2.0中还将包括对组件建模的改进。近几年来，随着J2EE和微软的.NET技术的出现，组件技术得到很大发展。这方面，UML2.0中将考虑如下内容：如何更好地描述组件描述的语意以及构建.NET和企业JavaBeans的专门模块。

Jim Duggan ，artner公司的副总裁和研发总监，认为UML2.0中要处理的首要问题就是保证标准的扩展性，他认为现行的标准中扩展机制定义得不够，导致各开发商使用了不同的扩展方法。另外，还必须提供对组件开发、面向服务的框架以及web services的支持。

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

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

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

其它公司，如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也开始进入。

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

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

事实上，UML正在将工具开发商们凝聚在一起，很多公司都参与了UML2.0的修改过程。除了Rational之外， Microsoft、Sun、IBM、Oracle、Borland、Telelogic等公司也都是UML协会的成员。