EMF framework for Event-B/Extensibility Issues
Extensibility in the Rodin Database.
The Rodin database can be extended with new element types by creating new Java classes that follow the pattern of the Event-B ones. This relies on the programmer creating the Java correctly. The new elements are then 'registered' via an extension point so that the database knows about them. Attributes can also be added via an extension point. The database is minimally structured with all elements contained in a 'children' collection. Methods are then provided to simulate a structure by returning all child elements of a particular kind. (note that this has the limitation that it is not possible to have two different collections which contain the same kind of element)
This approach has the advantage that it can be extended in any way (apart from the limitation noted above). However it is a very implementation-oriented view. That is, it would be nicer if extenders could work at a more model-oriented level and not have to understand (and get right) details about the coding of the database.
EMF provides a more model oriented approach by allowing the extender to create a declarative abstract syntax (a meta-model) from which code is automatically generated. It is often necessary to 'tweak' the code with customisations but the situation is greatly improved.
Extensibility of the EMF framework for Event-B
However, extensibility in EMF appears to be a problem:
It is possible to extend models by subclassing their elements and, for example, adding new attributes and collections to this subclass. However, this does not work retrospectively for previously created models. Also, extensions are effectively disjoint since an element cannot simultaneously be an instance of two or more subclasses.
When the Event-B EMF framework was created, we added a meta-class, 'Extension' and a collection, 'extensions' to the base element. The idea was that extenders could subclass this Extension class and thereby add new model features anywhere. This works, but is not very satisfactory for two reasons. Firstly it introduces an unnatural intermediate modelling artefact because the Extension element should really be the same element as its parent. Secondly, once an extension is defined there is no way of limiting who can own it. This means that the extension can be added to every kind of element in the rest of the model including all the new elements in the extension.
Another approach is now under investigation. This is to define the new meta-model including all new element kinds but omitting the containment that attaches it to the existing meta-model. This containment is then defined in an extension point, giving the allowed type of the owner and some EMF details about the properties of the EReference (multiplicity etc.). The core model package will then (via some additional custom code) read all extensions of this extension point and, if any have parent elements in the core package, dynamically extend the core package with a containment to attach the extension meta-model.
