This section focus on how to make an ECLass extensible by the eMDE mechanism and how to contribute with new extensions
Let take the following example to ilustate all the steps.
The ecore model A contains two EClasses: Project and Component. The first one is the model root element. It contains the containment EReference ownedComponents. That reference will be used to store all the Components of a project.
The Ns URI is http://www.polarsys.org/kitalpha/a/ |
|
The ecore model B contains the EClass ComponentExtension.
The Ns URI is http://www.polarsys.org/kitalpha/b/ |
Any EClass can be made extensible by adding emde.ExtensibleElement in it super classes list. To do that, one can uses the Ecore editor provided by EMF.
The steps bellow is an example of making the EClass a.Component extensible.
a.Component EClass.a.Component EClass by adding emde.ExtensibleElement in the list.The definition of an EClass as an eMDE extension in managed by adding:
emde.ElementExtension as a super type of the EClass to define as an extensionThe following sections describe the different EAnotations, the extensibility graphical designer and conclude with an example.
This EAnnotation concerns the EPackage containing the EClass to be defined as extension. It aims at initializing in the ecore model some required modification to do in the genmodel. That information are stored in the EAnnotation details entries and used by the EMF generation provided by Kitalpha.
The EAnnotation must have the following information:
http://www.polarsys.org/kitalpha/emde/1.0.0/extensionextensibleProviderFactory,
Value: true
childCreationExtenders,
Value: true
useUUIDs,
Value: true
useIDAttributes,
Value: fasle
The EAnnotation for the EPackage must be added only once.
These EAnnotation concerns the EClass to be defined as eMDE extension. There are two EAnnotations. The both provide an URI of the Extensible EClass. The difference between them is that the first one provides an Ns URI based URI and the second one provides a platform based URI.
The first EAnnotation must have the following information:
http://www.polarsys.org/kitalpha/emde/1.0.0/constraintExtendedElement,
Value:
An Ns URI based URI of the extensible EClass.
The second EAnnotation must have the following information:
http://www.polarsys.org/kitalpha/emde/1.0.0/constraintMappingMapping,
Value:
A platform based URI of the extensible EClass.
Kitalpha provides a Sirius diagram allowing end-users to define easily the EAnnotation for EPackages and EClasses.
To use that graphical designer, first, a Sirius representation should be created on the concerned ecore model. The steps are listed bellow:
Once the diagram created, the EAnnotation for the EPackage is automatically created.
Lets define the EClass b.ComponentExtension as an extension to the EClass b.ComponentExtension. The picture bellow shows an Extensibility diagram created on the EPackage b.
Step 1
The tool
Define Extension Element allow to display the EClass b.ComponentExtension on the diagram (see picture bellow). Concretely, this tool add the ECLass emde.ElementExtension as a super type of the EClass b.ComponentExtension and the diagram display only EClasses that inherit from the EClass b.ComponentExtension.
Step 2
Second, the tool
Extend Model allows to defines the EAnnotations to make the EClass b.ComponentExtension an extension to the EClass b.ComponentExtension. This tool end-user to select an extensible EClass and add the EAnnotations. The result on the diagram is shown in the picture bellow.
Result
The pictures bellow show the B.ecore model before (left side) and after (right side) adding the required EAnnotation to define the EClass b.ComponentExtension as an extension of the class a.Component.