The Eclipse Modeling Framework (EMF)

Transcrição

VICCI
Visual and Interactive Cyber-Physical Systems Control and Integration
A Practical Introduction and Technology Overview
Dipl.-Inf. Christoph Seidl
Overview of EMF

Eclipse Modeling Framework (EMF)
 Modeling framework and code generation
facility
 Employs structured data model that can be
used by other tools

Capabilities
 Define data structures (save and load, cross
references, listeners etc.)
 Generate code
 Specify languages (graphical, textual)
 Perform validation
 Transform model representations
 Generate editors (graphical, textual)
11.06.2013
The Eclipse Modeling Framework (EMF) - Christoph Seidl
2
EMF is very powerful but…
ETL
Ecore
11.06.2013
3
Overview of Presentation




Generative Model-Based Programming
Textual Domain-Specific Languages
Graphical Editors/Viewers and Data Visualization
Code Generation using Template Engines
 Further Tools and Technologies
 Validation
 Model-to-Model Transformation
 Data Handling
 Searching and Finding Model Elements
 Misc. Tools and Technologies
11.06.2013
4
Generative Model-Based Programming
Terms and Definitions

Model
 Abstraction from real world capturing important aspects (and
neglecting the ones not important) regarding an application area
 Application area here is software development for the target domain
 Can be expressed as textual language, graphical notation, various data
structures etc.

Meta Model
 „Blueprint“/building rules for models
 Describe what model elements may exist and how they interrelate

Meta Meta Model
 Building rules for meta model
 In the case of EMF: Ecore
11.06.2013
6
EMF Ecore
 MOF (Meta Object Facility)
 Specifies standard for meta meta models
 Defined by the Object Management Group (OMG)
 Complex
 EMOF (Essential MOF)
 Simplified/reduced version of standard for meta meta models
 EMF Ecore
 Implementation of EMOF
 Uses structured data for models that other tools can build upon
 Meta modeling notation of EMF (meta meta model)
 Tightly integrates with Eclipse but can be used without it
11.06.2013
7
Things you get for Free with Ecore








Source code for models
Change listener support
Automatic handling of cross/opposite references
Serialization/deserialization (save/load)
Visual tree-based editor
Property sheets
Eclipse integration
Compatibility with many other tools
11.06.2013
8
What (not) to expect from EMF
 What model-based development in EMF is
 Specification (closed world assumption)
 Data description (and more)
 Suitable for many platforms through code generation
 Aid in developing software (esp. tools)
 What model-based development in EMF is not
 Description/knowledge engineering (no open world assumption)
 Just another form of object-oriented programming
 Fully platform independent
 Panacea/silver bullet (there are caveats and pitfalls)
