Andromda: is it a true implementation of MDA?

Here is a foreigner's blog, which raises a question about whether andromda is actually an MDA:

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

The content is as follows:

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 supports XMI. How does it support the MOF standard?

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.

He thought there was a lack of 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.

========================================================== ========================

As a result, Matthias, the chief architect of andromda, passed:

Hi folks,

I'm the lead impact ect and founder of the Project andromda and just came authentication SS this interesting discussion. I 'd like to contrision.

From my point of view, I say: yes, andromda is an MDA tool. You have asked: what makes it MDA?

What is MDA? His understanding of 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 each action 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 temporary ts.

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 specified action 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 shocould 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 has Al 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!

Well, this is indeed the original intention and value of MDA.

One fact made this possible: the high level, platform independent specify tural patterns of the car Marshal 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 woshould 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

Appendix:

In the following blog, the documents of andromda are translated into Chinese. If you are interested, you can see them:
What is andromda? -
Http://starrynight.blogdriver.com/starrynight/149721.html
Andromda: Overview and working principles --
Http://starrynight.blogdriver.com/starrynight/149726.html

Initial Impression:

In andromda, the conversion is based on the template format. From model to text. Conversion rules are encapsulated as cartridge (also called arcstyler ). It is helpful for some specific applications, but in the future it is not very clear about the conversion from model to model, or the conversion implementation after qvt ......