Various Eclipse Modeling technologies are trying to empower domain experts in the creation of specific tools. Using EcoreTools and Sirius a domain expert can define languages, graphical modelers and editors without writing a single line of Java code or launching a new Eclipse runtime. However, when come the time to add behaviors to the language structure (e.g., to implement interpreters, compilers, static analysis, refactoring, or generators), the domain expert has to face all the complexity of Eclipse Plugin development, OSGi, Java and much more.
The Model-Driven Design approach is centered on the use of a model repository and a modelling tool. A drawback of the approach is that the evolution of derived artefacts (such as documents, code tests) requires to go back to the model. This process involves tracing the source element back in the model editor before triggering the update of the artefact. This can reveal quite inefficient and even causing user rejection.
Our talk presents a reusable mechanism matured over 5 years in model-based tooling (actually for requirements engineering) and deployed in international companie.
Working on evolving EMF Metamodels?
Testing your business rules?
You surely need easy-to-evolve instances of your metamodel!
In classic approaches, you either had the choice of creating static model instances, which are difficult to maintain, or to use the EMF API (hopefully with some custom helpers) to create compiling models, which are hardly understandable and a real reference nightmare.
Tons of outdated resources or boilerplate code to fix, on a simple metamodel modification, don’t let your tests bring you down.
BOEM will make your day.