1. The Eclipse Modeling Framework
and MDA®
Status and Opportunities
David Frankel Consulting
df@DavidFrankelConsulting.com
www.DavidFrankelConsulting.com
Portions adapted from the book Model Driven Architecture: Applying MDA™ to Enterprise Computing,
by David Frankel, published by John Wiley & Sons OMG Press
© 2004 David Frankel Consulting, All Rights Reserved

2. Agenda
• Model-Driven Metadata Management
• EMF and MDA Standards
– EMF and the MOF™ Core
– EMF and XMI® (XML Metadata Interchange)
– EMF and JMI (Java Metadata Interface)
– EMF and CMI (CORBA® Metadata Interface)
• Looking Forward: EMF, MDA, and other related
technologies
– Aspect-Oriented Modeling
– Product Line Practices
– Intentional Programming
– Generative Programming
– Microsoft modeling directions
EMF and MDA © 2004 David Frankel Consulting 2

3. Model-Driven Metadata Management
MOF-Compliant
MOF-Compliant
Metamodel
Metamodel
MOF-XML MOF-Java MOF-CORBA
Mapping (XMI) Mapping (JMI) Mapping (CMI)
XMI
XMI MOF-Compliant
MOF-Compliant MOF-Compliant
MOF-Compliant
DTD or Schema
DTD or Schema Java APIs
Java APIs CORBA APIs
CORBA APIs
EMF and MDA © 2004 David Frankel Consulting 3

4. Metadata Management Scenario
1—Integrated MOF Repository
= MOF CORBA Interfaces
= MOF Java Interfaces (JMI) MOF Repository
= MOF XML (XMI) Documents
= Import/Export UML™
Models
Data
Models
Workflow
Models
CCM CORBA
Interfaces
B2Bi
Collaboration
Descriptions
EMF and MDA © 2004 David Frankel Consulting 4

5. Metadata Management Scenario
2—Federated MOF Repositories
= MOF CORBA Interfaces
= MOF Java Interfaces (JMI)
= MOF XML (XMI) Documents
= Import/Export
MOF Repository MOF Repository
UML UML
Models Models
…
…
B2Bi B2Bi
Collaboration Collaboration
Descriptions Descriptions
EMF and MDA © 2004 David Frankel Consulting 5

6. Metadata Management Scenario
3—Eclipse IDE
= EMF Java Interfaces (Not JMI) In-Memory
= MOF XML (XMI) Documents
= Import/Export UML
Models
Data
Models
Workflow
Models
CCM CORBA
Interfaces
B2Bi
Collaboration
Descriptions
EMF and MDA © 2004 David Frankel Consulting 6

7. Eclipse and the MOF Core
MOF 2.0
MOF 1.x EMF
Core
Core Ecore
(EMOF)
• Ecore is closer to MOF 2.0 EMOF (Essential
MOF) than MOF 1.x
• IBM has indicated that Ecore will be aligned with
EMOF
EMF and MDA © 2004 David Frankel Consulting 7

8. EMF and XMI
XML Mapping
XMI 1.x XMI 2.0 EMF XMI XMI
(DTD (DTD and Implements For
only) Schema) XMI 2.0 MOF 2.0
MOF 2.0
MOF 1.x EMF
Core
Core Ecore
(EMOF)
• EMF XMI essentially implements XMI 2.0
—But XMI 2.0 is based on the MOF 1.x Core
• EMF XMI in effect maps Ecore to MOF 1.x Core
• EMF XMI does not implement XMI 2.0
parameterizations
EMF and MDA © 2004 David Frankel Consulting 8

9. EMF and JMI
Java Mapping
JMI EMF JMI
(Sun Java For
JSR-40) Mapping MOF 2.0
MOF 2.0
MOF 1.x EMF
Core
Core Ecore
(EMOF)
• EMF Java mapping does not align with JMI
• IBM indicates alignment will happen with
JMI for MOF 2.0
– No new JMI JSR process has been started
EMF and MDA © 2004 David Frankel Consulting 9

10. EMF and CMI
CORBA Mapping
CMI CMI
For For
MOF 1.x MOF 2.0
MOF 2.0
MOF 1.x EMF
Core
Core Ecore
(EMOF)
• CMI for MOF 1.x is impractical for distributed systems
• CMI for MOF 2.0 is excellent
– Defined by real time CORBA vendors
• EMF has no implementation of either (understandable)
EMF and MDA © 2004 David Frankel Consulting 10

11. Looking Forward
EMF, MDA, and Other Related Technologies
• Aspect-Oriented Modeling
• Product Line Practices
• Intentional Programming
• Generative Programming
– Key book: Generative Programming, Krzysztof
Czarnecki and Ulrich W. Eisenecker
• Microsoft modeling directions
– Key book: Software Factories: Assembling
Applications with Patterns, Models,
Frameworks and Tools, Jack Greenfield et al
(H1’04)
EMF and MDA © 2004 David Frankel Consulting 11

12. Aspect-Oriented Programming
Persistence Statefulness Security
Functional Transactional
Identity Business Behavior
Semantics
Service
Level Logging Reentrancy
Agreements
• Separating different aspects of a system at
design time
– Related to Multidimensional Separation of Concern
• An approach to separation of concern
• Addresses “code tangling” problem
EMF and MDA © 2004 David Frankel Consulting 12

