General |
top
|
- What is EMF?
The Eclipse Modeling Framework
is a Java/XML framework for generating tools and other applications based on simple
class models.
EMF helps you rapidly turn models into efficient, correct, and easily customizable Java code.
It is intended to provide the benefits of formal modeling, but with a very low cost of entry.
In addition to code generation, it provides the ability to save objects as XML documents for
interchange with other tools and applications.
Models can be created using annotated Java, XML documents, or modeling tools like Rational Rose,
then imported into EMF.
The code generator turns a model into a set of Java implementation classes.
These classes are extensible and regenerable - you can modify them by adding user-defined methods
and instance variables.
When the model changes, you can regenerate the implementation classes, and your modifications
will be retained. This works both ways - changes in the Java code can be used to update
the model.
- How do I get started with EMF?
Start by reading the
overview documents and the tutorial, followed by
downloading the driver.
- What exactly is the tutorial trying to show?
After going through the tutorial, you will have generated a completely working
editor from nothing but a picture of the object model (i.e., the simple libarary
model shown in the tutorial). If you run the generated editor, you can add and
remove books and authors, edit the properties (e.g., the book title), copy, paste,
drag-and-drop, etc. All with unlimited undo/redo. You can also save the document
(the default framework serialization format is XMI).
The purpose of the tutorial is to illustrate the power of a model driven
architecture (MDA). By providing a model for the data your application will
manipulate, you can use EMF to generate a Java implementation for you. EMF.Edit can
leverage the same model (meta) data to generate view support and even a working
editor. Read the overview documents for more details.
- Are there any "real" example EMF models in Eclipse?
Well, for starters, EMF
itself contains two interesting models. The Ecore model serves as the
meta-model for any EMF model you create -- it is the model that describes
the structure of your models. The Genmodel controls generation of an
EMF model. In fact, the generator UI that is used in the tutorial is the
EMF.Edit editor for the Genmodel, which explains why it looks so much like
the library editor in the tutorial. If you want to explore Ecore and
Genmodel further, you'll find their Rose models and Java code in the EMF
source package available on our download page. Of course, the code
produced by the EMF generator is meant to be a starting place, so you'll
see that much functionality has been manually added to both of these
models. But, it's quite easy to see the same sort of generated patterns
that appear in the simple library example. Ecore is in the
org.eclipse.emf.ecore plugin, the Genmodel is in
org.eclipse.emf.codegen.ecore, and its editor UI is in
org.eclipse.emf.codegen.ecore.ui. You'll find the Rose models in the
"model" subdirectory of the source for the former two plugins.
Finally, an even more complex example of an EMF model is XSD,
the XML Schema Infoset Model,
a subproject of the Eclipse Technology Project.
XSD models
the concrete and abstract relationships expressed in an XML schema
document, providing an API to manipulate the model and an
XML-schema-specific replacement for EMF's default XMI serialization. Of
course, there's also an EMF.Edit-based XML schema editor built on it.
|
Download and Install |
top
|
- How do I Install EMF?
Download the version of EMF that matches your installation of
Eclipse. Exit Eclipse, and Unzip into the eclipse directory.
|
Modeling Standards |
top
|
- What is the relationship of OMG™ MOF™ to the EMF Ecore model?
The OMG MOF 1.4 Model has influenced the design of the EMF Ecore model.
The Ecore model evolved in parallel with the MOF 1.4 model.
Implementation experience in integrating a number of tools led to an optimized
implementation (focused on tool integration as opposed to the original MOF focus
of metadata repositories) that uses a subset of the modeling concepts in MOF 1.4.
For example, Ecore does not support ‘first class’ Associations.
Associations are mapped to a pair of Ecore References.
To minimize confusion, we have used the term ‘Ecore’ to refer to the object model
in the EMF framework.
We use the terms ‘Ecore model’ and ‘EMF model’ interchangeably in this FAQ,
because the object model of the Eclipse EMF framework is the Ecore model.
The designers of EMF are participating in the OMG process to influence the design
of MOF 2.0 and UML 2.0, which are still being defined.
- Does EMF support OMG XMI?
EMF uses OMG XML Metadata Interchange (XMI™) 2.0 as the default XML serialization
format for Ecore models and Ecore instances.
The EMF framework allows the use of other serialization formats also.
The XMI 2.0 document production rules are used because of more compact representation
than XMI 1.2.
- Can I create an EMF model using UML™ modeling tools?
EMF models can be defined using UML modeling tools such as Rational Rose.
You simply define a class model with the packages, attributes, references, data
types, and operations.
This class model can be imported into EMF for additional code generation.
Since many Java developers are familiar with simple class modeling, this serves
as a ‘gentle introduction’ to UML class modeling.
In addition to UML class models, EMF models can be created by using annotated Java
interfaces or by directly editing an XMI document using an XML editor.
This approach is used to allow the benefits of model based code generation (one of
the principles of the OMG Model Driven Architecture – MDA)
to not just users familiar with UML, but also the larger community of developers
using Java and XML.
- Can I create an EMF model using OMG XMI?
Yes.
The XMI document that conforms to the EMF Ecore model can be directly edited using
your favorite text or an XML editor. Alternately you can use a modeling tool that
can produce the XMI document from a UML model.
You can also use annotated Java interfaces to define your input model.
- What is Model Driven Architecture – MDA?
MDA is an industry architecture proposed by the OMG that addresses full life cycle
application development, data, and application integration standards that
work with multiple middleware (CORBA, J2EE), languages, and interchange formats.
MDA unifies some of the industry best practices in software architecture,
modeling, metadata management, and software transformation technologies that allow a
user to develop a modeling specification once and target multiple
technology implementations by using precise transformations/mappings.
An example of the use of MDA is to use a UML model representation of a tool or application
and to use this model to automate (some or all) of the Java interface, implementation, as
well as any XML serialization for the modeled objects.
Many of the recent OMG standards such as UML, MOF, and CWM were developed using MDA principles
of using abstract models (these are also referred to as Platform Independent Models – PIM)
which can be mapped to Platform Specific Models (PSM).
Please note that ‘platform independent’ is a relative term!
For more information on MDA and related MDA specifications including UML, XMI,
and MOF, please visit www.omg.org/mda.
- What is the relationship of EMF to OMG™ MDA™?
One of the key goals of EMF is to use simple visual models to allow easy integration of Java
and XML tools.
To accomplish this you can use a UML class model as input to the EMF framework.
This model is then used to drive Java interface and implementation generation for EMF instances.
These Java interfaces define a consistent programming model for tools built using EMF.
The same EMF model is also used to generate the XML serialization (XMI 2.0 format) for EMF
instances.
Essentially EMF supports the key MDA concept of using models as input to development and
integration tools which produce multiple programming language (Java in the case of Eclipse
EMF itself) or data interchange format (XML) representations.
The code generation and XML serialization is ‘driven’ from the same model.
EMF supports OMG XMI 2.0 XML serialization format and the use of UML models for the analysis
and design of EMF models.
- What is the relationship of EMF to JMI™?
JMI (Java™ Metadata Interface) is a mapping of the OMG MOF 1.4 to the Java language developed
by the Java Community Process.
The JMI spec and the Eclipse EMF model to Java mapping were developed in parallel
and are not the same.
The Eclipse EMF Java mappings have been optimized for in memory tool integration using Java and
XML while JMI has been optimized for metadata repository usage scenarios.
Eclipse EMF designers are actively involved in the ongoing development of MOF 2.0 and related
mappings to XML and Java that are expected to proceed in the OMG and Java Community Process
respectively.
|
Developer |
top
|
- Does it matter what node in the genmodel tree I invoke Generate from?
Definitely. To do a full generation, you need to invoke "Generate" or "Generate EMF.Edit"
from the root node in the genmodel editor. If you invoke Generate lower down, you'll
only generate the files associated with the selected subtree.
- Can model classes be in the Java default package?
No. EMF does not allow model classes to be in the default Java package because it
would need to be handled specially in the code generator,
and since it's not a good Java convention anyway, we don't think it is
worth supporting. Make sure that if you load your model from annotated Java that
all the interfaces and classes with an @model tag also have an explicit
package declaration.
- Can annotated Java files use * imports?
Currently no. Until our Java name lookup mechanisms are
improved, we really rely on explicit imports to resolve names, i.e., two * imports
would confuse the code. It's best to entirely avoid * imports for the time being.
We will improve identifier lookup in the coming weeks.
- Does regeneration/merge work for properties and plugin.xml files?
Not yet. The current generator does not support merge for the plugin.properties and
plugin.xml files, so it will not overwrite them if they exist. If you want
to regenerate them, you'll need to remove or rename them before regenerating.
This will also be improved in the future.
- Can EMF be used in stand-alone applications?
An EMF model can be used without change in a stand-alone application with one exception. The default (XMI)
serializer is not registered in the stand-alone EMF environment, so you need to explicitly register it
with your model. For example, to register the XMI serializer for the library model, you would add something
like this in your main:
Resource.Factory.Registry.INSTANCE.getExtensionToFactoryMap().put("library", new XMIResourceFactoryImpl());
For EMF.Edit, the following framework plugins contain resources.jar files that need to be on the CLASSPATH
for stand-alone execution.
- org.eclipse.emf.common.ui/runtime/common.ui.resources.jar
- org.eclipse.emf.common/runtime/common.resources.jar
- org.eclipse.emf.edit.ui/runtime/edit.ui.resources.jar
- org.eclipse.emf.edit/runtime/edit.resources.jar
Also, to produce the right .jar file for stand-alone execution of a generated project,
you need to copy the plugin.properties file and the icons directory to the directory containing
the EMF XyzPlugin for the project.
This will put the resources in just the right place to be found by the generated XyzPlugin
during stand-alone execution. Such a project will work as both a plugin and for stand-alone execution.
|