2）DSL特征，在Module类中增加方法，以便用户类在定义时调用。

class Module
  @@doc = {}
  def doc(str)
    @@doc[self.name] = str
  end
  def Moduel.doc(aClass)
    aClass = aClass.name if aClass.class <= Module
    @@doc[aClass]
  end
end

class User
  doc "here is the doc for user"
end
 
3）条件定义

def foo
  if $DEBUG
    def foo
      puts "debug version"
    end
   else
  end
end 

4）匿名类

class User
   @class_val = 123
   class <<self
     def aClassMethod
       puts @class_val
     end
   end
end
 

下面谈一点关于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），它们或多或少地采用了翻译范式：由高层抽象到底层实现，以更灵活的领域概念表示手段。现在看来，没有具体领域的涉及和积累，这些工具或方法只能是说教。

待修正。。。

To seperate the Practical lang (P, PL) from the Kernel lang (K, KL),  we can use a namespace liked mechanism to rewrite the PL prog as follows:  
P::fun K::{ P::Sqr P::X K::} P::X K::* P::X K::end
P::B K::= K::{ P::Sqr K::{ P::Sqr P::A K::} K::}

Above shows that the constructions of KL can be  reused in a PL prog.
 
if PL is UML and KL is MOF:

1) how are MOF first-class concepts reused in UML, is an instance of MOF subset of an instance of UML?

2) how is an instance of UML translated into an instance of MOF?

3) how is an instance of MOF running and the result is still an instance of MOF?

4) if HUTN is a text lang for MOF, how is a HUTN prog running and the result can still  be described by HUTN?

Although the second question is partially solved by UML2MOF(a sub-tool of MDR), but i think the new abstractions of UML, such as Action, Message, Event are thrown away by UML2MOF.  That is to say that NO MOF first-class concepts are corresponding to them, such as the translation from an instance of UML::Message to an instance of MOF::Class will lose the meaning of UML::Message. This is key problem of MDA langs family.

This also give us a  tip: using what formalism (MOF,UML,CWM) to describe a grammar of a target lang is NOT the key concern, we can use any metamodel to describe the grammar, but can we give the real meaning to the target lang?

(omod PERSON is

    inc HUMAN .

    inc CONVERSION .

    inc CONFIGURATION .

    class Person | name : String, age : Int .

    subclass Person < Human .

    op getName : Object -> String .

    op setName : Object String -> Object .

    msgs name : Oid Oid -> Msg .

    msgs name-r : Oid String -> Msg .

vars X O : Oid .

vars N N1 : String .

vars A : Int .

eq  getName(< X : Person | name : N >) = N .

eq setName(< X : Person | name : N>, N1) = < X : Person | name : N1 > .

rl [Person.name] :  name(X, O) < X : Person | name : N >  => < X : Person | > name-r(O, N) .

endom)