AndroMDA 3.0M1 milestone release is out!


News: AndroMDA 3.0M1 milestone release is out!

  1. 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 AndroMDA development team is proud to announce the release 3.0M1 of the code generation framework. It is the first milestone release towards V3.0 and supports really exciting new features:

    * New cartridge "bpm4struts" (business process modeling for Struts) - generates a complete web based application from UML Use Cases und activity graphs.
    * New sample app "AnimalQuiz": Let the computer automatically guess an animal that you have in mind! The game uses Hibernate and Struts and is entirely generated from UML activity graphs.
    * New EJB cartridge supports abstract inheritance of entities.
    * New Hibernate cartridge supports true subclassing of Hibernate objects.
    * New "Meta" cartridge supports cartridge developers by generating your own metamodel API extension objects (we call them "metafacades"). Template writing becomes a snap, based on an API of smart objects!
    * Support for "segmented models" - models that are composed of more than one XMI file. Allows multi-user modeling and code generation - no more conflicts accessing the model in a team environment.
    * Model validation at code generation time.
    * Plug-ins for different metamodels (today, plug-in for UML 1.4 ships, the next one will support UML 1.3 for Rational Rose and ArgoUML, UML 2.0 will be supported as soon as the OMG releases it).
    * Plug-in for both Maven and Ant.

    If you want to know more, read or come to the JAX 2004 conference for Java/Apache/XML technologies in Frankfurt/Germany to learn about how AndroMDA was used at Lufthansa and about its new features in 3.0! The session will take place on Thursday, May 13, 2004.

    Please forgive us - the documentation is not yet complete for this first milestone release. We support the package on the andromda-user mailing list and will try to compensate for this - promised! :-) You can download the new package at .

    Matthias Bohlen
    AndroMDA lead architect

    Threaded Messages (15)

  2. Great stuff![ Go to top ]

    Hi Matthias, and AndroMDA team,

    congrats for the new release! If we had used AndroMDA, we wouldn't care about those persistance services (EJB, Hibernate, JDO, ...), which have been much discussed here in TSS... ;-)

    Anyway, AndroMDA 2.x is a pleasure to use. I myself have succeeded creating my own "customized" templates for the EJOSA structure (specification, business, presentation). I also implemented a template for Enhydra Presentation Object. In the meantime I also checked-in the code for transforming "language x" to "language y". With this "cartridge" it is just very simple to use one source UML model (XMI), which can be translated in many other languages using tagvalue "@language.y" (from x=English to y=German for example).

    I plan to release the new version of EJOSA (which contains AndroMDA on the top now ;-)) in coming week.

  3. In reverse?[ Go to top ]

    Congratulations on the milestone release ;)

    I haven't used this product in the past, but I'm curious: will it stay in sync with code modifications? Let's say I do a model in Rose, bring it into AndroMDA, and generate code from it. Then I modify the generated code by hand. Can I bring it back into AndroMDA to update its model?
  4. In reverse?[ Go to top ]


    Incremental development and regeneration cycles are supported by AndroMDA

    For classes this is not a problem, abstract parent classes are regenerated, the child classes are only generated when they do not yet exist, so you will put your custom code in there and you are sure it will stay there, worst case you'll have compilation errors when building your project

    Jsps, properties files, etc... are a different story because the notion of extending one another does not exist. Tackling this problem is not so easy as with classes. Anyway, it is partially supported. For the Bpm4Struts cartridge JSPs will be using Tiles to separate as much as possible those parts that need update and those that don't need update. The cartridge also generates CSS stylesheets, i18n properties files, etc.. subsequently making it easier to identify which files would need manual update

    what most users will do anyway is fine-tune the templates to their needs, they are quite easy to read and are written in Velocity (any other template-engine can easily be supported), and in doing so the generated files will be customized to your very needs.

    The purpose of AndroMDA is not to generate your complete application with the click of a button, maybe that will be possible in the future :-) but not yet for now. If you are tired writing the same code all the time, updating XDoclet tags, etc... and you want to keep focus on the business, AndroMDA is for you.

    For users not familiar with AndroMDA, here's an approximation of the percentage of code generated:

    Persistence (EJB/Hibernate): 100%
    Business (EJB): 30%
    Presentation (Struts): 80%

    The presentation layer is taken care of.
    The business layer needs an implementation since this is (or at least should be) unique for each different application.
    The presentation will also run out-of-the-box but you'll still need to wire it to the business layer. The web application can be deployed and run without it though, be it with a 'dummy' implementation behind.

    Since each layer is cleanly separated each one of them can be developed and tested independently before linking them together.

    good luck

    -- Wouter.

    ps: we could still use a couple of cartridge developers, for example for DAOs, WebWork, Spring, XSD, just to name a few... get in touch via the mailing list if you're interested.
  5. Presentation layer[ Go to top ]

    Hi Wouter,

    I would like to ask you something. I could ask this in AndroMDA list but I think this could be a good thing to discuss in broader spectrum ;-)

    You have a lot of experiences building the Bpm4Struts "Animal Quiz Application". I always follow the things you've done there, really nice. I see that in business and persistance layer it is really a good thing to use code generation, no doubt. But now I'm not sure whether it is always a good idea to use UML to model the "flow" of your presentation layer (activity diagram or state diagram):

    - If you use JSP, TagLibs, yes it could be worth it to use the UML modelling as you cannot directly "run" the JSP pages as they are within the web browser (especially if you put Java codes in your JSP files ;-)). You always need to run the web container to see the flow, etc.
    - But if you use XMLC (you just put "id" on the part you want to change in the runtime), you can have the flow, look&feel, sample data, etc. directly without needing to run the web container. So you just build the HTML files, add the flow directly as they would work within the web container. You can directly show the "story board" to your customer without any implementation and any web container, just use web browser ;-) Very easy. In this case it's not worth it, IMO, to use the flow modelling (activity diagram) in UML, as the story board would be a lot more easier to understand for the customer.

    I agree that the class diagram (structure) is always good to use, also for the presentation layer, as we can model the structure of the servlet part. But this would be already the PSM and not PIM anymore.

  6. Re: Presentation layer[ Go to top ]

    hi Lofi,
    I could ask this in AndroMDA list but I think this could be a good thing to discuss in broader spectrum ;-)
    Note: don't worry, I'll put your question in the FAQ.

    I remember the post about XMLC some time ago, but unfortunately I don't have too much time these days to check out projects as much as I would like.

    I created the bpm4struts cartridge for AndroMDA out of a general discomfort with working with JSP/Servlets or even Struts directly. The problem was that I would find myself spending too much time on details related to the underlying technology, rather than on the core business of the application.

    More concretely:

    1. client-side/server-side input validation
    Changing the type of a field, or adding a new one, would require me to update code at several locations. Granted, XDoclet can solve this problem.

    2. exception handling
    It's a known problem, and I was not unaffected by it neither. Exceptions are underestimated and therefore mostly added too late, which can be hard to do. I would like to have a default behavior in pages: "whenever something goes wrong, go back the previous page and display the error message". If you change the page flow often you'll find yourself updating struts-config.xml all the times.

    3. page flow transition (actions <--> pages)
    Error prone, although struts-config.xml is pretty clear and straightforward it is too easy to make a mistake. Repositioning transitions can be a nightmare if your pages rely on the parameters in your requests etc... you get the picture. Before you know it people are starting to put stuff in the 'session' (UGH).

    4. security
    I wanted a way to bundle resources together in web.xml, but I am too lazy to keep updating that file all the time.

    5. I18N Resources
    Or you lock your application into a single language, or you take the time to use the i18n features available. But in doing so you'll need to maintain a bundle for each language, wouldn't it be nice if the file would be created for you (at least in one language) ?

    ... I guess there is more, but you get the picture ...

    anyway, I chose Struts as a presentation layer, so subsequently I wrote an AndroMDA cartridge for Struts. There's no magic involved, the cartridge only takes over those tasks that are too boring and I was too lazy to do myself, this allows me to keep focus on what the application should be doing, not on how it should be doing it.

    If I understand correctly you build static pages using XMLC, for a POC. This is perhaps very interesting for short demos and presentations, but it is not the target of bpm4struts, as you briefly pointed out. I aimed for stable and production-ready dynamic web pages, I hope there will be enough users to give it a try, that way I am sure we'll get there eventually.

    Mind you, with QvT coming (soon?) we would have a standardized way of modeling our tiers, this would allow to generate different presentation layers using a single UML model. For now you would simply need to write a cartridge for WebWork/Swing/.Net/... and you could generate your code for that specific technology - still from the same UML.

    With bpm4struts you do not model for a specific technology, it is just that the cartridge outputs Struts code. You could easily share the model with a bpm4swing cartridge and have it generate Java Swing code.

    And you're right of course, everything has its own domain on which it is applicable, I am sure other technologies such as XMLC are better suited for specific tasks.

    best regards
    -- Wouter.
  7. Re: Presentation layer[ Go to top ]

    Hi Wouter,

    thank you for your explanation!

    The point is actually I really want to reuse your style (BPM4Struts) to implement the XMLC and Enhydra PO technology ;-) So it would be possible to exchange the templates and voila you have another implementation. But as you said this will be a lot more easier if we already have the QVT... Anyway, I follow your style to implement the XMLC and Enhydra PO (not yet all, but already a lot of ;-)).

    Mind you, with QvT coming (soon?) we would have a standardized way of modeling our tiers, this would allow to generate different presentation layers using a single UML model. For now you would simply need to write a cartridge for WebWork/Swing/.Net/... and you could generate your code for that specific technology - still from the same UML.

    This would be really great. With the transformation QVT we can really make PIM (instead of PSM) and transform it into PSM. IMO, the real value of MDA is the PIM as this will be the artifact to be communicated between developers and customers (domain engineering).

  8. Re: Presentation layer[ Go to top ]

    Mind you, with QvT coming (soon?) we would have a standardized way of modeling our tiers, this would allow to generate different presentation layers using a single UML model.
    For the first time in the history of computer science, project is a verb.
  9. In reverse?[ Go to top ]

    I just read the original question again. I misunderstood you the first time.

    You are asking whether or not changes in the code will be reflected back into the UML model. The answer is no. The generation is unidirectional from UML to <code>.

    -- Wouter
  10. In reverse?[ Go to top ]

    'Protected Areas' means that code written by the users are not touched by code generation. Isn't it ? Now if code cannot be reverse-engineered then that means reverse-engineering is not supported ?
  11. In reverse?[ Go to top ]

    that is correct, it has never been the purpose of AndroMDA to update the XMI files by rereading the generated sources

    don't forget that AndroMDA could output anything you like, it is /not/ restricted to Java, eg. you could have a cartridge writing a PDF report from your UML model. so reverse engineering would also mean you could apply changes in your PDF and this will update the UML model

    on the other hand, if someone feels creative he/she can always propose something on the mailing list

    Why would you like to reverse-engineer ? I have been using AndroMDA on 4 projects now and I never felt it needed to reverse-engineering anything. IMO the reason is that very elegantly the developer only needs to keep focus on the business part, everything around it (entity relationships, jsp/servlet process flow) is generated .

    A possible reason you ask the question might be that you want to know whether or not it is possible to introduce your existing project into AndroMDA and have the UML model writing for you? As I said, generation is uni-directional.


    -- Wouter
  12. In reverse?[ Go to top ]

    Hello wouter.
    Consider i have Modeled One Session Bean Service : HelloService
    It has only one Service say : public void sayHello();
    i model[using androMda] and generate the code.
    After few days i update the UML model to include a new service :
    say : public string echo(String message);
    I try to generate the code..what will happen now??
    will my earlier implementation lost?or Andro will merge it with the newly generated code??
  13. In reverse?[ Go to top ]

    AndroMDA suggests you to use inheritance to "protect" your own code and this works actually very good!

    In your example it will look like this:
    - AndroMDA generates HelloServiceAbstract (abstract class) which has an abstract method public void sayHello();
    - What you need is to extend this abstract class in your own class, something like HelloServiceBean extend HelloServiceAbstract...

    So if you add a new method "public string echo(String message)" in your UML diagramm you'll get a new generated abstract class:

    public class abstract HelloServiceAbstract .... with both methods
      public abstract void sayHello();
      public abstract String echo(String message);

    What you need to do is to extend your own implementation like:

    public class HelloServiceBean extend HelloServiceAbstract
      public void sayHello() {
        your implementation...
      public String echo(String message) {
        your implementation...

    That's it! Remember, that before you add an implementation method of the echo method, your Java compiler will throw an error...

    Using inheritance in MDA is quite nice as you don't need to take care of those "protected areas". Using inheritance is also better to let you separate the codes which are generated (normally this type of codes should never been saved in CVS) and the codes which you need to implement (this codes should be saved in the CVS repository).

    Hope this helps,
  14. Additional comment[ Go to top ]

    This is also a very good thing if you use IDE such as Eclipse which supports compiling in the background, good support of code writting as it would add the unimplemented method for you automatically and tells you whether there is an error...

    IMO, never think that model-driven and sourcecode-oriented are two enemies. No, they are friends and they work both on the sametime smoothly.

  15. In reverse?[ Go to top ]

    Consider i have Modeled One Session Bean Service : HelloServiceIt has only one Service say : public void sayHello();i model[using androMda] and generate the code.After few days i update the UML model to include a new service :say : public string echo(String message);I try to generate the code..what will happen now??will my earlier implementation lost?or Andro will merge it with the newly generated code??thnx..
    what Lofi replied is correct, there is no merging of code .. we keep generated code strictly separated from manual written code (although a skeleton for the manual code is generated the first time), inheritance provides an elegant way of dealing with this separation.

    you will not lose your code when regenerating, don't worry

    -- Wouter
  16. EXCELLENT![ Go to top ]

    Hello AndroMDA TEAM.
    Excellent work.its really kewl!!!