Emf GMF 141214150906 Conversion Gate02

The Eclipse Modeling (EMF) and
Graphical Modeling (GMF) Frameworks

Lecturer: Dimitris Kolovos
Model Driven Engineering

Department of Computer Science
Slide 1
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 2
Eclipse Modeling Framework

(EMF)

Slide 3

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 4

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 5
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 crossreferences between XML (model) elements
Slide 6
ECORE

Slide 7
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 8

Slide 9
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 10

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

Slide 13
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 14

Slide 15
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 16

Slide 17
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 18
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 19

Slide 20
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 21
No Opposites
class Node {
ref Transition[*] outgoing;
ref Transition[*] incoming;
}
class Transition {
ref Node source;
ref Node target;
}

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

Slide 23

Slide 24
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 25
DEFINING ECORE METAMODELS

Slide 26
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 27
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 28
Emfatic Editor

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

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

Slide 31
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 32
Ecore Tree-based Editor

Slide 33
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 34
Diagram-based Ecore Editor

Slide 35
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 36
Importing from Existing Artefacts

EMF provides
import wizards for
initialising Ecore
metamodels from
existing artefacts
Java interfaces,
Rational Rose
models,
XML Schemas
Slide 37
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 38
CREATING MODELS IN THE SAME

WORKSPACE
Slide 39
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 40
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 41
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 42
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 43
Creating Models

Slide 44
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 noncontainment references

Slide 45
Editing Models in the Reflective Editor

Slide 46
GENERATING A DEDICATED TREEBASED EDITOR

Slide 47
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 48
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 49

Slide 50

Slide 51

Slide 52

Slide 53

Slide 54

Slide 55

Slide 56

Slide 57

Slide 58

Slide 59
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 60
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 61
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 62

Slide 63
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 64

Slide 65
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 66

Slide 67

Slide 68

Slide 69

Slide 70

Slide 71

Slide 72

Slide 73

Slide 74

Slide 75

Slide 76

Slide 77
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 78
Graphical Modeling Framework

(GMF) and Eugenia

Slide 79
GMF

Slide 80

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 81

Slide 82

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 83
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 84
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 85
Generating the Diagram-based Editor

Once the .gmfgraph, .gmftool and .gmfmap
models are in place, GMF provides a model-tomodel 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 86
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 87
EUGENIA

Slide 88
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 89
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 90
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 91
Eugenia
Demonstrated only a small subset of the
supported annotations
Complete list of annotations
http://eclipse.org/epsilon/doc/articles/eugeniagmf-tutorial/

Slide 92
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 93

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
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 107
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 108
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 109

Slide 110
Advanced Eugenia
Using images instead of shapes
http://eclipse.org/epsilon/doc/articles/eugenia-nodes-withimages/
Nodes with images specified at runtime

http://eclipse.org/epsilon/doc/articles/eugenia-nodes-withruntime-images/
Phantom nodes
http://eclipse.org/epsilon/doc/articles/eugenia-phantomnodes/
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 111
Other Graphical Modelling

Frameworks
Sirius (builds on GMF's runtime)
www.eclipse.org/sirius
Graphiti
www.eclipse.org/graphiti

Slide 112
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
Slide 113

Emf GMF 141214150906 Conversion Gate02

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Emf GMF 141214150906 Conversion Gate02

Transféré par

Droits d'auteur :

Formats disponibles

The Eclipse Modeling (EMF) and

Graphical Modeling (GMF) Frameworks

Model Driven Engineering

Explore the Eclipse Graphical Modeling

Demonstrate the Eugenia tool that simplifies the

Eclipse Modeling Framework

Model Driven Engineering

Eclipse Modeling Framework

Eclipse Modeling Framework

Supports serialising and desialising models

Provides a built-in model validation framework

XML Metadata Interchange (XMI)

XML based format

Model Driven Engineering

Ecore: EMF's metamodelling language

Supports multiple inheritance

Model Driven Engineering

Semantically similar to a Java package

Prefix: No semantics. Only used for XMI serialisation

An EPackage can contain

Model Driven Engineering

Model Driven Engineering

Model Driven Engineering

Model Driven Engineering

Can inherit from multiple EClasses

Model Driven Engineering

Each EStructuralFeature has

Model Driven Engineering

Model Driven Engineering

Model Driven Engineering

Model Driven Engineering

Model Driven Engineering

Ecore can only define the signatures of

DEFINING ECORE METAMODELS

Model Driven Engineering

Defining Ecore Metamodels

Tree-based Ecore editor

Diagram-based Ecore editor

Supported by an Eclipse editor

Loss-less 2-way mapping between Emfatic <-> Ecore

Model Driven Engineering

Model Driven Engineering

Model Driven Engineering

Ecore Tree-based Editor

Model Driven Engineering

Ecore Tree-based Editor

Model Driven Engineering

Diagram-based Ecore Editor

Basic auto-layout capabilities

Diagram-based Ecore Editor

Model Driven Engineering

Importing from Existing Artefacts

CREATING MODELS IN THE SAME

To register your Ecore metamodel, right-click on

Model Driven Engineering

The EMF Package Registry

To explore the metamodels that are currently

EPackage Registry View

Model Driven Engineering

Editing Models in the Reflective Editor

Model Driven Engineering

Editing Models in the Reflective Editor

Model Driven Engineering