Your SlideShare is downloading. ×
EclipseCon 2008: Fundamentals of the Eclipse Modeling Framework
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

EclipseCon 2008: Fundamentals of the Eclipse Modeling Framework

2,052
views

Published on

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.

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.

Published in: Technology

0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,052
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
3
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • 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…
  • Transcript

    • 1. Fundamentals of the Eclipse Modeling Framework Dave Steinberg IBM Rational Software Toronto, Canada EMF Committer
    • 2. Goal
      • Learn about modeling and how the Eclipse Modeling Framework can help you write your application in significantly less time, simply by leveraging the data model you’ve probably already defined (although you might not know it yet)
    • 3. Agenda
      • What is Modeling?
      • Defining a Model with EMF
      • EMF Architecture
      • Code Generation
      • Programming with EMF
      • Summary
    • 4. Model Driven Architecture (MDA)
      • A software architecture proposed by the OMG (Object Management Group)
      • Application specified in high-level, Platform Independent Model (PIM)
      • Transformation technologies used to convert PIM to Platform Specific Model (PSM), implementation code
      • Includes several open modeling standards:
        • UML ™ (Unified Modeling Language)
        • MOF (Meta-Object Facility)
        • XMI (XML Metadata Interchange)
        • CWM (Common Warehouse Model)
    • 5. MDA – Are We There Yet?
      • Doubts exist about the ability of MDA to deliver on its promises:
        • Ambitiousness of vision
        • Model expressiveness vs. complexity
        • Availability of implementations (“vaporware”)
    • 6. Enter EMF!
      • EMF is a simple, pragmatic approach to modeling:
        • Allows us to generate some of the code that we write over and over, paving the way for more complex systems (including more ambitious MDA tools)
        • Models are simple, but meant to be mixed with hand-written code
        • It’s real, proven technology (since 2002)
    • 7. Model Driven Development with EMF
      • Contrary to the belief of many programmers, modeling is useful for more than just documentation
      • Almost every program we write manipulates some data model
        • Defined using UML, XML Schema, some other definition language, or implicitly in Java ™
      • EMF aims to extract this intrinsic “model” and generate some of the implementation code
        • Can be a tremendous productivity gain
    • 8. EMF at Eclipse.org
      • Foundation for the Eclipse Modeling Project
        • EMF project incorporates core and additional mature components: Query, Transaction, Validation
        • EMF Technology project incubates complementary components: CDO, Teneo, Compare, Search, Temporality, Ecore Tools…
        • Other projects build on EMF: Graphical Modeling Framework (GMF), Model Development Tools (MDT), Model to Model Transformation (M2M), Model to Text Transformation (M2T)…
      • Other uses: Web Tools Platform (WTP), Data Tools Platform (DTP), Business Intelligence and Reporting Tools (BIRT), SOA Tools Platform (STP)…
      • Large open source user community
    • 9. Agenda
      • What is Modeling?
      • Defining a Model with EMF
      • EMF Architecture
      • Code Generation
      • Programming with EMF
      • Summary
    • 10. What is an EMF “Model”?
      • Specification of an application’s data
        • Object attributes
        • Relationships (associations) between objects
        • Operations available on each object
        • Simple constraints (e.g. multiplicity) on objects and relationships
      • Essentially, the Class Diagram subset of UML
    • 11. Model Sources
      • EMF models can be defined in (at least) three ways:
        • 1. Java Interfaces
        • 2. UML Class Diagram
        • 3. XML Schema
      • Choose the one matching your perspective or skills and EMF can create the others, as well as the implementation code
    • 12. Java Interfaces
      • Classes can be defined completely by a subset of members, supplemented by annotations
      public interface PurchaseOrder { String getShipTo (); void setShipTo(String value); String getBillTo (); void setBillTo(String value); List<Item> getItems (); // containment } public interface Item { String getProductName (); void setProductName(String value); int getQuantity (); void setQuantity(int value) float getPrice (); void setPrice(float value); }
    • 13. UML Class Diagram
      • Built-in support for Rational Rose ®
      • UML2 support available with UML2 (from MDT)
    • 14. XML Schema <?xml version=&quot;1.0&quot; encoding=&quot;UTF-8&quot;?> <xsd:schema xmlns:xsd=&quot;http://www.w3.org/2001/XMLSchema&quot; targetNamespace=&quot;http://www.example.com/SimplePO&quot; xmlns:po=&quot;http://www.example.com/SimplePO&quot;> <xsd:complexType name=&quot; PurchaseOrder &quot;> <xsd:sequence> <xsd:element name=&quot; shipTo &quot; type=&quot;xsd:string&quot;/> <xsd:element name=&quot; billTo &quot; type=&quot;xsd:string&quot;/> <xsd:element name=&quot; items &quot; type=“po:Item&quot; minOccurs=&quot;0&quot; maxOccurs=&quot;unbounded&quot;/> </xsd:sequence> </xsd:complexType> <xsd:complexType name=&quot; Item &quot;> <xsd:sequence> <xsd:element name=&quot; productName &quot; type=&quot;xsd:string&quot;/> <xsd:element name=&quot; quantity &quot; type=&quot;xsd:int&quot;/> <xsd:element name=&quot; price &quot; type=&quot;xsd:float&quot;/> </xsd:sequence> </xsd:complexType> </xsd:schema>
    • 15. Unifying UML, XML and Java
      • All three forms provide the same information
        • Different visualization/representation
        • The application’s data “model” or structure
        • Model importers can be added for different model representations (e.g. RDB Schema)
      • From a model definition, EMF can generate…
        • Java implementation code, including UI
        • XML Schemas
        • Eclipse “plug-in” artifacts
    • 16. Agenda
      • What is Modeling?
      • Defining a Model with EMF
      • EMF Architecture
      • Code Generation
      • Programming with EMF
      • Summary
    • 17. EMF Architecture EMF Runtime EMF Tools Core Edit Codegen Model Editor Application Generates Eclipse Platform
    • 18. EMF Components
      • Core Runtime
        • Notification framework
        • Ecore metamodel
        • Persistence (XML/XMI), validation, change model
      • EMF.Edit
        • Support for model-based editors and viewers
        • Default reflective editor
      • Codegen
        • Code generator for application models and editors
        • Extensible model importer/exporter framework
    • 19. Ecore
      • EMF’s metamodel (model of a model)
    • 20. Ecore
      • Application models (e.g. purchase order model) are instances of Ecore
      EClass (name=&quot;PurchaseOrder&quot;) EClass (name=&quot;Item&quot;) EAttribute (name=&quot;shipTo&quot;) EAttribute (name=&quot;billTo&quot;) EReference (name=&quot;items&quot;) eReferenceType EAttribute (name=“productName&quot;)
    • 21. Ecore
      • Persistent format is XMI (.ecore file)
      • Alternate format is Essential MOF XMI (.emof file)
      <eClassifiers xsi:type=&quot;ecore:EClass&quot; name=&quot; PurchaseOrder &quot;> <eStructuralFeatures xsi:type=&quot;ecore:EReference&quot; name=&quot; items &quot; eType=&quot;#//Item&quot; upperBound=&quot;-1&quot; containment=&quot;true&quot;/> <eStructuralFeatures xsi:type=&quot;ecore:EAttribute&quot; name=&quot; shipTo &quot; eType=&quot;ecore:EDataType http:...Ecore#//EString&quot;/> ... </eClassifiers>
    • 22. Model Import and Generation Ecore Model UML XML Schema Java Model
      • Generator features:
        • Customizable, JSP-like templates (JET)
        • JDT-integrated, command-line or Ant
        • Full support for regen and merge
      I M P O R T Java Edit Java Editor GENERATE
    • 23. Direct Ecore Modeling
      • Ecore models can be created directly
        • Sample Ecore editor (in EMF)
        • Ecore Tools graphical editor (from EMFT)
    • 24. EMF and Java 5.0
      • EMF 2.3 began exploiting the capabilities of Java 5.0
        • Generics
        • Typesafe enums
        • Annotations
        • Enhanced for loop
        • Autoboxing
      • EMF 2.3 and later provide 5.0-targeted runtime that only runs on a Java 5.0 or later VM
      • The code generator can also produce application code that runs on a 1.4 VM against the 2.2 runtime
      • This is a recognition that Java 5.0 is the way forward, but the transition need not be painful for the user
    • 25. Agenda
      • What is Modeling?
      • Defining a Model with EMF
      • EMF Architecture
      • Code Generation
      • Programming with EMF
      • Summary
    • 26. Generated Model Code
      • Interface and implementation for each modeled class
        • Includes get/set accessors for attributes and references
      public interface PurchaseOrder extends EObject { String getShipTo(); void setShipTo(String value); String getBillTo(); void setBillTo(String value); EList<Item> getItems(); } public class PurchaseOrderImpl extends EObjectImpl implements PurchaseOrder { ... }
    • 27. Change Notification
      • Every EObject is also a Notifier
        • Sends notification whenever an attribute or reference is changed
        • Observers can update views, dependent objects
        • Observers are also adapters
      Adapter adapter = ... purchaseOrder.eAdapters().add(adapter);
    • 28. Change Notification: Feature Accessors
      • Efficient notification from set methods
      public String getBillTo() { return billTo; } public void setBillTo(String newBillTo) { String oldBillTo = BillTo; billTo = newBillTo; if (eNotificationRequired()) eNotify(new ENotificationImpl(this, ... , oldBillTo, billTo); }
    • 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
    • 30. Bidirectional Reference Handshaking
      • Multi-step procedure implemented using InternalEObject methods:
        • eInverseRemove()
        • eInverseAdd()
      • Framework list implementations and generated setters directly invoke them on target objects as needed
      • Notifications accumulated using a NotificationChain and fired off at the end
        • Not used to implement the handshaking
    • 31. Bidirectional Reference Handshaking p1.setNext(p3); p2 p1 p2 p3 change notification next previous previous next next previous next previous
    • 32. Reflective EObject API
      • All EMF classes implement EObject interface
      • Provides an efficient API for manipulating objects reflectively
        • Used by framework (e.g. persistence framework, copy utility, editing commands)
        • Key to integrating EMF-based tools and applications
      public interface EObject { EClass eClass(); Object eGet (EStructuralFeature sf); void eSet (EStructuralFeature sf, Object val); ... }
    • 33. Reflective EObject API
      • Efficient generated switch-based implementation of reflective methods
      public Object eGet(int featureID, ...) { switch (featureID) { case POPackage.PURCHASE_ORDER__ITEMS: return getItems (); case POPackage.PURCHASE_ORDER__SHIP_TO: return getShipTo (); case POPackage.PURCHASE_ORDER__BILL_TO: return getBillTo (); ... } ... }
    • 34. Typesafe Enums
      • Typesafe enum pattern for enumerated types
      public enum Status implements Enumerator { PENDING(0, &quot;Pending&quot;, &quot;Pending&quot;), BACK_ORDER(1, &quot;BackOrder&quot;, &quot;BackOrder&quot;), COMPLETE(2, &quot;Complete&quot;, &quot;Complete&quot;); public static final int PENDING_VALUE = 0; public static final int BACK_ORDER_VALUE = 1; public static final int COMPLETE_VALUE = 2; private final int value; private final String name; private final String literal; private Status(int value, String name, String literal) { ... } ... }
    • 35. Factories and Packages
      • Factory to create instances of model classes
      • Package provides access to metadata
      POFactory factory = POFactory.eINSTANCE ; PurchaseOrder order = factory. createPurchaseOrder (); POPackage poPackage = POPackage.eINSTANCE ; EClass itemClass = POPackage.Literals.ITEM ; //or poPackage. getItem () EAttribute priceAttr = POPackage.Literals.ITEM__PRICE ; //or poPackage. getItem_Price () //or itemClass.getEStructuralFeature( POPackage.ITEM__PRICE )
    • 36. Summary of Generated Artifacts
      • Model
        • Interfaces and classes
        • Type-safe enums
        • Package (metadata)
        • Factory
        • Switch utility
        • Adapter factory base
        • Validator
        • Custom resource
        • XML Processor
      • Manifests, plug-in classes, properties, icons…
      • Edit (UI Independent)
        • Item providers
        • Item provider adapter factory
      • Editor
        • Model Wizard
        • Editor
        • Action bar contributor
        • Advisor (RCP)
      • Tests
        • Test cases
        • Test suite
        • Stand-alone example
    • 37. Regeneration and Merge
      • The EMF generator is a merging generator
      • @generated elements are replaced/removed
      • To preserve changes mark @generated NOT
      /** * <!-- begin-user-doc --> * <!-- end-user-doc --> * @generated */ public String getName() { return name; }
    • 38. Regeneration and Merge
      • Generated methods can be extended through redirection
      public String getName () { return format(getNameGen()); } /** * <!-- begin-user-doc --> * <!-- end-user-doc --> * @generated */ public String getNameGen () { return name; }
    • 39. Agenda
      • What is Modeling?
      • Defining a Model with EMF
      • EMF Architecture
      • Code Generation
      • Programming with EMF
      • Summary
    • 40. Persistence
      • Persisted data is referred to as a resource
      • Objects can be spread out among a number of resources, within a resource set
      • Proxies represent referenced objects in other resources
    • 41. Resource Set
      • Context for multiple resources that may have references among them
      • Usually just an instance of ResourceSetImpl
      • Provides factory method for creating new resources in the set
      • Also provides access to the registries, URI converter and default load options for the set
      ResourceSet rs = new ResourceSetImpl (); URI uri = URI.createFileURI(&quot;C:/data/po.xml&quot;); Resource resource = rs. createResource (uri);
    • 42. Registries
      • Resource Factory Registry
        • Returns a resource factory for a given type of resource
        • Based on URI scheme, filename extension or content type
        • Determines the format for save/load
        • If no registered resource factory found locally, delegates to global registry: Resource.Factory.Registry.INSTANCE
      • Package Registry
        • Returns the package identified by a given namespace URI
        • Used during loading to access factory for instantiating classes
        • If no registered package found locally, delegates to global registry: EPackage.Registry.INSTANCE
    • 43. Resource
      • Container for objects that are to be persisted together
        • Convert to and from persistent form via save() and load()
        • Access contents of resource via getContents()
      • EMF provides generic XMLResource implementation
        • Other, customized implementations, too (e.g. XMI, EMOF)
      URI uri = URI.createFileURI(&quot;C:/data/po.xml&quot;); Resource resource = rs.createResource(uri); resource. getContents ().add(p1); resource. save (null); <PurchaseOrder> <shipTo> John Doe </shipTo> <next> p2.xml#p2 </next> </PurchaseOrder>
    • 44. Proxy Resolution and Demand Load proxyURI=&quot;p2.xml#p2&quot; proxyURI=&quot; p2.xml #p2&quot; p1 p1.xml PurchaseOrder p2 = p1.getNext(); next p2 next p2.xml
    • 45. XML Schema-Conformant Serialization
      • A DocumentRoot class is included in models created from XML Schema
        • Includes one containment reference per global element
      <xsd:schema ... > <xsd:element name=&quot; order &quot; type=&quot;po:PurchaseOrder&quot;> <xsd:element name=&quot; item &quot; type=&quot;po:Item&quot;> ... </xsd:schema>
    • 46. XML Schema-Conformant Serialization
      • To serialize an instance document
        • Use an XMLResource with extended metadata enabled (e.g. use the resource factory generated with your model)
        • Use an instance of the DocumentRoot in the resource’s contents
        • Set the appropriate reference to select the root element
      PurchaseOrder p1 = ... URI uri = URI.createFileURI(&quot;C:/data/order.po&quot;); resource resource = rs.createResource(uri); DocumentRoot root = POFactory.eINSTANCE.createDocumentRoot(); resource. getContents ().add( root ); root. setOrder ( p1 ); resource.save(null);
    • 47. Reflection
      • Setting an attribute using generated API
      • Using reflective API
      PurchaseOrder po = ... po. setBillTo (&quot;123 Elm St.&quot;); EObject po = ... EClass poClass = po.eClass(); po. eSet (poClass.getEStructuralFeature(&quot;billTo&quot;), &quot;123 Elm St.&quot;);
    • 48. Dynamic EMF
      • An Ecore model can also be defined at runtime using Ecore API or loaded from persistent form
        • No generated code required
        • Dynamic implementation of reflective EObject API provides same runtime behavior as generated code
        • Can create dynamic subclasses of generated classes
      • The framework treats all model instances the same, whether generated or dynamic
    • 49. Change Recording
      • The change model represents changes to instances of any EMF model
    • 50. Change Recording
      • Change recorder
        • Adapter that creates change description based on notifications, to describe reverse delta
        • Provides transaction capability
      ChangeRecorder changeRecorder = new ChangeRecorder(resourceSet); try { // modifications within resource set } catch (Exception e) { changeRecorder.endRecording().apply(); }
    • 51. Validation
      • Models can define named constraints and invariants for batch validation
        • Invariant
          • Defined directly on class, as <<inv>> operation
          • Stronger statement about validity than a constraint
        • Constraint
          • Externally defined via a validator
      • Invariants and constraints are invoked by a validator, which is generated for a package, if needed
        • Bodies of invariants and constraints are usually hand-coded
    • 52. Automatically Implemented Constraints
      • EObjectValidator validates basic constraints on all EObjects (multiplicity, data type values, etc.)
        • Used as base of generated validators and directly for packages without additional constraints defined
      • In XML Schema, constraints can be defined as facets on simple types
        • Full implementation generated in validator
      <xsd:simpleType name=&quot;SKU&quot;> <xsd:restriction base=&quot;xsd:string&quot;> <xsd:pattern value=&quot;d{3}-[A-Z]{2}&quot;/> </xsd:restriction> </xsd:simpleType>
    • 53. Diagnostician
      • Diagnostician walks a containment tree of objects, dispatching to package-specific validators
        • Diagnostician.validate() is the usual entry point
        • Detailed results accumulated as Diagnostics
      Diagnostician validator = Diagnostician.INSTANCE ; Diagnostic diagnostic = validator. validate (order); if (diagnostic.getSeverity() == Diagnostic.ERROR) { // handle error } for (Diagnostic child : diagnostic.getChildren()) { // handle child diagnostic }
    • 54. EMF Utilities
      • Class EcoreUtil provides various static convenience utilities for working with EObjects
        • Copying
        • Testing equality
        • Also, cross referencing, contents/container navigation, annotation, proxy resolution, adapter selection, and more…
      EObject copy = EcoreUtil.copy(original); boolean equal = EcoreUtil.equals(eObject1, eObject2);
    • 55. Agenda
      • What is Modeling?
      • Defining a Model with EMF
      • EMF Architecture
      • Code Generation
      • Programming with EMF
      • Summary
    • 56. Summary
      • EMF is low-cost modeling for the Java mainstream
      • Leverages the intrinsic model in an application
        • No high-level modeling tools required
      • Mixes modeling with programming to maximize the effectiveness of both
      • Boosts productivity and integrates integration
      • The foundation for model-driven development and data integration in Eclipse
    • 57. Resources
      • EMF documentation in Eclipse Help
        • Overviews, tutorials, API reference
      • EMF project Web site
        • http://www.eclipse.org/modeling/emf/
        • Downloads, documentation, FAQ, newsgroup, Bugzilla, Wiki
      • Eclipse Modeling Framework, by Frank Budinsky et al.
        • ISBN: 0131425420
        • Rough cut of second edition available
        • http://my.safaribooksonline.com/9780321331885
    • 58. Legal Notices
      • Copyright © IBM Corp., 2005-2008. All rights reserved. Source code in this presentation is made available under the EPL, v1.0. The remainder of the presentation is licensed under the Creative Commons Attribution-Noncommercial-No Derivative Works 2.5 License (http://creativecommons.org/licenses/by-nc-nd/2.5/).
      • IBM and the IBM logo are trademarks or registered trademarks of IBM Corporation in the United States, other countries or both.
      • Rational and the Rational logo are trademarks or registered trademarks of International Business Machines Corporation in the United States, other countries or both.
      • Java and all Java-based marks, among others, are trademarks or registered trademarks of Sun Microsystems in the United States, other countries or both.
      • Unified Modeling Language and UML are trademarks of Object Management Group Inc. in the United States, other countries or both.
      • Eclipse and the Eclipse logo are trademarks of Eclipse Foundation, Inc.
      • Other company, product and service names may be trademarks or service marks of others.
      • The information discussed in this presentation is provided for informational purposes only. While efforts were made to verify the completeness and accuracy of the information, it is provided &quot;as is&quot; without warranty of any kind, express or implied, and IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, such information. Any information concerning IBM's product plans or strategy is subject to change by IBM without notice.

    ×