EclipseCon 2008: Fundamentals of the Eclipse Modeling Framework
•
4 gefällt mir•1,418 views
EclipseCon 2008 long talk introducing EMF. A slightly different take from the preceding EclipseWorld talk, with a few more details on the EMF core and no discussion of CDO or Teneo.
![Goal ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (10)
Ähnlich wie EclipseCon 2008: Fundamentals of the Eclipse Modeling Framework
Ähnlich wie EclipseCon 2008: Fundamentals of the Eclipse Modeling Framework (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
EclipseCon 2008: Fundamentals of the Eclipse Modeling Framework
- 1. Fundamentals of the Eclipse Modeling Framework Dave Steinberg IBM Rational Software Toronto, Canada EMF Committer
- 14. XML Schema <?xml version="1.0" encoding="UTF-8"?> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.example.com/SimplePO" xmlns:po="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>
- 17. EMF Architecture EMF Runtime EMF Tools Core Edit Codegen Model Editor Application Generates Eclipse Platform
- 29. Bidirectional References public interface PurchaseOrder { ... PurchaseOrder getNext (); void setNext (PurchaseOrder value); PurchaseOrder getPrevious (); void setPrevious (PurchaseOrder value); } Bidirectional reference imposes invariant: po.getNext().getPrevious() == po
- 31. Bidirectional Reference Handshaking p1.setNext(p3); p2 p1 p2 p3 change notification next previous previous next next previous next previous
- 44. Proxy Resolution and Demand Load proxyURI="p2.xml#p2" proxyURI=" p2.xml #p2" p1 p1.xml PurchaseOrder p2 = p1.getNext(); next p2 next p2.xml
Hinweis der Redaktion
- Welcome…
- I hope to help you learn about modeling and convince you that EMF can help you write just about any application in significantly less time, simply by leveraging the data model you’ve probably already defined (even though you might not know it yet).
- Here’s our agenda. We’ll also be doing a couple of exercises… I’ll start with some philosophy.
- What is modeling? The Object Management Group, an industry consortium, has tried to answer that question by proposing MDA – Model Driven Architecture…
- MDA initiative began in 2001. Some people are wondering not just “are we there yet?” but “are we ever going to get there?”…
- This is the environment in which EMF was introduced and took hold…
- EMF’s take is that models are everywhere, and we just need to find them, extract them, and leverage them…
- Where does EMF fit into the Eclipse “big picture”? EMF was one of the first projects at Eclipse outside of the Eclipse Project itself, starting in 2002 as part of the Tools project. Since then, the modeling project has formed around it…
- Now, let’s talk some more about models in EMF: what they consist of and where they come from.
- I’ve mentioned that EMF’s view of modeling favours simplicity over expressiveness. But, to be more concrete, here’s what we mean by a “model” in EMF…
- EMF is very much intended to be a unifying technology. It expects models to be expressed in any number of different ways, and aims to extract its core view of the model from those different representations. Out of the box, it supports what we consider to be the most important ones… To dwell for a moment on the notion of equivalence of different model representations, let’s consider a simple, familiar example. Imagine we wanted to represent the data in a purchase order. The non-modeler would probably start by writing some Java interfaces…
- An interface for each type, accessors for each attribute or association (reference). This really is a definition of the model. But, it’s not quite expressive enough that we could generate a complete implementation from it…
- A graphical representation of the model is more concise. Here, we’re using UML notation…
- There’s another important way of coming at this: by asking “how do we want to instances of the model to look when they’re serialized?” That’s what XML Schema is all about… Notice that there’s additional information in this one…
- To reiterate, these different forms all provide the same core information about the model, or structure, of the application’s data. EMF allows you to capture this information and use it to, among other things, generate code.
- Now that I’ve hopefully motivated and introduced EMF, I’ll talk a bit about EMF’s architecture.
- I guess we need to start with a block diagram. EMF includes a runtime… The last thing to note is that the EMF core runtime’s dependency on the platform is optional…
- If we were to zoom in on those blocks, we’d see that EMF includes these components… The component I’ll focus on most is Ecore. If EMF’s purpose is to capture the core information about an application’s data model, the big question is how…
- Not surprisingly, it uses a model. Because it’s a model for models… Here is a simplified picture…
- The way EMF defines your application model, such as the purchase order we discussed previously, is by instantiating Ecore. So, when the purchase order application is running, there will actually be an instance of EClass present representing class PurchaseOrder…
- Ecore is persisted as XML, using the OMG’s standard for metadata serialization, XML Metadata Interchange… EMOF is the OMG’s equivalent to Ecore. Based on experience with EMF, MOF, the Meta-Object Facility, was split into to two layers, where EMOF is the minimal core. Because of their similarity, EMF also supports saving Ecore directly as EMOF XMI and loading EMOF XMI into Ecore.
- Here’s another pretty block diagram that will hopefully tie everything together…
- Another option is to model directly using Ecore. EMF provides…
- One last architectural note: as of last summer’s Europa release, EMF provides support for Java 5… Generics support includes the ability to model generic types within Ecore.
- I’ve mentioned more than once that EMF lets you generate code from a model. But what does that code look like?
- First off, for each modeled class, an interface/implementation pair is generated. Notice that the interface looks like the Java model representation. Using interfaces allows us to support multiple inheritance. Interfaces extend EObject, the EMF equivalent of java.lang.Object. Getter/setter pairs are included for single-valued attribute and references. Multiplicity-many features are manipulated directly through a list API, so there’s just a getter.
- Change notification is built right into EMF. Every EObject is also a Notifier… To attach an observer, which we call an adapter, to a notifier, we’d do this…
- Looking in the implementation class at the accessors, we can see how that’s done. It’s still a very simple implementation…
- Things get a bit more complicated if you model bidirectional associations, in order to ensure that referential integrity is maintained. To illustrate…
- EMF implements this using a handshaking pattern… It’s not possible to turn off this handshaking bahavior or stop it part-way, without significantly altering generated code.
- Now, looking at the example, let’s follow the whole handshaking process. If we have three purchase orders arranged like this…
- Earlier, I mentioned the EObject interface. Primarily, it provides an API for manipulating objects reflectively…
- These generic accessor methods are implemented using an efficient switch, so as to only impose a small constant-time overhead… Metadata in EMF is represented in two ways…
- Ecore includes enumerated types, which are realized with Java 5 enums. Previously, a class-based type-safe enum pattern was used.
- A couple of really important interfaces and classes are generated for each modeled package…
- Obviously, there’s not enough time to talk about every artifact that EMF generates, so here’s a quick list. Notice that the code is divided into four projects…
- As I mentioned in the intro, Ecore is simple by design. Instead of trying to provide a modeling vocabulary that’s as expressive as Java…
- The generator also supports a pattern for extending generated methods, analogous to overriding a method in a subclass…
- [8:35] Let’s get into the exercises… [8:55] I’d like to talk a bit about how you can use all this code you generated, and then I’ll let you do the second exercise.
- We’ll start with EMF’s resource-based persistence framework. A resource in EMF is just a container for a bunch of objects that will be persisted together. Objects can be spread out among a number of different resources, and demand-loading is used for cross-resource references. That allows…
- A resource set provides a context for multiple resources that may have references among them. You’ll use the resource set to create and manage those resources…
- There are a couple of registries you’ll need to know about… A resource factory registry is used by a resource set to decide what type of resource to create, so it determines the persistence format… A package registry is used to locate metadata during loading. Persisted data specifies a namespace URI…
- As I mentioned earlier, a resource is just a container for objects that are persisted together… Out of the box, EMF provides a generic XML resource and a number of different specializations of it…
- To expand on EMF’s demand-load model for cross-resource references, let’s look at another simple example…
- When you’re working with a model created from XML Schema, there are a couple of extra details you’ll need to worry about. In the first exercise, we saw that the model included…
- To serialize an instance document that conforms to the schema, you’ll need to use an instance of… Also, you’ll need to ensure that…
- The reflective EObject interface is a powerful mechanism for data integration, as it allows your application to discover the model for objects at runtime and modify them accordingly. If you know the model ahead of time…
- Built on the reflective API is dynamic EMF. Rather than generating code, you can define an Ecore model at runtime and instantiate it immediately, using a generic implementation. All of the behaviours of the generated code are emulated by this implementation. You can define the model…
- EMF provides a facility for representing and recording changes to data. As we’re big believers in eating our own dog food…
- A change recorder is a special adapter that attaches to an entire content tree and, based on the change notifications it receives…
- The EMF core also has a built-in framework for validation of invariants and constraints…
- There are a couple of cases where constraints will actually be implemented automatically… For example, in our purchase order schema, there is a SKU type that’s a restriction of string. It specifies a regular expression that any valid value must match…h
- The API for invoking validation is the Diagnostician class…
- Finally, the runtime provides a whole bunch of convenience utilities, mostly in the class EcoreUtil. There you’ll find…
- [9:15] I’ll stop talking again now and let you work on the second exercise. I’ll stop you a few minutes before the session ends to sum things up. [9:55] Let’s sum up…