Introducing AndroMDA 4.0

AndroMDA 4.0 (or as we call it: "A4") is a complete rewrite of the well-known model-driven development framework AndroMDA. It has become a very light-weight framework so that users can choose which components they want to use.

A4 has a completely new plugin architecture so that architects can write their own plugins to contribute own metamodels, model-to-model transformations, or model-to-text transformations.

A4 has a configurable workflow engine that can invoke the components inside the plugins to orchestrate the whole process of transformation and code generation.

Main advantages compared to A3

Create and use metamodels for your own DSLs

It is now easy to create and use your own metamodels. Create them using the EMF Ecore editor, the Eclipse GMF plugin or your favorite UML 2.0 tool and the A4 UML2-to-Ecore converter plugin. Contribute your metamodels inside your own plugin; AndroMDA will recognize them and be able to load arbitrary models, based on your metamodels. A3 was very much UML-oriented; there are domains that UML cannot describe very well (e.g. GUIs). For these domains, use your own DSLs (domain specific languages) to model your intentions.

Transform models in small, understandable steps

A4 can invoke multiple transformations from PIM via a set of intermediate PSMs to the final PSM from where it generates the source code. A3 had only a two-step process (first PIM-to-PSM, then PSM-to-code). These steps were sometimes too big.

A4 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

Both languages are supersets of a subset of OCL (the standardized object constraint language). They are supported by Eclipse editor plugins with syntax highlighting and metamodel-aware code completion (at least for MOFScript).

Connect your transformations like a graph. Each transformation can have m input models and n output models.

Maintain your transformation rules easily

Write transformations only once and re-use them in different contexts. For example: In A4, there is only one place where getters and setters are generated: in the final model-to-text transformation inside the Java cartridge. End of the maintenance nightmare. Period.