因为有些IDE不支持，一直没有完整留意UML的扩展机制，所以也就以为UML不很适合做MDA。比如生成Hibernate的hbm文件,一些属性的辅助属性比如lazy-load，应该放在Class图的哪里呢?
最近AndroMDA在TSS上发广告，介绍说AndroMDA 3.0 M3作为正式版前的最后一个MileStone已经推出。就连过去看了一下。原来除了StereoType，UML另有Tagged Value的机制,可以把一些属性附在类的方法和属性上。
AndroMDA的结构应该说比较开放和实际的
1.AndroMDA使用过程
1.程序员通过Poseidon or MagicDraw 绘制UML图并导出XMI 或者使用 Schema2XMI工具从数据库生成XMI
在绘制的过程中需要加入AndroMDA所需的StereoType和Table tag,column Tag等。
MagicDraw似乎比较难看，而Poseidon还提供AndroMDA的plug-in，什么功能还没细看。
2.用户通过Ant运行AndroMDA
Ant脚本除了指明xmi文件外，另一个很重要的节点就是节点,指明了Hibernate，Spring所需的一切项目级资料比如生成目录,数据源名称等。
3.AndromMDA解释XMI为相对高层的概念,然后调用Cartridge的Velocity语法模板的生成目标代码文件。
目前提供EJB，Hibernate，Spring等几个Cartridge。
如果要扩展Cartridge，只需要按照文档所教的方法，从内到外进行各种层次的增加，修改和替换。
2.五个核心部件
核心部件的设计代表了AndroMDA扩展的野心
1.Template Engines
目前使用Velocity作为模板语言,支持向其他语言的扩展。
2.MetaFascade
提供一个高层的Meta-Data访问API， 支持UML1.3、1.4、2.0等等语法的MOF model并可自行扩展。
3 Repositories
支持从XMI文件中读取MOF model，支持其他格式的扩展。
4.Cartridge
通过MetaFascade读取元模型，通过模板生成代码的核心。AndroMDA自带了Spring,Hibernate等Cartridge，也可自行扩展。
5.Translation-Libraries
把平台无关代码翻译成平台相关代码。比如Hibernate的getXXX()方法的HSQL语句，用者可以选择用Tagged Value写在模型里，也可以选择写成平台无关的OCL查询语言，然后用Query-Translation把它翻译成Hibernate HSQL，日后也可次翻译成EJB的EQL。
目前有Query和Valiations两个Library，亦可自行扩展。
3.AndroMDA的意义
AndroMDA带出的最重要的信息是，相对标准的，开源的MDA方案开始可用了，无数程序员不懈的代码自动生成的分散努力，有望纳入一个比较统一的框架内进行。
对比自己的简易版MDA方案：
1.模型的编写与维护
好处第一是, 以前的模型是自己制定的XML标准，现在是标准的UML语言，谁不想自己的东西标准化一点，谁不想被招安阿。
第二是模型可以使用图形化的工具维护模型了。
坏处也是，只能使用图形化工具维护模型了，没有了以前XML文件的文本级的简单。
2.代码的生成
大家暂时都是使用Velocity，只不过它有现成的Cartridge，估计还会不断增加，众人拾柴，比自己孤军奋战，一些大点的模板根本没法写（从经济学角度）好多了。
坏处就是以后修改扩展模板都要循规蹈矩，依足手续，比原来的随意扩展麻烦好多。
等他的正式版出来, 正好也是我们项目结束, 整理代码以作重用的好日子吧.