13. Product Line Practices
• Product Line
– “…a set of software-intensive systems that share a common,
managed set of features satisfying the specific needs of a particular
market segment or mission and that are developed from a common
set of core assets in a prescribed way. “—Carnegie Mellon
Software Engineering Institute
• Core Asset Development
– Capture domain knowledge in the form of reusable assets
• Define the scope of the domain
• Model the domain
• Develop components
• Define an architecture
• Production Plan
– How to produce systems using the core assets
• Product Development
– Uses core assets according to the production plan
– Creates individual products
EMF and MDA © 2004 David Frankel Consulting 13

14. Intentional Programming
• Objective: “Make the source look like the design”
• Programming via intentions
– High-level abstractions
• Active Source
– Knows how to compile itself, support editing, rendering,
and debugging
• Behaviors called at programming time
• Source graph
– Each abstract syntax tree (AST) node has a link to its
metadata
– The primary representation that plug-in modules deal with
• Not text or graphics vectors
• Transformations from one level of abstraction to
another
Charles Simonyi’s new company: Intentional Software
EMF and MDA © 2004 David Frankel Consulting 14

15. Active Source Graphs
Metamodel
Metamodel Model
Model
CWM™ Relational
CWM™ Relational CWM Relational Data Model
CWM Relational Data Model
Abstract Syntax Abstract Syntax Tree
Metamodel
Metamodel Model
Model
AST
AST AST
AST
Active Source behavior
<<call>>
invoked at programming time
Generic Host
Generic Host
Environment
Environment
EMF and MDA © 2004 David Frankel Consulting 15

16. Generative Programming (GP)
• Synthesis of
– Aspect-Oriented Programming
– Product Line Practices
– Intentional Programming
• Product Line Practices extended to include
specifying Domain-Specific Languages (DSLs) as
core assets for a product line
• Different DSLs for different aspects of the system
• Generators encapsulate product line knowledge
– Transformations from one level of abstraction to
another
• Extensible development environment based on
common technology for representing source
graphs in memory
– Capable of hosting active source for multiple DSLs
• Model Integrated Computing
– Vanderbilt Institute for Software Integrated Systems
EMF and MDA © 2004 David Frankel Consulting 16

17. Product Line Practices
Extended to Include Domain-Specific Languages
Individual
Individual Individual
Individual Individual
Individual
Product 1
Product 1 Product 2
Product 2 … Product n
Product n
Individual systems produced via product development
Production
Production
Plan
Plan
The Sims “Water Line” Reusable assets for the product line
Created via core asset development
Domain Model
Domain Model Components Architecture
Components Architecture Specialized
Specialized
Specification
Specification
Language(s)
Language(s)
i.e. DSL(s)
i.e. DSL(s)
EMF and MDA © 2004 David Frankel Consulting 17

18. Generative Programming (GP)
Design Time Composability
• Component description in some DSL pulled
in at design-time
– Application-specific configuration added
• Generator produces tailor-made component
with minimal foot print
• Similar to the latest manufacturing
processes
EMF and MDA © 2004 David Frankel Consulting 18

19. MDA as a Standards Base for GP
• Domain Specific Languages
– Languages defined via MOF (or UML® profiling)
– MOF-HUTN specification for textual DSLs
– MOF lacks the ability to define graphical syntaxes
• Active Source
– MOF-defined language packaged in a modeling framework
with components, editor, generator, debugger, rendering
support
• Source graphs in extensible development environment
for hosting active source
– JMI, driven by MOF metamodels of each DSL
• JMI provides link from an AST node to its metadata via MOF reflection
• Definitions of generators
– MOF Query View Transformations (QVT)
• Interchange of programs among tools when not “in-
memory”
– XMI, driven by MOF metamodels of each DSL
EMF and MDA © 2004 David Frankel Consulting 19

20. EMF as a GP Environment
• Already in place:
– Ecore for defining abstract syntax
– Java mapping for source graph (uses its own reflection,
not JMI-MOF reflection).
– XMI for interchange
• Still needed:
– Ability to define textual DSLs on top of abstract syntax,
using MOF-HUTN specification
– Ability to define graphical DSLs on top of abstract
syntax
• Implement over GEF
• DSTC project
• Extensions to MOF standards to follow
– Ability to define debugger plug-ins tied to abstract and
concrete syntax
EMF and MDA © 2004 David Frankel Consulting 20

21. Industry Status
• New MOF-based initiatives
– Business Process Definition Metamodel (OMG)
• BPMI.org involved
– Business Rules Metamodel (OMG)
• Key people from business rules community involved
– Ontology Definition Metamodel (OMG)
• Key people from Semantic Web community involved
– Distributed Management Task Force (DMTF)
• Moving toward MOF-based metadata
– Model-Driven data transformations a huge
opportunity (CWM)—a killer app for MDA
• Microsoft committed to GP approach
– But not to MOF
• MOF-Eclipse alignment is important
EMF and MDA © 2004 David Frankel Consulting 21

22. Trademarks
• “CORBA,” and “MDA,”, “Model Driven
Architecture,” “UML,” and “XMI” are
registered trademarks of the Object
Management Group
• “CWM” and “MOF” are trademarks of the
Object Management Group
EMF and MDA © 2004 David Frankel Consulting 22