EMF Best Practices

EMF is cool thing and when working with eclipse and java one should realy give EMF a try. This is advice I gave many times to other software developers. The response I got was often something like "EMF is way to complex", "the threshold is simply to high" "I'll better create my models in handcrafted code". Therefor I decided to write down best practices I developed over the years using EMF and which might help to lower the threshold for using EMF. I want to cover the following topics, which I think are key factors for successfully using EMF.

Working with Model Instances - EMF does not only provide modeling and code generation facilities, but as well powerful runtime support for manipulating model instances. Runtime support builds upon the reflective nature of EMF models and on generated metadata facilities such as model specific factory (EFactory) and metadata holder (EPackage) implementations. When starting to work with EMF and not knowing about this support, one will treat model instances as any other object structure and use home made patterns to access and manipulate your models. This best practice introduces a minimum set of very useful framework features and starting points developers should know about.

Adapt default templates - In this best practices I explain when and how to best adapt EMF’s default code generation facilities. The goal of this best practise is to motivate developers to get in control of their code generation process. Knowing how the code generation process works and if needed, where to start to make changes, is a big step towards extensive model driven development.

Mark model features as derived - When creating a domain model one may face the problem that values and state of model attributes may depend on other attribute values and that changes to one attribute must instantly trigger updates of dependent model valuei. A simple modeling technique is to mark model features which depend on others as derived. This can be achieved through marking an attribute or reference in your model editor as derived. Subse EStructuralFeatures as derived. flag on helps to represent this domain logic on model and implementation level by marking model features as derived. However setting the derived flag in your ecore editor leaves the generated code uneffected (an exception is the metadata initialization). This comes because the value of derived is somehow "derived" itself. Derived features are typically marked as volatile, transient and non-changeable. This leads to code which omitts feature serialization (transient), member variables and getter implementation (volatile) and declaration of setters (non-changeable).

Models change so you better be prepared - At some point a domain model will change. Be it due to deeper domain insight, the rise of new requirements or even technical issues such as performance optimization. As long as your model lives within a protected development environment even big changes are of no problem but as soon as you release, even minor changes can become real problem. Meta-Model and model instance evolution are a hot topic and various approaches such as cope or epatch provide assistance. A simple but yet very imported thing to do is to start to version your models. This can be achived through verious ways. I simple use a version number within a models package URI. So use something like http://at.somecompany/4/somemodel.ecore.

Hopefully to be continued....