Introducing EMF
- 2.1 Unifying Java, XML, and UML
- 2.2 Modeling vs. Programming
- 2.3 Defining the Model
- 2.4 Generating Code
- 2.5 The Runtime Framework
- 2.6 EMF and Modeling Standards
This chapter is from the book
This chapter is from the book
This chapter is from the book
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:
public interface PurchaseOrder
{
String getShipTo();
void setShipTo(String value);
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
)
Figure 2.1 UML diagram of interfaces.
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 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.