...
The core of EMF is an object-oriented modelling language called Ecore, and a supporting runtime. Ecore can be thought of as a subset of UML class diagrams (without the graphical notation), that is big enough to support basic domain modelling and small enough to allow for an efficient and lean framework. Ecore supports classes with attributes (properties of simple types), associations (references to other modelled classes) and operations, and multiple inheritance.
For more, see our Ecore page.
Ecore models may be edited using different tools and syntaxes. EMF itself provides a tree-based editor and an XML-based format (mostly for serialisation e.g. to files), EMFJSON provides a JSON format, Ecore tools (based on Sirius) provides a diagram notation and Xcore a textual syntax similar to Java classes. However, all support the same abstract language of classes, attributes, associations, operations and inheritance and any Ecore-supporting tool may use the resulting Ecore model.
For more, see our page on Editing Ecore models.
A plethora of other tools and frameworks utilise Ecore models to provide important and time-saving functionality, either part of the Eclipse Modelling project or the surrounding eco-system.
For more, see our Ecore page
Genmodel - generating Java code
To turn an Ecore model into executable Java code, you need to configure a generator model called genmodel and run EMF's code generator. A default genmodel is provided automatically, so the only thing you normally need to do is name the Java package (prefix) of the generated Java classes. The generator may generate Java classes corresponding directly to the Ecore classes, like OrgUnit and Person. If your Ecore classes include operations, you will need to add custom code to the generated classes (methods stubs).
In addition to domain classes, you may generate an Eclipse-based editor for your model, which you can install into Eclipse to make it easier to edit your domain data.
For more, see our Genmodel page.
Validation - checking your domain data
An Ecore model will to a certain extent constrain the structure of domain objects you can create, e.g. based on the multiplicity of attributes and association. However, not all such constraints are considered hard in the sense that they are enforced by the generated classes. E.g. if an attribute's multiplicity has a lower bound of two, it will always be possible to add only one value. Instead, you may ask EMF to validate your model, and a set of diagnostic objects will tell which (if any) constraints are violated. You may add your own custom validation rules, e.g. to limit the range of integer values or characters in a String, or ensure more structural constraints are met, like an OrgUnit always having a Person with a manager Role. The generated editor will automatically use the validation mechanism to indicate violated constraints, so you can avoid illegal domain data.
For more, see our Validation page.
Persistance - storing your data
Being able to store domain data is fundamental to any application, and there are many choices for persisting Ecore-based data. EMF provides XML-based persistance of any legal structure of domain objects to file, and other projects supports other formats, e.g. EMFJSON supports JSON, and ESON a more human-friendly JSON-like syntax. There are lots of ways of tweaking the XML format used by default, or customise how the generated code handles persistance, e.g. switch to JSON or a completely custom format. In the latter case, you can implement the serialiser and parser by hand or use DSL frameworks like Xtext and EMFText to generate them from a grammar.
For more, see our Serialization page.
If you prefer persisting to a database, Teneo supports mapping Ecore models to database tables and relations (so-called Object-Relation Mapping (ORM)) using Hibernate. The CDO project also supports several relational databases. If you prefer NoSQL storage, EMFJSON supports the increasingly popular MongoDB.
...
While the editor support provided by EMF will give you functionally complete editors, they are not usable/suitable for most end-users. Better editors can of course be developed by hand, but several frameworks allow you to make good editors without a lot of coding. The EMF Forms project allows you to build a custom, form-based GUI for your domain data without coding. Instead you compose your form from layouts and editing widgets and configure how they operate on the underlying domain data. The EMF Client Platform (ECP) provides a more complete (and complex) application development framework based on the same ideas. If you prefer a diagram notation for your data, combined with some form support, or advanced tables, you can use the Sirius framework.
For more, see our page on Editing Ecore model instances.