AndroMDA is a code generation framework that follows the Model Driven Architecture (MDA) paradigm. It takes a UML model from a CASE-tool and generates classes and deployable components (J2EE or other) specific for your application architecture.

The new release 2.0.3 is rock solid now and the usability (installation, starting the first project) has improved greatly. The package now features a "blank project wizard" which automatically creates a pre-configured AndroMDA project as a quick start for new users.

The new features of release 2.0.3 final include:
* Quite a number of bug fixes (code and documentation)
* Easier installation due to new distribution structure: two ZIP files only (one with source, one with binaries)
* Easy startup due to the "blank project wizard" for projects generating EJBs or Hibernate objects
* Better error messages as guidelines for new users
* Integration as a plug-in for the CASE tool Poseidon: edit your tagged values in an easy GUI dialogue and start the generator from inside your CASE tool!

We have now branched for AndroMDA 3.0 which will include:

* Refactoring at model level: Make a design change in your UML model and re-generate without breaking project integrity.
* Better EJB cartridge supports inheritance from abstract EJB classes.
* JDO cartridge generates JDO objects.
* Eclipse integration: run the generator as an Eclipse plugin.
* Model transformations: translate from one model abstraction level to another before going to code generation.

See http://www.andromda.org/ and/or come to the openMDA 2003 conference in Cologne/Germany (see http://www.openmda.de/ ) to get a hands-on AndroMDA tutorial!

Cheers...
Matthias Bohlen
AndroMDA lead architect

On the website it says that you need to download JBoss to
use AndroMDA. What is the dependency here?

Is some JBoss classes used when generating? Or is it
just that AndroMDA currently only generates the
needed extra descriptors for JBoss?

Regards
/M

hi Mikael,

AndroMDA can generate EJB classes from a UML model, the actual deployment of these beans can only succeed after running XDoclet on these classes, that way the proper interfaces are generated, including deployment descriptors

so to answer your question: the default velocity templates that decide what goes in these generated EJB classes only add XDoclet tags for JBoss AppServer, if you want you can easily add some tags for Weblogic, Resin, etc...

piece o' cake

If I might add, I must say personally I am very convinced MDA is an efficient way to reach a solid and stable architecture for your J2EE application. AndroMDA proposes an elegant and clear solution, I have successfully used it in a couple of projects and must say that I feel more confident about my code.


Wouter

The documentation for AndroMDA states it takes a Unified Modeling Language (UML) model from a CASE-tool in XMI format and generates custom components. So I am wondering which are the best OSS tools for building these UML digrams?? I looked through the AndroMDA documentation and didn't see any recommendations from them (except for products from commerical vendors: Rose, Together, ...).

I think that they also recommend Poseidon UML (www.gentleware.com) for model creation. The community edition is is an open source product.

Hi Chris,

sorry but Poseidon is open source based but is not open source in itself! It is based on ArgoUML (see http://argouml.tigris.org/) but is closed source software. However, the Community Edition is downloadable at no charge (just to avoid the word "free" here).

ArgoUML is an open source tool that used to have some stability problems. And: as far as I know, it supports only UML 1.3, not 1.4 as we need it.

Another alternative are MagicDraw from NoMagic. It is quite cheap ($300) and stable.

Cheers...
Matthias

Poseidon is based on ArgoUML but it's a commercial product and quite stable. All of its editions, including the free community addition, support UML 1.4. It think it's a pretty good product and is especially well-suited for work with AndroMDA. If I'm not mistaken, its version of XMI is one of the cleanest and works really well with AndroMDA. It also has great support for stereotypes and tagged values, which can be extremely useful for MDA.

You should check out Omondo - www.omondo.com, it supports all 9 diagram types and XMI, integrates well with Eclipse.

Last I saw, Omondo didn't have great support for stereotypes or tagged values. If it's evolved since then, I'd be interested, since I do so much else in Eclipse.

If I might add, I must say personally I am very convinced MDA is an efficient way to reach a solid and stable architecture for your J2EE application.

Because of the nature of automation, MDA architecture tends to achieve stability faster and retain it better than ad hoc architecture. Think of the consequences of a bug in MDA or ad hoc architectures. The MDA bug might be replicated into hundreds of generated classes or it might affect the reusable runtime and necessarily have eqaully widespread devistation. A saying of the Shlaer-Mellor community was that if generative architecture leaked, then it leaked like a seive. Whereas so many bugs in ad hoc architecture mostly go unoticed and therefore unfixed. Ad hoc architecture violates the desirable implementation principle that if something is going to fail, then best that it fail soon and obviously. Quality is all about feedback.

no failures yet ;-)

by the way, maybe there are exceptions but I think most of the code generated by AndroMDA/XDoclet is verified by the application server (JBoss does that very well, did not try it with other AppServers yet), that is: errors in the deployment descriptors, inconsistencies in the interfaces, etc...

but you're right about not being to trustworthy about the generated code; you can always review it yourself after it has been generated ;-)

greetz...

Wouter

Hi Brian,

yes, a bug in an MDA template causes this bug to spread throughout the project. And: this will be noticed!

The other way round: if you fix this template bug, it is fixed throughout the whole project. This makes bug fixing easier (at least for part of the bugs...).

Cheers...
Matthias

> use AndroMDA. What is the dependency here?
>
> Is some JBoss classes used when generating? Or is it
> just that AndroMDA currently only generates the
> needed extra descriptors for JBoss?

Hi Mikael,

it means two things:

* We compile against the EJB interfaces which are inside a jar in the JBoss directory structure. You can easily change this in a properties file that we use to build our classpath.

