关于MDA的长期等待

 

很久没有写blog了，有工作原因、有对MDA的思考和（初浅）实践原因。

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

1.　PIM-PSM-CODE

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

OptimalJ对于PIM和PSM同步做的不好，几个PIM->PSM，PSM->PIM来回下来，建模者估计会对OptimalJ的模型同步逻辑（通过某种标记表示模型的是否可更新…）晕倒。

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

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

2.       仍是重复工作

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

3.关于复用

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

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

 4.关于丰富的应用

从当前MDA实践来看，除了一些trivial的系统可以快速开发以外，大的、另类的系统基本上是没有公开发表过。我们不能凭一两个（或是多个）成功的trivial应用（petstore，cafeshop）就有足够的勇气说：任何系统都可以用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 profile比MOF重型扩展更好，因为UML profile不需要重复设计MOF/UML结构。

6.关于LOP，GP，MDD

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

待修正。。。