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.
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.
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.
August 12th, 2003 at 12:17 am
I believe the assertion is made that the UML diagrams themselves are the PIM and that Andromda allows you to generate the PSM. If you were to create a business model and a workflow for that model then use Andromda to generate a J2EE application from these diagrams, it might generate EJBs.
Now, whether this is much useful since the architect has the most responsibility to utilize the tools efficiently and correctly, I am not sure. I have been reading quite a few articles and the book about executable UML. I believe that in this paradigm, we have not come quite far enough with the platform specific code generation with Andromda. Another aspect that would be missing in executable UML is the activity language bindings for your UML diagrams. But this is another issue to resolve for a future MDA tool I guess.
I am somewhat impressed by Andromda and it does seem able to cut some of the development time for initial project designs. I am wondering what would happen once you have generated the platform specific code, add the model specific code and then have to make a modification to the model. It does not seem to be able to handle model specific code. It will just generate another skeleton of the code.
Oh well, I am waiting for the perfect tool to come down the line and generate the application binary from my design. Maybe I should get off my rear and work on one?
August 12th, 2003 at 12:40 am
The greatest thing about the tool, in my opinion, is that it allows full control over the actual architecture that you’ll output. Most of the tools out there, whether they generate code from a UML model or offer the full MDA features you describe, force you to use their architecture or their output patterns. Because you can write your own templates and your own cartridges, you have complete control over the output you generate and can evolve your own architecture over time, rather than being forced to use elements of some out-of-the-box architecture.
August 12th, 2003 at 4:47 pm
This issue of whether a tool is MDA or not is a problem with the OMG and the MDA ‘standards’. Just calling them ‘standards’ has some people debating the term. I think the OMG is going have to step up and provide more detail on the role of a generator and the standards involved.
Currently the vendors and authors I have talked with tend to shake their heads about ‘real MDA’ and concentrate on the fact that what they are doing, model based active code generation for applications, is valuable.
August 12th, 2003 at 11:45 pm
> I believe the assertion is made that the UML diagrams themselves are the PIM and that Andromda allows you to generate the PSM
I think that’s correct. When you run ant to transform your uml files to code you have to specify what technology should be generated, ejb or hibernate.
Looks like there’s no difference between PSM and code model. I think that’s what they are working on for release 3.0. They are building a psm repository so that they can detect refactorings on the PIM, and determine how the code model should be changed.
> The greatest thing about the tool, in my opinion, is that it allows full control over the actual architecture that you’ll output.
I think this is part of most MDA tools. OptimalJ allows you to add new technology and code patterns. And Oracle’s Application Development Framework also allows you to choose which technologies you want to use, and i believe you’ll be able to extend it with new technologies.
August 18th, 2003 at 12:00 am
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 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!
One fact made this possible: The high level, platform independent architectural patterns of the car rental app remained invariant. Examples:
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:
Keep on “MDA-ing”...
Matthias
November 26th, 2005 at 8:21 pm
AndroMDA is just an excuse to sell magic draw copies, since it only works correctly with this tool. Poseidon support is provided for certain models, but certanly with bugs. Also,it has the poorest usability ever seen by human race. The tool is hermetic, and I can’t see a business analyst using UML to define technology dependent things like ejb homes.
The last comment is: The AndroMDA team is so sure of itself, that most of the generated code can’t be customized, even with modern merge technologies avaible.
Beware that AndroMDA is a step to reach MDA, but it’s far beyond being usefull in real projects.
November 4th, 2006 at 1:59 am
I have been using Andromda and Magic draw for around a year now. And I must say that though the code generated by Andromda is well designed, the development on Andromda is at a pretty slow pace. They still do not support UML 2.0 out of the box. You need to play the trick of converting it to emf uml2 to use within eclipse. And for that you need to purchase Magic draw 11.0+ version.
At the end, it is just a ploy to sell more magic draw copies. Andromda is open-source but magic draw IS NOT.
November 4th, 2006 at 1:59 am
I have been using Andromda and Magic draw for around a year now. And I must say that though the code generated by Andromda is well designed, the development on Andromda is at a pretty slow pace. They still do not support UML 2.0 out of the box. You need to play the trick of converting it to emf uml2 to use within eclipse. And for that you need to purchase Magic draw 11.0+ version.
At the end, it is just a ploy to sell more magic draw copies. Andromda is open-source but magic draw IS NOT.
June 25th, 2007 at 5:01 pm
Hi, the andromda have improved all the last complaints:
– Andromda supports UML2.0 – You can model in Eclipse with the GMF plugin or other tool. – The Andromda4 uses modern transformation technology components from the Eclipse.org community:
* ATL = Atlas transformation language for model-to-model transformations
* MOFScript = a language for model-to-text transformations
And many others new cool stuff