MDA with Eclipse : Acceleo 2.0.0 generates JEE applications


News: MDA with Eclipse : Acceleo 2.0.0 generates JEE applications

  1. Model Driven Engineering refers to the systematic use of models as primary engineering artifacts throughout the engineering lifecycle, the set of tools needed to apply such an approach is made of graphical modelers (UML), interoperability layers (XML/XMI imports and exports) and tools to take advantage of this models using "Model to Text" transformations. IT companies used to buy expensive proprietary solutions for these needs, thanks to the Eclipse project and some high quality free software plugins one may now have a full featured IDE with modeling support. Acceleo is one of these tools, the latest release brings open-source generator modules for many technologies (JEE, Php, CSharp, Python...) These modules are by a team of architects trying to provide state of the art code architecture using well-tried framework and best practices. The JEE generator is directly inspired by the Sun blueprints with Struts and Hibernate. Spring support is on its way and should be integrated for the next release. The Eclipse ecosystem is now providing nice open-source UML modelers such as Topcased. Using this modeler one is able to design a sofware system using Class diagrams. These diagrams may be annotated using Stereotypes in order to add semantic information. Basically two main stereotypes are used on UML classes :
    • Screen : mean this class is a screen, each association going from a screen to another meaning I'm able to navigate from this screen to this other screen.
    • Entity : mean this class is a business object that should be persisted.
    As many technologies trying to avoid strong coupling, JEE tends to be quite verbose. Using a MDA approach one can greatly improve its productivity and its software consistency generating files. As an example an Entity "Book" generates:
    • DTO
    • book.hbm.xml
    • project-ddl.sql
    • project-constraints.sql
    • hibernate.config.xml
    A "Welcome" screen will produce:
    • Welcome.jsp
    • WelcomeAction
    • WelcomeForm
    • tiles-def.xml
    • struts-config.xml
    • validator.xml
    • web.xml
    • context.xml
    • Welcome.css
    • Welcome.js
    Changing a screen, adding for instance an association to another screen, will cause the update of the struts-config.xml and associated files. Note the fact that as soon as an entity or a screen is designed and the corresponding code has been generated you're able to deploy the software on application servers. This capability is useful for quick prototyping, encouraging exchanges with the final customer. The screencasts describes the use of the module: modeling, generating, adding a new business entity and a new screen and then generating again the whole architecture without loosing the previous customizations. Other features for the JEE module are described on the JEE module official web page. This pragmatic vision is enforced by an efficient tooling: writing generation templates is made easy thanks to a simple syntax and full-featured editors (highlighting, error detections and completion). This set of tool has been validated with success on real-world projects. Acceleo is not just a template language and provides behavior to keep user code. That means once you've generated your software and you complete the source code, this so-called "user code" won't be lost when you re-generate information. Emphasizing the Eclipse integration, it provides a seamless use of the MDA approach for the developers. "Ready to use" bundles are available providing Acceleo, the set of JEE, CSharp, Php and other modules, and an UML2 modeler. Thanks to many projects Eclipse is now providing a full set of modeling tools, do you use or plan to use them? Have you tried to apply a model driven approach on any project?
  2. Any comparison between Acceleo and Andromda (
  3. Acceleo versus Andromda[ Go to top ]

    Some users comming from AndroMDA to Acceleo reported the differences between Acceleo and AndroMDA, the pros for Acceleo were the following:
    • The template syntax easier to read and maintain than velocity.
    • Full Eclipse integration ( but it seems andromda plan to provide this) with editors and generation preview.
    • Acceleo supports any kind of EMF-based metamodel, that means UML but also specific paradigm one may define, XML files using XSD. Acceleo is also able to convert models coming from the MDR world.
    • An open community for generator modules trying to provide many kind of generators : Php, JEE, Java, .Net, Python..
    Here comes the topics being pros or cons depending on people vision.
    • Incremental generation with user-code, andromda generates interfaces and abstract classes in a specific directory (target) and only update this code, the implementations are generated once in "src".
    • The vision of both tools are quite different too, Andromda use models enhanced with a lot of technical informations (using tag values and stereotypes) to customize the generation process, Acceleo's vision is about keeping models abstracts, customizing the generation trough the properties/chain files and providing technical information through the implementation completion.
    On the cons side :
    • Eclipse integration, right now Acceleo need Eclipse to run, Andromda don't. This can be a pitfall for people not using Eclipse.
    • Andromda is older and as such provides more complete catridges. For instance Spring integration is not done yet in the Acceleo JEE module.
  4. Andromda could use Acceleo ![ Go to top ]

    I think another difference is "what is the goal of the projects ?" AndroMDA want to create some packaging cartridges, with one specific methodology and some hard-coded technical choices. Acceleo is a generic engine, to create specifics generators. Acceleo has been to create to simplify this creation (to industrialise some architectural choices). AndroMDA may use Acceleo as one of its engines. Acceleo may propose some AndroMDA generators in its modules repository.
  5. Congratulations. Though I am a bit surprised you use class diagrams to describe screen navigation. Wouldn't activity diagrams be more appropriate? Are you trying to stay compatible with modellers that only produce class diagrams maybe? Still, I am personally in favour of MDA-type approaches, so I welcome your addition. Kit