AndroMDA 3.0--开源的MDA方案

第2版：2005.6.22 --修改优缺点比较部分

因为有些IDE不支持，一直没有完整留意UML的扩展机制，所以也就以为UML不很适合做MDA。比如生成Hibernate的hbm文件,一些属性的辅助属性比如lazy-load，应该放在Class图的哪里呢?
最近AndroMDA在TSS上发广告，介绍说AndroMDA 3.0出来了。就连过去看了一下。原来除了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文件外，另一个很重要的节点就是<namespace></namespace>节点,指明了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语言，谁不想自己的东西标准化一点，谁不想被招安阿。
第二是模型可以使用图形化的工具维护模型了。

2.代码的生成
大家使用Velocity系的Template Engine，只不过它有现成的Cartridge，估计还会不断增加，众人拾柴，比自己孤军奋战，一些大点的模板根本没法写（从经济学角度）好多了。

缺点：
1.OMG UML真的是最好的模型语言吗？
MartinFowler也不赞成基于OMG UML的MDA，说UML用来作为描述沟通是一个好工具，但作为形式化的模型描述语言就未必那么好用。甚至时序图之类的图在描述也不见得设计得有多好，至少不见得比流程图，伪代码容易读。
所以，大家都喜欢MDD，但未必喜欢基于OMG UML的MDA。

2. UML是彻底的图形语言，XMI很难直接文本编辑器
只能使用图形化工具维护模型了，没有了以前XML文件的文本级的简单。
即使不想再讨论图形好还是文本好，但我还是喜欢两者结合得比较好的方式，UML里暂时还没有结合得很好。

3. AndroMDA居然完全靠Ant,没有IDE工具
好歹也该写个Eclipse插件啊

4.怎么现在大部分的代码生成模板都只是基于Class类图的
其他图的应用呢，show me a sample please。