Cédric Brun bio photo

Cédric Brun

Build open-source technologies to enable mission critical tools for complex domains.

Email Twitter LinkedIn Github Youtube

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
Derived features are fast, straightforward, or externalized
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