11.06.2013
9
Notation: Cardinality-Based Feature Model
Feature
Group
[1..1] AutomotiveMultimedia
[1..3]
[0..1] AudioPlayer
[1..1] OnBoardComputer
[0..1] PersonalNavigation
[1..2]
[1..2]
[1..1] Radio
[0..1] CDPlayer
[0..1] VoiceRecognition
[1..1] Maps
[1..1]
[0..1] AudioCDPlayer
[0..1] MP3CDPlayer
Group cardinality:
1..1 is alternative
1..n is or
m..n is arbitrary
11.06.2013
Feature cardinality:
0..1 is optional
1..1 is mandatory
The notation of cardinality-based feature
models and the content presented here
will serve as running example.
10
Practical Example
Specifying a Meta Model
Create a Plugin Project
11.06.2013
12
11.06.2013
13
11.06.2013
14
11.06.2013
15
11.06.2013
16
Create a Folder for (Meta) Models
11.06.2013
17
Create a Folder for (Meta) Models
11.06.2013
18
Create the Meta Model (Diagram)
11.06.2013
19
11.06.2013
20
11.06.2013
21
Create Meta Model Elements
11.06.2013
22
11.06.2013
23
11.06.2013
24
11.06.2013
25
11.06.2013
26
Set type of
attribute.
11.06.2013
27
11.06.2013
28
11.06.2013
29
11.06.2013
30
Create
generalization link.
11.06.2013
31
11.06.2013
32
11.06.2013
33
11.06.2013
34
11.06.2013
35
11.06.2013
36
11.06.2013
37
Containment reference: „owns“
referenced element (serialization).
An object can only be in one
containment relation at a time.
11.06.2013
38
11.06.2013
39
11.06.2013
40
Set Meta Model Namespace URI
Namespace URI is the unique
identifier of the meta model (click
on diagram background to see).
11.06.2013
41
Set Meta Model Namespace URI
Set it to a value unique and under
your control (usually webpage URL).
11.06.2013
42
Inspect Meta Model in .ecore File (optional)
Underlying representation of feature
meta model. Meta model could be
specified in this editor as well.
11.06.2013
43
Practical Example
Generating „Model“ Code from the Meta Model
How it Works: Code Generation
 Meta model (.ecore) is platform independent
 No idea about packages, Java classes etc.
 Can (in theory) be used to generate any kind of source code
 Ecore has generator for Java code
 Needs platform information!
 Generator Model (.genmodel)
 Contains information for code generation
 Java compliance level
 Which projects to generate
 Which packages to use
 Names for Java classes are derived from Ecore classes
 Possible to include generator models of referenced meta models
