这里有一个老外的blog，其中对AndroMDA是否真正的MDA提出了疑问：
http://andrej.racchvs.com/archives/2003/08/10/is-andromda-really-a-mda-tool/
内容如下：
Is Andromda really a [url=http://www.omg.org/mda][url=http://www.omg.org/mda]MDA tool?
The Andromda project just released version 2 of their tool. According to their website Andromda is an open source code generation framework that follow the model driver architecture (MDA) paradigm. It’s a nice tool which will generate j2ee code based on xml diagrams saved as xmi files. So you can design your application in an UML tool (e.g., poseidon), save the diagrams, and then use andromda to generate your application.
Andromda支持XMI，那么它对MOF标准的支持如何？
This is all very usefull ofcourse, but how’s this different than UML tools which generate code? What exactly makes this [url=http://www.omg.org/mda][url=http://www.omg.org/mda]MDA? As i see it, one of the important characteristics of [url=http://www.omg.org/mda][url=http://www.omg.org/mda]MDA is that is has models on different levels, and you’ll have tool based support to keep these models in sync. The three levels in [url=http://www.omg.org/mda][url=http://www.omg.org/mda]MDA are PIM, platform independent model, PSM, platform specific model, and the implementation. Currently the combination of Poseidon (or a similar UML tool) and Andromda seems to be missing the PIM level.
原来他是觉得这里缺少了PIM这一层。
Ofcourse, if you know j2ee and uml, and you just want to be more productive, the combination of a UML tool and Andromda might be exactly what you need.
=========================================================
结果恰巧AndroMDA的首席架构师Matthias路过：
Hi folks,
I’m the lead architect and founder of the project AndroMDA and just came across this interesting discussion. I’d like to contribute.
From my point of view, I say: Yes, AndroMDA is an [url=http://www.omg.org/mda][url=http://www.omg.org/mda]MDA tool. You have asked: What makes it [url=http://www.omg.org/mda][url=http://www.omg.org/mda]MDA?
谈到MDA是什么？他对MDA的理解：
[url=http://www.omg.org/mda][url=http://www.omg.org/mda]MDA is all about modeling at a platform-independent level (modeling the PIM) and be able to map this PIM to a concrete technical platform. Two points make this differ from traditional, CASE tool based code generators:
1) The level of abstraction of the PIM is very high.
2) The level is maintained over the whole project lifecycle. The mapping to a concrete platform can be changed “after the fact”.
What does this mean?
Example for 1): A class in the PIM can mean anything. AndroMDA translates the class to whatever artifact you like, one or more of them. A class in the PIM need not mean a class in the implementation language (e.g. a Java class). The mapping function (product of script helper objects and template code) determines which kind of artifacts are generated. The templates and script helpers are written by the target project’s architects.
Example for 2): An element of the PIM can be mapped to a few Java classes today but may be mapped to a table of bytes driving a state machine interpreter tomorrow. The PIM element remains the same and does not know about this. The high level of abstraction is maintained. Compare this to code generation techniques in traditional CASE tools! An EJB in a traditional CASE tool remains an EJB forever, even if you should find out after three months that you prefer a Hibernate object!
Andrej said: “the combination of Poseidon (or a similar UML tool) and Andromda seems to be missing the PIM level.”
No, we are not missing the PIM but the PSM level, in fact. The models that we design are a kind of “marked PIM”, i.e. a PIM with a small amount of additional markup (tagged values) that configures the code generation process. We skip the PSM because we feel that a PSM does not give our users any additional value.
In AndroMDA, we have a demo app that we call “the car rental system”. The PIM of this app is so platform independent that I was able to port the whole system from EJB entity beans to Hibernate objects in only one hour, once I had written the Hibernate cartridge for AndroMDA!
恩，这确实是MDA的初衷也是价值所在。
One fact made this possible: The high level, platform independent architectural patterns of the car rental app remained invariant. Examples:
Each component has a facade.
Each component throws one exception type.
About the PSM:
In AndroMDA 3.0, we’ll try to let Eclipse regenerate a kind of “very low level PSM” from the code (the so called abstract syntax tree, or AST) and let Eclipse make refactorings to it when AndroMDA detects a refactoring at the model level. But, I would rather not call this a PSM, either.
If you want to know more about all this, you have got two options:
Post questions on the andromda-user mailing list at sourceforge.net.
Come to my [url=http://www.omg.org/mda][url=http://www.omg.org/mda]MDA tutorial at the openMDA 2003 conference on Sept. 15 in Cologne, Germany (see http://www.openmda.de ).
Keep on “MDA-ing”...
Matthias
附录：
下面这个blog中对androMDA的文档给了中文翻译，有兴趣的可以去看：
AndroMDA是什么？-
http://starrynight.blogdriver.com/starrynight/149721.html
AndroMDA：概貌和工作原理- -
http://starrynight.blogdriver.com/starrynight/149726.html
初步印象：
AndroMDA中基于template的形式来进行转换的。从model到text。转换规则被封装为cartridge（Arcstyler中也这么叫）。对于一些特定的应用很有帮助，但未来对于model到model的转换支持，或者说QVT之后的转换实现，目前都觉得不是很清楚……
