EMF framework for Event-B/Extensibility Issues - Revision history

imported>Colin: /* Extensibility of the EMF framework for Event-B */

2010-01-22T10:50:58Z

Extensibility of the EMF framework for Event-B

← Older revision		Revision as of 10:50, 22 January 2010
Line 21:		Line 21:
	This method has now been abandoned.		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.		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'' EAnnotation '''org.eventb.emf.core.extendedMetaClasses''' to the meta-class that wishes to contribute new features to an existing one. This annotation will be recognised by the persistence plug-in and by any UI code. Instances of the intermediate meta-class with this annotation will be automatically generated by the persistence and added to the relevant parent(s) at load time. The intermediate classes will be hidden from view by any UI facilities. Extenders will populate the references of this EAnnotation with the EClass(es) which are allowed to be 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.

			The Annotation can be omitted in which case the meta-class will be treated as a child element which is contained in the extensions collection of all EventBObjects.

	==Extending the Presentation==		==Extending the Presentation==

imported>Colin: /* Extensibility of the EMF framework for Event-B */

2009-12-02T15:07:36Z

Extensibility of the EMF framework for Event-B

← Older revision		Revision as of 15:07, 2 December 2009
Line 17:		Line 17:
	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.		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. This method has now been abandoned.		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.		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.

imported>Colin: /* Some Notes on extensibility related to EMF framework. */

2009-11-25T15:21:10Z

Some Notes on extensibility related to EMF framework.

← Older revision		Revision as of 15:21, 25 November 2009
Line 1:		Line 1:
	~~==Some Notes on extensibility related to EMF framework.==~~		==Extensibility in the Rodin Database.==

	===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 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.		The new elements are then 'registered' via an extension point so that the database knows about them.
Line 12:		Line 10:
	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.		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.

	===Extensibility of the EMF framework for Event-B===		==Extensibility of the EMF framework for Event-B==
	However, extensibility in EMF is currently being investigated.		However, extensibility in EMF is currently being investigated.

Line 23:		Line 21:
	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.		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 Presentation===		==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:		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:

Line 33:		Line 31:
	Question: does the existing Rodin extension point handle multiple collections of the same element type?		Question: does the existing Rodin extension point handle multiple collections of the same element type?

	===Tighter Synchronisation===		==Tighter Synchronisation==
	TBD		TBD

imported>Colin: /* Instructions for creating an extension */

2009-11-25T15:12:45Z

Instructions for creating an extension

← Older revision		Revision as of 15:12, 25 November 2009
Line 37:		Line 37:

	==Instructions for creating an extension==		==Instructions for creating an extension==
			<still under investigation>

	* Design an EMF meta model (ecore) of your extension's abstract syntax. The model should ~~NOT deal with ownership of~~ the ~~extension (i.e~~. ~~where~~ the ~~extension is contained in~~ the ~~existing~~ meta-~~models)~~		* 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) ~~<still under investigation since extending provider would be the container which is defined dynamically now>~~		* Load and configure the gen model (this should be set for extensible providers)
	* Generate the code and edit code		* Generate the code and edit code
	* Customise the ~~package initialiser with~~ the ~~code shown below to make your package extensible~~		* Customise the content provider for the root element(s) to bypass the root node and return its containers directly
	* Add an extension to define the containment of the extension (~~the containment will be added dynamically~~ to the ~~meta-model being extended)~~
	* Add extensions to declare new kinds of Rodin elements and attributes		* Add extensions to declare new kinds of Rodin elements and attributes
	* Write Java interfaces and classes for each new Rodin element		* Write Java interfaces and classes for each new Rodin element
	* Add extensions to declare synchronisers to persist your new meta-classes into Rodin elements.		* Add extensions to declare synchronisers to persist your new meta-classes into Rodin elements.
	* Write Java classes for each synchroniser		* 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==		==Ideas that didn't work==

	[[DynamicContainer\|Some notes on an attempt to dynamically add a container to the existing meta-class]]		[[DynamicContainer\|Some notes on an attempt to dynamically add a container to the existing meta-class]]

imported>Colin: /* Extensibility of the EMF framework for Event-B */

2009-11-25T15:04:05Z

Extensibility of the EMF framework for Event-B

← Older revision		Revision as of 15:04, 25 November 2009
Line 21:		Line 21:
	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. This method has now been abandoned.		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. 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		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 Presentation===		===Extending Presentation===

imported>Colin: /* Extensibility in the Rodin Database. */

2009-11-25T15:00:39Z

Extensibility in the Rodin Database.

← Older revision		Revision as of 15:00, 25 November 2009
Line 10:		Line 10:
	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.		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~~.		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.

	===Extensibility of the EMF framework for Event-B===		===Extensibility of the EMF framework for Event-B===

imported>Colin: /* Extensibility of the EMF framework for Event-B */

2009-11-25T13:01:06Z

Extensibility of the EMF framework for Event-B

← Older revision		Revision as of 13:01, 25 November 2009
Line 19:		Line 19:
	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.		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~~.		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. This method has now been abandoned.
	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. All Extension plug-ins should also look for relevant extensions of themselves in a similar way.
			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

	===Extending Presentation===		===Extending Presentation===

imported>Colin: /* Instructions for creating an extension */

2009-11-25T12:01:46Z

Instructions for creating an extension

← Older revision		Revision as of 12:01, 25 November 2009
Line 35:		Line 35:
	TBD		TBD

	===Instructions for creating an extension===		==Instructions for creating an extension==

	* Design an EMF meta model (ecore) of your extension's abstract syntax. The model should NOT deal with ownership of the extension (i.e. where the extension is contained in the existing meta-models)		* Design an EMF meta model (ecore) of your extension's abstract syntax. The model should NOT deal with ownership of the extension (i.e. where the extension is contained in the existing meta-models)
