Ecore is EMF's object-oriented modelling language, and supports 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.
There can be many perspectives on modelling, traditionally UML class diagrams have been used for both analysis and design, i.e. describing the concepts in the domain as perceived by stakeholders and describing the software solution. When building an Ecore model, there are typically two perspectives that are relevant:
- With a code-centric perspective you create Ecore classes with features that allows the generator to generate the desired Java classes.
- With a runtime-perspective, you think of the Ecore classes as a way of constraining the object structures that are allowed during runtime.
When describing Ecore's modelling constructs below, we will take the latter of these perspectives. For the code perspective, see Genmodel.
Ecore's modelling constructs
Ecore supports classes with attributes (properties of simple types), associations (references to other modelled classes) and operations, and multiple inheritance. The main construct is the class, which is called EClass in Ecore terminology. An EClass contains (structural) features, which are either attributes or references (one-way associations) and operations, and can be related to other classes through inheritance.
| Construct | Runtime instance structures |
|---|---|
EClass Has a name and can be abstract (cannot be instantiated) and interface (purely API). A container of so-called structural features (attributes and associations). Example: | Non-abstract classes can be instantiated. Instances will have attributes values and links to other objects corresponding to contained and inherited features.
|
EDataType A non-modelled or "foreign" type, provided by the host language and runtime environment, like int, double, String, Date etc. Many such types are pre-defined by Ecore, e.g. EInt, EIntegerObject, EDouble, EDoubleObject, EBoolean, EBooleanObject, EString, EDate corresponding to Java's int, Integer, double, Double, boolean, Boolean, String and Date types. You can define your own, to be able to use other Java types in your model. | Instances of the corresponding (non-abstract) Java classes can be created from Strings. |
EClassifier Abstract superclass of EClass and EDataType | |
EAttribute Has a name, type (an EDataType) and multiplicity (lower and upper bounds).
| |
EReference Has a name, type (an EClass) and multiplicity. Corresponds to a one-way/directed association from the owning EClass to another EClass.
| |
Two EReferences may be each other's opposite, meaning that of one instance refers to the other, the other must refer back.
| |
EStructualFeature Abstract superclass of EAttribute and EReference. The distinction between these two is the kind of type they have, EDataType and EClassifier, respectively. | Instances will have fields constrained to the type of the attribute, either the type itself or a list of that type. |
| Operation |
The model itself consists of individual elements in a structure (instances of so-called meta-objects)