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

http://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

http://wiki.eclipse.org/OCL/OCLinEcore

http://wiki.eclipse.org/Xcore

http://wiki.eclipse.org/Xcore


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

Graphical Modeling Framework

• 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

Graphical Modeling Framework

• 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/

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/

http://eclipse.org/epsilon/doc/articles/eugenia-nodes-with-images/








http://eclipse.org/epsilon/doc/articles/eugenia-nodes-with-runtime-images/










http://eclipse.org/epsilon/doc/articles/eugenia-phantom-nodes/






http://eclipse.org/epsilon/doc/articles/eugenia-patching/




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

http://www.eclipse.org/sirius

http://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