Eclipse Modeling Framework (EMF) and Graphical Modeling Framework (GMF)

Model Driven Engineering
Department of Computer Science
Slide 1
The Eclipse Modeling (EMF) and Graphical Modeling (GMF) Frameworks
Lecturer: Dimitris Kolovos

Slide 2
Lecture Objectives
•Explore the Eclipse Modelling Framework
–Defining metamodels using Ecore
–Creating models that conform to Ecore metamodels
•Reflectively
•Through a dedicated tree-based editor
•Explore the Eclipse Graphical Modeling Framework (GMF)
–Capabilities, organisation, limitations
•Demonstrate the Eugenia tool that simplifies the development of GMF editors
–Annotations, polishing transformations

Slide 3
Eclipse Modeling Framework (EMF)

Slide 4
Eclipse Modeling Framework
•Robust and proven modelling framework built on top of Eclipse
–Since 2002 (open-sourced by IBM)
–Used in many commercial products (e.g. IBM Rational Software Architect, Gentleware Apollo for DSLs, Obeo Designer)
–Is the basis of the Eclipse modelling eco-system
–De-facto standard for modelling in the Java world

Slide 5
Eclipse Modeling Framework
•Supports the definition of metamodels using a dedicated metamodelling language (Ecore)
•Supports the definition of models that conform to Ecore metamodels
–Using graphical editors, generated Java code and a reflective API (more in the sequel)
•Supports serialising and desialising models
–In XMI by default, but supports pluggable model persistence formats
•Provides a built-in model validation framework
–Extensible, can support constraints expressed in Java or in dedicated constraint languages (e.g. EVL, OCL)

Slide 6
XML Metadata Interchange (XMI)
•The default serialisation format for EMF models and metamodels
•XML-based format standardised by the Object Management Group
–Currently at version 2.0
•XML based format
–Basically, XML with built-in support for cross- references between XML (model) elements

Slide 7
ECORE

Slide 8
Ecore: EMF's metamodelling language
•A dedicated language for constructing metamodels in EMF
•An object-oriented language
–EClasses, EAttributes, EReferences, Eoperations, EDataTypes, EEnum(erations) etc.
•Supports multiple inheritance
–Like C++, unlike Java
•Self-defined
–Ecore's metamodel is specified using Ecore

Slide 9