Line 46:		Line 46:
	* Add extensions to declare synchronisers to persist your new meta-classes into Rodin elements.		* Add extensions to declare synchronisers to persist your new meta-classes into Rodin elements.
	* Write Java classes for each synchroniser		* Write Java classes for each synchroniser


			==Ideas that didn't work==

	[[DynamicContainer\|Some notes on an attempt to dynamically add a container to the existing meta-class]]		[[DynamicContainer\|Some notes on an attempt to dynamically add a container to the existing meta-class]]

imported>Colin: /* Some Notes on extensibility related to EMF framework. */

2009-11-25T11:59:05Z

Some Notes on extensibility related to EMF framework.

← Older revision		Revision as of 11:59, 25 November 2009
Line 47:		Line 47:
	* Write Java classes for each synchroniser		* Write Java classes for each synchroniser

			[[DynamicContainer\|Some notes on an attempt to dynamically add a container to the existing meta-class]]

	~~'''example code~~ to ~~make~~ a ~~package extensible'''~~
	~~(the example is for the core package... core package should be changed~~ to the ~~name of your package)~~

	~~public static CorePackage init() {~~
	~~........~~
	~~//Link in any extensions~~
	~~getExtensions(theCorePackage,theMachinePackage,theContextPackage);~~

	~~// Mark~~ meta-~~data to indicate it can't be changed~~
	~~theCorePackage.freeze();~~

	~~return theCorePackage;~~
	}

	/**
	* Method to get all extensions from extension registry.
	* Extensions can link additional EMF model content to this core model by defining a new EReference
	* (usually a containment) which holds instances of a new metaclass.
	*
	* @custom
	*/
	~~private static final String extensionId = "org.eventb.emf.core.metamodel_extension";~~

	~~private static void getExtensions(EPackage theCorePackage,EPackage theMachinePackage,EPackage theContextPackage) {~~
	~~IExtensionRegistry extensionRegistry = Platform.getExtensionRegistry();~~
	~~IExtensionPoint extensionPoint = extensionRegistry.getExtensionPoint(extensionId);~~
	~~org.eclipse.core.runtime.IExtension[~~] ~~extensions = extensionPoint.getExtensions();~~

	~~for (org.eclipse.core.runtime.IExtension extension : extensions) {~~
	~~try {~~
	~~EPackage extenderPackage = null;~~
	~~IConfigurationElement [~~] ~~elements = extension.getConfigurationElements();~~
	~~for (IConfigurationElement element : elements) {~~
	~~if ("ePackage".equals(element.getName())){~~
	~~//String packageName = element.getAttribute("name");~~
	~~Registry packageRegistry = EPackage.Registry.INSTANCE;~~
	~~String extender_eNS_URI = element.getAttribute("eNS_URI");~~
	~~extenderPackage = packageRegistry.getEPackage(extender_eNS_URI);~~
	}
	}
	~~if (extenderPackage==null){~~
	~~EventbcoreEditPlugin.INSTANCE.logError(null, "extending ePackage not found during Event-B EMF metamodel extension");~~
	~~}else{~~
	~~for (IConfigurationElement element : elements) {~~
	~~if ("eReference".equals(element.getName())){~~
	~~String eReferenceName = element.getAttribute("name");~~
	~~String parentName = element.getAttribute("parent");~~
	~~boolean containment = Boolean.parseBoolean(element.getAttribute("containment"));~~
	~~String eTypeName = element.getAttribute("eType");~~
	~~String required = element.getAttribute("required");~~
	~~String singular = element.getAttribute("singular");~~
	~~Object parent=null;~~
	~~if ((parent = theCorePackage.getEClassifier(parentName)) == null)~~
	~~if ((parent = theContextPackage.getEClassifier(parentName))==null)~~
	~~if ((parent = theMachinePackage.getEClassifier(parentName))==null);~~

	~~if (parent instanceof EClass){~~
	~~EClass eType = (EClass)extenderPackage.getEClassifier(eTypeName);~~
	~~EReference eReference = EcoreFactory.eINSTANCE.createEReference();~~
	~~eReference.setName(eReferenceName);~~
	~~eReference.setEType(eType);~~
	~~eReference.setContainment(containment);~~
	~~eReference.setUpperBound(ETypedElement.UNBOUNDED_MULTIPLICITY); //change to set from required and singular~~
	~~((EClass)parent).getEStructuralFeatures().add(eReference);~~
	}
	}
	}
	}
	}
	~~catch (Exception e) {~~
	~~EventbcoreEditPlugin.INSTANCE.logError(e, "failed getting Event-B EMF extensions");~~
	}
	}
	}


	~~'''example metamodel-extension (containment definition)'''~~
	~~<extension~~
	~~point="org.eventb.emf.core.metamodel_extension">~~
	~~<ePackage~~
	~~eNS_URI="http://emf.eventb.org/models/records"~~
	~~name="RecordsPackage">~~
	~~</ePackage>~~
	~~<eReference~~
	~~containment="true"~~
	~~eType="AbstractRecord"~~
	~~name="records"~~
	~~parent="Context"~~
	~~required="false"~~
	~~singular="false">~~
	~~</eReference>~~
	~~</extension>~~

imported>Colin: /* example code to make a package extensible */

2009-11-25T11:56:21Z

example code to make a package extensible

← Older revision		Revision as of 11:56, 25 November 2009
Line 49:		Line 49:


	~~====~~example code to make a package extensible~~====~~		'''example code to make a package extensible'''
	(the example is for the core package... core package should be changed to the name of your package)		(the example is for the core package... core package should be changed to the name of your package)