Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

5,655 views

Published on

Lecture slides from the Model-Driven Engineering module of York's MSc in Software Engineering: http://www.cs.york.ac.uk/postgraduate/taught-courses/msc-swe/

Published in: Software

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

  1. 1. Model Driven Engineering Department of Computer Science Slide 1 The Eclipse Modeling (EMF) and Graphical Modeling (GMF) Frameworks Lecturer: Dimitris Kolovos
  2. 2. 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
  3. 3. Model Driven Engineering Department of Computer Science Slide 3 Eclipse Modeling Framework (EMF) Lecturer: Dimitris Kolovos
  4. 4. 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
  5. 5. 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)
  6. 6. 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
  7. 7. Model Driven Engineering Department of Computer Science Slide 7 ECORE
  8. 8. 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
  9. 9. Model Driven Engineering Department of Computer Science Slide 9
  10. 10. 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)
  11. 11. Model Driven Engineering Department of Computer Science Slide 11
  12. 12. 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
  13. 13. Model Driven Engineering Department of Computer Science Slide 13
  14. 14. 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
  15. 15. Model Driven Engineering Department of Computer Science Slide 15
  16. 16. 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
  17. 17. Model Driven Engineering Department of Computer Science Slide 17
  18. 18. 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
  19. 19. 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
  20. 20. Model Driven Engineering Department of Computer Science Slide 20
  21. 21. 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
  22. 22. 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; }
  23. 23. 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; }
  24. 24. Model Driven Engineering Department of Computer Science Slide 24
  25. 25. 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
  26. 26. Model Driven Engineering Department of Computer Science Slide 26 DEFINING ECORE METAMODELS
  27. 27. 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
  28. 28. 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
  29. 29. Model Driven Engineering Department of Computer Science Slide 29 Emfatic Editor
  30. 30. Model Driven Engineering Department of Computer Science Slide 30 Emfatic->Ecore •Generate Ecore model in the context menu of .emf files
  31. 31. Model Driven Engineering Department of Computer Science Slide 31 Ecore->Emfatic •Generate Emfatic Source in the context menu of .ecore files
  32. 32. 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
  33. 33. Model Driven Engineering Department of Computer Science Slide 33 Ecore Tree-based Editor
  34. 34. 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
  35. 35. Model Driven Engineering Department of Computer Science Slide 35 Diagram-based Ecore Editor
  36. 36. 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
  37. 37. 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
  38. 38. 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)
  39. 39. Model Driven Engineering Department of Computer Science Slide 39 CREATING MODELS IN THE SAME WORKSPACE
  40. 40. 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
  41. 41. 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 …
  42. 42. 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.
  43. 43. 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
  44. 44. Model Driven Engineering Department of Computer Science Slide 44 Creating Models
  45. 45. 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
  46. 46. Model Driven Engineering Department of Computer Science Slide 46 Editing Models in the Reflective Editor
  47. 47. Model Driven Engineering Department of Computer Science Slide 47 GENERATING A DEDICATED TREE- BASED EDITOR
  48. 48. 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
  49. 49. 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
  50. 50. Model Driven Engineering Department of Computer Science Slide 50
  51. 51. Model Driven Engineering Department of Computer Science Slide 51
  52. 52. Model Driven Engineering Department of Computer Science Slide 52
  53. 53. Model Driven Engineering Department of Computer Science Slide 53
  54. 54. Model Driven Engineering Department of Computer Science Slide 54
  55. 55. Model Driven Engineering Department of Computer Science Slide 55
  56. 56. Model Driven Engineering Department of Computer Science Slide 56
  57. 57. Model Driven Engineering Department of Computer Science Slide 57
  58. 58. Model Driven Engineering Department of Computer Science Slide 58
  59. 59. Model Driven Engineering Department of Computer Science Slide 59
  60. 60. 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
  61. 61. 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
  62. 62. 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
  63. 63. Model Driven Engineering Department of Computer Science Slide 63
  64. 64. 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
  65. 65. Model Driven Engineering Department of Computer Science Slide 65
  66. 66. 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
  67. 67. Model Driven Engineering Department of Computer Science Slide 67
  68. 68. Model Driven Engineering Department of Computer Science Slide 68
  69. 69. Model Driven Engineering Department of Computer Science Slide 69
  70. 70. Model Driven Engineering Department of Computer Science Slide 70
  71. 71. Model Driven Engineering Department of Computer Science Slide 71
  72. 72. Model Driven Engineering Department of Computer Science Slide 72
  73. 73. Model Driven Engineering Department of Computer Science Slide 73
  74. 74. Model Driven Engineering Department of Computer Science Slide 74
  75. 75. Model Driven Engineering Department of Computer Science Slide 75
  76. 76. Model Driven Engineering Department of Computer Science Slide 76
  77. 77. Model Driven Engineering Department of Computer Science Slide 77
  78. 78. 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
  79. 79. Model Driven Engineering Department of Computer Science Slide 79 Graphical Modeling Framework (GMF) and Eugenia Lecturer: Dimitris Kolovos
  80. 80. Model Driven Engineering Department of Computer Science Slide 80 GMF Graphical Modeling Framework
  81. 81. 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
  82. 82. Model Driven Engineering Department of Computer Science Slide 82
  83. 83. 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)
  84. 84. 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
  85. 85. 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
  86. 86. 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
  87. 87. 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
  88. 88. Model Driven Engineering Department of Computer Science Slide 88 EUGENIA
  89. 89. 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)
  90. 90. 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; }
  91. 91. 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";
  92. 92. 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/
  93. 93. 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
  94. 94. Model Driven Engineering Department of Computer Science Slide 94
  95. 95. Model Driven Engineering Department of Computer Science Slide 95
  96. 96. Model Driven Engineering Department of Computer Science Slide 96
  97. 97. Model Driven Engineering Department of Computer Science Slide 97
  98. 98. Model Driven Engineering Department of Computer Science Slide 98
  99. 99. Model Driven Engineering Department of Computer Science Slide 99
  100. 100. Model Driven Engineering Department of Computer Science Slide 100
  101. 101. Model Driven Engineering Department of Computer Science Slide 101
  102. 102. Model Driven Engineering Department of Computer Science Slide 102
  103. 103. Model Driven Engineering Department of Computer Science Slide 103
  104. 104. Model Driven Engineering Department of Computer Science Slide 104
  105. 105. Model Driven Engineering Department of Computer Science Slide 105
  106. 106. Model Driven Engineering Department of Computer Science Slide 106
  107. 107. 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
  108. 108. 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
  109. 109. 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;
  110. 110. Model Driven Engineering Department of Computer Science Slide 110
  111. 111. 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/
  112. 112. 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
  113. 113. 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

×