to reuse their generated code (not covered here)
11.06.2013
45
Create Generator Model (.genmodel)
11.06.2013
46
11.06.2013
47
11.06.2013
48
11.06.2013
49
Load
manually!
11.06.2013
50
11.06.2013
51
11.06.2013
52
Customize Generator Model
11.06.2013
53
Customize Generator Model: Model
11.06.2013
54
Customize Generator Model: Model
Set directories to generate code
in the „src-gen“ folder instead
of the „src“ folder.
(Best practice, benefits follow
later)
Do this for:
„Edit Directory“,
„Editor Directory“,
„Model Directory“,
„Tests Directory“
11.06.2013
55
Customize Generator Model: Package
Set base package for code
generation to a plausible
value. The string value of
Ecore.Package.NSPrefix will
be appended.
11.06.2013
56
Generate „Model“ Code
The „Model“ code is the
source code representing
the described data
model.
11.06.2013
57
Inspect Generated „Model“ Code (optional)
Generated classes for meta model
classes are divided into interface
(e.g., „Feature“) and its default
implementation (e.g.,
„FeatureImpl“).
11.06.2013
58
Inspect Generated „Model“ Code (optional)
The „…Factory“ class creates objects for
specified types of the meta model (e.g. „new
FeatureImpl()“ for Feature).
The „…Package“ class has knowledge of all
the types of the meta model, the namespace
etc.
11.06.2013
59
Practical Example
Creating a Model using the Generated Editor
Generate „Edit“ Code
11.06.2013
61
Generate „Edit“ Code
Edit code defines how model
elements are represented for
editing in multiple editors
(which values with which
ranges to edit, what icons to
use etc.).
11.06.2013
62
Generate „Editor“ Code
11.06.2013
63
Generate „Editor“ Code
Editor code
implements a basic
tree-based editor to
create models obeying
meta model.
11.06.2013
64
Generate „Edit“ and „Editor“ Code
Generating stubs for tests is also
possible but the test need manual
implementation (not shown here).
11.06.2013
65
Start Runtime Eclipse Instance to Use Editor
11.06.2013
66
Development and Runtime Instance of Eclipse
Until further notice, we are
operating in the runtime
instance of Eclipse!
11.06.2013
67
Create an Example Model
11.06.2013
68
11.06.2013
69
11.06.2013
70
11.06.2013
71
Pick the root element of the
model (e.g., „FeatureModel“ –
abbreviated to „Model“ by
editor due to meta model name
„Feature“).
11.06.2013
72
11.06.2013
73
Create Model Elements
Editor allows
only creation of
appropriate
elements.
11.06.2013
74
Property sheets are
generated from
attributes in meta
model classes.
11.06.2013
75
[1..3]
[0..1] AudioPlayer
[1..2]
[1..2]
[1..1] Radio
[0..1] CDPlayer
[1..1]
11.06.2013
[1..1] Maps
After this slide, we are back in
the development instance of
Eclipse!
[0..1] MP3CDPlayer
76
Practical Example
Creating a Model Programmatically
Creating a Model Programmatically
Factory is a singleton that creates all
instances of meta model classes (careful
when defining model programmatically
and overriding factory - see later)
11.06.2013
78
Practical Example
Operations for Meta Model Classes
Add an Operation
11.06.2013
80
Add an Operation
11.06.2013
81
Add an Operation
11.06.2013
82
Add an Operation
11.06.2013
83
Add an Operation
11.06.2013
84
Regenerate Meta Model Code
11.06.2013
85
11.06.2013
86
11.06.2013
87
11.06.2013
88
Inspect Generated Code (optional)
Interface
defines
method.
11.06.2013
89
Inspect Generated Code (optional)
…Impl creates standard
implementation (to be
overwritten).
11.06.2013
90
Practical Example
Customizing Generated Code
(Naive Way – Don‘t do this!)
Writing into Generated Code Files
Mark method as „@generated
NOT“ so that it is not overwritten
with next generation.
Write your code
directly in the
generated „…Impl“ file.
Do NOT do this. Mixes generated and manually
created code. Horrible for maintenance and
version control!
11.06.2013
92
Practical Example
(Using Annotations – Don‘t do this either!)
Annotate Operation with Implementation
11.06.2013
94
11.06.2013
95
11.06.2013
96
11.06.2013
97
Code generator will use
annotation and place
string value (!) as
implementation of
operation.
Do NOT do this. Includes code (low abstraction)
in meta model (high abstraction). Bad practice,
no type safety whatsoever and hard to find
where logic is specified.
11.06.2013
98
Practical Example
(Using the Generation Gap Pattern – Do this!)
The Generation Gap Pattern
„src-gen“
folder
generated
„src“ folder
manual
11.06.2013
100
Use the „src“ Folder
Manually created code goes into „src“
folder, generated code goes into „src-gen“.
11.06.2013
101
Create Custom Specializations
Create new package
„…impl.custom“ in
„src“ folder.
11.06.2013
102
Create custom
specialization of meta
model class.
11.06.2013
103
Override functionality
in custom class.
11.06.2013
104
Create custom specialization
for the factory.
11.06.2013
105
Have the custom factory
create custom
implementation for meta
model class.
11.06.2013
106
Register Custom Factory with Eclipse
Use Eclipse‘s extension
mechanism to plug in
custom factory for use.
11.06.2013
107
11.06.2013
108
Add a new
extension.
11.06.2013
109
Choose to
override an
Ecore factory.
11.06.2013
110
Namespace URI
(identifier) of the meta
model in question.
Qualified name of
the custom factory
specialization.
New Eclipse instances perform
extension and use custom factory
instead of standard factory.
11.06.2013
111
Caution: Model Code with Custom Factory
Careful when creating model
programmatically with a custom factory
(in the development instance of Eclipse).
Factory is overriden only in new Eclipse
instance. Only regular …Impl classes are
created. Solution see next slides…
11.06.2013
112
Override Created Factory in Generated Code
11.06.2013
113
Override Created Factory in Generated Code
Mark as „generated NOT“
to avoid overriding change
with next code generation.
Create object for
custom factory.
Solution is not ideal as it mixes generated
and manually writting code. However, just
two (trivial) lines in a single class.
11.06.2013
114
Textual Domain-Specific Languages
What is it?
 Specify textual syntax for models
 Create models from textual syntax (Parsing)
 Create textual representation from models (Printing)
