Painless (?) Metamodel EvolutionA pragmatic approach
© 2002 IBM Corporation
Confidential | Date | Other Information, if necessary
A pragmatic approach
Eclipse Con 2010
Christian Saad (University of Augsburg, DE)Etienne Juliot (Obeo, FR)Marc Dutoo (Open Wide, FR)
About the speakers
� Christian Saad - University of Augsburg• Research assistant at the University of Augsburg
• Topics of interest: Model analysis, business processmanagement
� Etienne Juliot - founder of Obeo, FR• Contributes to several Eclipse projects (SCA Tools,
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 2
• 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
Overview
� Metamodel evolution is painful !
� JWT (migration)� use case - practices - technologies - automating it
� SCA (extensions)
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 3
� SCA (extensions)� use case - analysis - solution
� Further
� Conclusion
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 4
� 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
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)...
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 5
the purpose)...
• …if there's actually someone caring enough
� and metamodel evolutions never stopthey just pile up !
... everyone who has really used modeling / MDA has experienced it !
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 6
that allows to support different runtimes
• different GEF-based views on top of it
• compatibility with other workflow standards (through transformations)
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 7
� 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 !
1. Alleviating the pain – practices
� Modeling practices: “eager” changes• Adding new nodes breaks nothing
• However Deleting/Refactoring does
Provide abstract nodes with generic semantics
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 8
� Write unit tests which load sample models!
� But� Beware of being restricted in metamodel evolutions that won't
break "too much" legacy models
− Default behaviours are inherited
− Ex: Subclassing JWT ExecutableNode
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 9
• 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
� … and provide these to model users!• extend the EMF editor actions (yours or the original one), up
to...
• breaking free from java, code, EMF (for best… and worse)
� An EMF solution : ATL• EMF based model to model transformations
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 10
� 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!
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 11
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
� The project is moving to the new SOA TLP (move review planned April 7)
SOA Top Level Project
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 12
� Each runtime extends the SCA specifications with additional Implementation, Interface and Binding types
SCA OSOASCA OASIS
Tuscany 1.x
FraSCAti 1.x
Tuscany 2.x
Runtime x Runtime y
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
Objective: to propose a set of tools(XML editors, GMF editors, launchers, ...) based on all these metamodels
The user must have the impression he is using the same tool when he defines an SCA-OSOA or an SCA-OASIS artefact!
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 13
� Each runtime extends the SCA specifications with additional Implementation, Interface and Binding types
SCA OSOASCA OASIS
Tuscany 1.x
FraSCAti 1.x
Tuscany 2.x
Runtime x Runtime y
SCA-OASIS artefact!
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"
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 14
� The "two-headed"metamodel and the extensions specific to the different SCA runtimes are transparent for the user
SCA-OASIS SCA-OSOA
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 15
� 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
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 extendImplementation, Interface or Binding
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 16
� 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
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
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 17
• 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)
}
Further
� Eclipse Edapt
• New project under EMFT
• Goals
• Migration of model instances, editors, transformations
• Attaching migration instructions to change history
• Approaches
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 18
• Approaches
• Recording changes (COPE)
• Extracting changes (EMF Compare)
� Semantic “tagging” of meta model elements
• Research topic
• Fit for every day use?
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...
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 19
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 ?
Thanks for your attention !
A ny questions???
Contact us at [email protected] [email protected]
Eclipse Foundation, Inc. | © 2010 by the Open Wide, Obeo and University of Augsburg. Made available under the EPL v1.0 20
We thank for his assistance:
� Stephane Drapeau, Obeo, FR – SCA project leader
JWT website & wiki: http://www.eclipse.org/jwt
SCA website : http://wiki.eclipse.org/STP/SCA_Component
Top Related