This document discusses approaches for managing metamodel evolution in a pragmatic way. It presents two use cases: managing metamodel changes in the Java Workflow Tooling project using ATL model transformations, and supporting the "two-headed" SCA metamodel and runtime extensions in a transparent way for users. Automating metamodel evolution can alleviate the pain of manual migration, and practices like model versioning, documentation, and testing can help diagnose and scale changes across models.

1. Painless (?) Metamodel Evolution
A pragmatic approach
Eclipse Con 2010
Christian Saad (University of Augsburg, DE)
Etienne Juliot (Obeo, FR)
Marc Dutoo (Open Wide, FR)
Confidential | Date | Other Information, if necessary
© 2002 IBM Corporation

2. About the speakers
Christian Saad - University of Augsburg
• Research assistant at the University of Augsburg
• Topics of interest: Model analysis, business process
management
Etienne Juliot - founder of Obeo, FR
• Contributes to several Eclipse projects (SCA Tools,
Acceleo, ATL, EEF, ...) and OpenSource communities
Marc Dutoo - SOA, BPM, ECM architect
• Head of R&D Dept. at Open Wide, a French Open
Source software integrator
With the support of
• Stéphane Drapeau, Obeo, FR
• The Java Workflow Tooling (JWT) and SCA projects
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 2

3. Overview
Metamodel evolution is painful !
JWT (migration)
use case - practices - technologies - automating it
SCA (extensions)
use case - analysis - solution
Further
Conclusion
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 3

4. Metamodels do evolve !
along with
The business domain
• Driven by new requirements or standards
• Concepts or attributes may be added or become obsolete
Internal features
Driven by features of the modeling tool itself
Ex: layout information
External features
• Driven by model usage
• Ex: runtime information (logging, transactions) in workflows
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 4

5. Metamodel changes are...
(too?!) easy to design (EMF & co)
painful to cope with – for devs and users alike
• old models must be migrated (tedious and boring)
• or their legacy metamodels maintained (defeats
the purpose)...
• …if there's actually someone caring enough
and metamodel evolutions never stop
they just pile up !
... everyone who has really used modeling / MDA has
experienced it !
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 5

6. Introducing the JWT use case
we experienced it at our project
• Java Workflow Tooling (JWT)
• An extensible Workflow tool suite in the SOA TLP
all the more because it aims at
• an extensible model (through aspect-like extensions)
that allows to support different runtimes
• different GEF-based views on top of it
• compatibility with other workflow standards (through
transformations)
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 6

7. 1. Alleviating the pain - diagnostic
Know where you are
• store a version number in the model
• version-specific namespace: pros and cons
• Use it if your technology allows it – see next
Manage evolutions
• talk about them! (Wiki, release notes, warning dialogs)
• write howtos on evolving legacy models in bugzillas
• ex. "all nodes with a X=Y property now are of type Z"
But
• The user still has to do everything, so it hurts !
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 7

8. 1. Alleviating the pain – practices
Modeling practices: “eager” changes
• Adding new nodes breaks nothing
• However Deleting/Refactoring does
Provide abstract nodes with generic semantics
− Default behaviours are inherited
− Ex: Subclassing JWT ExecutableNode
Write unit tests which load sample models!
But
Beware of being restricted in metamodel evolutions that won't
break "too much" legacy models
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 8

9. 2. Scalpels - using technologies
Been there, done that :
• you've migrated two models by hand, and don't want to do it
again. So code the evolution rules that you documented!
• Ex.: Java EMF - lighter : scripting (groovy)
BUT source and target metamodels are different:
• load both: But still has to code the copy of the part of the
original model that didn't change (most of it actually)
A simple, content-oriented solution : XSL
• breaking free from java, code, EMF
(for best… and worse)
An EMF solution : ATL
• EMF based model to model
transformations
… and provide these to model users!
• extend the EMF editor actions (yours or the original one), up
to...
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 9

10. 3. Healing - automating evolution
Make the evolution transparent
• When evolving (meta)models , most of the work is
the same
• Check version, if not the same as your tool's, find and
apply required transformation
JWT’s ATL model converter
• Lightweight ATL-based framework
• Developers only need to slightly adapt the ATL
transformation
• Ask users whether they are OK
with automatic transformation
before manipulating files!
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 10

11. Introducing the SCA Tools project
Service Component Architecture (SCA) aims to provide
A model for the creation of service components in a
wide range of languages and
A model for assembling service components into a
business solution
SCA Tools project is a set of tools for developers of SCA
applications
The project was created under the SOA Tools Platform
(STP) TLP
SOA The project is moving to the new SOA TLP (move
Top Level review planned April 7)
Project
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 11

