![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
11 Peking University Software Engineering Insistute 2009
Copyright
Many of the designations used by manufacturers and sellers to distinguish
their products are claimed as trademarks. Where those designations appear in
this book, and the publisher was aware of a trademark claim, the designations
have been printed with initial capital letters or in all capitals.
The authors and publisher have taken care in the preparation of this book, but
make no expressed or implied warranty of any kind and assume no
responsibility for errors or omissions. No liability is assumed for incidental or
consequential damages in connection with or arising out of the use of the
information or programs contained herein.
The publisher offers excellent discounts on this book when ordered in
quantity for bulk purchases or special sales, which may include electronic
versions and/or custom covers and content particular to your business,
training goals, marketing focus, and branding interests. For more information,
please contact:
U.S. Corporate and Government Sales
(800) 382-3419
corpsales@pearsontechgroup.com
For sales outside the United States please contact:
International Sales
international@pearson.com
Visit us on the Web: informit.com/aw
Library of Congress Cataloging-in-Publication Data:
EMF : Eclipse Modeling Framework / Dave Steinberg ... [et al.].
p. cm.
ISBN 0-321-33188-5 (pbk. : alk. paper) 1. Computer software--Development. 2
. Java (Computer
program language) I. Steinberg, Dave.
QA76.76.D47E55 2008
005.13'3--dc22
2007049160
Copyright © 2009 Pearson Education, Inc.
All rights reserved. Printed in the United States of America. This publication
is protected by copyright, and permission must be obtained from the
publisher prior to any prohibited reproduction, storage in a retrieval system,
or transmission in any form or by any means, electronic, mechanical,
photocopying, recording, or likewise. For information regarding permissions,
write to:
Pearson Education, Inc
Rights and Contracts Department
501 Boylston Street, Suite 900](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-16-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
20 Peking University Software Engineering Insistute 2009
References
[1] "Eclipse Platform Technical Overview." Object Technology International, Inc.,
February 2003, http://www.eclipse.org/whitepapers/eclipse-overview.pdf.
[2] "XML Schema Part 0: Primer," Second Edition. W3C, October 2004,
http://www.w3.org/TR/xmlschema-0/.
[3] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of
Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995.
[4] J. Bloch. Effective Java Programming Language Guide. Addison-Wesley,
Reading, MA, 2001.
[5] "Namespaces in XML 1.0," Second Edition. W3C, August 2006,
http://www.w3.org/TR/2006/REC-xml-names-20060816/.
[6] J. Gosling, B. Joy, G. Steele, and G. Bracha. The Java Language Specification,
Third Edition. Addison-Wesley, 2005.
[7] "XML Schema Part 2: Datatypes," Second Edition. W3C, October 2004,
http://www.w3.org/TR/xmlschema-2/.
[8] "XML Schema Part 1: Structures," Second Edition. W3C, October 2004,
http://www.w3.org/TR/xmlschema-1/.](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-25-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
22 Peking University Software Engineering Insistute 2009
single unit referred to as the Eclipse Software Development Kit (SDK). The
components of the other projects are used for specific purposes and are generally
independent and downloaded individually. New projects are created and new
components are added to existing projects on an ongoing basis.
1.1.1. The Eclipse Project
The Eclipse Project supports the development of a platform, or framework, for the
implementation of integrated development environments (IDEs) and other
applications. The Eclipse framework is implemented using Java but is used to
implement development tools for other languages as well (e.g., C++, XML, etc.).
The Eclipse Project itself is divided into four main subprojects: Equinox, the Platform,
the Java Development Tools (JDT), and the Plug-in Development Environment (PDE).
Collectively, the four subprojects provide everything needed to extend the
framework and develop tools based on Eclipse.
Equinox and the Platform are the core components of Eclipse and, together, are
considered by many to be Eclipse. Equinox is an implementation of the OSGi R4 core
framework specification,[1] which provides the component model on which all of
Eclipse is based. The Platform defines additional core frameworks and services
required to support the integration of tools. These services include, among others, a
standard workbench user interface and mechanisms for managing projects, files, and
folders. We describe the platform in more detail in Section 1.2.
[1] The OSGi specifications are available at
http://www2.osgi.org/Specifications/HomePage.
The JDT is a full-function Java development environment built using Eclipse. Its tools
are highly integrated and representative of the power of the Eclipse Platform. It can
be used to develop Java programs for Eclipse or other target platforms. The JDT is
even used to develop the Eclipse Project itself.
The PDE provides views and editors to facilitate the creation of plug-ins for Eclipse.
The PDE builds on and extends the JDT by providing support for the non-Java parts
of the plug-in development activity, such as registering plug-in extensions, and so
on.
1.1.2. The Modeling Project
The Eclipse Modeling Project is the focal point for the evolution and promotion of
model-based development technologies at Eclipse. At its core is EMF, the subject of
this book, which provides the basic framework for modeling. Other modeling
sub-projects build on top of the EMF core, providing such capabilities as model
tranformation, database integration, and graphical editor generation. Also included](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-27-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
23 Peking University Software Engineering Insistute 2009
are a number of implementations of important modeling standards. For example, the
UML2 project provides an EMF-based implementation of the UML 2.x metamodel.
1.1.3. The Tools Project
The Eclipse Tools Project develops a wide range of exemplary, extensible
development tools based on the Eclipse Platform. It includes a rather broad range of
sub-projects. Some provide tools for working with other languages, including
C/C++, COBOL, and PHP. Others, like the Graphical Editing Framework (GEF),
provide common support for larger categories of Eclipse tools. EMF also began its
life as a part of the Tools Project, before the Modeling Project was formed.
1.1.4. The Technology Project
The Eclipse Technology Project provides an opportunity for researchers, academics,
and educators to become involved in the ongoing evolution of Eclipse. This project
serves as a temporary home for new or experimental work, which may reach its
natural conclusion or move into another project on reaching maturity. The other
top-level projects may also contain so-called incubator projects for this purpose.
1.1.5. Other Projects
A growing number of other projects support and provide more specialized types of
tools. These include the Data Tools Platform Project, the Device Software
Development Platform Project, and the Eclipse Web Tools Platform Project, to name
just a few.
1.2. The Eclipse Platform
The Eclipse Platform is a framework for building IDEs. It's been described as "an IDE
for anything, and nothing in particular,"[1] which is pretty much the way you could
think of any framework. It simply defines the basic structure of an IDE. Specific tools
extend the framework and are plugged into it to define a particular IDE collectively.
In fact, the architecture of the platform allows for a subset of its components to be
used to help build just about any application at all.
1.2.1. Plug-In Architecture
In Eclipse, the basic unit of function, or a component, is called a plug-in. The Eclipse
Platform itself and the tools that extend it are both composed of plug-ins. A simple
tool might consist of a single plug-in, but more complex tools are typically divided
into several. Each plug-in contributes functionality that can be invoked by the user or
reused and extended by other plug-ins.](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-28-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
24 Peking University Software Engineering Insistute 2009
The platform runtime engine is responsible for discovering and running plug-ins. It
is implemented atop the OSGi Service Platform, which provides a flexible, standard
component framework allowing plug-ins to be installed and removed without
restarting the platform. The OSGi term for a component is bundle, so you will often
see this term used interchangeably with plug-in.
From a packaging perspective, a plug-in includes everything needed to run the
component, such as Java code, images, translated text, and the like. It also includes
two manifest files.[2] The OSGi bundle manifest file, named
META-INF/MANIFEST.MF, identifies the plug-in and provides, among other things,
dependency information. It includes the following:
[2] The OSGi-based runtime was introduced in Eclipse 3.0. Prior to this, a single
plug-in manifest file was used. For backward compatibility, the Eclipse Platform and
EMF still support this simpler, but less flexible, approach.
Required bundles. Its dependencies on other plug-ins.
Exported packages. The packages that it makes visible to other plug-ins.
The plug-in manifest file, named plugin.xml, declares the interconnections to other
plug-ins. It can define the following:
Extension points. Declarations of functionality that it makes available to other
plug-ins.
Extensions. Use (implementation) of other plug-ins' extension points.
The platform runtime manages the life cycle of the plug-ins and matches extensions
with their corresponding extension points. It uses class loaders to enforce the
visibility declared in the manifest files and provides a registry that plug-ins can
consult to discover the extensions to their extension points.
1.2.2. Workspace Resources
Integrated Eclipse tools work with ordinary files and folders, but they use a higher
level application programming interface (API) based on resources, projects, and a
workspace. A resource is the Eclipse representation of a file or folder that provides
the following additional capabilities:
1. Change listeners can be registered to receive resource change notifications
(called resource deltas).
2. Markers, such as error messages or to-do lists, can be added to a resource.
3. The previous content, or history, of a resource can be tracked.
A project is a special folder-type resource that maps to a user-specified folder in the
underlying file system. The subfolders of the project are the same as in the physical](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-29-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
26 Peking University Software Engineering Insistute 2009
Workbench
The workbench is the main window that the user sees when running the Eclipse IDE,
or any other Eclipse-based application; it's sometimes referred to as the Eclipse
desktop.[3] It is itself implemented using SWT and JFace.
[3] Although primarily intended for graphical user interface (GUI)-based
development, the Eclipse Platform can also be used to implement non-GUI
applications by running a "headless" workbench.
A workbench window is composed primarily of editors and views. Eclipse editors
work in the usual way, but they are integrated into the workbench window instead
of launched externally in their own window. Views are used to present more, or
different, information about the contents of the active editor or about the object
selected in an editor or another view. Typically, only one instance of a view can exist
at a time, and it is immediately updated based on the state of the workbench.
Likewise, any changes made in a view typically take effect immediately, without
requiring a save action. When activated, editors and views can contribute actions to
the workbench's menus and toolbar.
The arrangement of views and editors in the workbench window can be customized
to suit a role or task. A particular default arrangement is called a perspective in
Eclipse. The user can change the arrangement of a perspective and save the result for
future use.
The primary way to extend the Eclipse Platform is using extension points provided
by the workbench. These extension points allow tools to add new editors, views, or
perspectives to the workbench. Tools can also customize existing editors, views, or
perspectives for their own purposes.
IDE
The IDE is an instantiation of the generic workbench described earlier. It configures
the workbench with appropriate views, editors, and perspectives for an IDE.
For example, the IDE provides a Navigator view, based on the workspace model, for
navigating the tree of resources in the workspace and for performing common
actions on those resources, like deletion, copying, and renaming.
The IDE also provides IDE-specific menu and toolbar items, preference pages, and
other extensions.
1.2.4. Rich Client Platform](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-31-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
28 Peking University Software Engineering Insistute 2009
Chapter 2. Introducing EMF
Simply put, the Eclipse Modeling Framework (EMF) is a modeling framework that
exploits the facilities provided by Eclipse. By now, you probably know what Eclipse
is, given that you either just read Chapter 1, or you skipped it, presumably because
you already knew what it was. You also probably know what a framework is,
because you know what Eclipse is, and Eclipse is itself a framework. So, to
understand what EMF really is, all you need to know is one more thing: What is a
model? Or better yet, what do we mean by a model?
If you're familiar with things like class diagrams, collaboration diagrams, state
diagrams, and so on, you're probably thinking that a model is a set of those things,
probably defined using Unified Modeling Language (UML), the standard notation
for them. You might be imagining a higher level description of an application from
which some, or all, of the implementation can be generated. Well, you're right about
what a model is, but not exactly about EMF's spin on it.
Although the idea is the same, a model in EMF is less general and not quite as high
level as the commonly accepted interpretation. EMF doesn't require a completely
different methodology or any sophisticated modeling tools. All you need to get
started with EMF are the Eclipse Java Development Tools. As you'll see in the
following sections, EMF relates modeling concepts directly to their implementations,
thereby bringing to Eclipse—and Java developers in general—the benefits of
modeling with a low cost of entry.
2.1. Unifying Java, XML, and UML
To help understand what EMF is about, let's start with a simple Java programming
example. Say that you've been given the job of writing a program to manage
purchase orders for some store or supplier.[1] You've been told that a purchase order
includes a "bill to" and "ship to" address, and a collection of (purchase) items. An
item includes a product name, a quantity, and a price. "No problem," you say, and
you proceed to create the following Java interfaces:
[1] If you've read much about XML Schema, you'll probably find this example quite
familiar, as it's based on the well-known example from the World Wide Web
Consortium's XML Schema primer [2]. We've simplified it here, but in Chapter 4
we'll step up to the real thing.
public interface PurchaseOrder
{
String getShipTo();
void setShipTo(String value);](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-33-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
29 Peking University Software Engineering Insistute 2009
String getBillTo();
void setBillTo(String value);
List getItems(); // List of Item
}
public interface Item
{
String getProductName();
void setProductName(String value);
int getQuantity();
void setQuantity(int value);
float getPrice();
void setPrice(float value);
}
Starting with these interfaces, you've got what you need to begin writing the
application UI, persistence, and so on.
Before you start to write the implementation code, your boss asks you, "Shouldn't
you create a 'model' first?" If you're like other Java programmers we've talked to,
who didn't think that modeling was relevant to them, then you'd probably claim that
the Java code is the model. "Describing the model using some formal notation would
have no added value," you say. Maybe a class diagram or two would fill out the
documentation a bit, but other than that it simply doesn't help. So, to appease the
boss, you produce the UML diagram shown in Figure 2.1.[2]
[2] If you're unfamiliar with UML and are wondering what things like the little black
diamond mean, Appendix A provides a brief overview of the notation.
Figure 2.1. UML diagram of interfaces.](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-34-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
32 Peking University Software Engineering Insistute 2009
How's that for a quote? With EMF, modeling and programming can be considered
the same thing. Instead of forcing a separation of the high-level engineering and
modeling work from the low-level implementation programming, it brings them
together as two well-integrated parts of the same job. Often, especially with large
applications, this kind of separation is still desirable, but with EMF the degree to
which it is done is entirely up to you.
Why is modeling interesting in the first place? Well, for starters it gives you the
ability to describe what your application is supposed to do (presumably) more easily
than with code. This in turn can give you a solid, high-level way both to
communicate the design and to generate part, if not all, of the implementation code.
If you're a hard-core programmer without a lot of faith in the idea of high-level
modeling, you should think of EMF as a gentle introduction to modeling, and the
benefits it implies. You don't need to step up to a whole new methodology, but you
can enjoy some of the benefits of modeling. Once you see the power of EMF and its
generator, who knows, we might even make a modeler out of you yet!
If, on the other hand, you have already bought into the idea of modeling, and even
the Model Driven Architecture (MDA) big picture,[3] you should think of EMF as a
technology that is moving in that direction, but more slowly than immediate
widespread adoption. You can think of EMF as MDA on training wheels. We're
definitely riding the bike, but we don't want to fall down and hurt ourselves by
moving too fast. The problem is that high-level modeling languages need to be
learned, and because we're going to need to work with (e.g., debug) generated Java
code anyway, we now need to understand the mapping between them. Except for
specific applications where things like state diagrams, for example, can be the most
effective way to convey the behavior, in the general case, good old-fashioned Java
programming is the simplest and most direct way to do the job.
[3] MDA is described in Section 2.6.4.
From the last two paragraphs, you've probably surmised that EMF stands in the
middle between two extreme views of modeling: the "I don't need modeling" crowd,
and the "Modeling rules!" crowd. You might be thinking that being in the middle
implies that EMF is a compromise and is reduced to the lowest common
denominator. You're right about EMF being in the middle and requiring a bit of
compromise from those with extreme views. However, as the designers of EMF, we
truly feel that its exact position in the middle represents the right level of modeling at
this point in the evolution of software development technology. We believe that EMF
mixes just the right amount of modeling with programming to maximize the
effectiveness of both. We must admit, though, that standing in the middle and
arguing out of both sides of our mouths can get tiring!](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-37-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
34 Peking University Software Engineering Insistute 2009
The model used to represent models in EMF is called Ecore. Ecore is itself an EMF
model, and thus is its own metamodel. You could say that makes it a
meta-metamodel. People often get confused when talking about meta-metamodels
(metamodels in general, for that matter), but the concept is actually quite simple. A
metamodel is simply the model of a model, and if that model is itself a metamodel,
then the metamodel is in fact a meta-metamodel.[4] Got it? If not, don't worry about it,
as it's really just an academic issue anyway.
[4] This concept can recurse into meta-meta-metamodels, and so on, but we won't go
there.
A simplified subset of the Ecore metamodel is shown in Figure 2.3. This diagram
only shows the parts of Ecore needed to describe our purchase order example, and
we've taken the liberty of simplifying it a bit to avoid showing base classes. For
example, in the real Ecore metamodel the classes EClass, EAttribute, and EReference
share a common base class, ENamedElement, which defines the name attribute that
here we've shown explicitly in the classes themselves.
Figure 2.3. A simplified subset of the Ecore metamodel.
As you can see, there are four Ecore classes needed to represent our model:
1. EClass is used to represent a modeled class. It has a name, zero or more
attributes, and zero or more references.
2. EAttribute is used to represent a modeled attribute. Attributes have a name
and a type.
3. EReference is used to represent one end of an association between classes. It
has a name, a boolean flag to indicate if it represents containment, and a
reference (target) type, which is another class.
4. EDataType is used to represent the type of an attribute. A data type can be a
primitive type like int or float or an object type like java.util.Date.
Notice that the names of the classes correspond most closely to the UML terms. This
is not surprising because UML stands for Unified Modeling Language. In fact, you](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-39-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
35 Peking University Software Engineering Insistute 2009
might be wondering why UML isn't "the" EMF model. Why does EMF need its own
model? Well, the answer is quite simply that Ecore is a small and simplified subset of
full UML. Full UML supports much more ambitious modeling than the core support
in EMF. UML, for example, allows you to model the behavior of an application, as
well as its class structure. We'll talk more about the relationship of EMF to UML and
other standards in Section 2.6.
We can now use instances of the classes defined in Ecore to describe the class
structure of our application models. For example, we describe the purchase order
class as an instance of EClass named "PurchaseOrder". It contains two attributes
(instances of EAttribute that are accessed via eAttributes) named "shipTo" and
"billTo", and one reference (an instance of EReference that is accessed via eReferences)
named "items", for which eReferenceType (its target type) is equal to another EClass
instance named "Item". These instances are shown in Figure 2.4.
Figure 2.4. The purchase order Ecore instances.
When we instantiate the classes defined in the Ecore metamodel to define the model
for our own application, we are creating what we call an Ecore model.
2.3.2. Creating and Editing the Model
Now that we have these Ecore objects to represent a model in memory, EMF can read
from them to, among other things, generate implementation code. You might be
wondering, though, how do you create the model in the first place? The answer is
that you need to build it from whatever input form you start with. If you start with
Java interfaces, EMF will introspect them and build the Ecore model. If, instead, you
start with an XML Schema, then the model will be built from that. If you start with
UML, there are three possibilities:
1. Direct Ecore editing. EMF includes a simple tree-based sample editor for
Ecore. If you'd rather use a graphical tool, the Ecore Tools project[5] provides a
graphical Ecore editor based on UML notation. Third-party options are also
available, including Topcased's Ecore Editor (http://www.topcased.org/),](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-40-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
36 Peking University Software Engineering Insistute 2009
Omondo's EclipseUML (http://www.omondo.com/) and Soyatec's eUML
(http://www.soyatec.com/).
2. Import from UML. The EMF Project and EMF Model wizards provide an
extensible framework, into which model importers can be plugged,
supporting different model formats. EMF provides support for Rational Rose
(.mdl files) only. The reason Rose has this special status is because it's the tool
that was used to "bootstrap" the implementation of EMF itself. The UML2
project[6] also provides a model importer for standard UML 2.x models.
3. Export from UML. This is similar to the second option, but the conversion
support is provided exclusively by the UML tool. It is invoked from within
the UML tool, instead of from an EMF wizard.
As you might imagine, the first option is the most desirable. With it, there is no
import or export step in the development process. You simply edit the model and
then generate. Also, unlike the other options, you don't need to worry about the
Ecore model being out of sync with the tool's own native model. The other two
approaches require an explicit reimport or reexport step whenever the UML model
changes.
The advantage of the second and third options is that you can use the UML tool to do
more than just your EMF modeling. You can use the full power of UML and
whatever fancy features the particular tool has to offer. If it supports its own code
generation, for example, you can use the tool to define your Ecore model, and also to
both define and generate other parts of your application. As long as a mechanism for
conversion to Ecore is provided, that tool will also be usable as an input source for
EMF and its generator.
2.3.3. XMI Serialization
By now you might be wondering what the serialized form of an Ecore model is.
Previously, we've observed that the "conceptual" model is represented in at least
three physical places: Java code, XML Schema, or a UML diagram. Should there be
just one form that we use as the primary, or standard, representation? If so, which
one should it be?
Believe it or not, we actually have yet another (i.e., a fourth) persistent form that we
use as the canonical representation: XML Metadata Interchange (XMI). Why did we
need another one? We weren't exactly short of ways to represent the model
persistently.
For starters, Java code, XML Schema, and UML all carry additional information
beyond what is captured in an Ecore model. Moreover, none of these forms is
required in every scenario in which EMF can be used. Java code was the only one
required in our running example, but as we will soon see, even it is optional in some](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-41-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
37 Peking University Software Engineering Insistute 2009
cases. So, what we need is a direct serialization of Ecore, which doesn't add any extra
information. XMI fits the bill here, as it is a standard for serializing metadata
concisely using XML.
Serialized as an Ecore XMI file, our purchase order model looks something like this:
Code View: Scroll / Show All
<?xml version="1.0" encoding="UTF-8"?>
<ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="po"
nsURI="http://www.example.com/SimplePO" nsPrefix="po">
<eClassifiers xsi:type="ecore:EClass" name="PurchaseOrder">
<eStructuralFeatures xsi:type="ecore:EAttribute" name="shipTo"
eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="billTo"
eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EReference" name="items"
upperBound="-1" eType="#//Item" containment="true"/>
</eClassifiers>
<eClassifiers xsi:type="ecore:EClass" name="Item">
<eStructuralFeatures xsi:type="ecore:EAttribute"
name="productName"
eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EString"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="quantity"
eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EInt"/>
<eStructuralFeatures xsi:type="ecore:EAttribute" name="price"
eType="ecore:EDataType
http://www.eclipse.org/emf/2002/Ecore#//EFloat"/>
</eClassifiers>
</ecore:EPackage>
Notice that the XML elements correspond directly to the Ecore instances back in
Figure 2.4, which makes perfect sense because this is a serialization of exactly those
objects. Here we've hit an important point: because Ecore metadata is not the same as,
for example, UML metadata, XMI serializations of the two are not the same either.[7]
[7] When we spoke of exporting a model for use with EMF in the previous section, we
were really talking about exporting to Ecore XMI, specifically.](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-42-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
38 Peking University Software Engineering Insistute 2009
2.3.4. Java Annotations
Let's revisit the issue of defining an Ecore model using Java interfaces. Previously we
implied that when provided with ordinary Java interfaces, EMF "would" introspect
them and deduce the model properties. That's not exactly the case. The truth is that
given interfaces containing standard get() methods,[8] EMF could deduce the model
attributes and references. EMF does not, however, blindly assume that every
interface and method in it is part of the model. The reason for this is that the EMF
generator is a code-merging generator. It generates code that not only is capable of
being merged with user-written code, it's expected to be.
[8] EMF uses a subset of the JavaBeans simple property accessor naming patterns. For
more information, see Section 7.1 of the specification at
http://java.sun.com/products/javabeans/docs/spec.html.
Because of this, our PurchaseOrder interface isn't quite right for use as a model
definition. First of all, the parts of the interface that correspond to model elements
whose implementation should be generated need to be indicated. Unless explicitly
marked with an @model annotation in the Javadoc comment, a method is not
considered to be part of the model definition. For example, interface PurchaseOrder
needs the following annotations:
/**
* @model
*/
public interface PurchaseOrder
{
/**
* @model
*/
String getShipTo();
/**
* @model
*/
String getBillTo();
/**
* @model type="Item" containment="true"
*/
List getItems();
}](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-43-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
39 Peking University Software Engineering Insistute 2009
Here, the @model tags identify PurhaseOrder as a modeled class, with two attributes,
shipTo and billTo, and a single reference, items. Notice that both attributes, shipTo
and billTo, have all their model information available through Java introspection;
that is, they are simple attributes of type String. No additional model information
appears after their @model tags, because only information that is different from the
default needs to be specified.
There is some non-default model information needed for the items reference.
Because the reference is multiplicity-many, indicated by the fact that getItems()
returns a List, we need to specify the target type of the reference as type="Item".[9]
We also need to specify containment="true" to indicate that we want purchase orders
to be a container for their items and serialize them as children.
[9] Note that beginning with Java 5.0, generics can be used to specify a list's item type.
Generics have only been supported in EMF since version 2.3. You'll see the older
form, with a raw list type, throughout most of this book, both as the Java
specification for a multiplicity-many reference and in the code generated from it.
Chapter 21, which focuses specifically on EMF 2.3 and 2.4, details the new
generics-based form.
Notice that the setShipTo() and setBillTo() methods are not required in the annotated
interface. With the annotations present on the get() method, we don't need to include
them; once we've identified the attributes (which are settable by default), the set()
methods will be generated and merged into the interface if they're not already there.
2.3.5. The Ecore "Big Picture"
Let's recap what we've covered so far.
1. Ecore, and its XMI serialization, is the center of the EMF world.
2. An Ecore model can be created from any of at least three sources: a UML
model, an XML Schema, or annotated Java interfaces.
3. Java implementation code and, optionally, other forms of the model can be
generated from an Ecore model.
We haven't talked about it yet, but there is one important advantage to using XML
Schema to define a model: given the schema, instances of the model can be serialized
to conform to it. Not surprisingly, in addition to simply defining the model, the XML
Schema approach is also specifying something about the persistent form of the
instances.
One question that comes to mind is whether there are other persistent model forms
possible. Couldn't we, for example, provide a relational database (RDB) Schema and
produce an Ecore model from it? Couldn't this RDB Schema also be used to specify](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-44-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
41 Peking University Software Engineering Insistute 2009
pattern for any model-like API. For example, the Document Object Model (DOM) is
like this and so is much of Eclipse. It's also a necessary pattern to support multiple
inheritance in Java.
The next thing to notice about each generated interface is that it extends directly or
indirectly from the base interface EObject like this:
public interface PurchaseOrder extends EObject {
EObject is the EMF equivalent of java.lang.Object; that is, it's the base of all modeled
objects. Extending EObject introduces three main behaviors:
1. eClass() returns the object's metaobject (an EClass).
2. eContainer() and eResource() return the object's containing object and
resource.
3. eGet(), eSet(), eIsSet(), and eUnset() provide an API for accessing the objects
reflectively.
The first and third items are interesting only if you want to generically access the
objects instead of, or in addition to, using the type-safe generated accessors. We'll
look at how this works in Sections 2.5.3 and 2.5.4. The second item is an integral part
of the persistence API that we will describe in Section 2.5.2.
Other than that, EObject has only a few convenience methods. However, there is one
more important thing to notice; EObject extends yet another interface:
public interface EObject extends Notifier {
The Notifier interface is also quite small, but it introduces an important characteristic
to every modeled object; model change notification as in the Observer design pattern
[3]. Like object persistence, notification is an important feature of an EMF object.
We'll look at EMF notification in more detail in Section 2.5.1.
Let's move on to the generated methods. The exact pattern that is used for any given
feature (i.e., attribute or reference) implementation depends on the type and other
user-settable properties. In general, the features are implemented as you'd expect.
For example, the get() method for the shipTo attribute simply returns an instance
variable like this:
public String getShipTo()
{
return shipTo;
}](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-46-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
43 Peking University Software Engineering Insistute 2009
The generated package (e.g., POPackage) provides convenient accessors for all the
Ecore metadata for the model. You might already have noticed, in the
implementation of setShipTo() shown earlier, the use of
POPackage.PURCHASE_ORDER__SHIP_TO, a static int constant representing the
shipTo attribute. The generated package also includes convenient accessors for the
EClasses, EAttributes, and EReferences. We'll look at the use of these accessors in
Section 2.5.3.
2.4.2. Other Generated "Stuff"
In addition to the interfaces and classes described in the previous section, the EMF
generator can optionally generate the following:
1. A skeleton adapter factory[10] class (e.g., POAdapterFactory) for the model.
This convenient base class can be used to implement adapter factories that
need to create type-specific adapters; for example, a PurchaseOrderAdapter
for PurchaseOrders, an ItemAdapter for Items, and so on.
[10] Adapters and adapter factories are described in Section 2.5.1.
2. A convenience switch class (e.g., POSwitch) that implements a "switch
statement"-like callback mechanism for dispatching based on an object's type
(i.e., its EClass). The adapter factory class, as just described, uses this switch
class in its implementation.
3. Plug-in manifest files and property files, so that the model can be used as an
Eclipse plug-in.
If all you're interested in is generating a model, this is the end of the story. However,
as we'll see in Chapters 3 and 4, the EMF generator can, using the EMF.Edit
extensions to the EMF core, generate adapter classes that enable viewing and
command-based, undoable editing of a model. It can even generate a complete
working editor for your model. We will talk more about EMF.Edit and its capabilities
in the following chapter. For now, we just stick to the basic modeling framework
itself.
2.4.3. Regeneration and Merge
The EMF generator produces files that are intended to be a combination of generated
pieces and handwritten pieces. You are expected to edit the generated classes to add
methods and instance variables. You can always regenerate from the model as
needed and your additions will be preserved during the regeneration.](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-48-320.jpg)
![EMF: Eclipse Modeling Framework 2nd
PERSONAL AND NON-COMMERCIAL USE LIMITATION
45 Peking University Software Engineering Insistute 2009
The EMF code generator uses a generator model to store this information. Like Ecore,
the generator model is itself an EMF model. Actually, a generator model provides
access to all of the data needed for generation, including the Ecore part, by wrapping
the corresponding Ecore model. That is, generator model classes are decorators [3] of
Ecore classes. For example, GenClass decorates EClass, GenFeature decorates
EAttribute and EReference, and so on.
The significance of all this is that the EMF generator runs off of a generator model
instead of an Ecore model; it's actually a generator model editor.[11] When you use the
generator, you'll be editing a generator model, which in turn indirectly accesses the
Ecore model from which you're generating. As you'll see in Chapter 4 when we walk
through an example of using the generator, there are two model resources (files) in
the project: an .ecore file and a .genmodel file. The .ecore file is an XMI serialization
of the Ecore model, as we saw in Section 2.3.3. The .genmodel file is a serialized
generator model with cross-document references to the .ecore file. Figure 2.6 shows
the conceptual picture.
[11] It is, in fact, an editor generated by EMF, like the ones we'll be looking at in
Chapter 4 and later in the book.
Figure 2.6. The .genmodel and .ecore files.
Separating the generator model from the Ecore model like this has the advantage
that the actual Ecore metamodel can remain pure and independent of any
information that is only relevant for code generation. The disadvantage of not storing
all the information right in the Ecore model is that a generator model might get out
of sync if the referenced Ecore model changes. To handle this, the generator model
elements are able to automatically reconcile themselves with changes to their
corresponding Ecore elements. Users don't need to worry about it.](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-50-320.jpg)
![Fig. 431.—Wooden scoop for baling water.
⅑ real size.
Another boat of red pine wood was discovered alongside it. This one
was laid on the field and covered with bog mould, until the work
connected with the other boat was finished. Unfortunately the war of
1864 put an end to the examination of the Nydam bog, so that the
boat was left lying on the field, and strangers have carried off many
pieces of it. The bottom plank was about 50 feet long, 13 inches
broad, and ends in two spurs or rams. How high the prows were
raised above the plank cannot be stated. Since this date the diggings
have been done by inexperienced men, and consequently have given
but little results. This sacred part of the land of the Danes had
passed into the hands of its German conquerors, for the Nornir[166]
are fickle, and what is fated to one generation to accomplish is
often, in the course of time, undone by another.
NYDAM BOG FIND.
Fig. 432.—The end of the bottom plank of
a vessel of red pine, with a ram at each](https://image.slidesharecdn.com/31600-250225094820-259532a1/85/EMF-Eclipse-Modeling-Framework-2nd-Edition-Dave-Steinberg-56-320.jpg)
EMF Eclipse Modeling Framework 2nd Edition Dave Steinberg
- 1. Visit https://ebookultra.com to download the full version and explore more ebooks EMF Eclipse Modeling Framework 2nd Edition Dave Steinberg _____ Click the link below to download _____ https://ebookultra.com/download/emf-eclipse-modeling- framework-2nd-edition-dave-steinberg/ Explore and download more ebooks at ebookultra.com
- 2. Here are some suggested products you might be interested in. Click the link to download An introduction to psycholinguistics 2nd Edition Danny D Steinberg https://ebookultra.com/download/an-introduction-to- psycholinguistics-2nd-edition-danny-d-steinberg/ Psycholinguistics Language Mind and World 2nd Edition Danny D. Steinberg https://ebookultra.com/download/psycholinguistics-language-mind-and- world-2nd-edition-danny-d-steinberg/ Eclipse First Edition Steve Holzner https://ebookultra.com/download/eclipse-first-edition-steve-holzner/ Eclipse of Reason Max Horkheimer https://ebookultra.com/download/eclipse-of-reason-max-horkheimer/
- 3. Development 1st Edition Laurence Steinberg https://ebookultra.com/download/development-1st-edition-laurence- steinberg/ EPZ Eclipse of Reason Max Horkheimer https://ebookultra.com/download/epz-eclipse-of-reason-max-horkheimer/ Why Switzerland 3rd Edition Jonathan Steinberg https://ebookultra.com/download/why-switzerland-3rd-edition-jonathan- steinberg/ Financial Peace University Member Workbook 2nd Edition Dave Ramsey https://ebookultra.com/download/financial-peace-university-member- workbook-2nd-edition-dave-ramsey/ LANGUAGE PROOF AND LOGIC 2nd Edition Dave Barker-Plummer https://ebookultra.com/download/language-proof-and-logic-2nd-edition- dave-barker-plummer/
- 5. EMF Eclipse Modeling Framework 2nd Edition Dave Steinberg Digital Instant Download Author(s): Dave Steinberg, Frank Budinsky, Marcelo Paternostro, Ed Merks ISBN(s): 9780321331885, 0321331885 Edition: 2 File Details: PDF, 6.47 MB Year: 2008 Language: english
- 7. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 2 Peking University Software Engineering Insistute 2009 EMF: Eclipse Modeling Framework, Second Edition by Dave Steinberg; Frank Budinsky; Marcelo Paternostro; Ed Merks Publisher: Addison-Wesley Professional Pub Date: December 16, 2008 Print ISBN-10: 0-321-33188-5 Print ISBN-13: 978-0-321-33188-5 Pages: 744 Slots: 1.0
- 8. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 3 Peking University Software Engineering Insistute 2009 Overview EMF: Eclipse Modeling Framework Dave Steinberg Frank Budinsky Marcelo Paternostro Ed Merks Series Editors: Erich Gamma • Lee Nackman • John Wiegand The Authoritative Guide to EMF Modeling and Code Generation The Eclipse Modeling Framework enables developers to rapidly construct robust applications based on surprisingly simple models. Now, in this thoroughly revised Second Edition, the project's developers offer expert guidance, insight, and examples for solving real-world problems with EMF, accelerating development processes, and improving software quality. This edition contains more than 40% new material, plus updates throughout to make it even more useful and practical. The authors illuminate the key concepts and techniques of EMF modeling, analyze EMF's most important framework classes and generator patterns, guide you through choosing optimal designs, and introduce powerful framework customizations and programming techniques. Coverage includes • Defining models with Java, UML, XML Schema, and Ecore • NEW: Using extended Ecore modeling to fully unify XML with UML and Java • Generating high-quality code to implement models and editors • Understanding and customizing generated code • Complete documentation of @model Javadoc tags, generator model properties, and resource save and load options • NEW: Leveraging the latest EMF features, including extended metadata, feature maps, EStore, cross-reference adapters, copiers, and content types • NEW: Chapters on change recording, validation, and utilizing EMF in stand-alone and Eclipse RCP applications • NEW: Modeling generics with Ecore and generating Java 5 code
- 9. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 4 Peking University Software Engineering Insistute 2009 About the Authors Dave Steinberg is a software developer in IBM Software Group. He has worked with Eclipse and modeling technologies since joining the company, and has been a committer on the EMF project since its debut in 2002. Frank Budinsky, a senior architect in IBM Software Group, is an original coinventor of EMF and a founding member of the EMF project at Eclipse. He is currently cochair of the Service Data Objects (SDO) specification technical committee at OASIS and lead SDO architect for IBM. Marcelo Paternostro is a software architect and engineer in IBM Software Group. He is an EMF committer and has been an active contributor to several other Eclipse projects. Before joining IBM, Marcelo managed, designed, and implemented numerous projects using Rational's tools and processes. Ed Merks is the project lead of EMF and a colead of the top-level Modeling project at Eclipse. He holds a Ph.D. in Computing Science and has many years of in-depth experience in the design and implementation of languages, frameworks, and application development environments. Ed works as a software consultant in partnership with itemis AG.
- 10. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 5 Peking University Software Engineering Insistute 2009 Table of Contents Copyright The Eclipse Series Foreword by Richard C. Gronback Foreword by Mike Milinkovich Preface Acknowledgments References Part I: EMF Overview Chapter 1. Eclipse Section 1.1. The Projects Section 1.2. The Eclipse Platform Section 1.3. More Information Chapter 2. Introducing EMF Section 2.1. Unifying Java, XML, and UML Section 2.2. Modeling vs. Programming Section 2.3. Defining the Model Section 2.4. Generating Code Section 2.5. The Runtime Framework Section 2.6. EMF and Modeling Standards Chapter 3. Model Editing with EMF.Edit Section 3.1. Displaying and Editing EMF Models Section 3.2. Item Providers Section 3.3. Command Framework Section 3.4. Generating EMF.Edit Code Chapter 4. Using EMF—A Simple Overview Section 4.1. Example Model: The Primer Purchase Order Section 4.2. Creating EMF Models and Projects Section 4.3. Generating Code Section 4.4. Running the Application Section 4.5. Continuing Development Part II: Defining EMF Models Chapter 5. Ecore Modeling Concepts Section 5.1. Ecore Model Uses Section 5.2. The Ecore Kernel Section 5.3. Structural Features Section 5.4. Behavioral Features Section 5.5. Classifiers Section 5.6. Packages and Factories Section 5.7. Annotations Section 5.8. Modeled Data Types Section 5.9. Ecore and User Models
- 11. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 6 Peking University Software Engineering Insistute 2009 Chapter 6. UML Section 6.1. UML Packages Section 6.2. UML Specification for Classifiers Section 6.3. UML Specification for Attributes Section 6.4. UML Specification for References Section 6.5. UML Specification for Operations Section 6.6. Documentation Section 6.7. Ecore Properties in Rational Rose Chapter 7. Java Source Code Section 7.1. Java Specification for Classes Section 7.2. Java Specification for Enumerated Types Section 7.3. Java Specification for Packages Section 7.4. Java Specification for Maps Section 7.5. Java Specification for Annotations Chapter 8. Extended Ecore Modeling Section 8.1. Feature Maps Section 8.2. Modeling with Feature Maps Chapter 9. XML Schema Section 9.1. Schema Section 9.2. Simple Type Definitions Section 9.3. Complex Type Definitions Section 9.4. Attribute Declarations Section 9.5. Element Declarations Section 9.6. Model Groups Section 9.7. Wildcards Section 9.8. Annotations Section 9.9. Predefined Schema Simple Types Section 9.10. EMF Extensions Part III: Using the EMF Generator Chapter 10. EMF Generator Patterns Section 10.1. Modeled Classes Section 10.2. Attributes Section 10.3. References Section 10.4. Feature Maps Section 10.5. Operations Section 10.6. Class Inheritance Section 10.7. Reflective Methods Section 10.8. Factories and Packages Section 10.9. Switch Classes and Adapter Factories Section 10.10. Alternative Generator Patterns Section 10.11. Customizing Generated Code Chapter 11. EMF.Edit Generator Patterns Section 11.1. Item Providers
- 12. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 7 Peking University Software Engineering Insistute 2009 Section 11.2. Item Provider Adapter Factories Section 11.3. Editor Section 11.4. Action Bar Contributor Section 11.5. Wizard Section 11.6. Plug-Ins Chapter 12. Running the Generators Section 12.1. EMF Code Generation Section 12.2. The Generator UI Section 12.3. Generator Model Properties Section 12.4. The Command-Line Generator Tools Section 12.5. The Generator Ant Tasks Section 12.6. The Template Format Chapter 13. Example—Implementing a Model and Editor Section 13.1. Getting Started Section 13.2. Generating the Model Section 13.3. Implementing Volatile Features Section 13.4. Implementing Data Types Section 13.5. Running the ExtendedPO2 Editor Section 13.6. Restricting Reference Targets Section 13.7. Splitting the Model into Multiple Packages Section 13.8. Editing Multiple Resources Concurrently Part IV: Programming with EMF Chapter 14. Exploiting Metadata Section 14.1. Packages Section 14.2. Reflection Section 14.3. Dynamic EMF Section 14.4. Extended Metadata Chapter 15. Persistence Section 15.1. Overview of the Persistence Framework Section 15.2. The EMF Persistence API Section 15.3. XML Resources Section 15.4. EMF Resource and Resource Factory Implementations Section 15.5. Performance Considerations Section 15.6. Custom Storage for Active Objects Chapter 16. Client Programming Toolbox Section 16.1. Tree Iterators and Switches Section 16.2. Adapters Section 16.3. Cross-Referencers Section 16.4. Copying Objects Section 16.5. Comparing Objects Chapter 17. The Change Model Section 17.1. Describing a Change Section 17.2. Change Recording
- 13. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 8 Peking University Software Engineering Insistute 2009 Chapter 18. The Validation Framework Section 18.1. Constraints and Invariants Section 18.2. Effects on Generated Code Section 18.3. Invoking Validation Section 18.4. Basic EObject Constraints Section 18.5. XML Schema Constraints Chapter 19. EMF.Edit Programming Section 19.1. Overriding Commands Section 19.2. Customizing Views Chapter 20. Outside of the Eclipse IDE Section 20.1. Rich Client Platform Section 20.2. Stand-Alone Applications Chapter 21. EMF 2.3 and 2.4 Section 21.1. Java 5.0 Support Section 21.2. EMF Persistence Enhancements Section 21.3. Other New Features Section 21.4. Resource Options Section 21.5. Generator Model Properties Appendix A. UML Notation Classes and Interfaces Enumerations and Data Types Class Relationships Appendix B. Summary of Example Models SimplePO PrimerPO ExtendedPO ExtendedPO1 ExtendedPO2 ExtendedPO3 Index
- 14. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 9 Peking University Software Engineering Insistute 2009 Editorial Reviews Product Description EMF: Eclipse Modeling Framework Dave Steinberg Frank Budinsky Marcelo Paternostro Ed Merks Series Editors: Erich Gamma • Lee Nackman • John Wiegand The Authoritative Guide to EMF Modeling and Code Generation The Eclipse Modeling Framework enables developers to rapidly construct robust applications based on surprisingly simple models. Now, in this thoroughly revised Second Edition, the project’s developers offer expert guidance, insight, and examples for solving real-world problems with EMF, accelerating development processes, and improving software quality. This edition contains more than 40% new material, plus updates throughout to make it even more useful and practical. The authors illuminate the key concepts and techniques of EMF modeling, analyze EMF’s most important framework classes and generator patterns, guide you through choosing optimal designs, and introduce powerful framework customizations and programming techniques. Coverage includes • Defining models with Java, UML, XML Schema, and Ecore • NEW: Using extended Ecore modeling to fully unify XML with UML and Java • Generating high-quality code to implement models and editors • Understanding and customizing generated code • Complete documentation of @model Javadoc tags, generator model properties, and resource save and load options • NEW: Leveraging the latest EMF features, including extended metadata, feature maps, EStore, cross-reference adapters, copiers, and content types • NEW: Chapters on change recording, validation, and utilizing EMF in stand-alone and Eclipse RCP applications • NEW: Modeling generics with Ecore and generating Java 5 code About the Authors
- 15. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 10 Peking University Software Engineering Insistute 2009 Dave Steinberg is a software developer in IBM Software Group. He has worked with Eclipse and modeling technologies since joining the company, and has been a committer on the EMF project since its debut in 2002. Frank Budinsky, a senior architect in IBM Software Group, is an original coinventor of EMF and a founding member of the EMF project at Eclipse. He is currently cochair of the Service Data Objects (SDO) specification technical committee at OASIS and lead SDO architect for IBM. Marcelo Paternostro is a software architect and engineer in IBM Software Group. He is an EMF committer and has been an active contributor to several other Eclipse projects. Before joining IBM, Marcelo managed, designed, and implemented numerous projects using Rational's tools and processes. Ed Merks is the project lead of EMF and a colead of the top-level Modeling project at Eclipse. He holds a Ph.D. in Computing Science and has many years of in-depth experience in the design and implementation of languages, frameworks, and application development environments. Ed works as a software consultant in partnership with itemis AG. Reader Reviews From Amazon (Ranked by 'Helpfulness') Average Customer Rating: based on 2 reviews. A fine survey of how to define models and solve real-world problems using EMF and software quality improvement, 2009-04-14 Reviewer rating: Libraries catering to Java and Eclipse programmers will find this second updated edition of "EMF: Eclipse Modeling Framework" a fine survey of how to define models and solve real-world problems using EMF and software quality improvement. From understanding and customizing code to using the latest EMF features and understanding the validation process, EMF is a key guide users will find accessible and enlightening, with project developers offering expertise and insights. Good book for advanced Java professional, 2009-01-16 Reviewer rating: If you use Eclipse for Java programming, this is the book for you. It is written by the experts for the experts. Borland, IBM, Oracle, SunMicro Systems, and many other firms continue to embrace Java. Financial houses on Wall Street continue to develop Java applications. The book will be better if a complete example can be given in more details.
- 16. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 11 Peking University Software Engineering Insistute 2009 Copyright Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and the publisher was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals. The authors and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein. The publisher offers excellent discounts on this book when ordered in quantity for bulk purchases or special sales, which may include electronic versions and/or custom covers and content particular to your business, training goals, marketing focus, and branding interests. For more information, please contact: U.S. Corporate and Government Sales (800) 382-3419 [email protected] For sales outside the United States please contact: International Sales [email protected] Visit us on the Web: informit.com/aw Library of Congress Cataloging-in-Publication Data: EMF : Eclipse Modeling Framework / Dave Steinberg ... [et al.]. p. cm. ISBN 0-321-33188-5 (pbk. : alk. paper) 1. Computer software--Development. 2 . Java (Computer program language) I. Steinberg, Dave. QA76.76.D47E55 2008 005.13'3--dc22 2007049160 Copyright © 2009 Pearson Education, Inc. All rights reserved. Printed in the United States of America. This publication is protected by copyright, and permission must be obtained from the publisher prior to any prohibited reproduction, storage in a retrieval system, or transmission in any form or by any means, electronic, mechanical, photocopying, recording, or likewise. For information regarding permissions, write to: Pearson Education, Inc Rights and Contracts Department 501 Boylston Street, Suite 900
- 17. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 12 Peking University Software Engineering Insistute 2009 Boston, MA 02116 Fax (617) 671 3447 This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/). ISBN-13: 978-0-321-33188-5 Text printed in the United States on recycled paper at Edwards Brothers in Ann Arbor, Michigan First printing December 2008
- 18. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 13 Peking University Software Engineering Insistute 2009 The Eclipse Series Series Editors Erich Gamma • Lee Nackman • John Wiegand Eclipse is a universal tool platform, an open extensible integrated development environment (IDE) for anything and nothing in particular. Eclipse represents one of the most exciting initiatives hatched from the world of application development in a long time, and it has the considerable support of the leading companies and organizations in the technology sector. Eclipse is gaining widespread acceptance in both the commercial and academic arenas. The Eclipse Series from Addison-Wesley is the definitive series of books dedicated to the Eclipse platform. Books in the series promise to bring you the key technical information you need to analyze Eclipse, high-quality insight into this powerful technology, and the practical advice you need to build tools to support this evolutionary Open Source platform. Leading experts Erich Gamma, Lee Nackman, and John Wiegand are the series editors. Titles in the Eclipse Series John Arthorne and Chris Laffra Official Eclipse 3.0 FAQs 0-321-26838-5 David Carlson Eclipse Distilled 0-321-28815-7 Eric Clayberg and Dan Rubel Eclipse Plug-ins, Third Edition 0-321-55346-2 Adrian Colyer, Andy Clement, George Harley, and Matthew Webster Eclipse AspectJ: Aspect-Oriented Programming with AspectJ and the Eclipse AspectJ Development Tools 0-321-24587-3 Naci Dai, Lawrence Mandel, and Arthur Ryman Eclipse Web Tools Platform: Developing Java™ Web Applications 0-321-39685-5
- 19. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 14 Peking University Software Engineering Insistute 2009 Erich Gamma and Kent Beck Contributing to Eclipse: Principles, Patterns, and Plug-Ins 0-321-20575-8 Jeff McAffer and Jean-Michel Lemieux Eclipse Rich Client Platform: Designing, Coding, and Packaging Java™ Applications 0-321-33461-2 Diana Peh, Nola Hague, and Jane Tatchell BIRT: A Field Guide to Reporting, Second Edition 0-321-58027-3 Dave Steinberg, Frank Budinsky, Marcelo Paternostro, and Ed Merks EMF: Eclipse Modeling Framework 0-321-33188-5 Jason Weathersby, Tom Bondur, Iana Chatalbasheva, and Don French Integrating and Extending BIRT, Second Edition 0-321-58030-3 For more information on books in this series visit www.awprofessional.com/series/eclipse Foreword by Richard C. Gronback Modeling can mean very different things to different people, even within the discipline of software engineering. Some will immediately think of the Unified Modeling Language (UML), others will think of Model-Driven Architecture (MDA), while others may remember the days of CASE tools. With increasing frequency, those familiar with the Eclipse community think of the Eclipse Modeling Framework (EMF), which provides a solid basis for application development through the use of pragmatic modeling and code generation facilities. From its beginnings within the Tools Project at Eclipse, EMF's reputation for high quality and unparalleled community support quickly led to several complementary modeling projects forming at Eclipse. Code generators, graphical diagramming frameworks, model transformation, validation, and search are just a few that have built upon EMF and now are contained within the Eclipse Modeling Project. The growth and success of this top-level project is due in large part to the strength of its core component, EMF. In many ways, the EMF project is a model for other Eclipse projects (pun intended). From the tireless efforts of its committers in answering questions on the project's
- 20. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 15 Peking University Software Engineering Insistute 2009 newsgroup, to the professionalism and openness of its development in terms of API, features, performance, and documentation, EMF is a tough act to follow. The diversity of the Modeling community that has grown up around EMF makes it a poster child for collaboration, including individual contributors, commercial vendors, and academic institutions. Further evidence of EMF's value to Eclipse is its anticipated use in e4, the next Eclipse platform. At present, e4 developers have plans to leverage the capabilities of EMF to provide a consistent model-based foundation and runtime; clearly, a step forward for model-driven software development. With so much technology built upon EMF, understanding its architecture and capabilities are essential to using it successfully. For years, the first edition of this book has been an important resource for many developers building their applications with EMF and extending EMF's own capabilities. With the introduction of this second edition, the many enhancements made to EMF in the interim are now documented and able to be leveraged effectively. The API section has been replaced by new chapters covering EMF persistence, client programming, change recording, validation, and Rich Client Platform (RCP) development. In addition to updating the original material, this new edition covers the latest features of EMF versions 2.3 and 2.4, including generics, content types, and REST APIs. It is a most welcome second edition. I hope you find this second edition as valuable as I do. Richard C. Gronback Chief Scientist, Borland Software Corporation November 2008
- 21. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 16 Peking University Software Engineering Insistute 2009 Foreword by Mike Milinkovich The Eclipse Modeling Framework is an exemplary open source project in many respects. We at the Eclipse Foundation have a number of ways to value the contributions of any one project to our community. Our criteria include industry adoption, robust technology, stability as an extensible platform, and open and transparent project leadership. In all of these ways and more, EMF has for many years been one of the very best of Eclipse. With respect to industry adoption, I have often marveled at the amazing success of EMF. A large part of my role at the Eclipse Foundation is to travel and speak with adopters of Eclipse technology. Whether I am speaking to startups, enterprises or established software vendors, everywhere I go EMF is on the list of key Eclipse technologies being used. Its ability to simplify the development of complex software applications and products has been widely recognized. Rarely has a single framework driven so much developer productivity in so many domains. This adoption has largely been driven by a very simple value proposition: EMF is great technology. Careful attention has been paid to EMF's architecture, the completeness of its APIs, its flexibility, and its performance. And performance is key for any technology that is going to be used in real world applications. As a platform, EMF has transformed the modeling tools industry. Leading model tools vendors such as Borland and IBM have based their products on EMF, making a strategic decision that EMF is their core modeling framework of the future. Almost every new modeling product that I have seen over the past four years has been based on EMF. So, EMF has clearly seen enormous adoption in the industry, but that is only half the story. We look at EMF as a community success story as well. The EMF team has always done an excellent job of interacting with community. Ed Merks, the leader of the project and one of the authors of this book, is famous throughout the Eclipse community for his prompt responses to any adopter's inquiry about EMF. That leadership-by-example has resulted in the entire EMF team being one of the most community-focused at Eclipse. EMF is an enormous Eclipse community success story and I am certain that this book will help further that success. Mike Milinkovich Executive Director, Eclipse Foundation November 2008
- 22. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 17 Peking University Software Engineering Insistute 2009 Preface This book is a comprehensive introduction and developer's guide to the Eclipse Modeling Framework (EMF). EMF is a powerful framework and code generation facility for building Java applications based on simple model definitions. Designed to make modeling practical and useful to the mainstream Java programmer, EMF unifies three important technologies: Java, XML, and UML. Models can be defined using a UML modeling tool or an XML Schema, or even by specifying simple annotations on Java interfaces. In this last case, the developer writes just a subset of abstract interfaces that describe the model, and the rest of the code is generated automatically and merged back in. By relating modeling concepts to the simple Java representations of those concepts, EMF has successfully bridged the gap between modelers and Java programmers. It serves as a gentle introduction to modeling for Java programmers and at the same time as a reinforcement of the modeler's theory that a great deal of coding can be automated, given an appropriate tool. This book shows how EMF is such a tool. It also shows how using EMF lets you do more with your models that you might have thought possible. EMF provides a runtime framework that allows any modeled data to be easily validated, persisted, and edited in a UI. Change notification and recording are supported automatically. Metadata is available to enable generic processing of any data using a uniform, reflective API. With all of these features and more, EMF is the foundation for data sharing and fine-grained interoperability among tools and applications in Eclipse, in much the same way that Eclipse is itself a platform for integration at the component and UI level. Numerous organizations are currently using Eclipse, EMF, and the growing number of EMF-based technologies in the Eclipse Modeling Project as the foundation for their own commercial and open source offerings. This book assumes the reader is familiar with object-oriented programming concepts and specifically with the Java programming language. Previous exposure to modeling technologies such as UML, although helpful, is not required. Part I (Chapters 1 to 4) provides a basic overview of the most important concepts in EMF and modeling. This part teaches someone with basic Java programming skills everything needed to start using EMF to model and build an application. Part II (Chapters 5 to 9) presents a thorough overview of EMF's metamodel, Ecore, followed by details of the mappings between Ecore and the other supported model-definition forms: UML, annotated Java, and XML Schema. Part III (Chapters 10 to 13) includes detailed analyses of EMF's code generator patterns and tools, followed by an
- 23. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 18 Peking University Software Engineering Insistute 2009 end-to-end example of a non-trivial EMF application. Finally, Part IV (Chapters 14 to 21) takes a close look at EMF's runtime framework and discusses important EMF programming techniques. The bulk of this book is based on EMF 2.2, the last version to support the venerable Java 1.4 language. In version 2.3, EMF adopted key language features of Java 5.0, making it incompatible with previous Java runtimes. EMF 2.2, which was current while much of this book was written, is therefore still popular and an excellent base for learning about the framework. The code in Chapters 1 to 20 is based on that version, but due to EMF's backward compatibility, all examples run without change on version 2.4, the latest at the time of this book's release. Chapter 21 focuses specifically on changes in EMF 2.3 and 2.4 and, as such, uses 2.4 as the basis for its examples. Conventions Used in This Book The following formatting conventions are used throughout this book: Bold— Used for the names of model elements, such as packages, classes, attributes, and references; and of user-interface elements, including menus, buttons, tabs, and text boxes. Italic— Used for filenames and URIs, as well as for placeholder text that is meant to be replaced by a particular name. New terms are often italicized for emphasis. Also, in Chapter 9's example mappings, items shown purely to provide context appear in italics. Courier— Used for all code samples and for in-text references to code elements, including the names of Java packages, classes, interfaces, methods, fields, variables, and keywords. Plug-in names, command lines, and elements of non-Java files, including XML, also appear in this font. Courier Bold— Used to emphasize portions of code samples, usually new insertions or changes. Courier Strikethrough— Used in code samples to indicate that text should be deleted. Online Examples The Web site for this book is located at http://www.informit.com/title/9780321331885. All of the example models and code used throughout this book can be downloaded from there. The site will also provide an errata list, and other news related to the book.
- 24. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 19 Peking University Software Engineering Insistute 2009 Eclipse and EMF are required to use the examples. You can download one of several Eclipse packages (we recommend Eclipse Classic) at http://www.eclipse.org/downloads/ and the all-in-one EMF SDK at http://www.eclipse.org/modeling/emf/downloads/. Acknowledgments This book would not have been possible without the contributions of many people. First and foremost, we must thank those who reviewed our early drafts, pointed out our errors, and helped us improve our writing with their thoughtful feedback: Chris Aniszczyk, Chris Daly, Kenn Hussey, Elena Litani, and Kevin Williams. Kenn and Elena, in particular, also deserve acknowledgement for their major contributions to EMF as committers on the project. We also thank Stefan Baramov and Reinhold Bihler for their feedback on the Rough Cuts version of the book. We are grateful to Richard Gronback and Mike Milinkovich for their kind and insightful Forewords. A big thanks also goes to Greg Doench and Michelle Housley at Pearson, and to our production manager Mary Sudul, for their skill and patience in steering us through this process. Of course, there are many more people who have contributed to EMF, and without them, this book would have been much shorter and not nearly as interesting. Thanks to Lucas Bigeardel, Boris Bokowski, Nick Boldt, Steve Brodsky, Cedric Brun, Ian Bull, Christian Damus, Dmitry Denisov, Raymond Ellersick, Tim Grose, Michael Hanner, Anthony Hunter, Sridhar Iyengar, Bernd Kolb, Daniel Leroux, Kim Letkeman, Martin Nally, Frederic Plante, Bertrand Portier, Barbara Price, Tom Schindl, David Sciamma, Neil Skrypuch, Eike Stepper, and Martin Taal. EMF truly is a community effort, and there are countless members of the community who have contributed in various ways. It would be impossible to name them all, but we are deeply appreciative of everyone who has reported bugs, offered patches, provided feedback, written articles, answered other users' questions, promoted EMF, and created or contributed to related components in the Eclipse Modeling Project. Thanks also to the wider Eclipse community, and to all the talented people at the Eclipse Foundation who have nurtured and supported it. Finally, we wish to express our love and appreciation to our partners, spouses, and families. Writing this book was no small task, and we couldn't have done it without their support.
- 25. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 20 Peking University Software Engineering Insistute 2009 References [1] "Eclipse Platform Technical Overview." Object Technology International, Inc., February 2003, http://www.eclipse.org/whitepapers/eclipse-overview.pdf. [2] "XML Schema Part 0: Primer," Second Edition. W3C, October 2004, http://www.w3.org/TR/xmlschema-0/. [3] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, 1995. [4] J. Bloch. Effective Java Programming Language Guide. Addison-Wesley, Reading, MA, 2001. [5] "Namespaces in XML 1.0," Second Edition. W3C, August 2006, http://www.w3.org/TR/2006/REC-xml-names-20060816/. [6] J. Gosling, B. Joy, G. Steele, and G. Bracha. The Java Language Specification, Third Edition. Addison-Wesley, 2005. [7] "XML Schema Part 2: Datatypes," Second Edition. W3C, October 2004, http://www.w3.org/TR/xmlschema-2/. [8] "XML Schema Part 1: Structures," Second Edition. W3C, October 2004, http://www.w3.org/TR/xmlschema-1/.
- 26. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 21 Peking University Software Engineering Insistute 2009 Part I: EMF Overview Chapter 1. Eclipse Before we can begin to describe the Eclipse Modeling Framework (EMF), a basic introduction to Eclipse would seem in order. If you're already familiar with Eclipse, you can skip this chapter and go straight to Chapter 2, which is the "real" Chapter 1 from the EMF perspective. Eclipse is an open source software project, the purpose of which is to provide a highly integrated tool platform. The work in Eclipse includes a core project, which includes a generic framework for tool integration, and a Java development environment built using it. Other projects extend the core framework to support specific kinds of tools and development environments. The projects in Eclipse are implemented in Java and run on many operating systems including Windows, Mac OSX, and Linux. By involving committed and enthusiastic developers in an environment organized to facilitate the free exchange of technology and ideas, Eclipse is hoping to create the best possible integration platform. The software produced by Eclipse is made available under the Eclipse Public License (EPL), which contains a good deal of legalese, but in loose terms permits you to use, modify, and redistribute the software for free, and also to distribute it alongside proprietary components as part of a commercial product. The EPL is Open Source Initiative (OSI)-approved and recognized by the Free Software Foundation as a free software license. Any software contributed to Eclipse must also be licensed under the EPL. The development of Eclipse is overseen by the Eclipse Foundation, an independent, non-profit organization. The foundation's membership includes more than 100 companies that support Eclipse and provide commercial Eclipse-based offerings, as well as individual code committers without corporate representation. The Eclipse Foundation operates in accordance with a series of bylaws and a development process that define the roles and responsibilities of the various participants including the Board of Directors, the Eclipse Management Organization, the Project Management Committees, the membership, and users and developers of Eclipse. 1.1. The Projects The development work in Eclipse is divided into numerous top-level projects, including the Eclipse Project, the Modeling Project, the Tools Project, and the Technology Project. The Eclipse Project contains the core components needed to develop using Eclipse. Its components are essentially fixed and downloadable as a
- 27. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 22 Peking University Software Engineering Insistute 2009 single unit referred to as the Eclipse Software Development Kit (SDK). The components of the other projects are used for specific purposes and are generally independent and downloaded individually. New projects are created and new components are added to existing projects on an ongoing basis. 1.1.1. The Eclipse Project The Eclipse Project supports the development of a platform, or framework, for the implementation of integrated development environments (IDEs) and other applications. The Eclipse framework is implemented using Java but is used to implement development tools for other languages as well (e.g., C++, XML, etc.). The Eclipse Project itself is divided into four main subprojects: Equinox, the Platform, the Java Development Tools (JDT), and the Plug-in Development Environment (PDE). Collectively, the four subprojects provide everything needed to extend the framework and develop tools based on Eclipse. Equinox and the Platform are the core components of Eclipse and, together, are considered by many to be Eclipse. Equinox is an implementation of the OSGi R4 core framework specification,[1] which provides the component model on which all of Eclipse is based. The Platform defines additional core frameworks and services required to support the integration of tools. These services include, among others, a standard workbench user interface and mechanisms for managing projects, files, and folders. We describe the platform in more detail in Section 1.2. [1] The OSGi specifications are available at http://www2.osgi.org/Specifications/HomePage. The JDT is a full-function Java development environment built using Eclipse. Its tools are highly integrated and representative of the power of the Eclipse Platform. It can be used to develop Java programs for Eclipse or other target platforms. The JDT is even used to develop the Eclipse Project itself. The PDE provides views and editors to facilitate the creation of plug-ins for Eclipse. The PDE builds on and extends the JDT by providing support for the non-Java parts of the plug-in development activity, such as registering plug-in extensions, and so on. 1.1.2. The Modeling Project The Eclipse Modeling Project is the focal point for the evolution and promotion of model-based development technologies at Eclipse. At its core is EMF, the subject of this book, which provides the basic framework for modeling. Other modeling sub-projects build on top of the EMF core, providing such capabilities as model tranformation, database integration, and graphical editor generation. Also included
- 28. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 23 Peking University Software Engineering Insistute 2009 are a number of implementations of important modeling standards. For example, the UML2 project provides an EMF-based implementation of the UML 2.x metamodel. 1.1.3. The Tools Project The Eclipse Tools Project develops a wide range of exemplary, extensible development tools based on the Eclipse Platform. It includes a rather broad range of sub-projects. Some provide tools for working with other languages, including C/C++, COBOL, and PHP. Others, like the Graphical Editing Framework (GEF), provide common support for larger categories of Eclipse tools. EMF also began its life as a part of the Tools Project, before the Modeling Project was formed. 1.1.4. The Technology Project The Eclipse Technology Project provides an opportunity for researchers, academics, and educators to become involved in the ongoing evolution of Eclipse. This project serves as a temporary home for new or experimental work, which may reach its natural conclusion or move into another project on reaching maturity. The other top-level projects may also contain so-called incubator projects for this purpose. 1.1.5. Other Projects A growing number of other projects support and provide more specialized types of tools. These include the Data Tools Platform Project, the Device Software Development Platform Project, and the Eclipse Web Tools Platform Project, to name just a few. 1.2. The Eclipse Platform The Eclipse Platform is a framework for building IDEs. It's been described as "an IDE for anything, and nothing in particular,"[1] which is pretty much the way you could think of any framework. It simply defines the basic structure of an IDE. Specific tools extend the framework and are plugged into it to define a particular IDE collectively. In fact, the architecture of the platform allows for a subset of its components to be used to help build just about any application at all. 1.2.1. Plug-In Architecture In Eclipse, the basic unit of function, or a component, is called a plug-in. The Eclipse Platform itself and the tools that extend it are both composed of plug-ins. A simple tool might consist of a single plug-in, but more complex tools are typically divided into several. Each plug-in contributes functionality that can be invoked by the user or reused and extended by other plug-ins.
- 29. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 24 Peking University Software Engineering Insistute 2009 The platform runtime engine is responsible for discovering and running plug-ins. It is implemented atop the OSGi Service Platform, which provides a flexible, standard component framework allowing plug-ins to be installed and removed without restarting the platform. The OSGi term for a component is bundle, so you will often see this term used interchangeably with plug-in. From a packaging perspective, a plug-in includes everything needed to run the component, such as Java code, images, translated text, and the like. It also includes two manifest files.[2] The OSGi bundle manifest file, named META-INF/MANIFEST.MF, identifies the plug-in and provides, among other things, dependency information. It includes the following: [2] The OSGi-based runtime was introduced in Eclipse 3.0. Prior to this, a single plug-in manifest file was used. For backward compatibility, the Eclipse Platform and EMF still support this simpler, but less flexible, approach. Required bundles. Its dependencies on other plug-ins. Exported packages. The packages that it makes visible to other plug-ins. The plug-in manifest file, named plugin.xml, declares the interconnections to other plug-ins. It can define the following: Extension points. Declarations of functionality that it makes available to other plug-ins. Extensions. Use (implementation) of other plug-ins' extension points. The platform runtime manages the life cycle of the plug-ins and matches extensions with their corresponding extension points. It uses class loaders to enforce the visibility declared in the manifest files and provides a registry that plug-ins can consult to discover the extensions to their extension points. 1.2.2. Workspace Resources Integrated Eclipse tools work with ordinary files and folders, but they use a higher level application programming interface (API) based on resources, projects, and a workspace. A resource is the Eclipse representation of a file or folder that provides the following additional capabilities: 1. Change listeners can be registered to receive resource change notifications (called resource deltas). 2. Markers, such as error messages or to-do lists, can be added to a resource. 3. The previous content, or history, of a resource can be tracked. A project is a special folder-type resource that maps to a user-specified folder in the underlying file system. The subfolders of the project are the same as in the physical
- 30. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 25 Peking University Software Engineering Insistute 2009 file system, but projects are top-level folders in the user's virtual project container, called the workspace. Projects can also be tagged with a particular personality, called a nature. For example, the Java nature is used to indicate that a project contains the source code for a Java program. 1.2.3. Platform UI The Eclipse user interface (UI) framework, known as Platform UI, consists of two general-purpose toolkits, SWT and JFace; and a customizable workbench UI structure. Platform UI also provides a workbench instantiation configured for use as an IDE. SWT Standard Widget Toolkit (SWT) is an operating system (OS)-independent widget set and graphics library, implemented using native widgets wherever possible. This is unlike Java's Abstract Window Toolkit (AWT), which provides a native implementation only for low-level widgets like lists, text fields, and buttons (i.e., the lowest common denominator of all the OSs), and defers to Swing's emulated widgets for the rest. In SWT, emulated widgets are only used where no native implementation is possible, resulting in a portable API with as much native look and feel as possible. JFace JFace is a higher level toolkit, implemented using SWT. It provides classes to support common UI programming tasks such as managing image and font registries, dialog boxes, wizards, progress monitors, and so on. The JFace API does not hide SWT, but rather works with and expands on it. A particularly valuable part of JFace is its set of standard viewer classes. Viewer classes for lists, trees, and tables work with corresponding SWT widgets, but provide a higher level connection to the data they're displaying. For example, they include convenient mechanisms for populating themselves from a data model and for keeping themselves in sync with changes to the model. Another widely used part of JFace is its action framework, which is used to add commands to menus and toolbars. The framework allows you to create an action (to implement a user command), and then contribute the action to a toolbar, menu bar, or context menu. You can even reuse the same action in all three places.
- 31. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 26 Peking University Software Engineering Insistute 2009 Workbench The workbench is the main window that the user sees when running the Eclipse IDE, or any other Eclipse-based application; it's sometimes referred to as the Eclipse desktop.[3] It is itself implemented using SWT and JFace. [3] Although primarily intended for graphical user interface (GUI)-based development, the Eclipse Platform can also be used to implement non-GUI applications by running a "headless" workbench. A workbench window is composed primarily of editors and views. Eclipse editors work in the usual way, but they are integrated into the workbench window instead of launched externally in their own window. Views are used to present more, or different, information about the contents of the active editor or about the object selected in an editor or another view. Typically, only one instance of a view can exist at a time, and it is immediately updated based on the state of the workbench. Likewise, any changes made in a view typically take effect immediately, without requiring a save action. When activated, editors and views can contribute actions to the workbench's menus and toolbar. The arrangement of views and editors in the workbench window can be customized to suit a role or task. A particular default arrangement is called a perspective in Eclipse. The user can change the arrangement of a perspective and save the result for future use. The primary way to extend the Eclipse Platform is using extension points provided by the workbench. These extension points allow tools to add new editors, views, or perspectives to the workbench. Tools can also customize existing editors, views, or perspectives for their own purposes. IDE The IDE is an instantiation of the generic workbench described earlier. It configures the workbench with appropriate views, editors, and perspectives for an IDE. For example, the IDE provides a Navigator view, based on the workspace model, for navigating the tree of resources in the workspace and for performing common actions on those resources, like deletion, copying, and renaming. The IDE also provides IDE-specific menu and toolbar items, preference pages, and other extensions. 1.2.4. Rich Client Platform
- 32. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 27 Peking University Software Engineering Insistute 2009 The Eclipse Platform provides so much useful functionality that it would be a shame if much of it couldn't be reused outside of the context of an IDE. Fortunately, the Eclipse Rich Client Platform (RCP) allows exactly this kind of reuse. RCP refers to the minimal set of plug-ins needed to build a rich client application. Such applications are still based on a dynamic plug-in model, and have workbench-based UIs built on SWT and JFace. However, they specify their own workbench configuration and typically do not require the workspace resource model. There are a number of other components provided by the Eclipse Platform that can be used by RCP applications, including the standard Outline and Property views, the help system, the update manager, text editors, and the welcome page. EMF is also well suited for use in RCP applications, as Chapter 20 details. 1.3. More Information If you want to learn more about Eclipse, you can visit the Eclipse Web site at http://www.eclipse.org/. There you will find plenty of detailed information—technical, organizational, and legal. You can download the software, sign up to join user newsgroups, or even find out how to participate in the projects. Eclipse is an open source project, the very success of which depends on the active participation of a vibrant user community.
- 33. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 28 Peking University Software Engineering Insistute 2009 Chapter 2. Introducing EMF Simply put, the Eclipse Modeling Framework (EMF) is a modeling framework that exploits the facilities provided by Eclipse. By now, you probably know what Eclipse is, given that you either just read Chapter 1, or you skipped it, presumably because you already knew what it was. You also probably know what a framework is, because you know what Eclipse is, and Eclipse is itself a framework. So, to understand what EMF really is, all you need to know is one more thing: What is a model? Or better yet, what do we mean by a model? If you're familiar with things like class diagrams, collaboration diagrams, state diagrams, and so on, you're probably thinking that a model is a set of those things, probably defined using Unified Modeling Language (UML), the standard notation for them. You might be imagining a higher level description of an application from which some, or all, of the implementation can be generated. Well, you're right about what a model is, but not exactly about EMF's spin on it. Although the idea is the same, a model in EMF is less general and not quite as high level as the commonly accepted interpretation. EMF doesn't require a completely different methodology or any sophisticated modeling tools. All you need to get started with EMF are the Eclipse Java Development Tools. As you'll see in the following sections, EMF relates modeling concepts directly to their implementations, thereby bringing to Eclipse—and Java developers in general—the benefits of modeling with a low cost of entry. 2.1. Unifying Java, XML, and UML To help understand what EMF is about, let's start with a simple Java programming example. Say that you've been given the job of writing a program to manage purchase orders for some store or supplier.[1] You've been told that a purchase order includes a "bill to" and "ship to" address, and a collection of (purchase) items. An item includes a product name, a quantity, and a price. "No problem," you say, and you proceed to create the following Java interfaces: [1] If you've read much about XML Schema, you'll probably find this example quite familiar, as it's based on the well-known example from the World Wide Web Consortium's XML Schema primer [2]. We've simplified it here, but in Chapter 4 we'll step up to the real thing. public interface PurchaseOrder { String getShipTo(); void setShipTo(String value);
- 34. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 29 Peking University Software Engineering Insistute 2009 String getBillTo(); void setBillTo(String value); List getItems(); // List of Item } public interface Item { String getProductName(); void setProductName(String value); int getQuantity(); void setQuantity(int value); float getPrice(); void setPrice(float value); } Starting with these interfaces, you've got what you need to begin writing the application UI, persistence, and so on. Before you start to write the implementation code, your boss asks you, "Shouldn't you create a 'model' first?" If you're like other Java programmers we've talked to, who didn't think that modeling was relevant to them, then you'd probably claim that the Java code is the model. "Describing the model using some formal notation would have no added value," you say. Maybe a class diagram or two would fill out the documentation a bit, but other than that it simply doesn't help. So, to appease the boss, you produce the UML diagram shown in Figure 2.1.[2] [2] If you're unfamiliar with UML and are wondering what things like the little black diamond mean, Appendix A provides a brief overview of the notation. Figure 2.1. UML diagram of interfaces.
- 35. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 30 Peking University Software Engineering Insistute 2009 Then you tell the boss to go away so you can get down to business. (As you'll see later, if you had been using EMF, you would already have avoided this unpleasant little incident with the boss.) Next, you start to think about how to persist this "model." You decide that storing the model in an XML file would be a good solution. Priding yourself on being a bit of an XML expert, you decide to write an XML Schema to define the structure of your XML document: <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:po="http://www.example.com/SimplePO" targetNamespace="http://www.example.com/SimplePO"> <xsd:complexType name="PurchaseOrder"> <xsd:sequence> <xsd:element name="shipTo" type="xsd:string"/> <xsd:element name="billTo" type="xsd:string"/> <xsd:element name="items" type="po:Item" minOccurs="0" maxOccurs="unbounded"/> </xsd:sequence> </xsd:complexType> <xsd:complexType name="Item"> <xsd:sequence> <xsd:element name="productName" type="xsd:string"/> <xsd:element name="quantity" type="xsd:int"/> <xsd:element name="price" type="xsd:float"/> </xsd:sequence> </xsd:complexType> </xsd:schema> Before going any further, you notice that you now have three different representations of what appears to be pretty much (actually, exactly) the same thing: the "data model" of your application. Looking at it, you start to wonder if you could have written only one of the three (i.e., Java interfaces, UML diagram, or XML Schema), and generated the others from it. Even better, you start to wonder if maybe there's even enough information in this "model" to generate the Java implementation of the interfaces. This is where EMF comes in. EMF is a framework and code generation facility that lets you define a model in any of these forms, from which you can then generate the others and also the corresponding implementation classes. Figure 2.2 shows how EMF unifies the three important technologies: Java, XML, and UML. Regardless of
- 36. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 31 Peking University Software Engineering Insistute 2009 which one is used to define it, an EMF model is the common high-level representation that "glues" them all together. Figure 2.2. EMF unifies Java, XML, and UML. Imagine that you want to build an application to manipulate some specific XML message structure. You would probably be starting with a message schema, wouldn't you? Wouldn't it be nice to be able to take the schema, press a button or two, and get a UML class diagram for it? Press another button, and you have a set of Java implementation classes for manipulating the XML. Finally, press one more button, and you can even generate a working editor for your messages. All this is possible with EMF, as you'll see when we walk through an example similar to this in Chapter 4. If, on the other hand, you're not an XML Schema expert, you might choose to start with a UML diagram, or simply a set of Java interfaces representing the message structure. The EMF model can just as easily be defined using either of them. If you want, you can then have an XML Schema generated for you, in addition to the implementation code. Regardless of how the EMF model is provided, the power of the framework and generator will be the same. 2.2. Modeling vs. Programming So is EMF simply a framework for describing a model and then generating other things from it? Well, basically yes, but there's an important difference. Unlike most tools of this type, EMF is truly integrated with and tuned for efficient programming. It answers the often-asked question, "Should I model or should I program?" with a resounding, "Both." "To model or to program, that is not the question."
- 37. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 32 Peking University Software Engineering Insistute 2009 How's that for a quote? With EMF, modeling and programming can be considered the same thing. Instead of forcing a separation of the high-level engineering and modeling work from the low-level implementation programming, it brings them together as two well-integrated parts of the same job. Often, especially with large applications, this kind of separation is still desirable, but with EMF the degree to which it is done is entirely up to you. Why is modeling interesting in the first place? Well, for starters it gives you the ability to describe what your application is supposed to do (presumably) more easily than with code. This in turn can give you a solid, high-level way both to communicate the design and to generate part, if not all, of the implementation code. If you're a hard-core programmer without a lot of faith in the idea of high-level modeling, you should think of EMF as a gentle introduction to modeling, and the benefits it implies. You don't need to step up to a whole new methodology, but you can enjoy some of the benefits of modeling. Once you see the power of EMF and its generator, who knows, we might even make a modeler out of you yet! If, on the other hand, you have already bought into the idea of modeling, and even the Model Driven Architecture (MDA) big picture,[3] you should think of EMF as a technology that is moving in that direction, but more slowly than immediate widespread adoption. You can think of EMF as MDA on training wheels. We're definitely riding the bike, but we don't want to fall down and hurt ourselves by moving too fast. The problem is that high-level modeling languages need to be learned, and because we're going to need to work with (e.g., debug) generated Java code anyway, we now need to understand the mapping between them. Except for specific applications where things like state diagrams, for example, can be the most effective way to convey the behavior, in the general case, good old-fashioned Java programming is the simplest and most direct way to do the job. [3] MDA is described in Section 2.6.4. From the last two paragraphs, you've probably surmised that EMF stands in the middle between two extreme views of modeling: the "I don't need modeling" crowd, and the "Modeling rules!" crowd. You might be thinking that being in the middle implies that EMF is a compromise and is reduced to the lowest common denominator. You're right about EMF being in the middle and requiring a bit of compromise from those with extreme views. However, as the designers of EMF, we truly feel that its exact position in the middle represents the right level of modeling at this point in the evolution of software development technology. We believe that EMF mixes just the right amount of modeling with programming to maximize the effectiveness of both. We must admit, though, that standing in the middle and arguing out of both sides of our mouths can get tiring!
- 38. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 33 Peking University Software Engineering Insistute 2009 What is this right balance between modeling and programming? An EMF model is essentially the Class Diagram subset of UML; that is, a simple model of the classes, or data, of the application. From that, a surprisingly large portion of the benefits of modeling can be had within a standard Java development environment. With EMF, there's no need for the user, or other development tools (e.g., a debugger), to understand the mapping between a high-level modeling language and the generated Java code. The mapping between an EMF model and Java is natural and simple for Java programmers to understand. At the same time, it's enough to support fine-grained data integration between applications; next to the productivity gain resulting from code generation, this is one of the most important benefits of modeling. 2.3. Defining the Model Let's put aside the philosophy for now and take a closer look at what we're really describing with an EMF model. We saw in Section 2.1 that our conceptual model could be defined in several different ways; that is, in Java, UML, or XML Schema. But, what exactly are the common concepts we're talking about when describing a model? Let's look at our purchase order example again. Recall that our simple model included the following: 1. PurchaseOrder and Item, which in UML and Java map to class definitions, but in XML Schema map to complex type definitions. 2. shipTo, billTo, productName, quantity, and price, which map to attributes in UML, get()/set() method pairs (or bean properties, if you want to look at it that way) in Java, and in the XML Schema are nested element declarations. 3. items, which is a UML association end or reference, a get() method in Java, and in XML Schema, a nested element declaration of another complex type. As you can see, a model is described using concepts that are at a higher level than simple classes and methods. Attributes, for example, represent pairs of methods, and as you'll see when we look deeper into the EMF implementation, they also have the ability to notify observers (e.g., UI views) and be saved to, and loaded from, persistent storage. References are more powerful yet, because they can be bidirectional, in which case referential integrity is maintained. References can also be persisted across multiple resources (documents), where demand load and proxy resolution come into play. To define a model using these kinds of "model parts" we need a common terminology to describe them. More important, to implement the EMF tools and generator, we also need a model for the information. We need a model for describing EMF models; that is, a metamodel. 2.3.1. The Ecore (Meta) Model
- 39. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 34 Peking University Software Engineering Insistute 2009 The model used to represent models in EMF is called Ecore. Ecore is itself an EMF model, and thus is its own metamodel. You could say that makes it a meta-metamodel. People often get confused when talking about meta-metamodels (metamodels in general, for that matter), but the concept is actually quite simple. A metamodel is simply the model of a model, and if that model is itself a metamodel, then the metamodel is in fact a meta-metamodel.[4] Got it? If not, don't worry about it, as it's really just an academic issue anyway. [4] This concept can recurse into meta-meta-metamodels, and so on, but we won't go there. A simplified subset of the Ecore metamodel is shown in Figure 2.3. This diagram only shows the parts of Ecore needed to describe our purchase order example, and we've taken the liberty of simplifying it a bit to avoid showing base classes. For example, in the real Ecore metamodel the classes EClass, EAttribute, and EReference share a common base class, ENamedElement, which defines the name attribute that here we've shown explicitly in the classes themselves. Figure 2.3. A simplified subset of the Ecore metamodel. As you can see, there are four Ecore classes needed to represent our model: 1. EClass is used to represent a modeled class. It has a name, zero or more attributes, and zero or more references. 2. EAttribute is used to represent a modeled attribute. Attributes have a name and a type. 3. EReference is used to represent one end of an association between classes. It has a name, a boolean flag to indicate if it represents containment, and a reference (target) type, which is another class. 4. EDataType is used to represent the type of an attribute. A data type can be a primitive type like int or float or an object type like java.util.Date. Notice that the names of the classes correspond most closely to the UML terms. This is not surprising because UML stands for Unified Modeling Language. In fact, you
- 40. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 35 Peking University Software Engineering Insistute 2009 might be wondering why UML isn't "the" EMF model. Why does EMF need its own model? Well, the answer is quite simply that Ecore is a small and simplified subset of full UML. Full UML supports much more ambitious modeling than the core support in EMF. UML, for example, allows you to model the behavior of an application, as well as its class structure. We'll talk more about the relationship of EMF to UML and other standards in Section 2.6. We can now use instances of the classes defined in Ecore to describe the class structure of our application models. For example, we describe the purchase order class as an instance of EClass named "PurchaseOrder". It contains two attributes (instances of EAttribute that are accessed via eAttributes) named "shipTo" and "billTo", and one reference (an instance of EReference that is accessed via eReferences) named "items", for which eReferenceType (its target type) is equal to another EClass instance named "Item". These instances are shown in Figure 2.4. Figure 2.4. The purchase order Ecore instances. When we instantiate the classes defined in the Ecore metamodel to define the model for our own application, we are creating what we call an Ecore model. 2.3.2. Creating and Editing the Model Now that we have these Ecore objects to represent a model in memory, EMF can read from them to, among other things, generate implementation code. You might be wondering, though, how do you create the model in the first place? The answer is that you need to build it from whatever input form you start with. If you start with Java interfaces, EMF will introspect them and build the Ecore model. If, instead, you start with an XML Schema, then the model will be built from that. If you start with UML, there are three possibilities: 1. Direct Ecore editing. EMF includes a simple tree-based sample editor for Ecore. If you'd rather use a graphical tool, the Ecore Tools project[5] provides a graphical Ecore editor based on UML notation. Third-party options are also available, including Topcased's Ecore Editor (http://www.topcased.org/),
- 41. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 36 Peking University Software Engineering Insistute 2009 Omondo's EclipseUML (http://www.omondo.com/) and Soyatec's eUML (http://www.soyatec.com/). 2. Import from UML. The EMF Project and EMF Model wizards provide an extensible framework, into which model importers can be plugged, supporting different model formats. EMF provides support for Rational Rose (.mdl files) only. The reason Rose has this special status is because it's the tool that was used to "bootstrap" the implementation of EMF itself. The UML2 project[6] also provides a model importer for standard UML 2.x models. 3. Export from UML. This is similar to the second option, but the conversion support is provided exclusively by the UML tool. It is invoked from within the UML tool, instead of from an EMF wizard. As you might imagine, the first option is the most desirable. With it, there is no import or export step in the development process. You simply edit the model and then generate. Also, unlike the other options, you don't need to worry about the Ecore model being out of sync with the tool's own native model. The other two approaches require an explicit reimport or reexport step whenever the UML model changes. The advantage of the second and third options is that you can use the UML tool to do more than just your EMF modeling. You can use the full power of UML and whatever fancy features the particular tool has to offer. If it supports its own code generation, for example, you can use the tool to define your Ecore model, and also to both define and generate other parts of your application. As long as a mechanism for conversion to Ecore is provided, that tool will also be usable as an input source for EMF and its generator. 2.3.3. XMI Serialization By now you might be wondering what the serialized form of an Ecore model is. Previously, we've observed that the "conceptual" model is represented in at least three physical places: Java code, XML Schema, or a UML diagram. Should there be just one form that we use as the primary, or standard, representation? If so, which one should it be? Believe it or not, we actually have yet another (i.e., a fourth) persistent form that we use as the canonical representation: XML Metadata Interchange (XMI). Why did we need another one? We weren't exactly short of ways to represent the model persistently. For starters, Java code, XML Schema, and UML all carry additional information beyond what is captured in an Ecore model. Moreover, none of these forms is required in every scenario in which EMF can be used. Java code was the only one required in our running example, but as we will soon see, even it is optional in some
- 42. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 37 Peking University Software Engineering Insistute 2009 cases. So, what we need is a direct serialization of Ecore, which doesn't add any extra information. XMI fits the bill here, as it is a standard for serializing metadata concisely using XML. Serialized as an Ecore XMI file, our purchase order model looks something like this: Code View: Scroll / Show All <?xml version="1.0" encoding="UTF-8"?> <ecore:EPackage xmi:version="2.0" xmlns:xmi="http://www.omg.org/XMI" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ecore="http://www.eclipse.org/emf/2002/Ecore" name="po" nsURI="http://www.example.com/SimplePO" nsPrefix="po"> <eClassifiers xsi:type="ecore:EClass" name="PurchaseOrder"> <eStructuralFeatures xsi:type="ecore:EAttribute" name="shipTo" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> <eStructuralFeatures xsi:type="ecore:EAttribute" name="billTo" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> <eStructuralFeatures xsi:type="ecore:EReference" name="items" upperBound="-1" eType="#//Item" containment="true"/> </eClassifiers> <eClassifiers xsi:type="ecore:EClass" name="Item"> <eStructuralFeatures xsi:type="ecore:EAttribute" name="productName" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EString"/> <eStructuralFeatures xsi:type="ecore:EAttribute" name="quantity" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EInt"/> <eStructuralFeatures xsi:type="ecore:EAttribute" name="price" eType="ecore:EDataType http://www.eclipse.org/emf/2002/Ecore#//EFloat"/> </eClassifiers> </ecore:EPackage> Notice that the XML elements correspond directly to the Ecore instances back in Figure 2.4, which makes perfect sense because this is a serialization of exactly those objects. Here we've hit an important point: because Ecore metadata is not the same as, for example, UML metadata, XMI serializations of the two are not the same either.[7] [7] When we spoke of exporting a model for use with EMF in the previous section, we were really talking about exporting to Ecore XMI, specifically.
- 43. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 38 Peking University Software Engineering Insistute 2009 2.3.4. Java Annotations Let's revisit the issue of defining an Ecore model using Java interfaces. Previously we implied that when provided with ordinary Java interfaces, EMF "would" introspect them and deduce the model properties. That's not exactly the case. The truth is that given interfaces containing standard get() methods,[8] EMF could deduce the model attributes and references. EMF does not, however, blindly assume that every interface and method in it is part of the model. The reason for this is that the EMF generator is a code-merging generator. It generates code that not only is capable of being merged with user-written code, it's expected to be. [8] EMF uses a subset of the JavaBeans simple property accessor naming patterns. For more information, see Section 7.1 of the specification at http://java.sun.com/products/javabeans/docs/spec.html. Because of this, our PurchaseOrder interface isn't quite right for use as a model definition. First of all, the parts of the interface that correspond to model elements whose implementation should be generated need to be indicated. Unless explicitly marked with an @model annotation in the Javadoc comment, a method is not considered to be part of the model definition. For example, interface PurchaseOrder needs the following annotations: /** * @model */ public interface PurchaseOrder { /** * @model */ String getShipTo(); /** * @model */ String getBillTo(); /** * @model type="Item" containment="true" */ List getItems(); }
- 44. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 39 Peking University Software Engineering Insistute 2009 Here, the @model tags identify PurhaseOrder as a modeled class, with two attributes, shipTo and billTo, and a single reference, items. Notice that both attributes, shipTo and billTo, have all their model information available through Java introspection; that is, they are simple attributes of type String. No additional model information appears after their @model tags, because only information that is different from the default needs to be specified. There is some non-default model information needed for the items reference. Because the reference is multiplicity-many, indicated by the fact that getItems() returns a List, we need to specify the target type of the reference as type="Item".[9] We also need to specify containment="true" to indicate that we want purchase orders to be a container for their items and serialize them as children. [9] Note that beginning with Java 5.0, generics can be used to specify a list's item type. Generics have only been supported in EMF since version 2.3. You'll see the older form, with a raw list type, throughout most of this book, both as the Java specification for a multiplicity-many reference and in the code generated from it. Chapter 21, which focuses specifically on EMF 2.3 and 2.4, details the new generics-based form. Notice that the setShipTo() and setBillTo() methods are not required in the annotated interface. With the annotations present on the get() method, we don't need to include them; once we've identified the attributes (which are settable by default), the set() methods will be generated and merged into the interface if they're not already there. 2.3.5. The Ecore "Big Picture" Let's recap what we've covered so far. 1. Ecore, and its XMI serialization, is the center of the EMF world. 2. An Ecore model can be created from any of at least three sources: a UML model, an XML Schema, or annotated Java interfaces. 3. Java implementation code and, optionally, other forms of the model can be generated from an Ecore model. We haven't talked about it yet, but there is one important advantage to using XML Schema to define a model: given the schema, instances of the model can be serialized to conform to it. Not surprisingly, in addition to simply defining the model, the XML Schema approach is also specifying something about the persistent form of the instances. One question that comes to mind is whether there are other persistent model forms possible. Couldn't we, for example, provide a relational database (RDB) Schema and produce an Ecore model from it? Couldn't this RDB Schema also be used to specify
- 45. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 40 Peking University Software Engineering Insistute 2009 the persistent format, similar to the way XML Schema does? The answer is, quite simply, yes. This is one type of function that EMF is intended to support, and certainly not the only kind. The "big picture" is shown in Figure 2.5. Figure 2.5. An Ecore model and its sources. 2.4. Generating Code The most important benefit of EMF, as with modeling in general, is the boost in productivity that results from automatic code generation. Let's say that you've defined a model, for example the purchase order Ecore model shown in Section 2.3.3, and are ready to turn it into Java code. What do you do now? In Chapter 4, we'll walk through this scenario and others where you start with other forms of the model (e.g., Java interfaces). For now, suffice to say that it only involves a few mouse clicks. All you need to do is create a project using the EMF Project wizard, which automatically launches the generator, and select Generate Model Code from a menu. 2.4.1. Generated Model Classes So what kind of code does EMF generate? The first thing to notice is that an Ecore class (i.e., an EClass) actually corresponds to two things in Java: an interface and a corresponding implementation class. For example, the EClass for PurchaseOrder maps to a Java interface: public interface PurchaseOrder ... and a corresponding implementation class: public class PurchaseOrderImpl extends ... implements PurchaseOrder { This interface–implementation separation is a design choice favored by EMF. Why do we advocate this approach? The reason is simply that we believe it's the best
- 46. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 41 Peking University Software Engineering Insistute 2009 pattern for any model-like API. For example, the Document Object Model (DOM) is like this and so is much of Eclipse. It's also a necessary pattern to support multiple inheritance in Java. The next thing to notice about each generated interface is that it extends directly or indirectly from the base interface EObject like this: public interface PurchaseOrder extends EObject { EObject is the EMF equivalent of java.lang.Object; that is, it's the base of all modeled objects. Extending EObject introduces three main behaviors: 1. eClass() returns the object's metaobject (an EClass). 2. eContainer() and eResource() return the object's containing object and resource. 3. eGet(), eSet(), eIsSet(), and eUnset() provide an API for accessing the objects reflectively. The first and third items are interesting only if you want to generically access the objects instead of, or in addition to, using the type-safe generated accessors. We'll look at how this works in Sections 2.5.3 and 2.5.4. The second item is an integral part of the persistence API that we will describe in Section 2.5.2. Other than that, EObject has only a few convenience methods. However, there is one more important thing to notice; EObject extends yet another interface: public interface EObject extends Notifier { The Notifier interface is also quite small, but it introduces an important characteristic to every modeled object; model change notification as in the Observer design pattern [3]. Like object persistence, notification is an important feature of an EMF object. We'll look at EMF notification in more detail in Section 2.5.1. Let's move on to the generated methods. The exact pattern that is used for any given feature (i.e., attribute or reference) implementation depends on the type and other user-settable properties. In general, the features are implemented as you'd expect. For example, the get() method for the shipTo attribute simply returns an instance variable like this: public String getShipTo() { return shipTo; }
- 47. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 42 Peking University Software Engineering Insistute 2009 The corresponding set() method sets the same variable, but it also sends a notification to any observers that might be interested in the state change: public void setShipTo(String newShipTo) { String oldShipTo = shipTo; shipTo = newShipTo; if (eNotificationRequired()) eNotify(new ENotificationImpl(this, Notification.SET, POPackage.PURCHASE_ORDER__SHIP_TO, oldShipTo, shipTo)); } Notice that, to make this method more efficient when the object has no observers, the relatively expensive call to eNotify() is avoided by the eNotificationRequired() guard. More complicated patterns are generated for other types of features, especially bidirectional references where referential integrity is maintained. In all cases, however, the code is generally as efficient as possible, given the intended semantic. We'll cover the complete set of generator patterns in Chapter 10. The main message you should go away with is that the generated code is clean, simple, and efficient. EMF does not pull in large base classes, or generate inefficient code. EMF's runtime framework is lightweight, as are the objects generated for your model. The idea is that the code that's generated should look pretty much like what you would have written, had you done it by hand. However, because it's generated, you know it's correct. It's a big time saver, especially for some of the more complicated bidirectional reference handshaking code, which might otherwise be fairly difficult to get right. Before moving on, we should mention two other important classes that are generated for a model: a factory and a package. The generated factory (e.g., POFactory) includes a create method for each class in the model. The EMF programming model strongly encourages, but doesn't require, the use of factories for creating objects. Instead of simply using the new operator to create a purchase order, you should do this: PurchaseOrder aPurchaseOrder = POFactory.eINSTANCE.createPurchaseOrder();
- 48. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 43 Peking University Software Engineering Insistute 2009 The generated package (e.g., POPackage) provides convenient accessors for all the Ecore metadata for the model. You might already have noticed, in the implementation of setShipTo() shown earlier, the use of POPackage.PURCHASE_ORDER__SHIP_TO, a static int constant representing the shipTo attribute. The generated package also includes convenient accessors for the EClasses, EAttributes, and EReferences. We'll look at the use of these accessors in Section 2.5.3. 2.4.2. Other Generated "Stuff" In addition to the interfaces and classes described in the previous section, the EMF generator can optionally generate the following: 1. A skeleton adapter factory[10] class (e.g., POAdapterFactory) for the model. This convenient base class can be used to implement adapter factories that need to create type-specific adapters; for example, a PurchaseOrderAdapter for PurchaseOrders, an ItemAdapter for Items, and so on. [10] Adapters and adapter factories are described in Section 2.5.1. 2. A convenience switch class (e.g., POSwitch) that implements a "switch statement"-like callback mechanism for dispatching based on an object's type (i.e., its EClass). The adapter factory class, as just described, uses this switch class in its implementation. 3. Plug-in manifest files and property files, so that the model can be used as an Eclipse plug-in. If all you're interested in is generating a model, this is the end of the story. However, as we'll see in Chapters 3 and 4, the EMF generator can, using the EMF.Edit extensions to the EMF core, generate adapter classes that enable viewing and command-based, undoable editing of a model. It can even generate a complete working editor for your model. We will talk more about EMF.Edit and its capabilities in the following chapter. For now, we just stick to the basic modeling framework itself. 2.4.3. Regeneration and Merge The EMF generator produces files that are intended to be a combination of generated pieces and handwritten pieces. You are expected to edit the generated classes to add methods and instance variables. You can always regenerate from the model as needed and your additions will be preserved during the regeneration.
- 49. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 44 Peking University Software Engineering Insistute 2009 EMF uses @generated markers in the Javadoc comments of generated interfaces, classes, methods, and fields to identify the generated parts. For example, getShipTo() actually looks like this: /** * @generated */ public String getShipTo() { ... Any method that doesn't have this @generated tag (i.e., anything you add by hand) will be left alone during regeneration. If you already have a method in a class that conflicts with a generated method, your version will take precedence and the generated one will be discarded. You can, however, redirect a generated method if you want to override it but still call the generated version. If, for example, you rename the getShipTo() method with a Gen suffix: /** * @generated */ public String getShipToGen() { ... Then if you add your own getShipTo() method without an @generated tag, the generator will, on detecting the conflict, check for the corresponding Gen version and, if it finds one, redirect the generated method body there. The merge behavior for other things is generally reasonable. For example, you can add extra interfaces to the extends clause of a generated interface (or the implements clause of a generated class) and specify that they should be retained during regeneration. The single extends class of a generated class, however, will always be overwritten by the model's choice. We'll look at code merging in more detail in Chapter 10. 2.4.4. The Generator Model Most of the data needed by the EMF generator is stored in the Ecore model. As we saw in Section 2.3.1, the classes to be generated and their names, attributes, and references are all there. There is, however, more information that needs to be provided to the generator, such as where to put the generated code and what prefix to use for the generated factory and package class names, that isn't stored in the Ecore model. All this user-settable data also needs to be saved somewhere so that it will be available if we regenerate the model in the future.
- 50. EMF: Eclipse Modeling Framework 2nd PERSONAL AND NON-COMMERCIAL USE LIMITATION 45 Peking University Software Engineering Insistute 2009 The EMF code generator uses a generator model to store this information. Like Ecore, the generator model is itself an EMF model. Actually, a generator model provides access to all of the data needed for generation, including the Ecore part, by wrapping the corresponding Ecore model. That is, generator model classes are decorators [3] of Ecore classes. For example, GenClass decorates EClass, GenFeature decorates EAttribute and EReference, and so on. The significance of all this is that the EMF generator runs off of a generator model instead of an Ecore model; it's actually a generator model editor.[11] When you use the generator, you'll be editing a generator model, which in turn indirectly accesses the Ecore model from which you're generating. As you'll see in Chapter 4 when we walk through an example of using the generator, there are two model resources (files) in the project: an .ecore file and a .genmodel file. The .ecore file is an XMI serialization of the Ecore model, as we saw in Section 2.3.3. The .genmodel file is a serialized generator model with cross-document references to the .ecore file. Figure 2.6 shows the conceptual picture. [11] It is, in fact, an editor generated by EMF, like the ones we'll be looking at in Chapter 4 and later in the book. Figure 2.6. The .genmodel and .ecore files. Separating the generator model from the Ecore model like this has the advantage that the actual Ecore metamodel can remain pure and independent of any information that is only relevant for code generation. The disadvantage of not storing all the information right in the Ecore model is that a generator model might get out of sync if the referenced Ecore model changes. To handle this, the generator model elements are able to automatically reconcile themselves with changes to their corresponding Ecore elements. Users don't need to worry about it.
- 51. Another Random Scribd Document with Unrelated Content
- 52. The boat is clinch-built; that is, the planks are held together by large iron bolts with round heads outside, and clinch plates on the inside, at a distance of 5½ inches from each other. The space between the planks is filled with woollen stuff and a pitchy sticky mass. The boards are joined in a very common manner to the frame with bast ropes. In the frame are holes, which correspond to elevated pieces on the boards which are also bored through; these pieces had not been nailed to the planks, but were hewn out of the latter, which thereby had lost more than half their thickness. Vessels by this peculiar manner of joining frame and boards acquired great elasticity, which must have been of good service in the surf and in a heavy sea. Fig. 423.—Oar-thole of red pine. ⅒ real size. Fig. 424.—Oar-thole of the Nydam Boat. ⅐ real size.
- 53. Fig. 425.—Inside view of one of the stems of the Nydam boat. Fig. 426.—Rib of boat, showing seat attached. Fig. 427.—Wooden pegs fastening stem to bottom plank. 1 17 real size.
- 54. Fig. 428.—Showing how the boards joined the ribs. Fig. 429.—End face view of oar-thole. ⅒ real size.
- 55. Fig. 430.— Rudder, 10 feet long, found alongsid e Nydam boat. The boat was shaped alike both fore and aft, so that it could be rowed in either direction; and in both stems, which are fastened to the bottom plank, are two holes through which, judging from the manner in which they are worn, ropes were probably drawn, by which to drag the boat ashore at the beginning of winter. In the bottom there is a hole, which probably after the ship had been drawn up served to give outlet to the water collected in the boat. The boat had undoubtedly been intentionally sunk, for in the planks under the water-line had been cut large holes to let in the water. Rust had destroyed the ends of the iron bolts which had held the planks together, and also the ropes with which the boards and the frame had been held together. The planks fell apart, therefore, and took their original straight shape; the oar-tholes were loosened from the gunwale; the frame fell on different sides, and the two high stems fell down. As the joints loosened, the separate pieces sank to the bottom, and remained lying at about an equal depth, while the turf grew up above them and preserved them from destruction. After all the parts of the boat had been carefully collected and dried, it was possible to restore it to its original shape.
- 56. Fig. 431.—Wooden scoop for baling water. ⅑ real size. Another boat of red pine wood was discovered alongside it. This one was laid on the field and covered with bog mould, until the work connected with the other boat was finished. Unfortunately the war of 1864 put an end to the examination of the Nydam bog, so that the boat was left lying on the field, and strangers have carried off many pieces of it. The bottom plank was about 50 feet long, 13 inches broad, and ends in two spurs or rams. How high the prows were raised above the plank cannot be stated. Since this date the diggings have been done by inexperienced men, and consequently have given but little results. This sacred part of the land of the Danes had passed into the hands of its German conquerors, for the Nornir[166] are fickle, and what is fated to one generation to accomplish is often, in the course of time, undone by another. NYDAM BOG FIND. Fig. 432.—The end of the bottom plank of a vessel of red pine, with a ram at each
- 57. end, from Nydam Bog-find. The pointed lines show how the spurs protruded from the stem. Fig. 433. Fig. 434.
- 58. Fragments wooden scabbard with bronze mountings. ½ real size. Fig. 435.—A throwing spear with line attached, length of spear 10 feet. ⅓ real size. Fig. 436.—Spear-head. ⅓ real size. Fig. 437.—Leaf-shaped spear-point ornamented with engraved lines. ⅓ real size. Fig. 438.—Iron axes. ¼ real size. Fig. 439.—Iron celt. ¼ real size.
- 59. Fig. 440.—Tweezer and earpick of bronze hanging on a bronze ring. Real size. Fig. 441.—Wooden club. ⅛ real size. Fig. 442.—Black glass bead. Real size.
- 60. Fig. 443.—Light-green glass bead, with yellow points on a dark-red ground. Real size. Fig. 444.—Green glass bead with red stripes. Real size.
- 61. Fig. 445.—½ real size. Fig. 446.—½ real size. Buckles.
- 63. ½ real size. Fig. 449.— Iron knife with wooden handle. ¼ real size.
- 64. Fig. 450.— Double-barrelled tube of silver found with ear pick. Real size. Fig. 451.
- 65. Fig. 452. Wooden bows, with notches at the end for fastenin g the string. 1 11 real size.
- 66. Fig. 453. —Part of a wooden bow. ½ real size. Fig. 454.— Part of arrow-shaft bearing runic
- 68. Fig. 456.— Arrow-shaft with owner’s mark. Real size. Fig. 457.— Arrow- point of iron. ⅓ real size.
- 70. Fig. 460. Bronze mountings for a quiver. ¼ real size. Fig. 461. —¼ real size.
- 71. Fig. 462.—½ real size. Fragments of wooden scabbards with bronze mountings. Fig. 463. — Wooden quiver. ¼ real size.
- 72. Fig. 464.—Bearded spear-head, bent and twisted. ⅓ real size. Fig. 465.
- 73. Fig. 466. Bearded spear-points of iron. ⅓ real size. Fig. 467.— Iron
- 76. Fig. 470. —Leaf shaped iron spear- point. Real size. Fig. 471.—Iron sword, damascened, bearing Latin inscription. ⅔ real size.
- 77. Fig. 472.—Iron sword bearing Latin inscription. ⅔ real size. Fig. 473.—Iron sword bearing Latin inscription.
- 78. Fig. 474.—Part of sword blade with runes inlaid with gold. Fig. 475.
- 79. Fig. 476. Damascened blades. ⅔ real size. Fig. 477.—Wooden bowl. ⅙ real size.
- 80. Fig. 478. Fig. 479. Iron ferrules to scabbard, inlaid with flat hammered gold wire. ½ real size.
- 81. Fig. 480.—Wooden trough. ⅙ real size. Fig. 481. Fig. 482.—Ornaments of bronze plated with thin silver and gold. Real size. Fig. 483.—Bit of bronze. ¼ real size.
- 82. Fig. 484.—Bit of iron. ¼ real size. Fig. 485.— Double- edged damasc ened sword with silver handle. ⅕ real size.
- 83. Fig. 486.— Double- edged damasc ened sword. ⅕ real size. Fig. 487.—Spiral bracelet of gold with triangular ornaments, ½ real size, found in a bog near Horsens, Denmark.
- 84. Fig. 488. Fig. 489. Damascened iron sword, ¼ real size, of the later iron age, with
- 85. Welcome to our website – the ideal destination for book lovers and knowledge seekers. With a mission to inspire endlessly, we offer a vast collection of books, ranging from classic literary works to specialized publications, self-development books, and children's literature. Each book is a new journey of discovery, expanding knowledge and enriching the soul of the reade Our website is not just a platform for buying books, but a bridge connecting readers to the timeless values of culture and wisdom. With an elegant, user-friendly interface and an intelligent search system, we are committed to providing a quick and convenient shopping experience. Additionally, our special promotions and home delivery services ensure that you save time and fully enjoy the joy of reading. Let us accompany you on the journey of exploring knowledge and personal growth! ebookultra.com