Slide 10
EPackage
•The top-level object of an Ecore file
–In Ecore terminology metamodel === EPackage
•Semantically similar to a Java package
•Each EPackage has a name, a namespace URI and a prefix
–nsURI (Namespace URI): Global EPackage identifier
•Ideally, each EPackage in the world should have a unique nsURI
–Prefix: No semantics. Only used for XMI serialisation
•An EPackage can contain
–EClasses and EDataTypes (both inherit from EClassifier)
–Nested EPackages (highly discouraged as many EMF-based tools don't play well with these)

Slide 11

Slide 12
EDataType
•Represent primitive types
•Ecore provides built-in support for some EDataTypes (EString, EInteger, EBoolean, EDouble)
•Each EDataType needs to define the fully- qualified name of the Java class that can convert strings to instances of the data type and vice-versa

Slide 13

Slide 14
EEnum
•Semantically equivalent to a Java enumeration
•Defines a fixed set of possible values (literals)
•Each literal has a name and an integer value
–Integer value is incremental starting from 0

Slide 15

Slide 16
EClass
•Semantically similar to a Java class
•Can be instantiated to produce model elements
–In the same way that Java classes can be instantiated to produce objects
–Except if its abstract or interface properties are set to true (similar to Java)
•Can inherit from multiple EClasses
–Unlike Java classes
•Can contain
–(E)StructuralFeatures (EAttributes and EReferences)
–EOperations

Slide 17

Slide 18
EStructuralFeature
•EAttributes and EReferences are collectively known as EStructuralFeatures
–EAttributes: Provide slots for values of primitive types (EDataTypes, EEnum)
–EReferences: Provide slots for model elements
–They only denote structure, in contrast to EOperations which denote behaviour
•Each EStructuralFeature has
–a name
–a type (eType)
–a lower-bound and an upper-bound multiplicity e.g.
•0..-1 (-1 means unbounded/*)
•2..5
•0..1

Slide 19
EStructuralFeature
•EStructuralFeatures can be marked as
–derived: the value of the feature is computed and cannot be changed directly by the user
–volatile: the value of the feature is not persisted when the model is saved
–transient: the value of the feature is recomputed every time it is requested

Slide 20

Slide 21
EReference
•Containment
–If a model element is deleted from the model, any elements under its containment EReferences are also deleted
–Each model element can belong to at most one containment EReference slot
•eOpposite
–Enables 2-way synchronisation between EReferences
–Opposites need to be specified on both participating EReferences
–The opposite of the opposite of an EReference must be the EReference itself

Slide 22
No Opposites
class Node {
ref Transition[*] outgoing;
ref Transition[*] incoming;
}
class Transition {
ref Node source;
ref Node target;
}

Slide 23
Added Opposites
class Node {
ref Transition[*]#source outgoing;
ref Transition[*]#target incoming;
}
class Transition {
ref Node#outgoing source;
ref Node#incoming target;
}

Slide 24

Slide 25
EOperation
•Semantically equivalent to a Java method
•Has a name, typed parameters and a return type
–The multiplicy of an EOperation (loweBound, upperBound inherited from ETypedElement) affect its return type
•For example if the multiplicity of an operation is 0..* and its return type is EString, it means that the operation will return a list of Estrings
•Ecore can only define the signatures of operations
–Not their logic!
–More on this shortly

Slide 26
DEFINING ECORE METAMODELS

Slide 27
Defining Ecore Metamodels
•Many different options
•Emfatic (recommended)
–Textual syntax for Ecore metamodels
•Tree-based Ecore editor
–Default editor
•Diagram-based Ecore editor
•Xcore, OCLInEcore
•Import from
–Java interfaces
–Rational rose
–XML Schema

Slide 28
Emfatic
•Textual language for defining Ecore metamodels
–Very similar to Java
•Supported by an Eclipse editor
–Syntax highlighting
–Error reporting
–Outline view
•Loss-less 2-way mapping between Emfatic <-> Ecore
–You can generate an Ecore metamodel from an Emfatic file
–You can generate an Emfatic file from an Ecore metamodel
•Language reference
–www.eclipse.org/epsilon/doc/articles/emfatic

Slide 29
Emfatic Editor

Slide 30
Emfatic->Ecore
•Generate Ecore model in the context menu of .emf files

Slide 31
Ecore->Emfatic
•Generate Emfatic Source in the context menu of .ecore files

Slide 32
Ecore Tree-based Editor
•Works directly on Ecore files
•Integrates with the Properties view to edit properties of selected metamodel elements
•Robust but not particularly user-friendly

Slide 33
Ecore Tree-based Editor

Slide 34
Diagram-based Ecore Editor
•Graphical editor for Ecore models
•Stores information in 2 files
–.ecore: The actual Ecore metamodel
–.ecorediag: Contains information about the layout of the diagram only
•Basic auto-layout capabilities
•Modifying your Ecore model outside of the diagram-based editor may mean that you then have to redraw (parts of) the diagram
•I only use it to visualise stable Ecore metamodels

Slide 35
Diagram-based Ecore Editor

Slide 36
Other alternatives
•OCLInEcore
–http://wiki.eclipse.org/OCL/OCLinEcore
–Similar to Emfatic but with support for defining the implementation of derived attributes / operations using OCL
•Xcore
–http://wiki.eclipse.org/Xcore
–Similar to OCLInEcore but uses a different language (Xbase) for defining the implementation of derived attributes / operations

Slide 37
Importing from Existing Artefacts
•EMF provides import wizards for initialising Ecore metamodels from existing artefacts
–Java interfaces, Rational Rose models, XML Schemas

Slide 38
Creating Models
•Once you've defined your Ecore metamodel you'll want to create models that conform to it
•You have (at least) 2 options
–Create models in the same Eclipse workspace through EMF's reflective tree-based editor / API
–Generate code / a dedicated tree-editor from your Ecore metamodel
•To use the generated tree-editor you'll need to launch a new Eclipse instance from within Eclipse (more on this shortly)

Slide 39
CREATING MODELS IN THE SAME WORKSPACE

Slide 40
Metamodel Registration
•Before you can create a model that conforms to your Ecore metamodel, you need to let EMF know about your Ecore metamodel
–i.e. you need to register your metamodel
•To register your Ecore metamodel, right-click on the .ecore file and select Register EPackages

Slide 41
The EMF Package Registry
•When you do this
–the .ecore file is parsed into an EPackage
–the EPackage is stored in EMF's package registry (essentially a hash-map), using its nsURI as the key
•To explore the metamodels that are currently registered in the EMF Package Registry, you can use the EPackage Registry view
–Window->Show View->Other …

Slide 42
EPackage Registry View
Tip: The EPackage Registry view does not auto-refresh. You will need to click the Refresh button (top-right corner) when you launch it for the first time, and every time you register new metamodels.

Slide 43
Creating Models
•Once EMF knows about your metamodel, you can create models that conform to it using the File->New->EMF Model wizard
•Need to provide
–A filename
–The nsURI of the metamodel your model should conform to
–The type (EClass) of the root model element of your model

Slide 44
Creating Models

Slide 45
Editing Models in the Reflective Editor
•Once you've created your model it will appear in a new tree-based editor
•You can right-click elements of your model to create new children (for containment references) and use the properties view to change the values of attributes and non- containment references

Slide 46
Editing Models in the Reflective Editor

Slide 47
GENERATING A DEDICATED TREE- BASED EDITOR

Slide 48
Generating Code
•EMF provides tooling that can consume an Ecore metamodel and generate
–A Java API for your metamodel
–A dedicated tree-based editor
•The editor is an Eclipse plug-in project
–You'll need to run a new Eclipse instance from within Eclipse to use it

Slide 49
Generating Code
•2-step transformation
–Ecore -> GenModel (Model-to-Model)
–GenModel -> Java code (Model-to-Text)
•GenModel
–Intermediate model used to specify code generation options (e.g. which directory / Java package the code will be generated under)
•Step-by-step instructions follow

Slide 50

Slide 51

Slide 52

Slide 53

Slide 54

Slide 55

Slide 56

Slide 57

Slide 58

Slide 59

Slide 60
The Generated Code
•Java code will be added to the project containing your Ecore metamodel
–Java interfaces and implementations for each EClass in your metamodel
•3 new projects
–.editor: A dedicated tree-based editor for your metamodel
–.edit: Controls the behaviour of the Properties view
•You will rarely need to worry about this one
–.tests: JUnit tests

Slide 61
Modifying the Generated Code
•To implement the behaviour of operations / derived properties
•To change the appearance / functionality of the generated tree-based editor
•Preserving code modifications
–EMF-generated code annotates methods as @generated
–If you modify the body of a method you can annotate it as @generated NOT and then EMF will preserve your modifications the next time it re-generates the code

Slide 62
Node.isStart() and Node.next
•Our metamodel contains an operation and a derived reference
–Node.isStart() operation
–Node.nodes derived reference
•By default, the code generated by EMF for these, throws an UnsupportedOperationException
–i.e. we need to implement the logic of these methods

Slide 63

Slide 64
Node.isStart() and Node.next
•We need to define the logic of these 2 features by modifying the respective methods
–and annotate the modified methods as @generated NOT so that EMF does not overwrite our code the next time it generates code from the same metamodel
•@generated methods can also be safely modified in the remaining parts of the generated code (.edit, .editor projects)
•TIP: Try not to write too much code in @generated NOT methods
–Extract the complicated code into separate classes and call it from your @generated NOT methods

Slide 65

Slide 66
Using your Generated Editor
•The generated tree-based editor (.editor) project is an Eclipse plug-in
•As such, to run it you need to run a new Eclipse instance from within Eclipse
•You can then use File->New-><Your model type> to create models using the editor

Slide 67

Slide 68

Slide 69

Slide 70

Slide 71

Slide 72

Slide 73

Slide 74

Slide 75

Slide 76

Slide 77

Slide 78
So far
•Demonstrated defining Ecore metamodels
•Demonstrated creating models that conform to an Ecore metamodel using
–The reflective tree-based editor (same workspace)
–The generated tree-based editor (requires new instance of Eclipse)
•Tree-based editors are useful but they are not very usable
•Next: developing diagram-based editors for your Ecore metamodels

Slide 79
Graphical Modeling Framework (GMF) and Eugenia

Slide 80
GMF
Graphical Modeling Framework

Slide 81
•GMF is a framework that enables the development of diagram-based editors for models conforming to Ecore metamodels
–Builds atop EMF
•GMF works in a generative manner
–No reflective option
–Need to launch a new Eclipse instance to use / test your graphical editor

Slide 82

Slide 83
•GMF needs additional information to generate a graphical editor e.g.
–How different EClasses should be visualised (as nodes? connections?)
–What labels should be attached to each diagram element (e.g. internal labels for nodes, external labels for connections)

Slide 84
Additional Models
•GMF uses 3 additional models to specify this extra information
–.gmfgraph: Defines the shapes involved the editor
•e.g. the editor will contain rectangle and diamond nodes, and connections
–.gmftool: Defines the tools in the editor palette
•e.g. there will be 5 tools titled Action, Decision, Subflow, Trigger and Transition in the palette
–.gmfmap: Defines how shapes and tools are mapped to constructs in the metamodel
•e.g. The "Action" tool will create instances of the Action EClass which will be visualised as rectangle nodes on the diagram

Slide 85
Constructing the GMF-specific Models
•GMF provides very little support for specifying the .gmfgraph, .gmftool and .gmfmap models
–Tree-based editors, insufficient validation
•These models are complex and interconnected
–The .gmfmap model contains cross-references to the .gmfgraph, .gmtool and .ecore models

Slide 86
Generating the Diagram-based Editor
•Once the .gmfgraph, .gmftool and .gmfmap models are in place, GMF provides a model-to- model transformation that creates a generator model from them (.gmfgen)
–Provides additional customisation options for the editor
•Then, a model-to-text transformation consumes the .gmfgen model and produces a new plug-in project (.diagram) that contains the Java code for the diagram-based editor

Slide 87
GMF Challenges
•The GMF-specific models are notoriously hard to get right
–The metamodels they conform to are large
–Validation is not great (you may just end up with errors in the generated code or - even worse - with runtime exceptions in your editor)
•If you modify your Ecore metamodel, you will need to update these models manually

Slide 88
EUGENIA

Slide 89
Eugenia
•A tool that simplifies the development of GMF-based editors
•Information about the graphical syntax of the language is embedded in the metamodel using readable annotations
–Validation constraints (in EVL) catch common mistakes and provide sensible feedback
•The GMF-specific models are generated automatically through a complex model-to-model transformation (in EOL)
–The generated GMF-specific models can be fine-tuned using in-place transformations (in EOL)

Slide 90
Example: FlowchartExt (1/2)
@namespace(uri="flowchartext", prefix="flowchart")
package flowchartext;
@gmf.diagram
class Flowchart {
val Node[*] nodes;
val Transition[*] transitions;
}
@gmf.node(label="label")
abstract class Node {
attr String label;
ref Transition[*]#source outgoing;
ref Transition[*]#target incoming;
}

Slide 91
Example: FlowchartExt (2/2)
@gmf.link(label="label", source="source", target="target")
class Transition {
attr String label;
ref Node#outgoing source;
ref Node#incoming target;
}
class Subflow extends Flowchart, Node { }
class Trigger extends Node { attr Date when; }
class Action extends Node { }
class Decision extends Node { }
datatype Date : "java.util.Date";

Slide 92
Eugenia
•Demonstrated only a small subset of the supported annotations
•Complete list of annotations
–http://eclipse.org/epsilon/doc/articles/eugenia- gmf-tutorial/

Slide 93
Generating a GMF Editor
•That's everything!
•You can now right-click your .emf metamodel and generate a fully-functional graphical editor
•Once you've generated your editor, you'll need to run a new instance of Eclipse to use it
–If you modify your metamodel, you will need to re-run Eugenia

Slide 94

Slide 95

Slide 96

Slide 97

Slide 98

Slide 99

Slide 100

Slide 101

Slide 102

Slide 103

Slide 104

Slide 105

Slide 106

Slide 107
Polishing the Editor
•Eugenia annotations only control a subset of GMF's capabilities
–For example, there's no annotation that controls the weight of the font of a label
–Otherwise, Eugenia would be as complex as GMF
•Still, it is often useful to fine-tune the appearance of the generated editor

Slide 108
Polishing Transformations
•Eugenia provides support for fine-tuning the generated editor through polishing transformations
–Optional in-place transformations that can be placed next to your .emf metamodel
–Modify the GMF-specific models generated by Eugenia
•2 transformations
–Ecore2GMF.eol: Can modify the .gmfgraph, .gmfmap and .gmftool models
–FigGmfGen.eol: Can modify the .gmfgen model

Slide 109
Ecore2GMF.eol
// Add bold font to action labels
var actionLabel = GmfGraph!Label.all.
selectOne(l|l.name="ActionLabelFigure");
actionLabel.font = new GmfGraph!BasicFont;
actionLabel.font.style =
GmfGraph!FontStyle#BOLD;

Slide 110

Slide 111
Advanced Eugenia
•Using images instead of shapes
–http://eclipse.org/epsilon/doc/articles/eugenia-nodes-with- images/
•Nodes with images specified at runtime
–http://eclipse.org/epsilon/doc/articles/eugenia-nodes-with- runtime-images/
•Phantom nodes
–http://eclipse.org/epsilon/doc/articles/eugenia-phantom- nodes/
•Patching the generated code
–http://eclipse.org/epsilon/doc/articles/eugenia-patching/
•Invoking Eugenia from ANT
–http://eclipse.org/epsilon/doc/articles/eugenia-ant/

Slide 112
Other Graphical Modelling Frameworks
•Sirius (builds on GMF's runtime)
–www.eclipse.org/sirius
•Graphiti
–www.eclipse.org/graphiti

Slide 113
Lecture Summary
•Explored the Eclipse Modelling Framework
–Defining metamodels using Ecore
–Creating models that conform to Ecore metamodels
•Reflectively
•Through a dedicated tree-based editor
•Explored the Eclipse Graphical Modeling Framework (GMF)
–Capabilities, organisation, limitations
•Demonstrated the Eugenia tool that simplifies the development of GMF editors
–Annotations, polishing transformations

Eclipse Modeling Framework (EMF) and Graphical Modeling Framework (GMF)

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Eclipse Modeling Framework (EMF) and Graphical Modeling Framework (GMF) (20)

More from Dimitris Kolovos (14)

Recently uploaded (20)

Eclipse Modeling Framework (EMF) and Graphical Modeling Framework (GMF)