12. SCA "two-headed" metamodel and its extensions
SCA was initiated by the Open SOA consortium
→ SCA specifications 1.0
Currently, the OASIS Open Composite Services
Architecture (CSA) Member Section is standardizing SCA
→ SCA specifications 1.1
Each runtime extends the SCA specifications with
additional Implementation, Interface and Binding types
SCA
SCA OSOA
OASIS
Tuscany FraSCAti Tuscany
Runtime x Runtime y
1.x 1.x 2.x
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 12

13. SCA "two-headed" metamodel and its extensions
SCA was initiated by the Open SOA consortium a set of tools
Objective: to propose
(XML editors, GMF editors, launchers,
→ SCA specifications 1.0 ...) based on all these metamodels
Currently, the OASIS Open Composite Services
Architecture (CSA) Member Sectionuser must have the impression
The is standardizing SCA
he is using the same tool when he
→ SCA specifications 1.1 defines an SCA-OSOA or an
Each runtime extends the SCA specifications with
SCA-OASIS artefact!
additional Implementation, Interface and Binding types
SCA
SCA OSOA
OASIS
Tuscany FraSCAti Tuscany
Runtime x Runtime y
1.x 1.x 2.x
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 13

14. How we support the "two-headed" metamodel
For each SCA specifications (OSOA and OASIS), we generated
the metamodel and the GMF designer
The same SCA runtimes extension mechanism is used
The "two-headed"
metamodel and
the extensions
specific to the
different SCA
runtimes are SCA-OASIS SCA-OSOA
transparent for
the user
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 14

15. How do we support the SCA runtimes extensions?
A core metamodel: SCA-OSOA or SCA-OASIS
Extensions proposed by the SCA runtimes concern only the
Implementation, Interface and Binding types
Extension of the core metamodels is easy
Use the "Child Creation Extenders" and "Extensible
Provider Factory" options proposed in the .genmodel
Extension of the GMF modeler is more difficult
GMF does not take into account the extension options
proposed by EMF
→ Specific code in the sca.diagram plugin
→ New plugin (sca.diagram.extension) to dynamically
take into account the extensions
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 15

16. Create your own extension
First step: extend the SCA metamodel
Create a new metamodel
Create a DocumentRoot that extends the
DocumentRoot of the SCA metamodel
Create your own elements that extend
Implementation, Interface or Binding
Generate the code
Second step: extend the Composite Designer
org.eclipse.gmf.runtime.emf.type.core.elementTypes
org.eclipse.gmf.runtime.emf.type.core.elementTypeBindings
…
Third step: Extend existing ATL transformations and Acceleo generators
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 16

17. Further
COPE by TUM Munich University (http://cope.in.tum.de)
• Transformations
• by recording metamodel changes
• Mixes automatic and manually defined ones
High level transformation definition
• But
• Developers must be “convinced” to follow this procedure
• Overhead when “trying out” new things in your models
• Changes in semantics only recorded in developer’s mind!
// 1. metamodel adaptation
Signature.inPort.eType = newClass("InPort", [Port])
Signature.outPort.eType = newClass("OutPort", [Port])
Port.’abstract’ = true
// 2. model migration
for(signature in Signature.instances) {
for(port in signature.inPort) port.migrate(InPort)
for(port in signature.outPort) port.migrate(OutPort)
}
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 17

18. Further
Eclipse Edapt
• New project under EMFT
• Goals
• Migration of model instances, editors, transformations
• Attaching migration instructions to change history
• Approaches
• Recording changes (COPE)
• Extracting changes (EMF Compare)
Semantic “tagging” of meta model elements
• Research topic
• Fit for every day use?
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 18

19. Conclusion
From alleviating the pain, up to automated “healing”
JWT use case
• ATL converter : robust and versatile
• Next: graphical UI help, help migrating models referred by
other models, help migrating model transformations...
SCA "two-headed" metamodel use case
• Simple at EMF model level, harder at GMF UI level, but at the
end transparent for the user
• SCA metamodel can be used by others tools: ATL (module
superimposition), Acceleo (dynamic templates), EEF
What about your own experiences ?
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 19

20. Thanks for your attention !
A ny questions? ? ?
Contact us at christian.saad@informatik.uni-augsburg.de
or etienne.juliot@obeo.fr
or marc.dutoo@openwide.fr
JWT website & wiki: http://www.eclipse.org/jwt
SCA website : http://wiki.eclipse.org/STP/SCA_Component
We thank for his assistance:
Stephane Drapeau, Obeo, FR – SCA project leader
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 20