Model Driven Architecture(MDA) is an approach for developing software where software artifacts are generated from elements defined in a UML model.
| [top] |
Groovy is a powerful scripting language capable of utilizing existing java libraries and has many advanced features.
| [top] |
Typically what happens is a UML model is read from a format known as XML Metadata Interchange format (XMI) and converted into an object model. The object model is then passed into templates that generate code.
| [top] |
One of the more difficult aspects of getting a new project up and running is getting the right mix of technologies in place. This also includes coming up with patterns for the core artifacts. As an example, In JPA to confirm that entities are added to both sides of a bidirectional many to many relationship, helper methods are often created that add or remove entities to both sides. This results in a lot of repetitive coding that can lead to more room for error if coded manually. This is just one example of the types of tasks that MDA can help by automating. This allows the developer to spend more time making sure the model best suits the business needs rather than repetitive coding.
MDA allows you to create a template of the known working approach and then reproduce it against a large set of model elements. The model becomes the initial idea space where you think through the business model and the templates are the technology recipe. By using MDA during the beginning of a project and tuning the templates to your needs, you greatly reduce the number of potential bugs caused by repetitive coding and you know that techniques are being applied consistently throughout your code. It has been my experience that this technique is best used when applied at the beginning of new projects. Once my initial set of model elements are generated I normally discontinue using generation. This is one approach to using this tool but it is pretty flexible and can be used differently if you prefer.
One aspect I feel is powerful with MDA is tuning the templates to your own needs. One goal of this project is to provide commonly used templates, but you may find customizing the supplied templates better suits your needs. There is a lot of potential metadata that can be exposed to your templates. This not only includes the items you see in the model but all of the elements in a uml model support capturing additional metadata in what are known as tagged values. Tagged values are arbitrary key value pairs that are stored on any model elements. You can than access these within your templates to customize the behaviour of the templates. One example of this might be deciding if an associations fetch type is eager or lazy. There are many possible uses for this.
| [top] |