关于MDA的长期等待

 

很久没有写blog了,有工作原因、有对MDA的思考和(初浅)实践原因。

下面谈一点关于MDA的感受。

1. PIM-PSM-CODE

这是MDA眼中最MDA的软件开发方法,也有工具如OptimalJ实现了这种范式,当初在成立mdachina.net的时候,这个工具被俺之辈如视MDA之珍宝,俺则是把它的文档全看了,例子也做了一些。以为自此可以draw & run with a true MDA tool,可是事实并非如此。

OptimalJ对于PIMPSM同步做的不好,几个PIM->PSMPSM->PIM来回下来,建模者估计会对OptimalJ的模型同步逻辑(通过某种标记表示模型的是否可更新)晕倒。

OptimalJ对于CODE模型缺乏更逻辑的分离机制。在CODE保护块中编程而不是利用语言分离机制(如类继承,import之类),将导致很难管理机制与手工代码的逻辑边界,增加了代码的混乱。也许除了用不同颜色区分手工代码与机制代码之外,还要加上另一层UI(模型)表示这种区别?,明明PIMPSM清楚地表示了业务模型和技术模型,到了CODE模型,基本上是另外一回事了(因为PIMPSM具有广谱效应:一个模型映射为多个代码段),可是要在CODE模型中增加手工代码,除了保护段外没有更好的、更逻辑的方法,则是很令人失望的。

当然不只是OptimalJ才有这种问题,其它号称true MDA工具的,也有类似的问题。这里不一一表来。

2.       仍是重复工作

当前MDA的主流还在与3GL做相同的工作,类描述,代码生成,粒度太小,做个小应用还累的半死:安全,集群、cache等等还要手工编码(设计就没图了)。因为几乎所有的MDA工具都有一个底层假设的边界:OptimalJ/ArchStyler只做了常用J2EE的建模和自动生成,androMDA要好一点,除了常用J2EE还有一些轻量级框架,而那种像VExtUML则只能在更小的范围内可以自动化。事实上,一旦需要超出MDA工具的底层假设边界,则一切得自已实现:codemodeling, metamodeling, code generator designCMMC)。然后再是模型集成,这不是一件容易的事,似乎MDAMDD之类的方法学,强烈地依赖于开发团队有自治建模/元建模的能力,在现在这种快速delive系统的时代,谁有时间做metamodeling,除了俺这种没事找事的人。

3.关于复用

的确,在MDA上下文中,模型(设计)复用变的更加真实,就是除了设计图纸的交流以外,还要在建模工具、代码生成器层面上做到复用的保证。IP之父也说过类似的话:复用DSL和产生器比复用结果组件好的多。可是若结果组件与模型没有太大差别(就像当前PIM这种低级抽象),或者结果组件具有高度的可配置性(如EJBSpring BeanXML配置),那么DSL和产生器复用与高度可配置的组件复用并没有本质差别,前者更增加了开发费用。

奇怪的是,至今在MDA环境下,大家还在研究UML类图、状态图、对象图之类的语言级别的模型语义。对于含有领域级别的丰富语义的模型,很少见到公开发表。幸好有一个MDA学者做了这方面的初期工作,在那里我们可以看到应用商业构架型技术构造的领域模型,如:CRM应用的模型(moneyorderperson等一套可复用的类)。可是,这方面的工作还少的可怜,试想我们做系统时,有多少次在使用money, orderperson概念,有多少次在重复地为money, orderperson建模?,从这个角度讲,领域模型库确实有用。但是领域模型库要到真正的结果组件,按MDA的走法,同样存在PIM-PSM-CODE的问题,还有不同的建模工具所导出的模型版本问题、UMLCASE工具依赖的问题。这个痛苦的现实使得领域模型库更多是做为信息交流而不是drive MDA机器。

 4.关于丰富的应用

从当前MDA实践来看,除了一些trivial的系统可以快速开发以外,大的、另类的系统基本上是没有公开发表过。我们不能凭一两个(或是多个)成功的trivial应用(petstorecafeshop)就有足够的勇气说:任何系统都可以用MDA方式解决。前面已说了,一旦需求超出MDA工具所能提供的边界,你将走上:(CMMC)的不归路,虽然有:GME(Generic Metmodling Environment)EMF,之类的元建模工具,这些工具的逻辑其实不容易把握,除了在“元”字闹鬼以外,基本上与应用域无关,或者只是trivial地表示一个应用域的概念和工具内实例化(而不是代码生成,这些工具都假设你可以很好地做代码生成工作),其它事情,you must CMMC

于是,俺最初幻想有这么一个工具具备强大的元级能力(像smalltalk这种具有真反射能力的语言、工具和环境,像objecteeringUML内置的模型操纵语言和强大的uml profile与插件绑定),可以实现CMMC的复杂工作,现实情况是它们仍然只是一种元建模的枷锁,元建模真的要这样做吗。

5.关于元建模

元建模一直被认为是MDA的高阶应用,动不动就要MOF重型扩展来解决领域建模的问题,其实在俺看来:重型扩展基本没有必要,而且导致模型重复,试想重型扩展是不是还要再建一遍类似的MOF::Class,MOF::Attribute,MOF::Association概念?,UML profileMOF重型扩展更好,因为UML profile不需要重复设计MOF/UML结构。

6.关于LOPGPMDD

MDA的路一旦走的不顺,什么变种的方法都来了,LOPLanguage-Oriented Programming),GPGenerative Programming),MDDModel-Driven Development),MDSDModel-Driven Software Development),它们或多或少地采用了翻译范式:由高层抽象到底层实现,以更灵活的领域概念表示手段。现在看来,没有具体领域的涉及和积累,这些工具或方法只能是说教。

待修正。。。

posted on 2006-03-07 15:33 阿飞外传 阅读(...) 评论(...) 编辑 收藏

导航