imported>Colin |
imported>Andy |
| Line 1: |
Line 1: |
| − | ==Extensibility in the Rodin Database.== | + | == The Theory Plug-in == |
| − | 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 theory plug-in is used to add mathematical extensions to Rodin. The theories are created, and deployed, and can then be used in any models in the workspace. When dealing with implementation level models, such as in Tasking Event-B, we need to consider how to translate newly added types and operators into code. We have augmented the theory interface with a Translation Rules section. This enables a user to define translation rules that map Event-B formulas to code. |
| − | The new elements are then 'registered' via an extension point so that the database knows about them.
| + | === Translation Rules=== |
| − | Attributes can also be added via an extension point.
| + | Figure 1 shows the interface, and some translations rules of the mapping to Ada. |
| − | 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.
| + | <div id="fig:Translation Rules"> |
| | + | <br/> |
| | + | [[Image:TheoryCGRules.png|center||caption text]] |
| | + | <center>'''Figure 1''': Translation Rules</center> |
| | + | <br/> |
| | + | </div> |
| | | | |
| − | 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.
| + | The translation rules are templates used for pattern matching. The meta-variables are defined and typed, and used in the rules. Event-B expressions and predicates are defined on the left hand side of the rule, and the code to be output (as text) appears on the right hand side of the matching rule. |
| − | | |
| − | ==Extensibility of the EMF framework for Event-B==
| |
| − | However, extensibility in EMF is currently being investigated.
| |
| − | | |
| − | 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 was investigated.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 added programmatically by dynamically extending the core package with a containment to attach the extension meta-model. All Extension plug-ins should also look for relevant extensions of themselves in a similar way. This would be a 'clean' way to extend meta-models because it does not introduce artefacts into the model. However, the investigation discovered that statically generated meta-classes cannot be dynamically extended in any way.
| |
| − | A variation on this method was tried using Feature maps. Feature Maps define a core containment of type FeatureMap. derived volatile transient containments can then be defined based on this core containment. (note that Feature maps provide a similar model structure to the Rodin database). It was hoped that the derived containments could be added dynamically but it appears that they have no effect if added dynamically since they rely on generated methods that provide filtering wrappers on the core collection.
| |
| − | This method has now been abandoned.
| |
| − | | |
| − | The existing mechanism built into the Event-B EMF framework (containment of extensions) appears to be the only viable mechanism for achieving a retrospective and co-existing set of extensions. To avoid the problems outlined above it is proposed to add a ''configuration'' attribute '''ParentTypes''' to the meta-class, '''Extension'''. Extenders will populate this unmodifiable attribute with a collection of type EClass which defines the allowed types of the parents of this extension. Note that there may be several different kinds of allowed parents. Also, the given EClass could be a super-type of several kinds of parent.
| |
| − | | |
| − | ==Extending the Presentation==
| |
| − | The Rodin platform already provides an extension point for defining presentation of model elements and attributes. This extension point however, links information to Rodin elements. We require the same information linked to EMF model elements. Of course, EMF elements are synchronised with rodin elements, but this is only updated at save time. Several options exist:
| |
| − | | |
| − | * Replicate the current extension point but linking to EMF models.
| |
| − | * Use the existing Rodin extension point mapping to the EMF element via its dynamic synchronisation with rodin elements. It would be necessary to tighten the synchronisation between EMF and Rodin elements so that they are kept in step at all times (see discussion below).
| |
| − | * Use the existing Rodin extension point mapping to the EMF element via a static type mapping with rodin elements.
| |
| − | * Modify the existing Rodin extension to optionally specify an EMF element type in addition to the Rodin element type.
| |
| − | | |
| − | Question: does the existing Rodin extension point handle multiple collections of the same element type?
| |
| − | | |
| − | ==Tighter Synchronisation==
| |
| − | TBD
| |
| − | | |
| − | ==Instructions for creating an extension==
| |
| − | <still under investigation>
| |
| − | | |
| − | * Design an EMF meta model (ecore) of your extension's abstract syntax. The model should include one or more root elements that Extend the '''Extension''' metaclass. These root elements must define the meta-classes of the meta-classes that they extend. They should also define containers that are to be added to the extended parents.
| |
| − | * Load and configure the gen model (this should be set for extensible providers)
| |
| − | * Generate the code and edit code
| |
| − | * Customise the content provider for the root element(s) to bypass the root node and return its containers directly
| |
| − | * Add extensions to declare new kinds of Rodin elements and attributes
| |
| − | * Write Java interfaces and classes for each new Rodin element
| |
| − | * Add extensions to declare synchronisers to persist your new meta-classes into Rodin elements.
| |
| − | * Write Java classes for each synchroniser
| |
| − | * Extend the Rodin Navigator and Rodin Editor to match the new model structure in EMF
| |
| − | * Extend the static checker etc as necessary
| |
| − | | |
| − | ==Ideas that didn't work==
| |
| − | | |
| − | [[DynamicContainer|Some notes on an attempt to dynamically add a container to the existing meta-class]]
| |
The Theory Plug-in
The theory plug-in is used to add mathematical extensions to Rodin. The theories are created, and deployed, and can then be used in any models in the workspace. When dealing with implementation level models, such as in Tasking Event-B, we need to consider how to translate newly added types and operators into code. We have augmented the theory interface with a Translation Rules section. This enables a user to define translation rules that map Event-B formulas to code.
Translation Rules
Figure 1 shows the interface, and some translations rules of the mapping to Ada.
Figure 1: Translation Rules
The translation rules are templates used for pattern matching. The meta-variables are defined and typed, and used in the rules. Event-B expressions and predicates are defined on the left hand side of the rule, and the code to be output (as text) appears on the right hand side of the matching rule.