11.06.2013
116
Benefits of Textual Languages
 Why create textual syntax for models (Printer)?
 Readability
 Version control (diff/merge)
 Evolution
 Tool automation
 Quick model instantiation
 Why create models from textual syntax (Parser)?
 Tool reuse (e.g., graphical editors etc.)
 Know-how reuse
 Explicit representation of text document structure
 Tracing software artifacts
 Graphs instead of strings
Source: http://www.emftext.org/index.php/EMFText_10_Reasons
11.06.2013
117
General Procedure
 Use metamodel to specify structure of data
 Specify a grammar for textual syntax (e.g., EBNF)
 Generate code to get (for free!):
 Parser
 Transforms text to model
 Printer
 Transforms model to text
 Editor
 Syntax highlighting
 Auto completion
 Error/warning reports
 Integration with other EMF technology
11.06.2013
118
Tools and Technologies
 EMFText
 Originally created by Software
Technology Group at TU Dresden
 Now maintained by DevBoost
 Xtext
 Originally created as part of
openArchitectureWare
 Now part of the Eclipse project
11.06.2013
119
EMFText: Overview
 Generate parser, printer, editor for textual DSLs
 Support for interpreters, builders, validation etc.
 Syntax zoo with over 100 predefined languages (e.g., Java 5, Regular
Expressions, Requirements etc.)
 Good documentation, screencast, mailing list support
 Very easy to learn and handle
 www.emftext.org
11.06.2013
120
EMFText: Workflow
Define Meta
Model (.ecore)
11.06.2013
Define
Concrete
Syntax (.cs)
Generate Code
(via Context
Menu)
121
Create a Concrete Syntax for Meta Model (.cs)
11.06.2013
127
Create a Textual Model using the Concrete Syntax
11.06.2013
135
Xtext: Overview





Generate parser, printer, editor for textual DSLs
Great potential for customization (syntax coloring, quick fixes etc.)
Powerful tool
Good documentation with many screencasts
Integrates well with Xtend, Xpand, MWE
 www.eclipse.org/Xtext
11.06.2013
139
Xtext: Workflow
Define Syntax
(.xtext)
Auto Generate
Meta Model
(.ecore)
Generate Code
(via MWE)
- OR -
Define Meta
Model (.ecore)
11.06.2013
Define Syntax
(.xtext)
Generate Code
(via MWE)
140
Xtext: Example
Source: http://www.peterfriese.de/getting-started-with-xtext/
11.06.2013
141
Sidenote: Xtend
 Statically-typed programming language defined in Xtext
 Translates to Java source code (not bytecode, good for Android/GWT)
 Feels like java but has a few extensions (extension methods, operator
overloading, polymorphic dispatch etc.)
 Can be extended by new language constructs!
 www.eclipse.org/xtend
11.06.2013
142
Xtend: Example
Source: http://www.eclipse.org/xtend/documentation.html
11.06.2013
143
Conclusion
 Easy to specify textual languages for
models
 Great time saver compared to writing
parsers or printers manually
 Good tool support: Choice between
EMFText and Xtext is a matter of
preference
 Tools integrate well with other EMF
technology (see rest of presentation)
11.06.2013
144
Graphical Editors/Viewers and Data
Visualization
What is it?
 Tooling to build graphical editors/viewers and data visualization
 Graphical editor: modify underlying data in graphical DSL
 Graphical viewer: visualize underlying data in graphical DSL
 Data visualization: represent underlying data and its connection in
a generic way (e.g., nodes and connections)
[1..3]
[0..1] AudioPlayer
[1..2]
[1..2]
[1..1] Radio
[0..1] CDPlayer
[1..1] Maps
[1..1]
11.06.2013
[0..1] MP3CDPlayer
146
Benefits of Graphical Languages
 Why create graphical syntax for models?
 Use two dimensions (x/y, not just linear as text)
 Many (primarily) graphical notations (e.g., UML Class
Diagrams/State Charts, Petri Nets)
 Some notations are easier to grasp graphically (e.g., Public
Transport Route Maps, Feature Models, Mind Maps etc.)
 Why create models for graphical syntax?
 Allow processing of underlying data in the usual way
 Integrate with other EMF technology (validate, etc.)
