Metamodel (Ecore) Design Checklist

Posted on in Blog

This is an index page for the Metamodel (Ecore) Design Checklist serie, a condensed version listing all the rules of the article (part1 and part2) for your convenience.

I compiled the following checklist based on my personal experience, this is not exhaustive and I expect it to live and get richer over time.

Most of the checks stated here are very easy to comply with when considered from the start. When it’s later down the road the gain/risk ratio should be evaluated as some changes might need to update some code, some files or might just be too much work to be worth it then. Because of this and because we sometime learned the hard way you might quite easily find some Ecore models I authored which are not 100% compliant with this list ;).

By the way, feel free to tell me about your own rules, I might add it to the list!

Ground rules

The purpose and audience of the models are stated ☑
The nsURI is the definitive one and is consistent with your naming conventions. ☑
Nested EPackages are not used. ☑
Names are real ones, precise and consistent. ☑
Reference and attribute names are consistent. ☑
All the non-abstract EClasses are supposed to be instanciated. ☑
0..1 and 1..1 cardinalities have been reviewed. ☑
Containment relationships have been reviewed. ☑
Every validation rule which is not enforced by the Ecore model structure itself is named. ☑
The concepts are all documented. ☑
There are no Boolean monsters in the making ☑

Outside world

I decided how instances should be referenced from the outside ☑
A user can’t introduce cyclic references in between model fragments ☑
The dependencies in between EPackages are in control ☑
The concepts which might be extended by subtypes are clearly identified ☑

Scalability

Instances which will be present a lot in the models have a concise serialization ☑
Everything which is serialized needs to be serialized ☑
There is no EClass which could be replaced by an EDatatype ☑
The model has some structure ☑
It is possible to load part of the model without loading everything ☑
The implementation classes are using MinimalEObjectImpl ☑

Java

Multiple inheritance is not over-used ☑
Custom DataType are used in every situation where it makes sense ☑
The .genmodel output folders are specified or made empty ☑
The .genmodel base package is specified ☑

Metamodel (Ecore) Design Checklist was originally published by Cédric Brun at CTO @ Obeo on May 10, 2016.

Auteur d'origine: Cédric Brun