| Free tutorials for Java, Eclipse and Web programming |
Version 1.6
Copyright © 2007-2010 Lars Vogel
06.04.2010
| Revision History | ||
|---|---|---|
| Revision 0.1 - 0.4 | 12.08.2007 | Lars Vogel |
| Created, reworked and published | ||
| Revision 0.5 | 30.07.2008 | Lars Vogel |
| Updated to Eclipse 3.5, simplified article, added definition of data model. | ||
| Revision 0.6 | 01.08.2008 | Lars Vogel |
| Clean-up editor description | ||
| Revision 0.7 | 02.08.2008 | Lars Vogel |
| Moved Eclipse JET (Java Emitter Template) to own article http://www.vogella.de/articles/EclipseJET/article.html | ||
| Revision 0.8 | 25.11.2009 | Lars Vogel |
| Fixed typo | ||
| Revision 0.9 | 06.12.2009 | Lars Vogel |
| Improved reading and writing EMF models via code | ||
| Revision 1.0 | 17.01.2010 | Lars Vogel |
| added ecore tools, moved EMF models based on annotations to own article | ||
| Revision 1.1 | 20.01.2010 | Lars Vogel |
| Update chapter 5 with new model | ||
| Revision 1.2 | 21.01.2010 | Lars Vogel |
| Moved persistence and notifcation to own articles | ||
| Revision 1.3 | 27.01.2010 | Lars Vogel |
| Added infos on ecore and genmodel | ||
| Revision 1.4 | 08.03.2010 | Lars Vogel |
| how to extend / inheritant from an EMF model | ||
| Revision 1.5 | 30.03.2010 | Lars Vogel |
| Reworked article | ||
| Revision 1.6 | 06.04.2010 | Lars Vogel |
| Improved data type description | ||
Table of Contents
A data model, sometimes also called domain model, represents the data you want to work with. For example if you develop an online flight booking application you might model your domain model with objects like "Person", "Flight", "Booking" etc. The general recommendation is to model your data model independent of the application logic. This approach leads to classes with almost no logic and a lot of properties, e.g. Person would have the properties "firstName", "lastName", "Address", etc.
Eclipse EMF can be used to model your domain model. EMF has a distinction between the meta-model and the actual model. The meta-model describes the structure of the model. A model is then the instance of this meta-model.
EMF uses XMI (XML Metadata Interchange) to persists the model definition.
This EMF meta-model definition can be defined based on:
A XMI document, using an XML or text editor
Java annotations
UML
XML Schema
Once the EMF meta-model is specified you can generate the corresponding Java implementations classes from this model. EMF provides the possibility that the generated code can be safely extended by hand.
EMF is based on two meta-models; the Ecore and the Genmodel model. The Ecore metamodel contains the information about the defined classes.
EClass : represents a class, with zero or more attributes and zero or more references.
EAttribute : represents an attribute which has a name and a type.
EReference : represents one end of an association between two classes. It has flag to indicate if it represent a containment and a reference class to which it points.
EDataType : represents the type of an attribute, e.g. int, float or java.util.Date
The Genmodel contains additional information for the codegeneration, e.g. the path and file information. The genmodel contains also the control parameter how the coding should be generated.
The Ecore model shows a root object representing the whole model. This model has children which represents the packages, whose children represents the classes, while the children of the classes represents the attributes of these classes. EMF's meta model Ecore (roughly) corresponds to the EMOF (Essential MOF) subset of the MOF 2.0 standard.
With EMF you make your domain model explicit which helps to provide clear visibility of the model. EMF also provides change notification functionality to the model in case of model changes. EMF will generate interfaces and factory to create your objects; therefore it helps you to keep your application clean from the individual implementaiton classes.
Another advantages is that you can regenerate the Java code from the model at any point in time.