emf gmf 141214150906 conversion gate02
DESCRIPTION
emf-gmf-141214150906-conversion-gateTRANSCRIPT
Model Driven Engineering Department of Computer Science
Slide 1
The Eclipse Modeling (EMF) and Graphical Modeling (GMF) Frameworks
Lecturer: Dimitris Kolovos
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
Slide 3
Eclipse Modeling Framework (EMF)
Lecturer: Dimitris Kolovos
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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)
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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)
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
Slide 22
No Opposites
class Node {
ref Transition[*] outgoing;
ref Transition[*] incoming;
}
class Transition {
ref Node source;
ref Node target;
}
Model Driven Engineering Department of Computer Science
Slide 23
Added Opposites
class Node {
ref Transition[*]#source outgoing;
ref Transition[*]#target incoming;
}
class Transition {
ref Node#outgoing source;
ref Node#incoming target;
}
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
Slide 30
Emfatic->Ecore
• Generate Ecore model in the context menu of .emf files
Model Driven Engineering Department of Computer Science
Slide 31
Ecore->Emfatic
• Generate Emfatic Source in the context menu of .ecore files
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
Slide 37
Importing from Existing Artefacts
• EMF provides import wizards for initialising Ecore metamodels from existing artefacts
– Java interfaces, Rational Rose models, XML Schemas
Model Driven Engineering Department of Computer Science
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)
Model Driven Engineering Department of Computer Science
Slide 39
CREATING MODELS IN THE SAME WORKSPACE
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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 …
Model Driven Engineering Department of Computer Science
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.
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
Slide 46
Editing Models in the Reflective Editor
Model Driven Engineering Department of Computer Science
Slide 47
GENERATING A DEDICATED TREE-BASED EDITOR
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
• Step-by-step instructions follow
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
Slide 79
Graphical Modeling Framework (GMF) and Eugenia
Lecturer: Dimitris Kolovos
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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)
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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)
Model Driven Engineering Department of Computer Science
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;
}
Model Driven Engineering Department of Computer Science
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";
Model Driven Engineering Department of Computer Science
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/
Model Driven Engineering Department of Computer Science
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
• Step-by-step instructions follow
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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
Model Driven Engineering Department of Computer Science
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;
Model Driven Engineering Department of Computer Science
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/
Model Driven Engineering Department of Computer Science
Slide 112
Other Graphical Modelling Frameworks
• Sirius (builds on GMF's runtime)
– www.eclipse.org/sirius
• Graphiti
– www.eclipse.org/graphiti
Model Driven Engineering Department of Computer Science
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