11.06.2013
147
General Procedure
 Define how data elements should be represented visually
 Generate/write graphical editor
11.06.2013
148
 Graphical Editing Framework (GEF)
 Zest
 Graphical Modeling Framework (GMF)
 EuGENia
 Graphiti
 Spray
11.06.2013
149
GEF: Overview
 Graphical Editing Framework (GEF)
 Code base for (manual) creation of graphical editors
 Not tied to EMF Ecore but integrates very well
 Philosophy: write all code manually
 www.eclipse.org/gef
11.06.2013
150
GEF: Workflow
Define Meta
Model (.ecore)
11.06.2013
Manually
Write GEF
Code
Graphical
Editor
151
GEF: Basic Classes

Uses the Model-View-Controller (MVC) pattern

Domain Model
 Arbitrary model representation
 May be models of Ecore meta models
 The model of MVC

Figure
 Visual representation of domain model elements (e.g., Circles, Squares)
 The view of MVC

EditPart
 Business logic for editing domain model elements (e.g., what to do when
element is deleted)
 Delegate concrete work to EditParts (see next slide)
 The controller of MVC
11.06.2013
152
Zest: Overview


Visualization toolkit
Predefined layout algorithms and visualization components

Philosophy: Layout data and its relation with minimum effort

Not the right tool to implement editors/viewers for graphical domain
specific languages

www.eclipse.org/gef/zest
11.06.2013
154
Zest: Workflow
Define Meta
Model (.ecore)
11.06.2013
Bind to Zest
Graphical
Visualization
155
GMF: Overview
 Graphical Modeling Framework (GMF)
 Builds on GEF but uses models to specify tools, editors, palettes etc.
 Philosophy: use models to configure generation of GEF code
 Faster to get an editor out than manual GEF
 Specifying models for configuration is clumsy
 Generated code is hard to comprehend and customization is clumsy
 www.eclipse.org/modeling/gmp
11.06.2013
156
GMF: Models

Domain Model
 Data representation
 Preferrable in Ecore

GMF Graph Model (.gmfgraph)
 Defines visual representation for figures, nodes, links etc.
 Customize appearance by shape, color, line weight etc.

GMF Tool Model (.gmftool)
 Defines palette, creation tools, actions etc.
 Specify which domain elements may be created, modified, deleted,
connected to each other etc.
 Specify how the tools (in the palette) are named and represented

GMF Map Model (.gmfmap)
 Specify how visual representations and tools relate to domain models
11.06.2013
157
GMF: Workflow
Define Meta
Model (.ecore)
Define GMF Configuration
Models (.gmfgraph,
.gmftool, .gmfmap)
Generate GEF
Code
Graphical
Editor
11.06.2013
158
EuGENia: Overview




Part of Epsilon project
Builds on GMF but generates its configuration models
Annotate meta model with information for graphical editor
Integrates well with EMFatic (later slides)
 Philosophy: specifying GMF models is too clumsy -> generate them!
 www.eclipse.org/epsilon/doc/eugenia
11.06.2013
159
EuGENia: Workflow
Annotate
Meta Model
Define Meta
Model (.ecore)
Generate GEF
Code
11.06.2013
Generate GMF Configuration
Models (.gmfgraph,
.gmftool, .gmfmap)
Graphical
Editor
160
Graphiti: Overview


Part of the Eclipse project (Incubation)
Originally created by SAP



Builds on GEF but hides underlying code in its API
Uses preconfigured elements (graphical, tools etc.)
Good integration of layouting algorithms

Philosophy: generate code and use sensible defaults

