The default Ecore editor, named Sample Ecore Model Editor in Eclipse, provides tree-based editing of the main hierarchical structure of Ecore model elements, with commands for creating, deleting, copying and pasting elements, and a property sheet for editing details. The latter is shown in the standard Properties view outside the editor itself.

An example of the editor and Properties view is show right. The root node represents the file, it which contains an EPackage containing three EClasses.

. The Person EClass contains an worksIn EReference, and since the latter is selected, its attributes are shown in the Properties view.

To create new elements, you can right-click on the parent (to-be) and select New Child and the type of element to add. Only legal types of elements are shown, e.g. you can add an EReference to an EClass, but not to an EDataType. The new element is inserted at the bottom of the list of children underneath the parent, so you may have to move it using drag & drop. If you want to place the new element in the middle of a list of children, you can alternatively right-click on the child just above where you want the new element and select New Sibling and the element type.

The Properties view allows you to edit attributes of the selected element, and you will at least need to enter the name of new elements. Click in the Value column to enter editing mode. For each type of element, there are certain attributes you will need to consider. E.g. all EStructuralFeatures (EAttributes and EReferences) need a type (eType attribute), and you should also consider the Uppper Bound property and the Containment and Container flags.

In Eclipse's Edit menu you'll find the standard delete, cut, copy and paste commands that are accessible using the standard keyboard shortcuts. The latter two are particularly useful to save time, e.g. to make a new EReference similar to worksIn, it is often quicker to copy and paste it into the containing class and then edit the differing attributes, rather than using New Child or New Sibling.

The EMF Forms project has contributed another Ecore editor, named Ecore Editor in Eclipse. This editor is based on the default one and hence is tree-based, but has some improvements.

When right-clicking you immediately get a menu for selecting the type of child element to add, and it prompts you for relevant data.

The editor has its own pane for properties that has been tailored for Ecore with special attention to what attributes are most commonly edited, so you won't be using the Properties view. The same model as above is shown right, and as can be seen, some attributes have been "promoted" to the Standard group of properties, while others are in the Advanced group. This is particularly helpful for novices, as it helps to focus on the most relevant attributes.

For more about this editor, see http://eclipsesource.com/blogs/tutorials/emf-forms-editors/#ecoreeditor.

Image Added

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 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.

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.