這里有一個老外的blog，其中對AndroMDA是否真正的MDA提出了疑問：

http://andrej.racchvs.com/archives/2003/08/10/is-andromda-really-a-mda-tool/

內容如下：

Is Andromda really a 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 MDA ? As i see it, one of the important characteristics of 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 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 MDA tool. You have asked: What makes it MDA ?

談到MDA是什么？他對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 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之后的轉換實現，目前都覺得不是很清楚……

AndroMDA：是真正的MDA實現嗎？