Upload
marc-dutoo
View
4.686
Download
0
Embed Size (px)
DESCRIPTION
Software has to evolve along with the modeled domain. Over the years the pain of maintaining and migrating old models grows and grows as legacy models endlessly pile up and tend to restrict further development.In this talk presented at EclipseCon 2010 in Santa Clara, CA, Marc Dutoo of Open Wide, Christian Saad of the University of Augsburg and Etienne Juliot of Obeo discuss the pain and medicine of metamodel evolution. This is done from a developer and a user's perspective and details use cases based on the Eclipse JWT and SCA projects, along with presenting and evaluating a selection of appropriate methodologies and techniques which allow to overcome this difficulty.
Citation preview
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