Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

Ecore corresponds to a subset of the UML class diagram, so can reuse UML's graphical notation, as a view of the abstract Ecore concepts. The Sirius framework makes it relatively easy to create diagram notations for an abstract model, and to showcase their framework and contribute to the Eclipse modelling community, they have developed the Ecore Tools diagram editor for Ecore.

To create a diagram, select an Ecore file, e.g. just created with the normal Ecore file creation wizard, and then right-click and select Initialize Ecore Diagram... The wizard will first ask you to select a folder for an "aird" file, which will contain the diagram-specific data of your diagram, like location and sizes of boxes, with links to the corresponding Ecore file. While editing, the diagram-specific data will stay in the aird file, while the Ecore model elements will reside in the ecore file, and can be utilised by other tools. Second, the wizard will ask you to select the kind of representation, which should be Entities in a Class Diagram. Finally, you will need to select which object should be used to populate the diagram, which typically would be the (top-level) EPackage. The diagram will be created and opened, but note that the diagram will not actually be populated, but will instead contain a double-clickable label that will do it! The result will be somewhat like the figure to the right (the automatic layout has been edited slightly and some palette element have been collapsed).

The diagram is edited by using standard interaction techniques, like dragging elements from the palette, using handles, activating label editors by selecting and clicking etc. Details are entered in the Properties view, as for the default Ecore editor, but its design has been improved to make it easier to enter relevant data (but not as improved as the EMF Forms-based one).

The OCLinEcore Editor

The Object Constraint Language(OCL) is an expression language that can be used with Ecore to specify constraints, derived features and operation bodies. To make including OCL in models easier, a(nother) textual language has been designed for Ecore, which includes using the OCL syntax for constraints, derived features and operation bodies, in addition to a more Java-like syntax for the ordinary model elements. The custom OCLinEcore Editor supports this languages, while still using the standard XMI-based serialization of Ecore as storage format, so it interoperates nicely with other tools. This means you can open any ecore file in this editor, edit the model and save the file, still using the XMI-based ecore file format. This is different from Xcore's approach (see below), where the storage format is the same as the editor's language.

An example of the language is shown to the right. Almost at the bottom, the invariant keyword introduces the 'oneManager' constraint, where OCL is used for specifying the logic. See wiki page and help page for more about OCLinEcore.

Note that support for OCL must be installed on top of the standard modeling package using the OCL Examples and Editors SDK feature from the main Eclipse installation site.

Image Added

The Xcore editor

Xcore is a project that provides a textual notation for Ecore. Due to Xcore's architecture, you cannot just convert en Ecore model to text and start editing, you'll need to create an Xcore project from scratch using the Xcore project wizard. Then, create an "xcore" file using the Untitled Text File wizard, making sure to name it with the "xcore" file extension (you may need to type something to make the file dirty and saveable). Finally, right-click on the file and select Open With->Xcore Editor to get an editor supporting the Xcore syntax. Alternatively, you can close the original text editor and just double-click the file, since the Xcore Editor will be used by default.

A textual Xcore model corresponding to the models above is shown right. The syntax is similar to Java's, and with the proposals you get by typing ctrl-space it shouldn't be very difficult to learn the syntax. Or you can read https://wiki.eclipse.org/Xcore.

What makes Xcore different is that it actually replaces both ecore and genmodel files, i.e. both will implicitly be generated internally from the xcore file. In addition, the corresponding Java code will also be automatically generated in the src-gen forlder of the project, so the workflow is greatly simplified compared to how you otherwise need to create and open a Genmodel file and selected Generator->Generate Model Code for each model change, as described in the Genmodel page.

 

As mentioned, Xcore combines Ecore and Genmodel in one syntax. To see this, try opening the xcore file with Open With->Reflective Xcore Model Editor. This will give you a tree-based editor containing both Ecore and Genmodel models, as well as other, related models. This is shown in the figure to the right. The first (expanded) tree node named no.hal.org represents the Xcore textual structure (abstract syntax tree). The second node named Org represents the Genmodel model and the third one named org represents the Ecore model.

When loading an xcore file using the standard EMF API, the result is these three hierarchies having similar structure and corresponding objects, e.g. there will be an XClass instance, GenClass instance and EClass instance for each class in the model. Hence, if you have a tool that processes Ecore model elements, you can support both ecore and xcore files by simply searching for EPackages that are the container of Ecore model elements. Unfortunately, although Xcore corresponds to a combination of Ecore and Genmodel, not all tools that need ecore and genmodel files can use an xcore file instead.