四个阵营
Steve Cook将MDA研究者划分为三个阵营,Martin Flower也同意他的观点,并针对这三个阵营对待Language workbench的态度进行了详细的讨论。另外,Martin还提出了一个MDD阵营。总结他们两个人的意见,可以将MDA阵营划分为四个部分,其中有的阵营是完全对立的,而有的则是兼容并蓄的:
1. UML PIM阵营:使用UML来建立PIM,然后利用模型转换来生成PSM,最后用PSM生成代码;
2. MOF阵营:不使用UML,而用MOF来代替,建模语言和模型转换都使用MOF来定义;
3. 可执行的UML阵营:建立UML编译器,将UML直接作为编程语言,使UML可以执行。
(以上来自于Steve Cook的blog,原文如下:
1. The UML PIM camp: MDA involves the use of UML to build Platform Independent Models (PIMs) which are transformed into Platform Specific Models (PSMs) from which code is generated.
2. The MOF camp: MDA does not involve the use of UML, but instead the crucial technology is MOF, and the definition of modelling languages and language transformations using MOF.
3. The Executable UML camp: MDA involves building a UML compiler, making it a first class programming language.
)
4. MDD(Model Driven Development)阵营:他们也可以说不属于MDA的阵营,因为他们并不关心OMG的MDA系列规范。他们关注的是模型驱动的开发思想,可以说,MDA就是MDD在OMG规范上面的实现。
也有部分研究者将MDA划分为狭义和广义的两个阵营。同上面的联系起来看,狭义的MDA即前三个阵营,而广义的MDA即MDD阵营。我是这么认为的。
UML PIM阵营
UML PIM阵营可以说是目前最强大的,因为它是如此符合MDA最初的构想,从大家了解最多的UML开始建立PIM,然后转换为PSM(例如CORBA,J2EE,.NET),然后生成代码,一切看来都如此流畅,和以前出现的技术可以兼容,并且也不缺少工具和厂商的支持。
但是,它也是受到诟病最多的一个阵营,一个最大的问题就是关于UML是否是平台无关的问题,如果UML不是平台无关的,则显然它不适合用来构建PIM。MOF阵营的人对于UML的抛弃就是基于这个原因,他们认为MOF才是MDA的本源,过多的使用UML会导致不能真正的构建PIM,因为UML本身就是一个平台。我觉得关于平台无关的争论可以休矣,当初C也是被认为平台无关的,只要在不同的操作系统上重新编译一次即可;后来的CORBA也号称一举解决了网络平台不兼容的问题;再来就是J2EE。可是,当你解决了上一个平台相关问题时,你所创建的新技术同时变成了一个新的平台,如CORBA平台,J2EE平台等。为了解决不同的CPU硬件平台不兼容,发明了操作系统;为了解决不同的操作系统问题,发明了高级语言;为了解决网络不兼容问题,发明了中间件;为了解决中间件不兼容的问题,发明了MDA和web service等等技术。目前看来,使用UML来建立的模型基本上具有平台无关性,我(我是属于UML PIM阵营的)认为使用UML来建立PIM是合适的。
UML PIM阵营的另一个问题是,UML过于繁琐,UML2.0标准充斥着各种各样作用不大的填充物,不仅没有能够让UML更加实用,反而导致了UML的复杂度增加,可用性下降。就好比要使用一个锤子,但是UML给出了一整个房间的工具,在里面翻了半天却没有找到一把合适的锤子。唉。。。因此MOF阵营的人就决定自己去造一把锤子,反正它和UML一样,都贴有OMG出品的标签。
当目前的UML不能完全满足需要时,UML给出了标准的扩充机制,也就是Profile(包括Stereotype和tagged value)。但是,很多人认为UML的扩充机制和UML自身一样,过于复杂,还不如用MOF重新构建一个建模语言(我倒不这么认为,感觉Profile还是比较简单的)。
还有一个不能回避的问题是,UML PIM阵营更加注重系统的结构,而不注重(不能解决)系统的语义(动作/流程),因此很多人倾向于去掉UML动作语义,或者根本不使用UML动作语义。
尽管UML PIM有这么多的缺点,但是其优点也是显而易见的:1.符合标准;2.对于普通的软件从业者来说,学习UML比学习MOF要更容易一些;3.可以使用的工具更丰富一些。
MOF阵营
使用MOF来直接构建建模语言和模型转换语言在一些书中称为“重量级”方法,而使用UML Profile来扩充UML生成新的建模语言称为“轻量级”方法。由此可见,学习和使用MOF是一件比较耗时的事情,但是这并没有阻挡MOF阵营的脚步,他们认为MOF才是MDA的核心,才是纯粹的MDA。
MOF定义的四层模型,几乎将以往的模型概念一网打尽,在前人的基础上(M1层和M2层的模糊概念)又定义了M3和M0层。其中M2层可以包容以往所有已知的建模语言规范,然后定义了一个唯一的M3层,可以创建出所有这些建模语言,目前所有已知的模型技术中,唯有MOF是拥有M3层的,而且它是自定义的。这样MOF兼容并蓄了所有的建模技术,成为一支独大的元元模型工具。目前几乎所有的建模工具都号称MOF兼容的,因为做到这一点实在是太容易了,只要稍微修改一下自己的模型规范即可。可以这样认为,所有不愿意使用UML的建模者,在MDA出现后一定倒向了MOF阵营。而且,新的模型语言和DSL的创建和使用者,也大部分会倒向MOF(使用UML Profile对于这些人来说,不如使用MOF来得顺手和自如)。
OMG在制订MDA之初很明智的让MOF脱离了UML,这样增加了MDA的生命力,与其让MDA技术与新的技术竞争,不如将MDA分化为几个阵营之争。MOF的缺点是学习困难,工具较少,而优点则是灵活自如。由于对MOF没有深入研究过,姑妄言之。
可执行的UML阵营
这个阵营的人一定不会介意我将UML称为第四代语言。在第三代语言(高级语言)瓜熟蒂落之时,就开始了第四代语言的争论,到底第四代是属于SQL这样的描述性语言,还是类似于Agent系统这样的智能系统,或者网格?神经系统?Web Service?但是这个阵营的人会自豪的告诉你,第四代语言就属于可执行的UML,其他的无论影响力还是问题域的覆盖性,统统不如。(可能我的语言有点偏激,大家不要砸砖。。。)
这个阵营里面的人有个很好听的名字,“模型程序员”。当UML真正可以执行了,对于高级语言程序员的需求量就会像现在的汇编程序员一样稀少了。(写到这里,想起了前年和几个网友一起为MDACHINA论坛的《模型程序员》写稿的日子,时光荏苒啊,转眼都当爸爸了。)可执行的UML也是MDA研究的热点,尤其是在MDA技术提出之初,所有的MDAer都满心欢喜的想象UML编译器的出现,可以将手头的模型直接转换为可执行程序。在OMG网站内部,就介绍了三本可执行UML的书籍。
当然,在可以预计的将来(2,3年内?),我都想象不到可以有完全不产生高级语言代码的UML编译器。也许在某个局部领域内可以实现,但是能够做到像高级语言编译器那样完整,在目前是根本不可能的。原因很简单,目前的UML表达能力有限,它不能完全承载程序所需要的信息。即使是UML扩充了动作语义之后。
那么,通过进一步的扩充UML有没有可能呢?当然是可能的!当初谁也不认为高级语言可以完全取代汇编,可是现在已经很少有人再用汇编了(特殊领域如驱动程序等除外)。但是,目前的一个困境就是,UML已经过于臃肿了,已经由于体积的庞大遭到很多人的抛弃,如果再进一步扩充UML,是否会更加引起众人的反感?
对于这种困境,我建议将UML分为两个部分:UML前台和UML后台。前台是在目前UML的基础上进行精简,使之更加易学和实用;而后台是为了定义UML编译器,可以加入更多语义方面的东西。这样,可执行UML阵营的人可以致力于定义UML后台,使之能够完全承载目前高级语言所能表达的语义,从而使UML的执行成为可能。类似于java虚拟机,UML虚拟机也是可能出现的,在这个虚拟机上面,用UML前台编写的模型可以自动运行,如果在前台中没有定义详细的细节,那么后台可以加上大量的默认值使其可以运行。
MDD阵营
MDD阵营严格说来不一定属于MDA阵营,因为他们无视MDA的诸多规范,而是自成一体。他们是典型的“拿来主义”者,有用的就拿来,没用的就扔掉。很多人号称MDA的支持者,但是从来没有遵循过任何MDA的规范。他们只是拿来了模型驱动的思想来武装自己的开发方法。不过他们也许更加清晰的认识到MDA的精髓,毕竟他们还没有在冗长的MDA规范中泡得发白。
从另一个方面来说,他们是更加纯粹的MDA支持者,因为MDA Guide的开头就说:MDA is an approach to system development, which increases the power of models in that work. It is model-driven because it provides a means for using models to direct the course of understanding, design, construction, deployment, operation, maintenance and modification. MDA是一种方法,而不是仅仅是规范。
小结
谨以此文,献给那些还在MDA泥潭中挣扎的战友们,愿能抛砖引玉。很多地方都是我猜测的,不一定完全属实,如果需要在正规文献中引用,请参阅超链中的正规文献(我链接的很多也不是正规文献,汗!都是blog),或者参阅其他文档。