www.eclipse.org/graphiti
11.06.2013
161
Graphiti: Models
 Domain model
 Data representation
 Preferrably in Ecore but may be in other format
 Pictogram model
 Contains representation information
 Link model
 Connects data and representation
11.06.2013
162
Graphiti: Workflow
Define Meta
Model (.ecore)
Define Graphiti Configuration
Models (Pictogram, Link)
Generate GEF
Code
Graphical
Editor
11.06.2013
163
Spray: Overview
 Textual DSL defined in Xtext to create graphical editors
 Builds on Graphiti and uses it for code generation
 Generated code can be customized
 Code is still under heavy development
 code.google.com/a/eclipselabs.org/p/spray
11.06.2013
164
Spray: Workflow
Define Spray
Textual Format
(.spray)
Define Meta
Model (.ecore)
Generate GEF
Code
11.06.2013
Generate Graphiti
Configuration Models
(Pictogram, Link)
Graphical
Editor
165
Spray: Example
Source: Spray user guide (http://spray.eclipselabs.org.codespot.com/files/SprayUserGuide.pdf)
11.06.2013
166
Wrap Up
Graphical Editors/Viewers
Data Visualization
EuGENia
Spray
Zest
GMF
Graphiti
GEF
Ecore
11.06.2013
167
Conclusion
 Many tools to help build graphical editors
 Zest is for visualizing data and its connection
 GEF, GMF, EuGENia, Graphiti, Spray can be used for graphical DSLs
 Recommendation
 Build (small) editor with GEF to get acquainted
 If comfortable with it, switch to generation
11.06.2013
168
Code Generation using Template Engines
What is it?
 Transform model to code with a template engine
 Arbitrary textual representations (e.g., source code, textual DSLs,
configuration files etc.)
 Special form of model transformation
 Target is a textual representation
 Model-to-Text (M2T) transformation
 Difference between Printing and M2T
 Printing: target text format has same meta model
 M2T: target text format (usually) has different meta model (or no
explicit one at all)
11.06.2013
170
General Procedure
 Specify a template (skeleton of textual format with „slots“ for data)
 Use template engine to fill in data into „slots“ of template
11.06.2013
171
 Java Emitter Templates (JET)
 Part of the Eclipse project
 Very easy, no typing
 Acceleo
 Medium complexity
 Xpand
 Powerful, statically typed
11.06.2013
172
Overview: JET





Java Emitter Templates (JET)
Can generate all textual languages but has a (slight) focus on Java
Uses Java to create data to fill templates
Very easy to learn
Used by Ecore for code generation
 www.eclipse.org/emft/projects/jet
11.06.2013
173
JET: Example
Source: http://www.vogella.com/articles/EclipseJET/article.html
11.06.2013
174
Overview: Acceleo
 Pragmatic implementation of the OMG MOF Model to Text Language
(MTL) standard
 Modules, Templates
 www.eclipse.org/acceleo
11.06.2013
175
Acceleo: Example
Source: http://wiki.eclipse.org/Acceleo/Getting_Started
11.06.2013
176
Overview: Xpand




Powerful template engine
Uses textual DSL to create data to fill templates (statically typed)
Good integration with Xtext
Uses Xtend to specify custom operations on models used only for code
generation
 Caution: Xpand‘s Xtend language is another one than Xtext‘s Xtend
(which was originally called Xtend 2)

wiki.eclipse.org/Xpand
11.06.2013
177
Xpand: Example
Source: http://www.peterfriese.de/getting-started-with-code-generation-with-xpand
11.06.2013
178
Conclusion
 Multiple competing template engines
 JET is easiest to learn
 Xpand is very powerful
 Acceleo is somewhere in between
 Recommendation
 Use JET until you grow out of it
 Start using Xpand when you know that you need it
11.06.2013
179
Further Tools and Technologies
Defining Models
 Textually
 Annotated Java
 XSD Schemas
 EMFatic (wiki.eclipse.org/Emfatic)
 Epsilon Human Useable textual Notation (HUTN)
(www.eclipse.org/epsilon/doc/hutn)
 Graphically
 Ecore diagrams (from Ecore tools)
 Ecore diagrams (from Graphiti)
11.06.2013
181
Model Validation
 Some constraints cannot be enforced structurally (by design)
 Business rules that require knowledge of semantics
 E.g., one type of object only allowed for attribute if another
attribute has a certain value
 Creation of models has to respect these constraints
 Use model validation to ckeck custom validation rules
 Errors/Warnings are incorporated into other editors (textual,
graphical etc.)
 Tools and Technologies
 EMF Validation Framework
(www.eclipse.org/modeling/emf/?project=validation)
11.06.2013
182
Model-to-Model Transformation (M2M)

Information of one model has to be translated to a model of a different
meta model
 Use model-to-model transformation
 E.g., reuse model of another vendor that needs part of the
information in your model (with different meta model)

 Atlas Transformation Language (ATL)
(projects.eclipse.org/projects/modeling.mmt.atl)
 Query-Value-Transformation (QVT)
 operational: QVTo
(projects.eclipse.org/projects/modeling.mmt.qvt-oml)
 declarative: QVTd
(projects.eclipse.org/projects/modeling.mmt.qvtd)
 Epsilon Transformation Language (ETL)
(www.eclipse.org/epsilon/doc/etl)
 Programmatically
11.06.2013
183
Model Search and Find Tools and Technologies
 EMF Index (www.eclipse.org/modeling/emft/?project=emfindex)
 Create a search index of EMF models
 EMF Model Query/EMF Model Query 2
(www.eclipse.org/modeling/emf/?project=query2)
 Find model elements fulfilling a certain condition
 Textual language similar to SQL
 EMF Compare (wiki.eclipse.org/index.php/EMF_Compare)
 Find differences between two (or more) model instances
11.06.2013
184
Data Handling Tools and Technologies

EMF Service Data Objects (SDO) (www.eclipse.org/modeling/emf/?project=sdo)
 Support for service-oriented architectures (SOA)

EMF Connected Data Objects (CDO) (www.eclipse.org/cdo/#cdo)
 Distributed shared model repository
 Models may be remote

EMF Model Transactions (www.eclipse.org/modeling/emf/?project=transaction)
 Multi threading and model integrity support
 Undo/redo support
 Support for consistent representation of one model in multiple views

EMF Teneo (wiki.eclipse.org/Teneo)
 Support for database persistency (Hibernate, EclipseLink)
 Automatic EMF to relational mappings
11.06.2013
185
Misc. Tools and Technologies

Modeling Workflow Engine (MWE)
(wiki.eclipse.org/Modeling_Workflow_Engine_%28MWE%29)
 Some modeling tasks have to be carried out repeatedly
 Automating modeling work

OWLizer (st.inf.tu-dresden.de/owlizer)
 Transform Ecore models to OWL Ontologies
 Distinguishes between metamodel translation (OWL classes) and
model transformation (OWL entities)
 Developed by Software Technology Group at TU Dresden

Refactory (www.modelrefactoring.org)
 Generic Ecore model refactoring and evolution
 Reusable „refactoring patterns“ through role modeling
 Developed by Software Technology Group at TU Dresden
11.06.2013
186
Final Conclusion
Final Conclusion on EMF

Increased knowledge about data through operating on level of models

Benefits
 Short time to market through massive code generation (editors with
many support features, serialization etc.)
 Many tools and technologies that interoperate in EMF

Drawbacks
 Evolution of models problematic
 Not all platforms supported (e.g., Android)

Recommendation
 Use EMF for tooling projects in software engineering
 Think about feasibility in other scenarios
11.06.2013
188
Thank you for your attention!
Questions, Comments, Feedback?

The Eclipse Modeling Framework (EMF)

Transcrição

Documentos relacionados

Baixar este arquivo PDF