可以看到1990年的早期版本已经对对象模式和相关技术有着浓厚的兴趣。基于这个模式的新的编程语言（比如Smalltalk, Eiffel, C++, 和Java）已经被设计并投入使用。伴随着这些语言出现的还有令人惊叹和难以理解的面向对象（object-oriented（OO））软件设计方法和建模符号。因而在彻底的纵览了有关OO分析和设计方法后（包含800页以上），Graham列举了50种以上的有相当大影响力的方法（Graham01）。考虑到对象模式包含了基本概念的相对较小的子集（包括封装、继承和多态），很明显，在这些方法中存在非常多的重叠和概念上的结合--大多数情况下是由于符号性的和其他并不重要的差异而使其变得很模糊不好理解。这样就导致了令人难以理解以及不必要的市场分歧—反过来也阻碍了有实用价值的新模式的采用。软件开发者很难在这些相互矛盾的语言，工具，方法和供应商中做出选择。
由于这个原因，当Rational 软件随后提出了统一建模语言（UML）的初始版时--在Grady Booch，Ivar Jacobson和Jim Rumbaugh的领导下--得到了快速和积极的反响。其目的并不是为了提出任何新的内容，而是—--通过高级领域思想领导者们的协作—--把各种各样的OO方法的最好特性添加到一个单独的和与供应商无关的模型化语言和注释中。正因为如此，UML很快地成为了一个广泛的实践标准。随着1996年对象管理组织（Object Management Group）对它的采用，UML成为了一个广泛被接受的工业标准[OMG03a] [OMG04] [RJB05]。
从那以后，UML:
被绝大多数的模型工具开发商所采用和支持
成为全世界大学和各种各样的专业培训项目中计算机科学和工程课程中必不可少的一部分。
开始被学术和其他研究者所使用，并作为很便利的公共语言。
在处理复杂软件时，UML同样能够帮助增强对模建模价值的普遍的认识。尽管这种非常实用的技术几乎和软件本身一样历史悠久—――像很早以前的例子那样它们都带有数据流图（flowcharts）和有限状态机—――大多数开发人员慢慢地才接受它，如同接受其他工具一样，而不是像接受一个有用的小工具那样迅速。客观的说，这种对新事物的态度仍旧是一个占有主导性地位的，这就是为什么模型驱动方法在这一领域中受到很大的阻力的原因。
之所以会存在上述情形是有一些原因的（当然也有些不是那么有根据的原因，比如：通常人们并不相信创新）。主要原因是软件模式经常会导致不可预知的严重性错误：我们都清楚，任何一个模式的实际价值与它的正确性直接成比例。如果一个模式不能把它所表示的软件系统向你准确的表现出来，那么还不如不用模式，因为它可能会导致错误的结论。那么提高软件价值的关键在于缩小这些模式和它们所模式化的系统之间的差距。然而，正如这篇文章后面所论述的，在软件中减小这种差距比在其他任何的工程学科中要容易的多。
某些错误的软件模式归咎于当前编程语言的过多的细节和敏感的本质。一些较小的失误和几乎不被发觉的编码错误――比如指针偏差或者变量未初始化――可能会带来严重的后果。举一个实例来说，在一个有相关文档记录的案例中记载，由于一个嵌套的switch语句中的某个case中少了一个break，结果导致美国的大部分地区失去了长途电话服务，以致带来了巨大的经济损失【lee92】。如果这些看似微小的细节会带来如此可怕的后果，那么我们又如何相信模式的正确性（因为从定义上来看，模式应该用来隐藏或是去掉这些细节）？
模型驱动开发
解决这一难题的方法是通过一个或多个自动的模型转换器将一个模型与它相应的软件实现从形式上连接起来。也许这方面最好和最成功的例子就是编译器，它能够将一个高级语言程序解释成一个与之相当的机器语言的执行程序。这种情况下，模式就是这个高级语言程序，它就像所有有用的模式那样，隐藏了潜在的计算技术特性上的相关细节（比如内存字符大小，累加器的个数，索引寄存器，ALU算术逻辑单元类型等等）。
有趣的是，几乎没有任何其他的工程媒介能够为一个模型和它相应的工程工具提供如此紧密的连接。这是因为你所模式化的工具是软件而不是硬件。任何一种物理工具的模式（比如：一辆汽车，一座建筑物，一架桥等等）不可避免地包含了一些步骤，它会将物理特性抽象成一个相应的模型（就像数学或几何模型一样）。同样，使用物理原料实现一个抽象的模型包含了从抽象到具体的非正式转换。这一非正式步骤的本质会导致一些错误，正如上面所提到的，会导致模型效率低下或是甚至达不到预期目的。然而，对软件来说，原则上，这种转换可以从各个角度的形式上的执行。
在抽象性和自动化抽象性与自动化操作强有力的结合后,所产生的潜能已经导致新的建模技术和相关发展方法的出现,正如所提及的模型驱动开发MDD) [Brown04] [Booch04]。MDD的定义特征是,此模型已经成为软件设计的主要工具,它把许多注意力从相关的程序代码上转移开。它们为不同的自动化和半自动化的方法提供服务,这种方法源于代码和相关的模型。与传统的编码相比较，目前在MDD中使用自动化操作的程度不同于从简单框架代码到完全自动的产生代码。很明显地，自动化程度越高，模型越精确，MDD的优越性就更突出。
软件发展的模型驱动方法不是一种独特地新式方法，在过去就已经被使用并获得了不同程度地成功。他们之所以愈来愈受重视的原因是，其支持性技术已经愈来愈成熟，成熟点在于比起过去的情况来看在实践上更加自动化。这不仅仅在效率方面，而且在可测量性方面，同样这种工具所具有的能力是与继承性工具和方法相结合的。这种成熟技术所反应的MDD标准的出现，使得使用相关的工具时更加便利舒适，给使用者带来显而易见的好处。其标准之一是统一建模语言的修订版。
文章来源于领测软件测试网 https://www.ltesting.net/