* We generate XDoclet-tags only for JBoss. If you add Weblogic or WebSphere or whatever tags to the AndroMDA templates, you can generate for another app server.

Cheers...
Matthias

What parts of the MDA concept does AndroMDA implment? Does it only do PSM -> Code transformations or is it trying to do PIM -> Code while hiding the PSM stage? In what way is the tool different to existing code generation features of most CASE tools?

I'm dying to be able to do quality MDA transformations without forking out thousands that I can ill afford for an overblown commercial product. Keep up the good work on this tool. I have great hopes for it.

Hi Chris,

> What parts of the MDA concept does AndroMDA implment? Does it only do PSM -> Code transformations or is it trying to do PIM -> Code while hiding the PSM stage?

We are doing PIM->code, skipping the PSM stage by using additional tagged values on the model elements of the PIM. Other people call this a "marked PIM" approach.

> In what way is the tool different to existing code generation features of most CASE tools?

Most CASE tools (MDA tools are an exception!) do not use a true abstraction level, i.e. the model you feed into their code generator is not a PIM but only "one inch above the code". Watch it generate one class from one class and one method from one method. Watch AndroMDA generate a bunch of things from one class! And: you can define yourself what the word "bunch" means for your project!

> I'm dying to be able to do quality MDA transformations without forking out thousands that I can ill afford for an overblown commercial product. Keep up the good work on this tool. I have great hopes for it.

Thanks ... keep watching us, especially the new version 3.0 that we start to build!

Cheers...
Matthias

We are doing PIM->code, skipping the PSM stage by using additional tagged values on the model elements of the PIM. Other people call this a "marked PIM" approach.

That is an excellent marriage of MDA and AOP. They were made for each other.

Very nice product, which I've been using since the 2.00 alpha. A couple of issues, though:
1) The proxy thing makes it difficult to deal with model objects in your custom helper class. For example, to get an association to expose whether or not it's composite (using aggregation type), I had to edit the source and stick it into the AssociationEnd class. I couldn't get at the underlying omg object because of proxy interference, so I couldn't do the same thing (more cleanly) in my helper class. Unless I'm missing something.

2) The cartridge structure seems to have some issues with portability. A lot of things that get compiled into the cartridge descriptor are things that I'd like to change when I reuse the cartridge, meaning I think they belong in the generate task in my ant script rather than hardwired into the cartridge. For example, I may want to specify that my existing model has stereotype x, which should be mapped to what the cartridge calls stereotype y, so that I can use the cartridge to generate output without having to force my model to comply with the cartridge (in some cases this may not be possible). Another example is the overwrite attribute. The ability to turn that switch on and off makes more sense from the generate script than from the cartridge. If I want to turn it on temporarily from within a build script, I can't. I think that the "overwrite" attribute is more project specific than cartridge specific; some projects may want to always overwrite, some may want to never.

3) Some sort of package filtering thing would be nice in addition to the stereotype filtering, so that you could, for example, use outlet X on all objects in a model that match stereotype Y AND also match package or name pattern Z. Right now, if I want to focus generation on only one portion of my overall model (e.g., if I have one model that drives several web modules in an enterprise app, based on subpackage type), I can't. Not without screwing around with changing the stereotypes, which then means I need to use a different cartridge for each set of stereotypes I use (which could work if I were able to map project stereotypes to cartridge stereotypes in the generate task).

4) The output file naming process would be better if it were tied to the model, so that instead of using Java message replacement (e.g., "{0}/{1}.java"), you had access to the model properties and could use them with your transform class methods to create the output names. You could use a little velocity stack with the appropriate objects. Something like "${transform.packageToFileName($modelObject)}.${modelObject.name}.java" would be more powerful and would allow for a host of other output options (such as outputting classes to various subpackages that are similar to the class's package but under a different hierarchy: "com.myco.model.MyClass" to "com.myco.web.actions.MyClassAction").

Just my input, and I'd be more than happy to help out now that I'm familiar with the product. Can't wait to try the poseidon integration.

...

Hi Drew,

thanks for your feedback. Could you please mail this to the andromda-user list and/or file a feature request or bug report at http://sf.net/projects/andromda ?

We can deal with this and improve our product!

Cheers...
Matthias

Hi Drew,

I am one of the AndroMDA developers. Thanks for the excellent comments. They show that you have used the product a fair bit. The work on version 3.x is starting now and I think we'd be able to address all of your requirements. Just send them to the AndroMDA list where we can track them and we'll do our best.

The proxy thing in AndroMDA is a bit confusing and I can understand it causing you some grief - it has probably caused enough confusion that I should write some samples and documentation.

There should be a few ways for you to get at the underlying OMG objects via the dynamic proxies without you needing access to the AndroMDA source - in fact whenever a method is invoked on the proxy that it does not itself implement it dynamically forwards that method call onto the underlying wrapped OMG object. There are some strange situations where this has problems.

If you re-post the question on the AndroMDA user list I will try to provide a few examples and it will trigger me to write some AndroMDA documentation.

Once again, thanks for you endorsement and feedback.

Tony Mowers

No problem, I've logged some issues on sourceforge as feature requests. Thanks again for a great product.

Hello,

is AndroMDA somehow usable with Hibernate? I can imagine AndroMDA building all my persistent classes (and maybe even xml descriptors) directly from uml schema (nowadays it is me who have to do this irritating sync job..)

Tomas

Hi Tomas,

sure it is! We have a cartridge (our word for "plug-in") that generates Hibernate entities as well as stateless session facades which automatically open and close Hibernate sessions to use with the entities.

How does that sound to you?

Cheers...
Matthias