Compared to languages such as ATL, VIATRA, Kermeta, TEFKAT and frameworks such as openArchitectureWare and AndroMDA, Epsilon is a relatively young approach to MDD. This often raises the following (quite reasonable) questions:
- what is the aim of Epsilon in the MDD landscape?
- why wasn’t it built atop an existing framework?
The aim of Epsilon
Our aim with Epsilon is dual:
- to provide languages for tasks that are currently unsupported by other languages/tools
- to investigate novel/interesting ideas in model management tasks (e.g. M2M, M2T, model validation) that are already supported
(To put this into context, we are talking about languages that support contemporary object-oriented models specified using mainstream modelling technologies such as EMF and MDR.)
The first aim has been achieved. Epsilon provides languages for tasks such as model merging (EML) and model comparison (ECL) that were – at least to the best of our knowledge – previously unsupported.
The second aim has also been (partly) achieved.
- EVL is the only constraint language – again to the best of our knowledge – that supports concepts such as dependent constraints, user interaction and the ability to define inconsistency-repairing behaviour (fixes).
- Although some work based on graph transformations has been done in the context of in-place model transformations, EWL is unique in providing a powerful concrete textual-syntax and supporting features such as user-interaction, and undoing-redoing the effects of wizards on the edited models (see flash demo)
We are constantly working towards improving the Epsilon languages and enhancing them with new interesting features but also keep an eye open for new tasks that could benefit from a task-specific language…